Editing Requirement (section)

== Characteristics of good requirements ==
The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged.<ref name="Davis93">{{cite book |last1=Davis |first1=Alan M. |title=Software Requirements: Objects, Functions, and States, Second Edition |year=1993 |publisher=Prentice Hall |isbn=978-0-13-805763-3 |url=https://archive.org/details/softwarerequirem0000davi }}</ref>
<ref name="IEEE 830-1998 standard">{{cite book |last1=IEEE Computer Society |title=IEEE Recommended Practice for Software Requirements Specifications |year=1998 |publisher=Institute of Electrical and Electronics Engineers, Inc |isbn=978-0-7381-0332-7}}</ref>

{| class="wikitable"
|-
! Characteristic
! Explanation
|-
| Unitary (Cohesive)
| The requirement addresses one and only one thing.
|-
| Complete
| The requirement is fully stated in one place with no missing information.
|-
| [[consistency|Consistent]]
| The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
|-
| Non-Conjugated ([[Atomicity (database systems)|Atomic]])
| The requirement is ''atomic'', i.e., it does not contain conjunctions. E.g., "The postal code field must validate American ''and'' Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes".
|-
| [[traceability|Traceable]]
| The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.
|-
| Current
| The requirement has not been made obsolete by the passage of time.
|-
| [[Unambiguous]]
| The requirement is concisely stated without recourse to [[technical jargon]], [[acronym]]s (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are avoided.
|-
| Specify Importance
| Many requirements represent a stakeholder-defined characteristic the absence of which will result in a major or even fatal deficiency. Others represent features that may be implemented if time and budget permits. The requirement must specify a level of importance. 
|-
| [[Verification and validation|Verifiable]]
| The implementation of the requirement can be determined through basic possible methods: inspection, demonstration, test (instrumented) or analysis (to include validated modeling & simulation).
|}

There are many more attributes to consider that contribute to the quality of requirements.  If requirements are subject to rules of [[data integrity]] (for example) then accuracy/correctness and validity/authorization are also worthy attributes.  [[Traceability]] confirms that the requirement set satisfies the need (no more - and no less than what is required).

To the above some add Externally Observable, that is, the requirement specifies a characteristic of the product that is externally observable or experienced by the user. Such advocates argue that requirements that specify internal architecture, design, implementation, or testing decisions are probably constraints, and should be clearly articulated in the Constraints section of the Requirements document. The contrasting view is that this perspective fails on two points. First, the perspective does not recognize that the user experience may be supported by requirements not perceivable by the user. For example, a requirement to present [[Geocoding|geocoded]] information to the user may be supported by a requirement for an interface with an external third party business partner. The interface will be imperceptible to the user, though the presentation of information obtained through the interface certainly would not. Second, a constraint limits design alternatives, whereas a requirement specifies design characteristics. To continue the example, a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture.

=== 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.