Requirements Management Requirements Management

The Foundation of the Business Analyst’s The Foundation of the Business Analyst’s PracticePractice

Do Formal Requirements still matter?Do Formal Requirements still matter?

• What does the Agile development world mean to Business Analysts?

• Myths concerning “Agile” and requirements management– “Working code is all that is needed” – “All we need are stories?” – “Small self organizing team can manage architecture” – “Small self organizing team can manage non functional

requirements” – “Agile processes have built-in governance”

Requirements matter now more then ever!Requirements matter now more then ever!

% of Projects that are Successful

Requirements Maturity = Strong FoundationRequirements Maturity = Strong Foundation

Without Requirements we can’t prove completionWithout Requirements we can’t prove completion

• Requirements are the contract between business customer and development/IT• Requirements are only as good as their management• Requirements management key components:

– Requirements definition– Requirements organization and process– Requirements traceability– Requirements change management– Requirement re-use

Requirements Definition Best Practices - TypesRequirements Definition Best Practices - Types

• Not all requirements are created equal• Requirements must have types and attributes• “FURPS+” is a good guide

– Functionality - What the customer wants! Note that this includes security-related needs.

– Usability - How effective is the product from the standpoint of the person who must use it? Is it aesthetically acceptable? Is the documentation accurate and complete?

– Reliability - What is the maximum acceptable system downtime? Are failures predictable? Can we demonstrate the accuracy of results? How is the system recovered?

– Performance - How fast must it be? What's the maximum response time? What's the throughput? What's the memory consumption?

– Supportability - Is it testable, extensible, serviceable, installable, and configurable? Can it be monitored?

– + - addresses design constraints, physical systems needs, interfaces, design rules

Requirements Definition AbstractionRequirements Definition Abstraction

• Four example requirements for an insurance claims processing application:– “We must be able to reduce our backlog of claims” – “The system must be able to automatically check claim forms for eligibility

issues” – “The system shall determine whether a claimant is already a registered

user, based on his/her social security number”

– “The system shall support the simultaneous processing of up to 100 claims” • Requirements have type and abstraction level

– Business needs – Features – Functional software requirements – Non-functional software requirements

What is Agile DevelopmentWhat is Agile Development

• The Manifesto for Agile Software Development– Individuals and interactions over processes and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation – Responding to change over following a plan

SCRUM – An Agile Development ProcessSCRUM – An Agile Development Process

The SCRUM RolesThe SCRUM Roles• The Product Owner represents the stakeholders, ensuring that the team

delivers value to the business. The Product Owner writes customer-centric items user stories, prioritizes them, and adds them to the product backlog

• The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.)

• Scrum Master - Scrum is facilitated by a Scrum Master who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables

• Stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefits that justify its production. They are only directly involved in the process during the sprint reviews

SCRUMSCRUM - Business Analysts as Product Owners

• Product owners are the interface between business and technology implementers.

• User Stories are Agile Requirements• (User) Story

– A feature that is added to the backlog is commonly referred to as a story and has a specific suggested structure. The structure of a story is: "As a <user type> I want to <do some action> so that <desired result>" This is done so that the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand

– Example: “As a mobile banking customer I want to take a picture of check from smart phone so I can see deposit instantly”

Are stories enough?Are stories enough?

• A story - “As a mobile banking customer I want to take picture of check from smart phone so I can see deposit instantly.”

• Stories often lead to other requirements that need to be typed and organized– “mobile check deposit” leads to architectural requirements of persistence,

storage, image support– “mobile check deposit” leads to non functional requirements such as image

throughput bandwidth, response time, security– “mobile check deposit” likely needs function requirements decomposition

for imaging components, for image quality analysis, user verification etc.

Stories DetailedStories Detailed

• Stories can be elaborated using traditional methods!

User Story

UI mock ups

Use Cases

Architecture DiagramsBPMN

Others

…..

…..

Requirements Structure in an Agile worldRequirements Structure in an Agile worldP

ortf

olio

Level Requirements Backlog Owner Requirement Types

Portfolio ManagerThemes

Business Vision

Pro

gram

Program Manager Architectural Requirements

Features

Pro

ject

Product OwnersStories

Spikes

Release Manager

Scrum Master

Agile Team Members

1

*

1

*

Epics

Traceability

Requirements Organizational ConstructsRequirements Organizational Constructs

• Hierarchy• Modules• Links• Baselines

UREQ1UREQ2UREQ3UREQ4UREQ5UREQ6UREQ7UREQ8UREQ9UREQ10

User Requirements

SREQ1SREQ2SREQ3SREQ4SREQ5SREQ6SREQ7SREQ8SREQ9

SREQ10

Systems Requirements

TREQ1TREQ2TREQ3TREQ4TREQ5TREQ6TREQ7TREQ8TREQ9

TREQ10

Test Requirements

Version 2.0

Requirements Definition Best Practices - TraceabilityRequirements Definition Best Practices - Traceability

• Traceability is a dependency relationship between artifacts.• It is a methodical approach to managing process and relationship between artifacts• Wikipedia:

– Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction

– Requirements traceability refers to the ability to define, capture and follow the traces left by requirements on other elements of the software development environment and the trace left by those elements on requirements

Why Traceability is important?Why Traceability is important?

• Determine the origin of any requirement • Ensure quality

– You can verify that the software fulfills all requirements – You can verify that the software does only what was requested

• Help with requirement change management • Analyze impact of a change to a requirement. For example, if a

