Requirement Types

Have you ever started writing a Requirements document for your next Software project that has turned into a mess as you’ve been pouring more and more information there? I certainly did. Hopefully, there’s are clear solutions to this problem. First one, I’d say is having a clear document structure. But that’s clearly not enough if the content is not fit. That’s where Requirement Types come into play allowing you to classify all material and get rid of the unnecessary info.

First of all, what exactly is a Requirement? A requirement is a relevant statement about a project, environment, goal or system. As a requirement is a statement, it’s usually presented as a sentence or a paragraph. Thus, we can try to classify each sentence of a document you write to make sure it’s appropriate to place it in the document overall and in this particular place.

For Requirements there’s a very sophisticated classification shared by Bertrand Meyer in his book Handbook of Requirements and Business Analysis. He presents 14 general categories of requirements and 10 special cases. Meyer highlights four areas that Requirements may affect: PEGS – Project, Environment, Goals, System. Most of the requirement types are related to a single domain, others – to all of them.

Let’s briefly discuss each of the types before I present you the cheat sheet you can print and use in your daily job.

Goal requirements

1) a Goal is a need of the target organization, which the system must address. For example, “increase by 20% the proportion of graduates finding suitable jobs 6 months or less after completing their studies”.

1.1) an Obstacle is a goal consisting of removing or otherwise addressing a property of the current situation (prior to the project) that has negative consequences for the target organization.

Project Requirements

2) a Task requirement is an activity that is a component of the project. Examples are software design, user acceptance testing, domestic deployment, international deployment.

3) a Product requirement is the specification of an artifact as either:

• produced by the project (specifically, by one of its tasks), as a test plan or a particular deployable part of the system;
• needed by the project or one of its tasks; for example, the implementation task may require a particular software project management tool.

System requirements

System requirements, and more specifically behaviors, are the only ones that would appear in a conventional, simplistic view of requirements as “a description of what the system must do”.

4) a Behavior is the specification that the system must produce a certain outcome or behave in a certain way. For example, in a text processing system: “the ‘Justify’ command applied to a paragraph shall result in all its lines having an equal number of characters”.

4.1) a Functional Requirement expresses some of what the system must do.

4.2) a Non-functional Requirement expresses some of how the system will perform. Typical examples of non-functional requirements include properties of performance (timing properties on operations, parameters of storage use or bandwidth), security and privacy.

4.3) an Example is a behavior specification expressed not as a general rule (as should normally be the case) but in the form of an illustrative scenario for specific, representative cases. There are three fundamental forms of example:

• a Use Case specifies the scenario of a complete interaction of a user through the system, such as “cancel a previous order” in an e-commerce system;
• a User Story specifies the handling of a specific user need, such as logging in into the system;
• a Test Script describes a sequence of interactions with the system expected to produce a certain result. A test script includes a specification of the expected properties of that result, called a test oracle.

Environment requirements

5) a Constraint is a property of the environment that restricts what the system and project can do. An example Project constraint is “all programs developed for this project shall conform to the company’s coding standards”. An example System constraint, for an auction site, is “for past auctions, the hammer price shall be displayed only to registered users”.

• 5.1) a Business Rule is a constraint imposed by the target organization, the production organization, or another organization (such as regulatory authorities). An example for a bank transfer system is “any purchase over EUR 5,000 requires two authorized signatures”.
• 5.2) a Physical Rule is a consequence of the laws of nature, such as maximum signal speed.
• 5.3) an Engineering Decision results from an explicit choice of the project, rather than external considerations as in the previous two cases. A System example is the definition of the minimum and maximum network bandwidths that the system must support. A Project example is the imposition of a particular programming language (determined — maybe wrongly, but explicitly — by corporate standards rather than an analysis of the project’s technical needs).

6) an Assumption, also known as a precondition, is a property that we expect the environment to fulfill; the construction of the system takes it for granted. An example for a flight control system is “all pilots can understand messages in basic English”.

If you can exert influence on a condition, it will typically be to make your job easier – it’s assumption. Conversely, if a condition makes your job harder (), it is because you cannot remove or loosen it – it’s constraint.

7) an Effect, also known as a postcondition, is the specification of a change that operation of the system may bring to the environment. For example: when the system is put into operation, employees will be paid on the last working day of the month (whatever the practice was before).

