Glossary
for
Requirements Discovery

Acceptance Criterion (plural is Criteria)

Means of Measurement; a condition under which a Requirement is to be accepted as met when tested or otherwise Verified before Release. Contrast with Quality of Service.

Actor

UML term roughly equivalent to Operational Role. UML does not cover non-Operational Roles. However,
1) Actors need not be human, so a Product, capable of making decisions, with an Interface to our System is in UML terms an Actor;
2) Actor normally only covers Roles that directly interact with a Product, whereas in a System, human Actors often also interact with other human Operators to provide the wanted results, and it may not be known whether such interactions will be automated.

Assumption

Condition (of something outside the Product or System) that is taken to be true, and relied on by the Project, e.g. as part of the Rationale for the Requirements, but cannot be controlled. Contrast with Requirement.

Attribute

Component of a Requirement or Requirement Element, describing e.g. its Priority, status, Rationale. A field on a data entry form or in a database often corresponds to a requirement attribute.

Baseline

Published version of a Project document or set of documents, whether for Stakeholders to comment on or for developers to work from. As such, a baseline is always treated as read-only; agreed changes are incorporated into a subsequent (not yet baselined) version.

Beneficiary

Stakeholder Role involving direct or indirect benefit of any kind from the Product or System. For example a financial beneficiary expects to gain money from the system’s operations. Subclasses include Financial, Functional, Political, Social.

Business Event

An Event in the world that a Project decides is in Scope.

Business Objective

A (brief, high-level) statement of a Project’s overall purpose. May be analysed into detailed and more readily realisable Goals.

Business Requirement

A Requirement that comes from Stakeholders and states a result that is wanted in the world, without making assumptions about how that will be delivered.

Cherry Stones

Method of Triage (named after an old lover’s game) with values like {this phase, next phase, sometime, never}.

Constraint

A Requirement that places a specific limitation on

1)      how a Product may be constructed, e.g. on allowable power consumption (see Chapter 6, Qualities and Constraints);

2)      how a software Product may behave, e.g. that data in a field may only take certain values, perhaps governed by data in another field (see Chapter 8, Definitions).

Criterion (plural is Criteria)

A Measurable Goal against which design options can be compared in Trade-off analysis.

CRUD

Create – Read – Update – Delete: typical Scenarios for handling data (often called Housekeeping). Useful as a completeness check during Validation.  

Definition

A statement of the meaning of a Dictionary term (normally an item of data or a Role) by reference to other dictionary terms. Contrast with Designation.

Dependability

A major subclass of Quality Requirements, concerned with how far people may rely on a Product (generally one that operates in real time) for continued correct operation.

Subclasses include Availability, Reliability, Safety, Security, Survivability.

Design

1)      The process of stating how a Product is to be constructed, as opposed to Requirements (which state what and why).

2)      The documented output of that process; for hardware/software systems, this is also called an Architecture.  

The Design of a containing system imposes Interface Requirements on a contained sub-system.

Design Element

A part of a Design. See also Feature. Contrast with Requirements Element.

Designation

A description of the meaning of a Glossary term in the Project Dictionary by reference to things in the outside world.

Contrast with Definition.

Development Project

= Project.

Dictionary

= Project Dictionary.

DILO

“A Day In the Life Of”, a standard Scenario Pattern. See also CRUD.

Domain

A realm of business discourse, e.g. air traffic control, railway, broadcasting, banking, telecommunications, retail.

Event

Something that happens of significance to the Product, at one of its Interfaces. Subtypes are Business Event, (internal) “system” event.

Exception

1)      (= Exception Event) an Event that interferes with a Scenario (i.e. progress towards a Functional Goal)

2)      (= Exception Scenario) a Scenario describing how to handle an Exception Event; see Use Case.

Feature

A Functional Design Element visible at business level, i.e. from the outside of a Product. In an ongoing Programme, features are grouped into Releases.

Financial (Stakeholder)

Human Role for Stakeholders deriving money from the success of a Product or System, e.g. shareholders, company directors.

Function, -al

