COMVERSE 1 200 Quannapowitt Parkway Wakefield, MA 01880, USA

CMMI
Requirements Management
(REQM) Process Overview
Prepared by:
Anantha Koppa, Mark Haas

Reviewed by: Biron Shahar; Ovadia Zadok; Bhardwaj
Rajendra; Odessky Vicki; Koenig Shai

COMVERSE 2
Goal of this initiative:
Improve Business Results by increasing
performance and product quality, reducing
costs and shortening time to market

COMVERSE 3
Approach:
Implement effective and efficient processes that
fit the organizational needs and support its
business goals

As per Senior Management direction, this is
planned by implementing CMMI best practices


COMVERSE 4
CMMI Maturity Levels
Chaotic, processes are unpredictable, poorly controlled, reactive.
Basic Project Management
Managed Processes: planned, documented, performed,
monitored, and controlled.
Engineering, Process Standardization
Defined Processes: characterized and understood
Proactive.
Quantitatively Management
and statistically managed processes
Continuance Process
Improvement
Level 5
Initial
Level 1
Managed
Level 2
Defined
Level 3
Quantitatively
Managed
Level 4
Optimizing
Our Target
COMVERSE 5
Key Process Areas (CMMI Development Model)
Level 2 Process Areas:

1. PP: Project Planning (include Release Management)
2. PM&C: Project Monitoring & Control (include Release
Management)
3. CM: Configuration Management
4. PPQA: Process and Product Quality Assurance (Quality
Management System)
5. REQM: Requirements management
6. M&A: Measurement & Analysis
7. SAM: Supplier Agreement Management


Key Process Areas contains Goals, Practices and more..
Our Focus
COMVERSE 6
Requirement Management OPG (Organizational
Process Group)
Process Champions:
Biron Shahar
Bhardwaj Rajendra
Haas Mark
Koenig Shai
Odessky Vicki

OPG Leads
Koppa Anantha
Ovadia Zadok

COMVERSE 7
Process Status
This is NOT an approved process yet

Currently we are seeking review comments

This addresses What but not yet How
which will be addressed as a next step.

COMVERSE 8
Requirements Management Process
(CMMI L 2 Compliant)


COMVERSE 9
Purpose and Scope
Purpose:
This process defines how teams in Comverse manage
development project requirements.

Scope:
This process applies to all development Projects (Releases)
in the organization.
It does not cover managing requirements generated outside
of development projects (Examples: Roadmap definition
Process, Commitment Process, Pre Sales Process).
Requirements generated outside of development projects
can be input to this process.






COMVERSE 10
Process Activities Summary
Section refers to the numbering in word document
Section Sub-
Section
Sub-Process/Activity
4.1 Requirements Project Planning
4.1.1 Developing the Requirements Management Plan
4.1.2 Monitoring the Requirements Management Plan
4.1.3 Managing changes to baselined requirements
4.2 Requirements Management & Development
4.2.1 Customer/Marketing Requirements
4.2.2 System Requirements
4.2.3 Software Component Requirements
4.2.4 Technical Solution
COMVERSE 11
Requirements Project Planning
Establishes an agreement among the project stakeholders
on the Roles and Responsibilities (who does what) and the
work schedule (when).
The projects Requirements Management Plan should
describe the activities and tasks that are relevant for the
specific project.

There are 3 sub processes:


COMVERSE 12
Developing the Requirements Management Plan
The requirements Management Plan is the Project Plan for managing
the development of the requirements.
This plan includes
Timeline/schedule,
Resources,
Reviews,
Change management,
Tools, templates, checklists,
Repositories
Etc.
The role responsible for developing the requirements management
plan is the Requirements Management Lead
This role may be a part of SW Project Managers responsibility or can
be assigned to someone else
COMVERSE 13
Monitoring the Requirements Management Plan
Tracking and reporting the progress of requirements
development against the plan
Working with appropriate stakeholders/players when any
deviations are identified
Identifying corrective actions and tracking them to closure
Managing risks and mitigation
Coordinating with Software Project Manager
Keeping the plan up to date
Incorporating approved changes in the plan

COMVERSE 14
Managing Changes to baselined requirements
Provides information on managing changes in approved,
baselined individual requirements for the project
Ensures that every proposed change to a baselined
requirement is properly managed for possible impact, then
approved by the relevant authority before the change is
implemented
It is a sub process of the overall change management
process for the project.

Sub processes:
Change Request Initiation
Change Request Analysis and Decision

COMVERSE 15
Requirements Management & Development
The requirements Management &
Development process involves four main
activities
Customer/Marketing Requirements
System Requirements
Component Requirements
Technical Solution

