Monthly Archives: July 2008

Clarifying Requirements – Verification vs. Validation

In part 1 I discussed how user needs are the core of a good requirement.  The restaurant example  highlighted the key differences between needs, features and requirements.  In part 2 I showed how features, or the range of options and constraints across people, process and technology, will allow analysts and engineers to thread these needs through the requirements specification process.  In part 3, I’ll talk about the categories of a requirement, the difference between their validation and verification and conclude with a brief summary of the linguistic features behind a good requirement.

First, it is important to distinguish between user requirements and system requirements.  User requirements are typically written without any reference to a solution, technology or implementation approach.  Instead they are centered on the needs of the user in the problem domain, as well as the characteristics and context behind these needs.  For example, a requirement may incorporate elements from an overarching project vision statement.

System requirements, on the other hand,  contain references to technologies and solutions but ultimately should be written so that the functional behavior and non-functional characteristics of the solution are specified without describing how they should be implemented.  Use cases, for example are system requirements rooted in the solution domain that describe how the system is used and how it should behave and respond to user input.

Requirements Pyramid – http://www.ibm.com

System requirements can also be classified as functional or non-functional in nature.  This distinction is an ongoing source of much confusion.  Functional requirements describe the behavior of the system whereas non-functional requirements describe the characteristics of this behavior (click here for examples of non-functional requirements from our Agile on Wall Street presentation).   Indicating that a system should first authenticate a user’s credentials before allowing him to proceed to the reservation booking page is an example of a functional requirement.   Indicating that this process should take no longer than one second is an example of a non-functional requirement.

Verification vs. Validation

The differences between verification and validation in the software context are similar to those between efficiency and effectiveness in the business context. For our purposes, validation refers to ensuring the right needs are being met.  In part 1, I discussed the importance of correctly defining the user group from which needs will be elicited.   Successful software projects will prioritize the needs of this group so they can answer the validation question – Are we doing the right thing?

Verification, on the other hand, refers to the process of ensuring the correct implementation of these needs.  In other words, verification answers the question – Are we doing the thing right?

Any project that begins the software development phase with a validated set of requirements, and finishes the software deployment phase by verifying this set, is on the brink of satisfying customer demands.

Linguistic Characteristics

Quite simply, any stated requirement should satisfy the following criteria: the requirement should be written in such a way so that it is unambiguous, concise, and complete.

This concludes the series on Clarifying Requirements.  If you have any questions or comments on this article please email techdoer@gmail.com.

Tagged ,

Clarifying Requirements – Features

In part 1 I talked about stakeholder needs, both implicit and explicit and how these needs should be the core to any good requirement.   I also talked about the importance of correctly eliciting requirements from the right group of users.

Once the user needs have been identified, it is the responsibility of the project’s business and engineering teams to understand if and how they can capably solve them.   In our restaurant example, the patron who entered the restaurant craving a sizzling stake would be wasting his time in a Vegan restaurant.

The requirements pyramid below shows the relationship between needs, features, requirements and the boundary that separates them in the problem and solution domains.

Requirements Pyramid

Source: http://www.ibm.com

‘Features’, in this context, are better understood as the range of options and constraints across people, process and technology that may influence how the technical requirements are specified. The important part is to first understand and match the solution-agnostic needs with any solution-specific features that could help to satisfy these needs.

In part three of this series on Clarifying Requirements, I cover other important aspects of a good requirement.

Tagged ,

Clarifying Requirements – User Needs

Software teams struggle to identify requirements.  This is the case regardless of the software development process they practice.  The fact of the matter is that capturing, specifying  and maintaining stakeholder requirements throughout a project’s lifecycle remains the single most important task to ensure customer satisfaction.

In this series on Clarifying Requirements, I present the characteristics of a good requirement both from a linguistic perspective as well as its relationship to the hierarchy that includes needs and features.

User Needs

The key to specifying a good requirement is to first understand the needs that inspire it.  The relationship between needs and the requirements that capture them is illustrated in the figure below:

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

Restaurant Patron Example

A customer who enters a restaurant craving a steak will express this need to his waiter.  It is the waiter’s responsibility to register 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 this customer will almost certainly disappoint him.  There may be additional cravings to elicit from this customer.   For example, a sommelier may get involved to find a perfect red wine to accompany 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 fired off to the kitchen staff.

The customer’s order is loosely analogous to a good user requirement in the software world.  The needs (i.e. steak craving, red wine), and the restaurant’s ‘features’ (dinner menu, chef’s capabilities), as well as other constraints (i.e. patron’s budget), led to a 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 and this will ultimately determine the level of satisfaction experienced.  Sure, customers don’t always know what they need, but it’s the job of marketing, business and engineering to clarify this.

It is also important to identify the right pool of users from which to elicit these needs.  This is the job of marketing and one that will significantly improve the chances for project success.   Keep in mind that customers are only a subset of this group.  Project sponsors, investors, operators, developers, testers, and regulators are also stakeholders who  need to be included in the requirements elicitation process.

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

Tagged ,