Overview

It may not always be obvious why requirements are necessary. For projects, however, an agreed set of requirements is essential from a number of different perspectives. For business management, the set of requirements provides a mechanism whereby the organisation’s resources can be allocated knowingly to the project that has been established to bring the system into being. For project managers, the set of requirements is an essential part of the definition of the scope of the project—it is from this scope that estimates will be developed for schedule and budget. For the systems engineer, the formal set of system requirements represents the transition from the business world into the systems engineering and engineering domains.

This text focuses on the relevant processes for good requirements practice through which we develop a set of requirements that is complete, consistent, comprehensible, feasible, and able to be validated. It is designed to support undergraduate and postgraduate courses in requirements engineering, as well as provide a manual for practitioners in business analysis, project management, systems engineering, and requirements engineering. While addressing upper-level frameworks and lower-level requirements-writing skills, it focuses principally on how to ‘do’ requirements engineering—that is, how to conduct system-level logical design such that the resulting textual artefacts not only have the right shape, but also have the right content.

This requirements practice book is used as a text for a number of professional education and university courses, as well as for a number of in-house courses. In particular, it is complimentary to attendees on the edVirtus Requirements Writing training course delivered by the author Dr Mike Ryan. The text also supports the Coursera Massive Open Online Course (MOOC) Requirements Writing.

Preface

It may not always be obvious why requirements are necessary, particularly since much of our decision making in our personal and business lives is not conducted using formal methodologies. For projects, however, an agreed set of requirements is essential from a number of different perspectives.

From the point of view of business management, the set of requirements provides a mechanism whereby the organisation’s resources can be allocated knowingly to the project that has been established to bring the system into being. Unless the requirement set is well defined, the project has no firm base and will have inadequate resources allocated to it because the required work will not have been properly quantified in scope, cost, or schedule. Worse still, without sufficient oversight of the formulation of a set of requirements, the business may be held to ransom by users who insist on unrealistic requirements that business management have not approved. From the project manager’s perspective, the set of requirements is an essential part of the definition of the scope of the project—it is from this scope that suitable estimates will be developed for schedule and budget. Scope management is one of the major functions of a project manager—a well defined scope (set of requirements) is necessary to be able to justify any expenditure of funds or effort within the project, to be able to report adequately on the progress of work, and to eventually be able to determine when the project is complete. Inadequate requirements processes is one of the major reasons why projects fail. Clearly then, if the project manager does not begin with a well defined, universally agreed set of requirements, the project is doomed to fail.

From the systems engineering perspective, the formal set of system requirements represents the transition from the business world into the systems engineering and engineering worlds. Once the set has been established, it is not possible to rectify a poor set of requirements with good design, good engineering, or good production/process control—particularly when that set of requirements is the basis of a fixed-price contract between the acquirer and the contractor. Consequently, a project can rarely recover from poor definition, regardless of how much good work is performed subsequently.

An appropriate requirements-engineering process allows us to guarantee that we begin the project with a set of requirements that is complete, consistent, comprehensible, feasible, and able to be validated. A useful process ensures that all stakeholders have had input and the various points of view have been reconciled. To do that, we must therefore be able to trade off functionality for cost—which implies that we understand the required functionality, priorities, and costs. We also need to be able to use the requirements engineering process to manage changes in requirements for a wide variety of reasons.

The cost of developing requirements is estimated to be approximately 10–15% of the total system cost. Yet it is estimated that it costs some 200 times more to rectify an error in requirements during utilization than it does during early system design. Poor requirements definition cannot be rectified by good design or good engineering, so that it invariably follows that rigorous development of requirements is essential for successful system development. Requirements engineering provides this rigour through the application of a formal methodology. When requirements engineering processes are ad hoc, the end result is, at best, an unsatisfactory product or, at worst, a cancelled project. Perhaps the most persuasive evidence is provided by data from NASA (see Chapter 1) that shows that projects that expended the industry average of 2−3% of total project cost/effort on the requirements process throughout the life cycle experienced an 80−200% cost overrun, while projects that invested 8−14% of total project cost/effort in the requirements process had 0−50% cost overruns.

