This is the most commonly-encountered partition.
Provide safe, reliable, and quick transportation around campus
Print a receipt for every transaction
Be self-explanatory and easy to use.
A slightly different partition [Faulk1995-srt] divides requirements into behavioral requirements or developmental quality requirements (or requirements that are neither):
Turn out the lights when the room is unoccupied
Be thoroughly testable so that customers will have a high level of confidence.
Functional/non-functional and behavioral/developmental-quality
don't quite divide requirements the same way.
there are nonfunctional requirements
(such as, perhaps,
Cost less than $500 per copy)
that are arguably neither
behavioral requirements (because they don't address the system's behavior)
nor developmental quality requirements
(because they don't characterize the development process).
There are arguably behavioral requirements (such as, perhaps,
Secretly provide access to internal program state
needed to make testing more effective)
that are more closely related to a nonfunctional requirements
such as testability
than to any ordinary functional requirements.
It seems that
every developmental-quality requirement
would also be a non-functional requirement,
and any functional requirement would also be a behavioral requirement
(I have not come up with counterexamples, in any case).
Nonfunctional requirements can be divided into operationalizable and checkable NFRs (and perhaps a third category of neither operationalizable nor testable — this has not been established yet) (Xu+Ziv+2006-apnf).
Example: Security (an NFR), refined into Confidentiality (also NFR) and then into PIN-authenticated (functional).
Example: Performance (NFR), refined into
database workload, refined into
Monitor and report
number of queries answered per second (FR).
A goal is something that is desired but that might or might not be achieved, depending on circumstances. Goals are advantageous in several ways:
user friendliness), or definitely established (for example by testing), but that are nevertheless things the stakeholders care about.
A requirement is often assumed to be a property
that is expected to be true of the system:
The system shall ….
The traditional requirements document
is a thick book of such properties;
such requirements documents rarely have coffee stains.
Such requirements are explicit properties that are expressed in isolation, which means that their intended context is implicit. The property is specifically stated, but the situation in which it applies and its significance in that situation are not stated.
It is traditional to use the verb
for property requirements.
An example set of property requirements: the EMS requirements, for a phone message system used in industry to prototype and explore potential new features.
In this form,
(as a group)
are the properties possessed by a model.
The system is supposed to behave
like the model.
Example: a Statechart or other finite state machine.
The desired system properties are left implicit in this form of requirements. It is not possible to distinguish which properties of the model are essential properties of the system, and which are accidental properties of the particular model that was chosen.
Models are most frequently used to express behaviors that unfold over time. If a model is formal, its behaviors can be explored or verified using software tools.
A narrative about the system can express what is expected from it in a particular situation. Narratives have the advantage of providing context and motivation, and showing how different expectations are related to each other. People are very good at expressing and understanding narratives, and can pick up on a wide variety of implicit or hinted information in a narrative.
Some kinds of narrative requirements are:
Regardless of the form in which requirements are expressed, people seem to end up telling, writing, and asking for narratives that motivate, explain, and illustrate what the requirements say.
Tabular forms organize requirements (often property requirements) into tables that show how the individual requirements are related, make it easier to find the requirement you are looking for, and simplify checking the requirements for completeness. The classic example of tabular requirements is the SCR (Software Cost Reduction) form.
Different people want different things from requirements.
Requirements come from many sources.