Key Points
- Good requirements synthesize various inputs rather than just listing them.
- Rather than writing exhaustive requirements, consider the purpose of the requirements in order to focus them on your goals.
Most written requirements / use cases are limp, not getting to the essence of the goals. Why does this happen? Often, since tough decisions are not being made.
Requirements should be focused and targeted to meet your goals. Since it is probably more painful to make changes later in the process (for instance, after implementation has started), making the tough decisions needed for focused requirements should be a priority.
Of course, some readers may argue that traditional written requirements are less effective than a more iterative, generative agile approach. I also like the iterative approach, and in fact it can aid in decision-making (for example, since working code is something that all stakeholders can respond to during the process). That said, sometimes requirements written in advance are needed, for example when selecting a Content Management System.
Some Types of Unfocused Requirements
These are some of the types of requirements documents I've seen that show a lack of decision making:
Shock and Awe
Some requirements documents obscure the real purpose of a system since they are so "impressive". These may inspire comments like "Wow, that requirements document is 100 pages and I barely understand any of it! That must have taken a lot of work! You're so smart!". The main problem here is that if stakeholders cannot understand the requirements, then there cannot be true agreement on them. Although these may impress some, they still probably lack much strength since it's hard to see the point.
Listless
Ambling requirements are also common, and these often result from requirements being gathered rather than analyzed and synthesized. Ambling requirements may contain flashes of important requirements, but are buried along with unimportant requirements or even inconsistent requirements. Listless requirements may also be too detailed in places.
Overly Generic
Some requirements documents read like "car must have a driving wheel and four wheels" rather than "sports car primarily used to race on a racetrack on the weekends". One is certainly a fact but doesn't help in, for example, selecting a car. The second one shows a bit more of the flavor of the true requirement.
One requirements documents can have both of the problems listed above, but they can all be helped by better decision-making.
How to Tell if Your Requirements Are Unfocused and What to Do About It
How to know if you haven't made the decisions you need:
You resist efforts to prioritize your requirements.
You are excited about a possible capability, but have not written the related requirements since the relevant decisions haven't been made.
An outsider reads the requirements and does not understand overall what you are trying to accomplish.
How to make the decisions you need:
Define a compelling vision. In other words, big picture what are you trying to accomplish?
Make sure the requirements are synthesizing. People do not always know what they want, so everyone's input on the requirements should be synthesized into a coherent whole. A good way to see if the requirements are coherent is to ask someone uninvolved (but aware of the general area you are writing requirements for) understands them quickly.
Even though it is hard, prioritize your requirements. Many resist the concept of prioritizing requirements, since a requirement is a "must have". Of course you don't always get everything you want, but, moreover, you want to make sure that your highest-priority requirements are easy and straightforward in your implementation. Perhaps a lower-level requirement could be satisfied with a bit of a hack.
Consider the purpose of your requirements. If you are selecting a CMS, then really the only requirements that matter are those that will differentiate one product from another (based on your objectives). If you are handing off development in bulk to another team, then the requirements need to be more exhaustive. The general point is to concentrate on the requirements that matter for your current task at hand.