A few weeks ago, we looked at Peer Reviews for Software Development LifeCycle projects. This week, we’re going to look at what you need to include when doing Peer Review for System Requirements Specifications.
Reviewing System Requirements Specifications
You can use the same free template we shared last time – email me if you don’t have it – but add the following fields to the checklist:
Enter Yes or No and then provide your comments below.
- Technical Mistakes – Does the System Requirements Specifications have any mistakes?
- Grammar Mistakes – Is the System Requirements Specification free of grammatical and spelling errors?
- Consistent – Is this System Requirements Specifications consistent with other Specifications?
- Use Cases – Are the use cases properly identified and documented?
- Operating System – Has the operating environment been investigated and documented?
- Constraints – Are design and implementation constraints clearly stated?
- Technical Documentation – Are requirements for user documentation, help screens, or tutorials documented?
- Assumptions – Are assumptions and dependencies stated?
- Features – Is the list of system features complete?
- Narratives – Does each feature have a narrative process description?
- Hardware – Are external hardware interfaces documented?
- User interfaces – Are user interfaces requirements identified?
- Non–functional – Are non-functional requirements documented?
Peer Reviews For Requirements Specifications
The key to make this work is to keep the checklist simple, practical and actionable. Then use the information to improve the Software Development LifeCycle so that all others aspects of the system are improved.
I’ve always had mixed feelings about peer reviews. What they’re done right, we all learn but like Lesson Learned review can easily degenerate into bitching sessions if not managed correctly.