The key to any successful relational database is the table structure. Everything else is secondary. The quality parameters must not be fields in a table like you have them now, but rather records in a table. If you use your current approach and have to add additional quality parameters, then you will have to redesign your table and all associated forms, queries, reports, macro etc.
Based on your brief description, the following is a possible table structure:
tblQualityParameters
-pkQualityParameterID primary key, autonumber
-txtQualityParameter
-longQualityPoints
You then need a table to hold the basic information about the evaluation (who, when, where...)
tblEvaluationInfo
-pkEvalInfoID primary key, autonumber
-fkPeopleID (foreign key to a table holding the information about the person doing the evaluation)
-dteEval date of the evaluation
Now you need a table that joins the specific quality parameters to the evaluation
tblEvaluationQualityParameters
-pkEvalQParametersID primary key, autonumber
-fkEvalInfoID foreign key to tblEvaluationInfo
-fkQualityParameterID foreign key to tblQualityParameters
-fkResponseID foreign key to tblResponses
tblResponses (3 records: yes, no, not applicable)
-pkResponseID primary key, autonumber
-txtResponse
There is a key concept involved in designing the table structure. It is called normalization. This
link gives some details on normalization and why it is important.