The Info List - Requirement

--- Advertisement ---

In product development and process optimization , a REQUIREMENT is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design , including for example in systems engineering , software engineering , or enterprise engineering . It is a broad concept that could speak to any necessary (or sometimes desired) function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" (often imprecisely referred to as "the" spec/specs, but there are actually different sorts of specifications) refers to an explicit, highly objective/clear (and often quantitative) requirement (or sometimes, set of requirements ) to be satisfied by a material, design, product, or service.

A set of requirements is used as inputs into the design stages of product development . Requirements are also an important input into the verification process, since tests should trace back to specific requirements. Requirements show what elements and functions are necessary for the particular project. When iterative methods of software development or agile methods are used, the system requirements are incrementally developed in parallel with design and implementation. With the waterfall model requirements are developed before design and implementation.


* 1 Origins of term * 2 Product versus process requirements * 3 Types of requirement

* 4 Characteristics of good requirements

* 4.1 Verification

* 5 Documenting requirements * 6 Changes in requirements

* 7 Issues

* 7.1 Competing standards * 7.2 Disputes regarding the necessity and effects of software requirements * 7.3 Requirements creep * 7.4 Multiple requirements taxonomies * 7.5 Process corruptions

* 8 See also * 9 References * 10 External links


The term REQUIREMENT has been in use in the software engineering community since at least the 1960s.

According to the Business Analysis Body of Knowledge (BABOK ), a requirement is:

* A condition or capability needed by a stakeholder to solve a problem or achieve an objective. * A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents. * A documented representation of a condition or capability as in (1) or (2).


Requirements can be said to relate to two fields:

* PRODUCT REQUIREMENTS prescribe properties of a system or product. * PROCESS REQUIREMENTS prescribe activities to be performed by the developing organization. For instance, process requirements could specify the methodologies that must be followed, and constraints that the organization must obey.

