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