Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 2

Requirements Quality:

1. Are the requirements written in the user’s language? Do the users think so?
Yes, all the requirements are written in user’s language. The user can understand the
requirement easily
2. Does each requirement avoid conflicts with other requirements?
Yes, all the requirements are giving straight forward meaning for their own.
3. Are acceptable tradeoffs between competing attributes specified—for example,
between robustness and correctness?
Yes, the acceptable tradeoffs between competing attributes are specified.
4. Do the requirements avoid specifying the design?
No requirements do not avoid the specification of the design. Each of them is written in
detail.
5. Are the requirements at a fairly consistent level of detail? Should any requirement
be specified in more detail? Should any requirement be specified in less detail?
Some requirements like the password ranges from 0-9 and the paper number can be
ranges from 0-7 are once defined in the description section .Then there will be no need of
it to describe in every section of it in my point of view.
6. Are the requirements clear enough to be turned over to an independent group for
construction and still be understood? Do the developers think so?
All the requirements are written in an understandable language.
7. Is each item relevant to the problem and its solution? Can each item be traced to its
origin in the problem environment?
Yes, every item in this section is relevebt to problem and solution.
8. Is each requirement testable? Will it be possible for independent testing to
determine whether each requirement has been satisfied?
Yes, each item is testible.

You might also like