- Read Tutorial
This will be a quick module, however I think it's important to take the requirement document creation process seriously and I've discovered that going in small intervals works best when I'm learning new techniques.
Key Stakeholders
The list of key stakeholders will be a table that lists out each of the project owners. In order for a project to be successful it needs to have a clearly defined team. I've seen too many projects where individuals slide in and out of the team, which results in no one taking responsibility for issues when they arise and ultimately can lead to a product's failure.
This list should include, but isn't limited to the following:
The team member's name
The team member's role in the project - this doesn't mean their title, there are times when I'm a project manager even though my official title in the company is developer
The team member's preferred form of contact - everyone had a different preference when it comes to being contacted. For example, I hate when someone calls me on the phone, I've found phone calls take me about twice as long away from the work I'm doing, so my preference would be email or instant message
In the case that team members leave, or new ones are added, it's important to keep this portion of the document up to date.
Revision History
This portion of the document should include four elements:
The date of the revision
The description - this is the high level category of the revision, so if the change is that a new feature needs to be added, the value for this should be something like
Scope Change. This allows team members to quickly know what type of change has occurred. It also is helpful for tracking trends over the course of multiple projects. If I have a project manager who is consistently turning in projects filled with scope changes it could very well be that they need to be doing a more thorough job during the initial requirement's solicitation phase.The team member who made the change - it's also important to note that the revision should not be made to the document until the entire team has signed off on the change. In some cases this can mean keeping a formal sign off log where each team member needs to sign a piece of paper agreeing to the change. If you have done any development work you've probably already run into nasty project scope changes that can turn into clients wanting new features or changes that were never agreed; and this portion of the document can save a ton of headaches since it lists exactly every time a change was made from the original set of requirements. However this part is optional and typically is only needed when working for a large enterprise that has standardized development processes.