Many software teams struggle with the process of identifying and defining requirements.  Independent of the development process they practice (e.g. Agile, RUP, Waterfall, SCRUM or MSF), correctly capturing, specifying  and maintaining stakeholder requirements throughout a project’s lifecycle remains the single most important task to ensure customer satisfaction.

Towards this goal, it is important to understand the structure of a good requirement both from a linguistic perspective as well as its relationship to the hierarchy that includes needs and features.  In this series on Clarifying Requirements, I’ll expose this relationship as well as cover some of the basic linguistic characteristics of a good requirement.

User Needs

At the heard of any good requirement is the core user need – best illustrated by the the requirements pyramid and example below:

Figure 1: source:http://www.ibm.com

Restaurant Patron Example

A customer who enters a restaurant craving a steak may express this need to his or her waiter.  It is the waiter’s responsibility to identify this need, and match it to the customer’s budget, capabilities of the chef and the fresh produce of the day, among other things.   Suggesting a vegetarian dish to such a customer will almost certainly disappoint them.  There may also be be additional cravings that need to be elicited from this customer.   For example, a sommelier may get involved to find the perfect red wine to accompany with the steak.  The point here is that a single customer need (i.e. steak craving) leads to the discovery of an implicit need (i.e. accompanying wine) before the order was specified to the kitchen staff.

This customer order is loosely analogous to a good user requirement in the software world, where customer needs (i.e. steak craving, red wine), and the restaurant’s ‘features’ (dinner menu, patron’s budget, chef’s capabilities) led to the requirement for a grilled Black Angus steak served with sauteed broccoli rabe and a smooth, silky 1995 second-label Bordeaux on table 12.   Managing the status of this order throughout the patron’s dinner is the job of a waiter that will ultimately determine the level of satisfaction experienced by the customer.  Sure customers may not always know what they want but it’s the job of marketing, business and engineering to help them towards this understanding.

Equally important is identifying the right pool of user (i.e. stakeholders) from which to elicit these needs.  Marketing efforts that correctly identify a solution’s customer base will simplify the requirements process.   Also remember that customers are only a subset of this user group, albeit an important one.  Project sponsors, investors, operators, developers, testers, and regulators are just some of the other stakeholders that may need to be considered.

In part 2 to the series on Clarifying Requirements, we talk about features and their role in the requirements specification process.