The requirements document is at the heart of the process and can take a number of forms. Typically the document will include a catalogue of requirements, with each individual requirement documented using a standard template. One or more models showing specific aspects, such as the processing or data requirements, may supplement this catalogue.
Before they are formally entered into the catalogue, requirements are subject to careful scrutiny. This scrutiny may involve organizing the requirements into groupings and checking that each requirement is ‘well-formed’.
Once the document is considered to be complete, it must be reviewed by business representatives and confirmed to be a true statement of the requirements, at this point in time. During this stage the reviewers examine the requirements and question whether they are well-defined, clear and complete.
As we uncover the requirements from our various users, we need to document them. This is best done in two distinct phases – building the requirements list and, later, developing an organized requirements catalogue. The list tends to be an informal document and can be presented as four columns, as shown in Table 5.3.
|| Detail level
Table 5.3 Requirements list
Each requirement in the list must be checked to see whether or not it is well formed and SMART (Specific, Measurable, Achievable, Realistic and Timely).
When checking the individual and totality of requirements, the following checklist can be used:
- Are the requirements, as captured, unambiguous?
- Is the meaning clear?
- Is the requirement aligned to the service development and business objectives, or is it irrelevant?
- Is the requirement reasonable, or would it be expensive and time-consuming to satisfy?
- Do any requirements conflict with one another such that only one may be implemented?
- Do they imply a solution rather than state a requirement?
- Are they atomic, or are they really several requirements grouped into one entry?
- Do several requirements overlap or duplicate each other?
There are several potential outcomes from the exercise:
- Accept the requirement as it stands
- Re-word the requirement to remove jargon and ambiguity
- Merge duplicated/overlapping requirements
- Take unclear and ambiguous requirements back to the users for clarification.
188.8.131.52 The requirements catalogue
The Requirements Catalogue is the central repository of the users’ requirements, and all the requirements should be documented here, following the analysis of the list defined above. The Requirements Catalogue should form part of the overall Service Pipeline within the overall Service Portfolio. Each requirement that has been analysed is documented using a standard template, such as that shown in Table 5.4.
| IT service
| Requirement ID
|| Requirement Name
|| Business process
| Functional Requirement Description
| Management and Operational and Usability Requirements
| Related Documents
| Related Requirements
| Version No
|| Change History Date Change request
| || || || || || |
Table 5.4 Requirements template
The key entries in the template are as follows:
- Requirement ID – this is a unique ID that never changes and is used for traceability – for example, to reference the requirement in design documents, test specifications or implemented code. This ensures that all requirements have been met and that all implemented functions are based on requirements.
- Source – the business area or users who requested the requirement or the document where the requirement was raised. Recording the source of a requirement helps ensure that questions can be answered or the need can be re-assessed in the future if necessary.
- Owner – the user who accepts ownership of the individual requirement will agree that it is worded and documented correctly, and will sign it off at acceptance testing when satisfied.
- Priority – the level of importance and need for a requirement. Normally approaches such as MoSCoW are used, where the following interpretation of the mnemonic applies:
- Must have – a key requirement without which the service has no value.
- Should have – an important requirement that must be delivered but, where time is short, could be delayed for a future delivery. This should be a short-term delay, but the service would still have value without them.
- Could have – a requirement that would it be beneficial to include if it does not cost too much or take too long to deliver, but it is not central to the service.
- Won’t have (but want next time) – a requirement that will be needed in the future but is not required for this delivery. In a future service release, this requirement may be upgraded to a ‘must have’.
The following should be clearly agreed during this prioritization activity:
- Requirement priorities can and do change over the life of a service development project.
- ‘Should have’ requirements need to be carefully considered because, if they are not delivered within the initial design stage, they may be impossible to implement later.
- Requirements are invariably more difficult and more expensive to meet later in the Service Lifecycle.
- It is not just the functional requirements that can be ‘must haves’ – some of the management and operational requirements should be ‘must haves’.
- Requirement description – a succinct description of the requirement. A useful approach is to describe the requirement using the following structure:
- Actor (or user role)
- Verb phrase
- Object (noun or noun phrase).
- Where the requirement incorporates complex business rules or data validation, decision table or decision tree may be more useful to define complex business rules, whilst data validation rules may be defined in a repository. If a supplementary technique is used to specify or model the requirement, there should be a cross-reference to the related document.
- Business process – a simple phrase to group together requirements that support a specific activity, such as sales, inventory, customer service, and so on.
- Justification – not all the requirements that are requested will be met. This may be due to time and budget constraints, or may be because the requirement is dropped in favour of a conflicting requirement. Often the requirement is not met because it adds little value to the business. The justification sets out the reasons for requesting the requirement.
- Related requirements – requirements may be related to each other for several reasons. Sometimes there is a link between the functionality required by the requirements or a high-level requirement is clarified by a series of more detailed requirements.
- Change history – the entries in this section provide a record of all the changes that have affected the requirement. This is required for configuration management and traceability purposes.
184.108.40.206 Full requirements documentation
An effective requirements document should comprise the following elements: