PRODUCE THE DETAILED-LEVEL REQUIREMENTS

The plans that you already have are based on very high-level senior manager ideas. These ideas need to be formally translated into requirements, which in turn need to be translated into a day-to-day plan of work. This plan will change on a day-to-day basis, causing the requirements to change. Subsequently you need to gain and retain control of the requirements of the project if you are to deliver it successfully. There are four main aspects that you need to consider:

requirements gathering;
requirements in relation to the project life cycle;
requirements control systems;
change control.

Requirements gathering

Requirements are the requests from the organization to the project that it must fulfil to enable it to satisfy its stakeholders. Unfortunately, because advanced projects have a large volume of requirements, gathering and agreeing them can be difficult. An obvious example might be the building of a new airport. In this illustration there are requirements for lifts, check-in areas, security control, baggage handling, etc. There are far too many requirements for any one individual to understand completely. Instead method becomes important since it is through methodology that control can be retained.

Requirements are generally classified into two categories: high-level requirements (HLRs) and detailed-level requirements (DLRs). Normally a high-level requirement will be broken into many detailed-level requirements. Being able to understand this relationship is essential if the project is to be successful. However, this relationship on its own is not sufficient. You also need to be able to understand the association of the high-level requirement to the work breakdown structure of the project. This ensures that when a particular task is being reviewed it is easy to understand where the task originated from and who is supposed to be completing it. This is sometimes known as layering the requirements. A simple technique for relating high-level requirements to their associated work package is shown in Figure 3.1.

Figure 3.1: High-level requirement derivation from work packages

WP 3 (work package 3) is composed of three separate smaller work packages. For each of these work packages you should define a set of high-level requirements. In their simplest form these high-level requirements might be the tasks covered in the work package description developed during the work described in Chapter 2. However, each high-level requirement should cover only one topic and by the nature of the work undertaken so far it is unlikely that the work package description will do this. Instead it is likely that each work package will need to be revisited and appropriate high-level requirements detailed. The requirements should be related to each other and for clarity they should be contained in a separate document. This is shown in Figure 3.2.

Figure 3.2: High-level requirement number scheme

Each high-level requirement has its own unique identifier and that identifier links it to other similar high-level requirements. The unique identifier also links the high-level requirement to the appropriate work package. This scheme can now be extended to include the detailed-level requirements. The detailed-level requirements should be created in response to a specific high-level requirement. This relationship should be reflected in the numbering scheme. This is illustrated in Figure 3.3.

Figure 3.3: HLRs related to DLRs

The cross-indexing of high-level requirements and detailed-level requirements ensures that it is easy at all times to identify the trail from any individual requirement back to the work package that is charged with delivering it. This scheme is a simple but effective scheme. There are many schemes available commercially that relate to difficulties that specific industries might have. However, it is always worth while considering this scheme because it is simple and as a result it is easy to manage and understand.

As the requirements gathering starts to gather momentum it is important that you gain and retain control of the incoming requirements. With a suitable numbering scheme in place this can be achieved through a simple requirements management process. However, before looking at such a process it is important to understand the difficulties that the project life cycle can bring to requirements capture.

Requirements in relation to the project life cycle

It is not possible to gather all of the requirements at the start of a project. Although your project seems to run to a general life cycle there are actually many sub-life cycles within the overall life cycle. Associated to these sub-life cycles are the high-level requirements and associated with them a series of detailed-level requirements. This is shown diagrammatically in Figure 3.4.

Figure 3.4: HLRs and life cycles

Inexperienced project managers tend to think about their projects in a serial fashion. However, this is rarely the way projects actually happen. Figure 3.4 shows clearly the practical timing of the creation of high-level requirements and their associated detailed-level requirements. The high-level requirements and the detailed-level requirements are created both within an overall project life cycle and within several sub-project life cycles. These sub-projects, which all start at different times, are continually producing high-level requirements and detailed-level requirements. This ongoing process makes it very difficult to define a start and a finish to the requirements capture phase. Coping with this lack of clarity is largely a matter of process. This process doesn't have to be complicated. Instead preference should be given to finding a system that is simple and easy to follow.

Requirements control systems

There are many commercially available requirements management tools. These generally promise to solve all the requirements management issues. However, a simple paper system can prove to be just as effective. Setting up a system is achieved by following a few basic steps:

Step 1

Determine a common format that can be used for gathering key information about requirements. A simple word-processor-based template is helpful. It should look something like the form shown in Figure 3.5.

Figure 3.5: Requirements gathering form

