This document follows the requirements book structure presented in the Handbook of requirements and business analysis.

CHANGELOG

Version Date Comment

1.0

2021-02-01

Initial draft by J.-M. Bruel

1.23

2023-01-28

Updated by J.-M. Bruel after publication of the Handbook

1.23.1

2023-08-17

Correct S.4 title, by J.-M. Bruel

1.23.2

2023-08-25

Integrating the minimum principle, by J.-M. Bruel

1.23.3

2023-08-27

Adding note for each chapters and reordering to be consistent with the Handbook, by J.-M. Bruel

1.23.4

2023-12-22

Adding numbering options, by J.-M. Bruel

Goals

Goals are "needs of the target organization, which the system will address". While the development team is the principal user of the other books, the Goals book addresses a wider audience: essentially, all stakeholders (see Handbook).

It must contain enough information to provide — if read just by itself — a general sketch of the entire project. To this effect, chapter G.3 presents a short overview of the system and G.1 will typically include some key properties of the environment. As it addresses a wide readership, it should be clear and minimize the use of specialized technical terms. Together, G.1, G.2 and G.3 describe the rationale for the project. It is important to state these justifications explicitly. Typically, they are well understood at the start of the project, but management and priorities can change (see Handbook).

G.1 Context and overall objectives

High-level view of the project: organizational context and reason for building a system (see Handbook).
This chapter should not be empty (following the Minimum Requirements Outcome Principle, p.27 of the Handbook).

1 Example of numbered requirement (see another example).

G.1.2 Another example of numbered requirement, more explicit in its numbering (see another example).

G.1.3 A third example of numbered requirement, with a less intrusive numbering style (the one adopted in the Companion book).

G.2 Current situation

Current state of processes to be addressed by the project and the resulting system (see Handbook).

Example of To Be Done action:

TBD
Author

J.-M. Bruel

Date

2023-08-24

Deadline

2023-12-24

Importance

serious

Needs

  • stakeholders to ask

  • documentation to consider

  • management decision (by J.-M. Bruel)

G.3 Expected benefits

New processes, or improvements to existing processes, made possible by the project’s results (see Handbook).
This chapter should not be empty (following the Minimum Requirements Outcome Principle, p.27 of the Handbook).

G.4 Functionality overview

Overview of the functions (behavior) of the system. Principal properties only (details are in the System book) (see Handbook).

Nothing available at this point.

G.5 High-level usage scenarios

Fundamental usage paths through the system (see Handbook).

Nothing available at this point.

G.6 Limitations and exclusions

Aspects that the system need not address (see Handbook).

Nothing available at this point.

G.7 Stakeholders and requirements sources

Groups of people who can affect the project or be affected by it, and other places to consider for information about the project and system (see Handbook).
This chapter should not be empty (following the Minimum Requirements Outcome Principle, p.27 of the Handbook).

Environment

The Environment book describes the application domain and external context, physical or virtual (or a mix), in which the system will operate (see Handbook).

E.1 Glossary

Clear and precise definitions of all the vocabulary specific to the application domain, including technical terms, words from ordinary language used in a special meaning, and acronyms (see Handbook).
This chapter should not be empty (following the Glossary Principle_, p.27 of the Handbook).

Example of terms definition.

E.1.1 Terms

Book

Copy of a book with a copy number and an availability status.

Catalog

List of library books and their instance availability.

E.2 Components

List of elements of the environment that may affect or be affected by the system and project. Includes other systems to which the system must be interfaced (see Handbook).

Nothing available at this point.

E.3 Constraints

Obligations and limits imposed on the project and system by the environment (see Handbook).
This chapter should not be empty (following the Minimum Requirements Outcome Principle, p.27 of the Handbook).

E.4 Assumptions

Properties of the environment that may be assumed, with the goal of facilitating the project and simplifying the system (see Handbook).

Nothing available at this point.

E.5 Effects

Elements and properties of the environment that the system will affect (see Handbook).

Nothing available at this point.

E.6 Invariants

Properties of the environment that the system’s operation must preserve (see Handbook).

Nothing available at this point.

System

The System book refines the Goal one by focusing on more detailed requirements about the system under development, mainly its constituents, behaviors and properties.

S.1 Components

Overall structure expressed by the list of major software and, if applicable, hardware parts (see Handbook).
This chapter should not be empty (following the Minimum Requirements Outcome Principle, p.27 of the Handbook).

S.2 Functionality

One section, S.2.n, for each of the components identified in S.1, describing the corresponding behaviors (functional and non-functional properties; see Handbook).
This chapter should not be empty (following the Minimum Requirements Outcome Principle, p.27 of the Handbook).

S.3 Interfaces

How the system makes the functionality of S.2 available to the rest of the world, particularly user interfaces and program interfaces (APIs) (see Handbook).

Nothing available at this point.

S.4 Detailed usage scenarios

Examples of interaction between the environment (or human users) and the system: use cases, user stories (see Handbook).

Nothing available at this point.

S.5 Prioritization

Classification of the behaviors, interfaces and scenarios (S.2, S.3 and S.4) by their degree of criticality (see Handbook).

Nothing available at this point.

S.6 Verification and acceptance criteria

Specification of the conditions under which an implementation will be deemed satisfactory (see Handbook).

Nothing available at this point.

Project

The Project book describes all the constraints and expectations not about the system itself, but about how to develop and produce it.

P.1 Roles and personnel

Main responsibilities in the project; required project staff and their needed qualifications (see Handbook).

Nothing available at this point.

P.2 Imposed technical choices

Any a priori choices binding the project to specific tools, hardware, languages or other technical parameters (see Handbook).

Nothing available at this point.

P.3 Schedule and milestones

List of tasks to be carried out and their scheduling (see Handbook).
This chapter should not be empty (following the Minimum Requirements Outcome Principle, p.27 of the Handbook).

P.4 Tasks and deliverables

Details of individual tasks listed under P.3 and their expected outcomes (see Handbook).
This chapter should not be empty (following the Minimum Requirements Outcome Principle, p.27 of the Handbook).

P.5 Required technology elements

External systems, hardware and software, expected to be necessary for building the system (see Handbook).

Nothing available at this point.

P.6 Risk and mitigation analysis

Potential obstacles to meeting the schedule of P.4, and measures for adapting the plan if they do arise (see Handbook).

Nothing available at this point.

P.7 Requirements process and report

Initially, description of what the requirements process will be; later, report on its steps (see Handbook).

Nothing available at this point.