Requirements & Requirements Management

Software Requirements: Classifying Customer Input, Part 1

By |

As you acquire requirements input from various sources, it comes in all stirred together. People don’t just tidily tell you, “Here are all my business rules, here are all my use cases” and so forth. Instead, the business analyst is bombarded with a more or less random array of information. Therefore, an important part of requirements elicitation and analysis is to capture that array of input, understand it, and begin classifying it into different categories so you can store the information in the most appropriate locations and use it effectively on the project.

Figure 1 illustrates nine common requirement categories you’re likely to encounter. You’ll hear other kinds of information too, of course, including a large amount of extraneous or explanatory information. Information that doesn’t fit into one of these nine buckets might be one of the following:

• A requirement not related to the software development, such as the need to train users on the new system. • A project constraint, such as a cost or schedule restriction (as opposed to the design or implementation constraints described in the second article in this series). • An assumption, which is a statement about the project we regard as being true in the absence of definitive knowledge that it is true. • A data requirement, which can often be associated with some system functionality (you store data in a computer only so that you can get it out again later). • Additional information of a historical, context-setting, or descriptive nature.

Figure 1. Classifying the voice of the customer.

The rest of this two-part series suggests some phrases to listen for that will help the BA struggle to make sense of the customer input and to classify it all accordingly.

Business Requirements. Anything that describes the financial, market, or other business benefit that either customers or the developing organization wish to gain from the product is a business requirement. Business requirements answer the question “Why are we working on this project?” I like to document business requirements in a vision and scope document or a project charter.

It’s best if you can quantify these business objectives. Instead of just saying “increase market share,” try to set specific targets so you can track towards those goals and take actions that you think will help achieve them. Because the people who provide the input perhaps aren’t accustomed to stating their business requirements so precisely, the BA will have to help them structure the initial input into high-quality requirements. Listen for statements about the value that buyers or users of the software will receive, such as these:

• “Increase market share by X%.” • “Save $Y per year on electricity now wasted by inefficient units.” • “Save $Z per year in maintenance costs that are consumed by legacy system W.”

Use Cases or Scenarios. General statements of user goals or business tasks that users need to perform are use cases; a single specific path through a use case is a usage scenario. Work with the customers to generalize specific scenarios into more abstract use cases. You can often glean use cases by asking users to describe their business workflow. Another way to discover use cases is to ask users to state the goals they have in mind when they sit down to work with the system. A user who says, “I need to“ is probably describing a use case, as in the following examples:

• “I need to print a mailing label for a package.” • “I need to manage a queue of chemical samples waiting to be analyzed.” • “I need to calibrate the pump controller.”

User stories, as used in the agile development world, sound a lot like use case goals. User stories often are phrased in the form: “As a, I want [to achieve some goal] so that [I can reap some benefit].” It’s the same idea as a use case, although you might opt to document the two in different levels of detail when you reach that point in the project.

Business Rules. When a customer says that only certain user classes can perform an activity under specific conditions, he might be describing a business rule. A sample business rule for a chemical tracking system might be, “A chemist may order a chemical on the Level 1 hazard list only if his hazardous-chemical training is current.” You might derive some software functional requirements to enforce the rules, such as making the training record database accessible to the chemical tracking system. As stated, though, business rules are not functional requirements. Following are some other phrases that suggest the user is describing a business rule:

• “Must comply with (some law or corporate policy).” • “Must conform to (some standard).” • “If (some condition is true), then (something happens).” • “Must be calculated according to (some formula).”

As you can see from the final example above, even though they’re called business rules, these might also encompass information that you would think of as being more technical, such as formulas for performing certain calculations.

Functional Requirements. Functional requirements describe the observable behaviors the system will exhibit under certain conditions and the actions the system will let users take. Functional requirements derived from system requirements, user requirements, business rules, and other sources make up the bulk of the typical software requirements specification. Here are some examples of functional requirements as you might hear them from users:

• “If the pressure in the tank exceeds 40 psi, the high-pressure warning light should come on.” • “The user must be able to sort the project list in forward and reverse alphabetical order.” • “The system sends an e-mail to the Idea Coordinator whenever someone submits a new idea.”

These statements illustrate how users typically present functional requirements, but they don’t necessarily represent good ways to write functional requirements. For instance, in the first case, we would replace should with shall to make it clear that illuminating the warning light is essential. We would also want to make sure that there isn’t some other way to indicate a high-pressure condition besides illuminating a warning light. The warning light might just be an idea or assumption on the part of the speaker, or it could represent a legitimate physical constraint. The second example is a requirement of the user, not of the system. The requirement of the system is to permit the user to do the sorting. You can’t expect your users to provide you with well-crafted functional requirements from the get-go. You’ll have to pick up on the idea they’re trying to communicate and, through dialogue, shape that into a focused and unambiguous requirement statement.

In the final part of this series I’ll describe some cues you can use to detect when you’re hearing information from a customer that could be classified as a quality attribute, external interface requirement, constraint, data definition, or solution idea.

Check out Software Requirements: Classifying Customer Input, Part 2.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

 

Latest posts by Karl Wiegers (see all)