Requirements
Engineering
A step by step
approach
LN Mishra, CBAP, CPRE, CSM, PMP, SPOC
Author of “Mastering CBAP”, “Mastering CPRE” and “Stories for IT Trainers”
Requirements Engineering
A step by step approach
| Acknowledgements and Bibliography 1
Acknowledgements and Bibliography
A Guide to Business Analysis Body of Knowledge v2.0. International Institute
of Business Analysis. Toronto: IIBA, 2009. PDF and EBook.
Syllabus for CPRE Foundation Level examination, IREB, Germany
Rupp, Klaus Pohl and Chris. A Study Guide for the Certified Professional for
Requirements Engineering Exam Foundation Level 2nd Edition. Rocky Nook Inc.,
2015. Kindle and Paperback.
Business Analysis, Debra and Paul, British Computer Society
Podeswa, Howard. The Business Analyst's Handbook. Boston: Course Technology,
2009. Paperback.
UML for the IT Business Analyst, Second Edition. Boston: Course Technology,
2010. Paperback.
James Cadle, Debra Paul and Paul Turner. Business Analysis Techniques.
Chippenham: British Informatics Society Limited, 2010. Paperback.
Requirements Engineering
A step by step approach
| Copyright notice 2
Copyright notice
BABOK®, CBAP®, CCBA® are registered trademarks of International
Institute of Business Analysis, Canada.
CPRE® is registered Trademarks of International Requirements
Engineering Board, Germany.
All trademarks of copyrights mentioned herein are the possession
of their respective owners.
We make no claim of ownership by the mention of products that
contain these marks.
Contents of this document should not be disclosed to any
unauthorized person.
This document may not, in whole or in part, be reduced,
reproduced, stored in a retrieval system, translated, or
transmitted in any form or by any means, electronic or mechanical.
Requirements Engineering
A step by step approach
| Copyright notice 3
Table of contents
Acknowledgements and Bibliography........................................... 1
Copyright notice............................................................ 2
1. Introduction .......................................................... 8
1.1 Why this book? ...................................................... 8
1.2 Knowledge areas ..................................................... 8
1.3 Other sources of requirements engineering information .............. 10
2. Requirements engineering concepts .................................... 14
2.1 Defining requirements .............................................. 14
2.2 Types of requirements .............................................. 15
Functional requirements ................................................ 15
Non-Functional (Quality, Supplementary) requirements ................... 16
Constraints ............................................................ 18
2.3 Requirements categorizations ....................................... 19
2.4 Defining requirements engineering .................................. 22
2.5 Need for good requirements engineering ............................. 23
2.6 Major activities of requirements engineers ......................... 26
2.7 Responsibilities of requirements engineers ......................... 27
3. Vocabulary ........................................................... 33
4. Techniques ........................................................... 62
4.1 Acceptance criteria ................................................ 62
4.2 Activity diagrams .................................................. 63
Requirements Engineering
A step by step approach
| Copyright notice 4
4.3 Apprenticing ....................................................... 66
4.4 Audio and video recordings ......................................... 67
4.5 Benchmarking ....................................................... 68
4.6 Bionics/ bisociations .............................................. 69
4.7 Brainstorming ...................................................... 70
4.8 Brainstorming paradox .............................................. 72
4.9 Brain writing ...................................................... 73
4.10 Business rules analysis .......................................... 73
4.11 Change of perspectives - Six thinking hats (De Bono) ............. 76
4.12 Class model ...................................................... 79
4.13 Commenting ....................................................... 82
4.14 Conflict resolution techniques ................................... 82
4.15 Data flow diagrams ............................................... 86
4.16 Decision tables .................................................. 88
4.17 Decision tree .................................................... 90
4.18 Data model ....................................................... 91
4.19 Document analysis ................................................ 93
4.20 Entity-relationship diagrams ..................................... 95
4.21 Estimation ....................................................... 96
4.22 Flow charts ...................................................... 99
4.23 Focus groups .................................................... 101
4.24 Functional decomposition ........................................ 105
4.25 Functional requirements analysis ................................ 106
4.26 Implicit requirements analysis .................................. 108
4.27 Inspection ...................................................... 109
Requirements Engineering
A step by step approach
| Copyright notice 5
4.28 Interface analysis .............................................. 111
4.29 Interviews ...................................................... 113
4.30 Lessons learned process ......................................... 116
4.31 Matrix model .................................................... 117
4.32 Metrics and Key performance indicators (KPIs) ................... 119
4.33 Misuse case ..................................................... 122
4.34 Mind-mapping .................................................... 123
4.35 Goal modeling ................................................... 124
4.36 MosCoW Analysis ................................................. 127
4.37 Non-Functional (Quality, Supplementary) requirements ............ 127
4.38 Observation ..................................................... 130
4.39 Organization model .............................................. 133
4.40 Persona ......................................................... 134
4.41 Perspective-based reading ....................................... 135
4.42 Problem tracking ................................................ 137
4.43 Process modeling ................................................ 140
4.44 Prototyping ..................................................... 143
4.45 Release planning ................................................ 147
4.46 Risk management ................................................. 148
4.47 Requirements attribute chart .................................... 150
4.48 Requirements prioritization techniques .......................... 153
4.49 Requirements reuse .............................................. 155
4.50 Requirements review checklist ................................... 158
4.51 Requirements workshops .......................................... 160
4.52 Reverse walkthrough ............................................. 163
Requirements Engineering
A step by step approach
| Copyright notice 6
4.53 Root cause analysis (RCA) ....................................... 164
4.54 Scope models .................................................... 166
4.55 Sequence diagrams ............................................... 169
4.56 Sprint planning ................................................. 172
4.57 Sprint retrospective ............................................ 172
4.58 Sprint review ................................................... 174
4.59 Stakeholder register ............................................ 174
4.60 State Diagrams .................................................. 176
4.61 Structured walkthrough .......................................... 176
4.62 Surveys and Questionnaires ...................................... 181
4.63 System archaeology .............................................. 185
4.64 Time boxing ..................................................... 186
4.65 Use case diagrams ............................................... 187
4.66 Use case specifications ......................................... 190
4.67 User stories .................................................... 194
4.68 Supplier assessment ............................................. 196
5. Plan requirements engineering ....................................... 199
5.1 Key Concepts ...................................................... 199
5.2 Activities ........................................................ 224
6. Establish RE infrastructure ......................................... 250
6.1 Key concepts ...................................................... 250
3 quality aspects of requirements ..................................... 282
Using validation criteria for the quality aspects ..................... 283
Change control board .................................................. 285
Requirements Engineering
A step by step approach
| Copyright notice 7
Change request (CR) ................................................... 286
Classification of incoming change requests ............................ 287
Basic method for implementing CRs ..................................... 287
6.2 Activities ........................................................ 290
7. Elicit Requirements ................................................. 318
7.1 Key concepts ...................................................... 318
7.2 Activities ........................................................ 334
8. Analyze requirements ................................................ 352
8.1 Key concepts ...................................................... 352
Elements of a conceptual modelling language ........................... 354
8.2 Activities ........................................................ 357
9. Manage requirements ................................................. 377
9.1 Key concepts ...................................................... 377
Types of requirements conflicts ....................................... 380
Documentation of conflict resolution techniques ....................... 382
9.2 Activities ........................................................ 385
10. About Adaptive Processes ............................................ 408
Requirements Engineering
A step by step approach
| Introduction 8
1. Introduction
1.1 Why this book?
Although there are many books on software requirements
engineering, most of them describe the theoretical aspects
of requirements engineering. Practical requirements
engineering is an attempt to learn requirements through an
actual software product development - from concept to go
live.
This is essential for practitioners to understand the
entire requirements engineering process.
This is a very practical book and has been based on my
experience in developing our product “GRCPerfect – An
Enterprise Project Governance, Risk and Compliance
management system” for one of our key clients.
1.2 Knowledge areas
Knowledge areas define what a requirements engineer must be
able to perform. REs are likely to perform tasks from
different knowledge areas concurrently, and iteratively.
Tasks may be performed in any order but the required inputs
Requirements Engineering
A step by step approach
| Introduction 9
MUST be available.
Structure of tasks
Each knowledge area describes set of related tasks
performed by requirements engineers to accomplish specific
purpose of that knowledge area.
Tasks are structured in following format for easy
reference.
Task Name: Short description of the task.
Purpose: Reason to perform the task.
Stakeholders: Stakeholders who participate in the task.
Inputs Elements Outputs
Information and
preconditions
necessary for a
task to begin.
Describes key concepts
needed to perform the
task.
Output of the
task.
Tools and Techniques: Work aids to perform the task.
Tasks may be performed at least once up to any number times
needed during the project life.
Requirements Engineering
A step by step approach
| Introduction 10
3 essential characteristics of tasks are:
1. Tasks produce outputs which create value to the
sponsoring organization.
2. Tasks are atomic. In principle, successor tasks that
make use of outputs of a particular task can be
different person or group.
3. Tasks are necessary part of the purpose of the knowledge
areas.
Tasks may be performed at any scale, from few minutes to
few months. For example, a change request document can be a
single sentence explaining the benefit that a change will
produce for a single individual or several hundred pages
long for a multi-billion dollar investment.
Unlike other guidebooks, Practical requirements engineering
DOES recommend an order in which tasks are performed.
1.3 Other sources of requirements engineering
information
1. Syllabus for CPRE Foundation Level examination, IREB,
Requirements Engineering
A step by step approach
| Introduction 11
Germany
2. A Guide to Business Analysis Body of Knowledge v2.0.
International Institute of Business Analysis. Toronto:
IIBA, 2009. PDF and EBook.
3. A Guide to Business Analysis Body of Knowledge v3.0.
International Institute of Business Analysis. Toronto:
IIBA, 2009. PDF and EBook.
4. Project Management Institute, Project Business Analysis
Guide.
5. Business Analysis, Debra and Paul, British Computer
Society.
6. CMMI for Development, Carnegie Mellon University.
7. ISO 9001:2008 from ISO.
8. System Engineering Body of Knowledge, IEEE.
9. Enterprise architecture (including Zachman Framework for
Enterprise architecture™, and TOGAF™).
10.Governance, and Compliance Frameworks, including
Sarbanes-Oxley, Basel II, and others.
11.IT Service Management (including ITIL).
12.Rupp, Klaus Pohl and Chris. A Study Guide for the
Certified Professional for Requirements Engineering Exam
Foundation Level 2nd Edition. Rocky Nook Inc., 2015.
Kindle and Paperback.
13.Podeswa, Howard. The Business Analyst's Handbook.
Boston: Course Technology, 2009.
Requirements Engineering
A step by step approach
| Introduction 12
14.UML for the IT Business Analyst, Second Edition. Boston:
Course Technology, 2010.
15.James Cadle, Debra Paul and Paul Turner. Business
Analysis Techniques. Chippenham: British Informatics
Society Limited, 2010.
Requirements Engineering
A step by step approach
| Introduction 13
Trucks are in the warehouse and the God damn system has
failed
Requirements Engineering
A step by step approach
| Requirements engineering concepts 14
2. Requirements engineering concepts
2.1 Defining requirements
IEEE defines requirements as:
A condition or capability needed by a stakeholder to
solve a problem or achieve an objective.
A condition or capability to be met or possessed by a
solution or solution component to satisfy a contract,
standard, specification, or other formally imposed
documents.
A requirement may be unstated, implied by or derived
from other requirements, or directly stated and managed.
One of the key objectives of requirements engineering is
to ensure requirements are visible to and understood by
all stakeholders.
Requirements describe, but not limited to, past, present
and future conditions or capabilities in an enterprise,
organizational structures, roles, processes, policies,
rules and information systems. Requirements should be at
the level of depth necessary for clarity and
implementation.
Requirements Engineering
A step by step approach
| Requirements engineering concepts 15
2.2 Types of requirements
Functional requirements
Functional requirements (FRs) describe abilities of a system
that are important to user community. These are
functionalities offered by the system. Sample examples of
functional requirements are “Manage customer”, “Manage
order”, “Manage employees” etc.
Categories of functional requirements are:
User interface perspective: (UI)
In the UI perspective, interactions between users and
application are described.
Data perspective: (Data)
In the data perspective, data aspects are described.
Functional perspective: (Logic)
Functional perspectives describe data flows or logic flows
of the system.
Behavioral perspective: (State)
In the behavioral perspective, statuses of data elements are
described.
Requirements Engineering
A step by step approach
| Requirements engineering concepts 16
Non-Functional (Quality, Supplementary) requirements
The umbrella term “non-functional requirement” is often
used for quality requirements and constraints. Quality
requirements describe qualities of a system that are
important to:
User community, such as usability, learnability,
reliability, etc.
Development community, such as scalability,
maintainability, reusability, etc.
Quality requirements often influence the system
architecture more than functional requirements do. Quality
requirements must be documented explicitly. Quality
requirements should be traceable to business needs and
other requirements. Include appropriate measures for NFRs
to be testable.
Quality requirements are mostly documented using natural
language. For example:
90% of users shall be able to use basic functions of the
system within 6 hours of training. The system shall provide
90% of responses in less than 5 seconds.
Performance
Requirements Engineering
A step by step approach
| Requirements engineering concepts 17
Time taken to perform activities and resource utilization
levels.
Security
Ability to ensure appropriate confidentiality and integrity
of information, to verify when actions were taken and by
whom and to authenticate users.
Reliability
Measure of application being available when needed.
Includes ability of the application to recover from errors,
uptime, or failures in interfaces.
Usability
The system being usable by target audience with specified
duration of training.
Maintainability
Ability to change one component without affecting others
and without causing unexpected failures, ability to re-use
components and testability.
Portability, also known as Transferability
Ease of installing and uninstalling the application,
different environments it can run and ease of migrating it
to a new environment.
Requirements Engineering
A step by step approach
| Requirements engineering concepts 18
A useful mnemonic: CRM POST (Compatibility, Reliability,
Maintainability, Performance efficiency, Operability,
Security and Transferability)
Constraints
Constraints are aspects which the project team cannot
influence or modify. (e.g., “The system shall be
implemented using .net”) or the time frame (“The system
shall be available by fourth quarter of 2015”).
Constraints are not implemented; they are adhered to.
Constraints limit the solution options (which is actually a
good thing else we will have large number of solution
options to deal with). Constraints influence requirements
engineering planning, execution and techniques.
In addition to the above classifications, requirements may
be classified based on requirement attributes, such as the
levels of detail, priorities, or legal obligations.
Requirements Engineering
A step by step approach
| Requirements engineering concepts 19
2.3 Requirements categorizations
2.3.1 According to Kano Model
Image source: Wikipedia
In Kano approach, one classifies and prioritizes
requirements with respect to their acceptance on market.
Following three property classes are classified:
Dis-satisfiers: A requirement specifies a dis-satisfier
that system must possess to be successfully introduced to
market.
Satisfiers: A requirement specifies a satisfier if
customers consciously demand associated property.