Requirements Management

Madhusudan.V
Created Date: 8th June 2020
Version : 1.0
Contents:
 Requirement Management Overview
 Need Assessment
 Requirement management planning
 Requirements Elicitation
 Requirements Analysis
 Requirements Monitoring and Controlling
 Solution Evaluation
 Project or Phase Closure
Requirement Management- Overview
 Project:

A temporary endeavour undertaken to create a unique product, service or result

 Requirement:

A condition or capability that is required to be present in a product, service or result

to satisfy a contract or other formally imposed specification.
 Project Management:

The application of knowledge, skills, tools and techniques to project activities to

meet the project requirements.
Requirement Management- Overview
Innovation Program- TOC

Project Activities from TOC

Requirement Requirement
Elicitation Analysis

Need Requirement
Assessment Planning Solution
Evaluation

Requirements Monitoring and controlling

Overview-The continuum of project lifecycle

Highly Predictive Highly Adaptive

Requirements are mostly defined Requirements are defined Requirements are elaborated at
up-front before product iteratively and elaborated at frequent, recurring intervals for
development begins periodic intervals during each iteration
requirements process
Risk and cost are controlled by Risk and cost are controlled by Risk and cost are fixed and
detailed planning based on in- progressively detailed planning controlled for each iteration
depth analysis of requirements based on timely spec and
and constraints prior to requirements and constraints
development during development
Key stakeholders are involved at Key stakeholders are involved at Key stakeholders are continuously
scheduled milestones specific intervals and effectively engaged
Need Assessment
Portfolio
• Portfolio Strategic Program
Plan • Business Case
• Portfolio Roadmap • Program Plan Project
• Business Case • Program Roadmap • Business Need
• Benefits Register • Business Case Product
• Benefits realization • Project Charter Service or
Plan/register • Project Agreements Result meets
Requirements

Requirements √
Requirements management Planning
 Success Factors
 Organizational commitment
 Recognizing the value of Requirements management planning
 Stakeholder engagement and collaboration
 Integration with Project Management activities

 Requirements Management Planning activities

 Stakeholder Analysis and Engagement
 Requirements Management Planning initiation
 Develop the requirements management plan
 Launch requirements management plan

 Requirement Tools – Identify and determine when and how they will be used
Requirements Elicitation
 Elicitation is a discovery process used to bring forward or produce information
relevant to the project by drawing out information from stakeholders and other
sources.
 Requirement Elicitation Success Factors
 Planning and preparation
 Active stakeholder engagement
 Defined business/organisational need.
 Domain knowledge.
Requirements Elicitation
 Requirement Elicitation Techniques
 Interviews
 Facilitated Workshops
 Focus groups
 Brainstorming
 Questionnaires and Surveys
 Document Analysis
 Interface analysis (interaction between users, process and others)
 Prototypes
 Observation
Plan for Requirements Elicitation
 Plan for Elicitation
 Activities
 Resources
 Requirement sources
 Expected Deliverables

 Define types of Requirements

 Business Requirements
 Stakeholder requirements
 Solution requirement- Functional
 Solution requirement- Non Functional
 Transition requirements
 Project Requirements
Plan for Requirements Elicitation
 Define types of Requirements contd…
 Quality requirements
 Program Requirements
Challenges In Business Analysis
Knowledge and Skill Stakeholder Commitment:
1. Soft skills 1. Unshared information
2. Technical skills 2. Inconsistent attendance
3. Process knowledge 3. Ego and Politics
4. Domain Knowledge 4. Lack of Knowledge
5. Industry Knowledge 5. Changing roles
Conflict management Hazy Scope
1. Decision
2. Need Unclear Process
3. Effort and timelines
4. Resistance to change
5. Resource
6. Task Vs process
Context of project requirements:
Identify and
Manage
Stakeholders
Gather, Define
and Write
Requirements
Manage
Requirements
Changes
Test
Deliverables

Close
Requirements
process
Stakeholder identification
• Who is paying for it?
• Who is making a profit at it?
• Who is using it?
• Who is for it?
• Who is against it?
• Who can influence the outcome?
• Who will be promoted?
• Who will be punished?
Resourcing at various stages
Level of Resource
Involvement

Project Initiation Planning Execution & Control Closing

