The Requirements Process Workshop Presentation

The Requirements Process

PMI Tools & Techniques Forum

Ivars K. Lenss, PMP

Ivars K. Lenss, PMP

Tools & Techniques Forum

January 14, 2009 [email protected]

Agenda

Introductions

Definition of Requirements

Requirements Planning

Requirements Elicitation

Process Modeling

Q&A

Ivars K. Lenss, PMP



What Is a Requirement?

(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)

Source: IEEE Std 610.12-1990

Ivars K. Lenss, PMP



How Requirements Work

Requirements are not solutions

Design translates requirements into solutions

Many stakeholders mix requirements with their

proposed solutions

Requirements gathering is discovering the

essence of the system

Essence is the business reason of the work -

what the work would be if there was no project

Ivars K. Lenss, PMP



Benefits of Good Requirements

Common understanding

Collaborative relationships

Commitment of team members

Products support stakeholder needs

Ivars K. Lenss, PMP



Correcting Requirement Defects

Stage of Discovery Relative Cost to Correct

Requirements development 1X

Design 2-3X

Construction 5-10X

System or acceptance test 8-20X

Operation 68-110X

Source: Wiegers More About software requirements

Ivars K. Lenss, PMP



Cost of Requirements Defects

Requirements defects contribute to

one third of total delivered defects

Fixing requirements errors consumes

70-80% of project rework costs

Requirements defects consume 28-42%

of total software development costs

Source: Wiegers Software Requirements

Ivars K. Lenss, PMP



Requirement Sources

Business Implementation

Stakeholder Maintainability

User Regulatory

Quality of Service Legal

Performance Safety

Security Request for Proposal

External Systems Derived

Ivars K. Lenss, PMP



Raw Requirements

Higher-level statements of the business goals, objectives, and success factors

Often expressed in initiating documents

Often vague and subjectively interpreted

Can be intermingled with ideas and suggestions for potential designs

A raw requirement is an environmental or customer requirement that has not been analyzed and formulated as a well-formed requirement. (IEEE Std 1233, 1998 Edition)

Ivars K. Lenss, PMP



Example

Requirement: “The traffic monitor running in the background shall provide status messages at regular intervals not less than every minute.”

What are the status messages?

How are they provided to the user?

If displayed, how long are they displayed?

What is the acceptable timing interval?

Ivars K. Lenss, PMP



Business Events

A system responds to things that happen

externally – these are business events

Each event has a preplanned response –

This response is a business use case

A requirement associates a business event

with a business use case

Ivars K. Lenss, PMP



Well-Formed Requirements

Abstract: Independent of its implementation

Unambiguous: Interpreted in only one way

Traceable: Associated with source

Validateable: Fit criteria

A well-formed requirement is a statement of system functionality (a capability) that can be validated, and that must be possessed by a system to solve a customer objective, and is qualified by measurable conditions and bounded by constraints. (IEEE Std 1233, 1998 Edition)

Ivars K. Lenss, PMP



Example

The traffic monitor shall display status

messages in a designated area of the user

interface

The messages shall be updated every 60

seconds, plus or minus five seconds

Messages shall remain visible continuously

Raw Requirement: “The traffic monitor running in the

background shall provide status messages at

regular intervals not less than every minute.”

Ivars K. Lenss, PMP



Requirements Classification

Functional Requirements

- Things the product must do

- Action verbs – calculate, produce, inspect, publish

Nonfunctional Requirements

- Qualities the product must have

- Look and feel, performance, security, regulatory

Constraints

- Boundaries and limits on the solution.

- Glossary and naming conventions

- Training, knowledge transfer

Ivars K. Lenss, PMP



Examples

Functional

The rail system shall move people from San Francisco to Los Angeles

Nonfunctional

The rail system shall operate at an optimal cruise speed of 100 miles per hour

Constraint

The rail system shall operate at a maximum speed of 130 miles per hour

Requirement Attributes

• Assigned to each well-formed requirement

For example:

<identification> = 4.3.2

<priority> = high

<criticality> = low

<feasibility> = high

<risk> = medium

<source> = customer

<class> = nonfunctional

<type> = performance

Requirements Planning


January 14, 2009

Ivars K. Lenss, PMP



Requirements Planning Identify stakeholders and key project team members

Identify and communicate key roles/responsibilities to people involved in requirements gathering

[R]esponsible (does the work)

[A]ccountable (the decision maker-only one person)

[C]onsulted (consulted prior to the work, provides input)

[I]nformed (on a need to know basis)

Identify project assumptions

Determine tools and techniques to gather and communicate requirements

Ivars K. Lenss, PMP



Planning Considerations

Number of stakeholders

Locations of stakeholders

Sources of domain knowledge

Organizational culture

Documentation requirements

Ivars K. Lenss, PMP



Obstacles

Multiple, conflicting needs from stakeholders

Stakeholder availability

Stakeholder knowledge

Lack of involvement of the right people

Delivery dates mandated without prioritized

requirements

Scope creep

Analysis paralysis

Ivars K. Lenss, PMP



Requirements Life Cycle

REQUIREMENTS

Process

Modeling

Target

Environment

Stakeholder

Goals, Needs,

and Objectives

Requirements

DefinitionMODELS

Product

Design

REQUIR

EM

ENTS

SPECIF

ICATIO

N

MO

DE

LS

DESIG

N

FEEDBACK

Product

BuildDESIGN

SPECIFICATION

Product

Release

PRODUCT

RELEASE

FEEDBACK