(of a Requirement) calling for a specific capability, i.e. a defined piece of behaviour in response to a specific stimulus, from the Product or System.

(of a Beneficiary) making use of such capabilities.

Compare Normal Operator, User.

Global

(of an NFR) applying to the whole System or Product. Opposite of Local.

Glossary

The informal part of a Project Dictionary, Designating terms used in the world outside the Product.

Goal

1)      (Functional or Non-Functional) statement (a Requirement Element) of a Stakeholder’s desired target for a project. May not be completely realisable or Verifiable. Non-Functional Goals can often be decomposed into Functional Goals. Compare Obstacle.

2)      Requirement that has not yet received an Output Priority; even if strongly desired by Stakeholders, its inclusion in a (phase of a) project is uncertain.

“Housekeeping”

Colloquial engineering term for managing data. See CRUD.

“-ilities”

Colloquial engineering term for Qualities e.g. Reliability.

Information Model

Coarse-grained model of the information structure of a Product development project, suitable for designing a requirements database. The building blocks of the model are the types of Requirement Element.

Input Priority

Priority of a requirement in the opinion of Stakeholders, i.e. how much they want it.

Compare Output Priority.

Interface

(Requirement for) a System or Product’s ability to interchange data or anything else with any other System, or to have a connector of a specific design so as to enable such interchange. Interface Requirements are thus properly defined in complete design detail (down to bits and bytes). Interfaces are often standardised and can thus be specified simply by calling out a specific section or clause of a Standard.

Issue

A matter arising from the Requirements that needs to be understood and resolved before the requirements can be Released.

IPT

Integrated Project Team, a group of people including representative Stakeholders who are not themselves developers, assembled to enable effective development of a Product.

Justification

Rationale (for a Requirement) written as a brief text Attribute.

Key (Requirement)

Approach to setting Priorities in which only a small number of Requirements (say, seven) may be designated as ‘Key’, i.e. absolutely necessary.

Local (NFR)

(of an NFR) applying only within a limited scope, e.g. to a single Function or Use Case. Opposite of Global.

Measurement

1) For a Product which will be verified, then released: Acceptance Criterion

2) For a Service which will be delivered continuously: Quality of Service.

Mission

A short statement of the purpose and Scope of a Product development project.

Misuse Case

Hostile Functional Goal representing an intentional Threat (desired by a Negative Stakeholder).  

Multi-Functional Device (MFD)

Fictional hand-held product-under-development for outdoor leisure purposes used in examples and exercises in this book.

Negative Stakeholder

Stakeholder whose Goals appear as Obstacles to the Project.

Non-Functional Requirement (NFR)

Any Requirement that is not a Function. Includes Qualities and Constraints.

Normal Operator

Human Role that interacts with the Product to deliver results (to Functional Beneficiaries). Compare User.

Obstacle

Something (intentional or not) that obstructs progress towards a Goal. Subtypes include Exception Events and Threats.

Operator, Operational (Stakeholder)

Human Role for Stakeholders actively involved in making the System work, often but not exclusively by direct use of the Product.

Subclasses include Normal Operator, Maintenance Operator.

Operational Scenario

Type of Scenario, usually told as a simple story or sequence of Steps, describing how human Operators (possibly playing many Roles) interact with each other and with Products in a System to achieve a Goal.

Optioneering

= Trade-Off Analysis.

Output Priority

Priority of a Requirement with respect to the chosen design after Optioneering; can be expressed in terms of time, i.e. which Release the requirement will be in. Compare Input Priority.

Political (Stakeholder)

Human Role for Stakeholders deriving any kind of power or prestige from a System or Product.

Priority

The relative importance to Stakeholders (Input Priority) or implementability (Output Priority) of a Requirement or Feature.

Prioritisation

Process of assigning Priorities to Requirements or Features, with the purpose of Triage.

Product (Technical System)

The thing under development, whether software, hardware (computational or otherwise), or a combination; and whether for sale as a commercial item or part of one, or developed in-house. Forms part of a System (excluding the System’s human components, etc). Compare Service.

Product Line

Set of Products (from a single manufacturer) sharing a core of Reused Requirements, and possibly also sharing some standardised hardware or software components.

