6 More Important Requirements Practices

These practices add value to any software or systems project. Neglect them at your peril.

A recent article described the six most important requirements practices that every software and systems development team should perform, regardless of the type of product they’re building or the development approach they’re taking. They are:

• Practice #1: Define business objectives

• Practice #2: Understand what users need to do with the solution

• Practice #3: Prioritize the requirements

• Practice #4: Elicit and evaluate quality attributes

• Practice #5: Review the requirements

• Practice #6: Manage changes to requirements effectively

Of course, those aren’t the only things a business analyst needs to do to help guide a project to success. Here are six more practices that, again, virtually every project will find valuable. These are adapted from our book, Software Requirements Essentials: Core Practices for Successful Business Analysis.

Do you have to do them? Of course not—that’s your choice. The requirements police won’t hunt you down if you don’t. But if you know of any projects that won’t find at least five of them valuable, please let us know. We’ll notify the Guinness World Records people.

Practice #7: Understand the problem before converging on a solution.

     Far too often, teams build and release requirements, features, and even entire products that go unused because those teams didn’t fully understand the business situation and the problems they were trying to solve. Understanding the problems or opportunities that your solution will address aligns all participants on the key issues.

     A business problem is any issue that prevents the business from achieving its goals or exploiting an opportunity. Organizations launch projects to solve business problems. However, those problems or opportunities often are neither explicitly stated nor documented.

     The key to solving the real problem is to avoid presuming that either a presented problem or a presented solution is necessarily correct. Presented with a problem, perform a root cause analysis, working backward to identify the underlying problems and the factors that contribute to them. Then you can derive possible solutions to address those factors. If you’re presented with a solution, ask, “If <solution> is the answer, then what was the question?” You might discover that the underlying issue demands a different approach, which could be simpler, more complex, more specific, or more general. You won’t know until you perform the analysis.

     A root cause analysis, or fishbone, diagram is a way to show the analysis results, as shown in Figure 1. The problem goes at the head of the “fish.” Place the highest-level causes in the boxes on diagonal lines coming off the fish’s backbone. Add contributing causes on the short horizontal lines from each diagonal. Continue the exploration until you reach the ultimate, actionable root causes.

Figure 1. A root cause analysis (fishbone) diagram example shows factors that contribute to the stated problem.

When the key stakeholders have agreed upon a clear understanding of the core business concerns, consider writing a problem statement using this template:

Situation. Describe the background, context, and environment.

Problem. Describe the business problems or opportunities as you now understand them.

Implication. Describe the likely results if the problem isn’t solved.

Benefit. State the business value of solving the problem.

Vision. Describe what the desired future state would look like.

Practice #8: Identify and characterize stakeholders.

Every project has stakeholders, individuals or groups that are actively involved in a project, are affected by it, or can influence its direction. Some stakeholders are customers, and some customers are users. Users can be grouped into multiple user classes that have largely distinct needs. Overlooked stakeholders can lead to requirements gaps or surprise constraints that are disruptive when they’re finally discovered. When you go looking for stakeholders, consider questions like these:

• Who has influence or control over the project’s budget and schedule?

• Who can articulate the project’s business objectives?

• Who will be using the product directly? Indirectly?

• Who is responsible for other systems or projects that ours will affect?

• Who could have legal, compliance, or regulatory influence?

• Whose business processes would the system affect?

• Who would know about any project, process, or product constraints?

Record enough information about each stakeholder group so that everyone understands them. Consider these questions:

• Who and where are they?

• How much power or influence do they have over the project?

• What are their interests and concerns?

• What benefits do they wish to receive from the product?

• What information can they provide?

• What do they need to know about the project?

• Who can work with the team to represent the interests of each stakeholder group?

The time you spend on stakeholder analysis helps ensure that you engage the right participants in a collaborative effort that builds a solid base for project success.

Practice #9: Identify events and responses.

