Client: Project Name
Requirements Document

Date: dd.mm.yy

Written by: Author

Version: Latest version

Document Distribution

(Please inform the author of any required changes to the distribution list)

Key Client Stakeholder Sign-off
Name / Area / Approval level * / Date Signed Off
Key Stakeholder Sign-off
Name / Area / Approval level * / Date Signed Off
Project Team Sign-off / Interested Parties
Name / Area / Approval level * / Date Signed Off

* A = Approval, C = Comment, I = Information only

Document Control

Version
Number / Date Issued / Status / Owner / Reason for Change
0.1 / Draft / Enter the name of the document author or authors. / Give reason e.g. initial draft for peer review
0.2 / Draft / As above or different if amendments have been done by another / e.g. first draft issue for sign off following peer review
0.3 / Draft / e.g. amended version for sign off following walkthrough comments
1.0 / First issue / e.g. signed off version / baselined (all future changes should therefore be subject to change control)

Document References

This document should be read in conjunction with the following documents:

Document Name / Owner / Version
Provide document name and Insert hyperlinks where appropriate. Use of hyperlinks should mean it is not so crucial where a document is stored as it can be accessed from here. / Provide details of the latest owner of the document referenced / Enter the appropriate version number here. Note that if the document changes and the changes impact on this doc, then the version should be updated here. It might be worth Project Office maintaining the integrity of these links centrally by having all version controlled documents logged in through them

Glossary of Terms

Term / Meaning
Provide details in here of any abbreviations . acronyms or other terms that may be ambiguous or unclear to enable all reviewers to understand them / Give detail of the meaning behind each term

Priorities

The following table details the priority classification applied within the document which is based on the MoSCoW principle.

Term / Meaning
M / MUST have this / Anything labeled as "MUST" has to be included in the project delivery timebox in order for it to be a success
S / SHOULD have this if at all possible / While not critical to the success of the project delivery, "SHOULD" items are nearly as important and should be included if it is at all possible. "SHOULD" items are often as important as MUST items, however "SHOULD" items have workarounds allowing another way of satisfying the requirement
C / COULD have this if it does not affect anything else / "COULD" items are less critical and often seen as "nice to have". A few easily built Coulds in a delivery can increase customer satisfaction for little development cost
W / WON'T have this time but WOULD like in the future / "WON'T" items are either the least-critical or lowest-payback items. As a result, "WON'T" items are not planned into the schedule for the current project iteration. "WON'T" items are either dropped or reconsidered for reprioritization in later project increments. This, however doesn't make them any less important. Sometimes this is described simply as "Would like to have" in the future

Where a requirement relates to a statement included for completeness or to provide background this will be denoted in the priority column as “I” for Information only.

TABLE OF CONTENTS

Use the formatting available in Word to number pages and document secions and an automated table of c ontents can then be inserted

1.Introduction

Background
Provide detail of the background which has meant this document is necessary e.g.details of a new project. What has driven the project? Is it a new Client? Is it a particular operational problem which needs to be addressed?
If the project has a number of different requirements documents, then this section should provide details specific to the requirements that are in scope for this document.

1.1.GoalProvide details of the business objectives that these requirements will be supporting. e.g.reduce operating times, minimise the opportunities for error, introduce a new system as part of a strategic operating model etc. These should be as measurable as possible. They provide the link back to justify all requirements contained in the catalogue and those compiling and reading this document should be questioning every requirement to ensure that it meets the stated objectives. .

1.2.Purpose of the document

Provide details of the document purpose. Eg : to capture the high level or detailed requirements for third-party processing or to detail the requirements for the call centre to support a new client etc etc

It should be clear to all reading this section why the document has been put together. It is important to distinguish between high level and detailed requirements. If the project is of a size such as it makes more sense to document detailed requirements straight away, then state this so that there isn’t an expectation of a more detailed document being provided at a later stage following the initial publication.

1.3.Scope

1.3.1.In Scope

  • Note any scope inclusions relevant at either project or document level. E.g. items agreed for inclusion for Phase II when original project defined are included

1.3.2.Out of Scope

Note any specific exclusions here.
If there are any items for which there may have been an expectation that they would be included, it might be worth stating why they are out of scope.

1.4.Assumptions

Detail any key assumptions made within the document.

1.5.Constraints

Detail any key constraints which apply to the project within the document. For example, there may be a fixed time and budget available for this work which may affect the level of requirements which can be delivered. By ensuring that this is known upfront, anyone working on the project will have an awareness. Also include any legal constraints in here, any internal constraints (e.g. the client has signed up to the standard product so only a 10% customization of process will be permitted)

The next sections should detail the business requirements..Guidelines

They should consider both functional and non-functional requirements but should be stated clearly as a requirement rather than a solution

For example: think about any specific formatting or validation which may also be required;think about frequency e.g. a file needs to be produced, but is there a specific format required in order for it to be processed? What fields need to be in the file? How frequently does it need to be downloaded? Are there are restrictions on when it needs to be delivered?