The form should be adjusted to account for the type of tasks that the requirements are being captured for. It is also likely that the form will need to be changed for different project types and perhaps to fit in with the numbering system being used to capture the requirements. Completing the form shown is self-explanatory and should pose you little problem.
Step 2

Using the previously designed work breakdown structure, identify the work package managers. Explain to them the purpose of the form and ask them to complete the form for their area. Each work package manager should create a list of potential high-level requirements, which should be based on the contents of their work package. This should prove to be a quick exercise, since the work package already contains a list of tasks and deliverables from the work carried out at the macro planning stage. You should explain to the work package managers that this is now the preparation for the detailed requirements gathering phase. As a result they should take the opportunity to revise the form and add in specific high-level requirements associated with their area.
Step 3

All work package managers should now meet with those who have the authority for approving their work packages' high-level requirements. This meeting should cover the process for completing and signing off the high-level requirements. The process will vary from organization to organization with some organizations having whole departments dedicated to understanding and delivering requirements. When there is no in-house department it is useful if the work package manager takes on responsibility for the high-level requirement creation. This is a sensible approach since it is the work package manager who has resources available to undertake the work. It is worth emphasizing to the work package managers that this exercise is not the same as the initial requirements gathering held in support of the production of the macro plan. Instead they are expected to detail out all of the requirements to enable them to deliver the desired project outcome.
Step 4

Once the requirements have been signed off by the relevant customer the next step is the creation of the detailed-level requirements. The easiest way of achieving this is to follow the same process that was used for the generation of the high-level requirements. The only difference is the form that you provide as the standard template for the various work package managers to complete. A revised form is shown in Figure 3.6.

Figure 3.6: DLR gathering form

The detailed-level requirement capture should include using the numbering scheme defined for the project. This should be either the scheme provided by the sponsoring organization or one based on the earlier discussion in this chapter.

You should find the form in Figure 3.6 self-explanatory. However, it is worth explaining the two different methods that can be applied to describe detailed-level requirements. Firstly, detailed-level requirements can be described in a specific measurable form, for example ˜There shall be a 1.5-metre fence surrounding the building.' Unfortunately this method does not work for all requirements. When the requirement cannot be made specific then it is best to adopt a scenario approach, for example ˜Customers should be delighted with the software and as a result will tell their friends about it.' As the project progresses, the number of requirements that cannot be defined in a measurable way will decrease.
Step 5

Once the high-level requirements and the detailed-level requirements have been completed they should be included in the project baseline. This will bring them under configuration control. This simply means that prior to any change in day-to-day activity the change must be considered in relation to the requirements.

If you do decide to adopt a paper system then you should consider setting up a full-time requirements management team. This team should deal with all the requirements and their associated numbering and control. Although requirements management is not a difficult job it does require constant attention, something that you as the project manager will not be able to give it.

Change control

Unlike other projects, advanced projects often have continuous and significant change in their requirements. This large volume of change inevitably results in a substantial number of change requests. This is particularly true at the start of the project. This is when customers generally start to work out what they really want delivered. Controlling this volume effectively is necessary to ensure success in the early project phases. Even as you are in the process of capturing the initial wave of requirements, changes will be happening. It is important that these changes happen in a controlled manner and therefore you should ensure that everyone is using a change control mechanism. A change control mechanism is straightforward to implement. All that you need to do is implement a process that ensures that changes are investigated for their impact prior to the change being made. Again using a simple form helps. A suitable form is shown in Figure 3.7.

Figure 3.7: Change control form

Control of the change requests is achieved by the use of the priority and the open and closed date fields. Priority is assigned when the change request is initially raised. For the form shown a number between 0 and 4 should be used: 0 is the highest priority and 4 the lowest priority. The level of priority should be suggested by the sponsor (the person raising the change request), but it should be confirmed by someone designated by you. If you have set up a requirements management team then you should delegate the responsibility to them.

Priority setting on its own, however, is not enough to ensure that change requests are being dealt with properly. The length of time a change request has been outstanding also needs to be considered. If the time taken is not considered then those raising change requests will quickly become disillusioned. They will feel that the project simply sets priority levels to avoid dealing with requests. You can easily avoid this situation by setting and adhering to some standard response times, for example:

Priority	Turnaround time
	2
1	5
2	7
3	10
4	20

So for a priority 0 change request, the project is agreeing that it will deal fully with the proposed change within two days. You need to monitor these times on a regular basis and when the project is consistently failing to meet the set targets you should take remedial action.