Documenting requirements

Предыдущая73747576777879808182838485868788Следующая

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.

Requirements Source Comments 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:

There are several potential outcomes from the exercise:

5.1.5.1 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 Author Date
Requirement ID Requirement Name
Source Owner Priority Business process
Functional Requirement Description
Management and Operational and Usability Requirements Description
Justification
Related Documents
Related Requirements
Comments
Resolution
Version No Change History Date Change request

Table 5.4 Requirements template

The key entries in the template are as follows:

The following should be clearly agreed during this prioritization activity:

5.1.5.2 Full requirements documentation

An effective requirements document should comprise the following elements:


7966871948602472.html
7966921895812370.html
    PR.RU™