Requirements are often touted as the foundation of a good software project. I agree that without good requirements, you will find it very difficult to build the right solution.

What, then, is the foundation for the requirements?

A clear problem statement is, in many cases, just as important as the requirements themselves. It serves as the base from which the features and requirements are built. With some systems, the problem is obvious and it is clear that the solution will add value. With most enterprise systems, however, the problems and benefits are not so clear.

In these muddy waters, you should stop and analyze your problem statements in detail. Eliciting these issues is sometimes easy (when everyone hates the software, for example), but finding out the pain points of the users and management often requires the same degree of facilitation used in requirements gathering.

For example, a company may know that their overall processing time for orders is too long. They may not, however, understand all of the individual problem statements that add up to that company-wide issue. Breaking this problem down into individual subcomponents for analysis and definition requires the exact same skill set used in solution analysis.

Several useful ‘buckets’ for problem analysis are:
– Effort (the amount of work required by your employees to accomplish a task)
– Duration (the amount of real elapsed time required to accomplish a task)
– Risk (the propensity for error involved in a task)

The results of such a problem analysis might appear as follows:

Effort
-E01: Order entry takes too much effort
-E02: Order fulfillment takes too much effort

Duration
-D01: Order entry takes too long
-D02: Order fulfillment takes too long

Risk
-R01: Order entry may be inaccurate

You would, of course, define what ‘too much effort’ and ‘too long’ mean for your system in measurable terms.

Once you have the problem defined at this level, you can more easily create features that address each of these low-level problem statements.

Feature 01 – Automatically populate shipping information based on customer’s ID number.
Feature 02 – Automated order fulfillment system.

You can then map these features back to the problem statements for traceability.

Feature 01 satisfies problem E01, D01, and R01.
Feature 02 satisfies problem E02 and D02.

With a clear definition of the problem in hand, writing the requirements for each of these features becomes much easier. You can understand the original intent of the feature and the issue it was addressing. This also allows you to trace back ROI when the software is complete to see if the solution really addressed the problem.