Requirement
From Free net encyclopedia
A requirement is a singular documented need of what a particular product or service should be or do. It is most commonly used in a formal sense in systems engineering or software engineering.
In the classical engineering approach, sets of requirements are used as inputs into the design stages of product development.
The requirements development phase may have been preceded by a feasibility study, or a conceptual analysis 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).
Contents |
Use of Requirements in Systems and Software Engineering
In systems 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 defines the characteristics or features of the desired (required) system, but generally avoids saying 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 software engineering, a software requirement is a description of what a particular piece of software should do. A piece of software may also have from dozens to thousands of requirements.
Product vs. Process Requirements
Projects are subject to three sorts of requirements, the Business Requirements that describe what in business terms must be delivered or accomplished to provide value, the Product Requirements that describe a high-level system or product which is presumably one of the possible ways to accomplishing the presumed business requirements and frequently are phrased in terms of what functions the product is expected to perform (and thus also are known as functional requirements or specifications), and the Process Requirements that describe the how. The Process Requirements prescribe the processes the developing organizations must follow and the constraints that they must obey.
The Product and Process requirements are closely linked. Process requirements are often imposed as a way of achieving some higher-level 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 for the product to be maintainable (a Product requirement) often is traced to by requirements to follow particular development styles (e.g., object-oriented programming), style-guides, or a review/inspection process (Process requirements).
Some Factors in Developing Requirements
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 present at an ideal level. Often expert users 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
In theory, good requirements should be:
- Necessary
- Non-ambiguous
- Concise
- Consistent
- Complete
- Reachable
- Verifiable
- Clear
Testability
Most requirements should be testable. If this is not the case, another verification method should be used instead (e.g. analysis, inspection or review of design). Testable requirements are an important component of validation.
Certain requirements, by their very structure are not testable. These include requirements that say the system shall never or always exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements are often rewritten to state a more practical time period.
Un-testable non-functional requirements may still be kept as a documentation of customer intent; however they are usually 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 backdoors may be satisfied by replacing it with a process requirement to use pair programming. Avionics Software with its complicated safety requirements must follow the DO-178B development process.
Testability is essentially a form of clarity, which indeed is necessary but can divert attention from other important issues. A requirement can be testable yet incorrect; and assessing testability often will not detect incorrect requirements. Moreover, testability is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized. There are more than 21 more powerful ways to test or evaluate requirements adequacy and more than 15 ways to strengthen testing or evaluation of design adequacy.
Requirements Analysis
Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous 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
- 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 should normally conform to the business domain of operation.
Changes in Requirements
With time, requirements may change.
In this case, once defined and approved, requirements should fall under change control. For many projects, it would be extremely rare for at least some requirements not to alter before the system is complete. This characteristic of requirements has led to Requirements Management studies and practices.
Disputes regarding the necessity of rigour in software requirements
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.