-
Initiating Phase - Introduction
August 29, 2008
-
Balanced and Strong Matrix Authority - Resource Management
August 29, 2008
-
Estimating and Forecasting Biases in Projects - Part I
August 29, 2008
-
Plan Time for Process Improvement
August 29, 2008
-
Project Planning Process - The WBS
August 29, 2008
-
Risk Management Plan
August 28, 2008
-
13 Ways to Guarantee Project Failure - Part V
August 28, 2008
-
An Alternative to EVM: The Zone Method
August 28, 2008
-
Project Phases
August 28, 2008
-
Work Breakdown Structure Was Shallow - Project Management Mistake # 7
August 27, 2008
The Language and Layout of Requirements Specifications
April 9, 2008 | Author: admin | Filed under: Scope Management, Project Scope Management, Requirements Management
The Language and Layout of Requirements Specifications (#22 in the Hut A Project Management Primer)
By Nick Jenkins
Requirements specs. have multiple audiences. They are used by the project team to deliver the project, and they are used by stakeholders to verify what is being done. While I advocate including contextual information to illustrate why a particular decision was taken there needs to be some way of easily separating the discussion from the “assertions”.
So I apply the following rules of thumb:
- For each requirement there should be an “assertion”; in essence, a decision
- Where assertions are documented they should consist of a single sentence which states what a product “must” or “should” do.
- “Must” indicates a necessary requirement / “should” indicates a “nice-to-have”.
- There must be simple (visual) way to distinguish assertion from discussion.
Below is an example with some discussion and the assertion highlighted with italics:
- 1.1 Usability – usability of the system is seen as very important to adoption of the system. The client raised some concerns about the time scales required to implement usability testing but the project team as a whole supported extending the time line for the development phase to include usability testing..The system must be simple and easy to use and must follow the standard UI style as laid out in the company design handbook.
In this case the discussion is preserved for future reference but the requirement stands out distinctly from the body of the text. A project member reading the specification can skip through it and pull out the requirements quickly and easily. A manager reading through the document can do the same but also can review the context of the decision to understand how it came about.
Sometimes classification of requirements is made using the MoSCoW rules:
- Must-haves are fundamental to the project’s success
- Should-haves are important, but the project’s success does not rely on these
- Could-haves can easily be left out without impacting on the project
- Won’t-have-this-time-round can be left out this time and done at a later date
I feel that the distinction between “should have” and “could have” is never clear and is usually the subject of much debate between client and project manager so I normally omit “could have”. Every requirement then either becomes necessary (“must have”) or optional (“should have”).
Next in the Hut A Project Management Primer:
A Project Management Primer - Scope - Documenting Requirements - Diagrammatic Methods
Previously in the Hut A Project Management Primer:
A Project Management Primer - Scope - Documenting Requirements - SMART requirements
Nick Jenkins is an IT manager with 10 years experience in software development, project management and software testing. He’s worked in various fields of IT development in Australia, Britain and the USA and occasionally he learned something along the way. Now he lives on the banks of the Swan River in Perth, Western Australia, and he publishes the odd guide to help aspiring IT professionals. Nick’s website can be found at www.nickjenkins.net.
Related Articles
- 3 tips to improve requirements management
- Kano Model and Classifying Requirements
- Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part I - Introduction
- Requirements Defined = Internal Focus
- Successfully Interviewing Your Project Customer and Gathering Project Requirements - Part IV - Customer Interview Funnel
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Management Advantages
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
1 person has left a comment
[…] The Language and Layout of Requirements Specifications […]