A Guide to the Business Analysis Body of Knowledge

International Institute of Business Analysis

Business Analysis

Body of Knowledge

A Guide to the

Version 1.6

International Institute of Business Analysis

Guide to the Business Analysis Body of Knowledge

Draft Material for Review and Feedback

Release 1.6 Draft

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

Table of Contents

CHAPTER 1: PREFACE AND INTRODUCTION

TABLE OF CONTENTS............................................................................................................................................ I

PREFACE TO RELEASE 1.6.................................................................................................................................... 1

1.1 WHAT IS THE IIBA BOK........................................................................................................................... 5

1.2 PURPOSE OF THE GUIDE TO THE IIBA BOK ........................................................................................... 5

1.3 DEFINING THE BUSINESS ANALYSIS PROFESSION............................................................................... 6

1.4 CORE CONCEPTS OF BUSINESS ANALYSIS............................................................................................ 6

1.4.1 DEFINITION OF A REQUIREMENT ..............................................................................................................................................................7

1.4.2 EFFECTIVE REQUIREMENTS PRACTICES ....................................................................................................................................................7

1.5 THE BODY OF KNOWLEDGE IN SUMMARY ........................................................................................... 8

1.5.1 ENTERPRISE ANALYSIS................................................................................................................................................................................8

1.5.2 REQUIREMENTS PLANNING AND MANAGEMENT....................................................................................................................................9

1.5.3 REQUIREMENTS ELICITATION....................................................................................................................................................................9

1.5.4 REQUIREMENTS ANALYSIS AND DOCUMENTATION...........................................................................................................................10

1.5.5 REQUIREMENTS COMMUNICATION .......................................................................................................................................................10

1.5.6 SOLUTION ASSESSMENT AND VALIDATION........................................................................................................................................10

1.5.7 COMPLEMENTARY CHAPTERS ................................................................................................................................................................10

1.6 THE BODY OF KNOWLEDGE IN CONTEXT ........................................................................................... 11

1.6.1 BODY OF KNOWLEDGE RELATIONSHIPS...............................................................................................................................................11

1.6.2 RELATIONSHIP TO THE SOLUTIONS LIFECYCLE..................................................................................................................................14

CHAPTER 2: ENTERPRISE ANALYSIS

2.1 INTRODUCTION.................................................................................................................................... 15

2.1.1 STRATEGIC PLANNING.............................................................................................................................................................................16

2.1.2 STRATEGIC GOAL SETTING.....................................................................................................................................................................17

2.1.3 THE BUSINESS ANALYST STRATEGIC ROLE .........................................................................................................................................18

2.1.4 THE BUSINESS ANALYST ENTERPRISE ANALYSIS ROLE......................................................................................................................19

2.1.5 ENTERPRISE ANALYSIS ACTIVITIES.........................................................................................................................................................19

2.1.6 RELATIONSHIP TO OTHER KNOWLEDGE AREAS .................................................................................................................................22

2.2 CREATING AND MAINTAINING THE BUSINESS ARCHITECTURE ........................................................ 22

2.2.1 PURPOSE....................................................................................................................................................................................................22

2.2.2 DESCRIPTION ............................................................................................................................................................................................23

2.2.3 KNOWLEDGE.............................................................................................................................................................................................24

2.2.4 SKILLS ........................................................................................................................................................................................................25

2.2.5 PREDECESSORS.........................................................................................................................................................................................25

2.2.6 PROCESS AND ELEMENTS .......................................................................................................................................................................25

2.2.7 STAKEHOLDERS ........................................................................................................................................................................................28

2.2.8 DELIVERABLES ..........................................................................................................................................................................................28

2.2.9 TECHNIQUES .............................................................................................................................................................................................28

2.3 CONDUCTING FEASIBILITY STUDIES................................................................................................... 32

2.3.1 PURPOSE....................................................................................................................................................................................................32

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

2.3.2 DESCRIPTION ............................................................................................................................................................................................32

2.3.3 KNOWLEDGE.............................................................................................................................................................................................33

2.3.4 SKILLS ........................................................................................................................................................................................................33

2.3.5 PROCESS AND ELEMENTS .......................................................................................................................................................................34

2.3.6 STAKEHOLDERS ........................................................................................................................................................................................37

2.3.7 DELIVERABLES ..........................................................................................................................................................................................37

2.3.8 TECHNIQUES .............................................................................................................................................................................................39

2.4 DETERMINING PROJECT SCOPE .......................................................................................................... 42

2.4.1 PURPOSE....................................................................................................................................................................................................42

2.4.2 DESCRIPTION ............................................................................................................................................................................................43

2.4.3 KNOWLEDGE.............................................................................................................................................................................................43

2.4.4 SKILLS ........................................................................................................................................................................................................44

2.4.5 PREDECESSORS.........................................................................................................................................................................................45

2.4.6 PROCESS AND ELEMENTS .......................................................................................................................................................................45

2.4.7 STAKEHOLDERS ........................................................................................................................................................................................46

2.4.8 DELIVERABLES ..........................................................................................................................................................................................46

2.4.9 TECHNIQUES .............................................................................................................................................................................................47

2.5 PREPARING THE BUSINESS CASE ........................................................................................................ 48

2.5.1 PURPOSE....................................................................................................................................................................................................48

2.5.2 DESCRIPTION ............................................................................................................................................................................................48

2.5.3 KNOWLEDGE.............................................................................................................................................................................................48

2.5.4 SKILLS ........................................................................................................................................................................................................49

2.5.5 PREDECESSORS.........................................................................................................................................................................................49

2.5.6 PROCESS AND ELEMENTS .......................................................................................................................................................................49

2.5.7 STAKEHOLDERS ........................................................................................................................................................................................51

2.5.8 DELIVERABLES ..........................................................................................................................................................................................51

2.5.9 TECHNIQUES .............................................................................................................................................................................................53

2.6 CONDUCTING THE INITIAL RISK ASSESSMENT...................................................................................54

2.6.1 PURPOSE....................................................................................................................................................................................................54

2.6.2 DESCRIPTION ............................................................................................................................................................................................54

2.6.3 KNOWLEDGE.............................................................................................................................................................................................54

2.6.4 SKILLS ........................................................................................................................................................................................................54

2.6.5 PREDECESSORS.........................................................................................................................................................................................55

2.6.6 PROCESS AND ELEMENTS .......................................................................................................................................................................55

2.6.7 STAKEHOLDERS ........................................................................................................................................................................................56

2.6.8 DELIVERABLES ..........................................................................................................................................................................................56

2.6.9 TECHNIQUES .............................................................................................................................................................................................56

2.7 PREPARING THE DECISION PACKAGE ................................................................................................. 57

2.7.1 PURPOSE....................................................................................................................................................................................................57

2.7.2 DESCRIPTION ............................................................................................................................................................................................57

2.7.3 KNOWLEDGE.............................................................................................................................................................................................57

2.7.4 SKILLS ........................................................................................................................................................................................................57

2.7.5 PREDECESSORS.........................................................................................................................................................................................57

2.7.6 PROCESS AND ELEMENTS .......................................................................................................................................................................57

2.7.7 STAKEHOLDERS ........................................................................................................................................................................................58

2.7.8 DELIVERABLES ..........................................................................................................................................................................................58

2.7.9 TECHNIQUES .............................................................................................................................................................................................58

2.8 SELECTING AND PRIORITIZING PROJECTS.......................................................................................... 58

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

iii

2.9 LAUNCHING NEW PROJECTS ............................................................................................................... 59

2.10 MANAGING PROJECTS FOR VALUE ..................................................................................................... 59

2.11 TRACKING PROJECT BENEFITS ............................................................................................................ 60

2.12 REFERENCES .........................................................................................................................................60

CHAPTER 3: REQUIREMENTS PLANNING AND MANAGEMENT

3.1 INTRODUCTION.................................................................................................................................... 63

3.1.1 KNOWLEDGE AREA DEFINITION............................................................................................................................................................63

3.1.2 RATIONALE FOR INCLUSION ..................................................................................................................................................................63

3.1.3 KNOWLEDGE AREA TASKS......................................................................................................................................................................64

3.1.4 RELATIONSHIP TO OTHER KNOWLEDGE AREAS..................................................................................................................................64

3.2 UNDERSTAND TEAM ROLES FOR THE PROJECT ................................................................................. 64

3.2.1 TASK: IDENTIFY AND DOCUMENT TEAM ROLES FOR THE PROJECT ..............................................................................................65

3.2.2 TASK: IDENTIFY AND DOCUMENT TEAM ROLE RESPONSIBILITIES .................................................................................................68

3.2.3 TASK: IDENTIFY STAKEHOLDERS ............................................................................................................................................................72

3.2.4 TECHNIQUE: CONSULT REFERENCE MATERIALS..................................................................................................................................73

3.2.5 TECHNIQUE: QUESTIONNAIRE TO IDENTIFIED STAKEHOLDERS........................................................................................................75

3.2.6 TASK: DESCRIBE THE STAKEHOLDERS ..................................................................................................................................................76

3.2.7 TECHNIQUE: INTERVIEW STAKEHOLDERS TO SOLICIT DESCRIPTION ...............................................................................................78

3.2.8 TASK: CATEGORIZE THE STAKEHOLDERS.............................................................................................................................................81

3.3 DEFINE BUSINESS ANALYST WORK DIVISION STRATEGY ................................................................. 82

3.3.1 TASK: DIVIDE WORK AMONGST A BUSINESS ANALYST TEAM..........................................................................................................82

3.3.2 TECHNIQUE: BUSINESS ANALYST WORK DIVISION STRATEGY.........................................................................................................83

3.3.3 TECHNIQUE: CO-ORDINATION OF INFORMATION WITHIN THE TEAM ............................................................................................87

3.3.4 TECHNIQUE: KNOWLEDGE TRANSFER ..................................................................................................................................................90

3.4 DEFINE REQUIREMENTS RISK APPROACH .......................................................................................... 92

3.4.1 TASK: IDENTIFY REQUIREMENTS RISKS..................................................................................................................................................94

3.4.2 TASK: DEFINE REQUIREMENTS RISK MANAGEMENT APPROACH .....................................................................................................95

3.4.3 TECHNIQUE: REQUIREMENTS RISK PLANNING.....................................................................................................................................96

3.4.4 TECHNIQUE: REQUIREMENTS RISK MONITORING...............................................................................................................................98

3.4.5 TECHNIQUE: REQUIREMENTS RISK CONTROL .....................................................................................................................................99

3.5 DETERMINE PLANNING CONSIDERATIONS ......................................................................................100

3.5.1 TASK: IDENTIFY KEY PLANNING IMPACT AREAS ............................................................................................................................... 101

3.5.2 TASK: CONSIDER THE SDLC METHODOLOGY................................................................................................................................ 102

3.5.3 TASK: CONSIDER THE PROJECT LIFE CYCLE METHODOLOGY...................................................................................................... 104

3.5.4 TASK: CONSIDER PROJECT RISK, EXPECTATIONS, AND STANDARDS........................................................................................... 105

3.5.5 TASK: RE-PLANNING............................................................................................................................................................................. 108

3.5.6 TASK: CONSIDER KEY STAKEHOLDER NEEDS AND LOCATION .....................................................................................................109

3.5.7 TASK: CONSIDER THE PROJECT TYPE ................................................................................................................................................ 110

3.6 SELECT REQUIREMENTS ACTIVITIES .................................................................................................111

3.6.1 TASK: DETERMINE REQUIREMENTS ELICITATION STAKEHOLDERS AND ACTIVITIES .................................................................. 112

3.6.2 TASK: DETERMINE REQUIREMENTS ANALYSIS AND DOCUMENTATION ACTIVITIES .................................................................. 115

3.6.3 TASK: DETERMINE REQUIREMENTS COMMUNICATION ACTIVITIES .............................................................................................. 116

3.6.4 TASK: DETERMINE REQUIREMENTS IMPLEMENTATION ACTIVITIES ............................................................................................... 118

3.7 ESTIMATE REQUIREMENTS ACTIVITIES ............................................................................................119

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

3.7.1 TASK: IDENTIFY MILESTONES IN THE REQUIREMENTS ACTIVITIES DEVELOPMENT AND DELIVERY ............................................. 119

3.7.2 TASK: DEFINE UNITS OF WORK.......................................................................................................................................................... 120

3.7.3 TASK: ESTIMATE EFFORT PER UNIT OF WORK..................................................................................................................................121

3.7.4 TASK: ESTIMATE DURATION PER UNIT OF WORK.............................................................................................................................. 122

3.7.5 TECHNIQUE: USE DOCUMENTATION FROM PAST REQUIREMENTS ACTIVITIES TO ESTIMATE DURATION ................................ 123

3.7.6 TASK: IDENTIFY ASSUMPTIONS ........................................................................................................................................................... 125

3.7.7 TASK: IDENTIFY RISKS ........................................................................................................................................................................... 126

3.7.8 TASK: MODIFY THE REQUIREMENTS PLAN ....................................................................................................................................... 127

3.8 MANAGE REQUIREMENTS SCOPE .....................................................................................................129

3.8.1 TASK: ESTABLISH REQUIREMENTS BASELINE.................................................................................................................................... 129

3.8.2 TASK: STRUCTURE REQUIREMENTS FOR TRACEABILITY .................................................................................................................. 130

3.8.3 TASK: IDENTIFY IMPACTS TO EXTERNAL SYSTEMS AND/OR OTHER AREAS OF THE PROJECT ................................................. 135

3.8.4 TASK: IDENTIFY SCOPE CHANGE RESULTING FROM REQUIREMENT CHANGE (CHANGE MANAGEMENT) ............................. 136

3.8.5 TASK: MAINTAIN SCOPE APPROVAL ................................................................................................................................................. 138

3.9 MEASURE AND REPORT ON REQUIREMENTS ACTIVITY...................................................................138

3.9.1 TASK: DETERMINE THE PROJECT METRICS ..................................................................................................................................... 141

3.9.2 TASK: DETERMINE THE PRODUCT METRICS.................................................................................................................................... 142

3.9.3 TASK: COLLECT PROJECT METRICS................................................................................................................................................. 144

3.9.4 TASK: COLLECT PRODUCT METRICS ............................................................................................................................................... 145

3.9.5 TASK: REPORTING PRODUCT METRICS ............................................................................................................................................ 146

3.9.6 TASK: REPORTING PROJECT METRICS.............................................................................................................................................. 147

3.10 MANAGE REQUIREMENTS CHANGE ..................................................................................................150

3.10.1 PLAN REQUIREMENTS CHANGE.................................................................................................................................................... 150

3.10.2 UNDERSTAND THE CHANGES TO REQUIREMENTS ......................................................................................................................150

3.10.3 3.11.3 DOCUMENT THE CHANGES TO REQUIREMENTS ........................................................................................................... 150

3.10.4 ANALYZE CHANGE REQUESTS ....................................................................................................................................................... 151

3.11 REFERENCES .......................................................................................................................................152

CHAPTER 4: REQUIREMENTS ELICITATION.....................................................................................................153

4.1 INTRODUCTION..................................................................................................................................153

4.1.1 RELATIONSHIPS TO OTHER KNOWLEDGE AREAS ............................................................................................................................ 153

4.2 TASK: ELICIT REQUIREMENTS............................................................................................................155

4.2.1 PURPOSE.................................................................................................................................................................................................155

4.2.2 DESCRIPTION ......................................................................................................................................................................................... 155

4.2.3 KNOWLEDGE..........................................................................................................................................................................................155

4.2.4 SKILLS ..................................................................................................................................................................................................... 155

4.2.5 PREDECESSORS...................................................................................................................................................................................... 155

4.2.6 PROCESS................................................................................................................................................................................................. 156

4.2.7 STAKEHOLDERS ..................................................................................................................................................................................... 157

4.2.8 DELIVERABLES ....................................................................................................................................................................................... 157

4.3 TECHNIQUE: BRAINSTORMING .........................................................................................................157

4.3.1 PURPOSE.................................................................................................................................................................................................157

4.3.2 DESCRIPTION ......................................................................................................................................................................................... 157

4.3.3 INTENDED AUDIENCE ............................................................................................................................................................................ 158

4.3.4 PROCESS................................................................................................................................................................................................. 158

4.3.5 USAGE CONSIDERATIONS....................................................................................................................................................................159

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

4.4 TECHNIQUE: DOCUMENT ANALYSIS .................................................................................................159

4.4.1 PURPOSE.................................................................................................................................................................................................159

4.4.2 DESCRIPTION ......................................................................................................................................................................................... 159

4.4.3 INTENDED AUDIENCE ............................................................................................................................................................................ 159

4.4.4 PROCESS................................................................................................................................................................................................. 160

4.4.5 USAGE CONSIDERATIONS....................................................................................................................................................................160

4.5 TECHNIQUE: FOCUS GROUP ..............................................................................................................160

4.5.1 PURPOSE.................................................................................................................................................................................................160

4.5.2 DESCRIPTION ......................................................................................................................................................................................... 161

4.5.3 INTENDED AUDIENCE ............................................................................................................................................................................ 161

4.5.4 PROCESS................................................................................................................................................................................................. 161

4.5.5 USAGE CONSIDERATIONS....................................................................................................................................................................162

4.6 TECHNIQUE: INTERFACE ANALYSIS .................................................................................................. 163

4.6.1 PURPOSE.................................................................................................................................................................................................163

4.6.2 DESCRIPTION ......................................................................................................................................................................................... 163

4.6.3 INTENDED AUDIENCE ............................................................................................................................................................................ 164

4.6.4 PROCESS................................................................................................................................................................................................. 164

4.6.5 USAGE CONSIDERATIONS....................................................................................................................................................................164

4.7 TECHNIQUE: INTERVIEW....................................................................................................................165

4.7.1 PURPOSE.................................................................................................................................................................................................165

4.7.2 DESCRIPTION ......................................................................................................................................................................................... 165

4.7.3 INTENDED AUDIENCE ............................................................................................................................................................................ 166

4.7.4 PROCESS................................................................................................................................................................................................. 166

4.7.5 USAGE CONSIDERATIONS....................................................................................................................................................................168

4.8 TECHNIQUE: OBSERVATION ..............................................................................................................169

4.8.1 PURPOSE.................................................................................................................................................................................................169

4.8.2 DESCRIPTION ......................................................................................................................................................................................... 169

4.8.3 INTENDED AUDIENCE ............................................................................................................................................................................ 170

4.8.4 PROCESS................................................................................................................................................................................................. 170

4.8.5 USAGE CONSIDERATIONS....................................................................................................................................................................171

4.9 TECHNIQUE: PROTOTYPING ..............................................................................................................171

4.9.1 PURPOSE.................................................................................................................................................................................................171

4.9.2 DESCRIPTION ......................................................................................................................................................................................... 171

4.9.3 INTENDED AUDIENCE ............................................................................................................................................................................ 172

4.9.4 PROCESS................................................................................................................................................................................................. 172

4.9.5 USAGE CONSIDERATIONS....................................................................................................................................................................172

4.10 TECHNIQUE: REQUIREMENTS WORKSHOP .......................................................................................173

4.10.1 PURPOSE...........................................................................................................................................................................................173

4.10.2 DESCRIPTION................................................................................................................................................................................... 173

4.10.3 INTENDED AUDIENCE...................................................................................................................................................................... 174

4.10.4 PROCESS........................................................................................................................................................................................... 174

4.10.5 USAGE CONSIDERATIONS ............................................................................................................................................................. 175

4.11 TECHNIQUE: REVERSE ENGINEERING ...............................................................................................176

4.11.1 PURPOSE...........................................................................................................................................................................................176

4.11.2 DESCRIPTION................................................................................................................................................................................... 176

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

4.11.3 INTENDED AUDIENCE...................................................................................................................................................................... 177

4.11.4 PROCESS........................................................................................................................................................................................... 177

4.11.5 USAGE CONSIDERATIONS ............................................................................................................................................................. 177

4.12 TECHNIQUE: SURVEY/QUESTIONNAIRE............................................................................................178

4.12.1 PURPOSE...........................................................................................................................................................................................178

4.12.2 DESCRIPTION................................................................................................................................................................................... 178

4.12.3 INTENDED AUDIENCE...................................................................................................................................................................... 178

4.12.4 PROCESS........................................................................................................................................................................................... 179

4.12.5 USAGE CONSIDERATIONS ............................................................................................................................................................. 181

4.13 BIBLIOGRAPHY...................................................................................................................................182

4.14 CONTRIBUTORS.................................................................................................................................. 182

4.14.1 AUTHORS ......................................................................................................................................................................................... 182

CHAPTER 5: REQUIREMENTS ANALYSIS AND DOCUMENTATION.................................................................183

5.1 INTRODUCTION..................................................................................................................................183

5.1.1 KNOWLEDGE AREA DEFINITION AND SCOPE .................................................................................................................................. 183

5.1.2 INPUTS..................................................................................................................................................................................................... 183

5.1.3 TASKS ...................................................................................................................................................................................................... 184

5.1.4 OUTPUTS ................................................................................................................................................................................................184

5.1.5 ANALYSIS TECHNIQUES AND SOLUTION DEVELOPMENT METHODOLOGIES ............................................................................ 185

5.1.6 SIGNIFICANT CHANGES FROM VERSION 1.4.................................................................................................................................... 186

5.2 TASK: STRUCTURE REQUIREMENTS PACKAGES ...............................................................................187

5.2.1 PURPOSE.................................................................................................................................................................................................187

5.2.2 DESCRIPTION ......................................................................................................................................................................................... 187

5.2.3 PREDECESSORS...................................................................................................................................................................................... 187

5.2.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 188

5.2.5 STAKEHOLDERS ..................................................................................................................................................................................... 191

5.2.6 DELIVERABLES ....................................................................................................................................................................................... 191

5.3 TASK: CREATE BUSINESS DOMAIN MODEL ......................................................................................191

5.3.1 PURPOSE.................................................................................................................................................................................................191

5.3.2 DESCRIPTION ......................................................................................................................................................................................... 192

5.3.3 PREDECESSORS...................................................................................................................................................................................... 192

5.3.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 192

5.3.5 STAKEHOLDERS ..................................................................................................................................................................................... 193

5.3.6 DELIVERABLES ....................................................................................................................................................................................... 193

5.4 TASK: ANALYZE USER REQUIREMENTS ............................................................................................193

5.5 TASK: ANALYZE FUNCTIONAL REQUIREMENTS ...............................................................................193

5.5.1 PURPOSE.................................................................................................................................................................................................193

5.5.2 DESCRIPTION ......................................................................................................................................................................................... 193

5.5.3 PREDECESSORS...................................................................................................................................................................................... 193

5.5.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 193

5.5.5 STAKEHOLDERS ..................................................................................................................................................................................... 197

5.5.6 DELIVERABLES ....................................................................................................................................................................................... 198

5.6 TASK: ANALYZE QUALITY OF SERVICE REQUIREMENTS ..................................................................198

5.6.1 PURPOSE.................................................................................................................................................................................................198

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

vii

5.6.2 DESCRIPTION ......................................................................................................................................................................................... 198

5.6.3 PREDECESSORS...................................................................................................................................................................................... 198

5.6.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 198

5.6.5 STAKEHOLDERS ..................................................................................................................................................................................... 201

5.6.6 DELIVERABLES ....................................................................................................................................................................................... 201

5.7 TASK: DETERMINE ASSUMPTIONS AND CONSTRAINTS ..................................................................201

5.7.1 PURPOSE.................................................................................................................................................................................................201

5.7.2 DESCRIPTION ......................................................................................................................................................................................... 201

5.7.3 PREDECESSORS...................................................................................................................................................................................... 202

5.7.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 202

5.7.5 STAKEHOLDERS ..................................................................................................................................................................................... 202

5.7.6 DELIVERABLES ....................................................................................................................................................................................... 203

5.8 TASK: DETERMINE REQUIREMENTS ATTRIBUTES ............................................................................203

5.8.1 PURPOSE.................................................................................................................................................................................................203

5.8.2 DESCRIPTION ......................................................................................................................................................................................... 203

5.8.3 PREDECESSORS...................................................................................................................................................................................... 203

5.8.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 203

5.8.5 STAKEHOLDERS ..................................................................................................................................................................................... 205

5.8.6 DELIVERABLES ....................................................................................................................................................................................... 205

5.9 TASK: DOCUMENT REQUIREMENTS ..................................................................................................205

5.9.1 PURPOSE.................................................................................................................................................................................................205

5.9.2 DESCRIPTION ......................................................................................................................................................................................... 205

5.9.3 PREDECESSORS...................................................................................................................................................................................... 205

5.9.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 205

5.9.5 STAKEHOLDERS ..................................................................................................................................................................................... 207

5.9.6 DELIVERABLES ....................................................................................................................................................................................... 207

5.10 TASK: VALIDATE REQUIREMENTS .....................................................................................................207

5.10.1 PURPOSE...........................................................................................................................................................................................207

5.10.2 DESCRIPTION................................................................................................................................................................................... 207

5.11 TASK: VERIFY REQUIREMENTS ..........................................................................................................207

5.11.1 PURPOSE...........................................................................................................................................................................................207

5.11.2 DESCRIPTION................................................................................................................................................................................... 207

5.11.3 PREDECESSORS................................................................................................................................................................................ 208

5.11.4 PROCESS AND ELEMENTS.............................................................................................................................................................. 208

5.11.5 STAKEHOLDERS ............................................................................................................................................................................... 211

5.11.6 DELIVERABLES .................................................................................................................................................................................211

5.12 TECHNIQUE: DATA AND BEHAVIOR MODELS...................................................................................211

5.12.1 BUSINESS RULES.............................................................................................................................................................................. 211

5.12.2 CLASS MODEL ................................................................................................................................................................................ 214

5.12.3 CRUD MATRIX ............................................................................................................................................................................... 215

5.12.4 DATA DICTIONARY ........................................................................................................................................................................ 217

5.12.5 DATA TRANSFORMATION AND MAPPING .................................................................................................................................. 220

5.12.6 ENTITY RELATIONSHIP DIAGRAMS............................................................................................................................................... 223

5.12.7 METADATA DEFINITION ................................................................................................................................................................ 227

5.13 TECHNIQUE: PROCESS/FLOW MODELS.............................................................................................228

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

viii

5.13.1 ACTIVITY DIAGRAM ........................................................................................................................................................................ 228

5.13.2 DATA FLOW DIAGRAM.................................................................................................................................................................231

5.13.3 EVENT IDENTIFICATION .................................................................................................................................................................. 234

5.13.4 FLOWCHART.................................................................................................................................................................................... 235

5.13.5 SEQUENCE DIAGRAM.....................................................................................................................................................................239

5.13.6 STATE MACHINE DIAGRAM ..........................................................................................................................................................241

5.13.7 WORKFLOW MODELS.................................................................................................................................................................... 242

5.14 TECHNIQUE: USAGE MODELS............................................................................................................244

5.14.1 PROTOTYPING.................................................................................................................................................................................. 244

5.14.2 STORYBOARDS/SCREEN FLOWS .................................................................................................................................................. 247

5.14.3 USE CASE DESCRIPTION ...............................................................................................................................................................250

5.14.4 USE CASE DIAGRAM ...................................................................................................................................................................... 253

5.14.5 USER INTERFACE DESIGNS ............................................................................................................................................................257

5.14.6 USER PROFILES................................................................................................................................................................................ 259

5.14.7 USER STORIES.................................................................................................................................................................................. 261

5.15 ISSUE AND TASK LIST.........................................................................................................................264

5.16 REFERENCES .......................................................................................................................................265

CHAPTER 6: REQUIREMENTS COMMUNICATION

6.1 INTRODUCTION..................................................................................................................................269

6.1.1 KNOWLEDGE AREA DEFINITION ..........................................................................................................................................................269

6.1.2 RATIONALE FOR INCLUSION ...............................................................................................................................................................269

6.1.3 KNOWLEDGE AREA TASKS.................................................................................................................................................................... 269

6.1.4 RELATIONSHIP TO OTHER KNOWLEDGE AREAS................................................................................................................................ 270

6.2 TASK: CREATE A REQUIREMENTS COMMUNICATION PLAN ............................................................271

6.2.1 PURPOSE.................................................................................................................................................................................................271

6.2.2 DESCRIPTION ......................................................................................................................................................................................... 271

6.2.3 PREDECESSORS...................................................................................................................................................................................... 271

6.2.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 271

6.2.5 STAKEHOLDERS ..................................................................................................................................................................................... 273

6.2.6 DELIVERABLES ....................................................................................................................................................................................... 273

6.3 TASK: MANAGE REQUIREMENTS CONFLICTS ................................................................................... 273

6.3.1 PURPOSE.................................................................................................................................................................................................273

6.3.2 DESCRIPTION ......................................................................................................................................................................................... 273

6.3.3 PREDECESSORS...................................................................................................................................................................................... 274

6.3.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 274

6.3.5 STAKEHOLDERS ..................................................................................................................................................................................... 274

6.3.6 DELIVERABLES ....................................................................................................................................................................................... 274

6.4 TASK: DETERMINE APPROPRIATE REQUIREMENTS FORMAT .......................................................... 274

6.4.1 PURPOSE.................................................................................................................................................................................................274

6.4.2 DESCRIPTION ......................................................................................................................................................................................... 274

6.4.3 PREDECESSORS...................................................................................................................................................................................... 275

6.4.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 276

6.4.5 STAKEHOLDERS ..................................................................................................................................................................................... 280

6.4.6 DELIVERABLES ....................................................................................................................................................................................... 281

6.5 TASK: CREATE A REQUIREMENTS PACKAGE.....................................................................................281

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

6.5.1 PURPOSE.................................................................................................................................................................................................281

6.5.2 DESCRIPTION ......................................................................................................................................................................................... 281

6.5.3 PREDECESSORS...................................................................................................................................................................................... 281

6.5.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 282

6.5.5 STAKEHOLDERS ..................................................................................................................................................................................... 285

6.5.6 DELIVERABLES ....................................................................................................................................................................................... 286

6.6 TASK: CONDUCT A REQUIREMENTS PRESENTATION.......................................................................286

6.6.1 PURPOSE.................................................................................................................................................................................................286

6.6.2 DESCRIPTION ......................................................................................................................................................................................... 286

6.6.3 PREDECESSORS...................................................................................................................................................................................... 287

6.6.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 287

6.6.5 STAKEHOLDERS ..................................................................................................................................................................................... 288

6.6.6 DELIVERABLES ....................................................................................................................................................................................... 288

6.7 TASK: CONDUCT A FORMAL REQUIREMENTS REVIEW.....................................................................289

6.7.1 PURPOSE.................................................................................................................................................................................................289

6.7.2 DESCRIPTION ......................................................................................................................................................................................... 290

6.7.3 PREDECESSORS...................................................................................................................................................................................... 290

6.7.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 291

6.7.5 STAKEHOLDERS ..................................................................................................................................................................................... 294

6.7.6 DELIVERABLES ....................................................................................................................................................................................... 295

6.8 TASK: OBTAIN REQUIREMENTS SIGNOFF .........................................................................................295

6.8.1 PURPOSE.................................................................................................................................................................................................295

6.8.2 DESCRIPTION ......................................................................................................................................................................................... 295

6.8.3 PREDECESSORS...................................................................................................................................................................................... 295

6.8.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 295

6.8.5 STAKEHOLDERS ..................................................................................................................................................................................... 296

6.8.6 DELIVERABLES ....................................................................................................................................................................................... 296

6.9 REFERENCES .......................................................................................................................................296

CHAPTER 7: SOLUTION ASSESSMENT AND VALIDATION..............................................................................297

7.1 INTRODUCTION..................................................................................................................................297

7.1.1 KNOWLEDGE AREA DEFINITION......................................................................................................................................................... 297

7.1.2 RATIONALE FOR INCLUSION ............................................................................................................................................................... 297

7.1.3 KNOWLEDGE AREA TASKS...................................................................................................................................................................298

7.1.4 RELATIONSHIP TO OTHER KNOWLEDGE AREAS............................................................................................................................... 298

7.2 DEVELOP ALTERNATE SOLUTIONS ...................................................................................................299

7.2.1 PURPOSE.................................................................................................................................................................................................299

7.2.2 DESCRIPTION ......................................................................................................................................................................................... 307

7.2.3 PREDECESSORS...................................................................................................................................................................................... 307

7.2.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 307

7.2.5 STAKEHOLDERS ..................................................................................................................................................................................... 307

7.2.6 DELIVERABLES ....................................................................................................................................................................................... 307

7.3 EVALUATE TECHNOLOGY OPTIONS..................................................................................................307

7.3.1 PURPOSE.................................................................................................................................................................................................307

7.3.2 DESCRIPTION ......................................................................................................................................................................................... 307

7.3.3 PREDECESSORS...................................................................................................................................................................................... 307

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

7.3.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 308

7.3.5 STAKEHOLDERS ..................................................................................................................................................................................... 308

7.3.6 DELIVERABLES ....................................................................................................................................................................................... 308

7.4 FACILITATE THE SELECTION OF A SOLUTION...................................................................................308

7.4.1 PURPOSE.................................................................................................................................................................................................308

7.4.2 DESCRIPTION ......................................................................................................................................................................................... 309

7.4.3 PREDECESSORS...................................................................................................................................................................................... 309

7.4.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 309

7.4.5 STAKEHOLDERS ..................................................................................................................................................................................... 309

7.4.6 DELIVERABLES ....................................................................................................................................................................................... 309

7.5 ENSURE THE USABILITY OF THE SOLUTION .....................................................................................309

7.5.1 PURPOSE.................................................................................................................................................................................................309

7.5.2 DESCRIPTION ......................................................................................................................................................................................... 310

7.5.3 PREDECESSORS...................................................................................................................................................................................... 310

7.5.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 311

7.5.5 STAKEHOLDERS ..................................................................................................................................................................................... 311

7.5.6 DELIVERABLES ....................................................................................................................................................................................... 311

7.6 SUPPORT THE QUALITY ASSURANCE PROCESS ...............................................................................311

7.6.1 PURPOSE.................................................................................................................................................................................................311

7.6.2 DESCRIPTION ......................................................................................................................................................................................... 311

7.6.3 PREDECESSORS...................................................................................................................................................................................... 311

7.6.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 311

7.6.5 STAKEHOLDERS ..................................................................................................................................................................................... 311

7.6.6 DELIVERABLES ....................................................................................................................................................................................... 311

7.7 SUPPORT THE IMPLEMENTATION OF THE SOLUTION .....................................................................311

7.7.1 PURPOSE.................................................................................................................................................................................................311

7.7.2 DESCRIPTION ......................................................................................................................................................................................... 312

7.7.3 PREDECESSORS...................................................................................................................................................................................... 312

7.7.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 312

7.7.5 STAKEHOLDERS ..................................................................................................................................................................................... 312

7.7.6 DELIVERABLES ....................................................................................................................................................................................... 312

7.8 COMMUNICATE THE SOLUTION IMPACTS........................................................................................312

7.8.1 PURPOSE.................................................................................................................................................................................................312

7.8.2 DESCRIPTION ......................................................................................................................................................................................... 313

7.8.3 PREDECESSORS...................................................................................................................................................................................... 313

7.8.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 313

7.8.5 STAKEHOLDERS ..................................................................................................................................................................................... 313

7.8.6 DELIVERABLES ....................................................................................................................................................................................... 313

7.9 POST IMPLEMENTATION REVIEW AND ASSESSMENT......................................................................313

7.9.1 PURPOSE.................................................................................................................................................................................................313

7.9.2 DESCRIPTION ......................................................................................................................................................................................... 314

7.9.3 PREDECESSORS...................................................................................................................................................................................... 314

7.9.4 PROCESS AND ELEMENTS .................................................................................................................................................................... 314

7.9.5 STAKEHOLDERS ..................................................................................................................................................................................... 314

7.9.6 DELIVERABLES ....................................................................................................................................................................................... 314

7.10 REFERENCES .......................................................................................................................................314

Table of Contents

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org/

CHAPTER 8: BA FUNDAMENTALS

8.1 INTRODUCTION..................................................................................................................................315

8.2 COMMUNICATION SKILLS .................................................................................................................315

8.3 LEADERSHIP SKILLS ...........................................................................................................................315

8.4 PROBLEM SOLVING SKILLS................................................................................................................ 315

8.5 BUSINESS KNOWLEDGE.....................................................................................................................315

8.6 IT KNOWLEDGE ..................................................................................................................................315

8.7 REFERENCES .......................................................................................................................................315

CHAPTER 9: GLOSSARY

9.1 INTRODUCTION..................................................................................................................................316

9.2 TERMS.................................................................................................................................................316

Preface

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Preface to Release 1.6

P.1 Purpose of this release

The purpose of this release is to add refined detailed content to the material that was

published in BOK 1.4, as well as add content in most of the areas not addressed in 1.4.

This release moves us significantly closer to a complete guide to the Business Analysis

Body of Knowledge. As such, this release is being made available to IIBA members only.

We will continue to provide the table of contents and pieces of content to the general

public to help potential members understand what is covered in the BOK.

This document represents a snapshot of the Knowledge Area documentation as of June

2006. Over the past months since the October 2005 previous release we have gathered

feedback and input from many business analysis practitioners through a structured

feedback process. Each reviewer in that process was pre-screened to ensure they

represented practitioners with at least 3-5 years experience. Their feedback was used by

the Knowledge Area sub-committees to refine our content. We extend a huge thank-you

to each reviewer for taking the time to help in the ongoing creation of the Business

Analysis Body of Knowledge.

We also heard from many IIBA members and potential members who informally

reviewed the previous version. Rest assured your comments and ideas sparked many

discussions among the core team or sub-committees. Your support and enthusiasm have

been critical is helping us maintain focus and momentum. Thank you!

P.2 What is and is not in this release

This release includes:

• An updated introductory chapter including an updated definition of the business

analyst role, and a definition of requirements types. The introduction chapter

will continue to be revised as the BOK is further refined.

• Both refined and added content for:

o Enterprise Analysis

o Requirements Planning and Management

o Requirements Elicitation

o Requirements Analysis and Documentation

o Solution Assessments and Validation

o Requirements Communication

• An updated structure for the Underlying Fundamentals area.

Preface

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

This release does not include:

• The detailed content describing the Underlying Fundamentals area

• An updated Glossary

P.3 Continuing the review and refinement process

To address missing content a new sub-committee for Underlying Fundamentals has been

created and is already hard at work on content. We will also have someone focus on the

Glossary to ensure all key terms are added.

So, while there is still some content to be added for the next release, the primary focus will

be on refinement of the existing material.

The ongoing review and refinement process has a number of components:

BOK Core Team Review for consistency and coherence across the Body of Knowledge

The BOK core team is currently reviewing the inputs and outputs of each knowledge area

in order to:

• fix inconsistencies between chapters

• fix any redundancy between chapters

Many members of the core team have been heavily involved in writing detailed content

for specific knowledge areas. We now have the opportunity to also participate in a

detailed review of the material we did not write. This will further enable us to find and fix

inconsistencies. Our detailed review will focus on:

• keeping the BOK as a descriptor of the knowledge needed by a business analyst vs.

an analysis process or analysis methodology, or a how-to guide

• verifying that the BOK remains methodology-neutral and broadly applicable

• detailed integration between the Knowledge Areas

• ensuring a consistent level of detail across the Knowledge Areas

Industry Expert Advisory Group for industry validation

We have created a panel of industry experts who can provide feedback and input based

on their specialty and experience. This group will be assisting us through the end of 2006

by reviewing the overall scope of the BOK in preparation of the rollout of the certification

program at the end of this year.

Preface

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

In 2007, the group will assist us with a detailed review of the content.

We are still building this group. As of the date of writing this panel includes:

• Scott Ambler, Owner and Founder of Ambysoft Inc. and Practice Leader Agile

Development, IBM Rational. http://www.ambysoft.com/

• James Baird, Professor at Humber College and Owner of BPM3 Inc.,

www.bpm3inc.com

• Rafael Dorantes, Senior Project Manager, Rational Centre of Competency, IBM

Canada Inc.

• Ellen Gottesdiener, Principal Consultant and founder of EBG Consulting, Inc.,

http://www.ebgconsulting.com/about.asp

• Paul Harmon, Executive Editor, Business Process Trends, http://www.bptrends.com

• Ann M. Hickey, Ph.D., Assistant Professor of Information Systems, University of

Colorado, http://web.uccs.edu/ahickey/

• Dean Leffingwell, entrepreneur, software industry executive, and technical

author, http://www.leffingwell.org/bio.html

• Mark McGregor, Principal, BPMG.org (http://www.markmcgregor.com)

• Meilir Page-Jones, President and Senior Consulting Methodologist,

http://www.waysys.com/

• Richard Payne, Consulting Partner, Bauhaus Consulting Group,

http://www.bcgrp.com/

• Karen Tate, Member of the PMI Board of Directors and President of the Griffin

Tate Group, http://www.griffintate.com/

• Steve Tockey, Principal Consultant, Construx Software,

http://www.construx.com/training/instructors/BioSteveTockey.php

• Dr. Ralph R. Young, Director of Process Improvement, Systems and Process

Engineering, Defense Group, Northrop Grumman Information Technology,

http://www.ralphyoung.net

General membership review and input on specific topics

As the review and refinement continues, there will be specific topics or questions we

need to put to the IIBA membership. At various times, specific topics or small surveys

will be posted on the IIBA forum in the BOK area. Please check there often for topics of

interest to you.

Preface

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Professional editing for adherence to the style guide, overall flow and readability

Finally, we recognize that most of the BOK Core team are not professional writers or

editors. As we head into the 2007 release(s) we will be obtaining the professional editing

services required to move us to a professional BOK publication.

P.4 Thinking ahead to the next release

As this release is published, work has already begun on the next release planned for the

end of 2006. The next release will include:

• Content for all sections of each knowledge area and an updated Glossary.

• Refinements based on the Body of Knowledge core team review to ensure all the

connections between the knowledge areas are rationalized.

• Refinements based on the review feedback from our Industry Expert Group.

P.5 Contributors to this Release

The following volunteers have contributed to this release.

Name

Role

Kathleen Barret

Member, Body of Knowledge Committee and President, IIBA

Kevin Brennan

Co-chair, Body of Knowledge Committee and Leader, Requirements

Analysis & Documentation Sub-committee

Barbara Carkenord

Member, Body of Knowledge Committee and Leader, Requirements

Communication Sub-committee and Solution Assessment and Validation

Sub-committee

Mary Gorman

Member, Body of Knowledge Committee and Leader, Requirements

Elicitation Sub-committee

Kathleen (Kitty) Hass

Member, Body of Knowledge Committee and Leader, Enterprise Analysis

Sub-committee

Brenda Kerton

Chairperson, Body of Knowledge Committee

Elizabeth Larson

Member, Body of Knowledge Committee and Co-leader, BOK Review Sub-

committee

Richard Larson

Member, Body of Knowledge Committee and Co-leader, BOK Review Sub-

committee

Dulce Oliveira

Member, Body of Knowledge Committee and Leader, Requirements

Planning & Management Sub-committee

Cleve Pillifant

Member, Accreditation – liaison to Body of Knowledge Committee

Tony Alderson

Member, Requirements Analysis & Documentation Sub-committee

Neil Burton

Member, Enterprise Analysis Sub-committee

Karen Chandler

Member, Requirements Communication Sub-committee

Richard Fox

Member, Requirements Planning & Management Sub-committee

Rosemary Hossenlopp

Member, Requirements Analysis & Documentation Sub-committee

Peter Gordon

Member, Fundamentals Subcommittee

Monica Jain

Member, Requirements Planning & Management Sub-committee

Peter Kovaks

Member, Requirements Communication Sub-committee

Finny Lee

Member, Requirement Elicitation Sub-committee

Preface

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Chris Matts

Member, Fundamentals Subcommittee

Laura Markey

Member, Requirements Communication Sub-committee

Patricia Martin

Member, Requirements Planning & Management Sub-committee

Richard Martin

Member, Requirements Communication Sub-committee

Rosina Mete

Member, Requirements Planning & Management Sub-committee

William Murray

Member, Fundamentals Subcommittee

Harrish Pathria

Member, Requirement Elicitation Sub-committee and Requirements

Analysis & Documentation Sub-committee

Kathleen Person

Member, Requirements Communication Sub-committee

Tony Rice

Member, Requirements Analysis & Documentation Sub-committee

John Slater

Member, Requirements Analysis & Documentation Sub-committee

Mark Tracy

Member, Requirements Planning & Management Sub-committee

Jacqueline Young

Member, Enterprise Analysis Sub-committee

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

P.6 Body of Knowledge Reviewers

The following volunteers were part of the virtual review team.

Name

Sharon Aker

Betty H Baker

Cathy Brunsting

Carrollynn Chang

Pauline Chung

Joseph R Czarnecki

Stephanie Garwood

May Jim

Day Knez

Barb Koenig

Robert Lam

Cherifa Mansoura Liamani

Gillian McCleary

Kelly Piechota

Howard Podeswa

Leslie Ponder

Cecilia Rathwell

Jennifer Rojek

Keith Sarre

Jessica Gonzalez Solis

Jim Subach

Diane Talbot

Krishna Vishwanath

Marilyn Vogt

Scott Witt

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Chapter 1: Introduction

1.1 What is the IIBA BOK?

The Business Analysis Body of Knowledge is the sum of knowledge within the profession

of Business Analysis and reflects what is considered currently accepted practice. As with

other professions, the body of knowledge is defined and enhanced by the business

analysis professionals who apply it. The BOK describes Business Analysis areas of

knowledge, their associated activities and tasks and the skills necessary to be effective in

their execution.

Since the Business Analysis Body of Knowledge is growing and evolving constantly, this

release must be considered an evolving guide to the complete body of knowledge.

Additions will be made at least bi-annually for the next few years until the complete

foundation has been established. While specific techniques may be referenced, the

criteria for including information in the guide are that it is proven, generally accepted and

widely applied.

1.2 Purpose of the Guide to the IIBA BOK

The primary purpose of this guide is to identify the Business Analysis Knowledge Areas

that are generally recognized and accepted as good practice. The Guide provides a

general overview of each Knowledge Area and the list of activities and tasks associated

with each.

As this is the first time a formal document focused on the practice of Business Analysis has

been collected and collated into a structured document, the Guide is also intended as a

spring board for discussions amongst its professionals using a common, agreed to

vocabulary. Going forward the Guide will provide the basic reference document for all

practitioners.

In addition, as the Guide reflects the fundamental knowledge required of an effective

Business Analysis professional, any assessment or certification would require a

demonstration of ability to perform the activities and tasks identified within it. The Guide

to the Body of Knowledge is the basis for developing examination questions for the exam

that individuals must pass to become certified by IIBA. Applicants for IIBA Certification

will be tested on their knowledge in each area in a rigorous and psychometrically sound

examination. This examination is being developed as the IIBA BOK is constructed and

with the aid of a professional certification and licensure testing company. IIBA is

following the International Standard ISO/IEC 17024, General Requirements for Bodies

Operating Certification of Persons, in the creation of the certification and examination

processes.

This guide provides a basic reference for anyone interested in the profession of Business

Analysis. This includes, but is not limited to:

• Senior Executives

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Managers of Business Analysis Professionals

• Business Analysis Professionals

• Project managers

• Educators and Trainers teaching Business Analysis and related topics

• Consultants and other specialists in Business Analysis

This document is neither comprehensive nor all-inclusive. It lays the groundwork for on-

going development of the Body of Knowledge and will expand as information is added.

1.3 Defining the Business Analysis Profession

The IIBA is an organization that is dedicated to advancing the professionalism of its

members as well as the business analysis profession itself. IIBA recognizes the important

contributions business analysts make to organizations every day. As the governing body,

IIBA is seeking to establish common standards of knowledge within the BA profession

and is committed to work with practitioners around the globe to continually add to those

standards through education, research, and the sharing of effective tools and techniques.

A universally recognized certification is the first step towards creating a profession

unique to the functions of business analysis. Establishing a certification for the profession

will create a common expectation by organizations of the skills and knowledge they will

receive from certified business analysts.

Business Analysis is the set of tasks, knowledge, and techniques required to identify

business needs and determine solutions to business problems. Solutions often include a

systems development component, but may also consist of process improvement or

organizational change.

Those performing business analysis are today known by a number of titles such as

business analyst, business systems analyst, systems analyst and others. For simplicity in

this guide we refer to those performing business analysis as business analysts.

Business analysis is distinct from financial analysis, project management, quality

assurance, organizational development, testing, training and documentation

development. However, depending on an organization, an individual Business Analyst

may perform some or all of these related functions.

1.4 Core Concepts of Business Analysis

This section covers the knowledge needed to make effective use of the material in the

Knowledge Areas. Typically this knowledge is required across all the knowledge areas.

Much basic terminology is covered in the Glossary (Chapter 9), but the most key concepts

and knowledge are also discussed here with more detail than a glossary entry can allow.

This section will grow as the detailed material for each knowledge area is developed.

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

1.4.1 Definition of the Business Analyst Role

A business analyst works as a liaison among stakeholders in order to elicit, analyze,

communicate and validate requirements for changes to business processes, policies and

information systems. The business analyst understands business problems and

opportunities in the context of the requirements and recommends solutions that enable

the organization to achieve its goals.

1.4.2 Definition of a requirement

A requirement is

(1) A condition or capability needed by a stakeholder

to solve a problem or achieve an

objective.

(2) A condition or capability that must be met or possessed by a system or system

component to satisfy a contract, standard, specification, or other formally imposed

documents.

(3) A documented representation of a condition or capability as in (1) or (2).

Requirements serve as the foundation of systems or system components. A requirement

can be thought of as something that is demanded or obligatory; a property that is essential

for the system to perform its functions. Requirements vary in intent and in kinds of

properties. They can be functions, constraints, or other elements that must be present to

meet the needs of the intended stakeholders. Requirements can be described as a

condition or capability a customer needs to solve a problem or achieve an objective. For

clarification purposes, a descriptor should always precede requirements; for example,

business requirements, user requirements, functional requirements.

1.4.3 Definition of requirements types

The types of requirements that exist vary based on the problem domain and methodology

that the Business Analyst works with. For the purposes of the Business Analysis Body of

Knowledge, the following types of standard requirements types have been defined:

• Business Requirements are higher-level statements of the goals, objectives, or needs

of the enterprise. They describe such things the reasons why a project is initiated, the

things that the project will achieve, and the metrics which will be used to measure its

success. They are detailed further in the Enterprise Analysis KA.

• User Requirements are statements of the needs of a particular stakeholder or class of

stakeholders. They describe the needs that a given stakeholder has and how that

stakeholder will interact with a solution. User Requirements serve as a bridge

between Business Requirements and the various classes of solution requirements.

This definition is based on IEEE Std 610.12-1990.

The word “user” in IEEE Std. 610.12-1990 has been changed to “stakeholder”. Requirements may emerge from persons or organizations that do

not directly interact with the system under development.

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

They are gathered from stakeholders as described in the Requirements Elicitation KA

and documented using the techniques described in the Requirements Analysis and

Documentation KA.

• Functional Requirements describe the behavior and information that the solution

will manage. They describe capabilities the system will be able to perform in terms of

behaviors or operations – a specific system action or response. They are further

described in the Requirements Analysis and Documentation KA.

• Quality of Service Requirements capture conditions that do not directly relate to the

behavior or functionality of the solution, but rather describe environmental

conditions under which the solution must remain effective or qualities that the

systems must have. They are also known as non-functional or supplementary

requirements. They are further described in the Requirements Analysis and

Documentation KA.

• Assumptions and constraints identify aspects of the problem domain that are not

functional requirements of a solution, and will limit or impact the design of the

solution. They are further described in the Requirements Analysis and Documentation

KA.

• Implementation requirements describe capabilities that the solution must have in

order to facilitate transition from the current state of the enterprise to the desired

future state, but that will not be needed once that transition is complete. They are

further described in the Solution Assessment and Validation KA.

1.4.4 Effective requirements practices

Through practical experience and study of system and software engineering practices, it is

clear that the use of effective requirements definition and management practices leads to

successful projects, satisfied customers and increased professionalism in the industry.

Benefits include:

• A clear understanding of the needs of users, customers and stakeholders

• A collaborative relationship between the users, customers and stakeholders and

the technical team

• A strong commitment of the requirements development team members to

project objectives

• Use of a repeatable requirements process that is continuously improved

• A system architecture that supports the users, customers and stakeholders current

and planned needs

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• The ability to accommodate changes in requirements as they are progressively

elaborated

• High quality systems and products

• System development cost savings, accurate schedules, customer satisfaction

1.5 The Body of Knowledge in summary

There are six knowledge areas defined, that combined, cover the core areas where the

IIBA will set professional standards for those performing business analysis:

• Enterprise Analysis

• Requirements Planning and Management

• Requirements Elicitation

• Requirements Communication

• Requirements Analysis and Documentation

• Solution Assessment and Validation

Two other topics round out the knowledge requirements for business analysts:

• BA Fundamentals

• Glossary

1.5.1 Enterprise Analysis

This knowledge area is the collection of pre-project or early project activities and

approaches for capturing the necessary view of the business to provide context to

requirements and functional design work for a given initiative and/or for long term

planning. In some organizations this work is treated as an investigative, feasibility or

business architecture initiative and treated as a project in itself.

It is important for those in the Business Analysis profession to understand the

organizational environment in which they are working. They should understand how the

project, and their work in it, supports the entire enterprise.

Typical Enterprise Analysis activities leading up to project selection guided by the

Business Analyst include those listed below. While these activities appear to be

sequential, they are often conducted concurrently and iteratively.

• Creating and maintaining the Business Architecture

• Conducting feasibility studies to determine the optimum business solution

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Identifying new business opportunities

• Scoping and defining the new business opportunity

• Preparing the Business Case

• Conducting the initial Risk Assessment

• Preparing the Decision Package.

Enterprise Analysis is covered in Chapter 2.

1.5.2 Requirements Planning and Management

The Requirements Planning and Management Knowledge Area defines the resources and

tasks associated with the planning and management of requirements gathering activities

throughout the requirements process. The Business Analyst must define the requirements

activities that will be performed and how those activities will be performed on a project,

in accordance with any existing standards in the organization. It includes identifying key

roles, selecting requirements activities, managing the requirements scope and ongoing

communication of the requirements gathering status. Proper planning and management

of requirements gathering activities ensures the success of the requirements process and

requirements deliverables.

Before initiating requirements activities and during the requirements process it is

important to consider how the Business Analysis team is going about the requirements

activities on a project. This is necessary to ensure:

• the set of requirements activities undertaken are the most appropriate, given the

unique circumstances of the project,

• the requirements work effort is coordinated with the other work being done for

the project,

• the whole requirements team on a project has a common understanding of what

activities they are undertaking,

• business analysts are able to monitor and react to requirements challenges and

slippage,

• the tools, resources and requirements contributors are available as needed for the

requirements activities,

• and, changes are captured correctly and consistently.

Requirements Planning and Management is covered in Chapter 3.

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

1.5.3 Requirements Elicitation

Eliciting requirements is a key task in business analysis. Because the requirements serve as

the foundation for the solution to the business needs it is essential that the requirements

be complete, clear, correct, and consistent. Leveraging proven means to elicit

requirements will help meet these quality goals.

The Requirements Elicitation knowledge area defines standard techniques used to collect

the requirements of the system. This activity is also known in the industry as “eliciting”

requirements. The system in question may be a business system, and automated system or

both. The scope of the Elicitation work may be a new system or an enhancement to an

existing system. The business analysis professional selects the appropriate mean(s) to

gather the needed requirements based on the applicability of a technique’s process, key

features and strengths and weakness.

Requirements Elicitation is covered in Chapter 4.

1.5.4 Requirements Analysis and Documentation

This knowledge area describes how stakeholder needs are analyzed, structured and

specified for use in the design and implementation of a solution. The objective is to define

and describe the characteristics of an acceptable solution to a business problem, so that

the project team has a clear understanding of how to design and implement it.

Requirements analysis defines the methods, tools and techniques used to structure the

raw data collected during Requirements Elicitation, identify gaps in the information and

define the capabilities of the solution, which must be documented.

Deliverables from this process will be used by the project team to develop estimates for

the time, resources, and budget required to implement a solution or solutions that will

fulfill the requirements. The documentation itself is only one of several techniques the

Business Analyst will use to ensure that a consensus between all the stakeholders exists as

to the behavior of the solution. The primary focus of documentation activity is to refine

the models based upon stakeholder feedback and iteratively ensure feasibility of the

proposed requirements to support the business and user needs, goals and objectives.

Requirements Analysis and Documentation is covered in Chapter 5.

1.5.5 Requirements Communication

The Requirements Communication Knowledge Area is the collection of activities and

considerations for expressing the output of the requirements analysis and documentation

to a broad and diverse audience. Requirements communication is an ongoing, iterative

activity that is done in parallel with Requirements Gathering and Requirements Analysis

and Documentation. It includes presenting, communicating, verifying, and gaining

approval of the requirements from the stakeholders and implementers of the project.

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

An effective business analyst must be able to clearly present the requirements in a format

and structure that is appropriate for its intended audience. Business Analysts must

understand the options and select the appropriate communication formats for their

project. BAs must consider when and where communications need to take place, what

communication approach is appropriate for each situation, and how each

communication should be presented. Requirements must be “packaged,” reviewed, and

approved before the solution is implemented.

Requirements Communication is covered in Chapter 6.

1.5.6 Solution Assessment and Validation

This knowledge area covers the business analysis tasks necessary to ensure that the

solution meets the stakeholder objectives, is thoroughly tested, and is implemented

smoothly.

Once a solution design has been agreed upon, the Business Analyst assists the technology

team with detailed design work including splitting a large project into phases, reviewing

technical design deliverables, and helping to build usability into the application software.

In the case of a purchased solution, they will assist with any package customization

decisions that need to be made and with interface requirements. As the solution is built

and available for testing, the Business Analyst role involves supporting the Quality

Assurance activities. They may help business stakeholders with user acceptance testing,

defect reporting and resolution.

The Business Analyst is accountable for ensuring that the solution developed meets the

defined needs and should assess project success after implementation.

Solution Assessment and Validation is covered in Chapter 7.

1.5.7 Complementary Chapters

Chapter 8 in this Guide is titled BA Fundamentals and it defines the collection of general

competencies, skills, techniques and knowledge needed to effectively perform business

analysis. The defined knowledge is not unique to those performing business analysis and

the IIBA will not set the professional standards for this knowledge, but it is nevertheless

required in a business analysis role.

Chapter 9 of the Guide is the Business Analysis Body of Knowledge Glossary. The

Glossary will continue to grow and evolve as more detail is added to each knowledge

area.

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

1.6 The Body of Knowledge in context

1.6.1 Body of Knowledge relationships

The Body of Knowledge is not a methodology. While it defines the activities, tasks and

knowledge that a business analysis professional needs to know, it does not do so from the

perspective of prescribing an order or sequence.

Specifically, the knowledge areas do not define a business analysis methodology. They do

define what the BA needs to know to work within any analysis process or overall solutions

development methodology.

By looking at the following picture, however, we understand the relationships between

the areas of the Body of Knowledge and the broader world that business analysis fits into.

This picture highlights a number of important points:

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

1. The Fundamentals and Glossary sections of the Body of Knowledge are not activity or

task driven. As described in the previous section, they outline the base knowledge

needed for a business analysis professional to be successful.

2. Not all work that a business analysis professional does is for a defined project. It is not

unusual for Enterprise Analysis activities to be considered either pre-project work or

an early feasibility phase of a project, with the outputs of that analysis becoming input

into the requirements planning for a project as well as the high-level requirements

goals for further requirements Elicitation.

3. Requirements Planning and Management activities tend to span the duration of a

project with planning input provided to each of the other areas and output provided

back that allows for the requirements management activities and re-planning work to

be done.

4. Communicating about requirements also tends to span the duration of a project with

output from each other knowledge being those things that need to be communicated

and results of the communication feeding back into the necessary knowledge area.

5. Theoretically, one gathers requirements then analyzes and documents them, then

uses them as input into the designs that lead to the final implementation of the

gathered and documented requirements and the testing that validates the solution

against the requirements. In most situations a business analysis professional will face

however, there is significant concurrence and overlapping of these activities. It is

normal to have requirements elicitation and requirements analysis and

documentation work going on concurrently. In fact many of the analysis techniques

outlined later in this Guide are used (often in an informal form) during Elicitation to

understand and confirm the information being gathered. It is also not unusual to have

work being done on alternative solutions and technology options concurrently with

elicitation and analysis work. It is not advisable to start Solution Assessment and

Validation too early though, in order to avoid too early a focus on the solution

without a solid understanding of the need.

6. Information gathered during requirements elicitation or requirements analysis may

lead to further work or refinement of the project feasibility. Also true, though not

desirable is that work done during the implementation of the requirements also

causes review and revision of project feasibility. A full discussion of project

methodologies is outside the scope of this Guide, however, many common

methodologies are designed to reduce the risk of feasibility or requirements discovery

during implementation work.

1.6.2 Relationship to the solutions lifecycle

An individual Business Analyst must work with the project team and other stakeholders

to determine which tasks and techniques defined in the Business Analysis Body of

Knowledge are appropriate for their organization and for a given project. Different

Chapter 1 Introduction

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

projects and methodologies may demand that requirements be produced in specific

formats and in varying levels of detail.

The final version of the Business Analysis Body of Knowledge will be compatible with

small to large, simple to complex projects and all types of methodologies (e.g. iterative,

agile, waterfall). This section will show how the BOK knowledge areas relate to typical

solutions and systems development lifecycles and the project lifecycle.

As this section is further developed it will help the Business Analyst determine which

material in the BOK is most appropriate for their needs.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Chapter 2: Enterprise Analysis

2.1 Introduction

2.1.1 Definition

Enterprise Analysis is the Knowledge Area of the Business Analysis Body of Knowledge (BA

BoK) that describes the Business Analysis activities that take place for organizations to (1)

identify business opportunities, (2) build their Business Architecture framework, and (3)

determine the optimum project investment path for the enterprise, including

implementation of new business and technical system solutions.

The Enterprise Analysis Knowledge Area consists of the collection of pre-project

activities for capturing the future view of the business to provide context to project

requirements elicitation and solution design for a given initiative and/or for long-term

planning. In some large complex organizations this work is treated as an investigative,

feasibility or Business Architecture endeavor and is managed as a stand-alone project.

During Enterprise Analysis activities, the Business Requirements for future project

investments are identified and documented. Business requirements are defined as higher-

level statements of the goals, objectives, or needs of the enterprise. They describe such

things as the reasons why a project is initiated, the things that the project will achieve, and

the metrics which will be used to measure its success. They are detailed further in this

chapter of the BA BoK.

As project management matures into a critical management discipline, organizations

tend to realize that managing projects has two dimensions: (1) investing in the most

valuable projects, and (2) planning, executing and controlling project activities to attain

the business value as early as possible. In order to ensure they are investing in the most

valuable projects, management needs accurate, consistent and useful information about

initiatives that are currently funded as well as proposed new ventures. It is through

Business Analysis practices that this decision-support information is gathered, analyzed

and prepared in the form of a decision package for proposed new projects.

Enterprise Analysis activities (1) begin after the executive team of the organization

develops strategic plans and goals, (2) continue until information is gathered to propose

new programs and supporting projects to management for a go/no go decision whether

to select, prioritize and fund a new project, and (3) end after the benefits of project

outcomes are measured and analyzed. Refer to Table 1.0 for a summary of Enterprise

Analysis activities and their link to business planning events.

2.1.2 Overview

Projects play an essential role in the growth and survival of organizations today. With the

rapidly changing competitive business environment, projects are viewed as a means to

manage change and achieve the strategies of the enterprise. Competitive advantage is now

linked to an organization’s ability to rapidly deploy business solutions, to efficiently use

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

technology to support business processes, and to adapt these solutions as the business

need evolves. Projects must not only deliver high quality products faster, better, and

cheaper (traditionally the responsibility of the project manager), they are also under

intense scrutiny to positively impact the bottom line (increasingly, the joint responsibility

of the project manager, project sponsor, and the Business Analyst).

Activity

Owner

Deliverables

Role of the BA

Strategic Plan

Development

Executive

Team

Strategic Plan

Document

Sr. BAs may be asked to:

Conduct competitive analysis and benchmark studies that serve as input to

the strategic planning process

Help plan and facilitate strategic planning sessions.

Strategic Goal

Development

Executive

Team

Strategic Goals,

Themes &

Measures

Sr. BAs may be asked to facilitate strategic goal setting sessions.

Business

Architecture

Development

Business

Analyst

Business

Architecture

Using information from the strategic plan and goals, the BA leads the

development and maintenance of the current and future state Business

Architecture.

Feasibility Studies

Business

Analyst

Feasibility Study

Report

The BA collaborates with subject matter experts and facilitates the team to:

Identify solution options

Examine the feasibility of each option

Determine the most viable option

Business Case

Development

Business

Analyst

Business Case

Document

The BA collaborates with subject matter experts (the business sponsor,

business representative(s) and IT management) to scope the proposed

project, make time and cost estimates, quantify business benefits and

prepare the business case.

New Project

Proposal

Business

Sponsor

Executive

Presentation

Decision

Package

The BA collects the relevant information about the proposed new project and

provides the executive presentation and decision package to the business

sponsor to propose a new project to the organizational project investment

governance body.

Selecting and

Prioritizing New

Business

Opportunities

Enterprise

Governance

Group

Project Selection

Project Priority

Project Charter

Sr. BAs may be asked to help plan and facilitate portfolio management

meetings, and present the proposal for new projects.

Launching New

Projects

Project

Manager

Project Plans

The BA supports the project manager in initiating and planning the new

project. During the project initiation and planning processes, the BA is

eliciting, analyzing, documenting and validating business requirements and

collaborating with the system architect during initial design of the business

solution to be delivered.

Managing Projects

for Value

Business

Analyst

Updated

Business Case at

key control

gates

The BA works in partnership with the PM to update the Business Case at key

checkpoint control gate reviews to provide management with information to

help determine whether to continue to invest in the project.

Tracking Project

Benefits

Business

Sponsor

Balanced

Scorecard

Reports

The BA ensures metrics and measurements are in place, analyzed and

reported to the business sponsor to track actual vs. expected benefits as

documented in the business case.

Table 1.0 Enterprise Analysis Activities Linked To Business Planning Events

Since there appears to be a never-ending demand for efficient business solutions and new

products and services, organizations are adopting the practice of professional Business

Analysis to increase the value projects bring to the organization. For business

requirements and goals to be converted into innovative solutions that truly reflect the

needs of the business, the Business Analyst role is emerging as the individual who

collaborates with business stakeholders to build a strong relationship between the

business and the technical communities when implementing a new IT-enabled business

solution.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

2.1.3 Strategic Planning

The Business Analyst needs to fully understand the strategic planning process and the

current enterprise strategies. In their strategic planning role, the executive management

team defines the organization’s future in terms of vision, mission and strategic goals.

Strategic planning focuses the executive team on the organization’s reason for being and

provides the foundation to select and prioritize programs and projects. The strategic

planning process provides the context in which Enterprise Analysis is conducted. The

information compiled as a result of Enterprise Analysis facilitates investment decisions

that manifest themselves in programs and supporting projects.

Strategic planning serves to establish the future course of an enterprise. Various business

circumstances and needs are considered during the strategic planning process including:

• Investigating current strategy as related to environmental and market trends

• Assessing the current technology structure and strategies to ensure a fit with the

business vision

• Identifying ongoing business issues

• Remaining competitive, profitable and efficient.

In today’s fast-paced environment, the strategic plan is considered a living, breathing

document that changes as business needs evolve. As the strategies change, the portfolio of

programs and projects is also likely to change.

2.1.4 Strategic Goal Setting

The Business Analyst must also understand the strategic goals and priorities of the

enterprise. Scores of important strategic goals and objectives are likely to be developed

during the strategic planning cycle. Strategic goals are then converted into an organized,

actionable, measurable framework to attain the results that are intended.

An effective approach to execute strategy is to convert strategic goals and objectives into

strategic themes as the building blocks of the strategy. Strategic themes not only reflect

financial performance goals, but also include goals relating to customer value, business

operations that drive value to the customer and ultimately to the shareholders, and the

capabilities of human resources and other corporate assets. Strategic themes begin to

define new business opportunities. Examples of strategic themes include ideas such as:

(1) reduce costs through on-line customer ordering, (2) increase the number of high-

value customers through acquisitions, and (3) increase revenue per customer by

increasing the services provided per customer. For each strategic theme, context,

objectives and measures of success are developed.

To monitor the journey, executive teams are often building corporate scorecards as an

outgrowth of the strategic plan. Increasing the wealth of stakeholders is the ultimate goal

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

of for-profit organizations; as a result, financial goals often rank highest. However, non-

financial decision criteria are also needed to invest in the future success of the enterprise.

The balanced scorecard (Robert Kaplan and David Norton 1996) provides an effective

technique to frame strategic goals. In this model, goals are partitioned into four

dimensions: financial, customer, internal operations, and learning and innovation, as

described below.

Financial goals are the dollar-denominated goals that address finance and accounting

outcomes of the business. Example: “Earn 6% on sales, 18% on investments, and 12% on

assets this year.”

Customer goals address how the customer views the business. The primary measure is

customer satisfaction. An example: “Earn a customer satisfaction rating at 95% or better

this year.”

Internal Operations goals relate to process and functional performance and effectiveness

of core competence. Measures are typically internal, comparing performance with

industry benchmarks. Example: “Achieve inventory turns of 8.0 or better this year.”

Learning and Innovation goals address new product development, organizational

learning and skill development, and application of technology and productivity tools.

Example: “Earn 6% on new product sales.”

In the public sector where mission results drive government agency strategies, the

dimensions take on a slightly different slant (Global Balanced Scorecard for US

Government, PEA, 1999). Measures are established to answer the following questions.

• Customer: “How do our customers see us?”

• Financial: “How do we get the best results for the funds?”

• Internal processes: “What must we excel at?”

• Innovation and Improvement: “How do we continue to improve and create

value?”

Just as the strategic plan is a living document, strategic goals are dynamic as well. So the

process now includes tighter planning cycles to monitor progress and make course

corrections along the way. The bar for adding business value is likely to be raised for

every planning cycle.

2.1.5 The Business Analyst Strategic Role

In small organizations Business Analysts do not typically participate directly in strategic

planning. In large, complex organizations, senior Business Analysts often conduct

competitive analysis and benchmark studies to provide information to the strategic

planning team. As management teams realize they need a framework for strategy

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

execution, they are calling on senior Business Analysts to not only provide information to

management, but also to help plan and conduct strategic planning and goal setting

sessions.

Whether involved or not, it is imperative that Business Analysts have a full understanding

of the strategic goals of the enterprise to ensure new initiatives fit in the long term strategy

and/or mission of the organization, to build and manage the Business Case and other

relevant information regarding new project opportunities. Therefore, it is through

Enterprise Analysis activities that the Business Analyst plays a role in translating business

strategies and themes into proposed new business solutions and ongoing operational

activities. Minor enhancements to a business solution or change initiatives that do not

represent a significant investment often do not require a rigorous enterprise analysis.

However, all change initiatives should be reviewed for alignment with organizational

strategies. The Business Analyst often performs this analysis.

2.1.6 The Business Analyst Enterprise Analysis Role

The Business Analyst plays a critical role working with key stakeholders and subject

matter experts to provide management with the information they need to select and

prioritize projects to optimize the return on project investments. As the name implies,

when conducting Enterprise Analysis, the focus is at the enterprise level where

considerations about a proposed initiative are made across the organization. This is

necessary to be able to understand the business implications, inter-project dependencies

and system interfaces; to determine the risks and exposures to the business; and to relate

these considerations in a consistent manner to enable effective decision making from a

project portfolio perspective.

Every business change initiative needs clear articulation of what the business motivation

is for change. To accomplish this, the Business Analyst collaborates with project

managers, business unit managers and lead information technology (IT) architects and

developers to prepare decision-support information needed by management. In doing

so, the Business Analyst may need to seek advice from other industry experts, either

through the use of internal organizational resources or through the acquisition of these

experts, if not available internally.

2.1.7 Enterprise Analysis Activities

Typical Enterprise Analysis activities leading up to project selection include those listed

below. While these activities appear to be sequential, they are undoubtedly conducted

concurrently and iteratively. These activities are described in detail in the following

sections of this chapter. See Table 2.0 for a depiction of Enterprise Analysis activities, with

a view of the inputs and the outputs produced. Enterprise Analysis activities include:

• Creating and maintaining the Business Architecture

• Conducting Feasibility Studies to determine the optimum business solution

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Scoping and defining the new business opportunity

• Preparing the Business Case

• Conducting the initial Risk Assessment

• Preparing the Decision Package.

Table 2.0 Enterprise Analysis Processes

Enterprise Analysis Overview

- inputs and outputs for each section

Conducting

Feasibility

Studies

Business Architecture Artifacts

Business Feasibility Study

Strategic Alignment

Technical Alignment

Alternative Solution Ranking

& Recommendation

Strategic Plan / Goals / Objectives

Business Problem / Opportunity

Creating &

Maintaining

the Business

Architecture

Strategic Plan / Goals / Objectives

Business Problem / Opportunity

Current State Business Architecture

Business Architecture Framework

Business Architecture Artifacts

Gap Analysis Results

Alignment of Problem / Opportunity

to the business

Preparing

the

Decision Package

Business Architecture Artifacts

Business Feasibility Study

Proposed Project Scope definition

Business Case Report

Initial Risk Rating & Proposed Risk Response

Recommendations

Executive / Sponsor Briefing Material

Collated Package of Enterprise Activity Products

Enhanced Business Case Report

Conducting

the

Initial Risk Assessment

Business Architecture Artifacts

Business Feasibility Study

Proposed Project Scope definition

Business Case Report

Initial Risk Rating

Proposed Risk Responses

Preparing the

Business Case

Business Feasibility Study

Business Case Report

Strategic Plan / Goals / Objectives

Business Problem / Opportunity Definition

Business Architecture Artifacts

Proposed Project Scope definition

Business Case Summary Presentation

Determining

Project Scope

Business Problem / Opportunity Definition

Strategic Fit

Business Objectives & High Level Requirements

Product Description & Scope

Assumptions & Constraints

Major Project Milestones & Funding Requirements

Initial Project Approach & Resourcing

Root Cause Analysis

Rationale for Option Selected

Strategic Plan / Goals / Objectives

Business Architecture Artifacts

Business Feasibility Study

Alternative Solution Ranking & Recommendation

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.1 Scaling Enterprise Analysis Activities

To produce information for project investment decisions, the Business Analyst directs the

array of activities designed to produce just the right amount of information to determine

whether or not to invest in an opportunity. Obviously, significant, high-risk investments

often require more rigor and study than efforts to comply with a legal requirement or to

enhance an existing business system.

One of the tasks of the Business Analyst is to determine how much rigor is needed in

conducting the Enterprise Analysis activities. See Table 3.0, Project Sizing Grid to help

determine the project size, which in turn will help determine the level of analysis

recommended prior to proposing a new project for funding. Also see Table 4.0 for

guidelines for scaling Enterprise Analysis activities to conduct the appropriate amount of

analysis, and the commensurate Business Analyst experience level required.

Project Type

Project Attribute

Small, Low Risk

(SMALL)

Low-to-Moderate Risk

(MEDIUM)

Significant, High Risk

(LARGE)

Estimated Elapsed Time

< 6 Months

6 – 12 Months

12 - 24 Months

Timeframe

Schedule is Flexible

Schedule can undergo minor

variations, but deadlines are

firm

Deadline is fixed and cannot

be changed. Schedule has not

room for flexibility

Complexity

Easily understood

problem and solution.

The solution is readily

achievable

Either difficult to understand

the problem, the solution is

unclear or the solution is difficult

to achieve

Both problem and solution are

difficult to define or

understand and the solution is

difficult to achieve

Strategic Importance

Internal interest only

Some direct business impact

and/or relates to a low priority

Affects core service delivery

and/or directly relates to key

initiatives

Level of Change

Impacts a single

business unit

Impacts a number of business

units

Enterprise impacts

Dependencies

No major

dependencies or inter-

related projects

Some major dependencies or

inter-related projects, but

considered low risk

Major high-risk dependencies

or inter-related projects

Table 3.0 Project Sizing Grid

1. Significant, high-risk projects are likely to need robust Enterprise Analysis performed

by a core team of subject matter experts and facilitated by the Business Analyst.

Referencing the Project Sizing Grid, significant high-risk projects are characterized by:

• Level of Change = enterprise impacts; or

• Two or more categories in Large column

2. Low-to-moderate risk projects are likely to need a more moderate amount of enterprise

analysis performed by the Business Analyst prior to investment. Referencing the Project

Sizing Grid, low-to-moderate risk projects are characterized by:

• Four or more categories in the Medium column; or

• One category in Large column and three or more in Medium column

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

3. Small, low risk projects are likely to need little or no enterprise analysis performed by

the Business Analyst prior to investment. However, decisions to invest in even small

projects should be made based on a cost vs. benefit analysis to ensure the project will add

value to the organization. Referencing the Project Sizing Grid, low-to-moderate risk

projects are characterized by the remaining combinations.

PROJECT SIZE

LEVEL OF ENTERPRISE ANALYSIS

Significant,

High-Risk

Projects

Full set of Enterprise Analysis deliverables:

Business Architecture

Feasibility Study

Business Case

Risk Rating

Decision Package

Low-to-

Moderate Risk

Projects

Modified set of Enterprise Analysis deliverables;

minimally a full Business Case and some Business

Architecture activities

Small, Low-

Risk Projects

Simplified Business Case and some Business

Architecture to provide a context

Guidelines for Scaling Enterprise Analysis Activities

2.1.8 Relationship to Other Knowledge Areas

The outputs from the Enterprise Analysis Knowledge Area become the basis for decision

making during project planning and requirements gathering. As projects progress

through the life cycle, a well-constructed set of pre-project Enterprise Analysis

documentation provides the foundation for project team members to frame the project so

that it will add the value expected to the organization from the project outcomes. Outputs

from Enterprise Analysis will become inputs to:

• Requirements Planning and Management Knowledge Area

• Requirements Gathering Knowledge Area

• Requirements Communication Knowledge Area

It is expected that in the later phases of business analysis, the level of detail developed in

the documentation produced during Enterprise Analysis will be progressively

elaborated.

2.2 Creating and Maintaining the Business Architecture

2.2.1 Purpose

In complex organizations, it is becoming a widespread practice for senior Business

Analysts to focus on the development and maintenance of the Business Architecture. The

purpose of the Business Architecture is to provide a unified structure and context that

guides selection and management of programs and projects.

The Business Architecture is a set of documentation that defines an organization’s current

and future capabilities. The Business Architecture describes the businesses strategy, its

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

long term goals and objectives, the high level business environment through a process or

functional view, the technological environment, and the external environment. It also

defines the relevant stakeholders, such as the government, regulatory agencies,

customers, employees, etc. The Business Architecture is considered a strategic asset used

to understand the current state and plans for the future state of the enterprise.

The Business Architecture consists of an interrelated set of documents, models and

diagrams, organized to present information about the business in terms of business

vision, mission, strategy, functions, rules, policies, procedures, processes, organizations,

competencies and locations, that together comprise the business as a system for delivery

of value. The collective set of documents, models and diagrams provide a context from

which change impacts can be assessed.

Through the creation of the current and future state Business Architecture, a common

understanding of changes that the business must make to achieve its goals comes into

view. As we change the business, we ensure that business operations and their supporting

IT systems are aligned. Through architectural work, we capture and portray business and

technical information in a way that makes the two sets of information easy to interrelate to

drive consistency between business operations and IT systems. Therefore, the Business

Architecture becomes one element within the larger view, the Enterprise Architecture.

The Enterprise Architecture consists of five architectures which in total comprise

Enterprise Architecture:

• Business Architecture

• Information Architecture

• Application Architecture

• Technology Architecture

• Security Architecture

2.2.2 Description

The Business Architecture provides a common planning framework that fosters strategic

and operational alignment. The current and future state views of the business provide

both strategic and operational perspectives that then forms the basis for designing and

managing ongoing change initiatives.

As new business opportunities turn into proposed projects, the Business Architecture

views are used to determine the impact of change both on the business and on the IT

systems supporting the business. As new initiatives are planned, the architectural views

help to ensure integration of policies, processes and IT systems by:

• Documenting the current Business Architecture in terms of the business structure

and components describing the product and/or service strategy, and the

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

organizational, functional, process, information, and geographic aspects of the

business environment.

• Developing the future Business Architecture to depict the strategic vision in

practice.

• Analyzing the gaps between the current and future state Business Architectures to

determine the extent of change required to realize the future state objectives.

• Providing a context in which change initiatives (projects) can be assessed and

helping identify new business opportunities that need to be pursued.

While emerging as a key practice to help manage the complex business environment, the

nature of the Business Architecture implementation depends on the needs and maturity

of the business entity. In small or less mature organizations, the Business Architecture

consists of organizational structure charts, business plans and a simple set of business

rules. In more mature, large organizations, the Business Architecture consists of the

traditional business planning documents accompanied by powerful models, graphs and

matrices to depict the current and future states of the enterprise. Whatever format the end

product takes, most Business Architecture efforts have a common goal: to bring order to

the massive amounts of change businesses are struggling to manage. Achieving this goal is

difficult, since the Business Architecture must not only provide structure and efficiency,

but also remain flexible enough to accommodate different changing business strategies,

functions, rules, and components.

2.2.3 Knowledge

Business architects have knowledge of:

• General business practices

• Industry domains

• IT-enabled business solutions

• Current and emerging business concepts, strategies and practices

• How various lines of business within the organization interact

• Business concepts for organizing enterprise knowledge

• Standard architectural principles and semantics, including an understanding of

how business issues drive information systems requirements

• Standard business concepts and guidance as to how to use them to create

organized information about specific enterprises.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

2.2.4 Skills

Business architects have a balanced and applied skill set in the following areas:

• Business strategy

• Business process engineering

• Business analysis

• Business modeling, as well as various generic industry reference models

• Business concepts, rules, policies and terminology.

2.2.5 Predecessors

Business strategy and planning documents that provide direction when creating and

maintaining the current state Business Architecture include current business plans, goals,

measures and existing business documentation.

Predecessor activities also include strategic plans and goals, feasibility studies, approved

projects to seize new business opportunities and future state business and IT system

documentation.

2.2.6 Process and Elements

Since there can be different drivers for developing a Business Architecture, the sequence

of activities may vary. Some enterprises begin by developing descriptions of the current

state of the business, while others develop the description of the desired future state.

Typical process steps include:

• Determine the scope of the effort

• Plan the activities

• Create or update the documents and drawings

• Conduct a quality review of the Business Architecture components.

.1 Determine the Scope of the Business Architecture Effort

Not every business requires a full blown Business Architecture, and those that do, do not

require all possible views. Therefore, it is important to determine the specific

requirements that are driving the Business Architecture effort, how the resulting

architecture is intended to be used, and by whom. Expectations must be understood from

both the business and the IT groups.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Plan the Business Architecture Effort

Building Business Architecture components is a significant endeavor that should be

initiated and planned like a project. Steps include:

• Determine appropriate framework and approach (see techniques section for

representative frameworks).

• Determine the architectural documents and drawings to be created or updated.

• Select appropriate resources on the basis of the business drivers for building the

architecture and the business entities under review.

• Select relevant business architectural viewpoints, e.g., lines of business, or

business units (operations, management, financial, engineering, etc.), those that

will enable the architect to document the key capabilities of the organization

under review.

• Identify appropriate tools and techniques to be used for capture, modeling and

analysis. Depending on the degree of sophistication warranted, these may

comprise simple documents and spreadsheets, or more sophisticated modeling

tools and techniques.

• Determine how the architectural components will be stored. This may involve

creation of a repository to serve as the archiving mechanism.

Additionally, as plans are developed to create the business architecture, there are a

number of considerations that must be taken into account, including but not limited to

the following:

• Once again, revisit how the architecture will be used. Will it support business

planning activities, or help determine the scope of a change initiative? This

decision will help determine the level of detail that is needed when building the

architecture. (Note: building only the components that are necessary to

document the scope of the business to be impacted by the project would limit the

size and complexity of the architecture effort.)

• The decision to build the architecture using a top-down approach vs. a change-

initiative driven approach.

• The decision to build only the future state (to-be) model, or the current state (as-

is) model, or both. (Note: this may be determined by how much documentation

already exists on the current state.)

.2 Create or Update the Architectural Drawings and Documents

For each business entity, create the documents and models to describe the essential

organizational components. As noted above, only those that are required to meet the

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

specific business need should be created, so as not to invest too heavily in building the

Business Architecture. Activities involved in completing the architecture include the

following:

• Build the requirements traceability matrix to ensure specific architectural

components exist that meet the business need, thus ensuring all requirements for

the scope of the initiative have been addressed.

• Prepare the Business Architecture Report. Document the rationale for structure

and composition, and other decisions made, e.g., whether to build or not to

build certain elements of the architecture in the final architecture report.

Recognize that there are always different perspectives held and that multiple versions of a

base model may be required to represent information and communicate to these different

audiences; the most obvious is the different perspectives of business versus IT.

.3 Conduct a Quality Review and Baseline the Business Architecture

Conduct both an internal and external review with key stakeholders. Review all

architecture components and check against the requirements for this iteration of the

Business Architecture to ensure the Business Architecture is complete enough to be used

for its intended purpose (e.g., by a new project). In addition:

• Validate not only the original motivation for the architecture project to

determine if it is fit for use for the immediate need, but also that it is fit to support

subsequent work in the other architecture domains.

• Ensure standards compliance for each of the architecture components.

• Review to ensure each architecture component is fully documented.

• Refine the Business Architecture if necessary to close any gaps uncovered during

the quality reviews.

• Review and refine business performance measures, checking to ensure

performance measures and metrics are defined and relate to the strategic goals

and themes.

2.2.7 Stakeholders

The Business Architecture focuses on the process and functional aspects of the enterprise

or a portion of the enterprise. It addresses the concerns of all stakeholders of the business,

including:

• Executive and middle management

• Individual contributors

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Project and operational teams

• Shareholders

• Customers and end users

• Government and regulatory bodies.

2.2.8 Deliverables

The deliverables are the documents, graphs, models and any other descriptive

representations of the enterprise that are developed, refined or referenced as part of the

Business Architecture initiative, and may include:

• Strategic plans, goals and strategic themes

• Organization structures, identifying business locations and organizational units

• Business unit goals and objectives for each organizational unit

• Business functions, a detailed decomposition of major functional areas

• Business product lines, and customer-facing activities for each business unit

• Business services provided to customers, both internally and externally, for each

business unit

• Business processes, including performance measures

• Business roles, including knowledge and skill requirements

• Gap analysis results.

2.2.9 Techniques

A variety of frameworks, tools and techniques are employed to create and maintain the

Business Architecture.

.1 Business Architecture Frameworks

The value of a framework is that it provides compartments in which to place predefined

architectural products or outputs, thus providing order and structure to the components.

Examples of architectural frameworks include the following.

The Zachman Framework

It is helpful to use a defined framework that provides a common structure and

classification scheme for descriptive representations of an enterprise. One such

framework that has been widely adopted by organizations both public and private is the

Zachman Framework for Enterprise Architecture developed by John Zachman two

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

decades ago. The framework has evolved to become a universal schematic for describing

complex enterprise systems.

The framework provides common language and common structure for describing an

enterprise. Without a unifying framework, the fundamental design of an organization

may not result in an integrated, well functioning enterprise, which leads to redundancies,

inefficiencies and integration issues. The Zachman Framework is both complex and

comprehensive, and is presented in a matrix format, where:

The columns represent the questions that must be answered to design a business entity:

• What (data and entities)

• How (process or function)

• Where (location and network)

• Who (people)

• When (time)

• Why (motivation).

Whereas, the rows of the framework describe the different perspectives of the enterprise:

• Scope

• Business Model

• System Model

• Technology Model

• Detailed Representations.

The POLDAT Framework

Another, simpler structure that is often used in business process re-engineering projects

is the POLDAT framework. This model develops documents, tables, matrices, graphs,

models and organizes them in the following categories:

• Process – the business processes that flow value from the organization to the

customer.

• Organization – the organizational entities that operate the business processes,

including the management teams, staff positions, roles, competencies,

knowledge and skills.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Location – the location of the business units and other organizational entities,

e.g., call centers, distribution centers, etc.

• Data – the data and information that is the “currency” of the organization,

flowing through the processes to accomplish the business functions.

• Applications – the information technology (IT) applications that enable the

business processes to operate efficiently and provide decision-support

information to the management team.

• Technology – the enabling technology that supports the operation of the

processes and applications.

In this framework, the Process, Organization and Location components comprise

elements of the Business Architecture. When they are accompanied by the Data,

Applications and Technology views, the entire Enterprise Architecture is complete.

.2 Techniques for Business Architecture Modeling

There are a variety of models and graphical representations of business entities that may

be used to create the Business Architecture. Refer to Chapter 5 of the BABoK for a more

detailed description of the most-used business analysis models.

Component Business Models

IBM's Component Business Model is a simplified way of looking at an enterprise. The

Component Business Model has evolved from traditional views of a business, such as

business units, functions, locations or processes. Each model identifies a basic building

block of the business, and includes the people, processes and technology needed by the

component to deliver value to the customer.

Business Process Models

Process Models are often referred to as Activity Models. They describe the process

associated with business activities and the information exchanged between activities.

Process models are typically hierarchical in nature. They capture the activities performed

in a business process, and the inputs, outputs, and resources used of those activities.

Process models often reflect an enterprise wide horizontal perspective, not constrained

by functional areas or business units.

Class Models

A Class Model describes static information and relationships between information. Like

many of the other modeling techniques, it also can be used to model various levels of

granularity.

Use Case Models

Use Case Models describe business processes or systems functions. A Use Case model

describes the business processes of an enterprise in terms of actors involved in business

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

processes and organizational participants, (i.e., people, organizations, etc.). The early

stages of Business Architecture it may be sufficient to develop a high level list of Use Cases

providing a platform from which further levels of detail can be developed.

Business Scenarios

Business scenarios are a valuable technique that may be used as an input to the

development of the Business Architecture to help identify and understand the workings of

the business, and thereby to derive the business requirements and constraints that the

architecture must address. Business scenarios are used to depict what should happen

when planned and unplanned events occur.

Knowledge Management

While Knowledge Management is not typically thought of as a business analysis activity, it

is fast becoming a critical competency in organizations. Knowledge Management is

defined as the process of systematically managing, storing and using the vast array of

knowledge that has emerged within an organization. It is the process of transforming

intellectual property into a permanent asset.

.3 Business Architecture Tools

As the business and enterprise architecture activities become more comprehensive, it is

helpful to use sophisticated modeling tools. In addition, archiving data management

tools are used to consolidate the drawings and documents into a single repository to

provide the foundation for further business analysis activities.

There is an array of tools that exist to help architects model, store, manage and share

information about the enterprise. The tools are typically classified in two main categories,

repositories and modeling tools. As with architecture techniques and frameworks,

enterprise architecture tools are still emerging. However, the focus of business

architecture is about understanding the business, and the business architecture work

should not be overshadowed by the pursuit and use of technology tools.

2.3 Conducting Feasibility Studies

2.3.1 Purpose

Organizations are continually improving their strategic planning and goal setting process,

accompanied by a deliberate approach to strategy execution. Building the current and

future state Business Architecture provides a firm foundational understanding for where

the organization is today, and where it wants to be in the future. The next logical step is to

launch programs and supporting projects to manage the change and reach future goals as

quickly as possible. Determining the optimal project investment path involves identifying

alternative solutions and performing the analysis to select the best option.

A feasibility study may address either a business problem to be resolved, or a business

opportunity to be seized. The main purpose of the study is to ascertain the likelihood of

each potential solution alternative’s probability of satisfying the business need in terms of

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

economic, operational and technical feasibility. The outcome of the feasibility study is a

recommended solution option to be further defined in a business case.

2.3.2 Description

Feasibility studies are research efforts designed to help organizations understand the

competitive environment, enabling them to make informed decisions the future of their

business. Formal feasibility studies use reliable data, and apply proven methods of

statistics and market research to ensure complete and accurate information is produced.

Typically, a feasibility study is conducted to determine the viability of an idea for a new

business opportunity. Depending on the size, complexity and criticality of the study, it

may be consider its own stand-alone project. Feasibility studies provide information:

• When executives are developing strategic goals and themes to drive toward

strategy execution;

• During Enterprise Analysis to help the portfolio management team determine the

best investment path to solve business problems and seize new business

opportunities; and,

• During the requirements and design to help conduct trade-off analysis among

solution alternatives.

The feasibility study is typically an integral part of formulating a major business

transformation project, e.g., establishing a new line of business, increasing market share

through acquisition, or developing a new product or service. Abbreviated studies may

also be conducted for lower risk change initiatives. Although feasibility studies may be

conducted prior to, during or after the completion of a business case, it is usually

undertaken as part of the overall analysis process to create the business case.

2.3.3 Knowledge

Ideally individual(s) will have broad experience in business and IT, understand the

concept of project value and what it may mean to their organization. In addition, the

Business Analyst needs to understand:

• Financial analysis to evaluate the viability of a potential solution

• The industry and the organizational vision, mission, and strategic goals, as well as

organizational policies and procedures that may affect the study or be affected by

the change initiative under study

• A broad, not deep, understanding of the IT infrastructure that supports the

business

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

2.3.4 Skills

Due to the wide range of techniques that are used when conducting a major feasibility

study, the Business Analyst may not possess all of the skills required to plan and execute

the study. Therefore, the Business Analyst must enlist a team of experts to provide the

skills required, including:

• Research and information analysis skills

• Ability to plan and conduct the study, and document the results

• Technical writing skills

• Leadership and organizational skills

• Change management skills

• Communication skills (oral and written) in order to better facilitate, interview

and communicate in a collaborative manner

• Ability to work independently or in a team environment.

.1 Predecessors

Predecessor activities to conducting feasibility studies include:

• Strategic planning and goal setting

• High level business issues and problems descriptions

• Business architecture framework.

2.3.5 Process and Elements

Based on the size and/or complexity of the situation, the study effort may be broken down

into smaller, more manageable pieces and prioritized accordingly. The typical process

steps to conducting a feasibility study include those outlined below. It must be noted that

these steps are often be conducted concurrently, iteratively and, in fact, some steps may be

omitted entirely, depending on the complexity and criticality of the effort. Process steps

include:

• Determine requirements for the study

• Determine objectives, scope and approach, and plan the effort

• Conduct a current state assessment

• Identify potential solutions

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Determine the feasibility of each option

• Document and communicate the results of the study, and obtain approval to

develop the Business Case for the recommended solution.

.1 Determine Requirements for the Study: Business Problem or

Opportunity

Since feasibility studies are used to determine the approach to solving a business problem

or seize a new business opportunity, the approach is slightly different. In the case of a

business problem, the Business Analyst first determines and documents the problems

faced by the organization and the potential areas of study required to address the issues.

The analyst then conducts root cause analysis to determine the full nature of the problem,

the actual cause (or causes) of the problem, the adverse impact it is having on the business

and the criticality and required timing of the resolution.

To take advantage of a new business opportunity, the analyst defines the opportunity in as

much detail as possible to understand the scope and determine the nature of the study.

This information is then used to determine the methodology or approach to be

undertaken to complete the study. For each business problem and/or opportunity, the

analyst drafts a requirements statement describing the business need for a solution.

Examples include:

• Implement a new business process which will improve time to market for current

products by 30%.

• Implement a payroll system that complies with new state regulations by the end

of the year.

• Establish a new line of business to address an identified market demand.

• Establish a project management office to lead strategic projects

• Implement a new financial system that complies with new regulatory

requirements.

.2 Determine the Objectives, Scope and Approach and Plan the Study

Effort

To plan the feasibility study effort, the Business Analyst first assembles a team of skilled

resources who collaboratively perform the following tasks:

Establish specific, measurable objectives that the recommended solution must meet.

These objectives provide the basis for formulating options for consideration.

• Develop benefit criteria upon which alternative solutions will be evaluated in the

form of quantitative measurement criteria by which to judge the success of the

investment in the recommended solution.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Define scope of activities to be performed during the study.

• Define deliverable(s) to be produced from the study; if it does not exist, develop a

template for the final feasibility study report.

• Review all of the information developed in steps 1 and 2 with the sponsor to

validate requirements and scope, and to ensure the study will be complete, and

will satisfy the business drivers. Review and validate:

o Requirements of the study

o Plans for the study

o Objectives benefit criteria and measures by which to evaluate alternative

solutions.

.3 Conduct a Current State Assessment

The study team conducts a limited amount of internal analysis when initiating the

feasibility study. These may include review of business objectives, strategy and vision;

analysis of current business processes; and assessment of current (as-is) and future (to-

be) documentation. If Business Architecture has been created, the descriptive graphs and

documents would provide the source from which this assessment would be conducted.

The current state assessment consists of a review of all or part of these elements,

depending on the nature and scope of the study:

• Strategy – Review the business vision, strategy, goals and measures.

• Business Area – Describe the mission of each line of business or business unit that

is a stakeholder for the area under study, and collect relevant organizational

charts.

• Locations – Document the physical location of each impacted business unit.

• Data and Information – Identify the major types of business information

required. It is also helpful to list the repositories which retain the information

listed.

• Infrastructure – List each of the current business technologies impacted by the

initiative.

• Processes – List and provide a description of each of the current business

processes relevant to this project.

• Competitive Arena – Describe the current business environment within which

the business operates, including:

o Market analysis, competition, products and services available

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

o Emerging markets and technologies

o Regulatory or legislative changes.

.4 Identify Potential Solutions

At this point the study team conducts external research activities to uncover general

information about the industry, the competitive environment, best practices, risks and

results of the actual similar approaches that have been implemented by others to solve the

business problem or seize the new opportunity under consideration. Then, the team

identifies as many potential options as possible to meet the objectives identified in the

planning process. It is important to note that the list of possible alternatives should

include the option of doing nothing.

.5 Determine the Feasibility of each Option

For each potential solution, typical analysis steps include the following:

• Describe the solution option in as much detail as possible, perhaps building a

high-level work breakdown structure (WBS), a hierarchical decomposition of the

solution, to bring the full scope of the effort into view.

• Identify methods to assess the alternative, ensuring the analysis of the economic,

operational and technical feasibility of the option. Examples of methods include:

prototyping to prove the highest risk portions of the solution option are

technically feasible, market surveys to ensure there is a demand for the solution

and it will be economically feasible, technology capability assessment to ensure

the solution does not require new, unproven technology, and business staff

interviews and IT staff interviews to determine operational feasibility.

• Identify expected results of the assessment.

• Define assessment steps.

• Undertake feasibility analysis for each option.

• Review results to ensure completeness.

.6 Document and Communicate the Results of the Study

Describe the results of the feasibility study for each identified alternative solution. Share

the results with the executive sponsor of the study, and secure approval to proceed with

the analysis activities to build the Business Case for the recommended option.

2.3.6 Stakeholders

Stakeholders who are involved in or impacted by pre-project feasibility studies include

the following:

• Executive management

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Business process owners

• Business unit managers

• Subject matter experts who are participating in Enterprise Analysis activities:

Business Analysts, project managers, technology managers.

2.3.7 Deliverables

The deliverable is a Feasibility Study Report that includes environmental information,

both internal and external to the organization that is relevant to the business problem or

opportunity. Other elements that may be included in the report are listed below. It should

be noted that the information in the feasibility report is preliminary and at a very high

level. Further analysis is needed to fully define a proposed project, as described in other

sections of this chapter.

The Feasibility Study Report identifies each of the solution options available and rates the

likelihood of each option achieving the desired result. The Feasibility Study Report is

typically comprised of the following information:

• Executive Summary

• Business problem and/or opportunity statement, including information

uncovered during the current state assessment and the external research activities

• Feasibility study requirements, including the business drivers of the initiative

• For each option that was assessed, the results of the study including the following

pieces of information:

o A complete description of the solution option

o A complete description of the assessment process and methods that were

used

o A complete description of the overall results; document expected vs.

actual results, scoring, and other considerations

o A list of identified risks associated with the alternative. A risk is an event

that may adversely affect the ability of the solution to meet the business

need, including bringing about the business benefits (in terms of

profitability, reduced cost, increased market share, etc.). Risks can be

strategic, environmental, financial, operational, technical, industrial,

competitive, or customer related.

o A list of identified issues which adversely impact the success of the

solution.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

o Assumptions made during the study process to close gaps in information.

It is important to note that if the assumption does not prove to be true, it

may pose a risk to the success of the option under consideration.

• Alternative Solution Ranking

o Ranking criteria

o Ranking scores

• Results – recommended solution, including any additional rationale for the

decision

• Appendix containing all supporting information.

Additional information that may be included in the final report includes:

• Strategic alignment of the proposed change initiative to the organizational

strategy, direction and mission extracted from the Business Architecture activity

• Technology alignment with the current Enterprise Architecture standards

• Availability of COTS (Commercial Off the Shelf) software packages

• Extent to which existing business solutions will be changed, managed and

affected.

2.3.8 Techniques

There is an array of techniques that may be used to conduct the feasibility study,

including techniques to:

• Conduct the current state assessment

• Plan the feasibility study effort

• Identify solution options

• Assess the feasibility of each solution option.

.1 Techniques to Conduct the Current State Assessment

There is an array of techniques the Business Analyst uses to capture the current state of the

business. If the organization has an up-to-date Business Architecture, the task to

document the current state will have been completed, and the Business Analyst needs

only to review and glean as much understanding as possible about the business from the

Business Architecture documentation. If this is not the case, documentation that is

developed during the current state assessment by the feasibility study team will serve as a

basis for the first iteration of the Business Architecture for the current state. Therefore,

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

most if not all of the techniques used to develop the Business Architecture are applicable

when assessing the current state, including:

• Organization Charts to depict business entities impacted by the study.

• Geographical Maps to depict the physical locations of the business entities.

• Data Flow Diagrams to describe the major types of information required by the

business processes that will be impacted.

• Technology Architecture Diagrams to show the interfaces between current

business technologies.

• Process Flow Diagrams to depict the flow of process steps to complete a business

function.

• Domain Modeling techniques are used to provide a simplistic visualization of

the business area under consideration to understand the scope of the initiative.

• Six Sigma techniques to use data and statistical analysis to measure both current

and future state process efficiency.

• Root Cause Analysis to identify the conditions that initiate the occurrence of the

undesired activity or state.

.2 Techniques to Plan the Feasibility Study

During this step, the Business Analyst enlists the assistance of an experienced project

manager. Techniques include:

• Standard Project Management techniques to plan and manage the feasibility

study activities.

• Brainstorming techniques to identify as many potential solutions as possible that

will meet the requirements.

• Work Breakdown Structure (WBS) to provide a decomposition of each

proposed solution as part of the description of each option.

.3 Techniques to Identify Solution Options

During this step, the Business Analyst facilitates a creative session to identify as many

potential options as possible. Techniques include:

• Brainstorming techniques to identify as many potential solutions as possible that

will meet the requirements.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Six Sigma techniques are also useful when the study is focusing on business

process improvement because of its quality measurement and improvement

capabilities.

• Business Process Reengineering techniques may be used by the study team to

foster fundamental rethinking and radical redesign of business processes to

achieve dramatic improvements.

• Cause-and-Effect diagramming techniques graphically summarize the results of

a brainstorming session, identifying the causes of a specified undesirable

outcome.

.4 Techniques to Conduct the Analysis of the Feasibility of each Option

During this step, the Business Analyst involves all members of the study team. Techniques

that may be used include:

• Market Surveys to prove acceptance and to forecast demand in the marketplace.

• Technology Feasibility Assessment to ensure the option is not beyond the

organization’s current limits of technology.

• Interviews

o Business staff interviews to determine operational feasibility in the

workplace

o IT staff interviews to determine operational feasibility in the technical

operating environment

o Finance staff and project manager interviews to estimate the cost of the

alternative solution to ensure economic feasibility.

• Prototyping to build the highest risk component of a proposed solution to prove

that solution is technically feasible.

• Risk identification, assessment, ranking and risk response planning.

• Benchmarking Analysis to determine best-in-class practices.

• Competitive Analysis to examine the viability of market success of the solution.

• Environmental Impact Analysis to determine the likely environmental impacts

of the proposed solution.

• Technology Advancement Analysis to examine the latest technical approaches

to solving the business problem.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Early Cost Vs. Benefit Analysis to determine the economic viability of the each

option (this will be covered in more detail under the task to develop the business

case).

• COTS Package compare/contrast analysis to decide whether to select a

commercial-off-the-shelf product for a part of all of the solution option.

• Issue identification, assessment, ranking and issue response planning.

• Pareto Diagram to be used as a presentation device to help assess the relative

value and cost of potential solutions.

• The Analytic Hierarchy Process (AHP) to help study teams make the best

decision, capturing both qualitative and quantitative aspects of the decision. The

process is used to reduce these complex decisions to a series of simple

comparisons. Its power is that it provides a clear rationale for the decision.

• Decision Analysis is also used to help study teams make the best decision by

providing a statistical method to delineate the probabilities of various outcomes.

• Decision Tables are a matrix representation which can be used to communicate

the logic of the decision for the recommended option.

• Structured Problem Solving Techniques to provide mechanisms to receive and

retrieve new information in a systematic manner, e.g., the explicit method.

• Data Gathering and Research Approaches to conduct a systematic investigation,

including research development, testing, and evaluation, designed to develop or

contribute to the knowledge about each option.

• Probability Analysis is also used to help study teams make the best decision by

providing a mathematical description of the likelihood of a specific event.

2.4 Determining Project Scope

2.4.1 Purpose

Once the business solution has been identified, it must be further defined. The purpose of

this task is to define the project to conceptualize and design the recommended solution in

enough detail to build a business case, conduct an initial analysis of the risks and propose

a new project to the portfolio management governance group. The preliminary scope

definition provides a documented basis for building the business case. The activities

include:

• Describing the business environment in enough detail to provide context to the

new project.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Describing the business requirements in enough detail to understand the

business needs.

• Defining the scope of the work that must be performed to deliver the product,

service or results to meet the business objectives in enough detail to prepare time

and cost estimates.

During Enterprise Analysis, it is likely that a project manager has not yet been assigned,

since the project has not yet been approved. Since project scoping and defining is

typically the role of the project manager, the Business Analyst enlists the assistance of an

experienced project manager to establish the boundaries of the business problem and

solution and define the scope of the proposed project. The Business Analyst, serving as

the lead during Enterprise Analysis activities, facilitates the development of the high level

scoping documentation that is needed to build a Business Case for the proposed initiative.

It is likely that the Business Analyst will not only enlist the assistance of a senior project

manager, but also a business and technical lead to serve as a proposal team, compiling the

decision package for the executive sponsor of the proposed project. It is useful if the study

team that conducted the feasibility study also serves as the proposal team to continue the

effort quickly

2.4.2 Description

Defining the proposed project scope includes:

• Describing business objectives

• Determining expected deliverables at a high level in terms of products, services or

other outcomes

• Documenting business assumptions and constraints

• Building a statement of the anticipated work effort.

2.4.3 Knowledge

The knowledge requirements for the proposal team of subject matter experts include the

following.

An understanding of external frameworks for business process improvement, including

but not limited to:

• Business process re-engineering concepts and techniques

• Business architectural frameworks that provide industry context to Enterprise

Analysis, e.g., The Zachman Framework.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Capability Maturity frameworks that provide proven methods to advance

organizational capabilities, e.g., the Carnegie Mellon University, Software

Engineering Institute’s Capability Maturity Model.

• International standards that are proven to enable business processes, e.g., ISO,

the International Organization for Standardization.

• An understanding the business environment, including industry standards,

organizational culture, politics, social networks, organizational structures and

norms within the enterprise.

• Knowledge of general management disciplines, e.g., financial management,

purchasing, sales and marketing, contracts, manufacturing and distribution,

logistics, strategic planning, operation planning, health and safety practices.

A basic understanding of the Project Management Institute Project Management Body of

Knowledge (PMBOK), including:

• Project life cycles

• Project management process groups

• Project management knowledge areas, especially project scope management

• Projects, subprojects, programs and portfolios.

• Knowledge of the impacted application area standards and regulations:

• Functional departments within the enterprise

• Supporting disciplines within the enterprise: legal, production, inventory

management, marketing, logistics, human resources

• Knowledge about the technology elements supporting the enterprise, including

engineering, research and development, information technology

• Familiarization with management specializations, including government

contracting, new product development.

2.4.4 Skills

Skills required to scope and define the proposed project include:

• Planning, estimating and scheduling.

• Scope definition and decomposition.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Interpersonal skills: influencing the organization, leadership, motivation,

negotiation, conflict management.

• Documentation and diagramming approaches used to describe typical business

components including entity relationship diagrams, process diagrams, and

workflow diagrams. Note: these will be developed only at a very high level at this

point, to ensure the scope of the proposed project is understood.

Communication skills:

• Written communication

• Presenting

• Interviewing

• Listening

• Teamwork/Collaboration.

2.4.5 Predecessors

Predecessor activities to scoping and defining the proposed new project include:

• Strategic planning and goal setting

• Business architecture development and documentation

• Business opportunity and/or problem definition

• Feasibility studies to conduct alternative solution analysis and determine the

recommended solution.

2.4.6 Process and Elements

Scoping and defining the project proposal includes:

• Drafting the preliminary project scope statement

• Developing a high-level work breakdown structure

• Developing cost and time estimates

• Describing the project approach.

.1 Draft the preliminary project scope statement

Drafting the preliminary project scope statement involves developing a high level

description of the work that must be performed to deliver the proposed new business

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

solution. Scope statements typically clearly state in-scope and out-of-scope elements of

the solution.

In addition, develop a list of key stakeholders who will be involved in or impacted by the

project. Describe the new solution in terms of the major features and functions that are to

be included. Finally, depict project boundaries in terms of business units impacted,

business processes improved or redesigned, process owners, IT systems and technology

that will be impacted.

.2 Develop a high-level Work Breakdown Structure

Creating a high-level work breakdown structure (WBS) involves decomposing the work

that must be performed into lower-level deliverables. The WBS is used to further define

the project scope, and for cost and schedule estimating. In this early pre-project analysis,

the WBS should be decomposed only to levels 2 or 3.

.3 Develop Cost and Time Estimates

Develop initial cost and resource requirement estimates, including costs to procure,

develop, integrate, test, deploy and operate the new business solution. In addition,

develop the initial milestone schedule.

.4 Describe the Project Approach

Describe the initial project approach and structure, e.g., partitioning the proposed

project into releases that will deliver useful subsets of functionality to the business,

outsourced development of the entire solution, purchase an existing system and integrate

the solution into current business processes and technology, etc.

2.4.7 Stakeholders

Key stakeholders who are involved in or impacted by the proposed business solution

scoping activities include:

• Business executive sponsor of the proposed project..

• Business process owner(s) and business process subject matter experts for the

business area to be changed. The business process experts will assist in defining

the project objectives, business area constraints and the process boundaries of

the project.

• IT management who is supporting the business area. The IT manager will to help

scope the components of the business process that will be supported with

technology.

• The portfolio management governance group.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

2.4.8 Deliverables

The deliverable from this effort is the scope statement and supporting information

defining the following components by inclusion or reference. This documentation is

input to the preparation of the Business Case, and includes the following elements.

• Summary of activities the led up to the recommended solution including the

business environment analysis and competitive analysis.

• Strategic alignment describing how the initiative fits with organizational direction

or mission.

• Business objective(s) and high-level business requirements.

• Product description and scope.

• Project boundaries including context diagrams to provide a visual model of the

scope of the project.

• Assumptions and constraints.

• Major project milestones, funding requirements and limitations.

• Initial project approach including resource requirements, methodology, tools,

and training requirements.

• Current and future standards, policies, regulations to be adhered to and impacts

to the initiative.

• Commercial Off-the-Shelf (COTS) packages available vs. customized

development of the solution.

• Dependencies, including downstream systems, interfaces, supporting data

required.

2.4.9 Techniques

.1 Techniques to Define the Scope of the Proposed Project

Scope Decomposition and Decomposition

Scope definition and decomposition involve the activities to size the proposed project so

that estimates can be made of costs, resources requirements and project duration. Scope

definition and decomposition are traditional project management practices designed to

understand the full scope of a project. When used as a component of pre-project

Enterprise Analysis activities, the Business Analyst typically enlists the help of a senior

project manger who is skilled in early scope decomposition and cost and time estimation.

This information is critical for the portfolio management governance group to

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

understand the magnitude of the proposed project, and for the proposal team to develop

cost and schedule estimates. Techniques include:

• Work Breakdown Structure (WBS), a decomposition of work that is required to

complete a project to accomplish the business objectives. It is typically

deliverable-oriented and hierarchical in nature. The WBS describes the total

scope of the project work to be performed.

• Initial product analysis represented in a Product Breakdown Structure (PBS)

format, a decomposition of the components of the product. The PBS describes

the total scope of the product or service to be delivered.

• System Interface Analysis, a depiction of the scope of work required to integrate

the new solution into the business and technical environments.

.2 Context/Business Domain Models

The Context Diagram provides a visual model of the scope of the project. It serves as a

high-level view of the business solution to be built, and identifies the entities that interface

with the solution. Context diagrams are reviewed by all stakeholders and therefore are

written in natural language so that business stakeholders can understand the items within

the document. Context diagrams are used early in a project to get agreement on the scope

under review. A Use Case Diagram also represents the scope of the project at a similar

level of abstraction as the context diagram. See Chapter 5 for more detailed information

on context diagrams.

2.5 Preparing the Business Case

2.5.1 Purpose

The Business Case will ultimately be submitted to management as a basis to determine

whether further investment in the project is warranted, i.e., funding for project initiation,

planning and requirements elicitation, analysis and documentation. It is common

business practice to require the discipline of Business Case development for large-scale

initiatives. The Enterprise Analysis activities culminate in development of the Business

Case to ensure that adequate information is presented for the portfolio management

governance group to make the best investment decisions.

2.5.2 Description

The Business Case describes the justification for the project in terms of the value to be

added to the business as a result of the project outcomes vs. the cost to develop the new

solution. It usually includes information about the opportunity in terms of the market

trends, competitive environment and expected market penetration if a feasibility study is

not available to provide this context information. The Business Case also includes

qualitative and quantitative benefits, estimates of cost and time to breakeven, profit

expectations, follow-on opportunities, etc. The Business Case may present expected cash

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

flow consequences of the action, over time, and the methods and rationale that were used

for quantifying benefits and costs. This provides a framework to demonstrate how the

initiative is expected to achieve business objectives.

The Business Case also discusses the impact of the proposed change initiative on the

business operations, as well as on the technology infrastructure. In addition, the Business

Case lists the constraints associated with the proposed project, along with the estimated

budget, and alignment with priorities established by the business.

2.5.3 Knowledge

In addition to the knowledge required to define and scope the proposed initiative,

Business Case authors need:

• An understanding of accounting practices in order to quantify costs and benefits

that will result through the proposed project that is under consideration.

• Knowledge of how to translate the proposed change into financial terms and

knowing when and how to use financial projection techniques described in this

section is also needed.

• Knowledge of the organizational strategy and goals, the relevant business

processes and the supporting technical infrastructure is required.

• Financial analysis to forecast the economic impacts of the proposed new project;

it may be necessary to enlist the assistance of financial analysis experts to support

this activity.

2.5.4 Skills

The Business Analyst typically leads the effort to construct the business case, in

collaboration with other subject matter experts. In addition to the skills mentioned in the

previous section to scope and defining the proposed initiative, the following skills are

required:

• Financial analysis

• Financial profit projection models

• Use of technology tools to represent the benefits and costs.

2.5.5 Predecessors

Predecessor activities to preparing the Business Case for the new opportunity include:

• Strategic planning and goal setting

• Business architecture framework

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Business opportunity and/or problem definition

• Feasibility studies

• Proposed project scope definition.

2.5.6 Process and Elements

The information gleaned from the preceding Enterprise Analysis activities serve as critical

input to Business Case development. To develop the business case, the following steps are

involved:

• Identify and Quantify the Benefits

• Identify and Quantify the Costs

• Prepare the Business Case

• Determine the Measurement Process for the Costs and Benefits.

.1 Identify and Quantify the Benefits

Measure the benefits of the recommended solution in terms of both qualitative and

quantitative gains to the enterprises. Where possible, benefits should be quantified,

however, benefits of a non-financial nature are also identified. Ideally, benefit estimates

should relate back to strategic goals and elements of the balanced scorecard.

.2 Identify and Quantify the Costs

Estimate the total net cost of the solution. This requires estimates to be made of capital

expenditures for the new investment, costs of developing and implementing the change,

opportunity costs of not investing in other options, costs related to changing the work and

practices of the organization, total cost of ownership to support the new solution and

consequential costs borne by others.

It is a difficult endeavor to prepare cost estimates for IT projects during pre-project

Enterprise Analysis activities, when only very high level planning and requirements

definition has occurred. Since the decision is made to invest in projects at this early point,

there is a strong desire on the part of senior management to have cost estimates fixed at

this point in time. The desire for fixed cost estimates, however, is not supported by the

reality of most IT projects. By their nature, IT projects have a higher level of uncertainty,

and require a greater investment in defining the solution before costs and benefits can be

articulated with a high level of confidence. At this point, the accuracy of the cost estimates

is used to help confirm the viability of the proposed new project.

.3 Prepare the Business Case

Develop the Business Case at the level of detail sufficient to demonstrate project viability

and secure a go/no go decision for the initiative.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.4 Determine the Measurement Process for Costs and Benefits

Underlying many of the problems associated with both the development and the

realization of Business Case projections is an immature measurement culture within the

organizations today. The Business Case should articulate not just the benefits that will be

realized, but how those benefits will be assessed and evaluated. The Business Case may

also include a plan for benefit measurement and reporting, including where realignment

of internal measures or systems is needed to ensure that the behaviors we are seeking can

be seen, evaluated, and realized.

The business defines assumptions regarding how benefits will be apportioned;

particularly in situations (increased revenue being the most common) where a change in

what is being measured cannot always be fully attributed to one project alone. The

resulting measurement approach is accepted as part of the Business Case approval along

with the actual cost and benefit projections.

2.5.7 Stakeholders

Key stakeholders who are involved in or impacted by the Business Case include:

• Business executive sponsor of the proposed project. The executive sponsor will

likely use the Business Case to present the new project proposal to the portfolio

management team for a decision to further invest in the project.

• Business process owner(s) and business process subject matter experts for the

business area to be changed. The business process experts likely assist in

estimating business benefits expected from the new initiative.

• IT manager who is supporting the business area. The IT representative likely

established cost projections for the technology needed to support the new

solution.

• Senior project managers (PM). The PM assists the Business Analyst in

establishing initial cost and time estimates.

• The portfolio management team, aka, project investment governance group. This

committee comprised of senior executives reviews the Business Case information

and determine whether to invest in the proposed new initiative.

2.5.8 Deliverables

The deliverable from this effort is the Business Case document. The Business Case will

incorporate a summary of the findings from a number of the other documents and

reference other documents, models and charts that have been produced to date relevant

to the opportunity.

Organizational standards typically dictate the contents and format of the Business Case

document. Ultimately, the final deliverable presents the information necessary to support

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

a go/no go decision to invest and move forward with a project. A sample Business Case

table of contents would contain the following elements:

1. Executive Summary

2. Introduction And Summary

a. Project Rationale For Preferred Option

b. Current Business Process

c. Description Of The Problem

d. Opportunity

e. Project Objectives

f. Project Scope

g. Business Benefits

h. Project Costs

i. Assumptions

j. Potential Business And Staff Impact Analysis

k. Potential Technology Impact Analysis

l. Other Issues

m. Implementation Plan

3. Approach

a. Financial Metrics

b. Privacy Impact Assessment

c. Alternative Evaluation Criterion

4. Key Selection Criterion

a. Weighting

b. Constraints And Limitations

5. Preferred Alternative (Insert Title)

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

a. Business Benefits

b. Alternative Costs

c. Assumptions

d. Potential Business And Staff Impact Analysis

e. Other Issues

6. Risk Management Plan

a. Risk Assessment

b. Risk Response

c. Benefit Realization

7. Conclusion and Recommendations.

2.5.9 Techniques

Many techniques are used to develop a Business Case for proposed project, including

both qualitative business benefit analysis and quantitative financial profit/profitability

models. Several of these techniques are described below.

.1 Strengths, Weaknesses, Opportunities and Threats (SWOT) Analysis

The SWOT analysis demonstrates how the organization will maximize strengths and

minimize weaknesses relevant to the proposed solution. It includes a discussion of the

opportunities now possible because of the solution. It is also a means to identify,

minimize and prevent threats to the organization that may be caused by the solution.

.2 Financial Valuation

Financial valuation techniques include

• Discounted Cash Flow

• Net Present value

• Internal Rate of Return

• Average Rate of Return

• Pay Back Period

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.3 Cost-Benefit Analysis

Cost/Benefit Analysis seeks to compare the costs of implementing a solution against the

benefits gained from it. This technique is effective when both the costs and the benefits

can be quantified.

.4 Activity Based Costing

Activity Based Costing (ABC) is a technique that measures the development and

performance cost of activities, resources, and items. ABC identifies opportunities to

improve business process effectiveness and efficiency by determining the "true" cost of a

product or service. ABC focuses attention on the total cost of ownership, including the

cost to produce a product or service, operate it during its life, and the ability to recover

the cost.

2.6 Conducting the Initial Risk Assessment

2.6.1 Purpose

The purpose of the initial risk assessment is to determine if the proposed project carries

more risk than the organization is willing to bear.

2.6.2 Description

Project risk is an uncertain event or condition that, if it occurs, has a positive or negative

effect on at least one project objective, such as time, cost, scope, or quality (PMBOK

Guide Third Edition). Project risk management includes the processes concerned with

conducting risk management planning, identification, analysis, responses, and

monitoring and control on a project. The initial risk assessment is performed as a

component of Enterprise Analysis activities. Most of the risk management processes are

updated throughout the project. Since this is a project management practice, the Business

Analyst typically enlists the assistance of a senior project manager to perform the risk

assessment.

2.6.3 Knowledge

To perform risk assessment, the Business Analyst enlists the assistance of an experienced

project manager and other members of the study team who possess an understanding of:

• Risk management principles and concepts

• Financial analysis and profit projection models

• Business enterprise structure, operations, skill sets, etc.

• Organizational readiness for the change initiative

• Technical feasibility of the proposed solution, both to build and to operate and

maintain the technology.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

2.6.4 Skills

Skills required to conduct the initial risk assessment include:

• Facilitation

• Risk identification

• Risk probability and impact assessment

• Overall risk rating development.

2.6.5 Predecessors

Predecessor activities to conducting the initial risk assessment include all Enterprise

Analysis activities performed to date.

2.6.6 Process and Elements

The process steps to conduct the initial risk assessment include:

• Identifying project risks

• Assessing risk probability and impact

• Planning risk responses

• Assessing organizational readiness and calculating an overall risk rating.

.1 Identify Risks

Identifying project risks involves the following activities:

• Identifying and analyzing business risks

• Identifying and analyzing financial risks

• Identifying and analyzing technical risks.

.2 Assess Risks

Assessing risks involves analyzing the probability of the risk occurring, and the impact if

the risk does occur.

.3 Plan Risk Responses

For high probability/high impact risks, identifying risk mitigation strategy and

contingency response plans. Assess the cost of each risk response plan and add these costs

to the overall initiative cost estimates.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.4 Assess Organizational Readiness

Assess the overall organizational readiness for the magnitude of the change embodied in

the proposed new project.

• Quantify change management risk, impacts and response plans

• Describe and quantify the risk to the organization of doing nothing

• Calculate an overall risk rating for the proposed initiative in terms of costs, time,

and quality of the business operations.

2.6.7 Stakeholders

Key stakeholders who are involved in or impacted by the risk assessment include:

• Business executive sponsor of the proposed project. The executive sponsor will

likely present the new project proposal with the Business Case and the risk rating

to the portfolio management team for a decision to further invest in the project.

• Business process owner(s) and business process subject matter experts for the

business area to be changed. The business process experts assist in analyzing risks

to achieving the business benefits expected from the new initiative.

• IT manager who is supporting the business area. The IT representative assist in

analyzing technology risks, and risks to cost projections for the technology

needed to support the new solution.

• Senior project managers (PM). The PM assists the Business Analyst in

establishing risk estimates.

• The portfolio management team, aka, project investment governance group. This

committee comprised of senior executives will review the Business Case and

initial risk assessment information and determine whether to invest in the

proposed new initiative.

2.6.8 Deliverables

The deliverable from this effort is the initial Risk Rating for the proposed initiative and the

nature and cost of the risk response plan. This information is typically added to the

Business Case document.

2.6.9 Techniques

Techniques to determine the initial risk rating include standard project risk management

methods, such as risk probability and impact assessment and overall risk rating analysis.

In addition, techniques to help identify potential risks include information gathering

techniques, such as:

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Brainstorming

• Interviewing

• Root cause identification

• SWOT analysis.

2.7 Preparing the Decision Package

2.7.1 Purpose

The purpose of this activity is to provide an actionable set of information regarding the

proposed new project to the organizational decision makers. The business sponsor of the

proposed initiative is typically the individual who proposes the proposed new project to

the governance group for them to select and prioritize the portfolio of projects for the

enterprise. The Business Analyst plays a major role in compiling all of the information

gathered during the Enterprise Analysis activities.

The proposal documentation includes or references all information gathered about the

proposed project to date. In addition, the proposal identifies and justifies the next steps in

the overall process to continue with the proposed new project opportunity, including

approval of funding for the next major phase of the project and appointing a project

manager and core project team to proceed with project initiation, planning and

requirements development.

2.7.2 Description

This activity compiles the documents and summarizes all relative information about the

proposed project.

2.7.3 Knowledge

This activity requires knowledge in the following areas:

• Portfolio management

• Project selection and prioritization.

2.7.4 Skills

Skills required to prepare the project proposal documentation set include:

• Written communication skills

• Executive briefing preparation skills.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

2.7.5 Predecessors

Predecessor activities to conducting the initial risk assessment include all Enterprise

Analysis activities performed to date.

2.7.6 Process and Elements

The Business Analyst compiles all relevant information from the Enterprise Analysis

activities. In addition, an executive presentation is prepared summarizing the proposed

project and recommendations.

2.7.7 Stakeholders

Key stakeholders who are involved in or impacted by the project proposal include:

• Business executive sponsor of the proposed project. The executive sponsor will

likely present the new project proposal to the portfolio management team for a

decision to further invest in the project.

• The portfolio management team, aka, project investment governance group. This

committee comprises of senior executives will review the project proposal

information and determine whether to invest in the proposed new initiative.

2.7.8 Deliverables

Deliverables from this effort include:

• The Business Case and supporting Enterprise Analysis reports

• Executive Briefing.

2.7.9 Techniques

Techniques used to prepare the decision package include:

• Executive-level communication techniques

• Data representation techniques.

2.8 Selecting and Prioritizing Projects

After the decision package is complete, it is used by the sponsor of the proposed project

to present the proposal to the portfolio management governance group. As the individual

who possesses the most knowledge about the opportunity, the Business Analyst often

supports the sponsor when presenting the project proposal information.

The portfolio management process enables the organization to select the right investment

path from the mix of potential opportunities including (1) research initiatives, (2) new

product development activities, (3) information technology enhancements, (4) internal

business improvement projects, and (5) new business endeavors. Through enterprise

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

portfolio management, the organization is positioned to allocate scarce corporate assets

in priority order to ensure projects have the necessary resources to achieve their strategic

goals.

Portfolio planning and management groups usually follow a structured decision-making

methodology for selecting the portfolio of valuable projects. Since all project proposals

cannot be funded, selecting projects requires a framework consisting of a predetermined,

structured, defined decision-making process. The Business Analyst not only plays a vital

role in preparing the project proposal information as input to the portfolio management

process, but also is involved in continually improving the process for project selection

and prioritization process. As we have seen, the Business Analyst uses sophisticated

opportunity assessment and documentation techniques to prepare the information

presented to management so that they can make informed project selection decisions.

To ensure they invest in the most valuable projects, executives and key stakeholders are

required to evaluate potential change initiatives that will enable their organization to

reach their strategic business objectives. To select and prioritize the best change

initiatives, executives need information largely provided through the efforts of the

Business Analyst. The critical information will allow them to:

• Clearly understand the business problem or opportunity and the impacts of the

proposed project to the enterprise and to specific business units.

• Consider the options and the relevant costs and benefits of each alternative

opportunity.

• Understand the organization’s project resource capacity and expertise to deliver a

quality business solution.

• Prioritize and establish a means to measure progress to ultimately deliver the

expected business value.

• Provide guidance for formulation of the adopted course of action and project

related direction in terms of goals and constraints.

• Participate in project reviews for ongoing management oversight.

• Ensure delivery of expected results and value added to the enterprise.

2.9 Launching New Projects

Once a project has been approved, a project charter is prepared and a project manager is

assigned. The Business Analyst collaborates with the project manager throughout the

project initiation and planning process. It is at this point that the Business Analyst will

begin to plan the requirements elicitation, analysis and documentation activities.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

2.10 Managing Projects for Value

Once projects are funded, they must be managed throughout the project life cycle to

ensure that the Business Case remains valid and continued investment in the project is still

warranted. The Business Analyst plays a critical role in the project control gate review

process.

Typically, management reviews of ongoing projects are held at key project milestones to

re-validate the business case, review current estimates of cost and time, validate or refine

the project priority, and make a go/no go decision about funding the project for the next

phase. At key milestones the Business Analyst partners with the project manager, business

representative(s), and the lead architects and developers to update the project plans,

current cost/schedule estimates, the risk assessment and the business case. Once these

documents have been updated, the core team arrives at a consensus recommendation to

management regarding continued investment in the project. The Business Analyst will

often attend the management review meetings and help present the current status of the

project and the recommendation for future funding.

2.11 Tracking Project Benefits

Once projects solutions are implemented, the project team is usually disbanded and

reassigned to new projects. However, the process is incomplete unless the organization

measures the return on project investments (ROI). The Business Analyst plays a vital role

in ensuring the metrics and measurements are in place to track project ROI, often several

months or years after project completion.

Ideally, the measures of success were identified during the pre-project business planning

activities and documented in the business case. To track and analyze the ROI, the data

collection process must be delivered as part of the business solution (if it does not already

exist). The Business Analyst then reviews the data, tracks trends, and reports to the project

sponsor and portfolio management team on actual project ROI. It is through this process

that the portfolio management team can determine how valuable the project was to the

enterprise. If the ROI is not realized, one or more strategic goals or objectives may not

have been met, or may have been met only partially. In order to continuously improve

the project selection and execution process, the organization should conduct a root-

cause analysis to determine what circumstances prohibited the project outcomes from

delivering the expected value to the organization.

2.12 References

Ambler, S. (n.d.). Agile analysis. Retrieved Apr. 08, 2005, from Ambysoft Web site:

http://www.agilemodeling.com/essays/agileAnalysis.htm.

Ambler, S. (n.d.). When does(n't) agile modeling make sense? Retrieved Apr. 08, 2005,

from Ambysoft Web site:

http://www.agilemodeling.com/essays/whenDoesAMWork.htm.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Bechtold, R. (1999). Essentials of software project management. Vienna, VA:

Management Concepts.

The Carnegie Mellon University, Software Engineering Institute, The Capability Maturity

Model, (1994) Addison Wesley Longman, Inc.

Dye, Lowell D. and Pennypacker, James S. (1999) Project Portfolio Management,

Selecting and Prioritizing Projects for Competitive Advantage. Pennsylvania: Center for

Business Practices.

Dymond, K.M., A Guide to the CMM, (1995) Process, Inc., Annapolis, MD.

Fowler, M. (2003). The new methodology. Retrieved Apr. 08, 2005, from

martinfowler.com Web site:

http://www.martinfowler.com/articles/newMethodology.html.

Hadden, R. (2003). Leading culture change in your software organization. Vienna, VA:

Management Concepts.

Hass, Kathleen B. (2006) Business Analyst as Strategest. Vienna, VA: Management

Concepts

Intervista Institute, Inc. (2003). Managing Integration in a Federated Architecture

Environment, http://www.intervista-institute.com/articles/zachman-by-kull.html,

http://www.intervista-institute.com/articles/zachman-by-kull.htm

Jalote, Pankaj, CMM in Practice, (2000) Addison Wesley Longman, Inc., Reading, MA

Goodpasture, John C. (2002) Managing Projects for Value. Vienna, VA: Management

Concepts, Inc.

Kaplan, R. and Norton, D. (1996) The Balanced Scorecard: Translating a Strategy into

Action. Boston: Harvard Business School Press

Mooz, H., Forsberg, K., & Cotterman, H. (2003). Communicating project management:

the integrated vocabulary of project management and systems engineering. Hoboken, NJ:

John Wiley and Sons.

OSD Comptroller iCenter,

http://www.dod.mil/comptroller/icenter/learn/abcosting.htm

Project Management Institute, Inc. (2004) A Guide to the Project Management Body of

Knowledge, Third Edition, Newtown Square, PA.

Rad, Parviz F. and Levin, Ginger, Advanced Project Management Office, (2002) CRC

Press LLC, Boca Raton, FL.

Chapter 2 Enterprise Analysis

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Sodhi, J., & Sodhi, P. (2003). Managing IT systems requirements. Vienna, VA:

Management Concepts.

Sodhi, J., & Sodhi, P. (2001). IT project management handbook. Vienna, VA:

Management Concepts.

The Standish Group, (1999). Unfinished voyages: a follow-up to the chaos report.

Retrieved Apr. 08, 2005, from The Standish Group Web site:

http://www.standishgroup.com/sample_research/unfinished_voyages_1.php.

Scholtes, Peter R., The Team Handbook, How to Use Teams to Improve Quality, (1988)

Joiner Associates, Inc., Madison, WI.

Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems engineering: coping with

complexity. Indianapolis, IN: Pearson Education, Prentice Hall PTR.

Wiegers, K. (2003). Software requirements: practical techniques for gathering and

managing requirements throughout the product development cycle. 2nd ed. Redmond,

WA: Microsoft Press.

Young, R. (2001). Effective requirements practices. Addison-Wesley information

technology series. Boston: Addison-Wesley.

http://www.research.ibm.com/journal/sj/381/mcdavid.html

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Chapter 3: Requirements Planning and Management

3.1 Introduction

3.1.1 Knowledge Area Definition

The Requirements Planning and Management Knowledge Area defines the resources and

tasks associated with the planning and management of requirements gathering activities

throughout the requirements process. The Business Analyst must define the requirements

activities that will be performed and how the requirements activities will be performed on

a project, in accordance with any existing standards in the organization. It includes

identifying key roles, selecting requirements activities, managing the requirements scope

and ongoing communication of the requirements gathering status. Proper planning and

management of requirements gathering activities ensures the success of the requirements

process and requirements deliverables.

The Business Analyst must select which stakeholders, tasks, and communication tools

will most effectively provide the Business Analyst with the needed requirements

deliverables. For example, the Business Analyst must determine if the company CIO is a

stakeholder and if so, decide how best to gather requirements information from this

individual, merge this information with requirements gathered from other stakeholders,

and communicate all stakeholders’ requirements in an effective format.

3.1.2 Rationale for Inclusion

The rationale for including this knowledge area is that the project manager and the rest of

the project team are relying on the Business Analyst to provide clearly defined

requirements deliverables for the project. To provide this in a timely and efficient

manner, the Business Analyst needs to develop, define, and manage the roles and tasks

associated with requirements gathering, in coordination with the project manager.

• Proper planning and managing of requirements on a project ensures that;

• All necessary stakeholders are identified and properly represented during the

requirements gathering process.

• The most appropriate activities related to the requirements process are performed,

given the project circumstances.

• The requirements work effort is coordinated with other work done on the project.

• The requirements team has a common understanding of the activities they will

perform.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• The BA or BA team can effectively monitor and react to requirements challenges and

slippage.

• The tools, resources, and requirements contributors are available when

requirements activities are scheduled.

• Changes are captured correctly and consistently.

3.1.3 Knowledge Area Tasks

This Knowledge Area includes ten tasks that the Business Analyst will define and manage

through the requirements gathering process.

3.1.4 Relationship to other Knowledge Areas

.1 Inputs

• Business environment analysis from KA Enterprise Analysis

• Enterprise requirements scope from KA Enterprise Analysis

• Feasibility assessment from KA Enterprise Analysis

.2 Outputs

• List of project team members assigned to the project and team member roles

• List of stakeholders and their relationship to the project

• List of requirements gathering tasks and division of work

• Tool(s) used to gather and communicate requirements

3.2 Understand Team Roles for the Project

The Business Analyst should identify, understand and document all needed team roles in

the entire spectrum of requirements related activities for each of their projects in order to

insure that these activities are completed in the most effective and efficient manner

possible. It is important to the success of the project that all people involved understand

their role(s) and responsibilities. For example, it is likely that the Business Analyst may

decide to communicate in different ways using different methods to the different roles.

I.e. formal presentations to the Executive Sponsor and Project Manager while using

emails and memos to the project team members.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

During this activity, the Business Analyst must work closely with the Project Manager in

identifying, understanding and documenting team roles and responsibilities for the entire

spectrum of requirements life cycle activities. The Business Analyst will be involved in all

requirements related activities and roles while the PM is naturally concerned with all

project activities.

3.2.1 TASK: Identify and Document Team Roles for the Project

.1 Purpose

The purpose of this task is to identify and document all team roles relating to and involved

with the requirements related project activities. It should also provide an understanding

of certain team roles on a project and how each of these roles may contribute to the

process of requirements definition and management. It is important for the Business

Analyst to understand the difference between a role and a job title. Different

organizations will certainly have varied job position titles involved in their projects. The

roles that are discussed in this section may be titled very differently in different

organizations, so the Business Analyst must take this into account when reading this

section and especially when executing these tasks in their project.

Some of the roles shown below, as well as other roles that may be defined by an

organization, may or may not exist in any particular project. Project requirement

responsibilities may also be divided differently among different roles. Some of the roles

may exist only as needed at specific points of the project, while others may be in existence

throughout the entire project. Depending on the project and the organization, many of

these roles may be filled by a single individual or perhaps by multiple individuals.

.2 Description

This task will enable the Business Analyst to identify and document the necessary team

roles on their project. This will enable the Business Analyst to insure that all of these roles

are filled and that their responsibilities are assigned to someone.

.3 Predecessors

Inputs to this task will include the current project plan and other initial project

documents as may be available such as the project charter. Any available project

standards documents may also prove useful in identifying required requirements

planning and management roles. PLC and SDLC standards, if available, will also be used

in this task.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.4 Process and Elements

Project team roles should be identified early in the project to help ensure timely delivery

of project deliverables. Some individuals may be called on to play a variety of roles on

different projects and occasionally even on the same project.

Many organizations may have standards applicable to defining team roles. For example,

many PLC’s will define roles and responsibilities of project roles.

Typical Team Roles may include, but not be limited to the following:

• Executive Sponsor – The executive sponsor has overall responsibility for the project

at the management level including funding, go/no go decision making and providing

resource support. Often the executive sponsor also will function as the project

“champion” within the organisation. (also see Solution Owner)

• Business Analyst – The business analyst elicits, analyses, documents and reviews the

requirements for accuracy and presents them to project stakeholders for review and

approval.

• Project Manager - The project manager manages the day-to-day activities of the

project ensuring that requirement related tasks are delivered on time, within budget,

and within scope. The project manager must ensure that proper stakeholder approval

of the requirements is obtained before progressing forward with project delivery.

• Developer – Developers are the technical resources assigned to a project, and may

include many technical roles within a project team, e.g. The Technical Lead oversees

the design, code, and test activities for the technical members of the project team.

Developers also plan the application's transition to the user community, often

working directly with the business analyst and trainers.

• Quality Assurance Analyst – The quality assurance analyst is responsible for

ensuring that quality standards are adhered to by the project team.

• Trainer - The trainer is responsible for developing user training curriculum materials

and delivering training to end-user personnel. These materials are based on the

functional requirements.

• Application Architect - The application architect defines the architectural approach

and high-level design for a project solution. The application architect is responsible

for determining the technical direction of the project and the overall structure of the

solution.

• Data Modeler – (See Information Architect)

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Database Analyst (DBA) - The database analyst is responsible for all technical

aspects related to designing, creating and maintaining project databases.

• Infrastructure Analyst - The infrastructure analyst designs the overall hardware and

software infrastructure and environment needed to meet the application

development and operational requirements.

• Information Architect - The information architect is responsible for assessing the

overall data requirements of an information system project. Information architects

identify reusable data assets and resolve enterprise data modeling issues.

• Solution Owner - The solution owner is responsible for defining and approving the

project scope and ensuring that it aligns with the business strategy. Approving project

scope changes and defining the project success criteria and measurement are also

part of the responsibility of the solution owner. (see also Executive Sponsor).

• End User – The end user represents the group of people in the organisation (and

often external to it also) who will actually interact directly with the software

application.

• Subject Matter Expert (SME) – The subject matter expert (SME) provides expertise

in a particular business functional area. SME responsibilities are closely tied to

defining, approving and using the functional requirements for the project. SMEs

typically work very closely with business analysts in identifying and managing the

requirements.

• Stakeholders - Stakeholders represent anyone materially affected by the outcome of

the project. Stakeholders are often a prime source of information when planning and

managing requirements.

.5 Stakeholders

Stakeholders who should play a part in this task include all project stakeholders since any

of these may conceivably have a distinct team role to play in the project. A key input to the

task for the Business Analyst will be the Stakeholder List created in Section X.X.

.6 Deliverables

The deliverables from this task will typically be a revised/updated business analysis

requirements planning and management plan as well as a descriptive list of all of the

currently identified team roles for this specific project.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

3.2.2 TASK: Identify and Document Team Role Responsibilities

Each of the roles defined in the above task may share responsibility in the activities related

to requirements. Some of these responsibilities may overlap and must be clearly defined

and managed on each project.

.1 Purpose

The purpose of this task is to identify, document and achieve agreement on the specific

project responsibilities for all requirements related tasks for those roles identified in the

previous task.

.2 Description

This task will enable the Business Analyst to identify and document the responsibilities

for each of the team roles identified in the previous task. This will enable the Business

Analyst to insure that all of the responsibilities have been assigned to someone.

.3 Predecessors

The primary input to this task will be the list of roles identified in the previous task.

PLC and SDLC standards, if available, will also be used in this task.

.4 Process and Elements

Project team role responsibilities should be identified early in the project to help ensure

timely delivery of project deliverables. The Business Analyst must identify and document

his/her understanding of the specific responsibilities for each of the roles identified in the

previous task. Much of these responsibilities will not vary from project to project and

should prove to be relatively straightforward for the Business Analyst to document. Some

projects may however require more effort to identify and achieve agreement on the

responsibilities for each role because of the nature and objectives of the project itself. It

must be recognised by the Business Analyst that this task is only concerned with the

Requirements planning and Management activities in the project.

A list of typical responsibilities for the roles that were identified in the previous task are

listed below. These would be expected to be modified by the Business Analyst to better

suit their organization and project.

Some common responsibilities for these roles are shown below.

• Executive Sponsor – The ultimate “approver” of the requirements and their

management process. (also see Solution Owner)

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Business Analyst – The business analyst identifies, documents and manages the

requirements, manages the requirements modification process, and presents the

requirements for review and approval.

• Project Manager - The project manager must deal with requirements through

managing the project tasks that are involved in their creation, approval, management,

and ultimately, their fulfilment.

• Developer – Developers are involved in the requirements review, sign-off and

approval discussions with the Business Analyst and others on the project team. They

must have a complete understanding of the requirements in order to insure that the

application meets all of them.

• Quality Assurance Analyst – The quality assurance analyst should be involved in

requirements review and approval. Their review of the requirements will often result

in clearer, more testable and better defined requirements. Their major project task is

to ensure that the final product meets all user requirements.

• Trainer - The trainer uses the functional requirements in developing training

curriculum materials. They may also be involved with the review and approval of the

requirements .

• Application Architect - The application architect uses the requirements to insure

that the architectural approach and high-level design will allow the application to

meet them. They should also review requirements to insure completeness and

suitability to accomplish overall application product goals.

• Data Modeler – (See Information Architect)

• Database Analyst (DBA) - The database analyst is responsible for designing and

creating databases that will meet the performance and data requirements of the

project. They should also be involved in the review of this area of the requirements.

• Infrastructure Analyst - The infrastructure analyst uses the requirements in their

design of the infrastructure needs and should be involved in the review and approval

process.

• Information Architect - The information architecture is responsible for identifying

data requirements and should be heavily involved in their review and approval. They

should also be empowered to assist in the review of these requirements.

• Solution Owner – The solution owner provides information when gathering

requirements and often is directly involved in the approval of the final functional

requirements. (see Executive Sponsor also).

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• End User – The end user is often a source of information used in creating the

requirements and certainly is impacted by their quality and completeness.

• Subject Matter Expert (SME) – The SME will be a major source of requirements

information and must also be heavily involved in their review and approval.

• Stakeholders – The responsibilities of stakeholders varies greatly depending on the

type and level of stakeholder, but often involve providing information when

gathering requirements as well as reviewing and approving final requirements.

Definition of a Stakeholder

A ‘Stakeholder’ is defined as person or group that has a stake or interest in the success of a

project. Stakeholders are also important sources for project requirements and can be

responsible for one or more project activities or deliverables. A stakeholder can impose

constraints or boundaries on the project like time, money, and resources. These

constraints are part of the ‘stake’ or investment that the stakeholder makes in the project.

The stakeholder is may be a decision maker or influencer on the solutions and success of

the project. Stakeholders can also be the primary benefactor of the project, because the

completion of the project will affect the efficiency, quality, or financial success of their

department or company. A stakeholder can be a person, group, organization,

department, corporation or governmental entity. If the stakeholder is an organization or

group, the Business Analyst should understand who (a specific individual or individuals)

will communicate the group’s interests and needs.

It should also be noted that a stakeholder may not directly participate in the project, but a

representative of the stakeholder’s interests may be included. If a stakeholder’s

representative is included in the project, the Business Analyst should clearly understand

the level of decision making authority and expertise the representative brings to the

project.

The RACI Matrix

The RACI matrix is a powerful tool useful to illustrate usual responsibilities of the roles

involved in planning and managing requirements. Note that the chart below has been

completed only for Requirements Planning and Management, but the RACI approach is

also very useful for documenting roles and responsibilities in any project activity area.

The table illustrated below may be broken down into further levels of task detail by the

Business Analyst to provide further assistance in identifying roles and responsibilities

during requirements planning and management.

[R]esponsible does the work,

[A]ccountable is the decision maker (only one)

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

[C]onsulted must be consulted prior to the work and gives input

[I]nformed is on a need to know basis after the work is done

An example of documenting overall high level responsibilities may be seen below:

Role in Requirements Planning and Management

RACI

Executive Sponsor

Business Analyst

Project Manager

Developer

Quality Assurance Analyst

Trainer

Application Architect

Data Modeller (See Information Architect)

Database Analyst (DBA)

Infrastructure Analyst

Business Architect

Information Architect

Solution Owner (See Executive Sponsor)

End user

Subject Matter Expert (SME)

Other Stakeholders

R, C, I (varies)

.5 Stakeholders

Stakeholders for this task are the same as for the previous task.

.6 Deliverables

The deliverable from this task will typically be a descriptive list of all team roles from the

previous task with clearly defined responsibilities listed for all. It should also be a

responsibility of the Business Analyst to achieve consensus and agreement on this list.

3.2.3 Task: Identify Stakeholders

.1 Purpose

Project stakeholders are the driving force behind each project, because the project goal is

to design, create and implement solutions to fulfill one or more stakeholder needs.

Understanding who the stakeholders are and their ‘stake’ in the project is vital to

understanding what needs must be satisfied to successfully complete the project.

Identifying the project stakeholders at the beginning of the project is an important step

that should not be overlooked or minimized. Stakeholders or stakeholder interests that

are not identified until latter stages of the project can have a negative affect on all areas of

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

the project, including the cost, delivery, scope, and resource needs. Because project

requirements are based on stakeholder needs, stakeholders and stakeholder needs that

are identified late in the project could require a revision to requirements that will change

or nullify completed tasks or tasks already in progress.

Stakeholders identified in latter stages of a project may also be reluctant to participate or

may bring an adversarial presence into the project. A stakeholder added to the project

after the initial may also bring to light gaps in the project scope, requiring a complete

project review and re-scope.

.2 Description

The Business Analyst will create a list of all stakeholders associated with the project. If a

stakeholder is not an individual, the listing should note the person or persons who will

speak for the stakeholder group. If a stakeholder sends a representative, the Business

Analyst should note the representative and which stakeholder is represented. The listing

should include the persons name, their job title or job description, and some basic

demographics (address, phone number, email, etc.).

.3 Predecessors

To identify the project stakeholders, the BA will need a list of project team members, a

description of project team member roles and duties within the project, the Enterprise

Analysis document(s) described in chapter 2, the organizational chart of the company or

customer, and documentation on any existing processes or systems affected by the

project. Also, the project charter, project scope, or any other documentation on existing

systems or processes.

.4 Process

The Business Analyst will create a listing of project stakeholders using the documents and

artefacts defined in section 3.3.2.3 above.

.5 Alternatives

N/A

.6 Key Features

N/A

.7 Strengths and Weaknesses

N/A

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

3.2.4 Technique: Consult reference materials

.1 Purpose

This technique will use existing project reference materials to identify people associated

with the project and determine if they are project stakeholders. These reference materials

include the documents noted in section 3.3.2.3.

.2 Description

The Business Analyst will use the existing project documents and artefacts to develop a

listing of possible stakeholders. This listing will be reviewed by project management to

identify the project stakeholders.

.3 Intended Audience

N/A

.4 Process

The Business Analyst should review existing project reference materials and create a

listing of all potential resources and known stakeholders noted in these materials. This

listing should note all information pertaining to the resource.

This listing should be reviewed with the project sponsor or sponsor’s representative and

project manager. The Business Analyst, Project Sponsor or representative, and Project

Manager will identify and agree on the Stakeholders for the project.

The Business Analyst will create a Stakeholder Listing of all stakeholders identified and

agreed to.

For each stakeholder on the list, the Business Analyst will update the listing with the

stakeholder’s name and contact details. An example of the stakeholder listing is shown

below.

Sta keh older listin g

Name

Job Title or Job

Description

Organization

Address

Phone

Stakeholder

Project Manager

ABC Company

Address line 1

Address line 2

City,

State/Province,

Country

9.9.999.999.9999

stakeholder1@abc.com

Stakeholder

Executive Sponsor

ABC Company

Address line 1

Address line 2

City,

9.9.999.999.9999

stakeholder2@abc.com

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Sta keh older listin g

State/Province,

Country

Stake

holder 3

Business Analyst

ABC Company

Address line 1

Address line 2

City,

State/Province,

Country

9.9.999.999.9999

stakeholder3@abc.com

.5 Key Features

N/A

.6 Alternatives

N/A

.7 Strengths and Weaknesses

The skills required to perform this task are minimal and do not require special technical

support or training. But, the reference materials may not be up to date or complete and

will require some additional time and research to determine whether the person or entity

is a stakeholder.

3.2.5 Technique: Questionnaire to identified stakeholders

.1 Purpose

A questionnaire to identified stakeholders will determine, based on the questionnaire

responses, if any additional stakeholders exist that were not mentioned in the reference

materials. These stakeholders should be added to the stakeholder listing noted above in

section 3.3.3.4.

.2 Description

A questionnaire is a group of questions posed to elicit a valued response. The

questionnaire is distributed to the stakeholder list and responses are recorded. The

responses to the questionnaire should either identify possible additional stakeholders or

confirm that all stakeholders have been identified. Stakeholders from the Stakeholder List

in section 3.3.3.4 may also be helpful in identifying other as yet unidentified stakeholders.

The Business Analyst can prepare and distribute a brief questionnaire to existing

stakeholders to determine if there are additional unidentified stakeholders.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.3 Intended Audience

The intended audience is the stakeholder listing developed in section 3.3.3.4.

.4 Process

The Business Analyst will prepare a listing of questions intended to identify additional

stakeholders. Questions should be open ended and require more than a Yes or No

response. Examples of the types of questions that can uncover additional stakeholders

are:

• Who is initiating the change that will result from the project?

• Who owns the problem(s) to be solved or goals to be achieved by the project?

• Who is directly impacted by the project?

• What are their roles?

• Who executes activities in the immediate business process affected by the project?

The questionnaire is sent to each stakeholder with an explanation of the purpose of the

questionnaire and the deadline for responding.

When the responses are returned to the Business Analyst, any person or entity mentioned

in the responses from stakeholders should be reviewed with the Project Sponsor or

representative and Project Manager. The Business Analyst, Project Sponsor or

representative, and Project Manager will identify and agree on any additions to the

Stakeholder List.

.5 Alternatives

Interview - The Business Analyst may choose to contact each stakeholder directly to pose

each question and record each response.

Web Survey – The Business Analyst may contact each stakeholder and direct them to an

internet site specializing in managing surveys and questionnaires where they can view the

questionnaire and enter their responses. When the responses have been recorded, the

Business Analyst can review the complete listing and review the listing with the Project

Sponsor and Project Manager.

.6 Key Features

This technique requires special effort and skill from the Business Analyst to prepare

questions that elicit the desired response.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.7 Strengths and Weaknesses

Questionnaire responses can identify stakeholders that have not been documented. But,

Questionnaires require time to develop the right questions, distribute the questionnaire,

and review the responses. If the project has a limited timetable, the Business Analyst may

not have the time necessary to take advantage of this technique. Also, the Business Analyst

may not receive responses from all stakeholders by the deadline or may receive

incomplete responses, requiring a follow-up contact with stakeholders to request clarity

or solicit a more complete response.

3.2.6 Task: Describe the Stakeholders

.1 Purpose

Stakeholder descriptions provide the Business Analyst with information about each

stakeholder that is important to the project.

.2 Description

The Business Analyst will create a description of each stakeholder’s key characteristics

that affect the project.

.3 Predecessors

The Stakeholder listing from section 3.3.5.4 will be used as the primary input document

for this task.

.4 Process and Elements

The Business Analyst will develop questions designed to solicit information from each

stakeholder concerning their role and project responsibilities and authority. These

questions will focus on each stakeholder’s customers and suppliers, job functions,

systems used, number of end users, paper and hard copy processes, and key business

issues. The response to these questions will be summarized and combined with the

Stakeholder listing into a single matrix like the one shown in section 3.3.5.6 below.

.5 Stakeholders

Not applicable

.6 Deliverables

The results of this task will be a stakeholder summary document like the one shown

below. Every stakeholder from the Stakeholder List will be included in this summary and

will include details on their project stake and stakeholder description.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Stakeholder Summary

Name & Job Title

Project Stake

Description

[The name and job title or

description of job duties.]

[The stake or investment of the

stakeholder.]

[Summarize the stakeholder’s key

characteristics with regard to the project.]

Jane Doe - Project Sponsor

Primary end user of project solutions.

Success of the project solutions will

increase the quality and quantity of

output from Jane’s department.

Oversees development of project charter,

vision, scope, and requirements document

preparation. Provides direction and oversight

of requirements gathering.

John Smith – Executive Sponsor

Meeting or exceeding revenue and

expense budgets for the fiscal year.

Ensures that project requirements and

solutions match up with the Enterprise

Analysis.

Bill Young – Project Manager

Implementing a successful solution to

the sponsor’s needs on time and within

budget.

Define and develop project team, define and

manage project timetables and milestones,

define and manage project communications,

oversee project development throughout the

project life cycle.

Amanda Adams – Quality

Assurance

Ensure that all project solutions are

implemented within the company’s

quality standards

Testing development, implementation of

quality controls, review of project quality levels

throughout the project life cycle

3.2.7 Technique: Interview Stakeholders to solicit description

.1 Purpose

An interview of each stakeholder will solicit information used to document the

stakeholder’s involvement, authority, and project impact.

.2 Description

An interview is a discussion between the Business Analyst and the stakeholder to collect

information from the stakeholder their relationship to the project. The stakeholder

description will be created by the Business Analyst from the responses received from each

stakeholder.

.3 Intended Audience

The audience for this technique will be the stakeholders noted in the Stakeholder Listing

from section 3.3.3.4.

.4 Process

The Business Analyst will prepare a listing of questions intended to describe each

stakeholder’s involvement in the project, their authority in the project, and how the

project will impact them. Each question should focus on a specific point of involvement,

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

level of project authority or project impact. Examples of the types of questions that can

describe stakeholders are:

• Who are their customers or suppliers?

• What are their key job functions or duties?

• What are their key business issues?

• How many computer systems do they use?

• How many end users do they represent or manage?

• What are their paper or hard copy based processes affected by this project?

• What are their key business issues?

• Will one or more of their key issues be resolved by the project?

• Are they a change leader or a change recipient?

• What needs to they want to be met by the project?

• Are their needs included or involved in the project?

• Which needs are not included or involved?

• What is the impact of excluding stakeholder’s needs?

• Do any of their needs conflict with other stakeholders? How?

• How will the project change their business processes?

• What business processes do they interface with that are related to the project?

• What are the inputs and outputs to / from their business processes?

• What key issues or roadblocks do they face in this project? (E.g. geographic distance,

cost, technology, etc.)

• How many people in their organization are directly impacted by the project?

• Where are these people located geographically?

• What risks are they exposed to by this project?

• What level of risk are they able to tolerate?

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Have they ever been involved in a similar project?

• What level of success was achieved and were there lessons learned?

• Does the project’s success create any negative impact for the stakeholder?

• What project goals can be eliminate or revised to remove the negative impact?

• Will one or more key business issues be resolved by this project?

• Will the project be successful if it does not remove all negative impact to them? Can

they live with the negative impact?

• What is the importance of each key project success criteria (on time, within budget,

agreed-to scope, and low risk)?

• Do all of their needs have to be met for them to define the project as successful?

• What is the priority for each need? Must this need be met for them to define the

project as a success?

• Will they provide any requirements?

• Will they be a key or secondary source of requirements?

• What is their responsibility in the project (RACI: Responsible / Accountable /

Consulted / Information Only)?

• Who is the key person that has authority to sign off for them? Does this key person

have a backup?

• What is their availability in terms of resource and time? Is this sufficient according to

their project responsibilities? Do they have management backing?

All Stakeholder responses will be recorded by the Business Analyst during the interview.

The Business Analyst will summarize the stakeholder responses into a description for

each stakeholder.

.5 Key Features

This technique requires direct contact with the stakeholder, either face to face, via

telephone, or using technologies such as live video teleconferencing. The Business

Analyst must be proficient in any technologies used to interview stakeholders and record

responses. The Business Analyst must also have experience in developing the necessary

interview questions and experience in the needed listening skills required to interview

stakeholders.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.6 Alternatives

The Business Analyst could use the Questionnaire technique described in section 3.3.5 as

an alternative to interviewing stakeholders.

.7 Strengths and Weaknesses

Interviewing stakeholders solicits immediate responses to questions, provides more in-

depth responses than questionnaires, and can help develop a positive business

relationship between the Business Analyst and the stakeholder during the interview. The

Interview technique requires more of the Business Analyst’s time and increases the cost of

the project when remote stakeholders must be contacted via telephone or require

purchase and interviewer training costs to acquire remote conferencing technologies.

3.2.8 Task: Categorize the Stakeholders

.1 Purpose

Grouping stakeholders into multiple categories uncovers commonalities. This may also

assist the Business Analyst in other project phases, like planning a workshop based on

stakeholders geographic locations.

.2 Description

The Business Analyst will define stakeholder categories based on various factors that are

important in the project. The Business Analyst will enter a description in each category

for every stakeholder, creating a matrix or cross reference of stakeholder categories.

.3 Predecessors

The Stakeholder Summary and Stakeholder Listing will be used to develop and complete

the stakeholder categories.

.4 Process and Elements

The Business Analyst will create a document listing each stakeholder, stakeholder

categories, and how each stakeholder is recognized within each category. Examples of

stakeholder categories are:

• Key or secondary requirements sources

• Project impact

• Geographic distance

• Number of direct end users

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Number of business processes

• Number of existing systems in current business processes

• Number of interfacing business processes

.5 Stakeholders

Not applicable

.6 Deliverables

The end result of categorizing stakeholders is a matrix of stakeholders and categories. An

example of how this might look is shown below.

Stakeholder Classification

Stakeholder Name

State/Province

Key stakeholder?

Number of end users

Stakeholder 1

Texas, USA

Yes

Stakeholder 2

California, USA

Stakeholder 3

British Columbia,

Yes

Stakeholder 4

Ontario, CA

225

3.3 Define Business Analyst Work Division Strategy

The Business Analyst work division strategy is a systematic plan of action intended to

accomplish a specific goal. What are the different methods to divide the activities within

the group? There are 5 Business Analysts and 72 requirement activities, how will the work

be divided? What information/knowledge needs to be transferred between the Business

Analysts to successfully deliver compatible requirements? The strategy is applicable for a

Business Analyst team where there is more than one member. If there is only one Business

Analyst assigned to the project, then all requirement activities are assigned to that

Business Analyst. Within the Business Analyst team, the strategy is to define the work

division and co-ordinate the information and knowledge transfer among the team

members.

Figure 3.4-1 Business Analyst Work Division Strategy

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

3.3.1 Task: Divide Work amongst a Business Analyst Team

.1 Purpose

Dividing the work among the Business Analysts in a team removes obstacles of confusion

and uncertainty that can be placed among the Business Analysts and their goals. It defines

responsibilities and sets expectations. It clarifies both where the team wants to be and

how to get there.

.2 Description

The lead or team will decide and implement the most suitable method for the team to

achieve their specific goal(s). It is task of deciding which Business Analyst in the team is

assigned to the requirement activity.

.3 Predecessors

The Requirements Activities or Requirements Work Plan

.4 Process and Elements

The Business Analyst and/or Lead and/or the team review the activities and the duration

of the work effort.

The Business Analyst and/or Lead and/or the team decide on which strategy or strategies

(detailed in 3.4.2) to apply and document the rationale.

Based on the decided work division strategy or strategies, the activity is assigned to a

Business Analyst, either by another Business Analyst or by team consensus.

The task is completed when all the requirement activities are assigned to the Business

Analysts.

.5 Stakeholders

The Stakeholders are the Business Analyst and the Stakeholders associated with the

requirement activity.

.6 Deliverables

The resources (Business Analysts) assigned in the Requirements Work Plan.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

3.3.2 Technique: Business Analyst Work Division Strategy

.1 Purpose

A work division strategy is an allocation of activities according to some distinct

characteristic. It clarifies both where the team wants to be and how to get there. That

clarity removes obstacles of confusion and uncertainty that can be placed among the

Business Analysts and their goals. It defines responsibilities and sets expectations. The

lead or team will implement the strategy that is most suitable for them to achieve their

specific goal(s).

.2 Description

The following are different types of Business Analyst work division strategies:

Subject Matter Expertise

The Business Analyst who exhibits the highest level of expertise in performing a

specialized job, task or skill within the team

The work division strategy is based on the skill set required. For example, the team is

made up of three individuals where one specialize in data modeling, the other is a

business matter expert and the last business analyst specialize in requirement planning,

gathering and management. The strategy is that the first business analyst will take the lead

in the modeling activities and decisions, the second takes the lead in business content

related activities and decisions and the last business analyst takes the lead in requirements

related activities.

Complexity

The work division strategy is based on the activities’ level of complexity

For example, it has been determined that the workflow of the global underwriting system

is complex; thus, assigned to the Senior Business Analyst. The intermediate and simple

functions requirement activities will be assigned to the other Business Analysts on the

team.

Previous Work Experience with Stakeholders

If a Business Analyst within the team has had favorable work experience with a

Stakeholder(s) and the activity is based or related to that particular Stakeholder, the work

division strategy is based on which business analyst has worked with which stakeholder.

For example, the Business Analyst team is made up of three individuals on an

underwriting system development project. The Business Analysts’ milestone is

Requirements Sign-off. The stakeholders will sign-off on the requirements relating to

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

their department. One Business Analyst has had previous (favorable) work experience

with the Group Underwriting Stakeholder, another Business Analyst has had previous

(favorable) work experience with the Individual Underwriting Stakeholder and the third

Business Analyst has had no previous work experience with any Stakeholder nor

underwriting experience or training. Thus, the first Business Analyst is responsible of the

Group Underwriting functional requirements activities; the second is responsible of the

Individual Underwriting functional requirements activities and the last on the non-

functional requirements activities. The work division strategy was based on the Business

Analysts’ previous work experience and dynamics with the Stakeholders.

Geography and Culture

The work division strategy is based on the physical location of the Business Analyst

and/or the shared beliefs, values, customs and behavior of the society. It will save in time

and money due to the long travel time.

For example, for the global underwriting system project, there are three Business

Analysts. The first Business Analyst takes the lead for all requirement activities for Asia

and Australia because she is located in Asia. The second Business Analyst takes the lead

for all requirement activities for Europe and Africa because he is physically located in

Europe. The last Business Analyst takes the lead for all North and South America

requirement activities because she is geographical located in North America. Thus, the

work division strategy is based on the geographical location of the Business Analyst.

For the global underwriting system project, it was decided that the three Business

Analysts from Asia, Europe and North America to physically move to Europe to

successfully deliver compatible requirements. The work division strategy continues to be

the same as the above example. The Business Analysts have prior experience, knowledge

and relationships with the Stakeholders, the business and the culture.

The Business Analyst work division strategy may be based on Culture. Continuing with

the same example, for the Asia requirement activities, the work division strategy is altered

where the North American Business Analyst has the particular linguistic skill as for Asia.

For communication reasons, the North American Business Analyst will take the lead for

the Asia requirement activities. Thus, the work division strategy is based on the shared

beliefs, values, customs, dynamics, preferences and behavior of a society.

Area of Interests

The work division strategy is based on the business analysts’ area of interest.

For example, the underwriting development system requirement milestone activities

have been decomposed into functions: underwriting worksheets, insured information,

policy information, accounting transactions and workflow. The three Business Analyst

team divide the work on the basis of their functional area of interest or the function that

has attracted their attention. They might not necessarily have any previous experience in

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

the function but they have demonstrated a willingness and capability to successfully

deliver compatible requirements.

Physical Limitation

The work division strategy is based on the physical limitation, if any, of the Business

Analysts.

For example, a Business Analyst on the team is located off-site (works from home). All

research or non-functional requirement activities are assigned to the off-site Business

Analyst. Another Business Analyst, on the same team, has a bad back and physically

cannot travel. The requirement activities that involve travel are assigned to the off-site

Business Analyst. Thus, the work division strategy is based on the physical limitation of

the Business Analyst.

Business Analyst Availability

The work division strategy is based on the Business Analysts’ availability or commitment

to the project. Not all Business Analysts’ time is committed 100% to a particular systems

development component, process improvement or organization change. For example, a

Business Analyst may be committed 10% of their time to the global underwriting system

development component, 40% to the global claims system development component and

50% to the divisional claims system development component. Another example is that the

Business Analyst is only available to the project at the beginning of the phase.

The activities assigned to a Business Analyst must be within their committed time to the

project.

.3 Intended Audience

This technique is created by Business Analysts to obtain consensus and understanding

among themselves.

.4 Process

The Business Analyst and/or the Lead and/or the team decide which strategy or strategies

to use and document the rationale.

.5 Key Features

This technique is based on the Business Analyst skill set, previous experience and/or

environment. An individual on the team may be a cross-functional or a functional

Business Analyst where:

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

A cross-functional Business Analyst has a variety, and at different levels, of business

analysis skills and experience, i.e. Junior Business Analyst vs. Senior Business Analyst vs.

Business Analyst Lead

A functional Business Analyst has a specialty skill or training of business analysis, i.e. data

modeling

Review section 3.4.1.2 pertaining to a Business Analyst’s key features for a particular

strategy. To obtain information on a Business Analyst’s skill set, previous experience

and/or environment, refer to the Business Analyst Team Skill Matrix.

.6 Alternatives

Please review the strategies listed in section 3.4.1.2

.7 Strengths and Weaknesses

The strength of this technique is that the Business Analyst Team work division may be

based on one strategy or based on a number of strategies. It is flexible based on the team

members’ skill sets, previous experience and/or environment.

The work division strategy does not consider the Business Analysts’ time commitment to

the system development component, process improvement and/or organizational

change project. Not all Business Analysts’ time is committed 100% to a particular project.

However, it does take into account the Business Analyst skill set, previous experience

and/or environment.

For the Previous Work Experience with Stakeholders strategy, it might have been a

favourable end result; but, the Business Analyst might feel that the Stakeholder was

difficult to deal with in the past. Based on that experience, the Business Analyst may not

want to work with the Stakeholder in the future.

3.3.3 Technique: Co-ordination of Information within the Team

.1 Purpose

An information platform is created for the Business Analyst pertaining to business

concepts, functional and non-functional requirements, and how to handle requirement

issues to successfully deliver compatible requirements. They are set at the applicable

phase of the systems development component, process improvement and/or

organizational change. Thus, the Business Analysts have the same understanding,

information or tool to successfully deliver compatible requirements.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.2 Description

The following are examples of information that are co-ordinated among the Business

Analyst team members:

Core Business Concepts and Policies

Organization Standards and Policies

Examples are the “look and feel” of the web application and/or the standard architecture

platform or approved technology for the web application

Methodology

Examples are the company has incorporated the Information Technology Infrastructure

Library (ITIL) for service support and service delivery and Rational Unified Process

(RUP) for development.

Processes/Procedural Knowledge

Define and communicate Internal processes, i.e. requirement change request and

external processes, i.e. approval process in governance with organization’s policy

Document Templates

Set by either the methodology or the organization

Artifacts

Methodology or organization requirement

Terminology

Examples are cheque vs. check or word or phrase definition

Business Documentation

Examples are newsletters, books, central repository and websites

Functional and Non-Functional Requirements

• Strong understanding of In Scope and Out of Scope items

• Legal requirements or limitations

• Requirement Document Templates

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Provide instructions and examples

• Artifacts

• Methodology

• Consistent Approach for the Requirement Activity

• For example, have a common method of requirement gathering (JAD and

questionnaires)

Project Documentation

How to Manage Requirement Issues

Strong understanding of In Scope and Out of Scope items

Requirement Issues Communication Process

Approval Process in Governance with Organization’s Policy

.3 Intended Audience

This technique is created by the Business Analysts to share the same understanding,

information or tool to successfully deliver compatible requirements.

.4 Process

The Business Analyst begins by asking other Business Analysts or contacting other

members of the organization to where he/she may find the organization or the

department’s or the team’s standards, governance policies, methodologies, processes,

procedures, documentation and templates or the Business Analyst is given this

information, training and/or “welcome package” at the beginning of the activity or at time

when Business Analyst is assigned to the project.

.5 Key Features

This technique is for sharing and co-ordinating information among the team members. It

requires access to documentation, training, people and artifacts from different sources of

the organization and project.

.6 Alternatives

N/A

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.7 Strengths and Weaknesses

The benefits in co-ordinating information among the Business Analyst team are:

• To work together to create a new seamless and consistent way of thinking and

operating

• To save time

• To avoid re-work

• The disadvantages in this technique are:

• Cost of training

• Technology/software not availability

• Lack of access

• Learning curve

• Individuals that are resistant to change

• Lack of time

3.3.4 Technique: Knowledge Transfer

.1 Purpose

Knowledge transfer is a systematic approach to capture, collect and share tacit knowledge

in order for it to become explicit knowledge. Tacit knowledge is the know-how and

explicit knowledge is the knowledge that has been articulated and captured in the form of

text, diagrams, product specifications, etc. By doing so, this process allows Business

Analysts to access and utilize essential information, which previously was known

intrinsically by one or a small group of individuals, to successfully deliver compatible

requirements.

.2 Description

Knowledge transfer may be done at the beginning, middle or at the end of the phase or

project. It may be a one-time event or a scheduled event among the Business Analyst

team. Examples of knowledge transfer methods/techniques within the Business Analyst

team are:

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.3 Information Exchange

Verbal

Non Verbal

• Electronic

• Document

• Fax

Structured Walk-Through/Peer Reviews

Status Meetings

Verbal or non verbal

Debriefing Meetings

To report, verbal or non verbal, after the activity is completed, in order to obtain useful

information

Central Repository

Mentorship

Pair Senior and Junior Business Analysts for back-up, mentorship and knowledge transfer

.4 Intended Audience

This technique is created by the Business Analysts to share the same understanding,

information or tool to successfully deliver compatible requirements.

.5 Process

The Business Analyst and/or Lead and/or the team decide what type of knowledge needs

to be transferred, from whom to whom, when it will be done and how it will be

transferred. Refer to 3.4.4.2; it may be a one-time event or a scheduled event among the

Business Analyst team.

The Business Analyst and/or Lead and/or the team decide the method or methods of

knowledge transfer and communicate it to all team members.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.6 Key Features

This technique is for sharing and co-ordinating knowledge among the team members.

.7 Alternatives

N/A

.8 Strengths and Weaknesses

The benefits to knowledge transfer are:

• To solve problems and make better informed decisions

• To avoid repetition of past mistakes

• To understand customer’s behavior and preferences

• To work together to create a new seamless and consistent way of thinking and

operating

• To save time

• To avoid working in silos within the Business Analyst team

• To obtain the basic knowledge of other requirement activities details

The disadvantages in this technique are:

• Individuals that are resistant to change

• Learning curve

• No time

• Priorities change

• Business Analysts availability

3.4 Define Requirements Risk Approach

This section focuses on the Business Analyst’s role in requirements risk management and

how the Business Analyst will manage requirements risks.

For the definition of Risk and Issue (when a Risk materializes, it then becomes an Issue),

reference Fundamentals Knowledge Area, Chapter 8.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

Requirements risks and their management is a subset of overall project risks and their

management. Requirements risk relates to overall project risk in that there may be

dependencies between the two risk types or requirements risk impacting or being

impacted by overall project risks, and vice versa.

This section does not include discussion on detailed risk management for the overall

project. Overall project risks are managed by the Project Manager. The Business Analyst’s

role in dealing with broader project risks is as defined by the Project Manager.

Typical Roles and responsibilities of risk management for the Business Analyst vs. Project

Manager are as follows:

• End-to-End Requirements risk management: Business Analyst is responsible and

accountable.

• End-to-End Project risk management: Project Manager is responsible and

accountable. The project manager is also accountable for requirements risks.

For an understanding of Risk Management from a broader project perspective (not just

requirements focused) reference PMI’s PMBOK.

The risks and impacts resulting from poor quality requirements (such as re-work for the

technical team or lack of ability to test the application) are discussed, along with how to

recognize common risks that threaten good requirements, and how to respond to them.

The use of Requirements Attributes will allow for management of risks associated with

specific requirements. For more information on Requirements Attributes please

reference Requirements Analysis and Documentation Knowledge Area (Chapter 5,

section 5.9 Determine Requirements Attributes). How to use Requirements attributes to

understand risks are discussed.

This section includes discussion on:

• how requirements risk will be managed throughout the project

• how to decide what is the best risk management strategy for particular requirements

risks: e.g. risk avoidance, mitigation or assumption.

• how to define a Risk requirements attribute (level of risk) associated with different

attributes of requirements: e.g. difficulty of implementing, change management, new

technology, etc.

• examples of common requirements risks, such as risks associated with bad

requirements, and how to manage them

• techniques to use to manage requirements risk: planning, monitoring, and control

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

3.4.1 Task: Identify Requirements Risks

.1 Purpose

To identify a list of risks associated with each requirement based on the attributes defined

for each requirement and based on common requirements risks.

.2 Description

The Business Analyst reviews each requirement and associated requirements attributes to

identify the risks associated with each requirement. Also, there are common

requirements risks across all requirements which the Business Analyst identifies.

.3 Predecessors

All requirements at a business or user level have been defined with attributes defined for

each requirement.

.4 Process and Elements

The Business Analyst reviews each requirement along with its attributes and determines if

there is a risk associated with each requirement attribute.

For example, for the attribute “difficulty of implementing”, the greater the difficulty, the

greater the risk of implementation error.

For the “change management” attribute, if the degree of change in the end-user’s business

process is high, so may be the risk of acceptance of the solution.

Additional requirements attributes, such as “new technology” or “degree of stability of the

requirement”, once evaluated, may also produce additional requirements related risks.

Common risks across all requirements are identified. The Business Analyst reviews the

requirements and identifies common risks that threaten good requirements.

Some examples of common requirements risks are:

• Insufficient level of user involvement in identifying, detailed, and analyzing

requirements

• Ambiguous requirements. Not enough detail in the specification of the requirements.

• Missing, incorrect, and conflicting requirements

• Lack of requirements management and planning, such as requirements change

control

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

• Scope creep

The risks are documented.

.5 Stakeholders

The Business Analyst reviews the requirements and their attributes with the key

stakeholders: the requirements requesters and the Project Delivery Team. The BA is

accountable to identify requirements risks throughout the requirements process as

previously identified risks may disappear and new risks may surface.

.6 Deliverables

Once requirements risks have been identified, a list of requirements risks associated with

requirements and their attributes and common risks across all requirements is available.

3.4.2 Task: Define Requirements Risk Management Approach

.1 Purpose

To detail a requirements risk management process to use in dealing with requirements

risk throughout the requirements process.

.2 Description

The Business Analyst defines a requirements risk management approach.

.3 Predecessors

Requirements risk identification is complete, which is an output from the previous task.

.4 Process and Elements

The Business Analyst uses the techniques of Requirements Risk planning, monitoring and

control to manage requirements risks throughout the requirements process.

Following risk identification, the risks require close and careful management, in a timely

manner. Overlooking risk management can increase likelihood and impact of the risk,

and can cause further problems.

.5 Stakeholders

The Business Analyst, with input from the Key Project Stakeholders and the Project

Delivery Team, is responsible for managing requirements risk throughout the

requirements process.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.6 Deliverables

A requirements risk response strategy is documented for each identified risk, and kept up

to date as it is monitored and controlled. The strategy includes documentation resulting

from use of the 3 techniques: requirements risk planning, monitoring, and control.

3.4.3 Technique: Requirements Risk Planning

.1 Purpose

To provide a well thought out and methodically planned risk response strategy to be used

in monitoring and controlling of all identified risks, throughout the requirements

process.

.2 Description

The technique provides information about each identified risk so that it can be managed

in a methodical and logical manner. Planning for risks solves the problem of ad-hoc risk

management, which can lead to risk and impact materialization.

Other variations on this described technique is any similar risk planning techniques used

in specific industries.

.3 Intended Audience

This technique is executed by the Business Analyst to systematically plan for risks. All

project stakeholders should be involved and aware of risk management activities. Many

will be assigned to manage specific risks.

.4 Process

The Business Analyst begins by doing an initial risk assessment on each identified risk.

This assessment will be reviewed and updated if/as it changes.

The following is determined for each risk:

• Likelihood – the likelihood that the risk will occur. Use a scale such as 1 is low, 5 is

high.

• Impact - as forecast – the impact to the requirements process if the risk materializes

and becomes an issue. Use a scale such as 1 is low, 5 is high. Determine the following

categories of impact:

o Cost Impact

o Schedule Impact

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

o Scope Impact

o Quality Impact

o Benefits Impact

• Intervention Difficulty – determine how difficult it will be to intervene to prevent

the risk from occurring

• Precision of assessment – determine how precise the overall assessment is. Will be

based on past experience with the type of risk, and how much is known regarding the

risk.

• Mitigation Strategy - as initially defined – determine the best approach to detail with

the risk:

o Avoid

o Mitigate

o Assume

Action Plan - as initially defined. Identify who will do what to implement the mitigation

strategy of Avoid, Mitigate, or Assume. Determine Actionee and Date action should be

executed.

Contingency Plan/Corrective Action to be taken – as initially defined, and related

trigger event(s) (the trigger event indicates when to execute this plan). Determine what

the plan is if the risk does materialize. Identify what event(s) will trigger risk

materialization.

The next step is to document the risk response plan for each risk. Then, the business

analyst will review the plans with all key stakeholders.

.5 Key Features

A risk response plan, no matter what format is used, must include the detailed assessment

of each risk.

.6 Alternatives

N/A. There is no alternative to a requirements risk response plan.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

.7 Strengths and Weaknesses

A requirements risk response plan is an effective method to document requirements risk

assessment.

3.4.4 Technique: Requirements Risk Monitoring

.1 Purpose

To ensure risk status is assessed and up to date so that action can be taken in a timely

manner if need be. Careful monitoring can lead to enhanced controlling of all identified

risks, thereby reducing impact, throughout the requirements process

.2 Description

The technique provides a current status of each identified risk so that it can be controlled

in a methodical, logical, and timely manner. Monitoring risks solves the problem of

dealing with surprises that cause working in reactive, fire-fighting mode.

Other variations on this described technique is any similar risk monitoring techniques

used in specific industries.

.3 Intended Audience

This technique is executed by the Business Analyst to systematically monitor risks. All

project stakeholders should be involved and aware of risk monitoring activities. Many

will be assigned to monitor specific risks.

.4 Process

The business analyst executes the following steps on an ongoing basis (e.g. once per

week):

• performs weekly checks of risk status (e.g. red, yellow, green)

• Determine observed assessment if risk materializes. This allows comparison between

initial and observed assessment.

• Determine how to react to a risk when it materializes. Ensure action plan is in place.

Finally, the Business Analyst will document the monitoring results on an ongoing basis.

.5 Key Features

Risk monitoring and documentation, no matter what format is used, must include the risk

status and observation details.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

100

.6 Alternatives

N/A. There is no alternative to requirements risk monitoring.

.7 Strengths and Weaknesses

Requirements risk monitoring is an effective method to ensure you have a good handle on

up to date risk status.

3.4.5 Technique: Requirements Risk Control

.1 Purpose

To ensure risk is controlled by responding to it. Careful control can lead to reducing

impact of the risk throughout the requirements process.

.2 Description

The technique provides a way to control each risk so that it can be controlled in a

methodical, logical, and timely manner. Controlling risks solves the problem of dealing

with surprises that cause working in reactive, fire-fighting mode.

Other variations on this described technique is any similar risk control techniques used in

specific industries.

.3 Intended Audience

This technique is executed by the Business Analyst to systematically control risks. All

project stakeholders should be involved and aware of risk control activities. Many will be

assigned to control specific risks.

.4 Process

The business analyst executes the following steps on an ongoing basis (e.g. once per

week):

• Impact - as materialized. Describe the impact that was observed on the requirements

process/overall project when the risk materialized.

• Mitigation Strategy - as executed. Describe the mitigation strategy

(Avoid/Mitigate/Assume) that was executed to prevent the risk from materializing.

Compare against

• Action Plan - as executed. Document what was done by whom and when.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

101

• Contingency Plan/Corrective Action - as executed. Document what was done by

whom and when.

• Lessons learned. Describe the lessons learned from risk materialization

Finally, the Business Analyst will document the requirements risk control results on an

ongoing basis.

.5 Key Features

Risk control and documentation, no matter what format is used, must include the risk

materialization results and lessons learned.

.6 Alternatives

N/A. There is no alternative to requirements risk control.

.7 Strengths and Weaknesses

Requirements risk control is an effective method to ensure you understand risk

materialization results. This will assist in dealing better with risks in the next execution of

the requirements process.

3.5 Determine Planning Considerations

Requirements planning and management is typically a responsibility of the Business

Analyst. This section is intended to discuss tasks that the Business Analyst should include

in planning and managing requirements definition and documentation. It will explore

how decisions made in these areas may impact requirements planning and management.

The importance of good planning cannot be overstated as it will have a great impact on

achieving effective requirements identification, documentation and management. If

sufficient time is not allowed for requirements definition, or if all needed tasks related to

requirements are not identified; then requirements will not be sufficiently identified or

defined likely resulting in a poorly accepted final product. The effective Business Analyst

must be able to identify all relevant considerations in planning these activities.

Overall project planning is the responsibility of the Project Manager. The Business

Analyst must work out a requirements planning approach in agreement with the project

manager. For more detailed information on overall project planning, please refer to the

Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK).

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

102

3.5.1 Task: Identify Key Planning Impact Areas

.1 Purpose

The Business Analyst will be able to do a more effective job of planning and managing

requirements processing if they are able to identify those factors and considerations that

will impact their requirements planning and management process.

.2 Description

Many of these considerations will be significantly impacted by organization and project

specifics. These specifics must be strongly considered on an individual basis by the

Business Analyst in creating the requirements management plan.

.3 Predecessors

The Business Analyst should use all current project documentation in identifying those

areas that will impact their requirements planning. This will include the project charter

and overall project objectives, any existing project and organization standards and

procedures, as well as any personal knowledge of organization requirements. Project

historical records may also be of great value in this task.

.4 Process and Elements

The factors listed below represent typical, important factors that the Business Analyst

should consider in planning the requirements process for the project. It is not intended

that the Business Analyst should limit their analysis to only these, as many projects may

involve other factors as well. It should be further realized that not all of those factors listed

may be relevant on all projects in all organizations.

These factors can often be conveniently grouped by type. An example of such a grouping

is shown below.

The process that the Business Analyst will follow in their analysis of the potential impact

on the requirements management plan of each of these areas will necessarily vary due to a

number of individual, project and organizational factors.

Typically the Business Analyst will consider each of these areas in turn to determine their

impact on the planning process and the proposed requirements management plan.

Methodology

In a software development project, there are often two distinct, related methodologies in

use. These are the System Development Life Cycle (SDLC) methodology and the Project

Life Cycle methodology. Each will impact the planning process and must be considered

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

103

by the Business Analyst. Some organizations do not distinguish between these but rather

group methodology considerations together.

General Project Considerations

• Project Risk

• Project Expectations

• Organization standards

• Re-planning

• Stakeholder Needs and Location

• Project Type

.5 Stakeholders

Stakeholders for this task include all of the key stakeholders identified in Section 3.3 who

may be involved in the requirements planning and management project process.

.6 Deliverables

The deliverable of this task will be a list of relevant items for the Business Analyst to utilize

in the process of planning the requirements related activities for the project.

3.5.2 Task: Consider the SDLC Methodology

.1 Purpose

The particular SDLC, if any, in use in an organization will have a considerable impact on

the planning activities of the Business Analyst.

.2 Description

The System Development Life Cycle (SDLC) is defined as the overall process of designing

and developing information systems. This process is typically a multi phase approach

beginning with an analysis of initial requirements through the steps of analysis, design,

construction, implementation and eventual maintenance. A great variety of SDLC

approaches exist with each consisting of a different series of phases.

.3 Predecessors

The Business Analyst will need to be aware of the particular SDLC chosen for their

project as this will certainly influence the project tasks to be identified and included in the

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

104

requirements planning and management activities. In some organizations there may

actually be a choice available regarding the SDLC to be used in a particular project. In

some instances the Business Analyst may be involved in making this choice, while in

others there may be no particular SDLC used.

.4 Process and Elements

The SDLC methodology in use will impact requirements planning. It will determine how

the entire requirements process is executed and what deliverables are produced and

when.

The Business Analyst must be familiar and knowledgeable with their organization’s

SDLC(s), as it will greatly influence the process steps, tasks and deliverables required or

expected during the requirements planning and management phases of the project. Many

organizations may also offer and encourage the use of planning templates by the Business

Analyst in planning requirements planning and management.

Each of the SDLC approaches will define the requirements process in different ways and

will have very significant impacts on the Business Analyst’s planning efforts. Each will

offer descriptions of the project phases and tasks that should be included in the project

and will greatly impact the requirements plan.

E.g. The traditional waterfall method advocates gathering all requirements in the

beginning of the project; while in the Iterative/Agile approaches requirements may be

defined throughout the lifecycle. These differences will lead to different tasks being

identified as well as perhaps different sequences of tasks also.

Examples of common SDLC’s include:

• Waterfall

• Iterative

• Agile

.5 Stakeholders

Stakeholders for this task include all of the key stakeholders identified in Section 3.3 that

will be involved in the requirements planning and management project process.

.6 Deliverables

The selected SDLC represents the major deliverable of this task. This choice will also

cause the inclusion of the requirements related tasks to be part of the project plan.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

105

3.5.3 Task: Consider the Project Life Cycle Methodology

.1 Purpose

The particular Project Life Cycle(PLC), if any, in use in an organization will have a

considerable impact on the planning activities of the Business Analyst. The Business

Analyst must be aware of the PLC(if any) used in their organization as the defined

phases/events and related standards will impact on the requirements planning and

management aspects of the project plan. Some Business Analysts may typically become

involved in the project budgeting process and tasks also.

.2 Description

A Project Life Cycle (PLC) is defined as all of the project phases/events needed to

complete the project. The names and number of these phases will certainly vary

depending on the specific PLC in use. For example, the PMI defines the phases as

Initiation, Planning, Executing, Close Out and Controlling. The PLC will include all of

the steps defined in the SDLC (if used) but may also involve other steps and events. The

SDLC phases will fit into the PLC events and the PLC processes will be used to manage the

phases/events and tasks defined in the SDLC that may be used on any particular project.

.3 Predecessors

The Business Analyst will need to be aware of any PLC in use in their organization. The

PLC may have been already chosen for the project or the Business Analyst may be

involved in choosing the one to be used for their project.

.4 Process and Elements

The Business Analyst must consider the phases, tasks and subtasks defined in whichever

PLC that is in use for the project, and decide which of them are relevant and must be

included in the requirements planning and management activities in their project. They

may also have to identify additional tasks as well.

A typical PLC, for example, may include the following phases:

• Definition: The project concept is defined, various alternatives evaluated, and the

optimum alternative selected.

• Planning: The project is approved and the detailed project plan is created.

• Initiation: The project is kicked off with clear definition and defined agreed to

objectives.

• Execution: The project plan is executed with the tasks and activities underway.

Project deliverables listed in the project plan are created.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

106

• Close-Out: The final product is completed. Any close out activities are carried out

and the project terminated.

Each of these phases are typically further broken down into tasks and subtasks that should

be considered by the Business Analyst. The PLC may also include organization/project

standards that need to be considered and incorporated in the requirements planning and

management activity.

.5 Stakeholders

Stakeholders for this task include all of the key stakeholders identified in Section 3.3 that

will be involved in the requirements planning and management project process.

.6 Deliverables

The selected PLC represents the major deliverable of this task. This choice will cause the

inclusion of the requirements related tasks described in the PLC to be part of the project

plan.

3.5.4 Task: Consider Project Risk, Expectations, and Standards

.1 Purpose

The purpose of this task is to remind the Business Analyst that there are a number of

project and organization related factors that have a considerable impact on the planning

and execution of the requirements planning and management activities in the project.

These factors are Risk, Stakeholder Expectations, and Organization Standards. Each of

these should be analyzed and included by the Business Analyst in their planning activity.

.2 Description

The Business Analyst must include many factors in their requirements planning and

management activity. Among these are the three factors listed above – project risk, key

stakeholder expectations and organization standards for the project and for the product

of that project.

Project risk is a key element in any project planning task and the Business Analyst must

consider it in planning and managing the requirements process. The impact of risk and

planned responses to it will have a considerable affect on the requirements plan. For

example, there exists a risk that a requirement may be missed. The Business Analyst must

consider this possibility and it’s possibility and impact. They may decide to add a review

task to the plan to help avoid this risk.

Stakeholders will typically have their own expectations regarding project cost, schedule,

quality, etc., for example. These must be identified and documented as they relate to

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

107

requirements so that the Business Analyst can insure that they are met to help achieve a

successful project. This may well result in adding tasks to the project plan, in changing the

sequence of tasks or perhaps in affecting resource assignments or other changes to the

requirements plan. It is recommended that the Business Analyst take into account the

changing priorities of stakeholder project expectations. Priorities should be clearly

defined and communicated during project planning and execution. An example of how

to address this might be to plan a recurring meeting with the Sponsor, Project Manager

and key Stakeholders.

Organization standards for the project and/or the product may exist in a number of

organizations. These should be identified by the Business Analyst and then accounted for

in the plan.

.3 Predecessors

The major input to this task will be the current project plan. Along with the plan, other

useful documents will include organization project historical records, the project RACI

(Responsible-Accountable-Consulted-Informed) (see Section 3.2) chart and any relevant

project/product standards that are in use in the organization.

.4 Process and Elements

The Business Analyst must consider the impact of project risk on their planning efforts for

each project on an individual basis. E.g. how much risk are the project sponsors willing to

assume? The Business Analyst must consider the impact of the risks inherent in defining

functional requirements, and how these risks should impact the planning estimates and

schedule. For example, if the project has an absolute scheduled completion date, then the

scope and amount of functionality included in the requirements must be limited. The

Business Analyst should consider the impact of missing the scheduled dates and or cost

estimates for the project. Refer to the PMI PMBOK for more information concerning

project risk and the recommended responses available to cope with it.

The Business Analyst must have a clear understanding of the project sponsor’s and other

key stakeholders expectations of the project cost, schedule, scope, quality, and other

related areas. They must also be aware of the possible fluctuating priorities of these

factors as the project progresses. Additionally roles, responsibilities and associated

stakeholder expectations need to be documented, agreed to and officially signed off by

the project team members. A clear RACI chart should be created and maintained for the

entire project by the project manager and also maintained specifically for the

requirements process by the business analyst.

Part of the expectations process may be a Business Analyst review of existing historical

project records and comparing these to the project plan. If the business analyst has access

to such records, they will prove valuable to planning requirements activities. Typically it

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

108

is the responsibility of the Business Analyst to insure that accurate collection of the

requirements activities project task performance is done on each project.

An organization may have standards relating to the project planning process or to the

standards for the product of the project. From a requirements perspective, the Business

Analyst needs to understand what these standards are and how they will impact the

requirements process.

For example, one organization may have a standard that dictates that all requirements

will be gathered using the Joint Application Design (JAD) information gathering

approach and that all JAD sessions will last a minimum of 1 day. This requirement will

influence the Business Analyst’s approach to requirements planning and management.

Project planning will certainly be affected by these considerations.

.5 Stakeholders

Stakeholders for this task would include all project stakeholders that are impacted by

project risk as well as those affected by related organization standards and the project

expectations of key project stakeholders.

.6 Deliverables

The deliverable from this task will be the modified requirements management plan as it is

updated by the Business Analyst after their consideration of the areas of project risk,

organization standards and the expectations of key stakeholders.

3.5.5 Task: Re-Planning

.1 Purpose

The Business Analyst typically will have the project requirement to manage the

requirements management plan and to revise it as required during the project in order to

accurately reflect any changes in the requirements process. This will result in having to

modify and update the project plan and estimates periodically throughout the project.

.2 Description

Re-planning is defined as the process of modifying the project plan in response to events

that have occurred during project execution. The Business Analyst must realize that

project planning is an ongoing process, not an event that is done once in a project. The

process of project planning occurs throughout the project.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

109

.3 Predecessors

In order to accomplish the continuous task of re-planning, the Business Analyst will

primarily use two inputs. These are the current baseline requirements plan and whatever

changes have been uncovered to the existing plan.

.4 Process and Elements

The process of re-planning consists of evaluating the impact of the proposed change(s) in

the project environment or requirements to determine the impact on the base lined plan.

Impacts of re-planning may be considerable as it requires time and effort to actually

execute the re-planning. The re-planning may also result in dramatically different plans

as the project is executed.

As the project team becomes more involved with the project and the Business Analyst

becomes more involved in the details of the requirements process; the project scope

and/or non-functional requirements can be expected to change. As the new information

and discoveries are revealed, the original allocated time may increase as the estimates,

planned activities and assumptions are updated.

.5 Stakeholders

These include all stakeholders involved with the baselined requirements management

plan.

.6 Deliverables

The deliverable from this task will be the updated requirements management plan as it is

updated by the Business Analyst after their re-planning consideration. It is understood

that Business Analyst re-planning is an ongoing activity that will occur throughout the

project at any time that conditions and results of the project indicate that re-planning of

the requirements activities is needed.

3.5.6 Task: Consider Key Stakeholder Needs and Location

.1 Purpose

The physical location and specific needs of individual key stakeholders can each have a

significant influence on the requirements planning and management efforts of the

Business Analyst and must be considered in the requirements plan and management.

.2 Description

The Business Analyst must take into account specific needs and location(s) of the project

stakeholders in planning, defining and documenting requirements. Some projects will

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

110

have the stakeholders located in a single location while others will have some of their key

stakeholders dispersed over a wide area. These latter projects increase the complexity of

managing the requirements planning and management activity in the project. Typically,

some stakeholders will also exhibit individual specific requirements that must be met in

order to have a successful project. For example, perhaps one key stakeholder may have a

history with the IT department and does not usually like or trust them. This information

could obviously influence the planning of project tasks that must include this stakeholder.

Or perhaps another stakeholder may have some experience with using a particular

technology and be in favor of its choice for the current project.

If these can be identified and factored into the requirements planning and management

process, the project has a better chance of success.

.3 Predecessors

The Stakeholder list showing the identity, location and interests of the project

stakeholders developed in Section 3.3 is a major input to this task.

.4 Process and Elements

The Business Analyst must consider the location of the key stakeholders in their project.

Two different types of projects can be identified regarding the location of these

stakeholders:

.5 Centralized

All key stakeholders are located in the same local geographic area. There are no special

considerations for the Business Analysis involved in these projects.

.6 Dispersed

These more difficult projects have some key stakeholders located in different geographic

areas. The factors of distance, possible time differences and perhaps cultural and

language differences increase the difficulty for the Business Analyst and require some

special analysis to identify and account for these differences

An example of the impact of this type of situation might be the necessity to have

teleconferences rather than face to face meetings due to the differences in physical

location and the difficulty in scheduling everyone’s availability in a single location.

Another typical situation might involve an outsourced development project where the

development team is physically located many time zones away. This type of situation

must be accounted for during requirements planning by the Business Analyst and would

require more detailed requirements documentation, perhaps more frequent review

sessions or maybe a different more detailed documentation methodology, for example.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

111

Individual stakeholders may have specific requirements that need to be identified in the

requirements plan to insure their inclusion in the completed project output.

.7 Stakeholders

These include all key stakeholders involved with the baselined requirements

management plan.

.8 Deliverables

The deliverable from this task will be the updated requirements management plan.

3.5.7 Task: Consider the Project Type

.1 Purpose

The Business Analyst must know or be able to ascertain the type of project that is planned

in order to determine any impact on planning and management of requirements.

.2 Description

The type of project that the Business Analyst is assigned to may have a significant impact

on the planning process. The impact differences may include types and durations of

requirements planning and management tasks as well as the roles and responsibilities

involved. For example, in a project to purchase a new software package, typically the

level of detail required in requirements definition will be much less than in an in-house

software development one.

.3 Predecessors

A major input to this task will be the current project plan. This document should contain

information identifying the type(s) of project. In some cases, it is recognized that the

actual type of project, i.e. package purchase or in-house development, may not be

finalized until the project is underway based on information developed during the

project.

.4 Process and Elements

Types of projects often worked on by Business Analysts include the following:

• New Software Development (in-house)

• Outsourced Development

• Software Maintenance

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

112

• Software Package Selection

• Process improvement

• Organizational Change

The differences in the requirements planning and management activities of the Business

Analyst in these different types of projects will be very great; since the purpose of,

objectives and tasks involved in the requirements planning, definition and

documentation are different for these varying types of projects.

.5 Stakeholders

These include all key stakeholders involved with the requirements management plan.

.6 Deliverables

The deliverable from this task will be the updated requirements management plan.

3.6 Select Requirements Activities

The activities that are executed during the requirements process and how they are

executed will determine the quality and timeliness of the requirements deliverables and

ultimately of the solution. The Business Analyst should select a complete set of

requirements activities such that the result is a clear, concise set of requirements on which

the realization of the solution can be based. The resource types required to complete

each activity also need to be defined.

To accomplish this, the Business Analyst will determine what activities need to be

undertaken to complete the end-to-end requirements process, which consists of:

• Requirements Elicitation (Chapter 4)

• Requirements Analysis and Documentation (Chapter 5)

• Requirements Communication (Chapter 6)

• Solution Assessment and Validation (Chapter 7)

This section discusses:

• What the Business Analyst needs (inputs) to be able to select requirements activities.

• How the Business Analyst will select the activities needed (tasks).

Deliverables (outputs) of this activity are:

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

113

• A selection of all activities for the entire requirements process (Requirements

Elicitation to Solution Assessment and Validation)

• List of activities with a detailed description of each activity, and the types of resources

required to complete each activity e.g. a Work Breakdown Structure (WBS).

• Logical dependencies between activities i.e. determination of predecessors.

This section does not include:

• Selection of any non-requirements related activities

Assigning actual effort estimates (and duration estimates) and actual resources (who and

the number of resources) to the activities. These activities will be covered in 3.8.

3.6.1 Task: Determine Requirements Elicitation Stakeholders

and Activities

.1 Purpose

To determine which stakeholders will be involved in the requirements elicitation

activities, which requirements elicitation activities need to be undertaken, and the types

of resources required to complete them. The goal of requirements elicitation is to have a

complete set of business and user requirements available once the activities are complete.

.2 Description

This task entails determining what activities should be undertaken by whom, to complete

requirements elicitation.

The Business Analyst must select those business stakeholders from whom they will gather

information from to develop the requirements. All key stakeholders or someone

representing each key stakeholder’s perspective should be included in the requirements

elicitation process. The Business Analyst, in order to elicit requirements from them,

should ensure that all people included in the requirements elicitation process have the

necessary time and knowledge (are Subject Matter Experts in their business area). The

Business Analyst should also be satisfied that all perspectives of the requirements are

included to minimize changes during later phases of the project.

Once the stakeholders are identified, the BA will select the requirements activities by

determining how requirements will be gathered. The methods or processes for elicitation

requirements should align with the importance, impact, timing, and value of the project.

The activities selected should make best use of the participants’ time, they should stay

focused on the project requirements elicitation process, and they should provide the

Business Analyst with the information necessary to produce clear and accurate

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

114

requirements deliverables. The techniques used to gather requirements are discussed in

detail in Chapter 4 Requirements Elicitation. Each of these techniques should be reviewed

and the Business Analyst should select the technique or combination of techniques that

will best fit their needs.

Throughout this process, the Business Analyst should determine what other project roles

should be involved in requirements elicitation and review tasks. Some examples would

be:

Technical resources may need to be involved to support the tools used by the Business

Analyst

Internal or external Subject Matter Experts (SMEs) may be called in to help the Business

Analyst review, codify, and analyze the data collected

Accounting or Finance department resources can assist the Business Analyst in better

understanding financial information collected, organizational accounting practices, and

tax implications.

An important part of involving other roles in requirements elicitation and review is

getting their buy-in of the need to include them in various steps of the process. All

resources participating in requirements elicitation and review should know the

importance of their role, the reason(s) why they have been included, and the value that

they add to the process.

.3 Predecessors

The BA will use as input to the task the outputs of Section 3.3 Identify and Describe

Stakeholders and Section 3.6 Determine Planning Considerations. The key stakeholders

identified and the software development methodology, for example, will determine the

requirements elicitation techniques and activities.

.4 Process and Elements

The Business Analyst will determine the best way to gather requirements from the

stakeholders. The BA will refer to Chapter 4, Requirements Elicitation, and select the

appropriate techniques to elicit the requirements from the stakeholders.

For example, in a project where stakeholders are dispersed, one technique that could be

appropriate is a survey.

In a COTS (Commercial Off-the-Shelf System) implementation, an appropriate

technique could be to conduct a demo of several suitable products, and obtain

stakeholder feedback on them.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

115

In a project where an iterative software development approach is being utilized, a

prototype can be used to elicit the next iteration of requirements.

Requirements Workshops, where face-to-face time yields added benefits, while

especially well-suited to complex projects, is useful for all project types.

Note that there may be specific elicitation approaches that have been standardized by the

organization, in which case those can be used.

.5 Stakeholders

The stakeholders in this task are the key stakeholders that have needs/goals for the project.

.6 Deliverables

The task is complete when there is a complete list of activities, such as a WBS, detailed for

requirements elicitation. Each activity should be itemized with a detailed description and

the types of resources required to complete it. Predecessors to the activities have also

been defined based on logical dependencies of the activities.

3.6.2 Task: Determine Requirements Analysis and

Documentation Activities

.1 Purpose

To determine which requirements analysis and documentation activities need to be

undertaken, and the types of resources required to complete them.

.2 Description

The choice of requirements modeling and analysis techniques and documentation

techniques should be made based on the availability of the desired tools or technologies

or standards within the organization, the Business Analyst’s familiarity with the desired

techniques, the applicability of the desired technique, and the ability of the desired

techniques to provide objective and accurate requirements deliverables.

The project’s time constraints and budget should also be considered when selecting the

best modeling and analysis techniques, and documentation techniques. Chapter 5 covers

the most commonly used requirements modeling and analysis techniques and

documentation practices. The Business Analyst should become familiar with each one

and understand the advantages of each, the limitations or caveats associated with each

technique, and the types resources necessary to properly perform each technique.

Selection of the best techniques to model and analyze requirements should also include

the Business Analyst’s justification or reasoning for the techniques selected. Selection of

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

116

the best techniques to document requirements should include the Business Analyst’s

justification or reasoning for the techniques selected.

The Business Analyst will determine the types of resources required to conduct each

requirements analysis and documentation activity, as outlined in Chapter 5.

.3 Predecessors

The Business Analyst needs to have a good understanding of the type of project and the

scope level of requirements already elicited to determine which analysis techniques and

which documentation styles will be the most suitable. Requirements Elicitation activities

must be complete and Business and/or User Requirements documented.

.4 Process and Elements

The Business Analyst reviews all of the stakeholder information, requirements elicitation

results, and project scope information. Then the Business Analyst reviews each analysis

technique and each documentation style. The Business Analyst then determines the best

techniques to be used based on which techniques are best suited to what information is

available, which techniques have been used before in the organization (familiarity) and

types of resources required vs. available to accomplish the techniques.

For example, for a small/short 3 month project or a COTS system, use-cases may be used

for the analysis technique and for the documentation technique. In this case the BA may

choose to not have an SRS (Software Requirements Specification).

For a Data Warehousing project, the best requirements model to formulate and analyze

would be a data model.

For a project where the Project Delivery Team is outsourced, a detailed SRS would be

appropriate with formalized document walkthroughs.

.5 Stakeholders

The key stakeholders and SMEs should be involved in the requirements analysis phase to

ensure that the modeling represents correctly the requirements and to be implemented.

Constant collaboration between the key stakeholders and SMEs and the Business Analyst

is required to develop a solution to the requirements that will meet the stakeholders’

needs.

.6 Deliverables

The task is complete when there is a complete a list of activities, for example, a WBS,

detailed for requirements analysis and modeling and documentation. Each activity

should be itemized with a detailed description and the types of resources required to

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

117

complete it. Predecessors to the activities have also been defined based on logical

dependencies of the activities.

3.6.3 Task: Determine Requirements Communication Activities

.1 Purpose

To determine which requirements communications activities need to be undertaken, and

the types of resources required to complete them.

.2 Description

The Business Analyst must select the requirements documentation that best captures and

most clearly communicates the project requirements. The Business Analyst should be

familiar and comfortable with using the desired documentation and should have the

necessary skills to accurately complete the documentation. The decision on how the

requirements will be documented should also match the needs of all audiences

associated with the project. Chapter 6 explains the communication of project

requirements and shows the various ways that project requirements can be

communicated. Each method and technique for communicating requirements discussed

in Chapter 6 should be evaluated and selected, modified, or discarded to meet the needs

of the project.

.3 Predecessors

The key stakeholders will assist the Business Analyst in determining who needs to be

communicated to and how. All requirements, analysis models and results, and any other

requirements documentation need to be complete and available as input to this activity.

All preceding requirements related activities need to be successfully completed:

Requirements Elicitation and Requirements Analysis and Documentation.

.4 Process and Elements

The Business Analyst reviews all of the stakeholder information, requirements, analysis

results and models. Then the Business Analyst reviews each communication method

available to them (e.g. Software Requirements Specification template). The Business

Analyst then determines the best communication vehicles that are best suited to what

information is available and who is recipient of the final requirements communication

package.

For example, to communicate to Senior Level Management Stakeholders, a presentation

can be prepared with all of the key highlights.

To communicate the product requirements to potential customers, a brief video message

or webpage can be made available on the organization’s website.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

118

For the Project Delivery Team, detailed level business rules with decision trees can be

packaged together in a CASE (computer aided software engineering) tool.

.5 Stakeholders

The key business stakeholders and SMEs should be involved in the review and signoff of

the requirements to ensure that the documentation represents correctly the solution to be

implemented.

.6 Deliverables

The task is complete when there is a complete list of activities, for example, a WBS,

detailed for requirements communication, including reviews with key stakeholders, and

signoff. Each activity should be itemized with a detailed description and the types of

resources required to complete it. Predecessors to the activities have also been defined

based on logical dependencies of the activities.

3.6.4 Task: Determine Solution Assessment and Validation

Activities

.1 Purpose

To determine which Solution Assessment and Validation activities need to be undertaken,

and the types of resources required to complete them.

.2 Description

The Business Analyst must select the Solution Assessment and Validation activities that

best provides the design of the solution based on the requirements. The Business Analyst

should be familiar and comfortable with executing the tasks identified in Chapter 7 and

should have the necessary skills to determine best solution with the collaboration of the

Project Delivery Team. The decision on how the requirements will be implemented to

provide the final solution should align with the vision of the Organizations receiving the

solution.

.3 Predecessors

The Business Analyst needs to have the final requirements document(s) signed off by the

business, reviewed by the Project Delivery Team, and all questions and concerns

regarding requirements, analysis, modeling, documentation, and communication, by

both Key Stakeholders and Delivery Team(s) resolved. All preceding requirements

related activities need to be successfully completed: Requirements Elicitation,

Requirements Analysis and Documentation, and Requirements Communication.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

119

.4 Process and Elements

The Business Analyst reviews all of the stakeholder information, requirements, analysis

results and models, and the final set of requirements documentation. Then the Business

Analyst collaborates with the Project Delivery Team to conduct and coordinate the tasks

in Chapter 7 to determine the solution. Once the best solution has been determined by the

Project Delivery Team and the Business Analyst, the Business Analyst reviews the

solution with the Business to ensure it will meet their needs and to obtain buy-in.

For example, if the project involves implementation of COTS, an evaluation of several

viable solutions can be conducted.

For an enhancement to an existing application, there may be only one viable solution.

Since an existing production system will be impacted, all activities to move seamlessly to

the new version should be detailed and resourced to decrease risk of problems occurring

during and post-implementation.

.5 Stakeholders

The Project Delivery Team will be the key stakeholder involved in the design of the

solution based on the requirements. The coordination of the activities in Chapter 7 will

be the responsibility of the Business Analyst.

.6 Deliverables

The task is complete when there is a complete list of activities, such as a WBS, detailed for

Solution Assessment and Validation. Each activity should be itemized with a detailed

description and the types of resources required to complete it. Predecessors to the

activities have also been defined based on logical dependencies of the activities.

3.7 Estimate Requirements Activities

Requirements planning and management essentially includes three basic parameters:

scope (work to do), schedule (time to do it in), and resources (budget for the project).

Often enough, Business Analysts make haphazard estimations of their requirements

parameters. Rather than base the plan and activities on “gut feelings”, the requirements

plan needs to be based on empirical data and methodologies. The assumption is that each

task will usually be assigned to an individual resource and based on the skill level of a fully

qualified BA.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

120

3.7.1 Task: Identify milestones in the requirements activities

development and delivery

According to the Project Management Institute’s Body of Knowledge (PMBOK), a

milestone is a significant point or event in the project. Milestones are important times to

celebrate the completion or delivery of a major section of project work. Milestones are

used to measure the progress of the project and compare actual progress to earlier

estimates. An example of a major milestone of Requirements Planning and Management

is the stakeholders’ and sponsor’s sign-off of the Requirements Document and/or other

mandatory deliverables defined by the project (include other examples).

.1 Purpose

Milestones can be used by the Business Analyst to measure the progress and completion

of significant phases of requirements activities.

.2 Description

A milestone can be a calendar date or the completion of a significant number or group of

activities. The Business Analyst will define milestones that will occur within the listing of

requirements activities defined in section 3.7.

.3 Predecessors

The Business Analyst will use the listing of requirements activities developed in section

3.7 as the basis for developing the requirements activities milestones. (include mention of

project plan)

.4 Process and Elements

The Business Analyst will review the list of requirements activities with the Project

Sponsor and Project Manager to define and agree on each milestone and the associated

requirements activities that must be completed to recognize when the milestone has been

reached. Each milestone should be distinctly identified by name or a unique calendar

date to avoid confusion.

.5 Stakeholders

The Project Sponsor and the Project Manager are the key stakeholders for this task.

Project team members who will be assigned a requirements activity or who are

responsible for the completion of requirements tasks may also be consulted to identify

each milestone and determine which activities will be associated with each milestone.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

121

.6 Deliverables

The artifact produced from this task will be a listing of milestones and associated

requirements activities, which should be included as part of the project plan. This

information can also be appended to the requirements activities listing created in section

3.7 or developed as a separate document.

3.7.2 Task: Define Units of Work

(A unit of work is a task that cannot be decomposed further) Should we check how they

define this in the PMBOK?

.1 Purpose

To create a complete outline of how requirements planning and management will

proceed.

.2 Description

This task will document the steps or requirements planning activities that must be

completed in order to achieve the defined milestones. It will define how each task will

proceed and will provide a management tool for requirements activities to measure the

progress of each task.

.3 Predecessors

The Business Analyst will use the listing of requirements activities developed in section

3.7 as the basis of defining discrete units of work and time estimate for requirements

activities.

.4 Process and Elements

The Business Analyst will review each requirements activity listed in section 3.7 and break

down each activity into sub-activities and then further into tasks. Each task should be

completed within a 1-2 week time period and should be identified as an independent task,

a task dependent on the completion of other tasks, or a task that must be completed before

other tasks can start. For example, the activity of ‘Interview Stakeholders’ could be

decomposed into sub-activities: Prepare interview questions, interview stakeholders,

document interview responses. The sub-activity of interview stakeholders could be

decomposed into the tasks of interview stakeholder 1, interview stakeholder 2, interview

stakeholder 3, etc.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

122

.5 Stakeholders

Project team members who will be assigned a requirements activities task or who are

responsible for the completion of requirements tasks should be consulted to define and

agree on each task component and any dependencies. Any resources outside of the

project team that will perform a requirements activity should be contacted to review and

agree on components associated with their task(s).

.6 Deliverables

The artifact produced by this task will be a listing of components and dependencies

associated with every requirements activity defined in section 3.7. This listing can be

combined with the deliverables from section 3.7 or created as a separate document.

3.7.3 Task: Estimate effort per Unit of Work

.1 Purpose

This task will document the resource assigned to each task and the estimated timeframe

for completing each task. This estimate will provide the project team with a tool for

measuring the status and progress of each task.

.2 Description

The Business Analyst will develop an estimate of effort (hours, days, or weeks) for each

task identified in section 3.8.2.

.3 Predecessors

The Business Analyst will use the listing of requirements activities developed in section

3.8.2 and a listing of documented assumptions and risks.

.4 Process and Elements

(is this a technique, like historical data? – check PMBOK for alternate techniques)

The Business Analyst will assign an available resource and define a time estimate for each

requirements task. Critical or complex tasks should be assigned to the more skilled and

experienced resources. Related tasks should, if possible, be assigned to the same person.

Tasks with specific geographic needs should be assigned to resources closest to the

location unless the additional cost of remote resources can be justified in terms of

experience or value. Tasks requiring multiple resources should consider assigning

resources that work well together or have had past successful experiences working

together. The assignment should show the name or role of the resource and the duration

(in days) needed to complete the activity. Task assignments should be mindful of

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

123

potential personality issues or work styles when assigning multiple resources to an

individual task.

.5 Stakeholders

The stakeholders for this task are project team members who will be assigned a task or

who are responsible for the completion of a task. Also, resources outside of the project

team that are assigned a task should be contacted to help define estimates.

.6 Deliverables

The artifact produced from this task will be a list of the estimated time to complete each

requirements activity defined in section 3.8.2. This document can be combined with the

requirements activities document(s) created in section 3.7 or developed as a separate

artifact.

3.7.4 Task: Estimate duration per unit of work

.1 Purpose

This task will define the work period (calendar days) for each activity defined in section

3.8.2. These estimates will assist the Business Analyst in defining any sequences of

activities, determine resource timing, and identify schedule constraints.

.2 Description

The Business Analyst will estimate starting and ending dates for each activity defined in

section 3.8.2.

.3 Predecessors

The listing of activities from section 3.8.2 and the listing of estimated work effort from

section 3.8.3 will be needed to complete this task.

.4 Process and Elements

The Business Analyst will enter a beginning and ending calendar date for each task

defined in section 3.8.2. Estimates will assume that each task will be assigned to a single

resource and that the assigned resource will be exclusively dedicated to the task until the

task is completed.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

124

.5 Stakeholders

The Business Analyst should discuss and get agreement on estimates for tasks defined in

section 3.8.2 with the Project Manager and any resources that could be assigned to one or

more of these tasks.

.6 Deliverables

The artifact produced from this task will be an estimated duration for every task defined in

section 3.8.2.

3.7.5 Technique: Use documentation from past requirements

activities to estimate duration

.1 Purpose

This technique will provide the Business Analyst with data to support estimating duration

for the tasks defined in section 3.8.2.

.2 Description

The Business Analyst will review other projects in the organization that required the

completion of tasks that are the same as or similar to those developed in section 3.8.2. For

each completed task from other projects that match the tasks in section 3.8.2, the Business

Analyst should use the actual duration from the completed task as the estimated duration

for the matching or similar task in section 3.8.2. For each completed task from other

projects that is similar to the tasks in section 3.8.2, the Business Analyst should adjust the

estimate for the current project task to account for variations between the completed task

and the similar task noted in section 3.8.2.

.3 Intended Audience

N/A

.4 Process

The Business Analyst will review documentation and artifacts created from other recent

projects within the organization, looking for the actual duration of tasks that are the same

as or similar to the tasks defined in section 3.8.2. For each task found in other projects that

matches or is similar to tasks in the current project, the Business Analyst should set the

duration estimate of the current task equal to the number of days in the completed task,

taking into account any differences in project assumptions, business processes,

technologies, or resource availability that should modify the duration estimate. The

Business Analyst will then document the duration (start date and end date) for each task

defined in section 3.8.2 based on the actual duration of a matching or similar task that has

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

125

been completed in a recent project. When estimating the duration of each activity, the

Business Analyst should include time for conducting the work, resolving issues, meetings,

conducting working sessions, review of project documentation, reviewing stakeholder

feedback, and making revisions to project documents. Estimates should also account for

time constraints, like holidays, and prior resource commitments to other projects or

activities.

.5 Key Features

This technique requires access to documentation and artifacts from other completed or

active projects in the organization and requires stronger judgment skills from the Business

Analyst to determine how similar or different completed tasks from other projects are

from the task list defined in section 3.8.2.

.6 Alternatives

Interview – The Business Analyst could interview resources in the organization who

have performed tasks that are the same as or similar to the task list in 3.8.2 to solicit their

opinions or information about the duration of these similar tasks then use the responses

to develop duration estimates.

Duration Estimates from other projects – The Business Analyst could copy duration

estimates from other active projects where the tasks were the same or similar.

.7 Strengths and Weaknesses

The actual duration for similar tasks from recent projects provide an objective baseline

for the Business Analyst to use in estimating duration, but information can be incomplete,

inaccurate, or may exclude important factors that affected the actual duration, like hiring

an outside firm to research and develop all of the workflow analysis.

3.7.6 Task: Identify Assumptions

.1 Purpose

In each task, there are factors or conditions which are considered to be true or to exist

without the need to provide documented evidence or empirical data. These factors

should be documented as Assumptions and all estimates should support these

assumptions.

.2 Description

The Business Analyst will identify and document assumptions that affect requirements

planning and management activities. For example, the Business Analyst should

document the assumption that all invited parties will attend JAD sessions.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

126

.3 Predecessors

All project documentation developed to this point should be used in this task.

.4 Process and Elements

The Business Analyst should review all project documentation and prepare a list of all

Assumptions identified in these documents that impact Requirements Activities and

management. The Business Analyst will review and validate the Assumptions with the

project sponsors, project manager, and stakeholders before they are included in the

project documentation. During this review, each Assumption will also be assessed a

degree of risk, which defines the frequency (how often the assumption will apply) and

significance (how severe the assessment impact will be) of each assumption. Estimates

should be based on documented Assumptions and identified Risks.

.5 Stakeholders

The stakeholders for this task are the project sponsor, project manager, and project team.

.6 Deliverables

The result of this task will be a listing of Assumptions, their degree of risk, their

significance, and any justification if there is a conflict with an estimate.

3.7.7 Task: Identify Risks

.1 Purpose

Events or conditions that could have a positive or negative affect on estimating

requirements activities and management are Risks and should be documented.

.2 Description

This task will identify and list Risks associated with requirements planning and

management. Risks should be communicated to the project manager and documented in

the master project plan.

.3 Predecessors

All project documentation developed to this point should be used in this task.

.4 Process and Elements

The Business Analyst should review all project documentation and prepare a list of all

Risks identified in these documents. The Business Analyst will review and validate the

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

127

Risks with the project sponsors, project manager, and stakeholders before they are

included in the project documentation. Each Risk should be clearly defined, showing

which task is affected, the assumed affect of the event or condition, the affect of the event

or condition on the task, and what actions can be taken to mitigate or minimize the affect.

Tasks in the critical path of requirements activities should be evaluated and changes to the

task should be identified that could reduce the impact of the Risk. Examples of some ways

to reduce or avoid Risks include:

• Complete tasks simultaneously rather than sequentially

• Assign lead or lag time to a task to work around scheduled resource limitations

• Adjust the start and end times/dates of non-mission-critical tasks

• Add resources to critical activities

• Change the completion date of some of the requirements to a future release

• Identify links between tasks

• Identify dependencies

• Remove the activity from the critical path

.5 Stakeholders

The stakeholders for this task are the project sponsor, project manager, and project team.

.6 Deliverables

The result of this task will be a listing of Risks, their affect, and any actions taken to

mitigate or minimize their affect.

3.7.8 Task: Modify the Requirements Plan

.1 Purpose

When estimates assigned to project tasks become inaccurate because of changes to

project scope, assigned resources, or project schedule, the Business Analyst should re-

evaluate and modify the Requirements Plan to reflect the changes affecting the project.

.2 Description

As work evolves, more detailed and precise data is available to the project team. This task

will modify the Requirements Plan to correct inaccuracies caused by changes and revise

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

128

the project task schedule to more accurately define the project’s health, progress, and

completion.

.3 Predecessors

The project plan and the current project status (mention the BABOK chapter referring to

project reporting).

.4 Process and Elements

The Business Analyst should speak with the sponsor, the stakeholders and others on the

project team to determine if any aspect (scope, schedule, resources) of the plan should be

modified.

Also, the Business Analyst should consider options other than modifying task aspects, like

identify any individual tasks that can be eliminated, determine if the duration of any

individual tasks may be decreased, or revising task assignments.

The agreed upon changes will be made to the plan by the Business Analyst along with

documentation noting the reason(s) for the changes.

.5 Stakeholders

The project sponsor or their representative, the project manager, and other project team

members are stakeholders for this task.

.6 Deliverables

The deliverable from this task will be the revised plan along with documentation noting

the purpose for the change. The format for the revised plan should be documented in a

tool such as Microsoft© Excel or Microsoft© Project.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

129

3.8 Manage Requirements Scope

Managing requirements scope relates to managing the list of the requirements of the

systems development component and/or process improvement and/or organizational

change project. The Business Analyst involvement in requirements scope management is

to establish and maintain requirements baseline, tracing requirements, to identify

impacts to external systems and/or other areas of the project, to identify scope changes

resulting from requirements change, and maintain scope approval.

3.8.1 Task: Establish Requirements Baseline

Baseline is a line or standard by which the changes to requirements are compared; the

established baseline for the list of requirements. It is the point of reference for the

requirements, which is used as a basis for comparison. It becomes the official list of

requirements and it becomes an internal agreement, like a contract, between the client

and the project team. In some organizations, the list of requirements is officially signed-

off at the business requirement level, in the form of the Business Requirement Document.

In other organizations, sign-off to the list of requirements is done at the specification

system requirement level, prior to the system design phase.

.1 Purpose

If the list of requirements is not baselined, then it will be very challenging for the Business

Analyst to manage the Requirements Scope. It is difficult to evaluate what has changed if

the Business Analyst does not know where to start or the point of reference. The

requirements baseline is reviewed throughout the project by the Business Analyst to

ensure scope containment and to identify scope creeps.

.2 Description

Once the requirements have been reviewed and approved, the baseline is established and

becomes the first official document, which is available to all Stakeholders. For iterative

and agile projects, all the requirements are not baselined at the same time. Because a

group of requirements are known at certain phases of the project, a snapshot is taken of

those known and approved group of requirements. The baseline (the snapshot) will be

reviewed throughout the project to ensure its ongoing validity. It may be in the form of an

official Business Requirements Document or an official Specification System

Requirement Document. It is now considered under change control.

.3 Predecessors

The list of requirements, the deliverable from section 5.9 Document Requirements

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

130

.4 Process and Elements

The Business Analyst obtains a formal sign-off of the list of requirements in governance

with the organization’s approval process.

The Business Analyst takes a snapshot of the list of requirements.

Once the snapshot is taken, the list of requirements is under Change Control

Management.

.5 Stakeholders

All Stakeholders listed in section 3.3 Identify Stakeholders

.6 Deliverables

The baselined List of Requirements, now considered under Change Control

Management

3.8.2 Task: Structure Requirements for Traceability

.1 Purpose

Requirements traceability assists in managing changes to the requirements that will occur

after the requirements are baselined. Traceability allows the Business Analyst to verify

several items. First that the interests of all parties affected by a change to the project

requirements are properly considered . Next that all impacts of changes to the solution

scope are properly considered. Lastly, as the elapsed time between the specification of a

requirement and its implementation increases, the need to be able to trace a requirement

increases as well.

Requirements traceability has the following project benefits:

• Traceability aids scope management:

o A functional requirement must be traced back to a business requirement or

feature to prevent misunderstanding customer needs

o A design function must be traced to a functional requirement to prevent

scope creep

o A feature must be traced to lower level requirements to prevent a gap in

fulfilling customer needs.

• Traceability aids change impact analysis:

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

131

o Changes to higher-level requirement are traced to determine what may be

impacted

o Proposed changes can be more thoroughly costed by understanding all

impacts.

• Traceability aids risk based testing:

o A high priority requirement must have a test condition/case

o A low priority requirement traced to a large number of test cases may be over

tested

.2 Description

Requirements traceability supports the ability to trace a requirement through the

development life cycle. The ability to track the requirements is an important technique

used to detect missing functionality or identity if implemented functionality is not

supported by a specific requirement.

Traceability supports the following project goals:

Links downstream work products to the purpose for which they were created

Provides a process to confirm that the Requirements Elicitation process is complete

Ensures that project work is not authorized for items that are outside of project scope

Enables stakeholder notification during the change management process

Increases quality on all projects sizes and types

Facilitates the requirements change control process.

There are several different types of traceability information that the Business Analyst may

maintain:

Source: Indicates where the requirement originated. Used by the Business Analyst to

determine which stakeholders may need to be consulted in regards to a proposed change.

Rationale: Indicates the business goal that the requirement is intended to satisfy. Used by

the Business Analyst to determine if a change in the goals of the business should mandate

a re-evaluation or change in the requirements.

Requirements: Indicates which requirements are interrelated. Used by the Business

Analyst to determine which additional portions of the solution may be indirectly affected

by a proposed change.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

132

Design or Test: Indicates which elements of the solution implement or test a

requirement. Used by the Business Analyst and the Project Manager to determine what

work must be done to implement a change.

Interfaces: Indicates where requirements affect an external interface to another system.

Used by the Business Analyst to determine where changes may impact external systems.

.3 Predecessors

The Business Analyst can begin tracing requirements after Structuring Requirements

Packages.

.4 Process and Elements

Projects can use many different types of tools or relationships between elements to create

products and services. However, there is a common model and common tools that

describes how small projects to complex programs create similar elements during the

system requirements life cycle.

Model

Figure 3.5: Requirements Traceability

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

133

The user and stakeholder needs documented in a business case with high-level product

descriptions will drive all lower level requirements and their dependent deliverables.

Functional requirements are created from an upper level product description.

Supplemental requirements are created from that document, along with inputs received

during Requirements Elicitation.. Design and construction work products or artifacts are

created as a response to specific requirements and can be traced to the upper level need.

Test cases are also created from both the functional requirements and supplemental

requirements.

.5 Techniques

Several techniques assist in ensuring that the project team is well prepared to have

requirements traceable by the end of the analysis phases.

• Clear numbering scheme

• Unique and permanent number for each requirement

• Unambiguous requirements statements

• Assigned team role responsibility for creating or maintaining links

• Documented instruction set for project traceability requirements

• Documented requirements for which work products require direct traceability

Traceability Matrix

The traceability matrix relates one set of elements to another set. For example,

requirements can be traced to the high-level product description, or test cases can be

traced to specific requirements.

Figure 3.1: Tracing high-level product descriptions to Requirements

Requirement 1

Requirement 2

Requirement 3

Requirement 4

Product Description 1

Product Description 2

Product Description 3

Product Description 4

Product Description 5

Analysis can be conducted to determine if there are any missing connections. First we can

look across the row: If a successor item does not have a predecessor item, the team needs

to continue the decomposition and elaboration process to write a requirement. For

example, a requirement needs to be written for high-level product description number 5.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

134

Next we can look down a column: If a successor item is not traced to a predecessor item,

the team needs to review why that requirement was written. It might be an orphan

element that wasn’t deleted with the deletion of its predecessor or a stakeholder may have

added it without project team agreement.

If a predecessor has too many successors, it may be too complex. This will be dependent

upon the project context but it could be considered for additional decomposition it to

improve its clarity. For example, requirement 1 is included in many of the high-level

product descriptions, it may be a common element or it may be too broad. If too many

requirements are included in a product description, it will create a complex text scenario.

Projects can use matrixes to describe any key relationship between work products that are

important to the success of the project.

.6 Stakeholders

Requirements traceability assists the project team in assessing the impact of change

requests and in verifying that the requirements are complete and consistent.

.7 Deliverables

The Business Analyst can complete a traceability matrix showing the interaction of

requirements that will be implemented by the solution.

3.8.3 Task: Identify Impacts to External Systems and/or Other

Areas of the Project

.1 Purpose

In maintaining the list of requirements, the Business Analyst determines where changes to

the requirements that may impact external systems and/or other areas of the project.

.2 Description

The impacts to external systems and other areas of the project ensure that the work is not

authorized for items that are outside the baselined list of requirements. The requirement

change may impact the project schedule, cost, risk and resources, and/or affect an

external interface to another system or project.

.3 Predecessors

The Requirements Traceability Matrix, Interfaces column

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

135

.4 Process and Elements

The Business Analyst identifies any modified, added or removed Requirements that have

information in the Interfaces column in the Matrix.

The Business Analyst communicates the change(s) to the Stakeholder(s). Refer to 3.9.3.5,

below, for a list of possible Stakeholders.

Once the approval process has been completed, the Business Analyst updates the

Requirements Traceability Matrix. The updated Requirements Traceability Matrix

becomes the new baseline where changes to requirements are compared.

For example, for ID 1 in figure 3.9.2.4-1, due to the requirement change where the agent

no longer needs to subscribe to the service, the Design B was removed and Design C was

modified to Notify All Sales Agents. Because Interface is Microsoft Outlook for Design C,

the Business Analyst communicates the change to all interested Stakeholders. In this case,

it would be the Source (Jane Brown), the Developer, the Database Analyst, the Project

Manager and the Lotus Notes owner. Once the approval process is completed, the

updated Requirements Traceability Matrix is the new baseline.

.5 Stakeholders

• The Stakeholders identified in the Source column, i.e. the Solution Owner, in the

Requirements Scope Matrix

• Executive Sponsor

• Project Manager

• The responsible project team member that is affected by the modification, i.e.

Business Analyst, Developer, Quality Assurance Analyst, Data Modeller, etc…

• The responsible project team member of the external system or the external system

owner

.6 Deliverables

The updated the Requirements Traceability Matrix

3.8.4 Task: Identify Scope Change Resulting from Requirement

Change (Change Management)

.1 Purpose

Change Management is the process of controlling changes to the requirements of the

systems development component, process improvement and/or organizational change

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

136

project, in a controlled manner. No meaningful performance (where are we now)

measurements can be made where the requirements are not bounded and under some

form of change control. It is particularly important that Change Management process

have high visibility and open channels of communication to promote smooth transitions

when changes take place.

.2 Description

Scope changes stem from the following types of requirement changes:

New

Modifications to requirements (fixing requirements errors or omissions)

Removal of requirements already in-scope (de-scoping)

In governance with the organization’s change control policy, a formal change control

process is used to identify, evaluate, trace and report proposed and approved changes to

the requirements. In a change control process, approved changes are incorporated in

such a way as to provide an accurate and complete audit trail of the changes.

Because customer requirements are changeable throughout the lifecycle, requirements

are not often complete until the end of its implementation phase. Depending on the level

of the requirement change, it may impact managing the requirements not-at-all or it may

slightly change it or may change it drastically, which will impact the project scope, time,

cost and/or quality.

.3 Predecessors

The baselined List of Requirements and the Requirements Scope Matrix, Requirements

column/field

.4 Process and Elements

The Business Analyst evaluates any updated version of the list of requirements.

If and when a requirement has changed, the Business Analyst determines the impact by

updating the Requirement Traceability Matrix, as preparation for the approval and/or

negotiation process.

The Business Analyst determines if the requirement change is aligned with the objectives

of the project. If it is not (i.e. scope creep), the Business Analyst starts the organization’s

change control process to deem it out of scope for the project.

The Business Analyst determines any gaps due to the requirement change. The Business

Analyst take the necessary steps to have the identified gaps fulfilled.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

137

The Business Analyst review and compare the requirement change with existing

requirements with all Key Stakeholders and determine its relative Priority and business

value (Rationale).

The Business Analyst commence the organization’s change control process to obtain

approval and sign-off for inclusion or exclusion of the requirement in/out of scope for the

project based on review and agreement of all relevant information. Disposition based on

results as to when it will be delivered or if it will be deemed out of scope.

Once the approval process has been completed, the Business Analyst updates the

Requirements Traceability Matrix. The updated Requirements Traceability Matrix

becomes the new baseline where changes to requirements are compared.

.5 Stakeholders

All Stakeholders listed in section 3.3 Identify Stakeholders that are affected by the change

to the requirement

.6 Deliverables

New baseline for the List of Requirements and the updated Requirements Traceability

Matrix

3.8.5 Task: Maintain Scope Approval

.1 Purpose

The impact of not having an approved list of requirements is confusion regarding

Stakeholders’ expectations for the project. It is a mutual understanding between customer

and team about the requirements. As the project progresses, it is more difficult and costly

to repair requirements errors.

.2 Description

After the list of requirements is created, reviewed, verified and approved, it is put under

configuration/change management in order to control the iterative changes that occur

over the rest of the project lifecycle. It must be approved for every version of it.

.3 Predecessors

The baselined List of Requirements and the Requirements Traceability Matrix

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

138

.4 Process and Elements

For every version of the list of requirements, the Business Analyst commences the change

control process in accordance with the organization’s change control policy.

Once the approval process has been completed, the Business Analyst baseline the

updated list of requirements and updates the Requirements Traceability Matrix. The

updated list of requirements and the updated Requirements Traceability Matrix becomes

the new baseline where changes to requirements are compared.

.5 Stakeholders

All Stakeholders listed in section 3.3 Identify Stakeholders that are affected by the

requirements change.

.6 Deliverables

New baseline for the List of Requirements and the updated Requirements Traceability

Matrix

3.9 Measure and Report on Requirements Activity

It is suggested from the high failure rate of many projects that many do not effectively keep

track of the metrics of their teams and products. It is impossible to effectively manage

anything without an effective system of measurement and comparison to standards or

objectives.

A 1995 Standish Group study (CHAOS) found that only 16.2% of IT projects were

successful and over 31% were canceled before completion, costing over $81 B in the U.S.

alone.

There was an increase in success by 2001 according to the Standish Group research.

“The reasons for the increase in successful projects vary. First, the average cost of a

project has been more than cut in half. Better tools have been created to monitor and

control progress and better skilled project managers with better management processes

are being used. The fact that there are processes is significant in itself.

”

A metric is a quantitative measure of a process or product. It is used to describe what is to

be measured. It may also be used to set a goal/objective to be measured against to define

when a goal is met (or not!).

In order for the Business Analyst (and Project Manager) to make effective decisions about

the project and the product; then accurate, meaningful data is required.

The Standish Group, "CHAOS 2001: A Recipe for Success" (2001)

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

139

Examples of questions to be answered (and the needed metrics to be collected) might

include the following:

• Are we on schedule?

• How are we doing compared to the budget?

• What is the quality of the product?

• Do we have enough people assigned to the project?

Notice that we have assumed that schedule and budget metrics as well as product quality

metrics will be determined and compared to the actual collected data.

By answering these and similar questions through the use of collected metrics, the

Business Analyst will be able to take action to address any identified problem(s).

Every project has a project life cycle regardless of the product(s) created in it.

Every product has a product life cycle model that will vary considerably due to the nature

of the product. Each of these must be measured and managed by the Project Manager and

the Business Analyst.

Accordingly, there is a natural division in the kinds of metrics that the Business Analyst

must determine, collect and report during the life of the project. These are the following:

• Project Metrics – measurements of the type associated with the project (Cost, effort,

schedule, risk, resources, etc.))

• Product Metrics – measurements associated directly with the product of the project

(Defects, performance, size, etc.)

Metrics collection and analysis must be regularly monitored and measured. The results

should be reviewed on a scheduled basis, and must also allow for exception alarms on an

emergency basis when needed. The actual schedule of metrics collection and reporting

will be determined by the Business Analyst in conjunction with other key stakeholders

based on the size, complexity, risk and other relevant project factors.

The Business Analyst must determine the Product and Project metrics needed to be able

to effectively and efficiently measure and report on the requirements activities in the

project.

It is important to the success of the project that all key stakeholders involved understand

the metrics to be used.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

140

For example, on some projects, the success will be more closely measured and evaluated

based on the costs of the project rather than schedule related metrics. On others, the

primary metric may be the number of defects that are found and fixed in the product.

During this activity, the Business Analyst must work closely with the Project Manager in

identifying, understanding and documenting the best set of Project and Product metrics.

The Business Analyst typically will be involved in all requirements related activities while

the Project Manager is more naturally concerned with all project activities.

Different organizations may have metrics standards used in their projects. The metrics

that are discussed in this section may be critical to some organizations; while in others or

on other projects many metrics may not be used at all.

The Business Analyst should take any of their organization existing standards into

account when reading this section and especially when executing these tasks in their

project.

The remainder of this section will be involved in the three types of tasks for both product

and project related metric – the Identification, Collection and Reporting of these key

measurements.

A suggested sequence of steps for the Business Analyst includes the following:

• Determine relevant metrics for the requirements activities.

• Determine how the metrics will be collected, analyzed, documented, and

communicated.

Execute the following steps on a continuing scheduled basis:

• Collect

• Analyze

• Store

• Report and distribute the metric results

It should also be noted by the Business Analyst that all metrics that are determined must

be controlled under whatever change control process has been implemented for the

project as these are certainly subject to change during the project.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

141

3.9.1 TASK: Determine the Project Metrics

.1 Purpose

The purpose of this task is to identify and document all project metrics that will be used in

the requirements related project activities. The Business Analyst must work closely with

the Project Manager to identify these for each particular project.

Some of the metrics discussed below, as well as others that may be defined within an

organisation, may or may not be used on any particular project. Some metrics may also

be collected and reported only at specific points of the project, while others may be in

existence throughout the entire project.

.2 Description

This task will enable the Business Analyst to identify and document the necessary project

metrics. This will enable the Business Analyst to insure that all of these measurements will

be collected and reported to the appropriate stakeholders.

.3 Predecessors

Inputs to this task will include the current project plan. Any available project standards

documents may also prove useful in identifying the important project metrics. PLC and

SDLC standards, if available, may also prove useful in this task. Other metrics may be

determined by specific requirements of individual stakeholders, e.g. a cost metric to track

costs chargeable to a particular resource on a specific task.

.4 Process and Elements

Many organizations may have standards applicable to defining project metrics for any

type of project. For example, many PLC’s will define milestone use as well as specific cost

measurements that the Business Analyst must use in metrics collection and reporting.

Specific report formats may also be defined in this task or typically may be deferred until

the reporting task discussed below.

Typical project metrics might include the number of effort hours per standard tasks,

number of defects per hour of tester time, cost per hour of various levels of resources,

number of follow up sessions per a JAD session, etc. The key for the Business Analyst is to

determine which of the unlimited number of metric possibilities would be the most

valuable to him/her in managing and effectively controlling the requirements processes.

A suggestion for the Business Analyst is to ask the question of “What is our goal”, how do

we measure attainment of this goal, and what measurements are needed to check

attainment. Another key consideration is the amount of effort needed to collect, analyze

and report on this metric.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

142

.5 Stakeholders

Stakeholders who should play a part in this task include any project stakeholders but will

typically include those stakeholders responsible/involved with controlling or approving

the requirements activities cost, schedule, and resource scheduling.

.6 Deliverables

The deliverables from this task will typically include a descriptive list of all of the

currently identified project metrics for this specific project.

3.9.2 TASK: Determine the Product Metrics

Determining effective product metrics will demand a detailed and disciplined process as

usually good metrics depend on both the product's goals and any assumptions that may

have been made. It is part of the job of the Business Analyst to elicit and identify these

during this task.

This task may prove to be especially difficult during software development projects since

the optimum metrics to use are still poorly understood making the identification of the

proper metrics to use more difficult. One approach that aids greatly in determining

effective product measurements is to include an explanation of the “why” for a particular

metric to be used.

.1 Purpose

The purpose of this task is to identify and document all product metrics that will be used

with the requirements related project activities. The Business Analyst must work closely

with the Project Manager to identify these for each particular project.

Some of the metrics discussed below, as well as others that may be defined within an

organization, may or may not be used on any particular project. Some of the metrics may

also be collected and reported at specific points of the project, while others may be in

existence throughout the entire project.

.2 Description

This task will enable the Business Analyst to identify and document the necessary product

metrics. This will enable the Business Analyst to insure that all of these measurements will

be collected and reported to the appropriate stakeholders.

The Business Analyst is trying to determine the “fitness’ of the product for its intended

purpose as well as the “quality’ of the product during this task.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

143

.3 Predecessors

The major input for this task will be the detailed product requirements. Also typically

used will be any standards available within the organization for the type of products

created during the project.

.4 Process and Elements

The Business Analyst will use the product requirements list to identify any specific quality

measurements that will be used to judge the product i.e. to answer the question of

whether the product will meet the requirements. Specific reports content and formats

may also be determined at this point but typically will be done in a later task.

The requirements identified in this task are closely related to the product itself and will

usually not be created by the Business Analyst. The Business Analyst will question the

product team members such as marketing and sales to determine what these

requirements should be. It is more a task of eliciting these from other stakeholders rather

than identifying/determining themselves. A clear requirement of the Business Analyst

during this task is to uncover and document any assumptions held by any of the key

stakeholders.

An example of a useful metric might be the rate at which the development team is finding

and fixing product defects. This would have to be clearly defined regarding how to

measure this and what the target for being able to ship the product might be.

Suggestions for initiating a product metrics program include the following:

• Select a small set of metrics initially and add to it carefully as needed

• The effort to collect and report must be less than their value

• Metrics must not be used as a personnel evaluation

• Explanation of the metrics selected to the team is critical

• Keep no secrets and share the data

• Define the data and formulas used.

• Trends are much more significant than individual data points

• Understand that metrics may be initially threatening to many team members

.5 Stakeholders

Stakeholders who should play a part in this task typically include such stakeholders as

Executive Sponsor, Product Manager, as well as the project team members.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

144

.6 Deliverables

The deliverables from this task will typically include a descriptive list of all of the

currently identified project metrics for this specific project.

3.9.3 TASK: Collect Project Metrics

.1 Purpose

The purpose of this task is to collect the specific project metrics identified above for all

requirements related tasks.

.2 Description

This task will enable the Business Analyst to collect the identified project metrics. This

will enable the Business Analyst to insure that all relevant metrics are accurately collected

for analysis and reporting.

.3 Predecessors

The primary input to this task will be the list of project metrics identified in a previous

task.

.4 Process and Elements

Project metrics must be collected with as little effort and impact as possible. Ideally these

should be collected automatically.

This task is typically completed by all team members – the often disrespected weekly task

of entering their actual time spent on various assigned project tasks. It is critical that this

collection of “actuals” be done accurately and in a timely manner. Besides project team

members effort, the collection of these metrics may include the collection of other

resources used on the project.

This task is an ongoing one that will be executed as long as there are any active

requirements related activities going on in the project

.5 Stakeholders

Stakeholders for this task are typically all team members involved in any project tasks.

.6 Deliverables

The deliverable from this task will typically be a list of the identified project metrics with

any current values as well as the updated automated data base for storage of them.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

145

3.9.4 TASK: Collect Product Metrics

The process of collecting product metrics and the analysis of the collected data requires a

considerable amount of time and effort. A primary purpose of this task is to raise

appropriate alarms when and to whom as appropriate at the work product level.

.1 Purpose

The purpose of this task is to collect the specific product metrics identified above for all

requirements related tasks.

.2 Description

This task will enable the Business Analyst to collect the identified and agreed to product

metrics. In turn, this will enable the Business Analyst to insure that all relevant metrics are

accurately collected for analysis and reporting. Much of the data collection in this task

will take place during the various product testing and review tasks identified in the project

plan.

This task is an ongoing one that will be executed as long as there are any active product

testing/review activities going on in the project

.3 Predecessors

The primary input to this task will be the list of product metrics identified in the previous

task as well as the appropriate defined processes to collect and process the collected data.

.4 Process and Elements

Product metrics must be collected with as little effort and impact as possible. Ideally these

should be collected automatically. The identified metrics will be available from any of the

product testing and review tasks.

.5 Stakeholders

Stakeholders for this task are typically all team members involved in any product testing

and/or review project tasks.

.6 Deliverables

The deliverable from this task will typically be a list of the identified product metrics with

any current values as well as an updated automated data base for storage of them.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

146

3.9.5 TASK: Reporting Product Metrics

.1 Purpose

The purpose of this task is to report the specific product metrics for all requirements

related tasks identified above. It is highly recommended that an automated system be

used for collecting and reporting this information.

.2 Description

This task will enable the Business Analyst to report the identified and agreed to product

metrics. This will enable the Business Analyst to insure that all relevant metrics are

accurately analysed and reported.

Although this document discusses reporting the Project and Product metrics separately, it

is possible although not typical some of these measurements might be combined in a

single report. It should be a matter of what the responsible stakeholders are looking for

and will be effective with. The reporting system should be capable of combining any and

all of this information.

.3 Predecessors

The primary input to this task will be the product metrics collected in a previous task and

the updated database of up-to-date metrics

.4 Process and Elements

Product metrics must be reported to the appropriate stakeholders. The Business Analyst

is responsible for identifying the correct set of stakeholders to receive any of the various

product metric reports that may be available. He/she is also responsible to identify those

stakeholders who should have access to any ad-hoc reporting capabilities that are

available. This capability is highly recommended if at all possible as it will, if properly

implemented and controlled, save the busy Business Analyst and Project Manager a great

deal of time in responding to stakeholder information requests.

A key task of the Business Analyst is to identify the optimum reporting periods for the

different levels of product information, i.e. should status be reported daily, weekly, bi-

weekly or monthly? How detailed should the reports be? Who should receive what

metrics? These must often be negotiated among the stakeholders, Project Manager, and

Business Analyst and ideally should be determined product, project and stakeholder

considerations.

The Business Analyst must remember that “Trend Analysis” is often a key capability in

metrics reporting and design the reporting capability accordingly.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

147

.5 Stakeholders

Stakeholders for this task are all stakeholders involved with the creation of product

metrics or those responsible for making project or organization decisions based on these

measurements.

.6 Deliverables

The deliverable from this task will typically be a series of defined and ad-hoc reporting

capabilities utilising the identified product metrics.

3.9.6 TASK: Reporting Project Metrics

Project status reports are most often used to report on the status of project metrics. The

exact format and content is typically at least partially defined by the organization project

standards or perhaps by the PLC. Generally speaking within any project management

methodology, there can be seen five primary criteria that are common:

• Time (i.e. schedule)

• Cost (i.e. budget)

• Resources (Who and how much)

• Features (Any feature creep occurring)

• Quality (Defects versus plan)

These are the capabilities that should be designed into the project status reporting. It is up

to the Business Analyst, in close co-operation with the project manager, to identify which

stakeholders need to be recipients of which type, level of detail, and frequency of the

available types of project metric data.

Naturally, the format and media of the “reports” may vary according to the needs of the

audience.

.1 Purpose

The purpose of this task is to report the specific project metrics for all requirements

related tasks identified above. The identified metrics will be available from any of the

requirement activity project tasks.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

148

.2 Description

This task will enable the Business Analyst to report the identified and agreed to project

metrics. This will enable the Business Analyst to insure that all relevant metrics are

accurately analysed and reported.

.3 Predecessors

The primary input to this task will be the project metrics collected in the previous task.

.4 Process and Elements

Project metrics must be reported to the appropriate stakeholders. The Business Analyst is

responsible for identifying the correct set of stakeholders to receive any of the various

project status reports that may be available. He/she is also responsible to identify those

stakeholders who should have access to any ad-hoc reporting capabilities that are

available on the project. This capability is highly recommended if at all possible as it will,

if properly implemented and controlled, save the busy Business Analyst and Project

Manager a great deal of time in responding to stakeholder information and status

information.

A key task of the Business Analyst is to identify the optimum reporting periods for the

different levels of project status information, i.e. should status be reported daily, weekly,

bi-weekly or monthly? How detailed should the reports be? Who should receive what

metrics? These must often be negotiated among the stakeholders, Project Manager, and

Business Analyst and ideally should be determined by the size, complexity, criticality,

and other relevant project and stakeholder considerations.

The Business Analyst must remember that “Trend Analysis” is often a key capability in

metrics reporting and design the reporting capability accordingly.

.5 Stakeholders

Stakeholders for this task are all stakeholders involved with the input of project metrics or

those responsible for making project or organization decisions based on these

measurements.

.6 Deliverables

The deliverable from this task will typically be a series of defined and ad-hoc reporting

capabilities utilising the identified project metrics.

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

149

3.10 Manage Requirements Change

3.10.1 Plan Requirements Change

.1 Task - Determine who should be involved in handling

requirements changes

Content will describe which roles on a project should be involved in reviewing and

approving requirements changes; which project roles need to know about requirements

changes

.2 Task - Define how Requirements Changes will be administered

and communicated

Material will describe mechanisms for logging changes and communicating changes.

3.10.2 Understand the changes to requirements

.1 Task - Identify issues / changes

Capture any issues or requirements changes identified by the project stakeholders or

project team

Communicate information to project change management team for impact analysis

.2 Task - Participate in impact analysis

Participate in the project change management teams review of the identified issues or

requested changes

Present additional background information and/or supporting documentation

3.10.3 Document the changes to requirements

.1 Task - Create Formal Change Request

Ensure changes are formally included in the revised Requirements Documents

.2 Create Formal Change Request

Once the change has been approved, a formal change request shall be generated

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

150

The change request is a mandatory deliverable when a change occurs but does not have a

mandatory template

.3 Task - Define links to other requirements

• Revisit requirements document to ensure all impacted requirements are updated

• Note changes within the ‘Revision History’ section

3.10.4 Analyze change requests

.1 Task - Conduct fact-finding to obtain a greater understanding

of the requirements change, operational context, and potential

issues

• Interview stakeholders or project team members to better understand the issue or

request

• Determine if the requested change is within the scope of the project

• Trace impact of the change back to other high level or detail project requirements

• Determine impact of executing the change on external processes, people or systems

• Validate analysis with other team members

.2 Task - Categorize / prioritize requirements

• Determine how critical this change is to the success of the project and the impact of

not executing it

• Classify the change request into one of the major groups / types of requirements

identified within the HLRD or DRS

• Prioritize the changes by level of criticality (e.g., high, medium, low)

• Calculate cost and development effort to implement the requested change

.3 Task – submit changes for approval

• Submit to requirements approvers and project sponsor for sign-off

• Track changes to requirements

• Make sure client requirements are captured accurately, completely and succinctly

Chapter 3 Requirements Planning and Management

A Guide to the Business Analysis Body of Knowledge, Release 1.6

http://www.theiiba.org

151

• Ensure each changed requirement is traceable back to its source

• Identify change request information within the ‘Revision History’ section of the High

Level Requirements Document and the Detailed Requirements Specifications

• Define links to other requirements

• Revisit requirements documents to ensure all impacted requirements are updated

• Note changes within the ‘Revision History’ section

3.11 References

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

152

Chapter 4: Requirements Elicitation

4.1 Introduction

Eliciting requirements is a key task in business analysis. Because the requirements serve as

the foundation for the solution to the business needs it is essential that the requirements

be complete, clear, correct, and consistent. Leveraging proven means to elicit

requirements will help meet these quality goals.

The word elicit is defined

1. to draw forth or bring out (something latent or potential)

2. to call forth or draw out (as information or a response)

These definitions highlight the need to actively engage the stakeholders in defining

requirements.

This chapter includes details for eliciting requirements for a target system. The system in

question may be a business system, an automated system, or both. The scope may be a

new system or an enhancement to an existing system.

The business analyst should understand the commonly used techniques to elicit

requirements, should be able to select appropriate technique(s) for a given situation, and

be knowledgeable of what is required to prepare, execute and complete each technique.

Eliciting requirements is not an isolated, compartmentalized activity. Typically,

requirements are identified throughout the elicitation, analysis, and review activities

performed by a business analyst. For example: requirements may be elicited in interviews

and/or facilitated meetings. Later, when those requirements are used to build and verify

model(s) the business analyst may discover gaps in the requirements. This will then

require eliciting details of those newly identified requirements, using techniques outlined

in this chapter.

4.1.1 Relationships to Other Knowledge Areas

.1 Input to Requirements Elicitation

The techniques included in this Requirements Elicitation KA can be used to effectively

elicit many types of requirements.

Input to eliciting Enterprise Analysis requirements: A variety of means may be used to

elicit business requirements and are dependent on the type of study, e.g. Creating a

Business Architecture or Identifying Business Opportunity.

Merriam Webster

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

153

Input to eliciting user requirements: In the situation where Enterprise Analysis has been

completed and the project is ready to elicit user requirements, the following inputs are

typical:

• The Enterprise Analysis KA activities define the overall scope of the problem and

solution domain and the goals. The business analyst uses the scope definition and

goals to provide the boundaries for all requirements elicitation.

• The Requirements Planning and Management KA activities identify and

describe:

o the stakeholders,

o the requirements documentation and the deliverables that will be

created,

o the appropriate technique(s) to elicit requirements that will be

employed,

o the requirements traceability strategy that will be followed,

o the requirements’ attributes that will be captured, and

o the outputs of requirements elicitation.

.2 Output of Requirements Elicitation

Unlike other knowledge areas, e.g. Requirements Analysis and Documentation, the

Requirements Elicitation KA does not have a prescribed set of deliverables. It is expected

that the business analyst will reach a point during requirements elicitation when he/she

feels that sufficient material has been elicited from the business experts to enable analysis

and documentation to begin. The combined results of all the elicitation techniques used

will serve as input to building the selected analytical models. Missing, incomplete or

incorrect requirements will ideally be exposed during the analysis activities thus

requiring additional requirements elicitation.

A number of techniques listed in this chapter are difficult to separate from the analysis

tasks defined in the Requirements Analysis and Documentation KA. For example,

Requirements Workshops (which are described later in this chapter) start by eliciting

requirements and often end with the creation of models such as activity diagrams,

prototypes, or even data models. Such tightly coupled techniques are cross referenced in

both Chapter 4 and Chapter 5.

4.2 Task: Elicit Requirements

4.2.1 Purpose

The Business Analyst engages the stakeholders to elicit the essential needs of the system.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

154

4.2.2 Description

Determine business requirements, assumptions, current reality, and constraints by

communicating with stakeholders using a variety of techniques.

4.2.3 Knowledge

The business analyst must have knowledge of:

• Elicitation and research approaches

• Effective elicitation techniques

• The business organization and domain.

4.2.4 Skills

The business analyst must be skilled in:

• Eliciting and assessing information

• Interviewing

• Facilitating collaborative sessions

• Observation

• Resolving conflicts; eliminating root cause of conflicts; reaching consensus

• Thinking abstractly; finding and leveraging patterns

• Writing, business documentation

• Listening and oral communication.

4.2.5 Predecessors

A definition of the system’s scope is the minimum requisite needed to frame and contain

the requirements elicitation activities. See 4.1.1.1 for details on input to this task.

4.2.6 Process

.1 Prepare for Elicitation

Participants: Eliciting requirements is highly dependent on the knowledge of the

stakeholders, their willingness to participate in defining requirements, and the group’s

ability to reach consensus. The business analyst must be certain to include all defined

stakeholders during elicitation of requirements. The business analyst may find it

necessary to further clarify and possibly restate the requirements to encompass all

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

155

stakeholders’ perspectives. See Chapter 6, Requirements Communication, for details on

Managing Requirements Conflicts/Contradictions and techniques to reach consensus.

Techniques: The business analyst is responsible for coordinating the activities and

employing the appropriate techniques used to elicit requirements.

To fully examine and define the requirements a combination of complementary

elicitation techniques is typically used. The Requirements Planning and Management KA

activities include evaluating and selecting the appropriate requirements elicitation

techniques. A number of factors (the business domain, the corporate culture and

environment, the skills of the analyst and the requirements deliverables that will be

created) guide which techniques will be used.

The following requirements elicitation approaches are defined in this chapter:

Elicitation Technique

Synonym(s)

Brainstorming

Document Analysis

Review existing documentation

Focus Group

Interface Analysis

External Interface Analysis

Interview

Observation

Job Shadowing

Prototyping

Storyboarding, Navigation Flow

Requirements Workshop

Elicitation Workshop

Facilitated Workshop

Joint Application Design (JAD)

Reverse Engineering

Survey

Questionnaire

Table 4-1 Commonly used Requirements Elicitation Techniques

.2 Conduct Elicitation

Tracing requirements: While eliciting the requirements the business analyst must guard

against “scope creep”. Tracing requirements back to the business goals/objectives helps

to validate whether a requirement should be included. See Chapter 3, Requirements

Planning & Management, Section 3.9.4 for details on traceability.

Capturing requirement attributes: The business analyst will document the attributes

which can be initially identified during requirements elicitation such as each

requirement’s source, value, and priority. See Chapter 3, Requirements Planning &

Management, Section 3.9.5 for details on requirement attributes.

Use of glossary: Creation and use of a business glossary is an essential asset for all

requirements elicitation techniques. The glossary should contain key domain terms along

with their business definitions.

4.2.7 Stakeholders

• Business Owner

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

156

• Business User

• Domain Expert

• Project Manager

• Project Team

4.2.8 Deliverables

See 4.1.1.2

4.3 Technique: Brainstorming

4.3.1 Purpose

Brainstorming is an excellent way of eliciting many creative ideas for an area of interest.

Structured brainstorming produces numerous creative ideas about any given "central

question" or topic.

4.3.2 Description

In 1939, a team led by advertising executive Alex Osborn coined the term "brainstorm."

According to Osborn, “Brainstorm means using the brain to storm a creative problem

and to do so "in commando fashion, each stormer audaciously attacking the same

objective."

Brainstorming is a technique that promotes diversion type of thinking. Diversion refers to

those team activities that produce a broad or diverse set of options. Brainstorms help

answer specific questions such as (but not limited to):

• What options are available to resolve the issue at hand?

• What factors are constraining the group from moving ahead with an approach or

option?

• What could be causing a delay in activity ‘A’?

• What can the group do to solve problem ‘B’?

Brainstorming works by focusing on a topic or problem, and then coming up with many

radical solutions to it. This technique is best applied in a group as it draws on the

experience and creativity of all members of the group. In the absence of a group, one

could brainstorm on one’s own to spark new ideas.

4.3.3 Intended Audience

Ideas generated in a brainstorming session are consumed by any or all of the following:

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

157

• Project team

• Stakeholders

4.3.4 Process

.1 Prepare for Brainstorming

• Develop a clear and concise definition of the area of interest.

• Determine a time limit for the group to generate ideas, the larger the group, the

more time required.

• Decide who will be included in the session and their role – participant or

facilitator. Aim for participants (ideally 6 to 8) who represent a range of

background and experience with the topic.

• Establish criteria for evaluating and rating the ideas.

.2 Conduct Brainstorming session

• Share new ideas without any discussion, criticism or evaluation.

• Visibly record all ideas.

• Encourage participants to be creative, share exaggerated ideas, and build on the

ideas of others.

• Don’t limit the number of ideas as the goal is to elicit as many ideas as possible

within the time period.

.3 Wrap-up the brainstorming

• Once the time limit is reached, using the pre-determined evaluation criteria,

discuss and evaluate the ideas.

• Create a condensed list of ideas, combine ideas where appropriate, and eliminate

duplicates.

• Rate the ideas. There are many techniques that can be used to prioritize the ideas,

e.g. multivoting.

• Distribute the final list of ideas to appropriate parties.

4.3.5 Usage Considerations

.1 Strengths:

• Able to elicit many ideas in a short time period.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

158

• Non-judgmental environment enables outside-the-box thinking.

.2 Weaknesses:

• Dependent on participants’ creativity.

4.4 Technique: Document Analysis

4.4.1 Purpose

Document analysis is a means to elicit requirements of an existing system by studying

available documentation and identifying relevant information.

Document analysis is used if the objective is to gather details of the “As Is” environment

such as existing business rules, entities, and attributes that need to be included in a new

system or need to be updated for the current system. This technique would also apply in

situations where the subject matter experts for the existing systems are no longer with the

organization, or are not going to be available throughout the duration of the

requirements elicitation process.

4.4.2 Description

Requirements elicitation typically includes analysis of documents such as business plans,

market studies, contracts, requests for proposals, statements of work, memos, existing

guidelines, procedures, training guides, competing products literature, published

comparative product reviews, problem reports, customer suggestion logs, and existing

system specifications to list a few. Identifying and consulting all likely sources of

requirements will result in improved requirements coverage assuming the

documentation is up to date.

4.4.3 Intended Audience

• Project Team

• Subject Matter Experts

4.4.4 Process

.1 Prepare for Document Analysis:

• Evaluate which existing system and business documentation are relevant and

appropriate to be studied.

.2 Analyze the documents:

• Study the material and identify relevant business details.

• Document business details as well as questions for follow-up with subject matter

experts.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

159

.3 Post Document Analysis wrap-up:

• Review and confirm the selected details with subject matter experts.

• Obtain answers to follow-up questions.

4.4.5 Usage Considerations

.1 Strengths:

• Not starting from a blank page.

• Leveraging existing materials to discover and/or confirm requirements.

• A means to cross-check requirements from other elicitation techniques such as

interviews, job shadowing, surveys or focus groups.

.2 Weaknesses:

• Limited to “as-is” perspective.

• Existing documentation may not be up-to-date or valid.

• Can be a time-consuming and even tedious process to locate the relevant

information.

4.5 Technique: Focus Group

4.5.1 Purpose

A focus group is a means to elicit ideas and attitudes about a specific product, service or

opportunity in an interactive group environment. The participants share their

impressions, preferences and needs, guided by a moderator.

4.5.2 Description

A focus group is composed of pre-qualified individuals whose purpose is to discuss and

comment on a topic. This is an opportunity for individuals to share their own

perspectives and discuss them in a group setting. This could lead participants to re-

evaluate their own perspectives in the light of others’ experiences. A trained moderator

manages the administrative pre-work, facilitates the session and produces the report.

As this elicitation technique is considered a form of qualitative research, the session

results are analyzed and reported as themes and perspectives, rather than numerical

findings. The report may also include selected quotations to support the themes.

A traditional focus group gathers in the same physical room. An online focus group

allows members to be located remotely while participating by a network connection.

Each approach has pros and cons in terms of logistics and expenses.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

160

A focus group can be utilized during any life-cycle state: exploratory, under

development, ready to launch, or in production. If the group’s topic is a product under

development, the group’s ideas are analyzed in relationship to the stated requirements.

This may result in updating existing requirements or uncovering new requirements. If the

topic is a completed product that is ready to be launched, the group’s report could

influence how to position the product in the market. If the topic is a product in

production, the group’s report may provide direction on the revisions to the next release

of requirements. A focus group may also serve as a means to assess customer satisfaction

with a product or service.

4.5.3 Intended Audience

Depending on the topic of the focus group, the report may be directed to the:

• Stakeholders

• Business analyst

• Marketing.

4.5.4 Process

.1 Prepare for the Focus Group

Recruit Participants

A focus group typically has 6-12 attendees. It may be necessary to invite twice as many

individuals in order to allow for no-shows. If many people need to participate, it may be

necessary to run more than one focus group.

The topic of the focus group will influence who should be recruited. If the topic is a new

product, it is likely that existing users (experts and novices) should be included. There are

pros and cons that should be considered when using homogeneous vs. heterogeneous

composition.

• Homogeneous – individuals with similar characteristics. Caution: Differing

perspectives will not be shared. Possible solution: conduct separate sessions for

different homogeneous groups.

• Heterogeneous – individuals with diverse backgrounds, perspectives. Caution:

Individuals may self-censor if not comfortable with others’ background resulting

in lower quality of data collected.

Assign the moderator and recorder

The moderator should be experienced in facilitating groups. Typical skills include:

promote discussion; ask open questions; facilitate interactions between group members;

engage all members; keep session focused; remain neutral; be adaptable and flexible.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

161

Create discussion guide

The guide includes goals/objectives of the session and five to six open questions.

Reserve site and services

Select the location for the session. Arrange for technical support to transcribe the session

and, if used, audio/video taping equipment.

.2 Run the focus group session

The moderator guides the group’s discussion, follows a preplanned script of specific

issues and ensures the objectives are met. However, the group discussion should appear

free-flowing and relatively unstructured for the participants. A session is typically 1 to 2

hours in length. A recorder captures the group’s comments.

.3 Produce Report

The moderator objectively analyzes and documents the participants’ agreements and

disagreements and synthesizes them into themes.

4.5.5 Usage Considerations

.1 Strengths:

• Ability to elicit data from a group of people in a single session saves time and

costs as compared to conducting individual interviews with the same number of

people.

• Effective for learning people’s attitudes, experiences and desires.

• Active discussion and the ability to ask others questions creates an environment

where participants can consider their personal view in relation to other

perspectives.

.2 Weaknesses:

• In the group setting, participants may be concerned about issues of trust, or may

be unwilling to discuss sensitive or personal topics.

• Data collected (what people say) may not be consistent with how people actually

behave.

• If the group is too homogenous the group’s responses may not represent the

complete set of requirements.

• A skilled moderator is needed to manage the group interactions and discussions.

• It may be difficult to schedule the group for the same date and time.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

162

• If the goal of the focus group is to elicit ideas on a new or changing product, a

focus group is not an effective way to evaluate usability.

4.6 Technique: Interface Analysis

4.6.1 Purpose

An interface is a connection between two components. Most systems require one or

more interfaces with external parties, systems or devices. Interface analysis is initiated by

project managers and analysts to reach agreement with the stakeholders on what

interfaces are needed. Subsequent analysis uncovers the detailed requirements for each

interface.

4.6.2 Description

Interfaces types include:

• User interfaces - includes human user directly engaged with the system as well as

reports provided to the user

• Interfaces to and from external systems

• Interfaces to and from external hardware devices

The users, external systems and systems that own the devices are considered stakeholders.

Interface analysis helps to clarify the boundaries of the system. It distinguishes which

system provides specific functionality along with the input and output data needs. By

clearly and carefully separating the requirements for each system, while jointly defining

the shared interface requirements, a basis for successful interoperability is established.

It is important to look at the requirements across all interfaces. For example, data used for

one interface may also be used for other activities and interfaces. Building a

comprehensive glossary and data dictionary where all data is captured consistently and

non-redundantly is critical. The data can then be referenced, even traced, to all interfaces

where it is used.

4.6.3 Intended Audience

• Business Analysts and UI Designers working on detailed User Interface

requirements.

• Designers and Data Modelers designing system-to-system requirements.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

163

4.6.4 Process

.1 Prepare for Interface Analysis:

Identify the necessary interfaces. An effective means to visualize the interfaces is to draw a

Context Diagram. See Chapter 2 for details on the technique “Context/Business Domain

Diagram”, also Chapter 3 for details on “Stakeholders”.

.2 Conduct Interface Analysis:

For each interface:

• Determine its type: user interface, system-to-system interface, external hardware

device interface

• Elicit specific details about the interface, depending on its type.

o For an interface where the user directly engages the system, see Chapter 4,

Prototyping and Chapter 5 for details on the technique “Usage Models”.

o For an interface where a stakeholder receives a report, see Chapter 5

(reference is yet to be determined)

o For a system-to-system interface or an interface with an external hardware

device see Chapter 5 for details on the task “Define Supplementary

Specifications, Interface Requirements”.

4.6.5 Usage Considerations

.1 Strengths:

• The elicitation of the interfaces’ functional requirements early in the system life

cycle provides valuable details for project management:

o Impact on delivery date. Knowing what interfaces are needed, their

complexity and testing needs enables more accurate project planning and

potential savings in time and cost.

o Collaboration with other systems or projects. If the interface to an existing

system, product or device and the interface already exists, it may not be easily

changed. If the interface is new, then the ownership, development and testing

of the interface needs to be addressed and coordinated in both projects’ plan.

In either case, eliciting the interface requirements will require negotiation

and cooperation between the owning systems.

.2 Weaknesses:

• Does not provide an understanding of the business process since this technique

only exposes the inputs, outputs and key data elements related to the interfaces.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

164

4.7 Technique: Interview

4.7.1 Purpose

An interview is a systematic approach to elicit information from a person or group of

people in an informal or formal setting by talking to the person - the interviewee, asking

relevant questions and documenting the responses. (This section considers the business

analyst in the role of interviewer.)

4.7.2 Description

In an interview, a business analyst formally or informally directs his/her questions to: a

stakeholder / a subject-matter-expert / a potential user to obtain answers that finally take

the shape of requirements. One-on-one interviews are typically most common. In a

group interview (more than one interviewee in attendance) the interviewer must be

careful to solicit responses from all attendees.

For the purpose of eliciting business requirements, interviews are of two basic types:

• Structured interview, where the business analyst has a pre-defined set of

questions and is looking for answers.

• Unstructured interview, where, without any pre-defined questions, the business

analyst and the interviewee discuss in an open-ended way what the business

expects from the target system.

Successful interviewing depends on several factors such as, but not necessarily limited to:

• Level of understanding of the business analyst in that business domain.

• Experience of the business analyst in conducting interviews.

• Skill of the business analyst in documenting the discussions.

• Readiness of interviewee to provide the relevant information.

• Degree of clarity in interviewee’s mind about what the business wants/expects

from the target system.

• Rapport of the interviewer with the interviewee.

4.7.3 Intended Audience

The Business Analyst for use in analyzing and documenting the requirements.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

165

4.7.4 Process

.1 Prepare for the interview

• Define the interview’s focus or goal.

• Identify potential interviewees. The stakeholders identified in the Requirements

Planning KA may be the primary interviewees and/or will designate appropriate

persons who should be interviewed. The sponsor considers the following

questions when identifying who should be interviewed:

o Who holds the most authentic and the most current information on the

subject of interest?

o What is his/her stake in the project?

o What is the relative importance of information held by one person vis-à-vis

that held by another person? This information is helpful when analyzing

conflicting comments across interviews.

• Design the interview. The business analyst may need to custom-design the

interview for each identified interviewee. The interviewee’s ability to participate

and the desired outcome of an interview govern the design of an interview. In

addition, these factors are also considered:

o The format for the interview, structured vs. unstructured

o If a structured interview, the type of questions:

o Closed-ended questions: Questions that are used to elicit a single

response such as: yes, no, 3 Example: How many hours does it take for

the claim process to be completed?

o Open-ended questions: Questions that are used to elicit a dialog or series

of steps and cannot be answered in a yes or no fashion but need

explaining. Example: What does a claim processor do on receipt of a

claim form?

o Organization of the questions: use a logical order or an order of

priority/significance. Examples of order would be: general questions to

specific questions; start to finish; detail to summary, etc. The actual

organization is based on the interviewee’s knowledge, the subject of the

interview, etc. The goal is to follow a logical order rather than jump around

when asking questions.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

166

o Location of participants. An interview can be conducted in-person or via

telephone, or by means of other multi-media tools such as video-

conferencing over the Internet or intranet.

o The interview time and site are convenient to the interviewee.

o Determine if a scribe is needed and if so, include that person in the

scheduling process. Determine if a tape recorder is needed. If so, discuss the

purpose and usage with the interviewee.

• Contact potential interviewees - The business analyst contacts the selected

interviewees and explains to them why their assistance is needed. This initial

contact is established in person, by mail or by telephone. The purpose is to

explain the objective of the interview to the potential interviewee.

.2 Conduct the interview:

• Opening the interview - the business analyst as the interviewer gives an

introduction, states the purpose of the interview, addresses any concerns raised

by the interviewee, and explains that notes will be taken and shared with the

interviewee after the interview.

• During the interview:

o The interviewer maintains focus on the established goals and pre-defined

questions.

o All concerns raised by the interviewee are addressed during the interview or

documented for follow-up after the interview or in a subsequent interview.

o The interviewer practices active listening to confirm what he/she understood

from the information offered at various times during the interview.

• Closing the interview – the business analyst asks the interviewee for areas which

may have been overlooked in the session. Lastly, the business analyst summarizes

the session, reminds the interviewee of the upcoming review process and thanks

the interviewee for his/her time.

.3 Post interview follow-up and review:

After the interview is complete, the business analyst organizes the information elicited

and sends the notes to the interviewee for review. Documenting the discussion for review

allows the interviewee to see all of the information in context. This review may point out

items that are incorrect or missing because the interviewer (or scribe) missed

documenting them, or because the interviewer (or scribe) documented them incorrectly,

or because the interviewee missed discussing them. This review is not intended to address

whether or not the requirements are valid nor whether they will ultimately be approved

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

167

for inclusion into the deliverables but solely to determine if the interview has been

adequately documented.

4.7.5 Usage Considerations

.1 Strengths

• Encourages participation and establishes rapport with the stakeholder.

• Simple, direct technique that can be used in varying situations.

• Allows the interviewer and participant to have full discussions and explanations

of the questions and answers.

• Enables observations of non-verbal behavior.

• The interviewer can ask follow-up and probing questions to confirm own

understanding.

• Maintain focus through the use of clear objectives for the interview that are

agreed upon by all participants and can be met in the time allotted.

.2 Weaknesses

• Interviews are not an ideal means of reaching consensus across a group of

stakeholders.

• Requires considerable commitment and involvement of the participants.

• Training is required to conduct good interviews. Unstructured interviews,

especially, require special skills. Facilitation/virtual facilitation and active

listening are a few of them.

• Depth of follow-on questions may be dependent on the business analyst’s

knowledge of business domain.

• Transcription and analysis of interview data can be complex and expensive.

• Resulting documentation is subject to interviewer’s interpretation.

4.8 Technique: Observation

4.8.1 Purpose

Observation is a means to elicit requirements by conducting an assessment of the subject

matter expert’s work environment. This technique is appropriate when documenting

details about the current processes or if the project intends to enhance or change a

current process.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

168

4.8.2 Description

Observation relies on studying people performing their jobs, and is sometimes called "job

shadowing” or “following people around." For instance, some people have their work

routine down to such a habit that they have difficulty explaining what they do or why. The

business analyst may need to watch them perform their work in order to understand the

flow of work. In certain projects, it is important to understand the current processes to

better assess the process modifications that may need to be made.

There are two basic approaches for the observation technique:

• Passive / invisible. In this approach, the business analyst observes the subject

matter expert working through the business routine but does not ask questions.

The business analyst writes notes about what he/she sees, but otherwise stays out

of the way, as if he/she was invisible. The business analyst waits until the entire

process has been completed before asking any questions. The business analyst

should observe the business process multiple times to ensure he/she understands

how the process works today and why it works the way it does.

• Active / visible. In this approach, while the business analyst observes the current

process and takes notes he/she may dialog with the worker. When the business

analyst has questions as to why something is being done as it is, he/she asks the

questions right away, even if it breaks the routine of the person being observed. In

this approach, the business analyst might even participate in the work to gain an

immediate appreciation for how the current process works.

Variations of the observation technique:

• In some cases, the business analyst might participate in the actual work to get a

hands-on feel for how the business process works today. Of necessity this would

be limited to activity that is appropriate for a non-expert to perform and whose

results would not negatively impact the business.

• The business analyst becomes a temporary apprentice.

• The business analyst watches a demonstration of how a specific process and/or

task are performed.

4.8.3 Intended Audience

• Business Analysts for analysis of work flow, process modeling, business process

reengineering.

• Designers and Human Factors experts designing the detailed interface

requirements.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

169

4.8.4 Process

.1 Prepare for observation

• Determine what sampling of users (e.g. experts and novices, just experts) to

observe and which activities.

• Prepare questions to ask during or after the shadowing.

.2 Observe

• Observer introduces himself to the person being observed and:

o Reassures the user that their work is not being questioned but rather the

observation of the work and resulting documentation will serve as input to

requirements analysis. Informs the user that the observer is present only to

study their processes and will refrain from discussing future solutions to any

problems.

o Explains to the user that they may stop the observation process at any time if

they feel it is interfering with their work.

o Suggests to the user that they may “think aloud” while they are working as a

way to share their intentions, challenges, and concerns.

• Conduct observation.

o Take detailed notes.

o If using the active observation approach, ask probing questions about why

certain processes and tasks are being done.

.3 Post Observation wrap-up

• Obtain answers to original questions, or new questions that surfaced during the

observations.

• Feedback a summary of notes to the shadowed worker, as soon as possible, for

review and any clarification.

• When observing many users, compile notes at regular intervals to identify

commonalties and differences between users. Review findings with the entire

shadowed group to ensure that the final details represent the entire group, not

selected individuals.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

170

4.8.5 Usage Considerations

.1 Strengths:

• Provides a realistic and practical insight into the business knowledge by getting a

hands-on feel for how the business process works today.

• Elicits details of informal communication and ways people actually work around

the system that may not be documented anywhere.

.2 Weaknesses

• Only possible for existing processes.

• Could be time-consuming.

• May be disruptive to the person being shadowed.

• Unusual exceptions and critical situations that happen infrequently may not

occur during the observation.

• May not well work if the current process involved a lot of intellectual work or

other work that is not easily observable.

4.9 Technique: Prototyping

4.9.1 Purpose

Prototyping, when used as an elicitation technique, aims to uncover and visualize

interface requirements before the application is designed or developed. For additional

details on prototyping see Chapter 5 Requirements Analysis and Documentation Section

5.14 Usage Models.

4.9.2 Description

Initial prototyping produces “mock ups” of the screens or report layouts for an

application. Business users often find prototyping to be a comfortable, concrete means to

identify, describe and verify their interface needs.

Prototyping can be categorized in two ways:

The functional scope of the prototype:

• Horizontal prototype: Models a shallow, and possibly wide, view of the system’s

functionality. Typically does not have any business logic running behind the

visualization.

• Vertical prototype: Models a deep, and usually narrow, slice of the entire

system’s functionality.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

171

The use of the prototype throughout the system development lifecycle:

• ‘Throw-away’ Prototype: This exploratory approach seeks to quickly uncover

and clarify interface requirements using simple tools, sometimes just paper and

pencil. As the name suggests, ‘Throw-away’, such a prototype is usually

discarded when the final system has been developed. The focus is on

functionality that is not easily elicited by other techniques, has conflicting

viewpoints, or is difficult to understand.

• Evolutionary Prototype: This rigorous approach extends the initial interface

requirements into a fully functioning system and requires a specialized

prototyping tool or language. This prototype produces “running” software. It

emerges as the actual system downstream in the lifecycle.

4.9.3 Intended Audience

Designers and Human Factors experts designing the detailed interface requirements.

4.9.4 Process

.1 Prepare for prototyping

Determine the prototyping approach: throw-away vs. evolutionary; vertical vs.

horizontal.

Identify the functionality to be modeled.

.2 Prototype

Build the prototype.

.3 Evaluate the prototype

Verify the prototype represents the user’s needs.

4.9.5 Usage Considerations

.1 Strengths

• Supports users who are more comfortable and effective at articulating their needs

by using pictures, as prototyping lets them “see” the future system’s interface.

• A prototype allows for early user interaction and feedback.

• A throw-away prototype is an inexpensive means to quickly uncover and confirm

user interface requirements.

• A vertical prototype can demonstration what is feasible with existing technology,

and where there may be technical gaps.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

172

• An evolutionary prototype provides a vehicle for designers and developers to

learn about the users’ interface needs and to evolve system requirements.

.2 Weaknesses

• Depending on the complexity of the target system, using prototyping to elicit

requirements can take considerable time if the process gets bogged down by the

“hows” rather than “whats”.

• Assumptions about the underlying technology may need to be made in order to

present a starting prototype.

• A prototype may lead users to set unrealistic expectations of the delivered

system’s performance, reliability and usability characteristics.

4.10 Technique: Requirements Workshop

4.10.1 Purpose

A Requirements Workshop is a structured way to capture requirements. A workshop

may be used to scope, discover, define, prioritize and reach closure on requirements for

the target system.

Well-run workshops are considered one of the most effective ways to deliver high quality

requirements quickly. They promote trust, mutual understanding, and strong

communications among the project stakeholders and project team and produce

deliverables that structure and guide future analysis.

4.10.2 Description

A requirements workshop, (also generically referred to as JAD, Joint Application

Design), is not a traditional meeting. Instead, it is a highly productive focused event

attended by carefully selected key stakeholders and subject matter experts for a short,

intensive period (typically one or few days).

The workshop is facilitated by a team member or ideally, by an experienced, neutral

facilitator. A Scribe (also known as a Recorder) documents the business requirements

elicited as well as any outstanding issues. A business analyst may be the Facilitator or the

Scribe in these workshops. In situations where the business analyst is a subject matter

expert on the topic, the business analyst may serve as participant in the workshop.

A workshop may be used to generate ideas for new features or products, to reach

consensus on a topic, or to review requirements. Other outcomes are often detailed

requirements captured in models, such as the business domain model (Chapter 5.3), data

and behavior models (Chapter 5.12), process/flow models (Chapter 5.13) and or usage

models (Chapter 5.14).

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

173

4.10.3 Intended Audience

Project team

4.10.4 Process

.1 Prepare for the Requirements Workshop

• Clarify the stakeholder’s needs, and the purpose of the workshop.

• Identify critical stakeholders who should participate in the workshop.

• Define the workshop’s agenda.

• Determine what means will be used to document the output of the workshop.

• Schedule the session(s).

• Arrange room logistics and equipment.

• Send materials in advance to prepare the attendees and increase productivity at

the meeting.

• Conduct pre-workshop interviews with attendees.

.2 Conduct/Run the Requirements Workshop

• Elicit, analyze and document requirements.

• Obtain consensus on conflicting views.

• Maintain focus by frequently validating the session’s activities with the

workshop’s stated objectives.

The Facilitator has the responsibility to:

• Establish a professional and objective tone for the meeting.

• Enforce discipline, structure and ground rules for the meeting.

• Introduce the goals and agenda for the meeting.

• Manage the meeting and keep the team on track.

• Facilitate a process of decision making and build consensus, but avoid

participating in the content of the discussion.

• Ensure that all stakeholders participate and have their input heard.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

174

• Ask the right questions, analyze the information being provided at the session by

the stakeholders, and follow-up with probing questions, if necessary.

The Scribe’s role is to document the business requirements in the format determined

prior to the workshop.

.3 Post Requirements Workshop wrap-up done by Facilitator

• Follow up on any open action items that were recorded at the workshop.

• Complete the documentation and distribute it to the workshop attendees and the

sponsor.

4.10.5 Usage Considerations

.1 Strengths:

• A workshop can be a means to elicit detailed requirements in a relatively short

period of time.

• A workshop provides a means for stakeholders to collaborate, make decisions

and gain a mutual understanding of the requirements.

• Workshop costs are often lower than the cost of performing multiple interviews.

A requirements workshop enables the participants to work together to reach

consensus which is typically a cheaper and faster approach than doing serial

interviews as interviews may yield conflicting requirements and the effort needed

to resolve those conflicts across all interviewees can be very costly.

• Feedback is immediate, e.g. facilitator’s interpretation of requirements is fed back

immediately to the stakeholders and confirmed.

.2 Weaknesses:

• Due to stakeholders availability it may be difficult to schedule the workshop.

• The success of the workshop is highly dependent on the expertise of the facilitator

and knowledge of the participants.

• Requirements workshops that involve too many participants can slow down the

workshop process thus negatively impacting the schedule. Conversely, collecting

input from too few participants can lead to overlooking requirements that are

important to users, or to specifying requirements that don’t represent the needs of

majority of the users.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

175

4.11 Technique: Reverse Engineering

4.11.1 Purpose

In situations where the software for an existing system has little or outdated

documentation and it is necessary to understand what the system actually does, reverse

engineering is an elicitation technique that can extract implemented requirements from

the software code.

4.11.2 Description

Forward engineering is the traditional process of moving from high level abstractions to

physical implementation. Reverse engineering is a process of analyzing a subject

system/product to identify underlying business processes, data and rules. Based on the

identification work, representations of the system/product may be created at a higher

level of abstraction.

There are two general categories of reverse engineering:

• Black Box Reverse Engineering: The system/product is studied without

examining its internal structure.

• White Box Reverse Engineering: The inner workings of the system/product are

studied.

The results of reverse engineering can provide:

• An understanding of how a product works more comprehensively than by

merely observing it.

• A means to investigate errors and limitations in existing programs and a help in

correcting them.

• Details to help make products and systems compatible.

• Details to help evaluate a product and understand its limitations.

• Determining whether someone else has literally copied elements of one's own

technology.

• Documentation of a product whose manufacturer is unresponsive to customer

service requests.

• Details to help transform obsolete products.

4.11.3 Intended Audience

• Project team

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

176

4.11.4 Process

.1 Prepare for reverse engineering:

• Determine the scope of the functionality that needs to be reverse-engineered.

• Evaluate the cost-benefit. As reverse engineering can be time-consuming and

expensive, consider whether the financial investment is warranted by evaluating

the potential benefits gained from improved documentation and/or derived

abstraction in terms of maintenance of the existing system or development of a

new system/product.

.2 Perform reverse engineering:

• Disassemble or decompile the original system.

• Document the results in a manner that can be reviewed and verified by a business

subject matter expert. These can serve as baseline details to elicit requirements

for extending the existing system

4.11.5 Usage Considerations

.1 Strengths

• Protects investment in existing system/product by enabling the analysts to ‘build-

up’ existing functionality/business implementation.

• Provides detailed, current, information that can be used to update

documentation of an existing system/product.

.2 Weaknesses

• Expensive and time-consuming.

• Often restricted by copyright laws when a system/product of another

manufacturer is involved.

• Existing tools that support reverse engineering have limited capabilities and

require training to use.

• Requires specialized skills:

o Ability to abstract from ‘specific’ to ‘general’.

o Ability to draw inferences, especially, when documenting business rules.

o Ability to co-relate the functions of component(s) of a system with the

current and/or intended business processes.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

177

4.12 Technique: Survey/Questionnaire

4.12.1 Purpose

A survey is a means of eliciting information from many people, anonymously, in a

relatively short time. A survey can collect information about customers, products, work

practices and attitudes. A survey is often referred to as a questionnaire.

4.12.2 Description

A survey administers a set of written questions to the stakeholders and subject matter

experts. Their responses are analyzed and distributed to the appropriate parties.

Questions in a survey are of two types:

• Closed: The respondent is asked to select from available responses. Useful when

the issues are know but the range of user responses to them is not. The responses

to closed questions are easier to analyze than those gained from open-ended

questions.

• Open-ended: The respondent is free to answer the questions as they wish. Useful

when the range of users responses is pretty well understood, but the strength of

each response category needs to be determined. The responses to open-ended

questions may provide more detail and a wider range of responses than those

gained from closed-ended questions but open-ended questions are more difficult

to quantify and summarize.

4.12.3 Intended Audience

The survey questionnaire may be directed at any or all of the following:

• Marketing

• Project team

• Subject matter experts

• Primary and secondary stakeholders

• Current/potential users of a system.

4.12.4 Process

.1 Prepare

A survey requires detailed preparation to ensure the needed information is obtained

while minimizing the responders’ time to complete it.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

178

• Define the purpose of the survey and the target survey group: Identify the

objectives and the likely user group to be surveyed. Confirm with the sponsor.

• Choose the appropriate survey type: Initial steps of a survey are the same as for

interview design (see Section 4.7.2 Interview), keeping in mind that semi-

structured interviews are similar to ‘open-ended’ surveys; and structured

interviews are similar to ‘closed-ended’ surveys.

• Select the sample group: Consider both the survey type (‘open-ended’ or ‘close-

ended’) and the number of people in the identified user group to determine if the

entire group should be surveyed. For example: When the sample group is small,

it may be practical to survey all members of the group. When the sample group is

large and the desired survey type is ‘open-ended’, it may be necessary to identify a

subset of users. For such situations use of a statistical sampling method will help

ensure that survey results are not biased.

• Select the distribution and collection methods: For each sample group determine

the appropriate communication mode – surface mail; e-mail; web-based,

telephone.

• Project the desired level of response: Determine what response rate would be

acceptable. If the actual response rate is lower then the use of the survey results

may be limited. Offering an incentive can raise the response rate to 80% and

above but the cost of the incentive must be justified and budgeted.

• Determine if the survey should be supported with individual interviews: As a

survey does not provide the depth of data that can be obtained from individual

interviews consider:

o Pre-survey interviews may provide ideas for survey questions.

o Post-survey interviews can target specific survey responses or themes to

elicit a greater level of detail.

• Write the survey questions:

o Communicate the purpose: Explain the objectives of the survey. If the

stakeholders can see the reason for completing the survey, they are more

likely to do so.

o Be cognizant of the group’s characteristics: Understand the background

of the target group including their environment and specific terminology.

Use this information when writing the questions. If there is significant

diversity in the group’s background it may be useful to divide a large

group into smaller and homogenous groups during the preparation stage

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

179

and then produce variations of the survey that fit each group’s

background.

o Focus on the requirement: All questions should be directed towards the

stated objectives and the objectives should be supported by a

comprehensive set of questions.

o Keep the survey short. Less than 10 items is preferable limit in terms of the

content.

o Make the survey easy and fast to complete, ideally no more than five or 10

minutes.

o Make sure that the question wording is clear and concise.

o Avoid double questions in a single question.

o Avoid questions involving negatives.

o Avoid complex branching structures.

o Avoid asking questions that make respondents feel uncomfortable.

Trying to elicit information that is restricted by regulations is likely to put

respondents on the defensive.

• Test the survey. Perform a usability test on the survey. Use the results to fine-tune

the survey.

.2 Distribute the survey

.3 Communicate survey results

• Collate the responses. For the responses to ‘open-ended’ questions, evaluate the

details and identify any emerging themes.

• Analyze and summarize the results.

• Report findings to the sponsor.

4.12.5 Usage Considerations

.1 Strengths

• When using ‘closed-ended’ questions, effective in obtaining quantitative data for

use in statistical analysis.

• When using open-ended questions, the survey results may yield insights and

opinions not easily obtainable through other elicitation techniques.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

180

• Does not typically require significant time from the responders.

• Effective and efficient when stakeholders are not located at one place.

• May result in large number of responses.

• Quick and relatively inexpensive to administer.

.2 Weaknesses

• Use of open-ended questions requires more analysis by the business analyst.

• To achieve unbiased-results, specialized skills in statistical sampling methods are

needed when the decision has been made to survey a sample subset.

• Some questions may be left unanswered or answered incorrectly due to their

ambiguous nature.

• May require follow up questions or more survey iterations depending on the

answers provided.

• Not well suited for collecting information on actual behaviors.

Chapter 4 Requirements Elicitation

A Guide to the Business Analysis Body of Knowledge, Version 1.6

http://www.theiiba.org

181

4.13 Bibliography

Alexander, Ian and Richard Stevens, Writing Better Requirements. Addison-Wesley, 2002

Gause, Donald, and Gerald M. Weinberg, Exploring Requirements: Quality Before Design.

Dorset House Publishing, 1989

Gottesdiener, Ellen. “Requirements by Collaboration: Workshops for Defining Needs.”

Addison Wesley, 2002

Gottesdiener, Ellen. “The Software Requirements Memory Jogger” Goal/QPC, 2005

Hofmann, Hubert F., and Franz Lehner. "Requirements Engineering as a Success Factor

in Software Projects." IEEE Software July/Aug. 2001: 58-66.

Kotonya, Gerald and Ian Sommerville, Requirements Engineering: Processes and

Techniques. John Wiley & Sons, 1998

Lauesen, Soren, Software Requirements: Styles and Techniques. Addison Wesley, 2002

Leffingwell, Dean, and Don Widrig. “Managing Software Requirements: A Unified

Approach.” 2000: 103-111.

Sommerville, Ian and Peter Sawyer, Requirements Engineering: A Good Practice Guide.

Wiley & Sons, 1997

United States General Accounting Office, Program Evaluation and Methodology Division.

Using Structured Interviewing Techniques http://archive.gao.gov/t2pbat7/144388.pdf

Wiegers, Karl, Software Requirements. Microsoft Press, 2002, second edition.

Young, Dr. Ralph R. “Recommended Requirements Gathering Practices”. STSC Cross

Talk April 2002

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

182

Chapter 5: Requirements Analysis and

Documentation

5.1 Introduction

5.1.1 Knowledge Area Definition and Scope

Requirements analysis and documentation describes how stakeholder needs are analyzed,

structured and specified for use in the design and implementation of a solution. The

objective is to define and describe the characteristics of an acceptable solution to a

business problem, so that the project team has a clear understanding of how to design and

implement it. The primary focus of this activity is to develop the analysis models and

determine the gaps in the information provided by the stakeholders.

Deliverables from this process will be used by the project team to develop estimates for the

time, resources, and budget required to implement a solution or solutions that will fulfill

the requirements. The documentation itself is only one of several techniques the Business

Analyst will use to ensure that a consensus between all the stakeholders exists as to the

behavior of the solution. The primary focus of documentation activity is to refine the

models based upon stakeholder feedback and iteratively ensure feasibility of the

proposed requirements to support the business and user needs, goals and objectives.

5.1.2 Inputs

INSERT Figure 5.1: Inputs to Requirements Analysis and Documentation

During requirements analysis and documentation, the Business Analyst continues to

refine the overall scope of the problem domain and the scope of investigation. This is by

reviewing the analysis and documentation with key project stakeholders and the project

team. The stakeholders evaluate whether to increase or decrease project scope based on

project work revealing missing or new requirements. The documentation formally

acknowledges agreement on funding the proposed scope at the end of this knowledge

area.

The Business Analyst and the project team work with stakeholders to conduct

requirements analysis and documentation activities. The stakeholders consulted may

include:

• Users

• Senior management

• Customers

• Public

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

183

• Other systems owners or process owners that are impacted by the proposed

solution.

The Business Analyst has a defined a set of deliverables that will be the outcome of

requirements documentation. They include:

• Documentation

• Organizational assets e.g., templates for documentation or models

• Supplemental work records e.g., back-up information for models

The Business Analyst has collected a set of requirements, in the form of goals, needs, or

objectives set by the project stakeholders. Requirements Elicitation continues in

conjunction with requirements analysis until:

• Requirements are validated with the project stakeholders

• Consensus is obtained on a shared understanding of the defined requirements

• The project team is capable of implementing those requirements

The Requirements Communication Knowledge Area describes how the Business Analyst

works with stakeholders to achieve a shared understanding of and agreement to the

solution requirements.

5.1.3 Tasks

Requirements are typically developed iteratively, with the Business Analyst describing a

requirement based on available information about stakeholder needs and then presenting

the requirement to interested parties for review. Information gathered in that review is

incorporated into a revised version of the requirement, which will again be presented by

the Business Analyst. The Requirements Communication KA includes information on this

process.

The tasks defined as part of the Requirements Analysis and Documentation KA include:

o Structure requirements

o Create business domain model

o Analyze user requirements

o Analyze functional requirements

o Analyze supplementary quality of service requirements

o Determine assumptions and constraints

o Determine requirements attributes

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

184

o Document requirements

o Validate requirements

o Verify requirements

5.1.4 Outputs

Fully specified requirements are the primary output of this KA. These requirements will

be submitted to stakeholders that have the authority to review and amend the

requirements. These stakeholder reviews may cause an iterative series of changes to the

requirements documentation. The iterative process continues until it is agreed that

consensus on requirements is obtained and they are feasible and implementable. Fully

specified requirements are stable enough to be implemented by the project team.

5.1.5 Analysis Techniques and Solution Development Methodologies

There are many techniques available to the Business Analyst for requirements analysis.

These techniques include graphical, textual and matrix style modeling and

documentation. A Business Analyst should be capable of working with more than one

technique, even if he or she prefers a particular one. This will allow the Business Analyst a

wider range of options for expressing requirements, and will allow the Business Analyst

to understand documentation and models that have been prepared by others.

Selecting an appropriate solutions development methodology for a project falls outside

the scope of the BA Body of Knowledge. The decision will be determined by the culture

and standards of the organization. If the methodology in use does not mandate the use of

certain techniques, then the Business Analyst selects a set of analysis techniques that are

appropriate for the project as described in the Requirements Planning and Management

Knowledge Area.

There are three broad types of solution development methodologies that a Business

Analyst will use, each of which has a corresponding favored set of analysis techinques:

• Business process analysis

• Object-oriented analysis

• Structured analysis.

.1 Business Process Analysis

Business Process Analysis focuses on improving the processes of an enterprise in order to

maximize the achievement of its business mission, objectives and priorities. Because the

use of information technology is a primary enabler of process improvement, many

Business Process Analysis projects include an information systems or information

technology component in the solution design.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

185

Most projects require use of business process analysis techniques. The industry or project

type doesn’t necessarily alter the choice of techniques, A Business Analyst should be

familiar with analysis techniques used in both structured and object-oriented

methodologies, to easily work with documentation, people or processes that were

created with different model types.

Business Process Analysis (also referred to as Business Process Mapping) is a component

of larger methodologies such as Business Process Engineering, Business Process

Transformation, Business Process Reengineering, and Business Process Modeling. The

differences between these methods are minimal.

Business Process Analysis projects employ a model to describe both current processes

and recommended future processes. There are number of different diagram types and

conventions that support Business Process Analysis, such as Activity Diagrams (5.6.1),

Flowcharts (5.6.4) and Workflow Models (5.6.8).

.2 Object-Oriented Analysis

Object-Oriented Analysis views a information management system as a collection of

classes that pass messages to one another, and which contain both data (attributes) and

the operations that are used to create and modify those attributes. Data and processese are

not modeled separately.

Object-oriented modeling techniques are supported by the Unified Modeling Language

(UML) notation which is a standard defined by the Object Management Group.

In object-oriented methodologies, analysis typically begins with the identification of Use

Cases (5.14.3 and 5.14.4) that describe how people will interact with the system to achieve

their goals. Activity Diagrams (5.13.1) may be used to depict complex use case

interactions or to show how a process extends across multiple use cases. As objects are

identified in the problem domain, they will be abstracted into a Class Model (5.12.2).

Finally, Sequence Diagrams (5.13.5) describe how those classes interact in each possible

use case flow.

.3 Structured Analysis

Structured Analysis views a system primarily as a collection of processes executed by the

system, and analysis is therefore process-centric. Another characteristic of this approach

is a focus on data that is an input and output from these processes. Data and processes are

generally modeled separately.

Modeling techniques commonly used to support Structured Analysis include Flowcharts

(5.13.4), Data Flow Diagrams (5.13.2), functional decomposition diagrams, and Entity

Relationship Diagrams (5.12.6). Standards bodies have not codified most of the models

used in Structured Analysis, and so the Business Analysis Body of Knowledge defines a set

of common conventions for these techniques.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

186

5.1.6 Significant Changes from Version 1.4

The following tasks have been changed:

• A new task has been added to describe the existing Business Domain Model.

• Define Solution Model has been renamed to Structure Requirements Packages.

• Validate Requirements has been divided into two tasks: Validate Requirements

(which describes how the Business Analyst determines that the functional and

quality of service requirements will fulfill the original business requirements) and

Verify Requirements (which describes how the Business Analyst determines that

the requirements documentation is of sufficient quality to begin solution

development).

• Analysis models have been separated into an appendix. The content of those

models has not been updated. The Body of Knowledge Committee is currently

considering whether a detailed treatment of these models is a useful addition to

the Body of Knowledge or whether they should simply be listed. In the latter case,

Business Analysts who need to understand the details of each model can refer to

the standards body responsible for the model definition or to one of the texts used

to compile this knowledge area. We welcome feedback from the community to

help determine whether this content adds value.

5.2 Task: Structure Requirements Packages

5.2.1 Purpose

The purpose of structuring requirements into packages is to refine the problem boundary

and solution scope definitions developed in Enterprise Analysis. The Business Analyst

may decompose the problem model - to provide an increasing amount of detail on each

requirement. The goal of this task is to ensure that the problem model continues to

accurately provide the boundary for requirements analysis and solution development

while providing clarification of functional requirements and supplemental requirements

for downstream development activities.

5.2.2 Description

Concurrent to the Requirements Elicitation KA, the solution domain model is updated so

that it continually reflects the developing understanding of the problems to be solved, the

relationship between those problems, and the scope of the required solution. Failure to

do this may result in wasting of project resources on a solution that does not meet

stakeholder needs.

This iteration continues until the requirements have been structured.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

187

This task is optional and may not be required if the Business Analyst is specifying a small

set of requirements—for instance, an iteration in some Agile development methods or an

enhancement to an existing system.

5.2.3 Predecessors

The Business Analyst has determined the scope of the Problem Domain as described in

Enterprise Analysis.

Project work is initiated when an organization or customer funds solving a specific

problem. The tasks and techniques associated with high-level definition of the problem

and the scope of the required solution work are described in the Enterprise Analysis

Knowledge Area.

The business analyst conducts the tasks defined in the Requirements Elicitation KA.

During this activity additional requirements will be discovered which may change the

project team’s understanding of the problem and/or the required solution. New

opportunities or additional complexity may be identified and priorities may change. This

could have significant impact on the project scope and allocation of resources.

5.2.4 Process and Elements

The BA will iteratively structure the requirements model throughout requirements

analysis and documentation. The process follows the following principles:

Define Solution Boundary

The Business Analyst identifies the solution boundary. System boundaries are

determined by ownership. The business analyst documents:

o Where other actors interact with the solution.

o Where other systems provide or extract information from the solution.

o Where time initiates activities for the solution

Structure Solution Definition

Definition focuses on project work that can be accomplished in the current project or the

next release of a phased project release. The team reviews whether there is sufficient

funding to develop a solution for the high-level problem defined in the charter. If not, the

team escalates to senior management or the customer.

Most problems are too complex to be effectively managed as a whole. The business

analyst decomposes the solution into subsets that can have high-level estimates

developed to confirm early project feasibility. Decomposition is structuring the problem

domain into similar function, similar organizational relationships, models used to

describe the problem or some other logically breakdown. This is usually presented in

graphical models. The primary goal of problem decomposition is to ensure that the

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

188

problem is separated into sub-problems that interact as independently as possible, so that

work can be assigned to different groups. This provides the ability to scale and manage

larger projects.

Defining the solution boundary and structure the solution definition can be

accomplished by goal decomposition, feature list decomposition, functional

decomposition and solution-driven decomposition. The techniques will depend on your

organizations culture and the complexity and type of project.

.1 Goal Decomposition

Goals are developed by stakeholders in the Enterprise KA. Goals are prioritized during

the Planning and Managing KA and competing goals are addressed by senior

management or the customer to provide guidance to the team. The purpose of goal

decomposition is to focus the solution on satisfying high-priority stakeholder needs.

Goal decompositions considers the goals of stakeholders who will directly interact with

the solution (i.e. users) and the interests of stakeholders who will not interact with the

solution but do have concerns interests or concerns that they expect the solution to

satisfy. Techniques for identifying a complete list of stakeholders can be found in the

Requirements Planning and Management KA.

Goals are business requirements. Goals are textual. Either functional or supplemental

Quality of Service requirements trace to these business requirements. Goal

decomposition breaks down high-level stakeholder goals into lower-level goals that have

measurable objectives. .

The high-level goals in the charter may be an objectively measured target or a subjective

one, but all lower level goals must be objective. A lower level goal should include

objective criteria allowing stakeholders involved in the process and/or the system being

designed to determine whether the goal has been accomplished.

Lower level goals (or objectives) must either be achieved by the solution or by external

entities. If responsibility for the lower level goal is handed over to an actor outside the

scope of the solution, the solution should be prepared to cope with the failure of that

actor to fulfill the goal.

.2 Feature List Decomposition

A feature is a service that the solution provides to fulfill one or more stakeholder needs.

Features are high-level abstractions of the solution that must later be expanded into fully-

described functional and supplemental requirements. They allow for early priority and

scope management and for validating the stakeholders’ view of the solution.

Features can be textual or graphical such as use cases. A high-level summary is provided,

and later decomposed into additional levels of detail. An example of a feature scheme

structure follows.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

189

• 3.x System Feature X

• 3.x.1 Description and Priority

• 3.x.2 Stimulus/Response Sequences

3.x.3 Functional Requirements

Figure 5.2: Sample Feature List

Feature Description

Priority

Complexity

Schedule

FEA001

Allow user to log in

High

Low

Release

FEA002

Validate user authority level

High

Medium

Release

FEA003

Lockout user after three failed attempts and notify

sysadmin

Medium

Release

.3 Functional Decomposition

Functional decomposition identifies the high-level functions of an organization or

proposed solution and then breaks down those processes into sub-processes and

activities. This can be done as part of a systems development or business process analysis

project. The goal is to break functions down into smaller pieces to allow for analysis of

the detail processes and to ensure coverage of all significant processes.

Models start with a top-level function, typically corresponding with an organizational

unit and continue to drill down into sub-functions, representing the processes carried out

by that unit, and beneath those sub-processes and individual activities (the names for

each level are conventions only, and do not imply that decomposition must halt after the

fourth level is reached). These can be represented by a hierarchical diagram, a tree

diagram, or by numbering each sub-function. Each function consistes of the sub-

functions beneath it. The process of functional decomposition continues until a sub-

function cannot be broken down into two or more lower level functions.

Figure 5.3: Functional Decomposition Diagram

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

190

.4 Solution-driven Decomposition

In some projects, the solution architecture is determined at the time of project initiation.

Many organizations need to comply with existing business processes or the enterprises

technical architecture. The business analyst documents how the proposed enhancement

aligns to the current architectures.

5.2.5 Stakeholders

Stakeholders are impacted by analysis techniques. They need to verify and validate the

deliverables. Decomposition is used to help them understand how requirements impact

their business area or their system. Therefore the Business Analyst create model needed

to tailor the representation of the proposed solution for key stakeholder groups.

Project Management used the decomposed solution models to verify the scope of the

solution and assess the work that needs to be done in the project. The implementation

team can be assigned to specific lower-level problems. Business Analysts can choose to

structure the information in the models by the lower-level problems assigned to each

person, project team or vendor team. Clear alignment between the models and who is

assigned to the work with facilitates tracking and reporting of project progress.

The Business Analyst(s) works within established project procedures and milestones to

provide all stakeholders with the opportunity to review and approve the solution model.

Additional refinement of the models is needed if the information is not decomposed in a

way that is easily reviewed or agreed too by the various stakeholder groups.

5.2.6 Deliverables

The deliverable of this task is a documentation set that describes the solution model. This

documentation may be represented by text, by diagrams and models, or by a

Function

Subfunction 1

Subfunction 2

Subfunction 3

Process 1.1

Process 1.2

Process 1.3

Process 2.1

Process 2.2

Process 2.3

Process 2.4

Activity 1.1.1

Activity 1.1.2

Activity 1.1.3

Activity 1.2.1

Activity 1.2.2

Process 2.1.1

Process 2.1.2

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

191

combination of both. Any of the techniques described in this Knowledge Area may be

used. Stakeholder approval, in particular by representatives of the business area, is a key

component to ensure agreement that solution requirements are based on an accurate

model of the problem to be solved.

5.3 Task: Create Business Domain Model

5.3.1 Purpose

The purpose of this task is to describe the current and future state of the enterprise. This

model is used by the Business Analyst and the stakeholders to ensure that they have an

accurate understanding of the current as-is of the enterprise. It is used to verify that

stakeholders have a shared understanding of the proposed to-be of the solution.

5.3.2 Description

The objective is to create a complete description of existing and proposed organizational

structures, processes, and information used by the enterprise.

5.3.3 Predecessors

The Business Analyst will make use of tasks and techniques defined in the Requirements

Elicitation Knowledge Area to gather information on the current state of the business

domain.

5.3.4 Process and Elements

The following are guiding principles in analyzing functional requirements. The Business

Analyst time spent on this task is dependent on the following research and resoluton.

.1 Domain and User variation.

Developing a business model will frequently reveal areas of disagreement or confusion

between stakeholders. The Business Analyst will need to document the following

variations in the as-is model

• Multiple work units perform the same function: Document the variances in the

as-is model. This may be different divisions or geographies.

• Multiples users perform the same work.: different stakeholders may do similar

work differently. The variation may be the result of different skill sets and

approaches of different business units or the result of differing needs of external

stakeholders serviced by the enterprise. Document the variances in the as-is

model.

.2 Resolution

The Business Analyst will document whether the to-be solution will accommodate the

inconsistencies in the current business model or whether the solution will require

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

192

standardization. Stakeholders need to determine which approach to follow. The to-be

model will reflect their decision.

5.3.5 Stakeholders

All project stakeholders are impacted by the as-is and to-be models.

5.3.6 Deliverables

A high-level description of the as-is system and processes and to-be proposed solution.

5.4 Task: Analyze User Requirements

5.4.1 Purpose

To capture and describe requirements that affect a particular user or user group and

insure that the needs of individual stakeholder groups are addressed by a solution.

5.4.2 Description

User requirements describe the needs of a particular set of stakeholders in regard to a

proposed solution. They may be used to describe how a particular set of users of a

solution will interact with it or how a product will meet the needs of different customer

groups.

Not all solution development efforts require the development of a separate category of

User Requirements. Some of the factors the Business Analyst should consider when

determining whether to develop separate user requirements include:

• How the application will be distributed and used

! A commercial product may have different versions available for sale

targeted at distinct customer groupings with different needs.

• The number of stakeholder groups involved in the development of the solution

• The complexity of the solution

• The level of consensus among stakeholder groups (low consensus may make this

a valuable step in describing distinct needs

5.4.3 Predecessors

The Business Analyst must have Elicited the Requirements (see Requirements Elicitation

KA) from representatives of the user group.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

193

5.4.4 Process and Elements

The process of analyzing and specifying user requirements is identical to the processes

used to Analyze Functional Requirements (5.5), Quality of Service Requirements (5.6)

and Assumptions and Constraints (5.7).

5.4.5 Stakeholders

A set of User Requirements is intended to capture the needs of a particular stakeholder

group, and so the primary stakeholder in the completion of this task is that group.

The Business Analyst and other stakeholders will be concerned with ensuring that

conflicts between sets of user requirements can be resolved.

5.4.6 Deliverables

The Business Analyst, may, if required, express the User Requirements in a requirements

document. User Requirements are often developed as an intermediate step in

Requirements Analysis and Documentation and so may not need to be placed in a

deliverable of their own.

5.5 Task: Analyze Functional Requirements

5.5.1 Purpose

Functional requirements are analyzed to describe the desired behavior of a solution.

5.5.2 Description

Functional requirements describe the behavior that the solution will manage. They

describe capabilities the system will be able to perform in terms of behaviors or

operations – a specific system action or response.

Behavior also includes:

• An effect that a solution must have within the problem domain in order to bring

about a desired result,

• How a person or system will interact with the proposed solution.

• A standard that must be complied with

The functional requirements are well-written when they do not unnecessarily constrain

the solution design. Functional requirements can be organized and presented in various

ways. A selection of generally accepted techniques for analyzing and expressing

functional requirements can be found in the appendix to this knowledge area.

5.5.3 Predecessors

Analysis of functional requirements requires that the boundary of the solution model has

been defined. This is completed when business domain models are completed.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

194

5.5.4 Process and Elements

The following are guiding principles in analyzing functional requirements:

Uniqueness

All requirements should be stated in one and only one place within a requirements

document. Additional models can provide clarity on an aspect of the requirement but the

requirement should not be stated in multiple places.

.1 Textual Documentation

Some requirements are best stated in simple textual sentences and paragraphs. As an

example, business rules are often described textually. Requirements are best stated

simply.

o Avoid complex conditional clauses

o Use terminology is used consistently

o Don’t assume your reader has domain knowledge,

o Expressed as a verb or verb phrase.

o Express one and only one requirement.

o Paragraphs should be short so that they can be more easily understood.

o Write in the in the active voice, clearly describing who or what is responsible for

fulfilling the requirement.

Well-formed Requirements

A well-formed textual requirement must describe the capabilities of the solution, any

conditions that must exist for the requirement to operate, and any constraints that may

prevent the solution from being able to fulfill the requirement. Each of the following

elements should be considered when structuring a requirement to ensure that it is well-

formed:

• Event/Condition: Describes when the requirement must be fulfilled. This may

be an external event that triggers the requirement, or a condition under which the

solution is operating.

• Subject: Who performs the operation. This may be a person or a system, but the

subject responds to the event or condition in an effort to fulfill the requirement.

• Imperative: See above.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

195

• Action Verb: Describes what the subject must do. Common actions include

advise, assign, check, create, delete, display, obtain, and update.

• Object: The entities or data that are involved in fulfilling the requirement.

• Rules: Describes any rules that govern the outcome of the requirement. Complex

rules may require that additional requirements be described.

• Outcome: Describes the desired result, including any criteria used to determine

that the requirement has been successfully fulfilled.

.2 Matrix Documentation

A table is the simplest form of matrix. A table is used when the Business Analyst is looking

to convey a set of requirements that has a complex but uniform structure which can be

broken down into elements that apply to every entry in the table. Requirements Attributes

(5.8) and Data Dictionaries (5.12.4) are often expressed in tabular form Matrices are often

used for traceability of requirements to each other, from requirements to test cases, and

for gap analysis. Matrices are also used for prioritizing requirements by mapping them

against project objectives.

A more complex matrix will also express information in the rows of the table. Rather than

presenting repeating information, this form of matrix is usually intended to indicate that

two elements are related in some fashion (for instance, that a requirement affects a

particular data element). Examples of this kind of matrix can be found under Business

Rules (5.12.1) and to document Requirements Traceability (See the Requirements

Planning and Management KA).

.3 Diagrams

Diagrams are effective for showing the relationship between items of information in a

requirements specification. They are often easier to follow then textual descriptions of

structure or relationships, and for helping readers to understand the entirety of a

problem. Diagrams may be supported by textual descriptions of the requirement. This

knowledge area includes a number of diagrams that are commonly used in Requirements

Analysis and Documentation, but the Business Analyst is not restricted to using those

diagrams when a visual model is useful.

Diagrams are particularly useful when the Business Analyst seeks to:

• Show the relationship between entities in an organizational structure or between

portions of a solution.

• Show events that occur in a particular order, especially if some of those events

can occur in parallel.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

196

• Show the physical location of aspects of the solution that will be present in the

real world, such as the user interface of a system or the relative location of an

organization’s facilities.

Make diagrams as simple as possible. Graphical elements should be of a consistent size

and their appearance should only differ when that difference conveys information to the

viewer.

Diagrams that are intended to show a hierarchical relationship between elements of the

diagram should place the most important elements at the top of the page. Similarly,

Western audiences will expect a diagram that shows events occurring over time to have

those events flowing either from the top of the page to the bottom or from the left to the

right.

.4 Models

A model is a template for expressing requirements that may combine textual elements,

matrices, and diagrams. A number of modeling techniques commonly used by Business

Analysts are described in the Appendix to this Knowledge Area.

A model serves as an abstraction which represents some or all of the proposed solution. It

is not imperative on part of the business analyst to model everything and at all times. For

example, the BA may choose to rule out modeling when:

• The problem domain is well known.

• The solution is relatively easy to construct.

• Very few people need to collaborate to build or use the solution (often only one).

• The solution requires minimal ongoing maintenance.

• The scope of future requirements or needs is unlikely to grow substantially.

As the complexity of a solution increases, communication needs dictate modeling. Each

model looks at the problem or solution domain from a different perspective, requiring

that the Business Analyst must decide which perspectives are the most appropriate to the

needs of a specific project. In some cases, the organization may prescribe as a standard

the use of a particular modeling technique or set of techniques.

The benefits of using modeling techniques are:

• A model is a simplification of reality that allows analysts to focus on what is

considered important and filter out the “noise”.

• Models help us understand and describe complex systems that otherwise might

be difficult to comprehend.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

197

• Every system may be described from different perspectives using different

models.

• Models assist the Business Analyst to ensure that all aspects of a problem are

completely considered, as they include a number of mandatory elements that the

Business Analyst must evaluate.

• Models may more easily translate into a solution design.

Formal or Informal

A model may be formal, highly structured and detailed, or it may be informal and

general. The approach chosen will be dictated by the nature of the project and its time

and cost constraints, or by the system life cycle methodology of the organization.

Model Viewpoints

A requirements model may be intended to reflect a specific view of the requirements. A

view captures only the requirements that are relevant from the perspective of a specific

stakeholder or group of stakeholders, such as specific user groups, a set of related

functions, or a perspective required by the development team. The difference between a

view and a model decomposition is that a view is not exclusive—a requirement may be

referenced in all views in which it is relevant.

One of the most common sets of viewpoints in use is the development of separate

physical and logical models for a solution. Many of the modeling techniques used by

Business Analysts to describe the logical structure of the requirements will also be used by

developers to design the solution. In general, the Business Analyst will design a logical

model, and the solution developers will design a physical model.

Logical Models are typically used by Business Analysts to represent the requirements of a

business area. They generally show the entities that are visible to the problem domain and

show how they interact with one another and with users of the solution.

Physical Models are based on the Logical Model but are modified to represent the

implementation of the solution in a specific technology environment. Physical data

models are not usually the responsibility of Business Analysts—they are designed by the

implementers of the solution to express the solution design.

.5 Related Tasks

The Business Analyst should execute Determine Requirements Attributes and Structure

Requirements for Traceability (see Requirements Planning and Management KA) in

parallel with this task.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

198

5.5.5 Stakeholders

When analyzing the current state of a solution, the product of analysis must be verified

with stakeholders to verify that it is a full and accurate description of that solution.

When analyzing a desired future state of a solution, the products of the analysis effort

must be validated with the project team (to determine that there is sufficient information

at the end of analysis to proceed with implementation of the requirements) and by the

stakeholders (to validate that the requirements as expressed meet their organizational

needs).

From the perspective of various stakeholders, a complete requirement must meet the

following criteria:

• Business Users: The requirement must capture the business objective and, if

implemented, will fulfill a business need. Requirements must provide value to

the users.

• Project Team: The requirement must be stated completely enough to allow for

construction and implementation of the solution.

• Quality Assurance: The requirements must be stated clearly enough and

completely enough that the QA group can test whether they are met by the

solution.

5.5.6 Deliverables

A full description of the behavior of a proposed solution.

5.6 Task: Analyze Quality of Service Requirements

5.6.1 Purpose

Quality of Service requirements capture conditions that do not directly relate to the

behavior or functionality of the solution, but rather describe environmental conditions

under which the solution must remain effective.

5.6.2 Description

Quality of service requirements are most often used to describe some of the attributes of

the system or system environment. These requirements are constraints on the solution.

They are also known as non-functional requirements.

5.6.3 Predecessors

Understanding quality of service requirements begins during Requirements Elicitation

and documentation can begin concurrent with defining functional requirements.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

199

5.6.4 Process and Elements

There are several types of supplemental requirements. The following are typically part of

projects but specific project needs may require additional elements.

.1 Environmental Requirements

Environmental requirements are environmental constraints imposed by the atmosphere

outside of the system boundaries. The Business Analyst must specify political, regulatory,

market, standards, policies, cultural norms, physical constraints and globalization

requirements that apply to their project type. The most common environmental

requirements are:

Audit

Audit requirements define information that the process or system does not need in the

normal course of events but must be possible to produce when required by an outside

agency. Audit requirements may be expressed through Metadata Definition (5.12.7).

Globalization and Localization

These requirements are applicable to projects that must be implemented across multiple

cultures or nationalities. They may include support for multiple languages, date and

currency formats, number displays, text sorting, and other considerations.

Legal

Legal or regulatory requirements include rules and regulations imposed by governments

or other regulatory bodies outside the enterprise.

.2 Interface Requirements

Interface requirements define the interactions between computer systems. The different

types of external interfaces include hardware interfaces, software interfaces and

communication interfaces. Interface requirements impact the hardware selection

options, the connection to other software components and the communication functions

the system will use.

• Hardware interface requirements describe the characteristics of each interface

between the system and hardware components of other systems. Examples of

information described include support device types, the data and control

interactions between the software and hardware and communication protocols.

• Software interface requirements describe the connection to other software

components e.g., databases, operating systems, tools, libraries and commercial

components. The information should include the purpose of the message, as well

as the data and control items exchanged. The requirement includes the services

needed by external software components and the nature of the inter-component

communications. The data shared across systems is identified and any new data-

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

200

sharing mechanisms are identified. See also Data Transformation and Mapping

(5.12.5).

.3 Glossary

A glossary defines terms that have special meaning to the organization. It is used by the

project team to consistently use terminology. It also provide definitions of common

problem domain terms for other project team members.

.4 Operational Requirements

Operational requirements define how the system will run and interact with operators.

Examples include how many users may use the system concurrently, user access

requirements, and the maximum acceptable downtime.

.5 Performance Requirements

Performance requirements for various system components indicate how much

information the system must be capable of processing in a given period of time.

.6 Privacy

Privacy requirements restrict the distribution of personal information without the express

or implicit consent of the parties involved. They describe what information is considered

private and under what circumstances it may be made available to internal and external

parties. They are distinct from security requirements (below) in that they presume that

the parties in question have legitimate access. Privacy requirements may in some cases be

expressed through Business Rules (5.12.1) or a CRUD Matrix (5.12.3).

.7 Quality Requirements

Quality requirements describe the designability, reliability, usability, maintainability,

efficiency, human engineering, testability, understandability, maintainability, scalability,

and portability expectations for the system. These characteristics should be specific,

prioritized, quantitative and verifiable.

Some of the key quality requirements are described below.

Failure and Disaster Recovery

Failure and Disaster recovery requirements describe how the system is to be secured

against catastrophic failure and data loss. They may include procedures designed to

maintain data in a separate location, alternate means of making a system operational, and

other considerations. Scenarios should be considered for partial and complete system

failure. IN the case of complete failure it may be necessary to specify other systems or

manual procedures that will be used.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

201

Maintainability

Maintainability requirements describe how likely future changes to the solution are and

what should be done to facilitate those future changes in the present.

Scalability

Scalability requirements describe the likely growth of use of the solution over time,

allowing the project team to plan for increasing capacity.

.8 Safety Requirements

Safety requirements specify those requirements that are concerned with possible loss,

damage or harm that could result from the use of the system. Define any proactive

safeguards that must be taken, as well as preventative actions to avoid potentially

dangerous results from use of the system.

.9 Security Requirements

Security requirements are important when the nature of the data that is traded is sensitive

or access to the information must be either monitored or restricted.. Security

requirements protects the data that the system uses or creates. They describe the potential

risk that individuals will attempt to gain illegitimate access to information stored within

the solution or that individuals with legitimate access will use the information in

illegitimate ways. They include strategies to prevent access and mitigate the risks

involved.

.10 Training

Training requirements describe the educational needs of stakeholders who will interact

with the solution. They describe the types of stakeholders affected, the changes from the

present situation that each type of stakeholder will encounter, and how those

stakeholders will be informed of those changes in a way that allows them to make effective

use of the solution.

5.6.5 Stakeholders

See 5.4.5.

5.6.6 Deliverables

See 5.4.6.

5.7 Task: Determine Assumptions and Constraints

5.7.1 Purpose

Assumptions and constraints identify aspects of the problem domain that are not

functional requirements of a solution, and will limit or impact the design of the solution.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

202

5.7.2 Description

Constraints are limitations or restrictions on solutions. Constraints are provided to the

project team to inform them that options they would normally be allowed to consider are

not available. They place limitations on how the problem described by the requirements

may be solved.

Assumptions are things that are believed to be true but have not been confirmed Business

assumptions are provided to the project team to inform them of key stakeholder

expectations. Requirements assumptions are added by the Business Analyst to transfer

business domain knowledge to the project team.

5.7.3 Predecessors

The documentation of assumptions and constraints will likely begin during enterprise

analysis.

5.7.4 Process and Elements

The Business Analyst documents all identified requirements Assumptions and

Constraints. Since these do not fit within a model they are usually handled as Textual

Documentation (5.5.4.1).

.1 Business Constraints

Business constraints describe limitations on the projects flexibility. to adopt a desired

solution. They may reflect budgetary restrictions, time restrictions, limits on the number

of resources available, restrictions based on the skills of the project team and the

stakeholders, a requirement that certain stakeholders not be affected by the

implementation of the solution, or any other organizational restriction.

Business constraints are things like budget limitations, restrictions on the people who can

do the work, the skill sets available, etc. Constraints should be carefully examined to

ensure that they are in fact justified

.2 Technical Constraints

Technical constraints include any architecture decisions that are made. These may

include development languages, hardware and software platforms, and application

software that must be used. Constraints may also specify restrictions such as resource

utilization, message size and timing, software size, maximum number of and size of files,

records and data elements. Technical constraints include any enterprise architecture

standards that must be adhered to.

.3 Assumptions

Assumptions are used to document two types of issues relevant to the project:

• Things that the Business Analyst believes to be true but is unable to verify.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

203

• Things that the Business Analyst knows to be true at the present that would

impact the project negatively if they change (that are distinct from a

requirement).

5.7.5 Stakeholders

The primary consumers of assumptions and constraints are the project team, who will

have to integrate them into their proposed solution. The stakeholder responsible for

defining the assumption or constraint should be involved in any discussion that involves

changing that constraint.

5.7.6 Deliverables

See 5.3.6.

5.8 Task: Determine Requirements Attributes

5.8.1 Purpose

Requirements attributes provide information about the requirement, such as the source

of the requirement, the importance of the requirement, and other metadata (see 5.12.7).

Attributes aid in the ongoing management of the requirements throughout the project

lifecycle. . They should be gathered along with the requirement themselves, but are not in

themselves part of the solution definition. The information documented by the attributes

helps the team efficiently and effective make tradeoffs between requirements, identifying

stakeholders affected by potential changes, and understanding the impact of a proposed

change.

5.8.2 Description

Attributes are information attached to each individual requirement. Attributes allow the

requirements team to associate information with individual or related groups of

requirements and facilitate the requirements analysis process by expressing which

requirements may add project risk or require additional analysis.

5.8.3 Predecessors

Which attributes that should be documented will be determined during Requirements

Planning and Managemen KA. The requirements attributes needed for the project will be

determined by the complexity of the project and the change management strategies

adopted by the project team. In general, requirements attributes become increasingly

important as change becomes more difficult to accomplish.

A requirement must be defined (at least in a preliminary form) before the requirements

attributes for it can be provided.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

204

5.8.4 Process and Elements

.1 Process

During Requirements Elicitation KA the Business Analyst must record any information

supplied by stakeholders that may assist in the definition of the requirements. During

requirements analysis, each requirement must be assessed after it is analyzed to

determine the values of the required attributes. The Business analyst involves other

stakeholders and does not independently create the attribute values.

.2 Use of Imperatives

The Business Analyst may use imperatives to describe the priority of each requirement, in

the absence of a more explicit method of recording attributes. One scheme for doing so is

as follows:

• “Shall” and “Must” indicate that the requirement is mandatory.

• “Should” indicates that the requirement is highly desirable.

• “May” indicates that the requirement is optional.

• “Will” indicates that the requirement will be fulfilled by something outside the

scope of the solution.

.3 Elements

Some common requirements attributes include:

• Absolute reference is a unique numeric or textual identifier. The reference is not

to be altered or re-used if the requirement is moved, changed or deleted.

• Acceptance criteria describes the test that would demonstrate that the

requirement has been met to the customers, end users and stakeholders.

• Author of the requirement. If the requirement is later found to be ambiguous the

author may be consulted for clarification.

• Complexity indicates how hard the requirements will be to implement.

• Ownership indicates the individual or group that needs the requirement or will

be the business owner after the project is released into the target environment.

• Priority indicates which requirements need to be implemented first. See the

Requirements Planning and Management KA for further discussion or prioritizing

and managing requirements.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

205

• Source of the requirement. Every requirement should originate from a source

that has the authority to specify requirements. The source must be consulted if

the requirement changes, or if more information regarding the requirement or

the need that drove the requirement has to be gathered.

• Stability is used to indicate how mature the requirement is. This is used to

determine whether the requirement is firm enough to start work on.

• Status of the requirement, indicating whether it is proposed, accepted, verified

with the users, or implemented.

• Urgency indicates how soon the requirement is needed. It is usually only

necessary to specify this separately from the Priority when a deadline exists for

implementation.

Additional attributes may include information such as cost, assigned-to, location,

revision number, traced-from and traced-to. Minimally, attributes must indicate

verifiability and must contain acceptance criteria.

5.8.5 Stakeholders

The primary consumers of requirements attributes are the project team, who will use

them in the design and development of the system. They assist the project team in

determining when a requirement should be implemented, what trade-offs to make during

design and implementation, and who should be involved in the review of change

requests.

5.8.6 Deliverables

Requirements attributes must be populated for each attribute used in the project. They

may be captured in the requirements document or in a requirements management tool.

5.9 Task: Document Requirements

5.9.1 Purpose

The Business Analyst must create a requirements document to facilitate a common

understanding of the requirements among all of the stakeholders and document that

understanding for future reference.

5.9.2 Description

A requirements document describes a set of related functional and quality of service

requirements. It does not include project deliverable information such as cost and time

but formalizes the project scope. This document can be a contractual document when

the worked in performed by groups outside the project organization.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

206

5.9.3 Predecessors

Requirements documentation requires the Requirements Elicitation and requirements

analysis activities to be complete. Iteration continues to occur as the document is

formally reviewed by stakeholders for corrections or to perform requirements triage.

5.9.4 Process and Elements

.1 Selecting a Document Format

The format of the Requirements document is likely to be determined by the methodology

and process adopted by the enterprise. Using a predefined format can assist the Business

Analyst in ensuring that all requirements types are properly covered and facilitate

stakeholder understanding of the requirements for a given solution.

.2 Common Document Formats

There are many terms for requirement documents. The documents described below are

some examples of formats that are common to particular solution development

methodologies. Their inclusion here is intended as a guide only—the IIBA does not

endorse or reject any particular methodology or prescribe any particular set of

deliverables.

Figure 5.4: Common Document Contents

Document Type

Business

Requirements

Model

Current Business

Model

User Requirements

Functional

Requirements

Quality of Service

requirements

Assumptions and

Constraints

Requirements

Attributes

Traceability Matrix

Other*

Vision

Software Requirements Specification

Business Requirements Document

RFQ/RFP

Business Process Description

Other: Requirements Tool/Repository

*See Document Description for details.

Vision

A Vision Document may be created as an output of Enterprise Analysis. It documents a

high-level consensus among stakeholders as to the overall scope of the solution domain.

It can describe either a specific release or a roadmap. It is most commonly written when a

solution is to be developed iteratively.

Business Process Description

A business process description is an executive summary of an initiative. It describes the

problem and the proposed solution in high-level terms.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

207

Business Requirements Document (BRD)

The business requirements document describes the behavior required of a software

application. The primary target audience for a BRD is the customer and users.

This document should primarily describe the business requirements as defined in the

Enterprise Analysis KA.

Request for Proposal/Request for Quotation (RFP/RFQ)

An RFP or RFQ is a document that is distributed to parties outside the organization to

serve as the basis for the contracting of solution development services.

Software Requirements Specification (SRS)

A Software Requirements Specification (also known as a System Requirements

Specification) describes the behavior and implementation of a software application. The

primary target audience for a SRS is the development team that will be required to

implement the solution.

An SRS includes a description of the Problem Domain (see Enterprise Analysis), a

decomposition of the problem domain (5.2), a description of the functional requirements

that govern the solution (5.3—usually a selection of techniques from each class of model

is included), the relevant quality of service requirements (5.6), assumptions and

constraints affecting the solution (5.7) and may include requirements attributes (5.8) and

traceability information (Error! Reference source not found.) if the solution is

complex enough to warrant it.

5.9.5 Stakeholders

See 5.3.5

5.9.6 Deliverables

A requirements document that contains a fully analyzed set of requirements for a formal

presentation and sign-off from key stakeholders.

5.10 Task: Validate Requirements

5.10.1 Purpose

To ensure that the stated requirements correctly and fully implement the business

requirements as defined during Enterprise Analysis.

5.10.2 Description

To be added in later drafts…

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

208

5.11 Task: Verify Requirements

5.11.1 Purpose

Requirements verification ensures that requirements are defined clearly enough to allow

solution design and implementation to begin. Customer, user and project team

collaboration is required to complete this activity.

5.11.2 Description

Requirements can be considered to have been verified when the analyst can demonstrate

that they have enough information to allow the solution development process to begin.

This requires that project stakeholders agree that the requirements are correctly

understood and that the business analyst validates with the customer and user that the

requirements completely describe what is to be implemented and meets the relevant

quality standards.

5.11.3 Predecessors

Validation represents a final check by the Business Analyst to determine that the

requirements analysis has been correctly performed and that the requirements are ready

for review by the stakeholders. All tasks in this knowledge area must have been completed

prior to validation.

5.11.4 Process and Elements

The Business Analyst must verify that requirements have been specified uniquely in well-

written, unambiguous requirements statements.

• There is an absence of duplicate or overlapping requirements

• The requirements are feasible, implementable, and are not outside the capability

of current technology

• The requirements that will be implemented in the current release have been

stated in their entirety

• The requirements are used to conduct further analysis

• There is more effective use of project resources because of reduced rework

caused by defects in requirements

• The requirement does not make assumptions about how it will be implemented

except where mandated by constraints placed upon the solution. User interface

requirements are the most likely to require implementation assumptions.

Good requirements are unambiguous, complete, verifiable, consistent, correct,

modifiable, traceable, testable, and usable after development.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

209

.1 Criteria for Assessing Requirements Quality

Figure 5.5: Criteria for Assessing Requirements Quality

Criterion

Description

Allocatable

The requirement can be allocated to an element of the system design where it

can be implemented.

Attainable

Attainable means that the requirement is technically feasible and fits within

the project funding and timing constraints. Even if a requirement is technically

feasible, it may not be attainable due to constraints, e.g., weight or speed.

Complete

To be complete, all known requirements are documented and all conditions

under which a requirement applies are stated. Each requirement must contain

all the information necessary for the technical team to design, build and test

that component of the system.

Consistent

Consistency demands that the requirement can be met without causing

conflict with any of the other requirements.

Correct

Each requirement must accurately describe the functionality to be built. Only

the customer, user or stakeholder who was the source of the requirement can

determine its correctness.

Does Not Prematurely

Determine Solution

The requirement should be stated in a way to allow the widest possible

selection of implementation options.

Feasible

Feasible means that it is possible to implement each requirement within the

capabilities and limitations of the technical and operational environment.

Measurable and

Testable

Requirements that are testable are designed to demonstrate that the system

satisfies requirements. Tests may include functional, performance, regression,

and stress tests.

Necessary

A necessary requirement is one that is essential to meet the business goals and

objectives. If the system can meet prioritized, real needs without it, the

requirement is not necessary. The requirement should be traceable to a goal

stated in the project charter, vision document, business case, or other initiating

document.

Prioritized

A priority is assigned to each functional requirement or feature to indicate how

essential it is to a particular system release. If all requirements are considered

equally important, it is difficult for the Business Analyst and the Project

Manager to respond to budget cuts, schedule overruns, staff turnover or new

requirements added during development.

Traceable

The origin (source) of the requirement must be known, and the requirement

can be referenced or located throughout the system. (Note: an automated

requirements traceability tool enables finding the location in the system where

each requirement is met.)

Traceable backwards: each requirement should be traced back to specific

customer, user or stakeholder input, such as a use case, a business rule, or

some other origin.

Traceable forward: each requirement should have a unique identifier that

assists in identifying, maintaining change history, and tracing the requirement

through the system components.

Unambiguous

To be unambiguous, all readers of a requirement should arrive at the same

interpretation of its meaning. Requirements that are written in simple, concise,

straightforward language are more likely to be unambiguous. All specialized

terms and terms that might be subject to confusion should be well defined.

Understandable

Understandable means that the requirements must be clear, concise, simple

and free from ambiguity. Ambiguous requirements are often misunderstood,

resulting in rework and corrective actions during the design, development and

testing phases. If the requirement can be interpreted in more than one way, it

should be removed or clarified.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

210

Criterion

Description

When writing requirements, the author should use simple, short sentences and

imperative phrases using shall. Statements indicating goals or using the word

will are not imperatives.

Verifiable

Verifiable means that the requirement states something that can be confirmed

by examination, analysis, test, or demonstration. A good requirement does not

contain words that are not testable and measurable. If it is impossible to

ensure that the requirement is met in the system, it should be removed or

revised. The verification method and level (i.e., the location in the system

where the requirement is met) at which the requirement can be verified

should be determined explicitly as part of the development of each

requirement. Requirement statements that include words that have relative

meaning are not verifiable. For example:

• Easy

• Maximum

• Minimum

• Better than

• Adequate

• Substantial

• Quality product

• Comparison

• More efficient

Business analysts are challenged with writing “good” or “valid” requirements. Typical

problems that are encountered when writing requirements include:

• An incomplete understanding of the requirement; failing to ask for clarification

• Incorrect interpretation of the requirement; applying personal filters to the

information that alter the intent

• Writing about implementation (the how) instead of requirements (the what).

Implementation decisions should be deferred to as late a point in the

Requirements Elicitation process as possible.

• Using undefined acronyms

• Using incorrect sentence structure

During the requirement analysis and documentation process, requirements are often

categorized as valid or invalid. Invalid requirements are incomplete in some way – vague,

ambiguous, inconsistent, incorrect, untestable or not measurable – and therefore it is

impossible for a solution to be tested to determine whether or not it meets that

requirement.

Figure 5.6: Valid vs. Invalid Requirements

Invalid Requirements

Valid Requirements

Lightweight

Weight </= 20.0 oz.

Must be better than current system

Operational availability >/= 0.95

High quality

Operational availability >/= 0.95 of the time

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

211

.2 Checklists

Checklists are useful as a quality control technique. They may include a standard set of

quality elements that the Business Analyst or other reviewers should use to validate the

Requirements Specification or be specifically developed to capture issues of concern to

the project. The purpose of a checklist is to ensure that

5.11.5 Stakeholders

The Business Analyst, in conjunction with the solution delivery team, will have the

primary responsibility for determining that this task has been completed. Problematic

requirements may be discovered by other stakeholders during requirements

communication.

5.11.6 Deliverables

The Business Analyst will revise the requirements specification (5.9) to ensure that the

requirements stated there are fully valid and ready for stakeholder review.

Appendix

5.12 Technique: Data and Behavior Models

Data and Behavior models may also be referred to as static models. They describe the

kinds of things that exist within the scope of the solution, the information that the system

records about those things, the way that they relate to one another, and the rules that

govern their behavior. The data and behavior model does not show how the solution

behaves through time, or how persons outside the solution scope interact with the

solution.

5.12.1 Business Rules

.1 Purpose

The purpose of Business Rules Management is to provide a formal structure for the

identification, documentation and maintenance of business rules, and allow for the

implementation of those rules in a separate repository to facilitate making changes to

them in the future.

.2 Description

The organization and operation of most business enterprises is directed and constrained

by internal and external (e.g. by regulatory bodies) policies, or business rules. For

example, there may be a business rule that “Payment of employee expenses requires the

100% reliable

Kill probability </= 0.9

Range > 500 mi.

Range >/= 500 mi.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

212

approval of a manager at Level 5 or above”. Business rules, and changes to them, may

have a significant impact on business processes, business data and business systems.

A business rule describes a policy, guideline, standard, or regulation upon which the

business operates. A Business Rule is a statement that defines or constrains some aspect of

the business. It is intended to assert business structure, or to control or influence the

behavior of the business.

The business rules that concern the project are atomic, that is,

they cannot be further decomposed, and they are not process-dependent, so that they

apply at all times.

.3 Intended Audience

Coming soon…

.4 Process

Coming soon…

.5 Key Elements

A Business Rule is usually captured as a textual statement that defines the rule exactly and

unambiguously. Each Business Rule has a unique identifier.

Because a single Business Rule may impact a number of different business processes,

Business Rules are usually documented separately in some form of Business Rule Catalog.

This allows Business Rules to be documented and managed non-redundantly.

The Business Rule Catalog is managed as an on-going process, and may be supported by

rules management software.

Textual Rules

• A business rule should be a well-formed written requirement (5.5.4.1) and must

be uniquely identified. Common types of Business Rules include:

• Term: A term defines the meaning of a word or phrase with a specific meaning to

the stakeholders. The term must be unique and includes a definition of what is

known about the thing in question.

• Fact: A fact describes the relationship between two or more terms. Relationships

may include one term being part of another, one term interacting with another,

or any other relevant connection between the two. A derived fact is one that is

computed or inferred from other facts (e.g. if a always relates to b, and b always

relates to c, then a must relate to c).

• Derivation: Derivations are used to create new information from existing

information. A derivation may be the result of a calculation (e.g. the duration of a

The Business Rules Group. www.businessrulesgroup.org

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

213

process is the elapsed time between the start date and the end date) or the result of

a logical inference based on known information.

• Assertions: Assertions state what values of a term or fact are considered valid by

the business under given circumstances. Assertions can be further broken down

into three types:

o Authorization: An authorization rule determines whether a person may

perform a specified action.

o Condition: A condition specifies a circumstance under which another

business rule may be applied.

o Integrity Constraint: Specifies which values of a term or fact are

permissible, given a specified value of another term or fact.

• Action Enabler: Action Enabler rules trigger an activity or a message if a certain

condition becomes true.

• BR654 Payment of employee expenses requires the approval of a manager at

Level 5 or above.

• BR728 Claims for employee expenses must be submitted for approval no later

than 15 days following the date that the expense was incurred.

More complex Business Rules may require a more extensive textual description, or a

diagram such as a Flowchart or Activity Diagram. It may be necessary to provide an

example to clarify understanding of a Business Rule.

Decision Tables/Trees

Decision tables are used to structure the presentation of a series of closely related Business

Rules. Anything that is presented in a decision table or a decision tree can be stated as a

series of sentences, but the tabular format makes it easier for stakeholders to understand

the essential similarities and focus in on the differences.

A decision table may also be used when multiple rules may apply to a situation…

Note: Needs expansion and completion.

.6 Usage Considerations

Business Rules Management may be used whenever it is necessary to ensure that the

policies that constrain and direct the operation of a business are well understood and

correctly implemented.

The strength of Business Rules Management is that it provides a structured, rigorous and

non-redundant approach to the management of Business Rules. This serves to ensure that

Business Rules are properly implemented, and that the impact of changes to Business

Rules can be assessed more easily.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

214

Business Rules Management, however, does require an additional set of documentation

to be developed and maintained, and additional effort to ensure that the impact of the

business rules on other functional requirements is properly understood. This technique

is most effective when business rules are applied across multiple processes, or when the

solution includes a separate component for managing and enforcing the Business Rules.

If neither condition is met there is little value in separating the business rules from the

other models used to describe the solution.

.7 Complementary and Alternative Techniques

Business Rules may be encapsulated in Process/Flow Models (5.13), a Metadata

Definition (5.12.7) or in a Use Case Description (5.14.3).

Terms and Facts may be fully described by a Data Dictionary (5.12.4), Class Model

(5.12.2), or Entity-Relationship Diagram (5.12.6). Other Business Rules may be

encapsulated in Process/Flow Models (5.13), a Metadata Definition (5.12.7) or in a Use

Case Description (5.14.3).

5.12.2 Class Model

.1 Purpose

The purpose of a Class Diagram is to show the entities relevant to the solution, along with

each entity's internal structure and relationships with other entities.

.2 Description

Class Diagrams show a set of related classes that exist within the solution domain and the

associations that each class has with other classes. A class represents a distinct concept

within the solution domain, which may represent a physical item, a logical collection of

information, a piece of functionality within the system, or an action that may be taken.

Each particular instance of a class (the actual physical thing, the execution of an action,

etc.) is an object.

A class has attributes that describe it and operations which it knows how to perform. A

typical class has the following characteristics that distinguish it from other classes:

• Attributes: Attributes of a class describe the information that may be recorded

about an particular instance, or object. They may include a description of the

possible states (5.13.6) or other data that may be of interest. Attributes are

created, modified, and deleted through a class’s operations.

• Operations: Operations describe what a class can do. Operations accept

attributes, modify them, and output a result. This result may be communicated to

other classes. Classes may only affect one another by requesting that an operation

be performed through a message. Classes must be associated in order to send

messages.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

215

.3 Intended Audience

Class Models, when developed by a Business Analyst, are used to communicate the

logical view of the requirements or the problem domain to the system architects or

designers to help them design the technology-specific solution. System Architects (or

designers) and developers also study the class models to understand the existing system

and dependencies of various business entities therein. Old or previously developed class

models are also used by business analysts themselves to model a business's current assets

and resources, such as account ledgers, products, or geographic hierarchy.

.4 Process

Coming soon…

.5 Key Features

The format and elements of the Class Diagram are defined in the UML standard

maintained by the OMG.

.6 Usage Considerations

Strengths

• A logical class model also makes it easier to build and design system architecture.

• A logical class model is the best way to create visualizations of code and other

forms of implementation.

Weaknesses

• Class models result from an object-oriented analysis and design approach and

may not be as useful for non-OO solutions.

.7 Complementary and Alternative Techniques

The Entity-Relationship Diagram (5.12.6) may also be used to describe the entities of

interest to the solution domain and the relationships between them.

Variations

Many variant notations for the class diagram were used prior to the development and

adoption of the UML standard.

The Object-Role Model is a variant technique that serves a similar purpose to the Class

Model in analysis. Unlike the Class Model, the Object-Role Model does not include data

elements other than those required to describe how entities relate to one another.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

216

5.12.3 CRUD Matrix

.1 Purpose

The CRUD Matrix is used to define different levels of access rights to data stored within a

software solution.

.2 Description

The CRUD (Create, Read, Update, Delete) Matrix cross-references user groups against

the entities managed within a system. For each data element, it states which user groups

are allowed to create, read, update, delete, or list those entities.

.3 Intended Audience

The CRUD Matrix will be used by stakeholders to validate which data is available to each

group of end users and by the development team to implement system security.

.4 Process

The CRUD Matrix requires that the Business Analyst identify sets of users who have

different access rights to the data stored in the system. User Profiles (5.14.6) may be used

as the basis for these user groups, as may Actors identified through Use Cases (5.14.3 and

5.14.4).

The CRUD Matrix also requires that a detailed data model be defined for the system,

generally through a Class Model (5.12.2) or an Entity-Relationship Diagram (5.12.6). A

Data Dictionary (5.12.4) may also serve as the basis for a CRUD Matrix, but as the Data

Dictionary is likely to contain many more entities than a Class Model or Entity-

Relationship Diagram, the CRUD Matrix will be harder to develop and maintain.

The Business Analyst should consider which user groups require access to the

information stored in each data element. The appropriate access level should be

determined through consultation with the stakeholders, from the Functional

Requirements defined for the system, and from any Privacy (5.6.4.6) or Security (5.6.4.9)

requirements. Create, update, and delete rights should be carefully examined to ensure

that data within the system is properly managed.

As a final validation step, the Business Analyst should check that each entity in the CRUD

matrix can be created, read, updated and deleted by one or more user groups (in other

words, that each of these rights levels appears in the column beneath the data element).

At least one user group must have each of these rights for every data element managed by

the system, unless the data element is managed in a different system.

.5 Key Features

The CRUD Matrix breaks access rights down into five possible levels of security:

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

217

• Create: members of the user group may instantiate new instances of that data

element.

• Read: members of the user group may view all data stored in the data element.

• Update: members of the user croup may change the data stored in the element.

• Delete: members of the user group may delete instances of the data element.

• List: members of the user group may list all instances of the data element but do

not have access to internal data. This is optional and often subsumed into Read.

User groups may have none, one, some, or all of these access levels to any particular

entity. If no rights are specifically granted, the group is not allowed to access the data.

Users with Update access to an entity will likely have Read access to it as well.

The CRUD Matrix organizes these access levels into a matrix for easy reference, as shown

in the following example:

Figure 5.7: CRUD Matrix Example

Entities

Entity 1

Entity 2

Entity 3

Entity 4

Entity 5

Group 1

Group 2

CLD

Group 3

CRUD

Group 4

CRU

User Group

Group 5

CRD

.6 Usage Considerations

The CRUD Matrix is intended for use in software development projects and is unlikely to

be of much value in Business Process Analysis.

The Business Analyst must be careful to keep the CRUD Matrix consistent with the user

groups and entities identified elsewhere in the requirements.

.7 Complementary and Alternative Techniques

The information expressed in a CRUD Matrix may also be captured in Use Case

Descriptions (5.14.3) or in Business Rules (5.12.1).

Business Analysts working with use cases may also use the CRUD Matrix to verify that a

use case exists that is able to update each entity. In this case the use cases will replace the

user groups in the matrix.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

218

5.12.4 Data Dictionary

.1 Purpose

A data dictionary defines the data that is recorded or used by an organization.

.2 Description

A Data Dictionary defines the data that relates to the solution, including both the

primitive data elements and the more complex data structures that will be built out of

them.

.3 Intended Audience

The data dictionary is typically aimed at non-technical stakeholders in a solution, such as

managers and end-users. Technical stakeholders will generally require that the Data

Dictionary be elaborated into a Class Model (5.12.2) or Entity-Relationship Diagram

(5.12.6). Business Process efforts may not require that a more detailed data model be

developed.

.4 Process

The Data Dictionary is collected throughout the Requirements Elicitation process by

collecting definitions of terms from stakeholders as data that they must use is

encountered. When contradictory definitions are encountered or aliases for the same

data elements are found to be in use, the Business Analyst must work with stakeholders to

reach an agreed definition.

.5 Key Features

A data dictionary contains definitions of each primitive data element and indicates how

those elements combine into composite data elements.

Primitive Data Elements

The following information must be recorded about each data element in the data

dictionary:

• Name: a unique name for the data element, which will be referenced by the

composite data elements.

• Aliases: alternate names for the data element used by various stakeholders.

• Values/Meanings: a list of acceptable values for the data element. This may be

expressed as an enumerated list or as a description of allowed formats for the data

(including information such as the number of characters). If the values are

abbreviated this will include an explanation of the meaning.

• Description: the definition of the data element in the context of the solution.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

219

The primitive data element can also be expressed in a short form, as follows:

Data Element Name = [enumerated list 1 | enumerated list 2] *description, including

format*

In other words, all information regarding the data element is contained within a

comment, which is delineated by an asterisk on each end of the comment. The only

information that is not included in the comment is a list of values for the data element.

Those values are contained within brackets.

Composite Data Elements

Composite data is assembled from primitive data elements. The composite data element

is assigned a unique name, which is followed by an equals sign before the primitive data

elements are listed. Composite structures include:

• Sequences: show primitive data elements in order, separated by a ‘+’. The

primitive elements must always occur in the specified order.

• Repetitions: show that one or more primitive data elements occur multiple times

in the composite element. The repeated element or elements are enclosed within

curly braces (‘{‘ and ‘}’). The allowed number of repeats are shown before the

braces, with a colon separating the minimum and maximum. The minimum may

be 0. If the maximum is unlimited, the letter ‘m’ is used.

• Optional Elements: may or may not occur in a particular instance of the data

element. They are enclosed in parentheses.

Example:

• Composite Data Element = Primitive 1

• + Primitive 2

• + 1:20 {Primitive 3 + Primitive 4 + Primitive 5}

+ (Primitive 6)

.6 Usage Considerations

The Data Dictionary is useful for ensuring that all stakeholders in a solution are in

agreement on the format and content of information relevant to the system. Capturing

these definitions in a single model ensures that these terms will be used consistently.

If the project will result in the implementation of a software system, the Business Analyst

may prefer to use an alternate method (below).

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

220

.7 Complementary and Alternative Techniques

The Business Analyst may choose to capture Business Rules (5.12.1) governing the data

while the Data Dictionary is compiled.

In software development projects, the data dictionary is likely to be a intermediate

analysis product that will be refined into a Class Model (5.12.2) or an Entity-Relationship

Diagram (5.12.6). The Business Analyst may choose to bypass the development of a Data

Dictionary in favor of one of those techniques.

5.12.5 Data Transformation and Mapping

.1 Purpose

Data Transformation and Mapping is used on application development projects that

require use of existing business data records. The organization has made a decision to

have these business records available in a new business process.

Planning for data transformation and mapping must occur before moving data records

into a new business solution. This ensures that the historical business data records are

consistent with the new business solutions needs.

Variants on Data Transformation and Mapping include:

• Extraction, Transformation, and Loading (ETL) , which describes the end-to-end

project process:

o Extraction is the task of acquiring the data from different source systems.

o Transformation is analyzing the data formats of the acquired data records

and understanding how to cleanse the records to support the new

applications business goals. Business rules are developed to understand

what to correct or reject. The conversion involves changing the original

data into a form needed by the target system.

o Load accomplishes writing the transformed data is into the new data

store.

.2 Description

Data Transformation and Mapping provides a way for a project to understand several

data challenges.

Different places: This data may lie in heterogeneous systems. For example data records

may be in a mainframe legacy application, an off the shelf vendor database, a flat file or an

excel spreadsheet. This data is moved to support a business process or a requirement to

view historical information.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

221

Different definitions: The data may be defined differently. For example a customer site

may either be the billing site or a installed at location. Therefore the data transformation

and mapping process involves gaining agreements on names and fields and determining

how to map various systems to the new business solution names and fields. This planning

is done to develop the value case needed to enforce consistency with the stakeholders.

Varying levels of quality: The data may not be accurate. For example, multiple records

for the same customer may exist. Therefore the data transformation and mapping process

quantifies the extent of the cleansing the data needed to remove duplicates. This as-is

analysis and metrics will lead to suggested to-be process improvements or system

enhancements that prevent future data pollution.

Tools used in preparing a Data Transformation and Mapping analysis may be software

based, but is intended to be an analysis of the data that doesn’t require complex tools.

.3 Intended Audience

Data Transformation and Mapping planning is a cross-functional effort facilitated by an

analyst to gain agreement between business process users, business process champions,

data record business owners, data administrators, operations groups and the subject

matter database experts on the plan to accomplish the data migration The purpose is to

identify data issues, business rules issues and a framework for moving data from a current

system to the new business solution with minimal disruption to the users.

.4 Process

This process covers requirements planning activities for Data Transformation and

Mapping. While there can be a sequential process, many of these steps can be

accomplished concurrently.

High level data modeling: Projects use Data Transformation and Mapping to review the

existing data record structures against a proposal for a high-level model of the new

business solution. This process is iterative and varies based on the number of different

data record resources and the amount of data records that need to be analyzed.

Data Analysis: Current data records are reviewed for consistency against the proposed

high-level data model. Metrics are gathered to understand the size of the issues.

Stakeholders are asked to resolve inconsistencies between the source data records and the

proposed business solution.

Iterative Review of analysis model and project assumption: Document discovery of new

assumptions, requirements, constraints or data inconsistencies that require updates to the

high-level analysis models or project plans.

Enterprise Data Model: Align and review project specific Data Transformation and

Mapping efforts with the enterprise architecture vision.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

222

.5 Key Features

There is no formal, universally accepted standard for Data Transformation and Mapping.

The level of detail required in a Data Transformation and Mapping and the format used

in the documentation must be selected by the business analyst to match the specific needs

of stakeholders, project team, data types and target data repository.

A Data Transformation and Mapping process, no matter what methodology is used, must

include the following:

• Hi-level data model that provides a description of the entity-relationships. Other

attributes can be completed during design.

• Data business rules: Identification and stakeholder agreement on business rules

for use in cleansing and project requirements. Ownership of the data is defined

along with documented processes for business changes and approvals.

• Data cleansing plan: Documentation of responsibilities of deliverables needed

for source data records that can be used by the target data repository. These

deliverables are aligned with the proposed business process needs.

• Environment plan: The data can not be directly moved from the source data

records to a production system. A migration plan for staging the data transfer

should be developed with clear responsibilities, deliverables and business

solution data quality criteria.

Other elements may be required in specific methodologies or under specific

circumstances. These may include:

• Business data categories: This is also called business meta data and provides

context or organization of the data through a business viewpoint.

• Source and Target Record Naming conventions: For code and document

naming to assist in project organization

.6 Usage Considerations

This is the early analysis phase of a project process that allows an enterprise to develop

analysis that supports the plan to:

• move data from multiple sources

• reformat and cleanse it.

• load it into another database, a data warehouse for analysis, or onto another

operational system

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

223

Data Transformation and Mapping is used to uncover issues that will occur during the

data loading or eventually be discovered by users. Business-focused data analysis allows

alignment of the project with the enterprise business needs. This is completed with

stakeholder review of models, rules and migration plans.

This will be a difficult process if neither business owners nor development subject matter

experts are available to the project. This can increase development time or cause

surprises after roll-out process issues if as-is usage is not understood or documented.

Data migrations are done infrequently. Therefore many enterprises do not have personal

or tool experience needed to complete these projects.

Models, rules, and reviews must be completed to minimize the risk that an improperly

implemented Data Transformation and Mapping destroys or corrupts data in the target

system.

.7 Complementary and Alternative Techniques

Data Transformation and Mapping process has no alternatives if data needs to be moved

from source systems into a target business solution. There may be tailoring of the project

depending on the size of the project or to mitigate risks in known data integrity issues.

5.12.6 Entity Relationship Diagrams

.1 Purpose

An Entity Relationship Diagram (ERD) is a visual representation of a data structure.

Because they describe things that are significant to the enterprise (e.g. Customers,

Products, Employees, Invoices, etc.), ERDs are useful in describing the structure of the

business itself, and many of the rules by which it is governed.

.2 Description

An Entity Relationship Diagram is a visual representation of the entities of interest to the

solution, the information that must be retained about each entity, and the relationship

between them.. Primarily it shows rectangles representing “things” (entities) about which

data is needed, lines that represent relationships between entities, and annotations on

these lines to represent the numerical constraints of these relationships.

Standard

ERDs were first introduced in 1976 by Peter Chen and have since been extended and

improved by additional contributors. No formal standard exists.

.3 Intended Audience

Business Analysts use Entity Relationship Diagrams to communicate data requirements to

business area experts. They are also used by analysts to communicate the agreed

requirements to developers.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

224

.4 Process

Developing an ERD is an iterative process. It typically proceeds as follows:

• From descriptions of the business area, identify what appear to be the things of

significance about which data will be required. This will provide an initial list of

candidate entities that will be refined as analysis proceeds.

• From continued analysis identify the attributes of each entity and the

relationships between them. Continue to develop the model as these are

identified.

• From the identified attributes, decide on an appropriate unique identifier for

each entity. In the absence of attributes that will serve this purpose, assign a

surrogate (e.g. Employee Number).

• When the model is complete, ensure that each entity is normalized to third

normal form.

• Validate the model with business area experts.

.5 Key Features

An Entity Relationship Diagram has four main components:

Entities: an entity represents a group of uniquely identifiable people, places, things or

concepts about which a business area needs information. (e.g. Customers, Products,

Employees, Invoices, etc.).

Attributes: an attribute is one of the individual pieces of information that describes an

entity (e.g. Customer Name, Product Price, Employee Number, Invoice Date).

Unique Identifiers: a unique identifier is an attribute, or a combination of attributes, that

will uniquely identify each separate occurrence of an entity (e.g. Customer Number,

Invoice Number, Social Insurance Number).

Relationships: a relationship is a significant business association between two entities. It

reflects how data from one entity needs to be used in conjunction with data from another

entity. It also reflects a “business rule” of the enterprise.

At each end of a relationship line, a notation indicates the minimum and maximum

number of occurrences of one entity that may be associated with the other entity. This

notation is known as the “cardinality” of the relationship. A variety of notations are in

popular use, all expressing the same general concept.

The possible permutations of minimum and maximum cardinality are:

• Zero or one

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

225

• Zero or more

• One and only one

• One or more

The following diagram illustrates these components and expresses the following business

rules:

• Each customer places zero or many orders

• Each order is placed by one and only one customer

• Each order contains one or more order items

• Each order item is contained in one and only one order

• Each order item is for one and only one product

• Each product is ordered as zero or many order item

In addition, the diagram describes the attributes and unique identifiers of the Customer,

Order, Order Item and Product entities.

ERDs may also be shown with less detail, as follows:

Each entity is

shown as a

rectangle with

the entity name

The unique

identifier of the

entity is shown

under the entity

name

The attributes of

the entity are

listed below the

unique identifier

Relationships are indicated by a

line, which is annotated to

show cardinality

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

226

.6 Usage Considerations

Logical Entity Relationship Diagrams can be used by a Business Analyst to:

• Develop and document an understanding of the entities of significance to a

business area and the rules that govern the relationships among them.

• At a high level, simplify and clarify complex issues and explain concepts

• At a detailed level, document the data requirements of a business area

• Present a specification of data requirements to a database designer in a single

comprehensive document.

Strengths

• Flexibility, in that they can be used at a high level to develop a conceptual model

with minimum detail, or at a detailed level to fully describe the data requirements

of a business area.

• A useful and comprehensive deliverable to a database designer, especially in a

relational database environment.

• Rigor, in that they are based on mathematical concepts (relational calculus) that

provide some stringent rules for correctness and completeness.

Weaknesses

• Complexity. If not properly presented, they can be difficult for users to

understand and relate to.

• Data-centric. Process modeling must be completed with separate models.

.7 Complementary and Alternative Techniques

Entity-Relationship Diagrams should be supplemented by Business Rules (5.12.1) and

Metadata Definition (5.12.7).

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

227

Entity Relationship Diagrams may be replaced with:

• Textual documentation that categorizes and describes entities, attributes and

relationships

• Object Role Models. These are a more complex diagram type that also cover data

structures.

• Class Diagrams. There are many similarities and shared concepts between Entity

Relationship Diagrams and Class Diagrams. They are both static, or structural,

models that describe “what” is important to the enterprise.

Variations

There are several variant notations for the Entity-Relationship Diagram.

Logical Data Models are used in the SSADM methodology. They are functionally almost

identical, although the notation is slightly different.

5.12.7 Metadata Definition

.1 Purpose

Metadata is information about data used by a solution that helps the Business Analyst to

explain the context in which the data is used.

.2 Description

Metadata is information that describes the context, use, and validity of business

information. The definition of metadata is “data about data”, that is, it describes

information that the solution or system needs to know in order to make the data

intelligible and to ensure that the data is valid.

.3 Intended Audience

.4 Process

To be defined…

.5 Key Features

The capture and maintenance of metadata is normally a byproduct of the functioning of

the system. Since metadata primarily concerns the usage…

Note: define key features of metadata…

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

228

.6 Usage Considerations

Metadata must eventually be recorded within the solution to be of any value. That means

that the process and/or the system must be structured to facilitate its capture and

maintenance, even if the users of the solution never directly update it.

.7 Complementary and Alternative Techniques

Metadata includes information that a business analyst is likely to capture and describe

using other techniques in this knowledge area. In particular:

• The structure of the primitive data element and composite data elements that

include the data element will be described using a Class Model (5.12.2), Data

Dictionary (5.12.4), or Entity-Relationship Diagram (5.12.6).

• Ownership of and access to the data element may be described using a CRUD

Matrix (5.12.3).

• Business Rules (5.12.1) may also describe ownership of the data, the relationship

between data elements, what values of that data element are valid under given

conditions, and rules governing when and how that data may be changed.

The techniques above describe those concerns more fully. However, if a Business Analyst

is not using some or all of those techniques, then those issues should be resolved as part of

Metadata Definition.

5.13 Technique: Process/Flow Models

A process/flow model may also be described as a dynamic model. These models show

how the system behaves over the course of time, through the execution of a business

process or as the result of events that occur inside the solution scope. They do not

describe the entities that are relevant to the solution outside of the context of a particular

series of events, nor do they describe how persons may interact with the solution from a

user perspective.

5.13.1 Activity Diagram

.1 Purpose

The purpose of an Activity Diagram is to graphically represent the flow of a sequence of

activities, and the logic that controls the flow. It shows the dynamics, or behavior, of the

sequence of activities represented in the diagram.

.2 Description

An Activity Diagram is a visual representation of the sequential flow and control logic of a

set of related activities or actions.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

229

An Activity Diagram can be useful whenever it is necessary to communicate the details of

a complex process.

Standard: The format and elements of the Activity Diagram are defined as part of the

UML standard maintained by the OMG. This description complies with version 2.0 of

that standard.

.3 Intended Audience

An Activity Diagram may be used by a Business Analyst to communicate the details of a

sequence of related activities to a business area expert or to a solution developer. The

sequence of activities communicated by the diagram may document an existing process,

or may represent an anticipated or recommended future process. The activities

represented may be manual activities, or automated, or a combination of both.

.4 Process

Completion of an Activity Diagram is generally accomplished by:

• Deciding the boundaries (start and end points) of the set of activities to be

modeled

• Determining details of the activities such as sequence dependencies, conditional

logic, and (optionally) performance responsibilities

• Completing the diagram

• Preparing brief textual descriptions, if necessary to avoid misinterpretation, of the

symbols shown in the diagram

.5 Key Features

An Activity Diagram typically has the following components:

• Activities, represented by rounded rectangles

• the sequential flow of activities, represented by an arrow-headed line

• the start point of the sequence, represented by a filled circle

• The end point of the sequence, represented by a bounded filled circle

• Branches, represented by a diamond, from one path to two or more mutually

exclusive alternative paths

• Merges, also represented by a diamond (or simply by converging flow lines) of

independent flows into a single flow

• forks, represented by a bar, from a single flow into two or more parallel flows

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

230

• joins, also represented by a bar, of a number of independent parallel flows into a

single flow

• responsibility for completion of activities in the diagram, represented by labeled

“swim-lanes” in which are shown only the activities for a specified area of

responsibility.

These components are illustrated in the following diagram.

ad New Product

Research & Development Production Marketing

Develop new

product concept

Analze market

potential

Cancel project

Build prototype

Confirm feasibility

of manufacture

Cancel project

Prepare for

production

Prepare

marketing plan

Commence

production

Commence

marketing

Release product

[potential not confirmed]

[potential confirmed]

[prototype successful]

[prototype unsuccessful]

[not confirmed]

[confirmed]

.6 Usage Considerations

Activity Diagrams can be used to:

• Analyze and describe a complex Use Case scenario

• Analyze and document business workflows (current or future)

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

231

• Describe any complex sequence of activities, or complex algorithms

• Document activities together with responsibility for their completion

Strengths

• Ability to visually represent complex flows with multiple decision points and

parallel flows

• Easy to develop and easily understood by most audiences

Weaknesses

• Complex sequences of activities documented with swim-lanes are often difficult

to organize for simplicity and easy comprehension.

.7 Complementary and Alternative Techniques

There are a number of other diagramming conventions that serve a similar purpose to the

Activity Diagram. These include:

• The IDEF3 diagram type developed by the U. S. Department of Defense.

• Flowcharts (5.13.4).

• Workflow models (5.13.7).

5.13.2 Data Flow Diagram

.1 Purpose

To show how information is input, processed, stored, and output from a system.

.2 Description

The Data Flow Diagram (DFD) provides a visual representation of the:

• External Entities that provide data to, or receive data from, a system

• The Processes of the system that transform data

• The Data Stores in which data is collected for some period of time

• The Data Flows by which data moves between External Entities, Processes and

Data Stores

It provides a data-centric view of the scope of the project, representing what the system

does, not how it does it. It is intended as a communication method between business and

system stakeholders. It may be used to represent an automated system or a business

system.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

232

.3 Intended Audience

Data Flow Diagrams are used as a communication between business stakeholders,

analysts and developers, data base designers, architects and other system stakeholders.

They should be written to be understandable by business representatives, but still be

specific about the data elements being processes.

.4 Process

Data Flow Diagrams are prepared by successive decompositions of a process hierarchy.

The first diagram (known as the Context Diagram) will show the system or business area

as a single process with data flows coming from and going to External Entities.

The single process in the Context Diagram is then decomposed successively into a

number of more detailed diagrams that show data inputs to and outputs from Data

Processes within the system or business area.

.5 Key Elements

The DFD uses a set of standard symbols for External Entities, Data Stores, Processes and

Data Flows

External Entities

An external entity is a source or a destination of data. Represented as a labeled rectangle.

External

Entity

Data Store

Data store represents a location where data is not moving or transforming but is being

stored passively for future use. Data stores are represented as a label between two parallel

lines or a labeled rectangle with a square.

Data Store

Data Process

A data process is a process that transforms the data in some way, either combining the

data, reordering the data, converting the data, filtering the data or other such activities.

An asterisk within the process is used to identify data processes that have further

decomposition models. Data Processes are represented as a labeled circle or a rectangle

with curved corners. Standard labeling is to use a Verb-object structure.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

233

Data Process

Data Flow

A Data flow identifies where Data is being moved between a Data Process and an External

Entity, a Data Store or another Data Process. The label should be a noun phrase that

identifies data being moved. Can be further specified into Result flows, Control flows and

Update flows. Data Flows are represented by a single or forked line with an arrow. Lines

must be labeled with a descriptor of the data being moved.

Data Flow

Example

System

User

User Profile

Verify user

Password

Valid user id

Last logged in date

.6 Usage Considerations

Data Flow Diagrams are used as part of a “structured analysis “approach. They are used to

get an understanding of the range of data within the domain. They are typically used after

a context diagram has been completed and as a prerequisite or concurrent activity to data

modeling.

Strengths

May be used as a discovery technique for processes and data, or as a technique for

verification of a Functional Decomposition and Entity Relationship Diagram that have

already been completed.

Most users find these diagrams quite easy to understand

Generally considered a useful analysis deliverable to developers in a structured

programming environment.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

234

Weaknesses

May not be the most useful analysis deliverable to developers in an object-oriented

environment.

.7 Complementary and Alternative Techniques

The Data Flow Diagram conveys similar information to that found in Activity Diagrams

(5.13.1), Flowcharts (5.13.4), Workflow Diagrams (5.13.7) and Use Cases (5.14.3 and

5.14.4).

Sequence diagrams also look at messaging of data between entities.

5.13.3 Event Identification

.1 Purpose

The purpose of Event Identification is to facilitate the discovery of the processes of a

system (either a business system or an automated system). There is no specific

diagramming technique associated with Event Identification. The processes identified

through the use of this technique are usually diagrammed by using a process modeling

diagram such as a Data Flow Diagram (5.6.2.) or a Process Decomposition (5.6.5.).

.2 Description

Event Identification asks the question “what are the events to which the system must

provide a response?”. Events may be of different types:

• External Events are those that are initiated by an entity that is external to the

system, for example “Customer places an Order”

• Temporal Events are those that are initiated by the passage of time, for example

“Month End”

• Internal Events are those that are initiated within the system, for example

“Inventory falls below re-order level”.

When events have been identified, the next question asked is “What processes are

required to provide a complete response to this event?”. The answers to this question

identify the processes of the system. These processes may then be documented, and

further analyzed, using an appropriate process modeling technique.

.3 Intended Audience

Event Identification is used by the Business Analyst to identify external triggers that begin

processes of interest to the stakeholders in the solution. It is primarily used by

stakeholders outside the project team.

.4 Process

Event Identification is usually completed by interviewing individuals who are familiar

with the system that is being analyzed, and are familiar with the events/responses that

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

235

activate the system. Where the system being analyzed is a business area, then business

area experts who are themselves responsible for responding to business events would be

interviewed.

Through these interviews, the events, and the processes required to fully respond to

them, are identified. Documentation of the processes would follow, usually in the form of

a process model such as a Process Decomposition or Data Flow Diagram.

.5 Key Elements

.6 When to Use

Event Identification can be used as an initial approach to any type of process modeling

where it is necessary to first identify what the processes are that make up the system or

business area that is the focus of analysis.

In particular, it is useful when it is necessary to identify processes at a lower level more

quickly than would be possible using top-down analysis.

The strengths of this technique are that:

• Business area experts usually find it easy to respond to this approach, because

they find events and their responses easy to identify from their work

responsibilities.

• This technique provides a quicker way than top-down process decomposition to

discover lower level processes

However, the event identification approach does not provide as structured an approach

to the analysis of complex processes as does top-down decomposition.

.7 Complementary and Alternative Techniques

Event Identification is a technique for identification and analysis of processes and it may

be used in conjunction with other techniques. Other approaches to process analysis

include top-down process decomposition, data flow diagramming, use case analysis and

workflow modeling.

5.13.4 Flowchart

Flowcharts are a visual representation of the sequential flow and control logic of a set of

related activities or actions.

Standard

Flowcharts are defined by the American National Standards Institute (X3.6 - 1970) and

the International Standards Organization (ISO 5807 – 1985).

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

236

.1 Purpose

The purpose of a Flowchart is to graphically represent the flow of a sequence of activities,

and the logic that controls the flow. It shows the dynamics, or behavior, of the sequence

of activities represented in the diagram.

A Flowchart can be useful whenever it is necessary to communicate the details of a

complex process.

.2 Description

A Flowchart is made up of a number of graphical symbols. These are described, and an

example is shown, in the sub-section “Key Features” below.

.3 Intended Audience

A Flowchart may be used by a Business Analyst to communicate the details of a sequence

of related activities to a business area expert or to a solution developer. The sequence of

activities communicated by the diagram may document an existing process, or may

represent an anticipated or recommended future process. The activities represented may

be manual activities, or automated, or a combination of both.

.4 Process

Completion of a Flowchart is generally accomplished by:

• Deciding the boundaries (start and end points) of the set of activities to be

modeled

• Determining details of the activities such as sequence dependencies, conditional

logic, and (optionally) performance responsibilities

• Completing the diagram

• Preparing brief textual descriptions, if necessary to avoid misinterpretation, of the

symbols shown in the diagram

.5 Key Features

A Flowchart typically has the following components:

• Activities, represented by rectangles

• the sequential flow of activities, represented by an arrow-headed line

• the start point of the sequence, represented by a rounded rectangle

• The end point of the sequence, represented by a rounded rectangle

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

237

• branches, represented by a diamond, from one path to two or more mutually

excusive alternative paths

• merges, also represented by a diamond (or simply by converging flow lines), of

independent flows into a single flow

• forks, represented by parallel bars, from a single flow into two or more parallel

flows

• joins, also represented by parallel bars, of a number of independent parallel

flows into a single flow

A number of other symbols representing, for example, documents, databases, storage

and input/output media, etc. are also available but are less frequently used.

The major components are illustrated in the following diagram.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

238

.6 Usage Considerations

Flowcharts can be used to:

• Analyze and describe complex Use Cases

• Analyze and document business workflows (current or future)

• Describe any complex sequence of activities, or complex algorithms

• Document activities together with responsibility for their completion

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

239

Strengths

• Ability to visually represent complex flows with multiple decision points and

parallel flows

• Easy to develop and easily understood by most audiences

Weaknesses

• Does not explicitly support the concept of “swim-lanes” to identify responsibility

for execution of a process.

.7 Complementary and Alternative Techniques

There are a number of other diagramming conventions that serve many of the same

purposes as a standard Flowchart. These include:

• The IDEF3 diagram type developed by the U. S. Department of Defense

• Activity Diagrams (5.13.1)

• Workflow Models (5.6.8).

5.13.5 Sequence Diagram

.1 Purpose

Sequence diagrams are used to model the logic of usage scenarios, by showing the

information passed between objects in the system through the execution of the scenario.

.2 Description

A sequence diagram shows how a use case scenario (5.14.3) is executed by the class

model (5.12.2). The classes required to execute the scenario are displayed on the

diagram, as are the messages they pass to one another (triggered by steps in the use case).

The sequence diagram shows how objects used in the scenario interact but not how they

are related to one another.

.3 Intended Audience

The sequence diagram is used by the Business Analyst to verify that Use Case Descriptions

(5.14.3) and Class Models (5.12.2) are consistent with one another. They are used by

developers during system implementation.

.4 Process

The Business Analyst identifies …

.5 Key Features

The sequence diagram shows particular instances of each class (i.e. objects) with a

lifeline beneath each object to indicate when the object is created and destroyed. The

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

240

earliest events in the scenario are depicted at the top of the lifeline, with later events

shown further down. The sequence diagram only specifies the ordering of events and not

the exact timing.

The sequence diagram shows the stimuli flowing between objects. The stimulus is a

message and the arrival of the stimulus at the object is called an event. There are two types

of objects:

• A passive object is active only while handling the event, and is shown with the

box representing the active state existing only while it handles a message;

• An active object is active for its entire lifetime, and with shown with the box for

the entire scenario.

A message is shown as an arrow pointing from the lifeline of the object sending the

message to the lifeline of the object receiving it. Message control flow describes the types

of messages sent between objects.

• Procedural Flow is usually indicated by a solid line with a filled arrowhead. An

object can send only one procedural message at a time and control is transferred

to the receiving object and the sender is blocked until a return (indicated by a

dashed line and open arrowhead) is received.

• Asynchronous Flow (also known as a signal) is indicated by a solid line and an

open arrowhead. The object after sending a signal may continue with its own

processing which implies parallel processing. The object may send many signals

simultaneously, but may only accept one signal at a time.

.6 Usage Considerations

The sequence diagram is most commonly used to validate the domain model in

preparation for solution design. As such, it is likely to be produced by developers during

the design of a solution for validation by a Business Analyst.

The sequence diagram may be used during analysis to validate the Class Diagrams against

the Use Case Descriptions, or to show the timing of interactions between entities within

the system scope.

.7 Complementary and Alternative Techniques

The sequence diagram can be used to model interactions with the user interface of a

software system. In this case the messages on the diagram will represent interactions

between the user of the application and various user interface elements. If the sequence

diagram is used for this purpose the Business Analyst may not use a Class Model for the

basis of the Sequence Diagram, as the relevant classes will be specified by the solution

designers at a later date.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

241

5.13.6 State Machine Diagram

.1 Purpose

The State Machine Diagram is …

.2 Description

A state machine specifies a sequence of states that an object goes through during its

lifetime, in response to events, and also the responses that the given object makes to those

events. The state machine has one or more possible states that a transitioned or triggered

by a signal.

There are usually many state chart diagrams describing the many complexities of any

software or system. It is possible to have composite states in a UML state machine. This is

a way simplifying the complexity of the requirements by defining a sub-state with a state

chart of its own.

.3 Intended Audience

.4 Process

As the Business Analyst further defines the requirements from the user’s language into a

more refined system requirement, it is necessary to also consider the business rules that

may be directly applicable to such things as a state machine. There may be policy and

legal implication to impose a specific state and transition. Again we see the emphasis on

traceability from the element to the requirement, but also to the other related

requirements (business rules) to ensure completeness of the model and the requirements

management process.

.5 Key Features

The State Chart Diagram helps detail the life of the object using the following three main

elements:

The possible states are depicted by boxes with round corners

The transitions that show how the object moves between states are depicted by a line with

direction arrow.

The events that cause the transitions are the labels on the lines

.6 Usage Considerations

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

242

.7 Complementary and Alternative Techniques

5.13.7 Workflow Models

A workflow model is a visual representation of the flow of work in a business area.

Workflow models are used to document how work processes are carried out, and to find

opportunities for process improvement.

.1 Purpose

Workflow models are used to depict the sequential flow of a work process.

.2 Description

A workflow model represents:

• business activities,

• the sequential flow of these activities,

• the persons who perform the work,

• key business decisions that affect the flow of work, and

• the start and end points of the process flow.

In addition to the diagram, some textual information is also required to ensure that the

diagram is useful and understandable. For example, each activity requires at least a

meaningful description. Other information, such as process volumes (e.g. time, costs,

resources), may also be collected.

.3 Intended Audience

Workflow models are used by analysts to develop and communicate their understanding

of business workflows to business area experts.

They are also used to communicate details of current and recommended future business

workflows to solution developers. A workflow model might be used to clarify a set of use

case scenarios that has complex logic and many alternative paths.

.4 Process

Completion of a process model where the current and future states are both modeled

generally proceeds as follows:

• Establish the scope of the process to be modeled by determining the event that

triggers it, the customer(s) who benefit from it, and the specific result(s) it is

intended to achieve

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

243

• Understand the current process, and its strengths, weaknesses, and problem

areas. Develop an “AS IS” workflow model to describe the current process.

Validate the model with business area experts.

• Identify opportunities for process improvement, and decide a process

improvement strategy. Develop one or more “TO BE” workflow diagrams to

describe recommended solutions.

• Present the recommendations to stakeholders for approval.

.5 Key Features

A workflow model typically has the following components:

Activities/Tasks: rounded rectangles show the individual steps or pieces of work that

must be completed in order to execute the business process.

Sequential flows: arrows indicate the direction of the step by step sequence of the

workflow.

Decision points: diamond shapes show forks where the flow of work proceeds in two or

more mutually exclusive flows and, optionally, where separate flows merge together.

Parallel flows: solid bars indicate branch points where the flow of work proceeds in two

or more parallel paths which subsequently join together again.

Swim-lanes: horizontal or vertical divisions indicate responsibility for performance of

the activities.

Terminal: symbols indicating the start and end points of the flow.

.6 Usage Considerations

Workflow models can be used by a Business Analyst when it is necessary to define how

and by whom business processes are carried out. This may be to:

• Develop and document an understanding of the current workflows in a business

area.

• Identify opportunities for process improvement, and recommend alternative

solutions.

• Understand and communicate complex business logic.

• Document business processes for user manuals and training documentation.

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

244

Strengths

• Ability to visually represent complex flows with multiple decision points and

parallel flows

• Easy to develop and easily understood by most audiences

• Support the identification of problems and alternative solutions

• Can show a workflow across the enterprise, or within one functional area

Weaknesses

Multiple sets of diagramming conventions (ANSI/ISO, UML, IDEF3, BPMN etc.)

.7 Complementary and Alternative Techniques

Use Cases are sometimes used to document business processes, but these do not have the

same capability for visual representation of sequence, control logic and parallel paths. A

workflow diagram can be depicted using the traditional ANSI/ISO standard flowchart or

with a UML Activity Diagram.

Variations

Other similar diagramming conventions exist but are less widely used. These include, for

example, the IDEF3 standard and IBM’s Line of Vision approach.

5.14 Technique: Usage Models

Usage models describe the interaction of a user with the solution. They describe how a

person interacts with the solution to fulfill the requirements. They do not describe

anything that exists within the solution scope unless that thing is visible to an external

user, nor do they describe processing that is invisible to an outside observer.

5.14.1 Prototyping

.1 Purpose

A prototype is a simplified representation of the user interface of a proposed software

application. They allow more realistic visual representation of user interaction with a

system. This allows end users to better understand the software solution and to either

provide confirmation that it supports their requirements or to provide feedback for

improvement. A prototype may also be used to demonstrate technical feasibility.

Variants on Prototypes include:

• Rapid prototyping, which describes quickly developed codes to demonstrate

functionality or feasibility of a complex feature or difficult interface or a portion

of an untested integration. It is developed quickly, altered or replaced after design

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

245

feedback. The special problems of reliability, throughput and response time as

well as system features are addressed in the best prototypes.

• Throw-away prototyping, see rapid prototyping.

• Proof of concept, see rapid prototyping.

• Evolutionary prototyping, which describes coding incremental functionality. This

demonstrates a portion of the system to the end user for feedback that is

incorporated in successive iterations in development. Code is retained in the final

implementation.

.2 Description

A prototype is an iterative design technique that allows end users to view a working

model and provide feedback that can be quickly incorporated to create a design more

suitable for the user community.

.3 Intended Audience

Prototypes are requested by analysts to get agreement from project stakeholders on

requirements that are hard to understand.

Prototypes may be used to obtain funding for development of the business solution.

.4 Process

The business analyst begins by identifying preliminary requirements that will be used to

build the prototype.

The project team decides what project elements contribute to risk. Technical team

members can advise on which features would be good candidates for prototyping. A

prototype should be built only for the elements where the business analyst needs more

insight from the stakeholders/users or to reduce the probability of failures found later in

construction.

Areas of risk need to be prioritized. Prototypes address the highest risk, highest value to

the end user first. Delivering what is easy only delays discovery of issues that may cause

the project to fail.

Next align the choice of a prototyping process with the development life cycle. The use of

throw-away prototyping is appropriate during an early feasibility assessment but is a

poorer choice for an iterative development life cycle where code is desired to be used in

the final production version.

Also align the choice of a prototype process with the available tool sets. Prototyping on

unfamiliar tools contributes to project risk. Prototyping activities are coordinated with

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

246

the systems analyst data models to ensure that the prototyping results can be used in the

project.

The prototype process is managed with a timeline, budget and exit criteria. The timeline

must be realistic to develop, evaluate and document the prototype. The budget must

allow for development of the model, recruiting end users, interviewing them while they

are using the prototype and evaluating the users design feedback. The process must allow

iterations needed to gain valid user feedback. The prototype must have predefined exit

criteria goals. This may be either number of users, number of iterations or quality of

feedback.

The business analyst walks an end user through a feature. The end user gives additional

requirements based on their experience. The application running the prototype is then

changed and the process is repeated with additional end users. This repetitive process

continues until the exit criteria are met.

Finally, the business analyst updates functional and supplemental requirements based on

the prototype.

.5 Key Features

There is no formal, universally accepted standard for prototypes. The level of detail

required in a prototype and the coding standards used in build must be selected by the

business analyst in conjunction with the project manager and in alignment with the

development life cycle.

A customer facing prototype, no matter which type is built, must include the following:

• Shell. This is the application that contains the online screens. There is only

enough programming of the core business processes to allow the prototype to go

from screen to screen. The user should see a screen and enter some information.

The logic will then go to the next screen or screens, passing whatever information

made sense from the first screen. In fact, user input could be accepted but

ignored, and all the screen values could just be hard-coded. The point is to

provide a visual representation of the application, not the complex business logic

that goes behind it.

Other elements may be required in specific methodologies or under specific

circumstances. These may include:

• Documentation for development

.6 Usage Considerations

A prototype is an effective risk reduction technique when working with an unfamiliar

business domain or which end users who needs are not understood. A tangible product is

very helpful in validating requirements in these situations. It is also valuable where there

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

247

is a high amount of technical risk that can be reduced by demonstrating feasibility of a

particular design alternative.

They are less effective for enhancement projects or when the domain and technical

expertise is very high.

They do not eliminate the need to provide functional requirements.

They may not be the best technique to describe features as they may only describe a small

portion of a user experience.

.7 Complementary and Alternative Techniques

Prototypes may be replaced by Storyboards (5.14.2) and User Interface Designs (5.14.5).

5.14.2 Storyboards/Screen Flows

.1 Purpose

Storyboards/Screen Flows do not involve working software code. They do provide an

early mock-up of proposed business solution functionality. This collaboration with end

users provides a low cost and quick design feedback for incorporation into improved

requirements documentation. For the purpose of this discussion they will both be

referred to as storyboards.

Variants on storyboards include:

• Paper based prototyping, which describes any paper-based simulation of an

interface or system.

• User experience storyboards, which describes user interface processes and

techniques needed to execute use case analysis models.

.2 Description

A storyboard provides a simple simulation of an interface or a use case using commonly

available office tools, e.g., white board, markers, index cards, post-it™ notes, scissors, or

transparency film. This is a low cost modeling technique that provides early design

feedback from users and is quicker than providing a working, coded user interface

prototype.

Tools used preparing storyboards may be software based, but the storyboard has no code

behind it.

.3 Intended Audience

Storyboards descriptions are created by analysts to get agreement between project

stakeholders on user interface issues. The purpose is to identify complex interfaces and

determine early ways to improve usability Early identification of usability issues reduces

Chapter 5 Requirements Analysis and Documentation

A Guide to the Business Analysis Body of Knowledge, Release 1.6

\http://www.theiiba.org/

248

project risk and increases user acceptance, user satisfaction and customer adoption of the

proposed business process or solution.

.4 Process

The business analyst begins by identifying ambiguous project areas that require user

involvement to clarify requirements. This involves creating the use cases if this has not

been completed yet and having the customer prioritize the use cases or usage models that

provide the most business value. Project do not have unlimited time to storyboard all

interfaces, especially those that are common or known to the end user community.

The business analyst also identifies the key end user types or classes that will utilize the

business process or solution. These user groups also are prioritized for participation in

the storyboarding process.

Usability factors are identified that are the target of the study. This may be behavior

needed, required sequence of tasks, user help, or end user ease of understanding

navigational elements. Options are unlimited so documentation of the goal is required.

The project core team then creates a prototype of a use case or a specific portion of a use

case or equivalent usage model. If this is high ambiguity about the requirements, several

different choices could be created for storyboarding.

The team then requests individual users that represent the end user types to step through

the prototype. A facilitator may guide a participant through the selections. A team

member responds to user storyboard choices and presents the next selection that is made.

This simulates a computer environment. Modifications can be made immediately to test

different navigation paths, supply additional input fields, or change field names.

Notes or a video record are taken of the session. Issues and their severity and a list of