InFlux™ Requirements Engineering

(RE) Methodology
SETLabs

1
De 201 / De Bridge (OOAD) - Framework

1-2

2
 Objectives
• Provide a high level view of InFlux RE methodology, its lifecycle stages and
activities
• Learn the concepts of Requirements Elicitation
– Hierarchy of requirements
• Learn the concepts of Requirements Analysis
• Learn the concepts of Requirements Specification
– Visual modeling of requirements
• Learn the concepts of Requirements Validation

1-3

In order to convey the key concepts in this course, I will walk you through a set of
slides that are supported by detailed course documentation available to you as a
handout.

3
 InFlux Methodology Vision

To bring in formalism and repeatability into the process of

translation of business objectives into IT solutions through
a collection of models, techniques and tools

1-4

To start with, let me introduce InFlux to you. InFlux is a set of proven methodologies
supported by toolsets developed by SETLabs to achieve Business-IT alignment.
This slide shows the vision of InFlux.

Let me quickly touch upon why we chose Requirements Engg as one of our focus
areas in InFlux

4
 Requirements Engineering – Essential to
Success of a Project
A Standish Group survey “Chaos Chronicles” (2003) pointed out that more
than 66% of the software projects delivered were challenged or were a failure
due to the lack of a robust requirements process
A fall 2004 Forrester survey of 692 technology influencers — those who hold
the IT purse strings — indicated that nearly one-third are dissatisfied with the
time it takes their development shops to deliver custom applications, and the
same proportion is disappointed by the quality of the apps that are ultimately
delivered. One-fifth of respondents are unhappy on both counts.

Impact of Requirements Phase to project success based on Infosys experience

• Average of 1.5 hrs of rework effort is spent on fixing a defect (considering all lifecycle
stages)
• Average of 7-8 hrs of rework effort is spent on fixing Requirements defects
• Average of 5hrs of rework effort is spent on fixing performance defects (attributable to lack
of understanding of Non-functional requirements)
• 15% (Requirements + Performance) of all defects contributes to 50% of rework effort

1-5

Lets look at some practical facts of life related to RE in software development

Standish Group reports on software project success are legion. Their survey result
published in 2003, talked about project failures due to lack of requirements process.
This fact had hardly faded from our memory when another survey result hit the
industry.

This time, well known research firm Forrester reported the following :
– this itself shows that only 14% of business respondents are really satisfied with
their software development

Coming to our very own backyard, very recently, it was identified that 50% of our
project rework is attributable to defects arising out of functional and non-functional
requirements

These startling facts demand an answer to the question – What’s causing these
defects or failures?

5
 Requirements Engineering – Essential to
Success of a Project
Key issues affecting Productivity during Analysis/Design

30% 28%
22% 22%
20%
15% 14%

10%

0%
LBK LAK ABR LEX LTC
LBK – Lack of Biz knowledge; LAK – Lack of Application knowledge; ABR – Ambiguous requirements; LEX – Lack of Experience; LTC – Lack of
Technical skills

Source : Infosys Data

Typical Requirement Errors

Inconsistency
Ambiguity [5%] [13%]
Omission [31%] Incorrect Facts [49%]
Misplaced Req [2%]

Source : Industry Data

1-6

A recent Infosys level survey has demonstrated that Lack of Business Knowledge is
the most commonly accepted issue for lack of productivity in initial phases of a
software project

Further insights are available from industry research data that points towards types
of requirements errors.

Given this state of the practice in the industry it is imperative that Requirements
Engineering as a subject is not left alone to its own fate.

To address the concerns apparent from this data, we have packaged best practices
in a robust RE methodology and toolset

6
 InFlux RE Methodology – Scope

Requirements
Engineering

contains contains

Requirements Links Requirements

Development Management

Caters To Caters To

Requirements Design Code Implement

Software Development Lifecycle

1-7

Let us now look at the scope of the InFlux RE methodology. In fact the scope of
InFlux methodology covers all areas of RE as commonly accepted by the industry.

At the risk of repeating, requirements engineering scope is subdivided into RD and

RM. RD is concerned with activities taking place during the Requirements phase of
a software development lifecycle while RM is concerned with managing
Requirements as an artefact till the final implementation of an IT solution

7
 InFlux RE Methodology – Scope for this Training

Requirements
Engineering

contains contains

Requirements Links Requirements

Development Management

Caters To Caters To

Requirements Design Code Implement

Software Development Lifecycle

1-8

As part of this course, I will focus mainly on the Requirements Development scope
under RE

8
 Requirements Development – Things to Ponder
• What is the essential purpose of an IT solution?

• Are there different levels of requirements - business requirement,

system requirement?