Despite the considerable effort expended in systems engineering and requirements engineering standards, there are surprisingly few methodologies available for the actual conduct of requirements engineering. At one level, this is not so surprising because standards such as ISO/IEC-15288 (Systems and Software Engineering—System Life Cycle Processes), ANSI/EIA-632, IEEE-STD-1220 (IEEE Standard for Application and Management of the Systems Engineering Process), and ISO/IEC 29148 (Systems and Software Engineering—Life Cycle Processes—Requirements Engineering) have a true systems engineering background—they are therefore focused on what must be done and do not prescribe how it should be done. Consequently, all of these standards are extremely useful in the guidance that they provide to an organization, but a requirements engineer cannot ‘do’ them because they (deliberately) provide little or no guidance on how to perform the tasks associated with good requirements practice.

Similarly, much has been written about requirements engineering, by both academics and practitioners. There are thousands of conference and journal papers addressing the topic and at least a hundred books directly addressing requirements engineering as well as several hundred more books (on business analysis, project management, systems engineering and software engineering) that make significant mention of it. Yet, in all of these descriptions, the focus is on what to do, rather than how to do it. In particular, most of what is written focuses either on the very high-level consideration of requirements frameworks and elicitation techniques, or on the very low-level activities such as the syntax of good requirement statements. It is important to understand the upper-level issues such as the appropriate life-cycle models and requirements engineering processes, and it is essential to understand the templates for documents and the language used (vocabulary, syntax, and structure) of requirements, but it is also important to address what are arguably the most important activities—those that are undertaken to articulate the purpose of the system; gather the relevant information; analyze, negotiate, and synthesize the needs and requirements; and then present them in such a manner that describes the system’s mission in order to meet the business needs.

This text focuses on those latter issues for good requirements practice. While addressing upper-level frameworks and lower-level requirements-writing skills, it focuses principally on how to ‘do’ requirements engineering—that is, how to conduct system-level logical design such that the resulting artefacts not only have the right shape, but also have the right content.

We should make clear at the outset which types of systems are relevant to the practices presented here. In particular, we are focussed on one type of system and on one way to represent requirements. There are a large number of types of systems based on the various combinations of characteristics—open or closed, natural or human-made or human-modified, and precedented or unprecedented. It is important to recognise that this text and the majority of the standards discussed (such as ISO/IEC 15288) refer to open, physical systems that are human-made/modified from largely precedented elements. It should also be noted at the outset that we are focused here on text-based requirements.

The text assumes an organization that is undertaking requirements engineering in systems acquisition within a framework that conforms to ISO/IEC 15288, and the chief engineer of the organization is required to develop a systems engineering process that conforms to a standard such as IEEE-STD-1220 and, as part of the development of a suitable systems engineering process, is required to develop a requirements-engineering methodology that conforms to ISO/IEC 29148 (or similar). The methodology proposed here provides a framework for requirements-engineering activities associated with the development of the logical (functional) architecture (the conduct of logical design in the Conceptual Design phase of the system life cycle), and is called for convenience the Conceptual Design Methodology (CDM).

The book is written as a text for undergraduate and postgraduate courses in requirements engineering, as well as a manual for practitioners in business analysis, project management, systems engineering, and requirements engineering. For students, review questions are provided to assist in the confirmation of understanding at the end of each chapter.

We begin in Chapter 1 by setting the context for requirements engineering, with a description of systems, system life cycles, project management, systems engineering, and requirements engineering to provide the context for the detail in the remaining chapters. Chapter 2 provides an overview of a number of the important aspects of the extant requirements-engineering body of knowledge. Chapter 3 outlines the key aspects that underpin the design of CDM and outlines the upper-level processes, which are then detailed further in the reminder of the chapter. The major processes, activities, steps, and tasks are then detailed and illustrated in the remaining chapters—Chapter 4 (Identify Major Stakeholders and Constraints), Chapter 5 (Define Business Needs), Chapter 6 (Scope System and Define Business Requirements), and Chapter 7 (Define Stakeholder Needs and Requirements). Chapters 8 and 9 focus on defining system requirements and requirements writing respectively. Throughout the chapters, a single unifying example is used to illustrate the application of CDM.

Michael Ryan
Canberra

Table of contents

