Anatomy of a Good Requirement

"The Online Banking System shall allow the Internet user to access her current account balance in less than 5 seconds"

• defines the system under discussion
• verb with correct identifier (shall or may)
• defines a positive end result
• quality criterion

Standard for Writing a Requirement

• Each requirement must first form a complete sentence
  • not a bullet list of buzzwords.
• several standards define how to use key words (verbs and adjectives) in their documents.

Key words for use in RFCs to Indicate Requirement Levels

• MUST, REQUIRED, or SHALL
  • mean that the definition is an absolute requirement of the spec
• MUST NOT or SHALL NOT
  • absolute prohibition
• SHOULD OR RECOMMENDED
  • think twice about not doing it!
• SHOULD NOT OR NOT RECOMMENDED
  • think twice about doing it!
• MAY OR OPTIONAL
  • truly optional

Characteristics

Look for the following:

• Needed (provides the specifics of a desired end goal or result)
• Feasible (not wishful thinking, take resources into account)
• Testable/Verifiable (contains a success criterion/other measurable indication of quality)
• Unambiguous, precise, concise, correct, singular (one thought)
• identifiable along all its life

Pitfalls

• never describe prematurely how the system is going to achieve something (over-specification), always describe what the system is supposed to do
  • danger signs: using names of components, materials, software objects, etc.
• avoid ambiguity
• don't make multiple requirements

This is a requirement with a Pitfall

"The system shall use Microsoft Outlook to send an email to the customer with the purchase confirmation."

Simple Tests

• What vs. How
  • Example: a requirement may specify an ordinary differential equation that must be solved, but it should not mention that a fourth order Runge-Kutta method should be employed
• "What is ruled out" test
  • does the requirement actually make a decision
• "Negation" test
  • if the negation of a requirement represents a position that someone might argue for, then the original decision is likely to be meaningful.
  • Failing that test may indicate the presence of a goal that still needs to be refined into requirements

Typical Mistakes

• Noise = the presence of text that carries no relevant information to any feature of the problem
• Silence = a feature that is not covered by any text
• Over-specification = text that describes a feature of the solution, rather than the problem
• Contradiction = text that defines a single feature in a number of incompatible ways
• Ambiguity = text that can be interpreted in >=2 different ways
• Forward reference = text that refers to a feature yet to be defined
• Wishful thinking = text that defines a feature that cannot possibly be validated
• Jigsaw puzzles = e.g., distributing requirements across a document and then cross-referencing
• Inconsistent terminology = inventing and then changing terminology
• Putting the onus on the development staff = i.e. making the reader work hard to decipher the intent
• Writing for the hostile reader (fewer of these exist than friendly ones)

Patterns for Functional Requirements:

A Ubiquitous requirement is continually active and takes the form The system name shall system response

• A State-driven requirement is active while some precondition remains true and takes the form WHILE precondition the system name shall system response
• An Event-driven requirement is activated when a triggering event is detected at the system boundary and takes the form WHEN trigger the system name shall system response
• An Option requirement is used for systems that include a particular feature and take the form WHERE feature is included the system name shall system response
• An Unwanted Behavior requirement defines the required system response to an unwanted external event and takes the form IF trigger THEN the system name shall system response
• The basic EARS (Easy To Approach Requirement Syntax) patterns can be combined to build Complex requirements

Requirement Specifications

• Structured collection of the essential requirements (characteristics, functions, qualities, constraints, and attributes) of the system and its external interfaces
• Basis for contractual agreements between contractors or suppliers and customers

Standards

A standard is a “Set of mandatory requirements established by consensus and maintained by a recognized body to prescribe a disciplined uniform approach or specify a product, that is, mandatory conventions and practices”.

Levels of Abstraction

Business Requirement Specification

The Business Requirements Specification (BRS) describes the organization’s motivation for why the system is being developed or changed, defines processes and policies/rules under which the system is used and documents the top-level requirements from the stakeholder perspective.

The BRS describes how the organization is pursuing new business or changing the current business in order to fit a new business environment, and how to utilize the system as a means to contribute to the business.

StakeHolder Requirement Specification

The Stakeholder Requirements Specification (StRS) describes the organization’s motivation for why the system is being developed or changed, defines processes and policies/rules under which the system is used and documents the top-level requirements from the stakeholders’ perspective including expressing needs of users/operators/maintainers as derived from the context of use in a specific, precise and unambiguous manner.

In the context described in the BRS, the StRS describes how the organization will utilize the system as a means to contribute to the business.

System Requirement Specification

The System Requirements Specification (SyRS) identifies the technical requirements for the selected system-of-interest and usability for the envisaged human-system interaction.

It defines the high-level system requirements from the domain perspective, along with background information about the overall objectives for the system, its target environment and a statement of the constraints, assumptions and non-functional requirements.

Software Requirement Specification

The Software Requirements Specification (SRS) is a specification for a particular software product, program, or set of programs that performs certain functions in a specific environment.

The SRS may be written by one or more representatives of the supplier, one or more representatives of the acquirer, or by both.

Note:The structure of section 3 may vary substantially

Writing Good Requirement Specifications

• Consistent
  • Does not contradict itself (satisfiable)
  • Avoid synonyms for terms
  • Note: inconsistency can be hard to detect, especially in concurrency/timing aspects and condition logic
  • Formal modeling can help
• Beneficial
  • Has benefits that outweigh the costs of development
• Modifiable
  • Will have to be updated
• Complete
  • Specifies all the things the system must do (including contingencies)
  • ...and all the things it must not do!
  • Conceptual Completeness(e.g., responses defined for all classes of input)
  • Structural Completeness(e.g., no TBDs in sections)
• Feasible
  • Can be entirely realized and validated within known constraints (e.g., cost, schedule, technical) with acceptable risk