• How can I get business and IT teams to speak the same language?!!

• How good is a verbose requirements document that describes all

requirements in unstructured text?

• When will I know that I have actually completed the requirements?

1-9

Before we jump into the methodology details, let us take a step back and explore
the need for a well defined phase and techniques for developing requirements. A
few of the key questions facing requirements analysts are -

9
 Requirements Development – Understanding the
Complexity

COLLECTING INFORMATION?

STAKEHOLDERS? DOCUMENTING INFORMATION?

Complexity

GETTING CONSENSUS?
SCOPE?

HANDING OVER? MISSING PIECES?

ORDER OF PREFERENCE?
1 - 10

Activities performed in Requirements Development have to manage a high degree

of complexity upfront as they are responsible for deciding the course of action for
the entire project.

Take a look at some of the factors causing complexity in Requirements

Development itself –

Scope – The project scope definition is part of RD and is as complex to get a handle
on as it can get!

10
 Requirements Development – Bringing in a
methodology
Typical Requirements Development Activities

Requirements Requirements Requirements Requirements

Elicitation Analysis Specification Validation

+Whose needs have to be satisfied?

+ What needs have to be satisfied?
+How should needs be gathered?

1 - 11

To Handle this complexity, let us explore

the industry standard activities in
Requirements Development

RE – This activity is concerned with

11
Requirements Development – Bringing in a
methodology
Typical Requirements Development Activities

Requirements Requirements Requirements Requirements

Elicitation Analysis Specification Validation

+Are requirements of good quality?

+Are requirements non-conflicting?
+Are requirements prioritized?

1 - 12

12
Requirements Development – Bringing in a
methodology
Typical Requirements Development Activities

Requirements Requirements Requirements Requirements

Elicitation Analysis Specification Validation

+Are requirements well documented?

+Are requirements easy to understand by all stakeholders?
+Are requirements documents easy to maintain?

1 - 13

13
Requirements Development – Bringing in a
methodology
Typical Requirements Development Activities

Requirements Requirements Requirements Requirements

Elicitation Analysis Specification Validation

+Are requirements reviewed and finalized by stakeholders?

+Are requirements ready for handover to IT development team?
+How will requirements be validated after implementation?

1 - 14

14
 InFlux Requirements Development Viewpoint :
Approach to execute activities - Iterative
Typical Requirements Development Activities

Requirements Requirements Requirements Requirements

Elicitation Analysis Specification Validation

NN
ATIO
ITER
% of Requirements Complete

…..
N2
ATIO
ITER

1
TION
ITERA

Requirements Development Activities

1 - 15

A key Question that comes to mind is how are these activities carried out in a
project – Two simple choices are

1. They can be done sequentially

2. They can be done iteratively

Based on experience, specially in medium to big sized projects, InFlux methodology

supports an iterative development of requirements through series of iterations
across the four activities. This is because the four activities are tightly coupled
with each other and the initial activity of elicitation by itself does not always
produce a valid document. The picture on the slide demonstrates this concept. It
is important to understand that each iteration may have dependencies on the
other and they may not proceed as synchronously as it seems in the picture.
However, executing a requirements phase of a large project in a purely
sequential way increases the risk of disaster

15
 Requirements Development – Methodology Details

Requirements Requirements Requirements Requirements

Elicitation Analysis Specification Validation

1 - 16

Given this overview of the activities in Requirements Development, let us now do a

deep dive into each of these activities

16
 Requirements Elicitation & Specification :
STARTING POINT

+Whose needs have STAKEHOLDERS

to be satisfied? ™ Project Sponsors
+What needs have
to be satisfied?

OUTPUT
™ Project Needs Document (Template)
+How should needs METHODS
be gathered? ™ “Needs” Workshop
™ Sponsor Interview
+How should needs
be documented? ACTIVITY AIDS
™ Guidelines for Facilitated Workshops
™ Interview Checklist
™ Guidelines to effective Notes Taking
™ High Level Business Need (HLBN) Review Checklist

1 - 17

Let us start with Requirements Elicitation and understand the practices required for comprehensive elicitation of
requirements.

To start on Requirements Elicitation, one needs to identify ‘whose needs have to be satisfied’ or in other words the
stakeholders of the final IT solution. The first set of stakeholders are the people responsible for initiating the project.
They are called the project sponsors.
This brings us to the next point – what needs can I gather from these stakeholders – The project sponsors would typically
provide high level needs that can be from business perspective, technology perspective or regulatory perspective. These
needs are the drivers of the project and logically determine the success criteria of the project.

If these high level needs are not articulated or understood properly, it can lead to great difficulty in gathering or
understanding requirements from further set of stakeholders