A requirements elicitation technique that’s useful for many business applications but particularly effective for real-time systems is to identify the events that a business, or a software system, could receive. Each event triggers some behavior in response. Figure 2 shows three types of events: business, signal, and temporal.

Figure 2. Businesses and systems must respond to several types of events.

A business event originates from the outside world and crosses the boundary into the business domain. As part of generating the response to the business event, a user inside the domain may invoke a software system by initiating one or more use cases. Signal events originate from a hardware device or arrive as messages from a communications channel. Temporal events trigger the system to perform some action at a predetermined time or when a specific duration has passed since a previous event or condition.

An event-response table lists possible events and the expected response based on the system’s state when it detects the event. Table 1 shows a small fragment of an event-response table for a home alarm system. Such a table doesn’t show all the necessary details, though; you still need written requirements for that. Event analysis also aids test planning and release scoping.

Table 1. A fragment of an event-response table for a home alarm system

Practice #10: Analyze requirements and requirement sets.

Analysis sounds like one of those things that just kind of happens through staring at requirements long enough. In reality, we can use several techniques to search for specific issues and produce better requirements—and better solutions. Requirements analysis is where the business analyst really adds value. Some analysis activities apply to individual requirements, others to sets of requirements, as Table 2 shows.

Table 2. Some analysis techniques for individual requirements and sets of requirements

Practice #11: Organize requirements in a structured fashion.

Human memories are imperfect and incomplete. They fade and distort over time, and other people can’t access them. Consequently, a software team should record its requirements information to serve as a persistent group memory. Requirements can be recorded in documents, spreadsheets, databases, requirements management tools, wikis, or sticky notes on a wall. Requirements specification methods vary in content, structure, form, detail, and formality.

Whichever structure you choose, you need to store various pieces of knowledge about each type of requirement information you deal with. Select standard templates that your organization finds effective to organize their project requirements. Templates provide slots to hold various pieces of information so requirement writers know where to put it and readers know where to find it. A structured template serves as a checklist, a reminder to avoid overlooking some topic.

When initiating a new project, consider the best way to organize, store, and communicate your requirements. The storage format should be easy to modify as requirements evolve. The structure should let you define various requirements attributes that provide a richer understanding of each item. An effective alternative to writing requirements documents is to store the requirements in a database. Dozens of requirements management tools are available. Remember, though—they won’t help you identify stakeholders, ask the right questions, or write good requirements.

An unorganized collection with diverse requirements information all mixed together isn’t a requirements specification; it’s just a pile of information. Good luck with that.

Practice # 12: Identify and document business rules.

Business rules are statements that define certain aspects of the business or influence the behaviors of people and software systems within the business. Common sources of business rules include corporate policies, laws, regulations, and industry standards. A store might have these policies regarding refunds for customer returns:

RET-1. The customer must present a receipt to obtain a refund on a returned product.

RET-2. Only store credit may be issued for products purchased more than 30 days prior to being returned.

RET-3. Refunds may not be issued for products purchased more than 90 days prior to being returned.

Business rules have an existence and applicability beyond the scope of any particular software application. They often serve as the origin of functionality and data needed to ensure that a software system complies with the rule.

During requirements elicitation, the business analyst should actively listen for possible business rules. If someone uses restrictive words like only, must, may, or may not, they might have a business rule in mind. Business rules can be documented in text, in the database of a rules engine, or in structured formats such as decision tables.

Applying these six practices on your project, along with the six we described in the earlier article, won’t ensure success. However, they will give you better results and fewer headaches.

Author: Karl Wiegers and Candase Hokanson

This article is adapted from Software Requirements Essentials:Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson. Karl is the Principal Consultant at Process Impact. He’s the author of numerous books on software development and other topics, including Software Requirements (with Joy Beatty), Software Development Pearls, and The Thoughtless Design of Everyday Things. Candase is a Business Architect at ArgonDigital. She has written numerous articles on best practices in requirements management and agile product ownership.