PRODUCT

BUILD

FEEDBACK

Source: Robertson & Robertson, Mastering the Requirements Process



January 14, 2009

Ivars K. Lenss, PMP




Used to build analytical models

Exposes missing, incomplete, or incorrect

requirements

Determines if additional iterations required

Ivars K. Lenss, PMP



REQUIREMENTS

INTERVIEWS

REQUIREMENTS

WORKSHOPS

BRAINSTORMING/

FOCUS GROUPS

PROTOTYPING

DOCUMENT

ANALYSIS

INTERFACE

ANALYSIS

REVERSE

ENGINEERING

OBSERVATION/

SHADOWING

SURVEY/

QUESTIONNAIRE

Ivars K. Lenss, PMP



Interviews

Solicit stakeholder involvement, authority, impact

Most common elicitation technique

Structured interview, pre-defined questions

Unstructured interview, no pre-defined questions

Encourages participation and establishes rapport

with the stakeholder

Results subject to interviewer’s interpretation

Not a means of reaching consensus

Ivars K. Lenss, PMP



Requirements Workshops

Structured way to capture requirements (scope,

define, discover, prioritize, and reach closure)

Also referred to as JAD, Joint Application Design

Effective way to elicit requirements quickly

Feedback is immediate

Stakeholders availability affects scheduling

Too many participants can slow down the process

Too few participants can overlook requirements

Ivars K. Lenss, PMP



Brainstorming/Focus Group

Focuses on a topic or problem area

Share new ideas without criticism or evaluation

Create a condensed list of ideas

Homogeneous—individuals with similar characteristics Differing perspectives might not be shared

Heterogeneous—individuals with diverse backgrounds Individuals may self-censor if not comfortable with others’

background

Ivars K. Lenss, PMP



Survey / Questionnaire

Quick and relatively inexpensive

Does not usually require significant time

Efficient when stakeholders are not co-located

Closed-ended questions:

Used when issues are known, responses are not

Effective in obtaining quantitative data

Open-ended questions:

Effective in obtaining insights and opinions

Difficult to quantify and summarize

Ivars K. Lenss, PMP



Prototyping

Creates “mock ups” of screen or report layouts

Lets stakeholders “see” the system’s interface

Horizontal prototype Models a shallow and wide view of the system (breadth)

Vertical prototype Models a deep and narrow view of the system (depth)

Can take considerable time

Can get bogged down by the “hows” rather than “whats”

May lead to unrealistic expectations of performance,

reliability, usability

Ivars K. Lenss, PMP



Document Analysis

Used to gather details of the “As Is” environment

Leverage existing materials to discover and/or confirm

requirements

Applied 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

Documentation may not be up-to-date

Can be tedious and time-consuming

Ivars K. Lenss, PMP



Interface Analysis

Used to identify shared interface requirements

Interfaces types include: User interfaces

System-to-system interfaces

Interfaces to and from external hardware devices

Reveals inputs, outputs, functionality

Important to look across all interfaces

Promotes successful interoperability

Does not reveal business processes

Ivars K. Lenss, PMP



Observation / Shadowing

Study people performing their jobs

Assess an SME’s work environment

Sometimes called "job shadowing” or “following

people around”

Documents details about a current process

Could be time-consuming

May be disruptive

Ivars K. Lenss, PMP



Reverse Engineering

Existing system has little or outdated documentation

Helps in understanding what a system actually does

Black Box: Studied without examining its internal structure

White Box: Inner workings of the system/product are studied

Expensive and time-consuming

Can be restricted by copyright laws

Existing tools have limited capabilities and require training to use

Requirements Modeling


January 14, 2009

Ivars K. Lenss, PMP



Analytical Models

Express different views of requirements

Provide perspectives and focus

Achieve specific levels of detail

Facilitate communication

Models can be text, diagrams, or both

Behavior models (processes, tasks, sequences)

Structural models (parts and relationships)

Dynamic models (how things change over time)

Control models (decisions and policies)

Ivars K. Lenss, PMP



Model Views

Control Models (guidelines, standards)

Business Policies

Business Rules

Structural Models (parts and relationships)

Domain Models

Glossary

Dynamic Models (changes over time)

Event Table

Ivars K. Lenss, PMP



Model Views

Behavioral Models (processes, tasks, sequences)

Relationship Map

Context Diagram

Stakeholder Classes

Actor Map

Actor Table

Prototype

Process Map

Use Cases

Scenarios

Ivars K. Lenss, PMP



Writing Requirements

Written for stakeholders

Written for designers

Written using business language

Associated with a fit criterion

Designers can build what the client wants

Ivars K. Lenss, PMP



Establishing Metrics

Project Metrics – measurements

associated with the project

Cost, effort, schedule, risk, resources, etc.

Product Metrics – measurements

associated with the product

Defects, performance, size, etc.

Ivars K. Lenss, PMP



1. Wiegers, Karl E., Software Requirements , 2nd ed., Microsoft Press, 2003

2. Wiegers Karl, E., More about Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, 2006

3. Robertson & Robertson, Mastering the Requirements Process, 2nd ed., Addison-Wesley, 2006

4. Sward, Measuring the Business Value of Information Technology, Intel Press, 2006

5. Bridgeland, Zahavi, Business Modeling, A Practical Guide to Realizing Business Value, Morgan Kaufman, 2009

6. IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Specifications

Further Reading

The Requirements Process Workshop Presentation

Documents

Transcript of The Requirements Process Workshop Presentation