| Version | Date | Change Information | Author | Approver |

| ------- | ---- | ------------------ | ------ | -------- |

| V1.0 | Feb 24, 2026 | Initial Draft | Melisha Dsouza | Pooja Thorat |

Requirements are a vital part of software development. Requirement management introduces the process of gathering, analyzing, and managing requirements. It ensures a clear agreement between the development team and the customer on what is to be delivered and helps maintain that agreement throughout the project lifecycle.

- **Business Requirements**—which covers high-level business goals.

- **Functional/Technical Requirements**—which covers the functionality of the product in detail

- **Non-Functional/Non-Technical Requirements**—These do not cover the product's functionality but rather goals such as Reliability, Scalability, Security, Integration, etc.

- **UI (User Interface) Requirements**—which covers the interface between “the user” and “the system.” It is closely related to functional requirements.

The purpose of requirements management is to ensure that an organization documents, verifies, and meets the needs and expectations of its customers and internal or external stakeholders. Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. Requirements management further includes supporting planning for requirements, integrating requirements and the organization for working with them (attributes for requirements), as well as relationships with other information delivering against requirements, and changes for these.

The scope of this process is managing requirements and changes in requirements.

The scope includes the following activities:

- Obtain an understanding of requirements.

- Manage SRS

- Obtain commitment to requirements.

- Manage requirement changes.

The purpose of requirement management is to systematically collect, document, and manage requirements until completion. It also involves analyzing requirements, incorporating feasible changes, and identifying any inconsistencies between the requirements and the project plan.

For requirement management our policy is,

- To document the requirements as received and effectively manage their evolution and changes throughout the project lifecycle.

- Requirement management will not only gather the requirements but will also handle their change and incorporate the new requirements received.

- Requirement management will make sure that what we are building is required and deliver the product with the required characteristics.

A work product may begin as an analysis made during the development of a project, creating a type of proposal for the project that a company cannot deliver until the project has received approval. Companies use work products to provide information to current stakeholders and potential investors. Types of information available in a work product might include prototypes, presentations, recorded discussions, diagrams, and status reports. The organisation can also utilise the work product as a source of information as the project progresses.

- SRS (System Requirement Specification)

| Process Elements | File Name or Reference |

| ----------------------------------- | ------------------------------------ |

| Checklist | RDM audit checklist |

| Checklist | RM change request analysis checklist |

| Requirement Traceability | JIRA |

| Impact Analysis | JIRA |

| Unit Test Case Traceability | Gitlab |

| Record | Where to get it? |

| ----------------------------------------- | ------------------------------ |

| Signed Agreement | NA |

| Approved SRS | Process Area_RDM |

| Recorded Requirements | Jira tool |

| Recorded change in requirements | Jira tool |

| Requirement Traceability | Jira tool |

| Unit Test Cases Traceability | Gitlab |

| Impact Analysis | Jira tool |

| Design Documents (HLD, LLD, etc.) | Process Area_TS |

| Bug Tracking and Resolution | Jira tool |

| Test Plan | Process Area_PLAN |

| Audit Plan and Audit Reports | Process Area_PQA |

| Minutes of Meeting (MOM) | Process Area_PCM, Mails |

| Requirement Review | Jira Tool, Gitlab, Process Area_PLAN|

| Unit Test Case Review | Jira Tool, Gitlab, Process Area_PLAN|

| Milestone/Release Review | Jira Tool, Gitlab, Process Area_PLAN|

| Measurements | Process Area_MPM |

| Work Product Checklist | Process Area_PQA |

| Release Checklist | Process Area_RDM |

| Roles | Responsibilities |

| --------------------------------------- | ---------------- |

| Project Owner | Requirement Gathering and approval<br>Prepare an agreement for the project<br>Ensure approval of the project to team members.<br>Task tracking and deployment |

| Business Analyst / Project Coordinator | Gather the requirements from the client.<br>Prepares the Requirement specification document.<br>Manages and documents the system requirements throughout the project’s life.<br>Prepare a project in Jira to record requirements, test cases, etc.<br>Functional Test Cases Review<br>Communicates and resolves any customer-related issues.<br>Responsible for making the requirements understood to the project manager.<br>Helps the PM with the CRs of the system requirements and their allocation.<br>Manage Requirement Traceability<br>Record MOM |

| Quality Analyst | Understand the requirements<br>Note down functional test cases<br>Prepare test Plan<br>Testing<br>Manage functional test cases traceability<br>Records Bugs<br>Release Checklist |

| Team Leader | Prepare HLD according to requirements<br>Unit test case review<br>To help developers with critical technical issues<br>To ensure delivery on the given timelines<br>Record MOM |

| Project Manager | Prepare resource plan<br>Prepare a release plan with the help of the BA/PC<br>Manages the allocation of the system requirements throughout the project’s life.<br>Design Document review (HLD, LLD, design doc, etc..)<br>Communicates and resolves the issue escalated by the project team.<br>Monitors the project progress and keeps the PC/BA/customer informed.<br>Periodically seeks customer feedback<br>Review Requirements<br>Record MOM |

| Developer | Understand the requirement<br>Prepare design plans |

