REQUIREMENTS ELICITATION, ANALYSIS AND MANAGEMENT

Tim Roby, CBAP

Lead Transformation Business Analyst

DMV Service Transformation Program (STP)

INTRODUCTION AND PURPOSE• Purpose: discuss the important role of BA as it relates to requirements

• How do BAs deliver value?

• Requirements Elicitation

• Requirements Analysis

• Requirements Management

OUTLINE

1. The importance of high quality requirements and requirements management

2. Methods for eliciting requirements

3. Requirements analysis

a. Specify and Model requirements

b. Verify and Validate requirements

c. Define requirements architecture

4. Requirements approval

THE IMPORTANCE OF HIGH QUALITY REQUIREMENTS AND REQUIREMENTS

MANAGEMENT

• Inaccurate requirements gathering was the second most common primary cause of project failures. ~ PMI, Pulse of the Profession® – 2017

• 75% of organizations surveyed waste over one in three dollars spent in IT development and implementation annually as a result of poor requirements maturity. ~ IAG Consulting, Business Analysis Benchmark – 2009

• CIO’s cannot simply attempt to hire great analysts and expect the problem of poor requirements to go away: In fact, lower skilled people in a high requirements maturity company significantly outperform highly skilled people in a low requirements maturity company. ~ IAG Consulting, Business Analysis Benchmark – 2009

THE IMPORTANCE OF HIGH QUALITY REQUIREMENTS AND REQUIREMENTS

MANAGEMENT

• A total of 74.1% of the companies surveyed in The Business Analysis Benchmark –2009, were found to have a low level of requirements maturity (Maturity Level of 1 or 2 where maximum maturity is 5.). ~ IAG Consulting, Business Analysis Benchmark –2009

• There is a 60% time and cost premium to be paid on projects with poor quality requirements. ~ IAG Consulting, Assessing the Impact of Poor Requirements on Companies

• Sub-optimal requirements consumes approximately 41.5% of the IT development budget for people (internal and external) and software on strategic projects. ~ IAG Consulting, Assessing the Impact of Poor Requirements on Companies

IAG REQUIREMENTS MATURITY MODELProcess Practices &

Techniques

Deliverables Technology Organization

Staff

Competency

1

Performed

Informal/ inconsistent

definition and execution

Informal & Inconsistent use

Informal, non-standardized

documentation

Standard generic desktop

tools. No planned

approach to tool usage

Limited Support. Undefined Roles.

Little Training

Have a fundamental knowledge of

most core concepts & skills

2

Defined

Defined activities

performed on many projects

Best practices used. Guidelines defined but not

mandated

Templates, guidelines,

standards defined. Not mandated.

Used on most projects

Requirement automation

software tools provided.

Inconsistent usage

Organization has delegated

support of

business analysis best practices

and staff development to an individual or

team

Good knowledge of all

concepts and key BA skills

* IAG Consulting, Business Analysis Benchmark – 2009

IAG REQUIREMENTS MATURITY MODELProcess Practices &

Techniques

Deliverables Technology Organization

Staff

Competency

3

Implemented

Standards implemented

and followed on

majority of projects.

Detailed task definition

Standards implemented

used on majority of projects

Use of standard deliverables mandatory.

Quality standards well defined. Used on majority of

projects

Requirements management

software implemented

and mandatory

A formal Requirements/BA organization

established

Good demonstrated

ability in required

competencies

4

Institutionalized

Universally applied.

Integrated with PMLC/SDLC

Measurements of compliance,

and effectiveness are applied

regularly

Meets expectations on

virtually all projects.

Integrated with PM/SDLC. Fully

automated

Required

management software

integrated with project

management and application

life cycle management

software

Metrics are applied against

the center of support for

Business Analysis. Organization

measures effectiveness of

training

Solid knowledge, skills,

and ability. consistently

applied

* IAG Consulting, Business Analysis Benchmark – 2009

* IAG Consulting, Business Analysis Benchmark – 2009

* IAG Consulting, Business Analysis Benchmark – 2009

* IAG Consulting, Assessing the Impact of Poor Requirements on Companies

METHODS FOR ELICITING REQUIREMENTS

ELICITATION AND COLLABORATION

• BABOK ® v3 chapter 4:

• The Elicitation and Collaboration knowledge area is composed of the following tasks:

• Prepare for Elicitation

• Conduct Elicitation

• Confirm Elicitation Results

• Communicate Business Analysis Information

• Manage Stakeholder Collaboration

ELICITATION AND COLLABORATION

• Prepare for Elicitation: involves ensuring that the stakeholders have the information they need

to provide and that they understand the nature of the activities they are going to perform. It

also sets a shared set of expectations regarding the outcomes of the activity. Preparation may

also involve identifying research sources or preparing to conduct an experiment to see if a

process change actually results in an improvement.

• Conduct Elicitation: describes the work performed to understand stakeholder needs and

identify potential solutions that may meet those needs. This may involve direct interaction with

stakeholders, doing research, or running experiments.

ELICITATION AND COLLABORATION

• Confirm Elicitation Results: involves ensuring that stakeholders have a shared understanding

of the outcomes of elicitation, that elicited information is recorded appropriately, and that the

business analyst has the information sought from an elicitation activity. This task also involves

comparing the information received with other information to look for inconsistencies or gaps.

• Communicate Business Analysis Information: provides stakeholders with the information

they need, at the time they need it. The information is presented in a useful form, using the right

terminology and concepts.

• Manage Stakeholder Collaboration: describes working with stakeholders to engage them in

the overall business analysis process and to ensure that the business analyst can deliver the

outcomes needed.