feature is modified, traceability enables you to determine: – Which use cases need to be modified – Which supplementary requirements are affected

• Auditiblity/Regulatory certification (DO178B, Sarbanes-Oxley…)• “Every line of code should be directly traceable to a requirement, no

extraneous code outside of this process should be included in the build” – DO178B

Simple link vs. TraceabilitySimple link vs. Traceability

Simple link e.g. hyperlink • Unbounded, and unstructured• Implicit semantics• Unidirectional• Ad-hoc

Traceability• Bounded• Explicit well defined semantics• Bi-directional• Often process governed

Traceability Anti-patternTraceability Anti-pattern

- Requirements in MS Word Documents

- Tests in Excel- Link by a common ID

Requirements – Standard ModelsRequirements – Standard Models

• Common Model

• More detailed requirement model

QualifiesRequirement

Implements

Change Request

Test Case

Manages

Effects

Use CaseSystem Requirement

User Requirement

Satisfies

Defines

Requirements – Sanitize, Clarify and ConsolidateRequirements – Sanitize, Clarify and Consolidate

• Usage: to collate together requirements (possibly from several sources) into an agreed specification.

• Link Type: “Satisifies".• When Appropriate

– When there is a need to clarify and standardize terminology.– When there is a need to reconcile conflicting requirements from different sources.

Information Source 2

Collection or Module

Satisfies

Information Source 1

Information Source 3Asdf lksad lk as;lSdfaasdfDsfdasdfasdfAsdasdfasdfasdFasdfasdfasdfa dsfjsadajs flkasdj f;asdaskd jf;laj aw;ief a;lsdjf ;lajf ;alsjf ;alsfa;lsjf lksajf ;lsa ;ahgawoie a;sdhgaasdga adsfasdfwefawgfasdvasg ; aksd lkja flksadf lkajsflkasjf sajf ladsjfla fiwa elkvsz dj asd jfjfs d asdjf asdfjdsf ajf lkwaj lfwalkef jajf ajflksadjf ajf lksajf alskdjf alksdjf aflksaf ksafdj alskdfj alsdfj alsjf lasjf lksajf alksjf alks jf ds jfalf alsjfa sf safd

Satisfies

Satisfies

User Requirement

User Requirement

User Requirement

User Requirement

Requirements – DependencyRequirements – Dependency

• Usage: when requirements are dependent on other requirements being satisfied. Structure is

• Link Type: "depends on".

Depends

System Requirement 1

System Requirement 2

User Requirement 1Satisifies

User Requirement 2Satisifies

Requirements – Test Case CoverageRequirements – Test Case Coverage

• Usage: Show that specific tests are to be carried out proving application meets requirement.

• Link type: “Qualifies” (or “Verify”)

QualifiesRequirement

Implements

Change Request

Test Case

Manages

Effects

Requirements – Architecture as a constraintRequirements – Architecture as a constraint

• Usage: when architecture is predetermined, rather than derived from the requirements.

• Link type: “Constrains”

Satisifies

Architecture

User Requirement

Satisifies

Constrains

Constrains

System Requirement

Sub-System Requirement

Traceability – Impact AnalysisTraceability – Impact Analysis

Traceability and ChangeTraceability and Change

Lifecycle ToolRequirementsManagement

User Requirements

System Requirements

Test Cases

Change in User

Requirements

Lifecycle ToolQualityManagement

The Consequences of ChangeThe Consequences of Change

Lifecycle ToolRequirementsManagement

User Requirements

System Requirements

Test Cases

Lifecycle ToolQualityManagement

Change in User

Requirements

Artifacts become suspect

Test Cases

Lifecycle ToolQualityManagement

Lifecycle ToolRequirementsManagement

User Requirements

System Requirements

Artifacts become suspect

Cross toolsuspect artifacts

Change in User

Requirements

Change in System

Requirements

The Consequences of ChangeThe Consequences of Change

Requirements Change Management Best PracticeRequirements Change Management Best Practice

• Requirements can be managed like any other form of work item (task)– Managed with a lifecycle– Assigned, reviewed, approved by appropriate roles based

stakeholders– Important in high compliance or governed environments (audit

history)– A mechanism to document impact analysis exercise

Requirement Re-use Best PracticesRequirement Re-use Best Practices

CREQ1CREQ2CREQ3CREQ4CREQ5CREQ6

CoreApplication

Requirements

MREQ1MREQ2CREQ1MREQ3CREQ2CREQ4MREQ4MREQ5CREQ5CREQ6

Mobile Application

RequirementsTREQ1CREQ1TREQ2TREQ3CREQ3TREQ4TREQ5TREQ6CREQ5CREQ6

Call CenterApplication

Requirements

• Module can embed requirements from others

• Requirements can extended or specialized

Summary - Applications are only as good as Summary - Applications are only as good as their Requirementstheir Requirements• Requirements are the contract between business customer and development/IT• Requirements are only as good as their management• Requirements management key components:

– Requirements definition– Requirements organization and process– Requirements traceability– Requirements change management– Requirement re-use

BibliographyBibliography

• Writing good requirements is a lot like writing good code Jim Heumann, IBM, Software Group, 14 Jul 2004

• IIBA BABOK Guide V2.0, 2009• Six Things Your CIO Needs to Know About Requirements Maturity, IAG Consulting,

2012• Agile Software Requirements, Dean Leffingwell, 2011• The Benefits of Well Managed Traceability, Ed Genrty, Innovate 2012