Once the stakeholders and type of requirements to be elicited from them is determined, a method to obtain the information
needs to be determined. InFlux methodology prescribes two methods –

1. A “Needs” workshop and

2. Sponsor Interview

In order to effectively use these methods, you can refer to the course material handout that gives
1. Guidelines on facilitated workshops
2. Interview Checklist

Also Guidelines are available on how to take down this information in the form of notes which need to be later converted into
a formal document. The template called Project Needs document for the final document is provided.
After the first draft of documentation is done, the HLBN review checklist needs to be referred to for finding out any missing
information and further workshops/interviews can be conducted to fill the gaps
In some cases, a project needs document may be already available – The review checklist can be applied on this directly.

17
 Requirements Elicitation & Specification :
Project Needs

+Whose needs have STAKEHOLDERS

to be satisfied? ™ Program/Project Management
+What needs have
to be satisfied?

OUTPUT

+How should needs ™ Project Scope Document (Template)

be gathered? ™ Requirements Elicitation Plan (Template)
METHODS
+How should needs ™ Multiple Techniques
be documented? ACTIVITY AIDS
™ Scope Definition Guidelines
™ Guidelines to Identify Types of Requirements
™ Guidelines to Select Requirements Elicitation Techniques
™ Logistics Planning Checklist

1 - 18

Moving on in the journey of elicitation, once the high level needs are captured, its time for the
Program/Project Management team to provide more inputs.

The requirements artifact that now needs to be created is definition of the project scope. A project
scope needs to be defined from multiple perspectives – Some of them are:
1. Identify Stakeholders or organizational units in scope who are impacted or who will provide
specific requirements
2. Identify business landscape that the project influences or gets influenced by
3. Identify application portfolio areas that the project influences or gets influenced by
4. Identify technical constraints which set the boundaries
5. Identify legal constraints that define the boundaries

Based on the project scope, the project management team needs to develop a plan for gathering
further requirements. In order to do that, the following needs to be done

1.Identify all types of requirements that can be gathered from business/system perspective
2. Identify the list of all stakeholders for all levels of requirements details (inputs, document, review,
validate)
3. Identify the eliciation method for different levels of stakeholders and a logistical plan to carry our
rest of the requirements elicitation process

18
 Requirements Elicitation & Specification :
Project Scope
Requirements Elicitation Plan

+Whose needs have STAKEHOLDERS

to be satisfied? ™ Business Managers, Business Users, Business Analysts, IT Analysts
+What needs have
to be satisfied?

OUTPUT
™ As-Is/To-Be Business Models
+How should needs ™ Issues and Recommendations Details (Template)
be gathered?
™ To-Be Business Requirements List (Template)
+How should needs
METHODS
™ Facilitated Workshops, Interviews, Notes Taking
be documented?
™ Business Modeling, Business Analysis, Use-case Modeling
ACTIVITY AIDS
™ Guidelines for Facilitated Workshops, Interview Checklist, Guidelines
to effective Notes Taking
™ Guidelines to consolidate Requirements

1 - 19

Once the elicitation plan is executed, the detailed requirements need to be gathered from business
perspective. The stakeholders that provide or influence business requirements are BMs, Business
Users, Business Analysts, IT Analysts.

To understand business requirements in a structured way, it is important to understand the As-Is as

well as the To-Be.

As-is denotes the current behaviour of the business in terms of the flow of information and flow of
activities. As –is helps in…

Understanding of As-Is allows us to move systematically from the problem space to the solution
space. Business Analysis in terms of Issues and Recommendations help understand the exact areas
of change and solution ideas.

The To-Be business behaviour represents the solution from the business perspective…

Let us now look at the various methods to describe the business behavior and perform business
analysis.

Now that we have seen the methods of business modelling and business analysis, we need to
understand the ways of documenting this information. During the elicitation workshop or interview
sessions , this information may be gathered through notes or may be directly modeled into diagrams
discussed. Please refer to the Guidelines on taking notes and guidelines on consolidating information
provided with the course material handout.

19
 Requirements Elicitation & Specification :
Business Requirements

+Whose needs have STAKEHOLDERS

to be satisfied? ™ Business Managers, Business Users, Business Analysts, IT Analysts
+What needs have
to be satisfied?

OUTPUT
™ System Requirements List (Template)
™ Use case elaboration (Template), NFR (Template)
+How should needs METHODS
be gathered? ™ Facilitated Workshops, Interviews, Notes Taking
™ Task-flow Modeling, Wireframe Modeling , NFR Modeling
+How should needs ACTIVITY AIDS
be documented? ™ Guidelines for Facilitated Workshops, Interview Checklist, Guidelines
to effective Notes Taking
™ Guidelines to consolidate Requirements

