When talking about requirements specification there are many factors to consider. 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, the characteristics and surrounding context for these needs, and may incorporate elements from an overarching 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 respond to user input.

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.

Once all user needs are identified and specified, it is the responsibility of the project’s business and engineering teams to understand how they can capably solve these needs.   In our restaurant example, the patron who entered the restaurant craving a sizzling stake would be wasting his time in a restaurant that only served raw food.

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

Source: http://www.ibm.com

The reference to features can better be understood as the range of options and constraints across people, process and technology that will influence the method and approach used to solve the problem.  Understanding and matching features with user needs will drive the requirement specification process.

Click here for part three to our series on Clarifying Requirements.

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 need, 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 also stakeholders whose needs will need to be considered during 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.

]]> http://techdoertimes.com/agile/clarifying-requirements-user-needs/feed 0