The requirement id is provided in order to make referencing easier (see amendments / comments sections at the end), allows greater ease of review, especially during walkthroughs or conference call reviews and provides an element of traceability. It also allows dependencies between requirements to be tracked also as any linked requirements should be identified in the related requirement box. That way, should any requirement be deleted,de-scoped or amended, the impact on the related requirement can be assessed.

Titles should be snappy and succinct so anyone reviewing quickly can find what they need more easily. Use the numbering convention to show supporting detailed sub requirements for high level requirements e.g. 1. sort by date order 1.1 sort by day, month and year ascending, 1.2 dates to be formatted as mm-dd-yyyy
Priority should be completed to enable an understanding of how important a requirement really is. An appropriate agreement on how to categorise these should be reached. Suggestions are to base this on the Moscow principle or to assign a H, M, L priority. This will help should delivery slip against a “drop dead” date as it might be possible to negotiate delivery of the High and Medium items only for example. Should a risk-based testing approach be adopted, this will also enable categorisation of risks. In a large development where design and build activity may be phased, then attention can be focussed on the priority items first.

Where possible, the reason field should be populated in order to fully understand the reason for the requirement. E.g. a request for a blue screen may be simply as that is a preferred colour for the requestor but they would be equally happy with a red screen. However, if a particular shade of blue is required for corporate colours, for example, then that puts a different view on the requirement and raises the importance that needs to be attached to it. This enables effective prioritisation of requirements and also allows for push-back. It also ensures that there is a level of verification as to the understanding of the requirement and why it is needed.
The owner should identify the key stakeholder for that requirement e.g. Marketing, Operations etc. That enables effective management of queries against a particular requirement and also an idea of who to agree the priorities with. It can also help with conflicting priorities where the BA may need to negotiate between different parties to agree which requirement takes precedence.

Remember to support your functional requirements with any non-functional requirements as these can be just as important. For example: how many users need to have access to the system; are there any security requirements; where are the users located; what are the throughput volumes; what are the peaks etc

Any supporting flow-charts or other diagrams should be provided as Appendices or included prior to the requirements catalogue as part of background information e.g. maps of as-is versus future processes.

1

18/04/2019

2.Requirements Catalogue

2.1.1stBusiness Process Area

Req. ID / Requirement Title / Requirement Description / Priority / Reason / Owner / Related Req.
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10

2.2.2nd area etc

Req. ID / Requirement Title / Requirement Description / Priority / Reason / Owner / Related Req.
2.1
2.1.2
2.2

3.Change Control

This section of the document will be used to highlight changes to requirements made after the first client review. It should be read in conjunction with the comments section at the end of the document and will enable stakeholders to review the detail of changes made without having to read through the main document again.

It will also be used to maintain the integrity of the numbering system used to identify requirements.

3.1.New Requirements

The following section covers requirements which have been identified as missing from the draft documents produced. Note that some of these requirements fall outside of the original project scope and may therefore be subject to inclusion through Change Control This may mean that they cannot be accommodated..This section may also be used to update the requirements catalogue following change control in order to maintain an up to date requirements catalogue. In this case, the CR reference number should also be included

Req. ID / Requirement Title / Requirement Description / Requirement requested by

3.2.Amended Requirements

Changes to original requirements are highlighted in italics for alterations / additions and in strikethrough for partial deletions. Requirements deleted in their entirety are documented in Section 3.3. Deleted Requirements. This section should ideally be used only until the requirements are base-lined and are to track any changes made during the initial review and walkthrough process following issue of the first draft.

Req. ID / Requirement Title / Requirement Description / Amendment requested by / Date Amended / Original req documented / Amendment included

3.3.Deleted RequirementsThis section should be used for requirements which may be deleted during initial review as they are deemed no longer required or that they fall out of scope. They may also be used to track requirements which are descoped during design due to complexity etc. This is another time where the owner of the requirement is a useful piece of information as it enables appropriate communication to be provided to alert the owner to the change in status of their requirement (and therefore their expectation of delivery!) in cases where the deletion has not been prompted through themselves. This also provides a useful reference for any development,build or test planning and test activity so that actions are not being taken on outdated requirements.

Req. ID / Requirement Title / Requirement Description / Deleted Reason / Date Deleted / Owner / Related Req.

APPENDIX I

Comments

Date / Who / Section / Comment / Response

The comments section should be used to record all feedback received on the documentation. Any deletions, additions and amendments should be added to the appropriate sections of the documented and recorded for audit purposes. This ensures that all comments are captured and actioned in one place and also provides ease of visibility to stakeholders that their queries or amendments have been dealt with appropriately. By having used section numbers and requirements ids throughout the document (together with an index page), review is made easier during walkthrough. It is particular useful for stakeholders when there is a large document to review as it removes the need for them to review the whole document from scratch and enables them to concentrate only on the areas that are important to them, whilst also allowing them visibility of changes made by other stakeholders in case this may impact on them (particular where linked requirements exist).

This section is designed to be used in conjunction with the standard sign-off and feedback sheets so that comments can be easily transferred from stakeholder feedback into this document for tracking.

NB. Care should be taken where the intended audience of the requirements may cover both internal and external stakeholders as some comments may not be appropriate for distribution to Clients.

1

18/04/2019