Requirements engineering

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.

Why do we need requirements?


Requirements are not collected but mined.


We should set up a common terminology before writing requirements. And use that consistently.

A glossary entry includes:

Background information

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

What makes a good requirement?

Six C: Clear, conscise, correct, coherent, complete and confirmable

and agreed on.

What are the types of requirements?

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.


How detailed?

Readme driven development


Hypertext is underrated!

#sw #requirement