Bulletproof Requirements for Offshore Projectsbaconvention.com/wp-content/uploads/2014/12/5...© 2014 BA Convention 2 Why Bulletproof Requirements are Imperative for Project Success

© 2014 BA Convention

Bulletproof Requirements for

Offshore Projects

Ashu Potnis

Content & images are Copyright TechnoSolutions Corp. © 2008-2014

© 2014 BA Convention 2

Why Bulletproof Requirements are Imperative for Project Success

A Quick Look at the Fundamentals

© 2014 TechnoSolutions Corp. 3

Click to edit Master text styles

Click to edit header

PROJECT

Requirements / Needs

Resources Time

Fundamental Factors of Project Management




Requirements - Foundation of Systems

Requirements are the very foundation of products, systems & applications




Cost of fixing Requirements Errors

Source: Boehm, Barry W., Software Engineering Economics : Study of 63 projects

from IBM, TRW, GTE etc.

Relative Cost for fixing Requirements Errors and

Omissions at different stages of the Project Lifecycle

200x




Discovery of Defects in the Project Lifecycle

Project Lifecycle

Rate

of

Dis

co

ve

ry o

f D

efe

cts

Requirements Design &

Build Release to Test

Release to Field

Common

Ideal




Requirements Analysis

Faithfully “communicate” user needs to all stakeholders

Needs

Business Analyst User




Who are these stakeholders?

Requirements

Business Users

Project Managers

Product Managers

Developers System

Architects

Quality Assurance

Peer Business Analysts


Examining the unique requirements challenges in offshore projects

Peculiar Requirements Challenges

in Offshore Projects




Time Zone Difference

Problem? You can’t just ask questions or clarifications as and when you come across them




Language and Accent




Cultural Differences




Resource Mobility

• Employee Churn • Mobility of Resources

among Projects

Business Analyst Project Manager

Old Business Analyst

New Business Analyst




Challenges are compounded in Offshore Projects

Different Time Zones

Language and Accent

Cultural Differences

Resource Mobility / Non-Permanence


Let’s Address the Problem




Typical Requirements Document


Organizing Requirements to be easily understood

1. Structure Requirements for easy

consumption by all Stakeholders




Methods of Expressing Requirements

Requirements

Models &

Visual Requirements

Textual Requirements

Requirements

Documents can become

very large and difficult to

understand!




Requirements should be like an Onion!




…you peel it to get into the details!

Context Diagram

Use Case Diagram / Business Process Diagrams

Use Case Scenario

Use Story

Business Rules

Non-Functional Requirements




Structure Requirements in Layers

Context Diagram(s)




Context Diagrams




Structure Requirements in Layers

Context Diagram(s)

Business Process / Use

Case Diagrams




Business Process Diagrams




Use Case Diagrams




Requirements in Layers

Context Diagram(s)


Case Diagrams

Use Cases / User Stories




Use Case Scenarios




Activity Diagram for Scenario




User Story




Requirements in Layers

Context Diagram(s)


Case Diagrams

Use Cases / User Stories

Functional / Non-

Functional / Business

Rules




Detailed Textual Requirements

Textual Requirements

Functional Non-

Functional Business

Rules

Now that we have structured

requirements for easy consumption…

…how do we ensure that the Requirements truly

reflect user expectations?

I didn’t ask for that!

Communication Gap results in costly rework!

Application Delivered


Are we Building the Right Thing?

2. Requirements Validation




Goal of Requirements Process

The main goal of the Requirements process is to establish a common understanding of the problem and its proposed solution among all

stakeholders

Requirements

Business Users

Business Analysts

Project Managers

Product Managers

Developers

System Architects

Quality Assurance




Requirements Visualization

From this…

…to this

Promote a common understanding of the

needs and the proposed solution




Screen Mockups




Conduct Application Walkthrough / Simulation

Visual Prototypes close the

communication gap




Visual Requirements Promote Understanding

Be more Visual (Diagrams)

“Show – not tell” (Application Prototypes)

Engage Users in reviews early in Project


Important Sections of the Requirements Document

3.Factors that Impact the Project

Outcome but are Often Ignored




Assumptions

Assumptions are factors that are

believed to be true. Assumptions

may affect all aspects of the project

and pose a certain degree of risk if

they do not prove to be true.

Document assumptions to ensure that the “unsaid” things are formally documented.




Business Rules

Extract Business Rules and

maintain and independent catalog

of Business Rules.

Business Rules are very important for QA and are generally used across the system




Out-of-Scope

• Everyone documents what should

be done

• Equally important to identify

Requirements that are out of

scope. i.e. What won’t be done




Prioritize Requirements - MoSCoW

• Must be delivered

• Should be delivered

• Could be delivered

• Won’t be delivered

We always fall short of time, having prioritization helps put important things ahead of others.




Often Ignored Factors

Assumptions

Business Rules

Out-of-Scope

Requirements Prioritization




Summary

1. Structure Requirements for easy consumption by all Stakeholders

2. Validate Requirements

3.ConsiderOften Ignored Factors




Question & Answer Session

© 2014 BA Convention

Learn more. www.baconvention.com

Thank You!