August 12, 2008 | Author: PM Hut | Filed under: Requirements Management
Specific: a good requirement is specific and not generic. It should not be open to mis-interpretation when read by others. This is the most important attribute to get correct. Avoid using conjunctions (and, or, but) as they can confuse or misconstrue the meaning. Avoid indeterminate amounts of time (soon, fast, later, immediately) as they are open to wide mis-interpretation which results in dissatisfied customers.
- Weak Requirement: The report displays all the monthly data from the marketing department.
Why it is weak: Anytime you see all, always, never and other global adjectives, beware. What if the marketing dept adds more data; do you need to immediately update the report? What if “all the data” that you are aware of from marketing is different than what your customer (the report requester) perceives as “all the data”? Even if you and the customer agree, what about a third reader?
Strong Requirement: The report contains the following columns: Total Sales for Month, Average Retail Price, Total Units Sold, Remaining Inventory, Total Cost of Goods Sold.
It is appropriate and expected to list every column - it might be 100 of them, but list every one exactly. There should also be a subsequent requirement that lists what the column headers should be as well.
Jessica Popp is a practicing project manager in software engineering. She has more than 13 years experience in software development, project management and people leadership in both Fortune 500 and startup companies. She has a wealth of hands-on project experience from the smallest project to projects whose budgets exceeded $50M per year. Jessica holds a BBS in Information Systems, an MS in Decision Sciences and has a current PMP certification. Jessica runs Project Management 101, a blog dedicated to disccussing various topics about Project Management.
No comments yet.