◦ Feasible

◦ Valid
◦ Unambiguous
◦ Verifiable
◦ Modifiable
◦ Consistent
◦ Complete and
◦ Traceable
◦ If a requirement has only one interpretation then it is
called unambiguous requirements
◦ Source of ambiguity is:
◦ Natural language
◦ Ambiguity level shows the quality of requirements
◦ Can effect project schedule and budget
 Example:
◦ Ambiguous statement:
◦ “The data complex shall withstand a catastrophe (fire,
flood).”
◦ Unambiguous statement:
◦ The data complex shall be capable of withstanding a
severe fire. It shall also be capable of withstanding a
flood
◦ Feasible
◦ Valid
◦ Unambiguous
◦ Verifiable
◦ Modifiable
◦ Consistent
◦ Complete and
◦ Traceable
◦ Also termed as testable requirements
◦ Requirements are verifiable if the developed system or
application can be tested to ensure that it meets the
requirements.
◦ But product features are not easy to be verified
◦ Proper analysis is needed to make it testable
 Example:
◦ The car shall have power brakes.
 Abstract so Not testable

◦ Detailed testable requirement:

◦ The car shall come to a full stop from 60 miles per hour within
5 seconds.
◦ Feasible
◦ Valid
◦ Unambiguous
◦ Verifiable
◦ Modifiable
◦ Consistent
◦ Complete and
◦ Traceable
◦ Software & Systems Requirements Engineering - In
Practice Mar 2009
◦ IBM press