• Home
• Foundations
• ⁘
• Mathematical
  • Sets
  • Relations
  • Correspondences
  • Ordered Sets
  • Lattices
  • Graphs
  • Powersets
  • Cartesian Products
  • Binary Strings
  • aia
  • Greek &c.
• Logic
  • Logic
  • Math. Induction
  • Strong Induction
  • Recurs. Defs., Derivs.
  • Structural Induction
  • Regular Expressions
  • Protégé 4
  • Macro Processing
• Writing/Thinking
  • External Glossary
  • Abstracts
  • Argument
  • Formality
  • Inquiry Cycle
  • Legal Relations
  • LATEX
  • Negotiation
  • Presentations
  • Quotations
  • Teamwork
• SWD
  • Quotations
  • Kinds
  • Architecture
  • Data Flow
  • Evolution
  • IP
  • Object Orientation
  • Process
  • Reviewing
  • Testing
• Requirements
  • Kinds
  • Quick Start
  • Glossaries
  • Goals
  • i*
  • Ilities
  • Narratives
  • SCR
  • Tracing
• Specifications
  • Alloy
  • E-R
  • MSCs
  • Statecharts
  • UML
• Java
  • Coding Standards
  • Design Patterns
  • Javadoc
  • JUnit
  • Nested Classes
  • Packages
  • Types
• Web
  • (X)HTML
  • XML Schemas
  • XSLT
  • MathML

Partitioning requirements by their subject matter

Functional / non-functional

This is the most commonly-encountered partition.

• Functional requirements (FRs) express behaviors that a system is to deliver. A functional requirement is typically either satisfied or not satisfied, with nothing in between.
• All other requirements are non-functional requirements (NFRs). These include requirements related to the -ilities (suitability, reliability, usability, interoperability, verifiability, …). Nonfunctional requirements are typically not either satisfied or not satisfied, unlike functional requirements; instead, they are satisfied to a greater or lesser degree. Example: A system isn't typically either usable, or not usable, but may be more usable or less usable than some other system.

Behavioral / developmental-quality

A slightly different partition [Faulk1995-srt] divides requirements into behavioral requirements or developmental quality requirements (or requirements that are neither):

• Behavioral requirements characterize what a system's behavior is to be. These requirements are satisfied (or not) by what the system does when it runs.
• Developmental quality requirements characterize the process by which a system is produced and evolved. These requirements are satisfied (or not) by the actions of the people responsible for producing a system. Evolvability, understandability, and testability are developmental quality goals; but not usability, reliability, robustness, which are non-functional but behavioral.

Functional/non-functional and behavioral/developmental-quality don't quite divide requirements the same way. Most notably, 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).

Subdividing non-functional requirements

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).

• Operationalizable: can be refined into a functional requirement whose satisfaction implies the NFR's satisfaction.

  Example: Security (an NFR), refined into Confidentiality (also NFR) and then into PIN-authenticated (functional).

• Checkable: cannot be operationalized, but there can be a functional requirement for a system component that can check and verify whether the NFR is being satisfied.

  Example: Performance (NFR), refined into Check database workload, refined into Monitor and report number of queries answered per second (FR).

Partitioning requirements by their form

Goals

A goal is something that is desired but that might or might not be achieved, depending on circumstances. Goals are advantageous in several ways:

1. They express things that often cannot be complete achieved (such as high quality or user friendliness), or definitely established (for example by testing), but that are nevertheless things the stakeholders care about.
2. They are useful for thinking about tradeoffs of one thing for another.
3. They are at a higher level than other requirements.
4. They often refer to the system's stakeholders and the context in which the system will operate, rather than to the system itself.
5. They are usually more stable than the system's proposed properties, models over time, and narratives; they tend not to change.

Properties

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 shall 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.

Models over time

In this form, the requirements (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.

Narratives

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:

1. Unstructured text telling a story.
2. A use case, in its original meaning as a statement of a case (situation) in which a system will be used.
3. A UML use case, or a narrative divided into steps with a variety of possible relationships among the steps. These relationships are often not understood except by a use case's authors.
4. A timeline model (which is also of course a model), in which the relationships among events are graphically expressed by laying them out along timelines.

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.

Tables

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.

Audiences

Different people want different things from requirements.

• The stakeholders want requirements as a way of asking for what is needed, and as a contract that the developers are expected to fulfill.
• Development managers want the requirements to set limits on what is expected. They use the requirements to estimate the cost, time, and other resources needed to produce the required system.
• Developers want the requirements to tell them what they need to do. They use the requirements to guide their work.
• Reviewers and testers use the requirements to evaluate the development artifacts as they are produced, and to guide the creation of tests for checking whether the implementation (when it is completed) will satisfy the stakeholders' expectations.
• Maintainers use the requirements retrospectively to help them understand the system and what it should be doing.

Sources

Requirements come from many sources.

• Stakeholders, especially clients and users, are the most obvious source of requirements. They provide requirements that they hope will guide the developers to produce what the stakeholders need and want.
• The development organization typically has its own requirements, most concerning developmental qualities such as maintainability, reusability, and understandability.
• Legislatures and regulators are another source of requirements. At the present day, for example, health-care systems must meet strict requirements that are imposed by HIIPA, the federal law regulating privacy of healthcare information.
• Finally, society as a whole is a source of some requirements, for example for ethical behavior or for functions or properties that support the interests of society at large.

References

Faulk1995-srt

Xu+Ziv+2006-apnf

• thomas · alspaugh @ acm · org
• 
• 2019May11Sa10:37
• Attribution