| • Science | • People | • Locations | • Timeline |
A collection of requirements then define the characteristics of the desired (required) system, but do not say how the system should implement those requirements.
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.
Requirements are notoriously difficult to pitch 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 .
It is essential that requirements go through a rigorous inspection, in order to flush out any ambiguities, anomalies and downright impossible requests!
There is a fine balance to reach between requirements which are too vague, and those which are so detailed that they
All requirements should be testable. If this is not the case, then offending requirements should be altered or dropped.
Requirements fall under change control once signed-off, and for multi-million dollar projects, it would be extremely rare for requirements not to alter before the system is complete.
Some modern software engineering methodologies like Extreme programming question the need for software requirements, which they consider a moving target, the real requirement is the program itself and the test cases.
software engineering