REQUIREMENTS ANALYSIS

REQUIREMENTS ANALYSIS

• BABOK ® v3 chapter 7:

• The Requirements Analysis and Design Definition knowledge area describes the

tasks that business analysts perform to

• structure and organize requirements discovered during elicitation activities,

• specify and model requirements and designs,

• validate and verify information,

• identify solution options that meet business needs,

• and estimate the potential value that could be realized for each solution option.

REQUIREMENTS ANALYSIS

• This knowledge area covers the incremental and iterative activities ranging from

the initial concept and exploration of the need through the transformation of

those needs into a particular recommended solution.

SPECIFYING AND MODELING

• BABOK ® v3 Definition:

• describes a set of requirements or designs in detail using analytical techniques.

• Data Dictionary

• Data Flow Diagrams

• Process Modelling

• Prototyping

• Use Cases and Scenarios

• User Stories

SPECIFYING AND MODELING

• Data Dictionary: used to record details about the data involved in the change.

Details may include definitions, relationships with other data, origin, format, and

usage.

• Data Flow Diagrams: used to visualize data flow requirements.

• Process Modelling: used to show the steps or activities that are performed in the

organization, or that must be performed to meet the desired change.

SPECIFYING AND MODELING

• Prototyping: used to assist the stakeholders in visualizing the appearance and

capabilities of a planned solution.

• Use Cases and Scenarios: used to model the desired behavior of a solution, by

showing user interactions with the solution, to achieve a specific goal or accomplish

a particular task.

• User Stories: used to specify requirements as a brief statement about what people

do or need to do when using the solution.

DATA DICTIONARY

DATA FLOW DIAGRAMS

PROCESS MODELING

PROTOTYPING

• Storyboarding: is used to visually and textually detail the sequence of

activities by summing up different user interactions with the solution or

enterprise.

• Paper Prototyping: uses paper and pencil to draft an interface or process.

• Workflow Modelling: depicts a sequence of operations that are performed

and usually focuses solely on the human aspect.

• Simulation: is used to demonstrate solutions or components of a solution. It

may test various processes, scenarios, business rules, data, and inputs.

USE CASES AND SCENARIOS

USER STORIES

• User stories can be used:

• to capture stakeholder needs and prioritize development of solutions,

• as a basis of estimating and planning solution delivery,

• as a basis for generating user acceptance tests,

• as a metric for measuring the delivery of value,

• as a unit for tracing related requirements,

• as a basis for additional analysis, and

• as a unit of project management and reporting.

ACTIVITY

ACTIVITY REPORT BACK

• What was the value of this exercise?

• How different will your outcome be now, compared to if you

had just used the owner’s wants statement?

• What form did your group choose for documenting the

requirements? Why?

• Any other observations?

VERIFYING AND VALIDATING

• BABOK ® v3 Definition:

• Verify Requirements: ensures that a set of requirements or designs

has been developed in enough detail to be usable by a particular

stakeholder, is internally consistent, and is of high quality.

• Validate Requirements: ensures that a set of requirements or

designs delivers business value and supports the organization's

goals and objectives.

VERIFYING REQUIREMENTS

• BABOK ® v3 Chapter 7.2:

• Acceptable quality requirements exhibit many of the following characteristics:

• Atomic

• Complete

• Consistent

• Concise

• Feasible

• Unambiguous

• Testable

• Prioritized

• Understandable

VALIDATING REQUIREMENTS

• BABOK ® v3 Chapter 7.3:

• Validated requirements and designs are those that can be

demonstrated to deliver benefit to stakeholders and align with the

business goals and objectives of the change. If a requirement or design

cannot be validated, it either does not benefit the organization, does not

fall within the solution scope, or both.

DEFINING REQUIREMENTS ARCHITECTURE

• BABOK ® v3 Definition:

• structures all requirements and designs so that they support the

overall business purpose for a change and that they work

effectively as a cohesive whole.

DEFINING REQUIREMENTS ARCHITECTURE

• Business analysts use a requirements architecture to:

• understand which models are appropriate for the domain, solution scope, and

audience,

• organize requirements into structures relevant to different stakeholders,

• illustrate how requirements and models interact with and relate to each other,

and show how the parts fit together into a meaningful whole,

• ensure the requirements work together to achieve the overall objectives, and

• make trade-off decisions about requirements while considering the overall

objectives.

REQUIREMENTS APPROVAL

• BABOK ® v3 Chapter 5.5:

• Approved Requirements are requirements which are agreed to by

stakeholders and are ready for use in subsequent business analysis efforts.

SUMMARY

1. The importance of high quality requirements and requirements management

2. Methods for eliciting requirements

3. Requirements analysis

a. Specify and Model requirements

b. Verify and Validate requirements

c. Define requirements architecture

4. Requirements approval

INTRODUCTION AND PURPOSE

• Purpose: discuss the important role of BA as it relates to requirements

• How do BAs deliver value?

• Requirements Elicitation

• Requirements Analysis

• Requirements Management

QUESTIONS?

REFERENCES

• PMI, Pulse of the Profession® – 2017

https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-

the-profession-2017.pdf

• IAG Consulting, Business Analysis Benchmark – 2009

https://www.iag.biz/resource/business-analysis-benchmark-full-report/

• IAG Consulting, Assessing the Impact of Poor Requirements on Companies

https://www.iag.biz/resource/assessing-the-impact-of-poor-requirements-on-companies-quantifying-

the-cost-of-poor-requirements/

• BABOK ® v3

https://www.iiba.org/standards-and-resources/babok/

TIMOTHY ROBYTimothy.ROBY@odot.state.or.us