So what happens once the scope of a project has been defined. The requirements for the execution of the project must be identified. As described in the last post, Defining the Scope, the scope of the project covers the six things which must be identified to fully flesh out what it is being done. Now that what is being done and the why it is being done has been identified the how it will be done has to be detailed.
Detailing the how of a projects starts with breaking down the scope of the project. The justification, objectives and descriptions are used as what are known as the customer needs statements. These are the highest level requirements of the project. Through an analysis of these statements lower level requirements are created, known as the derived requirements.
Typically there will be many more derived requirements than customer needs statement. This is because each justification, objective and description will have multiple facets which will have to met in order to be met. For example if the customer has the objective of centralized data storage, the derived requirements for this would indicate the need for an active storage node in the network, some data management application and redundant network connectivity to ensure that the data is always available.
Each of these derived requirements would then go through another analysis to identify the specific items which are needed to make each of them happen. This next level of requirement is known as Functional Requirements. It is at this level that the specifics of how to do the project are discovered. Going back to the previous example, for an active storage node the functional requirements would look something like, it shall have 50 TB of storage space; it shall function as a RAID 10; it shall have an IO (Read/Write) speed of 45 MB/sec.
The functional requirements are then mapped to the acceptance criteria of the project. By doing this and comparing to the constraints, it can be assured that the project will meet the objectives and satisfy the justification without adding time to the schedule and cost. Once all of the functional requirements are identified and mapped to the acceptance criteria, they then produce the road-map for the execution of the project.
This road-map is a document called the Requirements Specification Document. To ensure that it is not changed at random it should be placed under Configuration Management control. Through the course of a project, however, there are instances where this document does need to be modified. This would happen when some of the assumptions which were identified are found to be incorrect, it is discovered that some of the features and/or functions will not be possible under current schedule and budget or additional features and functions are found, which were not previously identified, that are needed to be successful.
There are a number of way to address this modification process, one of which is to form a Configuration Control Board (CCB). This CCB will review the proposed changes to any documents or other artifacts under the purview of Configuration Management. A future post will address the Configuration Management process and functions of a CCB.
[social_share style=”circle” align=”horizontal” heading_align=”inline” text=”” heading=”” facebook=”1″ twitter=”1″ google_plus=”1″ linkedin=”1″ pinterest=”1″ link=”” /]