Editing Requirement (section)

== Types of requirements ==
Requirements are typically classified into types produced at different stages in a development progression, with the taxonomy depending on the overall model being used.  For example, the following scheme was devised by the [[International Institute of Business Analysis]] in their Business Analysis Body of Knowledge<ref>{{cite book |title=A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0 |url=http://IIBA.org |year=2009 |isbn=978-0-9811292-1-1 |last1=Iiba |last2=Analysis |first2=International Institute of Business }}</ref> (see also [[FURPS]] and [[Requirements analysis#Types of requirements|Types of requirements]]).

; [[system architecture|Architectural requirements]]
: Architectural requirements explain what has to be done by identifying the necessary integration of system [[structure]] and system [[behavior]], i.e., [[system architecture]] of a system.
: In [[software engineering]], they are called [[Architecturally Significant Requirements|architecturally significant requirements]], which is defined as those requirements that have a measurable impact on a software system’s  [[Software architecture|architecture]].<ref name="ASR_Chen">{{Cite journal |doi = 10.1109/MS.2012.174|title = Characterizing Architecturally Significant Requirements|journal = IEEE Software|volume = 30|issue = 2|pages = 38–45|year = 2013|last1 = Chen|first1 = Lianping|last2 = Ali Babar|first2 = Muhammad|last3 = Nuseibeh|first3 = Bashar|hdl = 10344/3061|s2cid = 17399565|hdl-access = free}}</ref>

; [[Business requirements]]
: High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities that an organization wants to realise or problems that they want to solve. Often stated in a [[business case]].

; [[User requirements document|User (stakeholder) requirements]]
: Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the high-level business requirements and more detailed solution requirements.

; [[Functional requirements|Functional (solution) requirements]]
: Usually detailed statements of capabilities, behavior, and information that the solution will need. Examples include formatting text, calculating a number, modulating a signal. They are also sometimes known as ''capabilities''.

; [[Non-functional requirements|Quality-of-service (non-functional) requirements]]
: Usually detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate.<ref>Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., [[John Mylopoulos|Mylopoulos, J.]], and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136</ref> Examples include: reliability, testability, maintainability, availability.  They are also known as ''characteristics'', ''constraints'' or the ''[[ilities]].''

; [[Implementation|Implementation (transition) requirements]]
: Usually, detailed statements of capabilities or behavior required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include recruitment, role changes, education, migration of data from one system to another.
;[[Regulation|Regulatory requirements]]
: Requirements defined by [[Law|laws]] (Federal, State, Municipal, or Regional), [[Contract|contracts]] (terms and conditions), or [[Policy| policies]] (company, departmental, or project-level).