Requirement |
In software engineering, a requirement is a description of what a system should do. Systems may have from dozens to thousands of requirements.
A collection of requirements then define the characteristics or features of the desired (required) system, but do not say how the system should implement those requirements. Language in the requirements that describes how the system should be implemented is known as implementation bias.
In a classical software engineering approach, requirements are used as input into the design stages (functional design followed by technical design) of the development process.
The requirements phase may have been preceded by a feasibility study, or a conceptual phase of the project. The requirements phase may be broken down into requirements elicitation (gathering the requirements from stakeholders), analysis (checking for consistency and completeness), definition (writing down descriptive requirements for developers), and specification (creating an initial bridge between requirements and design).
== Classification ==
Requirements are typically classified into three categories:
#functional requirements - Describe system features or things the system must do. #non-functional requirements - Describe properties the system must have (e.g. performance, availability, accessibility). #constraints - Limits the development in some way. Such as, defining an operating system the system must run on, or defining which programming language must be used to implement the system.
Requirements are notoriously difficult to pitch at an ideal level. Often expert user are employed to provide a link between users and developers. These expert users are able to express functional requirements in a way which is easily translated into a design feature of the system, and yet still understandable by end users.
== Good Requirements ==
A good requirement should indeed be:
All requirements should be testable . If this is not the case, then offending requirements should be altered or dropped. Testable requirements are an important component of validation.
Requirements are prone to issues of incompleteness, inconsistency, and conflict. Techniques such as rigorous software inspection have been shown to help deal with these issues. Ambiguities 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 software development. Requirements analysis strives to address these issues.
There is a fine balance to reach between requirements which are too vague, and those which are so detailed that they
#take a long time to produce #begin to limit the implementation options available #are costly to produce
== Writing Requirements ==
Requirements are written in such a way that they direct the creation/modification of a system according to the business rules appropriate to the domain in which the system will be used. Systems must conform to the business domain of operation.
== Changes in Requirements ==
With time, requirements change.
Requirements fall under change control once defined. For many projects, it would be extremely rare for requirements not to alter before the system is complete. That characteristics led to Requirements Management studies and practices.
Some modern Software Engineering methodologies like Extreme programming question the need for rigorously describing software requirements, which they consider a moving target. Instead, they describe requirements informally using user stories (short summaries fitting on an index card explaining one aspect of what the system should do), and compose a series of acceptance test cases for this user story.|
|