1 - 20

Understanding of the To-Be business behaviour leads us to capture further

requirements from a system perspective. System functionality identified through the
method of use-case identification, is further elaborated by capturing information to
create a Taskflow Model. Also non-functional requirements corresponding to the
system behaviour are elicited. Information that helps define the user interface in the
form of Wireframe models is also captured at this stage.

Let us now go into the methods of Taskflow modeling, Non-functional requirements

modeling and Wireframe modeling.

The completion of the system requirements elcititation practically completes

gathering of all types of requirements. These requirements are now ready for
analysis, specification and validation.

20
 InFlux Requirements Development Viewpoint –
Hierarchical
Key Goals and Objectives
Drivers
Regulatory
Business Needs Technical Needs
Needs

Internal/ High Level

Application Technical Legal
SCOPE External Business
Portfolio Constraints Constraints
Stakeholders Landscape

PLAN Type of Requirements Elicitation Techniques Logistics

Application
Business Business Issues &
Functionality
Business Collaboration Workflow Recommendations
Catalog
Reqmts

As-Is Business Behavior Business Analysis To-Be Business Behavior

System
System Taskflow, Non-Functional Wireframe Model Data Model,
Reqmts Business Requirements (UI Screen) Dictionary
Rules

Hierarchical View of Requirements

1 - 21

Before moving to Requirements Analysis activity, let me summarize the key

approach in eliciting requirements. The figure on the slide depicts the hierarchical
view of requirements development that I have walked you through till now.

In different project scenarios, the hierachical view may not be easy to follow based
on availability of stakeholders and the sequence of information available with the
stakeholders. In such a case, the different pieces of requirements should be
captured and sticthed together in a progressive manner as the requirements phase
proceeds.

21
 Requirements Analysis :

+Are Requirements OUTPUT

of Good Quality? ™ Agreed and Prioritized Requirements List (Template)

+Are Requirements METHODS

Non-conflicting? ™ Requirements Negotiation Workshops
™ Requirements Prioritization Technique
ACTIVITY AIDS
™ Checklist for Good Requirements
™ Guidelines to identify requirements conflicts and dependencies
+Are Requirements ™ Guidelines on Addressing Conflicts
prioritized?
™ Guidelines for Requirements Prioritization

1 - 22

Let us now look at the Requirements analysis activity in detail.

Requirements Analysis is key to ensure that we have ‘clean’ and ‘good’ requirements that can be put
into a formal specification document. This activity’s effort is usually inversely proportion to the care
taken during requirements elicitation.

Requirements captured in the form of notes or lists during requirements elicitation need to be run
through a quick assessment against the ‘goodness’ factors. Please refer to the handout for a
checklist of goodness factors for analysis.

After this analysis of the requirements, it is imperative to identify and resolve any conflicting
requirements. Please refer to the course material handouts for guidelines on identifying and
addressing requirements conflicts and dependencies.

As part of the requirements elicitation exercise, a large number of requirements that are not required
to be implemented in the IT solution may get introduced. The requirements prioritization exercise
helps in filtering out the essential requirements that can be addressed through the budgeted time and
cost. Please refer to requirements prioritization guidelines in the handout for more information

22
 Requirements Specification :

+Are Requirements OUTPUT

well documented? ™ Business Requirements Document (Template)
™ System Requirements Specification (Template)
+Are documented METHODS
Requirements easy
to understand by ™ Business Modeling, Usecase Modeling, Taskflow Modeling
stakeholders? ™ Non-functional Requirements (NFR) Specification Technique

ACTIVITY AIDS
+Are Requirements ™
documents easy to
maintain?

1 - 23

Requirements specification involves documenting requirements through formal

templates and models. We have already discussed the modeling methods used to
capture business and system requirements.

Please refer to the BRD, SRS templates for further information.

23
 Requirements Validation :

+How Are
Requirements OUTPUT
reviewed and finalized ™ Baselined Business Requirements Document (Template)
by stakeholders? ™ Baselined System Requirements Specification (Template)
+How Are METHODS
Requirements ™ Walkthrough Workshops
handed over to IT ™ Application Simulation
development team?
ACTIVITY AIDS

+How are ™ Requirements Validation Guidelines

Requirements
validated after
implementation?

1 - 24

Requirements Validation method aims to get review and signoff from the various
stakeholders for their respective areas of expertise. The requirements specification
created using models helps in delineating requirements from the viewpoint of
different stakeholders and hence becomes easy to validate.

Please refer to the requirements validation guidelines provided in the handout.

Application simulated using tools are a good way to validate System behaviour and
user experience. We would cover this when we go through the InFlux Workbench
tool demonstration.

24