Editing Requirement (section)

=== Verification ===
All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration, inspection, or review of design).

Certain requirements, by their very structure, are not verifiable. These include requirements that say the system must ''never'' or ''always'' exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable.

Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent. However, they may be traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from [[Backdoor (computing)|backdoor]]s may be satisfied by replacing it with a process requirement to use [[pair programming]]. Other non-functional requirements will trace to other system components and be verified at that level. For example, system reliability is often verified by analysis at the system level. [[Avionics software]] with its complicated safety requirements must follow the [[DO-178B]] development process.

Activities that lead to the derivation of the system or software requirements. Requirements engineering may involve a [[feasibility study]] or a ''conceptual analysis phase'' of the project and [[requirements elicitation]] (gathering, understanding, reviewing, and articulating the needs of the [[Stakeholder (corporate)|stakeholders]]) and [[requirements analysis]],<ref>{{cite book | last1=Stellman | first1=Andrew | last2=Greene | first2=Jennifer | title=Applied Software Project Management | url=http://www.stellman-greene.com/aspm/ | page=98 | publisher=O'Reilly Media | year=2005 | isbn=978-0-596-00948-9 | url-status=dead | archive-url=https://web.archive.org/web/20150209011617/http://www.stellman-greene.com/aspm/ | archive-date=2015-02-09 }}</ref> [[requirements analysis|analysis]] (checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct).<ref name="Wiegers03">{{cite book |last1=Wiegers |first1=Karl E. |title=Software Requirements, Second Edition |year=2003 |publisher=Microsoft Press |isbn=978-0-7356-1879-4}}</ref><ref name="Young01">{{cite book |last1=Young |first1=Ralph R. |title=Effective Requirements Practices |year=2001 |publisher=Addison-Wesley |isbn=978-0-201-70912-4 |url=https://archive.org/details/unset0000unse_g5k2 }}</ref>

Requirements are prone to issues of ambiguity, incompleteness, and inconsistency.  Techniques such as rigorous [[software inspection|inspection]] have been shown to help deal with these issues.  Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development.  Requirements analysis strives to address these issues.

There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they

* take a long time to produce - sometimes to the point of being obsolete once completed
* limit the implementation options available
* are costly to produce

[[Agile software development|Agile approaches]] evolved as a way of overcoming these problems, by baselining requirements at a high-level, and elaborating detail on a [[Just in time (business)|just-in-time]] or ''last responsible moment'' basis.