Product Manager

Human Role in a product development organisation, responsible for managing a Product or Product Line through its various Releases, on behalf of the organisation, and as Surrogate for (mass market) Users.

Product Specification

(a set of) Requirements specifying a Product after Optioneering in sufficient detail for it to be developed. A product specification may refer to any design elements that have been agreed in the Optioneering process. Contrast with Stakeholder Requirements.

Project

Time-limited undertaking with a single purpose: to create the new thing – the Product or Service – named in its Mission.

Project Dictionary

Set of interlocking definitions of terms used within the Project. At least 3 kinds of term may be included: Glossary Designations, Role definitions, and (hierarchical) Data definitions. Acronyms may be included, but should be defined as well as expanded into full names of terms. Data items may be further subtyped into Messages etc.

Programme

Set of related Projects, often sharing Requirements and team members. When a Programme consists of a sequence of developments of the same Product, resulting in successive Releases, the project-like developments are described as Programme Phases.

Programmatic

(Issue, Requirement) concerning team management, organisation, cost, timescale, etc.

Qualities

Requirements stating the manner (safely, etc) in which a product to operate, as opposed to its Functions. Popularly called the “-ilities” for the names of many subclasses. Subclasses include Dependability, Maintainability, Verifiability, Usability, Safety, Security.

Quality of Service (QoS)

Measurement, made continuously or at regular intervals, of a Service to determine its acceptability for contractual and financial purposes. Contrast with Acceptance Criteria.

Questions, Options, Criteria (QOC)

An approach to Trade-offs using a simple diagram of the Traces between a question, a set of (design) options, and a set of Criteria (based on Requirements).

Rationale

Definition of the reason or purpose of Requirements, often by Traces to underlying Goals or Assumptions. See also Justification.

Rebuttal

Argument against a conclusion, forming part of a Rationale. Opposite of Warrant.

Regulations

Documents with legal force, created by legislation, listing Requirements on all Systems, Products, services and businesses of stated types. Regulations are applicable whether or not they are mentioned in a project’s requirements. Compare Standards.

Regulator

Stakeholder Role responsible for controlling some aspect of the System, often with legal authority.

Release

A (numbered) version of a Product issued to customers, often associated with a Programme of development of successively more Features.

Requirement

1: Narrow Sense) Verifiable condition of a (class of) Product or System, initially false, that must be made to become true by the development project. Traditionally written in a style such as “The system shall do xyz”, for inclusion in a commercial contract.

Contrast with Assumption, Goal.

Subclasses include Function, Quality, Constraint, Interface.
2: Broad Sense) Any Requirement Element; or as “The Requirements”, equivalent to “A Specification”.

Requirement Element

A work product of the process of discovering Requirements.

Subclasses include Stakeholder analysis, Goals, Scenarios, Rationale, Assumptions, Definitions, Priorities, Measurements, Qualities, Constraints. See also Information Model.

Requirements Definition

= Requirements Discovery.

Requirements Discovery (RD)

The process of finding out the Requirements for a Project, by working together with the Stakeholders. Contrast with Requirements Management.

Requirements Management (RM)

The process of tracking Requirement status, Priority, progress, and change throughout the development life-cycle. Contrast with Requirements Discovery.

Reuse

Adoption of an existing Requirement on a project. See also Standards, Regulations, Product Line.

Risk

Anything that might interfere with a project’s ability to create a successful Product or System.

Role

1: broad sense) Part played by any class of Stakeholders with respect to a Product, e.g. its Operator, Regulator.

2: narrow sense) Part played by any class of Operational Stakeholders, i.e. interacting with other Stakeholders or with Products within a System to deliver results as stated in Requirements. E.g. Normal Operator, Maintenance Operator.

Compare Actor.

Scenario

Time-sequence of Steps to achieve a Functional Goal. Synonyms are Course, Flow, Path, Sequence or informally “Story”. See also Operational Scenario, Use Case.

Scope

The envelope or boundary of a System or Product, defined ultimately by the complete set of Requirements, but initially by an informal statement of Objectives and then by a context diagram or its equivalent.

