PMBOK Requirements documentation
As you collect your requirements, it is important to remember to document and organize them so it is easy to demonstrate that they are complete, as well as how the impact and interact with other requirements.
An important aspect regarding PMBOK requirements documentation is you need to consider how you’ll manage and control your requirements.
Depending on the type and complexity of your project, your requirements documentation can be relatively simple or very complex.
One way to keep requirements organized is to create a Requirements Register that documents all the requirements for the project and you can do this in a table or a spreadsheet for small projects.
For larger and more complex projects, software programs can help you organize, track, and manage requirements. A simple Requirements Register should as a minimum, include the following:
- Stakeholder name or position
- Requirement description
- Category or type of requirements
- Acceptance criteria
Requirements must be carefully focused and for that reason, it is important to use pre-existing documentation such as the scope, requirements and stakeholder management plans which have all been derived from the project charter.
You need to ensure that all of the correct stakeholders are involved in helping to identify, refine, and gain agreement that you have identified the full scope of the requirements.
Collect Requirement – Tools and Techniques
There are many tools and techniques which I strongly suggest you use to ensure your requirements are authentic and complete. These include:
Interviews. An obvious choice, and they should be done face to face whenever possible in order to gather a rich picture and to refine your understanding.
Group creativity techniques. Group decision making techniques .Much like brainstorming, when done in a group environment, collecting requirements becomes far easier and an important advantage is gained by including the thoughts comments and feedback of a group.
Observation. This could be observing users in their operational areas to help tease out and refine requirements.
Questionnaires and surveys. This can be a very efficient way to get the requirements, as you could use the mail or intranet facilities to help gather requirements.
Prototyping. Building a restricted functionality, or a simplified prototype, can identify requirements that would not otherwise be identified.
Facilitated workshops. My comments about group creativity, and group decision-making techniques also apply here.
Benchmarking. This is excellent in making sure that a common understanding of various aspects and elements of the solution are agreed by all, and contributes greatly to a consistent understanding prior to gathering requirements.
Focus groups. These have the same powerful advantage as ‘tiger teams’, and build a strong group of expertise and requirements and knowledge in a specific area.
Context diagrams. These help filter and refine the gathering of requirements.
Document analysis. Probably the most obvious, the use of existing documents often contain the major source of requirements.
Creating the requirement documents
Writing good requirements can be challenging, and so I have included the attributes of good requirements with the following:
Clear and unambiguous. Your goal is one, and only one way, to interpret the requirement. Having a quantitative or measurable statement will help.
Concise requirements. Ensure that there is only one requirement in each statement
Testable. Make sure you can prove a requirement has been met or not.
Consistent. Different requirements must not conflict. For example, you cannot have a requirement that person information is encrypted to protect privacy, yet another requirement that a person’s e-mail address is available
Complete. Ensure that all known requirements are documented
You will want to progressively elaborate your requirements, and so you will want to categorize them to maintain visibility and control.
Commonly use categories include the following:
- Size, weight, and appearance
- Environmental and interface
- Safety and security
- Business requirements
- Interface requirements
- Training and documentation
- Cost and schedule
Obviously, the nature of the product will determine your requirement categories, and the above are merely examples.
It is very important in your job, and for the exam, that all stakeholders agree to the requirements. You may want to get sign off or some other written form of agreement for the requirements to do this.
The diagram below, will help you to see the big picture with regard to the collection of requirements:
The requirements management plan
Any project manager will tell you that one of the most important reasons to project failure is lack of requirements management. This is a key contributor to scope creep.
Missing requirements, changes to requirements, and losing control of requirements all lead to failure in meeting project objectives, therefore you should establish a plan to manage them.
A Requirements Management Plan is really a strategy – showing how for this project, requirements will be identified and captured – including the use of methods and tools.
Some projects assign a requirements manager to control requirements. This individual oversees documenting, managing, tracking, controlling, and verifying requirements. In some organizations, a business analyst does this.
Your requirements management plan should describe the following:
- How you will operate your existing requirements if needed
- A method for documenting requirements
- How you’ll show that race ability
- Relationships among requirements and methods for verification
Your requirements management plan should also contain a section on configuration management, and they made directly assist the business analysis mentioned above.
The configuration management system should be able to carry out the following:
- Defined an identification system, such as a numbering system that allows for parent/child relationships
- The trace ability structure that tracks specified relationships
- Authority to add, delete, or change requirements
- A system to Audit and determine whether the process is being used and is effective
The PMP exam assumes that to collect and manage requirements effectively, you understand configuration management principles.
Requirements traceability matrix
Because requirements drive scope and because scope determines the should rule, costs, and everything else about the project, you should be able to tie your requirements to various aspects of the project.
A requirements traceability matrix can help you do that. For complex projects, you will need software that manages all the requirements and relationships for you. For simple projects, you can create a database of spreadsheet.
Here are some examples of what you will be tracing and tracking:
- How your requirements trace to a deliverable?
- How your requirements trace to an objective?
- How detailed requirements relates to high level requirements
- How technical requirements relate to business requirements
- Which verification and validation method will be used for a requirement?
- Which stakeholder provides the requirement?
Having this information documented and easily accessible will simplify the process of analyzing the impact of changes and help you understand the relationships between requirements.