Management
Business Analysis Gather Data Assign Core Team Setup project Org. Review & accept Project
Identify Reqr Write Project Plan Establish Detailed requirements Transfer Responsibility
Estimate Resources Develop Scope Baseline Develop and Implement WBS Document & Evalate
Develop Charter Obtain Approval Manage S,C,T Release resources
Define Project Scope Capture Lessons Learnt

Contract Gather Reqr Mange Change Requrests Manage change requests

Model Reqr Manage/Conduct Acceptance Testing
Management Analyse Reqr
Verify & Validate Reqr.

Contract Conduct Pre-award activities Determine the make or buy Award contract Confirm contract completion
Develop RFP etc decision Administer contract Conduct contract closeout
Management Conduct solicitation Evaluate proposals Manage change requests to contract Capture performance metrics
Lifecycle of Requirement

Assessing
Need and Planning Eliciting Requirement
Solution
Creating Business Requirement s
Evaluation
Business Analysis s Management
Case
Role of Business Analyst
Role of Business Analyst
Customer Team Technology Team

Identifying business Detailed

Need Requirements

Validate Solution Solution

Important Skills of Business Analyst
• Understand the present state and its related information
Analytical • Identify the solution
• Validate the solution w.r.t business needs

• Understand the domain

Technical • Understand the system
• Evaluate the benefits of the technical solution

• Collaborate with stakeholders

Interpersonal • Handling cultural and communication challenges
• Problem solving and negotiation skills
Need Vs Goals
 Need: Improvements, changes, pain points, opportunities.
 Goals: quantitative targets to measure the level of achieving needs
Requirements specification rules
 Rule 1 – State only one thing and state it well
 Rule 2 – No use of and to combine distinct requirements
 Rule 3 – Avoid ‘Unless’, ‘except’
Ex: Policy will be issued unless the customer has a bad credit
The system should issue a policy for customers with good credit
The system should reject applications from customers with bad credit
 Rule 4 – Does not depend on other sources of information
Submit an application – Incomplete
The customer will submit an application for vehicle loan
Requirements specification rules
 Rule 5 – Use verb, object, subject and modifies
Customer with good standing – Incomplete
Customers who are current in their payments for existing policies are considered customers
in good standing - Complete
 Rule 6 – Use actor and actions to be carried out
Application must be processed by underwriting 1 business day – Ill structured
Underwriting department should process applications within 1 business day – Well
structured
 Rule 7 – Rules but no on how to present them
The user should be able to select the policies from the ‘drop down’ list – Technology
solution
User should be able to select the option from the policies offered. Rule
Best Practice to write requirements- What not to do?
• At a minimum the performance should be ………..
Avoid Ambiguity • The feature may/can be enabled for the car…..

Avoid Scope Creep • The features are not limited to the following..

• Easy to use
Avoid not easy to test • Performance same as existing systems
statements • TBD (To be discussed)

Avoid incomplete • Non usage of reference documents usage

statements • Page/Table/notes references unavailability

Avoid using certain • Can

verbs • May
Best Practice to write requirements- What to do?
• The report shall have the following contents
Use as follows • A……………..
• B…………..

• Can’t use if and but or else if

Use look up table • Temp > 10°C
• Temp >0°C & <10°C
- Response1
- Response 2

Use • Pictures speak 1000 words

figures/sketches

Use notes • Use supplements for better understanding.

Best Practice to write requirements- Conventions

Must • For compliance related (Emission must comply to BS VI)

Shall • At any cost to be implemented

• System shall have a daily back of data

Should • Shall is not possible; but will have a workaround

• The system should have alternate day backup on weekend

Will • Used in the same level as ‘Shall and ‘Should’

Requirement life cycle management
Traceability
Needs change due to Various reasons
Why ID for a requirement
To identify which requirement has changed
To identify what in requirement has changed
Types of ID:
Numbers like WBS
Coding
What is traceability
To check if test cases are changed wrt requirements changes
Is it only test cases change when requirements change?
Design, hardware/product/code/solution also may change when requirements
change
V-Model
Concept of Verification and Operation and
operations Validation Maintenance

Requirement & System Verification

Architecture and Validation

Integration, Test
Detailed Design
and Verification

Project Project
Implementation Test & Integration
Definition

Time
Change Management
Receive Change
Request (CR) Change Control Board Includes
Analyse CXO’s, Business Analysts, Subject
Matter Experts, PM, Customer Reps
Analyse Business
Impact

Accept Change Reject

Defer
Implement
Now/Next
release
Inform
Stakeholders
Way forward
1. Timelines
2. Prioritize
3. Integration Management