Documenting the Project Requirements
This step is concerned with documenting stakeholder needs to meet project objectives. All requirements should be gathered at the start because it becomes more costly to make changes as the project progresses. Gathering requirements from all stakeholders will also ensure that their opinions are taken into consideration, which will lead to higher rates of project acceptance.
 |
The development of requirements should begin by analyzing information the project scope plan, requirements management plan, project charter and the stakeholder register. You can check out the complete range of project management pdf eBooks free from this website.
The important thing to note is that the needs and requirements of the customer and other key stakeholders need to be translated from high-level requirements to more detailed requirements that eventually will turn into the deliverables that comprise the work breakdown structure (WBS).
 |
There are various ways that the project requirements can be established including: interviews, workshops, group activities, questionnaires, user observation, and prototyping. All of these approaches involve meeting interested parties face-to-face to discuss requirements and deliverables. During these interactions you can use visual tools and diagrams that help others to identify particular deliverables. It also categorizes the latter showing the high-level relationships between these deliverables. This type of aid is often referred to as a 'deliverables diagram'. This makes it much easier for people to see these things quickly and will save you a lot of time describing them in words or trying to overcome misconceptions about how things are going to fit together.
Whether you are interviewing someone one-to-one or running a workshop or group event, you will need to plan exactly what is required from the participants. It is all too easy for these types of interactions to stray into areas that are not strictly within the bounds of the project or to get bogged down in areas of disagreement.
 |
Obviously, where there are significant differences of opinion then these will need to be resolved but it is vital that these meetings are kept 'on track' by a nominated chairperson or facilitator who has the authority to terminate discussions that are going nowhere and to keep the meetings as productive as possible.
If you would like to know more about taking charge of meetings and ensuring that they are as productive as possible then you should download our free 'Meeting Skills' eBooks from this website.
Questionnaires can be an effective way of getting information quickly because more people can be persuaded to find the time to complete a questionnaire than to attend a meeting. The results of a questionnaire can be compared to see if there is common ground between the different stakeholders and where this is the case it can save a lot of time in face-to-face meetings, which can then be used to discuss and agree areas of contention.
There are some industry specific questionnaires available online and you may be able to find one that you can modify and use for your own project. Obviously, if there are areas where there is general agreement about the scope of particular products or deliverables then these are candidates for utilizing project resources whilst other more controversial areas are still being discussed.
In an ideal world, the scope of the whole project would be agreed before any real work began but in reality you may find yourself in a situation where you are waiting for stakeholder meetings and you have people who are assigned to your project who are becoming frustrated at the lack of progress and are keen to get started producing something. Some members of the project team may become disillusioned if they cannot get on with productive work and you will need to balance this with your desire to do things 'by the book'.
Some types of project lend themselves to user observation and prototyping more than others. Software interfaces are a good example of those that do and could represent an opportunity to engage team members in useful work even in cases where the scope of some aspects of the project is still under discussion. User observation is particularly useful where stakeholders have been unable to articulate their requirements. Remember, not everyone is good at describing exactly what it is that they do in a way that can be easily understood by others. Assigning an experienced business analyst to shadow someone for a day or two will often produce far more usable and accurate documentation then asking that same person to document it themselves.
Prototyping aims to implement a working model of a project deliverable to see how well it fulfills its requirements. Prototyping can provide early feedback on suitability and provided that prototypes can be produced quickly enough this can be a very powerful tool that can highlight unforeseen problems that could otherwise prove expensive to remedy later on.
 |
This technique has most value when the prototype is given to the people who will actually be using the deliverable. This may sound obvious but in the real world deliverables are sometimes specified by supervisors or managers, people who have not actually 'done the job' for some time and may be out of touch with the day-to-day task the deliverable is designed to accomplish or facilitate.
 |
Requirements documentation describes how individual requirements meet the business need for the project. This consists of the following categories of requirements:
1. Business requirements
2. Stakeholder requirements
3. Solution requirements
4. Project requirements
5. Transition requirements
6. Requirements assumptions, dependencies, and constraints.
Requirements may start out at a high level and become progressively more detailed as more is known. Before being baselined, requirements must be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of a requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing executive summary, detailed descriptions, and attachments.
A requirements traceability matrix is a table that links requirements to their origin and traces them throughout the project life cycle. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives.
It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.
This process includes, but is not limited to tracing:
1. Requirements to business needs, opportunities, goals, and objectives
2. Requirements to project objectives
3. Requirements to WBS deliverables
4. Requirements to product design
5. Requirements to product development
6. Requirements to test strategy and test scenarios
7. High-level requirements to more detailed requirements
Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include:
• Unique identifier,
• Textual description of the requirement,
• Rationale for inclusion,
• Owner,
• Source,
• Priority,
• Version,
• Current status (such as active, cancelled, deferred, added, approved)
• Date completed.
Additional attributes to ensure that the requirement has met stakeholders' satisfaction may include stability, complexity, and acceptance criteria.
In summary, this step is about determining, documenting, and managing stakeholders needs and requirements to meet project objectives and stakeholders needs. The collecting requirements will ensure that the customer's needs are completely and fully understood. This process provides the basis for defining and managing the project scope including product scope.
You may also be interested in:
Project Scope Management | Scope Creep and Project Change Control | Planning How to Manage the Project Scope | Documenting the Project Requirements | Creating a Project Scope Statement | Creating the Work Breakdown Structure | Validating and Controlling Project Scope.
|
|
