1.

INTRODUCTION

Between 40% and 60% of software failures and defects are the result of poor software management and requirements definition. This means that about half of the problems encountered could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. This is to say that the programming was fine and the developers did their job well - only they did a different job from what they were supposed to. Requirement management plan, in a nut shell, streamlines the requirement management process and convey it to all stake holders.

2.0

PURPOSE

This Requirement Management Plan serves the purpose of organizing all stakeholders requirement management aspects of Software Development Lifecycle, handled and managed by the Business Analysis team (SWPD). RM plan establishes an orderly method by which the goals of customer requirements will be achieved. The plan also communicates essential information to project participants and helps newcomers understand the requirements. Consequently, the plan is a living document (configurable item), which needs to be updated and supplemented throughout its life.

3.0

SCOPE

The scope of the Requirement Management plan covers all Project related activities with respect every requirement for each project phase. Its a process spanned over complete project life cycle. The scope of the plan includes: What must be done All the activities mentioned in the plan should be taken care of. How it shall be done

The process and procedures, defined in this document, are taken as guidance for how to perform the requirements management. Who will perform various activities Roles and responsibilities should be defined for the various roles for different activities of requirement management. Furthermore, WBS should be made with respect to each task and role. When they must be performed The Project Life Cycle relationship should be maintained for identifying the timing of each task. What level of quality must be achieved

4.0
PHPL: Role

RESOURCE ALLOCATION

Following resources are identified who will gather, manage, and stream line requirements from both and Responsibility Ensures that all stakeholders have Name

resources to complete requirements.

Role

Responsibility Monitors identified. Handles all financial and implications change of in requirement requirements. Monitors deployment requirements gathering phase and from phase ensures initial, to timely requirement approves status of requirements and

Name

ensures that all requirements are clearly

completion of all requirements. Communicates technical constraints associated with requirements. Communicates technical repercussions and estimates incase of change in requirement or new requirement. Gather all requirements, document it and communicates Analyze technical implications it. of

requirements and communicates functional constraints associated with a requirement. Ensures that all requirements are clearly identified and communicates the requirements to all required functions. Periodically monitors business activity from requirement gathering to its completion and ensures that all processes adheres to CMMi quality assurance process. * TBH: To be hired * TBD: To be determined

List of tools being used, including requirements repository, CASE tools, test tools, project planning tools, issue management tools, estimating tools, as well as non-automated tools such as diagrams Tool Name Microsoft Word Microsoft Visio LDM (Lotus Document Manager) Microsoft PPT Subversion Presentation Material for training and some reviews For keeping Source Code 6.0 2003 Purpose Used for Documenting Requirements Process Flows for requirements Version Control and repository Version 2003 2003 6.5

5.0

REQUIREMENT PROCESSES

Requirement management process shall start from requirement gathering phase and shall go through following sequence: 1. 2. 3. 4. 5. 6. 7. 8. team of consultants shall gather requirements from PHPL and draft it formally in Requirement Specification Document. Document shall be sent to PHPL project manager (TBH), who will approve it. If incase of any issue in RS, requiring changes in it, cycle from point 1 to 2 shall be repeated. After RS approval, it shall be baseline and any change request will go through formal change request process. Functional Specification, containing technical implication and constraints will be drafted by keeping all requirements from RS in mind. Document shall be sent to PHPL project manager (TBH), who will approve it. If incase of any issue in FS, requiring changes in it, cycle from point 5 to 6 shall be repeated. After FS approval, it shall be baseline and any change request will go through formal change request process. Note: All requirements, from Requirement Specification, Functional Specification, Test Cases, Builds and Releases shall be traced through Traceability Matrix. Requirements Management reflected in Project Life Cycle as shown below:

Refer to section 4.2 of project execution plan for development lifecycle life cycle

Requirement Management High Level Process Flow

Responsibilities Artifacts

1 Requirements will be analyzed

1 Ahshan Ullah Bughio Amir Dawra 2 Ahshan Ullah Bughio Furqan Baqai

1 Requirement Specification

2 Requirement Specification Document

Formation of RS (Requirement Specification) Gathered through meetings

10

Change request Internal or external from client

3 Financial Service Team / QE

3 RS in Draft from

3 Review of RS

Issue Resolution

4 Financial Service Team / QE 5 Ahshan Ullah Bughio Furqan Baqai

4 Signed RS ready for baseline 5 Functional Specification Document Draft

4 Signoff by customers on the RS Document

6 Financial Service Team / QE Formation of FS (Functional Specification) Document

6 Draft

7 Financial Service Team / QE Issue Resolution 8 Request by client or internal team decision

7 Signed FS ready for baseline

6 Review of FS 8 Change Request Form

7 Signoff by customers on the FS Document

Change Management Process

End of Process

6.0

DOCUMENT CHANGE PROCESS

