Go to: Definition · Why do we need requirements? · Elicitation · Glossary · Background information · What makes a good requirement? · What are the types of requirements? · How detailed? · Format
IEEE definition:
Requirements engineering refers to engineered, systematic gathering, documentation, testing and managing of requirements.
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability.
More practical view from the development team’s perspective:
… (software) is living manifestation of the development team’s collective understanding - How to build good software
Requirements capture the team’s understanding of what the system should do, code captures how it should be built.
Requirements are not collected but mined.
We should set up a common terminology before writing requirements. And use that consistently.
A glossary entry includes:
It’s impossible to capture every aspect of the system with requirements. Yet we have to make decisions during the project even when we can’t point to a requirement. In these cases it helps if we can answer the question:
Goals should be written down and agreed on, just like requirements.
Goals vs requirements
Six C: Clear, conscise, correct, coherent, complete and confirmable
and agreed on.
Functional requirements
Non-functional requirements
Architecturally significant
Architecturally significant requirements (ASR) are those requirements that have a measurable effect on a computer system’s architecture.
Highlight some requirements on which you can start designing and make easy architectural decisions. ASRs should be easily traceable to architectural elements.
Levels
Hypertext is underrated!
#sw #requirement