One of the main challenges in drafting requirements is to state “what” the solution must entail, and not “how” the solution must be tailored. I found the excerpt below from a paper authored by Ivy Hooks very helpful. The paper is available in its entirety here .
A specification was released for the development of a requirements management tool. The first requirement was to “provide a data base”. The statement is one of implementation and not of need, and it is common to find such statements in requirement specifications. Specifications should state WHAT is needed, not HOW it is to be provided. Yet this is a common mistake made by requirement writers. Most authors do not intend to state implementation; they simply do not know how to state the need correctly.
To avoid stating implementation, ask yourself WHY you need the requirement. In the example cited, it can be seen that by asking WHY, the author can define all of the needs that the system must meet and will then state the real requirements, e.g.:
- provide the capability for traceability between requirements
- provide the capability to add attributes to requirements
- provide the ability to sort requirements.
These requirements state WHAT is needed, not HOW to accomplish it. Each of the above listed requirements might result in a data base type of system, but the requirement for the database was not needed.
There are two major dangers in stating implementation. The one most often cited is that of forcing a design when not intended. If all the needs can be met without a database, then why state the need for a database. If they cannot be met, another, or better way, then a database will be the solution — whether or not there was a requirement for a database.
The second danger is more subtle and potentially much more detrimental. By stating implementation, the author may be lulled into believing that all requirements are covered. In fact, very important requirements may be missing, and the provider can deliver what was asked for and still not deliver what is wanted. Providing a database will not be sufficient for someone needing a requirements management tool. It is the capabilities of the tool that need to be stated as requirements.
To ensure that you have not stated implementation, ask yourself WHY you need the requirement. If this does not take you back to a real need statement, then you are probably stating a need and not implementation.
Excellent post. I cringe whenever someone responds to the question “What are you trying to do?” with “Well, I need an Access database. . .”
Asking the right questions can be very useful. What does success look like? How will this be used? etc. The ‘5 whys’ techniques of Lean are also a useful tool.