COMVERSE 16
Customer/Marketing Requirements
Involves transforming visions and needs for the system into
requirements. These visions and needs originate from
anywhere.
The most common sources are customers and Product
Management & Marketing.
However, needs and visions can also come from
development, test, support, services, etc.
This activity is the entry point to the formal requirements
development process.
The objectives of this activity are to analyze these
customer/market needs, expectations, constraints, interface
requirements, etc

COMVERSE 17
System Requirements
The purpose of the System Requirements Specification is to
provide a description of what the system should do, in
terms of the system's interactions or interfaces with its
external environment.
The objective of this activity is to
Transform stakeholder requirements into a formal system
requirements specification.
Solve collisions between existing requirements and new ones
Complement the Customer/Marketing requirements with
architecture driven requirements.
Ensure traceability of the system requirements towards the
Customer/Marketing requirements and needs.
Review and Approve the system requirements
Freeze/mark baseline the system requirements. Any changes from
this point should be treated as a change requests.

COMVERSE 18
Software (Component) Requirements
The software requirements specification (SRS) is a
specification for a particular software product, component,
program, or set of programs that performs certain functions
in a specific environment.
The objective of this activity is to design and define low
level implementation requirements that cover system
requirements.
The best practice in industry treat this activity as
requirements to enhance traceability and distinguish from
other types of design activities, for e.g., modeling,
prototyping, etc.
This activity encompasses development, appropriate
reviews, approvals, traceability and baselining of software
requirements.

COMVERSE 19
Technical Solution

The objective of this activity is to
Provide and get approval for the technical solution for the
defined requirements including components decomposition
and interaction between them
The Technical Solution is often needed to convert the
system requirements into functional requirements for each
component of the eventual system.


COMVERSE 20
Impact on Solution Consultants
Customer Requirements Specifications will need to be
more structured than they are today in some parts of the
organization
Attributes that need to be captured with the actual
requirements
Provide traceability to targeted needs
Baselining and changes to baselined requirements
Need to work with System Engineering teams to
ensure traceability to system requirements.

These activities will be done more formally than being done
in some parts of organization today
COMVERSE 21
Next Steps
Review with Senior Management
Preparation of Process Assets Templates, Checklists
Defining How part of implementation
Training to stakeholders

The Requirements Management Process is
located in REQM_Process

Please review and provide your review comments to
anantha.koppavenkatasubbarao@comverse.com
by July 12, 2013



COMVERSE 22
Impact on Product Management

Marketing Requirements Specifications will need to be
more structured than they are today in some parts of the
organization
Attributes that need to be captured with the actual
requirements
Provide traceability to targeted needs
Baselining and changes to baselined requirements
Need to work with System Engineering teams to
ensure traceability to system requirements.

These activities will be done more formally than being done
in some parts of organization today

COMVERSE 23
Impact on Project Managers
Coordinating with Requirements Management Lead
Planning and Monitoring
Requirements Change Management
Synchronization with Requirements Management Plan

These activities will be done more formally than being done
in some parts of organization today
COMVERSE 24
Impact on System Engineers/BAs
Some of you might be asked to take the role of REQM Lead
which may not exist today
Provide traceability to Customer/Marketing requirements
Attributes that need to be captured with the actual
requirements
Baselining and changes to baselined requirements
Need to work with Dev/Test teams to ensure traceability
between requirements and Dev/Test

These activities will be done more formally than being done
in some parts of organization today

COMVERSE 28
COMVERSE 29
Appendix


COMVERSE 30
Purpose:
It is our policy that all requirements under Software Projects conducted in Comverse will be properly
managed, to ensure alignment between those requirements and the projects plans and work
products.
In meeting this policy the project must maintain a current and approved set of requirements over
the life of the project by doing the following:
Baseline requirements for the Software Project consistent with configuration management
processes
Manage all changes to the requirements (using change management process)
Maintain the relationships (traceability) among the requirements, the project plans, and the
work products
Identify inconsistencies among the requirements, the project plans, and the work products, as
well as taking corrective actions and tracking them to closure
All processes, procedures, templates, tools and forms must be followed under this policy.

Scope:

This policy relates to all software development projects conducted in the CTO & R&D and the SSG
organizations, covering all products in the various classifications, General Availability, Customer and
Maintenance projects, ranging from Major, to Medium, Minor and small Correction deliveries.
Policy 1/2
COMVERSE 31

Responsibilities:

Senior management is responsible for providing the guidance and resources for meeting this
policy, as well as providing the authority for executing the activities, and supplying the
measurement objectives.
Product Manager is responsible to provide market driven requirements
Head R&D is responsible to provide technical or architectural driven requirements
Business analyst / System Engineer is responsible
to analyze the requests and write the requirements
to Baseline the requirements
to maintain bi-directional traceability of requirements
to manage changes to requirements
responsible to validate the requirements with the customer
Development/Test lead will review the requirements
Development/PQA lead is responsible to approve the requirements


Policy 2/2