8) an Invariant is an environment property that the system must maintain. In other words, it exists as both an assumption and an effect (precondition and postcondition); properties with this double affiliation will be categorized as invariants. Examples are:

1. For a factory control system, including both sensors to measure the temperature and air-conditioning units to control it, the property that the system expects a temperature between 18 to 25 degrees Celsius (precondition) and maintains it in that range (postcondition).
2. For a train control system, the property that a train can only start moving with the doors closed (precondition) and leaves them closed until arrival (postcondition). This invariant can also be formulated as a logic rule: whenever the train is moving, doors must be closed.

Requirements applying to all dimensions

9) a Component requirement specifies that the project, environment, goals or system shall contain a certain part. Examples are: a component of the project (a case which yields its own category ,“task”, discussed below) or of the environment; one of the goals; a subsystem.

10) a Responsibility requirement specifies a certain actor is in charge of carrying out a certain task (for a project requirement) or behavior (for a system requirement). “Actor” in this definition is a general term, which may cover:

1. A system component, as in the responsibility requirement “the input-output system ensures that the temperature value originally entered by the user, if validated, is in the allowable range of -20 to +40 degrees Celsius”.
2. A human actor, in which case the responsibility is also called a role, as seen below.

10.1) Role. A role requirement specifies a human or organizational responsibility. For example:

1. “UI development shall be the responsibility of the Bangalore division”, a Project role.
2. “Safety regulations for aircraft are as defined by IATA”, an Environment role.
3. “The lead-tracking system shall be designed for use by marketing reps”, a Goal role.
4. “Operation of the system for 24/7 availability shall be the responsibility of the central IT group”, a System role.

11) a Limit requirement identifies aspects that fall beyond the scope of the system. Limits are negative properties, protecting the project from matters it does not need to address.

Special requirements elements

Elements that commonly appear, or should appear, in requirements documents, but are not requirements in that strict sense since they are properties of the requirements specification itself (rather than of the project, environment, goals or system).

12) a Silence category describes something that the requirements do not include. An instance of silence is a property — pertaining to any of the PEGS — that the requirements should state, but do not. There are two sources of silence:

1. The requirements gathering process, known as “elicitation”, may miss an important need or feature in any of the four dimensions.
2. Requirements engineers may fail to record properties because everyone at the target organization considers them obvious — but they are not obvious to outsiders, including the developers.

13) Noise is the converse of “silence”: something that appears in the requirements documents, but should not.

Requirements documents often include discussions that are of no use as requirements (they are not “relevant statement about a project, environment, goal or system”). Usually the authors include them to provide more context and explanations. Such attempts are laudable in principle but in reality self-defeating because they make the requirements bigger and more complex, forcing the requirements consumers — designers, programmers, testers — to rummage the requirements for the useful gems out of a plethora of unessential comments.

A typical example of noise is repetition: an attempt to clarify the requirements by explaining properties in several ways. The resulting repetitions are often confusing, rather than helpful, particularly since the different phrasings may introduce involuntary contradictions and ambiguities.

13.1) a Hint, a case of noise made acceptable, is a suggestion for a design or implementation technique. Such techniques normally do not belong in requirements, where they risk causing over specification, a form of noise. Sometimes, however, they can be useful, as long as they are properly characterized as suggestions for other activities of the project (design, implementation…) rather than actual requirements.

14) Meta requirements. Unlike silence and noise, Meta requirements cause no harm. They appear in a requirements document to bring information not about the project, environment, goals or system but about the requirements themselves.

Examples include section titles but also explanations of forward or backward references, such as “networking protocols appear in section S.3.X”.

14.1) a Justification, a case of meta-requirement, also called a rationale, is an argument explaining the reason for a property of the System or Project in terms of a Goal or of an Environment property. Examples are:

1. “The maximum allowed time of 100ms for this input operation is necessary to meet the goal of immediate user feedback discussed in section G.4.X” (justification by a goal).
2. “The presence of two signature fields follows from the rule on purchases higher than € 5000 (section E.3.X)” (justification by an environment property, in this case a constraint).

Here you have a cheat sheet for all the types and special cases: