Requirements For DCN - ITSD-12336
Document Purpose
The purpose of this document is to document the high-level business requirements for Service Requests and Projects. High-level business requirements for Projects are obtained from the Business Case Evaluation or the Project Request.
Requirement Elicitation Sessions and Reviews Conducted:
The following requirement elicitation sessions and reviews were conducted with the customers on the following days:
- 06/08/22, Ryan Arcilla, SME, Geronimo Ocampo, SME
Introduction
Request Description
We need the ability to be able to switch the requester when needed just like how we are able to do so for some of the other fields. The reason for this is there will be instances that the DCN will need to be reassigned to a different owner because the original requester has left Regional San or possibly that the requester should just be someone else. There’s huge impact on our work when we have to go through an ITSD to request to fix this as we need to keep the DCN’s moving forward and it be available to be reviewed by the person it gets reassigned to. Even if we have completed the DCN, we will not be able to turn it in to Requesters Review until the ITSD request gets completed
Business Requirement Instructions
Business requirements are needs or wants or an organization which allows the business to achieve its end objectives, vision, and goals. They give the extent of a business need or a problem that should be addressed by a particular project. Business requirements are intended to be guide and they are not intended to be specified at a level that they could be implemented by a developer. Each requirement should be assigned a unique requirement key as this key is used for traceability from this document through to the implementation of the requirement.
Requirement Key: IT-9999-BR-9999 (IT-9999 = Jira Epic or Issue # of your project/task, BR = Business Requirement, 9999 = Unique # assigned by Requirement Yogi). Requirement Yogi will automatically assign the next consecutive number.
Requirement Type:
- Executive, Stakeholder, Product
The source column indicates the source of the requirement and can be any of the following:
- Specific Person or Persons
- Group, Division or Department
- Documentation (Forms, etc.)
- Meeting
- Application
The priority column ranks the relative importance of the requirement to the Stakeholders:
- 1 – highest priority; absolutely essential product feature OR Must have
- 2 – medium priority; individual features are not essential, but together they affect the viability of the system OR Should have
- 3 – lowest priority; nice-to-have feature; one or more of these features could be omitted without affecting the system viability OR Nice-to-have
- Not implementing
Status Legend
NEW | New requirement, details have not been worked out |
|---|---|
WIP | Requirement details are being worked out. |
PO REVIEW | PO is reviewing the requirement or implementation options. |
IN REVIEW | Requirements are in review by the project team. |
REVIEWED | Requirements have been reviewed by the project team and are ready for approval |
|---|---|
SYSTEM TEST | Requirements are in system test. |
UAT | Requirements are being tested by the customer. |
CANCELLED | The business decided they did not need the requirement (keep on matrix as they may change their mind). |
APPROVED | The requirement has been approved by the customer and can be implemented. |
|---|---|
DEPLOYED | A solution that meets the requirements have been deployed into production. |
Business Requirements
The following matrix describes the high-level business requirements:
Functional Requirements
This section specifies the functional requirements (FR). These should also be the basis for UAT testing.
Key | Functional Requirement Description | Status | Source | Category | Priority | Refines Business Requirement | Links |
|---|---|---|---|---|---|---|---|
ITSD-12336-FR-001 | The DCN requestor field must be an editable field. | APPROVED | Ryan Arcilla Geronimo Ocampo | Interface | Must Have | ||
ITSD-12336-FR-002 | Only a coordinator user should have the ability to edit the requestor field. | APPROVED | Ryan Arcilla Geronimo Ocampo | Data | Must Have | ||
ITSD-12336-FR-003 | Modifications to the requestor field must be tracked in change history. | APPROVED | Ryan Arcilla Geronimo Ocampo | Data | Must Have | ||
ITSD-12336-FR-004 | Requestor field change history must not trigger a change to status date. | APPROVED | Ryan Arcilla Geronimo Ocampo | Data | Must Have |
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|