1	INTRODUCTION	1
1.1	Definition of a System	2
1.1.1	Types of Systems	3
1.1.2	Hierarchical Descriptions	4
1.1.3	System-of-Systems (SoS)	6
1.1.4	Logical and Physical Descriptions of a System	7
1.1.5	Problem Domain and Solution Domain	8
1.1.6	Capability System	9
1.2	System Life Cycle	10
1.2.1	Parties Involved	11
1.3	Acquisition and Utilization Phases	12
1.3.1	Acquisition Phase	13
1.3.2	Utilization Phase	16
1.3.3	Systems Engineering and Development Approaches	16
1.4	Test and Evaluation (T&E)	17
1.5	Introduction to Project Management	17
1.6	The Role of Systems Engineering	20
1.6.1	Top-down Approach	20
1.6.2	Focus on Life Cycle	22
1.6.3	System Optimization and Balance	22
1.6.4	Integration of Disciplines and Specialties	22
1.6.5	Management	23
1.6.6	Focus on Requirements Engineering	23
1.7	Benefits of Systems and Requirements Engineering	24
1.8	The Purpose of this Book	26
1.9	Review Questions	26
2		33
2.1	Introduction	33
2.2	Needs and Requirements	33
2.2.1	What is a Requirement?	37
2.2.2	Requirements Characteristics and Attributes	38
2.2.3	What Not How	43
2.2.4	Emergent Properties	44
2.3	What is Requirements Engineering?	44
2.3.1	Why We Need Requirements	45
2.3.2	Why We Need Requirements Engineering	46
2.4	Requirements Elicitation and Elaboration	46
2.4.1	Elicitation Dimensions	49
2.4.2	Difficulties in Eliciting and Elaborating Requirements	51
2.4.3	Techniques for Eliciting Requirements	54
2.5	Requirements Validation	60
2.5.1	Validating Individual Requirements	61
2.5.2	Validating the Requirement Set	62
2.6	Requirements Management	66
2.6.1	Requirements Change Management	66
2.6.2	Change Management—Traceability	67
2.6.3	Requirements Management Tools	68
2.7	Requirements-engineering Tools	70
2.7.1	Requirements Breakdown Structure (RBS)	71
2.7.2	Functional Flow Block Diagrams (FFBDs)	72
2.8	Review Questions	74
3		83
3.1	Introduction	83
3.2	Guidance for the Conduct of Conceptual Design	83
3.3	A Conceptual Design Methodology (CDM)	88
3.3.1	Key Aspects of CDM	88
3.3.2	Summary of CDM Processes	91
3.4	C1—Define Business Needs and Requirements (BNR)	92
3.4.1	C1.1—Identify Major Stakeholders and Constraints	92
3.4.2	C1.2—Define Business Needs	95
3.4.3	C1.3—Scope System	96
3.4.4	C1.4—Define Business Requirements	97
3.4.5	C1.5—Finalise Business Needs and Requirements (BNR)	98
3.5	C2—Define Stakeholder Needs and Requirements	99
3.5.1	C2.1—Define Stakeholder Needs	99
3.5.2	C2.2—Define Stakeholders Requirements	100
3.5.3	C2.3—Finalise Stakeholder Needs and Requirements (SNR)	101
3.6	C3—Define System Requirements	101
3.6.1	C3.1—Establish Requirements Framework	102
3.6.2	C3.2—Perform Requirements Analysis and Allocation	103
3.6.3	C3.3—Draft System Requirement Specification (SyRS)	104
3.6.4	C3.4—Define Technical Performance Measures (TPMs)	104
3.6.5	C3.5—Conduct System Requirements Reviews (SRR)	105
3.6.6	Project Management, Systems Engineering and Logistics Considerations	105
3.7	C4—Conduct System-Level Synthesis	106
3.8	C5—Conduct System Design Review (SDR)	108
3.9	Relationship of CDM to Major Systems-engineering Standards	110
3.1	ACME Medical Centre Example	110
3.11	Summary	111
3.12	Review Questions	111
4		113
4.1	Introduction	113
4.2	C1.1.1—Identify Major Stakeholders	113
4.2.1	Who is a Stakeholder?	113
4.2.2	A Better Definition of Stakeholders	115
4.2.3	Identifying Stakeholders	115
4.2.4	Identify Stakeholders—Examples	121
4.3	C1.1.2—Identify Business and Project Constraints	127
4.4	C1.1.3—Identify External Constraints	128
4.5	C1.1.4—Identify Design Constraints	129
4.6	Some Caution When Considering Constraints	129
4.7	Review Questions	130
5		133
5.1	Introduction	133
5.2	The Need for a Mission Statement	133
5.2.1	Desirable Characteristics of a Mission Statement	136
5.2.2	Guidelines for the Format for a Mission Statement	137
5.3	C1.2.1—Develop Mission, Goals, and Objectives	139
5.3.1	C1.2.1.1—Develop Mission Statement	140
5.3.2	C1.2.1.1.1—Identify Candidate Need elements	140
5.3.3	C1.2.1.2—Develop Goal Statements	145
5.3.4	C1.2.1.3—Develop Objective Statements	148
5.3.5	Requirements vs Work Breakdown (RBS vs WBS)	151
5.4	C1.2.2—Define Preliminary Operational Scenarios	153
5.5	C1.2.3—Define Preliminary Validation Criteria	155
5.5.1	ACME Medical Centre—Development of Measures	156
5.5.2	Measurement	157
5.5.3	An Alternative Approach to the Development of Measures	157
5.6	C1.2.4—Define Preliminary Life-cycle Concepts	160
5.6.1	Preliminary Operational Concept (OpsCon)	161
5.7	Summary	166
5.8	Review Questions	167
6		169
6.1	Introduction	169
6.2	C1.3—Scope System	169
6.2.1	C1.3.1—Develop Context Diagram	169
6.2.2	C1.3.2—Define System Boundary	174
6.2.3	C1.3.3—Define External Interfaces	174
6.2.4	C1.3.4—Endorse Draft Business Needs	181
6.3	C1.4—Define Business Requirements	182
6.4	C1.5—Finalise Business Needs and Requirements	185
6.5	Review Questions	185
7		187
7.1	Introduction	187
7.2	C2.1—Define Stakeholder Needs	187
7.2.1	C2.1.1—Identify Stakeholders	188
7.2.2	C2.1.2—Refine Mission, Goals, and Objectives	188
7.2.3	C2.1.3—Develop Operational Scenarios	188
7.2.4	C2.1.4—Develop Life-cycle Concepts	188
7.2.5	C2.1.5—Endorse Stakeholder Needs	188
7.3	C2.2—Define Stakeholder Requirements	188
7.3.1	C2.2.1 and C2.2.2—Trade Studies	188
7.4	C2.3—Finalise Stakeholder Needs and Requirements (SNR)	195
7.5	Review Questions	197
8		199
8.1	Introduction	199
8.2	C3.1—Establishing the Requirements Framework	200
8.3	C3.2—Perform Requirements Analysis and Allocation	200
8.3.1	C3.2.1—Define Functional/Non-Functional Requirements	201
8.3.2	FFBD Example—ACME Medical Centre	201
8.3.3	C3.2.2—Define Performance Requirements	204
8.3.4	C3.2.3—Define Verification Requirements	205
8.3.5	C3.2.4—Assign Rationale	206
8.3.6	Requirements Allocation	207
8.4	C3.3—Draft System Requirements Specification	207
8.4.1	SyRS Structure	208
8.4.2	SyRS Format	209
8.5	C3.4—Define Technical Performance Measures (TPM)	209
8.6	C3.5—Conduct System Requirements Review (SRR)	210
8.7	Review Questions	211
9		213
9.1	Introduction	213
9.2	Some Guidelines for Writing Good Requirements	213
9.2.1	Use a Style Guide and Template for Requirement Statement	214
9.2.2	Use a Glossary to Define Terms	215
9.2.3	Use Correct English Expression	216
9.2.4	Use a Subject Appropriate to Level	217
9.2.5	Use Explicit Lists	217
9.2.6	Use the Active Rather Than the Passive Voice	218
9.2.7	Use the Definite Article	218
9.2.8	Use the Same Term to Mean the Same Thing	219
9.2.9	Avoid Vague Words, Terms, and Expressions	220
9.2.10	Avoid Superfluous Words	221
9.2.11	Avoid the Use of Conjunctions (Using a Convention for Logical Conditions)	222
9.2.12	Avoid Unbounded Statements and Escape Clauses	224
9.2.13	Avoid Unnecessary Precision	225
9.2.14	Be Explicit Where Necessary	225
9.2.15	Use Units, Ranges and Tolerances	225
9.2.16	Avoid the Use of ‘Not’	226
9.2.17	Avoid Cross-references Including Pronouns	227
9.2.18	Use Diagrams Wherever Appropriate	227
9.2.19	Introduce Logical Groups of Requirements with Informative Statements	228
9.2.20	Invoking Other Documents	228
9.2.21	Ensure that Each Requirement is Verifiable	228
9.3	Incorporating Performance and Verification Requirements into the Requirements Expression	230
9.3.1	Performance Requirements	230
9.3.2	Verification Requirements	230
9.3.3	An Alternative Approach	231
9.4	Review Questions	231
	GLOSSARY	233
	APPENDIX 1 - ACME Medical Centre Example—Background	235
	INDEX	237

Sample Chapter

Download a sample chapter of Requirements Practice (PDF)