Product and process requirements are closely linked; a product requirement could be said to specify the automation required to support a process requirement while a process requirement could be said to specify the activities required to support a product requirement. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement that the product be maintainable (a product requirement) often is addressed by imposing requirements to follow particular development styles (e.g., object-oriented programming ), style-guides, or a review/inspection process (process 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 (see also FURPS and Types of requirements ). Architectural requirements Architectural requirements explain what has to be done by identifying the necessary integration of systems structure and systems behavior , i.e., systems architecture of a system. In software engineering , they are called architecturally significant requirements , which is defined as those requirements that have a measurable impact on a software system’s architecture . 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 (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 (solution) requirements Usually detailed statements of capabilities, behaviour, and information that the solution will need. Examples include formatting text, calculating a number, modulating a signal. They are also sometimes known as capabilities. 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. Examples include: reliability, testability, maintainability, availability. They are also known as characteristics, constraints or the ilities . Implementation
(transition) requirements Usually detailed statements of capabilities or behaviour required only to enable 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.


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.


Unitary (Cohesive) The requirement addresses one and only one thing.

Complete The requirement is fully stated in one place with no missing information.

Consistent The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.

Non-Conjugated (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".

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 , acronyms (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.

Verifiable The implementation of the requirement can be determined through basic possible methods: inspection, demonstration, test (instrumented) or analysis (to include validated modeling "> IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.


Many projects have succeeded with little or no agreement on requirements. Some evidence furthermore indicates that specifying requirements can decrease creativity and design performance Requirements hinder creativity and design because designers become overly preoccupied with provided information. More generally, some research suggests that software requirements are an illusion created by misrepresenting design decisions as requirements in situations where no real requirements are evident.

Meanwhile, most agile software development methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead, extreme programming for example describes requirements informally using user stories (short summaries fitting on an index card explaining one aspect of what the system should do), and considers it the developer's duty to directly ask the customer for clarification. Agile methodologies attempt to capture requirements in a series of automated acceptance tests .


Scope creep may occur from requirements moving over time. In Requirements management the alteration of requirements is allowed but if not adequately tracked or preceding steps (business goals then user requirements) are not throttled by additional oversight or handled as a cost and potential program failure, then requirements changes are easy and likely to happen. It is easy for requirement changes to occur faster than developers are able to produce work, and the effort to go backwards as a result.


There are multiple taxonomies for requirements depending on which framework one is operating under. (For example, the stated standards of IEEE, vice IIBA or U.S. DoD approaches). Differing language and processes in different venues or casual speech can cause confusion and deviation from desired process.


A process being run by humans is subject to human flaws in governance, where convenience or desires or politics may lead to exceptions or outright subversion of the process and deviations from the textbook way the process is supposed to proceed. Examples include:

* Process with no rigor gets no respect - If exceptions or changes are common, such as the organization running it having little independence or power or not being reliable and transparent in records, it may lead to the overall process being ignored. * New players wanting a do-over - e.g., The natural tendency of a new person to want to change his predecessor's work to demonstrate his power or his claims of value, such as a new CEO wanting to change the previous CEO's planning, including business goals, of something (such as a software solution) already in development, or a newly created office objects to current development of a project because they did not exist when user requirements were crafted, so they begin an effort to backtrack and re-baseline the project. * Coloring outside the lines - e.g., Users wanting more control do not just input things that meet the requirements management definition of "user requirement" or priority level, but insert design details or favored vendor characteristic as user requirements or everything their office says as the highest possible priority. * Showing up late - e.g., Doing little or no effort in requirements elicitation prior to development. This may be due to thinking they will get the same benefit regardless of individual participation, or that there is no point if they can just insert demands at the testing stage and next spin, or the preference to be always right by waiting for post-work critique.

Within the U.S. Department of Defense process, some historical examples of requirements issues are

* the M-2 Bradley issues of casual requirements movement portrayed in Pentagon Wars ; * the F-16 growth from lightweight fighter concept of the Fighter mafia , attributed to F-15 program attempting to sabotage competition or individual offices putting in local desires eroding the concept of being lightweight and low cost. * enthusiasm ca. 1998 for 'Net-Ready' led to its mandate as Key Performance Parameter from the Net-Ready office, outside the office defining requirements process and not consistent to that office's previously defined process, their definition of what a KPP was, or that some efforts might not be appropriate or able to define what constituted 'Net-Ready'.


* Business requirements * Software requirements * Requirements engineering * Requirements analysis * Requirements elicitation * Requirements management * Requirement prioritization * Requirements traceability * Specification (technical standard) * Shall and will - phrasing * MoSCoW Method - prioritisation technique * User Story * Use Case


* ^ Form and Style of Standards, ASTM Blue Book (PDF). ASTM International . 2012. Retrieved 5 January 2013. * ^ Boehm, Barry (2006). "A view of 20th and 21st century software engineering". ICSE '06 Proceedings of the 28th international conference on Software engineering. University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA. pp. 12–29. ISBN 1-59593-375-1 . Retrieved January 2, 2013. * ^ "1.3 Key Concepts - IIBA International Institute of Business Analysis". www.iiba.org. Retrieved 2016-09-25. * ^ A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0. 2009. ISBN 978-0-9811292-1-1 . * ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45. doi :10.1109/MS.2012.174 . * ^ Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J. , and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136 * ^ Davis, Alan M. (1993). Software Requirements: Objects, Functions, and States, Second Edition. Prentice Hall. ISBN 0-13-805763-X . * ^ IEEE Computer Society (1998). IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers, Inc. ISBN 0-7381-0332-2 . * ^ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. p. 98. ISBN 978-0-596-00948-9 . * ^ Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press. ISBN 0-7356-1879-8 . * ^ Young, Ralph R. (2001). Effective Requirements Practices. Addison-Wesley. ISBN 978-0-201-70912-4 . * ^ A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0. 2009. p. 4. ISBN 978-0-9811292-1-1 . * ^ "IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology". * ^ Checkland, Peter (1999). Systems Thinking, Systems Practice. Chichester: Wiley. * ^ Ralph, Paul; Mohanani, Rahul (May 2015). "Is Requirements Engineering Inherently Counterproductive?". Proceedings of the 5th International Workshop on the Twin Peaks of Requirements and Architecture. Florence, Italy: IEEE. pp. 20–23. * ^ Jansson, D.; Smith, S. (1991). "Design fixation". Design Studies. 12 (1): 3–11. * ^ Purcell, A.; Gero, J. (1996). "Design and other types of fixation". Design Studies. 17 (4): 363–383. * ^ Mohanani, Rahul; Ralph, Paul; Shreeve, Ben (May 2014). " Requirements Fixation". Proceedings of the International Conference on Software Engineering. Hyderabad, India: IEEE. pp. 895–906. * ^ Ralph, Paul (2012). "The Illusion
of Requirements in Software Development". Requirements Engineering.