Requirements

Jan 26

Thought model for the requirements process.

Requirements sound so easy to talk about in the project, everyone can figure out a few. But often and way too late the requirements were wrong and the damage for the project is done… So what is a requirement?

Digital Quality Definition of “requirements”

1. A condition or property of the user needs to solve a problem or achieve a goal
2. A condition or property such as the system or the system components must hold or comply
to meet what is in contract, standards, specification and other documents.
3. A documented occurrence of a condition or one property as described in (1) or (2).

The above definition is based on[IEEE 610.12 - Standard Glossary of Software Engineering Terminology]

So here are some ideas to help you to collect the requirements. The first simple step shown in the picture (pic 1) is how the process could look like for the requirements.

What is the purpose of requirements management? The main purpose of requirements management should be to collect needs and desires and boil them down to a few realistic requirements. Take actions on those few and try to deliver them (see pic 2).

I just want to mention that you should have in mind that there are different levels of requirements (pic 3). The client requirements will most often have the aspect of;

it is drafted from the client’s point of view ( e.g. operational requirements ),
it focuses on the user and hers /his requirements ( e.g. Acceptance test ),
it describes the “what” and calls the “why” (e.g. in the form of goals),
It provides the basis for implementation by one or more supplier.

The supplier requirements will be the type of;

it is expressed from the point of view of the supplier,
it addresses the system level ( e.g. solution, design requirements ),
It describes the “how” and thus the plan for implementing the “what” from the customer specification,
It represents the basis for the conclusion of the contract between the customer and the supplier.