| Configuration Manager | Prepare a project in the gitlab to keep the source code as well as documents.<br>Prepare a configuration plan<br>Update Configuration Management Checklist |

| Process Quality Assurance Manager | Prepare Audit Plan<br>Maintain Audit reports<br>Assure the quality of the process |

| SPOC (Customer’s side) | Reviews the requirement document from the perspective of ensuring the completeness of coverage of all the requirements.<br>Review the change in the requirement form and update information about approval. |

- **Requirements should be gathered by the PO/PC,** who understands the project flow, using tools like **Jira, Record My Desktop, Recorder, or drawings on a notepad,** and should create a **Functional Specification Document (FSD)**, which will then be used for creating the **SRS and estimations further**.

- The **prioritization of requirements** should also be noted along with the requirements.

- **Commitment to the client should not be given** until the requirements are discussed among the team members, who should include the **Project Manager, Team Lead, Developers, and Quality Analyst** as well.

- The discussion with the team members should include the **feasibility of the requirements and open issues**. The discussion should end with the requirements that are feasible and can be taken forward.

- After the discussion, **PO/PC should rephrase the requirements or user stories** into:

- Short Business Requirements

- Functional Requirements

- Non-Functional Requirements

- These should include both **problem statements** and solutions and be documented in the **Software Requirement Specification (SRS) Document.**

- This **SRS document should be sent for the client’s approval**. Once approved, it can be kept in a **document repository/Google Drive for record keeping**.

- The approved document should be revised among the team members again.-

- According to the approved SRS, PO/PC should record all requirements in Jira.-

- **A Quality Analyst (QA)** should understand the requirements and prepare functional test cases in Jira, and link test cases to requirements.

- A **Team Leader (TL)** should prepare a Design Document (HLD, LLD, etc.), which will be reviewed by the Project Manager (PM).

- **PO/PC and PM** should prepare a Release Plan and share it with the team members.

- According to the **approved HLD and SRS guidelines**, a Developer should prepare Unit Test Cases, which will be reviewed by a team member.

- Once **test cases are approved/accepted** by the Team Leader, the developer should start development according to the Release Plan.

- The **Project Owner** should prepare a Sprint for testing according to the release plan.

- **Developers** should ensure the successful completion of Unit Testing before giving it for Functional Testing.

- **Quality Analysts** should perform Functional and Non-Functional Testing according to the Test Plan and ensure proper status updates.

- The Quality Analyst should record bugs in Jira and update the closure status once fixed.

- Once the QA ensures the successful status of testing, PO/PC should conduct a Milestone Review with the TL and PM.

- **After milestone delivery,** PO/PC should record client feedback, which may include approvals or client-reported bugs.

- If there are **open client bugs**, the team should resolve them according to the Project Plan.

- Configuration managers should prepare a CM plan and create a new project in Jira for time entries spent on the project.

- PQA should prepare an audit plan and ensure the process quality.

- Whenever a change in requirements, as well as new requirements other than initial requirements, arrives, PO/PC should accept the change, but should not commit before the impact assessment is done.

- The impact assessment should include the PC, PO, PM, devs, and testers. Once the impact analysis is done, the same is communicated to the SPOC for approval.

- After the impact assessment, the PC should communicate the impacts and costs of the change over communication channels, such as Google Meet/Telegram, to the client for approval.

- Once client approval is received from the client. The changed requirement should be recorded in Jira under the component name Enhancements and issue type improvements by PC/PO.

- The changes should be sent to the project manager for development.

- The changes should be reflected in JIRA and other related documents. All stakeholders, project managers, developers, and testers should have the knowledge about the changed requirements.

- Requirement elicitation and analysis

- SRS preparation and documentation skills

- Requirement traceability and change management

- Impact analysis and feasibility assessment

- Knowledge of SDLC and testing lifecycle

- Jira and GitLab tool proficiency

- Communication and stakeholder coordination

- Basic technical understanding (HLD, LLD, APIs)

- Planning and release coordination

- Quality and process awareness (CMMI standards)

Traceability is the life cycle of an issue type. In the requirement development management, Enovate will be keeping a record of traceability for below issue types.

- Story

- Technical Story

- Change Request

- Improvement

- New Feature

- Security Issue

Requirement Traceability will be maintained in the Jira tool by QA/PC. Below is the workflow for a requirement status.


Measurement standards are used to determine accuracy as well as to see the chain or graph of the process. In the measurement of a set, accuracy refers to the closeness of the measurements to a specific value. In the RDM process area, below, measurements will be counted.

- Requirement performance will be evaluated based on the results of the release checklist.

- Periodic (daily/weekly) reviews of the process and work will be done by the PO/PC and the manager.

- All managerial tasks and required information will be maintained in Jira.

- This provides awareness of and insight into software process activities at an appropriate level of abstraction and in a timely manner. The time between the reviews should meet the needs of the organization.

| Acronym/Term | Description/Definition |

| ------------ | --------------------------------- |

| RTM | Requirement Traceability Matrix |

| PM | Project Manager |

| PL | Project Leader |

| PC | Project Coordinator |

| PO | Product Owner |

| BA | Business analyst |

| CM | Configuration Management |

| HRM | Human Resource Management |

| TC | Test Cases |

| RSH | Related Stakeholders |