Professional Documents
Culture Documents
(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
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.
• 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
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
Inconsistency
Ambiguity [5%] [13%]
Omission [31%] Incorrect Facts [49%]
Misplaced Req [2%]
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
Caters To Caters To
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.
7
InFlux RE Methodology – Scope for this Training
Requirements
Engineering
contains contains
Caters To Caters To
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?
• How can I get business and IT teams to speak the same language?!!
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?
Complexity
GETTING CONSENSUS?
SCOPE?
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
1 - 11
11
Requirements Development – Bringing in a
methodology
Typical Requirements Development Activities
1 - 12
12
Requirements Development – Bringing in a
methodology
Typical Requirements Development Activities
1 - 13
13
Requirements Development – Bringing in a
methodology
Typical Requirements Development Activities
1 - 14
14
InFlux Requirements Development Viewpoint :
Approach to execute activities - Iterative
Typical Requirements Development Activities
NN
ATIO
ITER
% of Requirements Complete
…..
N2
ATIO
ITER
1
TION
ITERA
1 - 15
A key Question that comes to mind is how are these activities carried out in a
project – Two simple choices are
15
Requirements Development – Methodology Details
1 - 16
16
Requirements Elicitation & Specification :
STARTING POINT
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 –
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
OUTPUT
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
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.
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
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
20
InFlux Requirements Development Viewpoint –
Hierarchical
Key Goals and Objectives
Drivers
Regulatory
Business Needs Technical Needs
Needs
Application
Business Business Issues &
Functionality
Business Collaboration Workflow Recommendations
Catalog
Reqmts
System
System Taskflow, Non-Functional Wireframe Model Data Model,
Reqmts Business Requirements (UI Screen) Dictionary
Rules
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 :
1 - 22
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 :
ACTIVITY AIDS
+Are Requirements
documents easy to
maintain?
1 - 23
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
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.
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