Abstraction

Yesterday’s rather lengthy post on requirements writing is driven by some basic principles that I think are important. These were implied in the entry, but I thought it would be helpful to make them explicit.

• First, I believe that the requirements definition process should be collaborative, open to everyone, and written by beginning at a high level overview and moving to the nuts and bolts details through a series of iterations. Dare I say this is a kind of Agile style of product definition?
• A product steering committee should exist (sometimes called a product council). In yesterday’s post I was referring to the product steering committee for the first, high level, review of the product requirements. The PSC is made up of senior stakeholders in the organization and is responsible for the overall strategic direction of the product (it’s also a key component of my philosophy of collaboration).
• Requirements should be defined using many different techniques working together. Detailed prototypes (working is better than paper), essay-style descriptions, use cases, and traditional “the product shall…” requirements should all be used. Depending on the product, one technique will probably be emphasized over the others.
• Requirements should be maintained in an online format available for anyone to see. There are lots of ways to do this (commercial software, wikis, trackers, blogs, etc.). I have my favorite (alluded to ad nauseam elsewhere).
• Requirement definition has a finite time line. You can’t succeed by arguing endlessly about a requirement, and it is very easy to fall into this trap (By the way, did you ever notice that the first 10% of requirements in a review get 90% of the time, with the remaining requirements getting rushed through as people get tired? Put really important requirements toward the end if you want to improve the odds of avoiding an argument about them) . They must be a well understood deadline, after which requirements are “frozen.” “Frozen” means that any changes to the requirement must be conducted through a change control process.
• Finally, and this isn’t mentioned or implied in my previous post, but it’s important: the test cases built for QA must map to the requirements. Product management is responsible for making sure that this happens (because, believe me, no one else will bother). If a feature, failure scenario, or edge case behavior isn’t part of the test case, there is high risk that it won’t be in the product, either.