Service

The provision of some desired behaviour to a Functional Beneficiary by a System (possibly containing one or more Products, possibly containing humans), usually in return for payment.

See also Quality of Service.

Soft Systems Methodology (SSM)

Approach pioneered by Peter Checkland for understanding the ill-defined behaviour of social and socio-technical Systems.

Specification

Description of a Product or a part of one, defining what is to be built. Necessarily assumes some knowledge of the chosen design. Contrast with Stakeholder Requirements.

Standards

Documents listing Requirements intended to be Reused on all Systems, Products, services or businesses of stated types, with a degree of force ranging from advisory (e.g. industry guidelines, best practice, yellow books) to mandatory (national and international standards). Standards often become applicable only when they are explicitly called up in a project’s Requirements. Compare Regulations.

Stakeholder

Human or other legal entity (Company, etc) playing a System Role and thereby having a valid interest in the development of the System or Product. Subclasses include Beneficiaries, Operator, Regulator, Negative Stakeholder.

Stakeholder Requirements

Set of Requirements stating desired results in the world, before Optioneering, i.e. without assuming knowledge of any future product’s design. Contrast with Product Specification.

Step

Single Functional activity undertaken either by an Operator or by a Product, and, in a time-sequence with other Steps, forming a Scenario.

Surrogate (Role)

Stakeholder Role that exists to represent or serve the interests of other groups of stakeholders. E.g. Marketing represents product customers.

System (Socio-Technical)

The socio-technical network of Operational Roles, Procedures, Product(s) and Interfaces that together can deliver the wanted results to Functional Beneficiaries. Contrast with Product.

System Requirements

[In common usage] = Product Specification (note that this usage conflicts with the definition of System as socio-technical). [Contrasted in common usage with User Requirements].

Test Case

Information structure combining Functional Goals and Scenarios, used to demonstrate by test that a Scenario or Requirement has been met by a Product or System.

Threat

Goal desired by a hostile Stakeholder, and which endangers a Goal of the project. Compare Obstacle.

Trade-Off (Analysis)

Process of finding the design option(s) which best meet(s) the Requirements. In turn, the chosen design determines which of the requirements and their Measurements can be met. Output Priorities generally depend on the results of trade-off analysis.

Trace

A navigable reference between two project information items, e.g. a database link, hyperlink, or paragraph reference. See Traceability.

Traceability

The ability to navigate between related information elements, possibly of different kinds (Requirements, Goals and other Requirement Elements, design elements, tests, etc) for Validation and other purposes including Verification and product Release planning. Traces are a major means of providing Rationale.

Triage

Process of sorting Requirements into groups, such as {obviously needed, obviously not needed, and to be prioritised in more detail}. Makes use of Prioritisation, Trade-Off.

Unified Modeling Language (UML)

The de facto industry standard language for modelling data and software behaviour. UML was devised in the context of software systems, but has steadily spread into other areas. Specialised versions of it have been created to encourage its use in other areas: e.g. SysML for systems engineering. However UML at present does not cover many Requirement Elements. See also Constraint.

Use Case

Information structure combining Functional Goals, Roles, (Functional Requirements represented as) Scenarios, Exceptions and associated Requirements including pre- and post-conditions and Local NFRs.

User

Hybrid Role combining Functional Beneficiary, Normal Operator and possibly mass-market consumer as well.

User Requirements

[In common usage; obsolete term for] Business Requirements. [Contrasted in common usage with System Requirements].

Validate, Validation

Checking that a Requirement correctly reflects the intentions of the Stakeholders, and is realistic given the resources of the development project and the laws of nature. See also Verification. Note that the terms are sometimes interchanged, but the activities remain distinct.

Verify, Verification

Checking that a Product or System meets the Requirements placed upon it, whether by test, analysis, or other means. See also Validation. Note that the terms are sometimes interchanged, but the activities remain distinct.

Verifiable

(quality of a Requirement) Capable of Verification. Compare Goal.

Warrant

Argument in favour of a conclusion, forming part of a Rationale. Opposite of Rebuttal.