All changes in the document will be subjected to Change Management Process highlighted in the process flow (refer to section 5.0) All requirements changes will go through: External changes will be initiated by the Project Manager of PHPL (TBH) All changes will be reviewed by CCB (Configuration Control Board) and will be catered accordingly. (Please refer to section 2.9.1 of Project Execution Plan for CCB members) Depending on the type of change, team of consultants and Sr. Architect, (Ahsanullah Bughio and Amir Dawra) will analyze the change along with its technical implications, impact on current development activity and resources required to cater the change(s) and draft it in the form of formal Change Request Form. Change Request Form (CRF) shall be approved by Vice President TDS (Kashif Aziz), Project Director and Director VAR (Mohammaed Sabzwari) and Project Manager - (TBD). The approved CRF will be passed to PHPLs Project Manager for approval from PHPL. After approving the CRF, all impacted artifacts shall be changed accordingly.

For more details, please refer to the Configuration Management plan,

7.0

CONFIGURATION MANAGEMENT

All documents produced as a result of the REQM activities of the project should be placed under configuration control in the respective project folder. Naming conventions and standards for the documents to be followed according to the CM plan and requirements document criteria. Document Path: Please refer to Appendix B for referring Configuration Management Plan

8.0
Name

INVOLVEMENT OF STAKEHOLDERS
Role VP, TDS CFO, PHPL Project Director and Director VAR Group Head, QE Project Manager, PHPL Project Manager, PMO Manager, ADMS and Sr. Architect MIS Manager, PHPL Associate Manager , Functional Consultant

Following stakeholders are affected by, or affect, the product as well as the process.

Note: Functional head of all stake holders are mentioned in the list. Stakeholders involvement will be confined to Resolving issues on the understanding of the requirements This includes PM, Testers, Clients in the issue resolution phase. Assessing the impact of requirement changes Communicating bidirectional traceability Identifying inconsistencies between project plans, work products and requirements

For more details, refer to Requirement Specification Document [To be drafted].

9.0

MEASURES
and PHPL shall be responsible for monitoring all requirements and variances

Project Manager(s), from

against the estimated timelines. Detailed measures shall be captured by the s Quality Engineer team and will be communicated to: Kashif Aziz (VP, TDS) Mohammed Sabzwari (Project Director and Director VAR ) Project Manager () Amir Dawra (Manager ADMS and Sr. Architect ) Ahsanullah Bughio (Associate Manager, Functional Consultant )

Measures impacting project directly or indirectly shall be communicated to Project Manager, PHPL by Project Manager . KPIs, for monitoring requirements shall be captured in Measurement Plan (Please refer to Appendix B for Document Paths).

10.0 REQUIREMENTS VOLATILITY (NUMBER OF CHANGE REQUESTS AFTER THE BASELINES HAVE BEEN ESTABLISHED FOR RS AND FS)
n/a

11.0
1. 2.

NUMBER OF HIGH RISK REQUIREMENTS

10.1.1: Development of business intelligent application. 10.1.5: Development of Banner Management portlet.

12.0

PHASE WISE HIGH LEVEL REQUIREMENTS

This document covers all requirement for Phase 1. Deployment of application shall take place in one phase. Note: If incase because of any known / agreed upon reason, any features development is delayed, rest of the application shall be deployed and other feature will be deployed in next mutually agreed phase.

13.0

ASSESMENTS AND REVIEWS

The REQM Team would be responsible for adhering to the best practices standard. QE team will be auditing the implementation of REQM according to plan, process guides and templates from both process and product quality perspective. Refer to Project Schedule and MOM, from Appendix B.

14.0

REVIEW STATUS WITH HIGHER LEVEL MANAGEMENT

The status or requirements is shared as per need of the project with the higher management for resolution of issues related to the requirements. The meeting minutes, tracking of requirement issues or resolution of REQM process non- compliance is reviewed with the higher management through periodic or event base meetings. Higher management consist of: 1. 2. 3. 4. 5. 6. (VP, TDS ) (CFO, PHPL) (Project Director and Director VAR ) (Group Head, QE ) (MIS Manager, PHPL) (Project Manager, PHPL)

7. 8.

(Manager, ADMS) (Associate Manager Functional Consultant, ADMS )

15.0
1. 2. 3.

PLAN APPROVAL
(VP, TDS ) (Project Director, Director of VAR ) (MIS Manager, PHPL)

Document shall be approved by:

APPENDIX A - DEFINITIONS, ACRONYMS, ABBREVIATIONS

QEQuality Engineering REQMRequirement management TDS..Technology Deployment Services CEO.Chief Executive Officer GH. Group Head QAQuality Assurance SLT. Senior Leadership Team CMMI Capability Maturity Model with Integration PMProject Manager OJT On the Job Training CT.Class Training SME.Subject matter expert in one or more areas of the clients business TBHTo be hire TBDTo be determine

APPENDIX B - REFERENCES
Document Name Training Template WBS / Grantt chart Risk Log Document *Configuration management Plan Project Execution Plan *Verification plan BOQ Features List Procurement Plan Measurement Plan *Requirement Specification SOW * Shall be develop after planning phase Path