Requirements Engineering A step by step approachadaptiveprocesses.com/sample-estore/Practical Requirements... · Requirements Engineering A step by step approach LN Mishra, ... (including

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.



| 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.




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




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




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




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




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



| 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



| 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.



| 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,



| 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.



| 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.



| Introduction 13

Trucks are in the warehouse and the God damn system has

failed



| 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.




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.




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




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.




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.




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.

Requirements Engineering A step by step approachadaptiveprocesses.com/sample-estore/Practical Requirements... · Requirements Engineering A step by step approach LN Mishra, ... (including

Documents