Author: Karl Wiegers

Karl Wiegers is Principal Consultant with Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of 14 books, including Software Requirements Essentials, Software Requirements, More About Software Requirements, Successful Business Analysis Consulting, Software Development Pearls, The Thoughtless Design of Everyday Things, and a forensic mystery novel titled The Reconstruction. Karl also has written many articles on software development, design, project management, chemistry, military history, and consulting, as well as 18 songs. You can reach him at ProcessImpact.com or KarlWiegers.com.

Open-Ended Questions

Written by Karl Wiegers on January 3, 2012. Posted in Articles.

The Business Analyst as Explorer, Part 5 of 6 by Karl Wiegers

An effective business analyst is not simply a scribe who records whatever customers say. The BA needs to stimulate the thinking of the people he’s interviewing to get below the surface. The BA should ask questions such as “What else could happen that we haven’t already discussed?” and “Would anyone ever want to ?” and “Could ever occur?” These are ways to discover possible lower-probability scenarios or options the system should provide to the user.

In their book Exploring Requirements: Quality Before Design, Donald Gause and Gerald Weinberg describe “context-free questions.” In their words, context-free questions “are high-level questions that can be posed early in a project to obtain information about global properties of the design problem and potential solutions. Context-free questions are completely appropriate for any product to be designed….” The BA can use such questions to explore both processes and products. They’re a valuable complement to specific questions about the capabilities and characteristics of the product being specified.

In my experience, requirements elicitation discussions typically emphasize the expected normal behavior of the system. However, anyone who has ever done any programming knows that a good developer writes a lot of code to deal with exception conditions. An important aspect of requirements elicitation is to identify things that could go wrong, determine how the system should detect an error, and describe how the system should respond to the error. As a BA, you need to probe around the exceptions during your requirements discussions. Ask questions such as “What should happen if ?” This is a way to detect missing requirements that haven’t come up in the discussion yet. It’s also a way to surface previously unstated assumptions. Testers are particularly adept at spotting exception conditions, so I like to have someone with testing experience participate in requirements elicitation sessions, if possible. I also engage a tester to review the emerging requirements documentation and look for exceptions and alternatives we haven’t considered.

Beware of asking questions that solicit a yes/no or multiple-choice type of response. Such questions can unnecessarily constrain the answer so that the requirements discussion misses an opportunity to discover (or invent) something that goes beyond the BA’s preconceptions. Of course, this doesn’t mean you can’t ever ask a question with a closed list of possible responses. Just make sure you aren’t prematurely constraining the exploration.

The last question I typically ask in a requirements elicitation discussion is, “Is there anything else I should be asking you?” This is an example of a metaquestion, a question about a question. I freely admit that I don’t know all the right questions to ask. Sometimes the person of whom I’ve asked this question realizes that we haven’t yet discussed some important topic. I simply didn’t know enough to bring it up.

I use this same question in daily life. A few years ago I had new kitchen counters installed in my house. I’d never done any home remodeling before and didn’t know that much about the process. Near the end of my discussion with a contractor, I asked, “Is there anything else I should be asking you about this job?” He thought for a moment and then brought up an issue we had not yet discussed. This is also a collaborative question to ask. It acknowledges that you rely on the expertise of other people to work toward a mutually satisfactory project outcome.

Business analysis is hard! Because it is intrinsically a communication-centric human activity, I don’t know of any shortcuts. Business participants in the requirements elicitation process can get frustrated by the number of questions the BA asks and how long the process can take. But that’s just the way it is. And it’s a whole lot cheaper and less painful to have those discussions before you’ve actually built the software.

Don’t forget to leave your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.

Questions for Eliciting User Requirements

Written by Karl Wiegers on December 6, 2011. Posted in Articles.

The Business Analyst as Explorer, Part 4 of 6 by Karl Wiegers

This article presents several sets of questions the business analyst might consider asking customer representatives during a discussion about user requirements. Don’t use these questions as a script to be followed by rote in an elicitation workshop. Instead, look for ways to build these sorts of questions into the natural flow of a requirements exploration.

What are some reasons why you or your colleagues would use the new product? These “reasons to use” could become candidates for use cases. They might identify business tasks or objectives that members of a particular user class might need to achieve from time to time.

What goals might you have in mind that this product could help you accomplish? Use cases normally are directed toward helping the user achieve a specific goal. The name of the use case indicates the goal the user has in mind: Print a Boarding Pass, Withdraw Cash, Submit an Employment Application, and so on.

What problems do you expect this product to solve for you? Understanding the problems and limitations the users perceive in their current environment helps the BA determine appropriate capabilities for the new system. This question also helps determine whether the end users’ objectives for the system align well with senior management’s objectives, as captured in the business requirements. If not, you need to iterate between the business requirements and user requirements to align expectations.

What external events are associated with the product? BAs sometimes use the term business event to describe the triggering condition that launches execution of a use case. Perhaps a help desk receives a phone call from a user who needs assistance. This external event triggers the help desk staffer to create a problem report ticket. In products such as real-time control systems, use cases aren’t a valuable technique for understanding user requirements. An alternative approach is to identify the external events the system must detect. Then describe the appropriate system response, which depends on the state the system is in at the time each event is detected.

Most requirements discussions focus on functionality. However, a product’s nonfunctional characteristics also have a great impact on how users feel about the product. Questions such as the ones that follow help the BA understand the user’s expectations about aspects of the product’s quality.

What words would you use to describe the product? Consider asking users to close their eyes and describe their vision of the future system. Listen to the words they use to describe the product. Nouns suggest objects the system must be able to manipulate (such as order, reservation, chemical, account balance, sensor). Verbs can indicate actions the user expects to be able to take or expects the system to take (such as place, create, revise, submit, receive, detect, measure, display). Adverbs convey the user’s thoughts about the product’s characteristics (for example, quickly, reliably, efficiently, flexibly, easily).

Are specific portions of the product more critical than others for performance, reliability, security, safety, availability, or other characteristics? You can never create a product that combines the maximum levels of all quality characteristics. Tradeoffs are necessary between properties such as usability and efficiency, integrity and usability, and integrity and interoperability. (See Chapter 12 of my book Software Requirements, 2nd Edition for more about tradeoffs.) Therefore, it’s important to understand which specific portions or aspects of the product have critical quality demands so that developers can optimize their designs to achieve those objectives.

Are there any constraints or rules to which the product must conform? Most products are subject to corporate policies, industry standards, government regulations, and computational algorithms. It’s essential to know about such business rules so the BA can specify functional requirements to enforce or comply with those rules. Look for subject matter experts within the organization who have current knowledge about the business rules.

How is the product you envision similar to the way you do business now? How should it be different? When automating current business processes or replacing an existing information system with a new one, it’s easy to inadvertently re-implement all the shortcomings of the current approaches. This is known as “repaving the cow paths.” It’s difficult for people to break from the mindset of their current ways of working and to envision something that’s really different and better. The BA should stimulate the thinking of the user representatives to rethink business rules and business processes to see what has changed—or what could change.

What aspects of the current product or business process do you want to retain? To replace? Customer acceptance of a new product depends partly on how familiar it feels to them. Similarity to previous products and processes reduces the learning curve, making it easier for users to master a new system and workflow.

The following questions help the BA gain a richer understanding of how potential users view the product. Asking these questions of people who represent different stakeholder groups can reveal conflicts that you’ll need to reconcile.

Which aspects of the product are most critical to creating business value? A user’s view of business value might be different from a manager’s view or an acquiring customer’s view. A user might value a more efficient way to perform a specific task that will save considerable time over many executions. A manager could be more impressed if the product has lower acquisition and support costs than the one it’s replacing.

What aspect of the product will be most valuable to you? Least valuable? No project can deliver everything to everybody on day one. Someone needs to determine the implementation sequence for various capabilities. Ask this question of different user representatives, and look for patterns that indicate certain product capabilities are more important and more urgent than others. Those capabilities should have top priority.

What is most important to you about the product? This deliberately vague question could generate responses dealing either with the product itself or with other aspects of the project. One user might say, “It’s most important that this system be available before the beginning of the next fiscal year.” Another might respond, “It’s most important that this system will let me import all my data from these older systems we’ve been using.” A manager might say, “It’s most important that the people in my department can get up to speed on this new system without training.” These responses have implications for how the project is planned, the functionality to include, and usability, respectively.

How would you judge whether the product is a success? A business manager might judge the success of the product quite differently from how members of various user classes determine success. Surface these different perspectives early so that they can be reconciled to keep all stakeholders working toward a common objective.

Can you describe the environment in which the product will be used? The operating environment has a big impact on both requirements and design decisions. The user interface is also highly sensitive to the operating environment. Touch screen displays are superior to keyboards in some settings, for example, and speech recognition is becoming increasingly effective for certain applications.

The more the BA can learn about how users intend to employ the product, the better she can do at determining and specifying the functionality that developers need to implement. When you get right down to it, users don’t really care about product features; they care about getting their job done efficiently and maybe even enjoyably.

Don’t forget to leave your comments below.

User Requirements and Use Cases

Written by Karl Wiegers on November 8, 2011. Posted in Articles.

The Business Analyst as Explorer, Part 3 of 6 by Karl Wiegers

The business requirements will help the business analyst identify potential user classes for the product. The objective of exploring user requirements is to understand what members of these user classes expect to be able to do with the product and how the product will let them achieve specific goals. The user requirements must align with the higher-level business goals captured in the business requirements.

Some user goals might pertain to tasks the users must perform; use cases often are an effective way to record these tasks. Other user goals, though, might indicate the importance of specific nonfunctional requirements. Examples include the ability to complete a task within a certain length of time, and the ability to access a system remotely from a smart phone. Therefore, user requirements also encompass the users’ expectations about performance, availability, usability, reliability, and other quality attributes.

It’s also important to surface pertinent business rules, design and implementation constraints, and assumptions the various stakeholders might be making. The objective is for the BA to understand what customers are envisioning so he can record both functional and nonfunctional requirements that will guide the development team’s work. Furthermore, documented requirements and user acceptance criteria will help testers determine whether the delivered product satisfies its requirements.

When eliciting user requirements, the BA typically works with a number of key users who represent specific user classes. The BA needs to ask questions that will help those users describe the goals they want to accomplish with the help of the system. For most types of software projects, this is far more valuable than the traditional focus of requirements discussions on system features and functions. The emphasis on user tasks or goals is the essence of the use case approach to requirements elicitation. Scenarios and stories also emphasize a usage-centric perspective to requirements elicitation.

Instead of asking, “What do you want?” or even “What do you want the system to do?” an approach based on usage and user goals asks, “What do you need to do with the product?” Your users might not be accustomed to a dialogue of this nature. It can be difficult to shift their thinking from the traditional focus on the system itself, so some education of your user representatives is in order. It’s not realistic to think you can simply ask the users what their use cases are and get a meaningful response. Even if you explain what use cases are, don’t expect users to hand you a tidy, precise, and complete list of their use cases. The BA must work with the input that users provide to determine the real goals they have in mind.

I sometimes use the example of an airline flight reservation kiosk when describing use cases in my training seminars. Instead of just asking the class what their use cases would be for such a product, I ask, “What are some things you would imagine doing with an airline flight reservation kiosk?” A variant question is, “What are some reasons you would want to use an airline flight reservation kiosk?” During the class discussion, some of the responses are indeed candidates for use cases, although they still need to pass through a filter that asks “Is this in scope?” before we determine that they belong in the system we’re exploring. These use cases include:

Find Available Flights for an Itinerary
Make a Flight Reservation
Select Seats
Print an Itinerary
Change a Reservation
Cancel a Reservation
Check on Flight Status (This one might not be in scope because it requires real-time access to current flight information from the airlines. The business requirements should indicate whether this sort of capability will help us achieve our business objectives.)

Notice that all these use cases begin with a verb. This is a standard convention for naming use cases. The BAs should listen for responses from customers that do not begin with a verb and discuss the intent behind each such response. Once when I held this discussion in a class and asked, “What are some things you would imagine doing with an airline flight reservation kiosk?” one student simply said, “Weather.” This one-word response prompted me to explore exactly what aspect of weather the student had in mind, to find an appropriate verb. Did she want to create the weather, change the weather, or what? I learned that she wanted to check the weather forecast at the originating, destination, and connection cities for a specific flight itinerary. Hunting for the verb the customer has in mind is a way to discover the task or goal behind the initially presented input.

Just because a user provides a response that begins with a verb doesn’t mean that it’s actually a use case. Someone might suggest as a possible use case, “Enter my frequent-flier number.” A use case should describe a standalone task: A user has a specific goal in mind, walks up to the system, interacts with it in some way, and—if all goes well—achieves the goal and walks away happy. However, no one would ever walk up to this kiosk, enter his frequent-flier number, and feel fulfilled. I needed a follow-up discussion to determine what the user was really trying to accomplish by entering a frequent-flier number. Some possibilities are:

See how many miles he has accrued.
Purchase a ticket using frequent-flier miles.
Purchase a seat upgrade using frequent-flier miles.
See if he has received mileage credit from a previous flight, car rental, or hotel stay.
Recall his stored profile so that he doesn’t have to reenter a lot of information when making a reservation.

The first four of these items are use cases, something a user might do as a standalone task. The last one, though, doesn’t represent a discrete task. It’s likely part of some other use case, such as Make a Flight Reservation. The main point here is that the BA must expect to work with users to determine whether a piece of presented input is a user task, a bit of system functionality, a quality attribute, a constraint, a business rule, extraneous information, or something else.

(adapted from More about Software Requirements by Karl Wiegers)

Don’t forget to leave your comments below.

Eliciting Business Requirements

Written by Karl Wiegers on October 11, 2011. Posted in Articles.

The Business Analyst as Explorer, Part 2 of 6 by Karl Wiegers

We explore business requirements to gain a shared understanding of the business opportunity being created or exploited, the organization’s business objectives, success criteria, product vision, and project scope boundaries. Business requirements answer the question, “Why are we undertaking this project?”

The project manager has a strong interest in determining the business requirements. Perhaps the first question the project manager and the business analysis must assess for a proposed requirement is whether it’s in scope for the overall project. It’s impossible to make this judgment until the scope has been determined based on the business objectives. If a proposed requirement is out of scope, the PM and BA don’t need to think it about any more. (However, you don’t want to lose sight of the fact that someone once proposed that requirement, because it might come back into scope in the future.) If the requirement is in scope for the project, though, the PM will need to allocate it to a specific release or iteration. These sets of allocated requirements determine the scope for each planned iteration.

If some new requirement request for a particular iteration comes along later, as it inevitably will, the PM must evaluate that requirement’s priority against the backlog of work already allocated to that iteration. Do you defer that new requirement to a later iteration, bump a lower priority allocated requirement to a later iteration, or consciously increase the scope of the iteration by adding the new requirement to it? You can’t just keep cramming more functionality into a planned iteration and expect to get it done on the original schedule. Serious, ongoing prioritization is essential to effective scope management, and it demands clearly defined business requirements. This process requires collaboration between the BA, the PM, and appropriate customer representatives.

Sources of business requirements include senior managers, marketing managers, funding sponsors, product visionaries, and others who know the rationale and business drivers for the project. Such folks might already have established their business requirements, perhaps in a project charter or a business case document. In other situations, though, it can be helpful to have a skilled BA work with the right people to elicit this vital knowledge. Following are some questions to consider asking if you’re a BA working with the holders of the business requirements.

What business problem are you trying to solve? This helps align subsequent requirements development and software development activities with the right objectives.

What’s the motivation for solving this problem? Team members work together more effectively and more enthusiastically if they understand the rationale behind their work.

What would a highly successful solution do for you? Management should be able to state the benefits they and their customers will receive from the product.

How can we judge the success of the solution? People often don’t think about how they will determine whether some enterprise has been successful. Contemplating this evaluation early on helps crystallize the stakeholders’ thinking about objectives and steers the project toward a clearly successful outcome. Project success criteria are the subject of Chapter 4 of my book Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007).

What’s a successful solution worth? Whenever possible, quantify the business outcomes. All projects involve some cost–benefit analysis. Understanding the potential return in meaningful units helps participants make cost-effective decisions.

Who are the individuals or groups that could influence this project or be influenced by it? This question seeks to identify potential stakeholders in the project. The BA might need to consult these stakeholders to understand their interests in the project, their expectations, and the nature of their involvement. Stakeholders could be internal to the project, internal to the organization, or external to the organization. And you can bet that your stakeholders will have conflicting objectives, requirements, and priorities.

Are there any related projects or systems that could influence this one or that this project could affect? Look for dependencies between projects and systems that need to be analyzed and accommodated. Sometimes apparently small changes can have vast ripple effects across multiple interconnected systems.

Which business activities and events should be included in the solution? Which should not? These questions help define the scope boundary. Modifying the established project scope is a business decision that has implications for cost, schedule, resources, quality, and tradeoff decisions.

Can you think of any unexpected or adverse consequences that the new system could cause? Consider whether certain individuals, organizations, customers, or business processes could experience a negative impact from the system or product being developed. For example, a new information system that automates a process that has been performed manually in the past could threaten the job stability of the people who perform that process. Employees might need retraining, or their job descriptions could change, both of which could lead to resistance to the project and unwillingness to cooperate.

As you gain experience with these sorts of dialogues, you’ll build a set of your own questions that you find helpful to pull out the key information. You might write those kinds of questions down on index cards. When you find that an elicitation discussion is stalling out or nearing an end, randomly pull out one of those cards and see if the question on it has already been addressed. If not, the question just might help you surface another tidbit of knowledge that will help you plan the project and keep it on track.

Don’t forget to leave your comments below.

(adapted from More about Software Requirements by Karl Wiegers)

An Inquiry, Not an Inquisition

Written by Karl Wiegers on September 27, 2011. Posted in Articles.

The Business Analyst as Explorer, Part 1 of 6 by Karl Wiegers

Many years ago, my manager, Jerry, sat in on a discussion I had with a customer named Steve to explore his requirements for a new application. After the meeting, Jerry pointed out that I had been rather aggressive in my questioning of Steve. He was right. I hadn’t realized how hard I’d been pressing Steve to make up his mind on certain points and tell me exactly what he wanted. Fortunately, when I contacted Steve to apologize, it was clear that he wasn’t offended. Nonetheless, our discussion probably felt like an inquisition to Steve, rather than an inquiry into what he was asking us to build. Not the best strategy for a business analyst to take.

Another extreme approach to requirements elicitation is for the BA simply to record whatever the customer says and pass that information on to the developers. This doesn’t work very well, either. As with most things in life, the appropriate behavior lies in between the possible extremes.

Requirements elicitation is a process of exploration and discovery, not just collection (which is why I don’t talk about “gathering requirements”), and the BA is the guide. BAs need to recognize that customers won’t be able to present all their requirements in a single workshop or discussion. They probably don’t even know what their real requirements are yet. Elicitation requires multiple cycles of refinement, clarification, and adjustment as the participants move back and forth between high-level concepts and specific details.

But First, Some Questions to Avoid

The worst question you can ask during a requirements discussion is “What do you want?” The second-worst question is “What are your requirements?” No one knows quite how to answer these questions. Customers and other elicitation participants might not share the BA’s understanding of what the word “requirement” even means. When customers attempt to answer these questions in good faith, they typically generate a large number of random—yet important—thoughts.

I’ve observed this in some of my training classes, in which small groups of students conduct a practice requirements elicitation workshop on a sample project called the Cafeteria Ordering System. The groups are trying to learn how to employ use cases to explore user requirements. One member of each group plays the role of a user who would employ this system to order meals. Some groups begin by asking this student, “What do you want?” because this is how they’re accustomed to launching requirements discussions. They typically get responses such as:

I need to be able to pay by either credit card or payroll deduction.
I want to be able to order group meals for lunch meetings.
The system has to be available from home as well as from work.
I’ll have to submit delivery instructions for my meals.
I shouldn’t have to pay any delivery charges.
Can contractors order meals or just employees?
I want to be able to order meals at least a week in advance.
It would be nice if I could easily reorder the same meal I ordered sometime in the past.
Could I get nutrition information for a whole meal?

These are unquestionably important thoughts and ideas. However, when asked “What do you want?” the workshop participants tend to spew out these thoughts in a random sequence with no organizing structure. This makes it hard for both the BA and the customers to know what the information means, what to do with it, where to store it, and what to discuss next. The student groups who take this approach invariably flounder in the sea of random input. In contrast, those groups that grasp the use case approach early on make much faster progress. An important BA skill is to structure the dialogue and ask questions that will guide elicitation participants through progressive layers of refinement in an organized fashion.

The BA should remember his role as a neutral facilitator. We all filter what we hear through our own biases, preferences, experiences, and hot button issues. Avoid asking leading questions that steer customers to agree with your own intentions. Also avoid overruling a customer’s idea just because it doesn’t agree with your own point of view. I once observed a 60-participant “voice-of-the-customer” workshop that one of my consulting clients conducted to explore requirements for a major new product. The workshop facilitator was the senior manager responsible for the product. He had strong opinions about the project’s direction and didn’t hesitate to steer the discussion toward his predetermined outcomes. This is discouraging for participants, who will feel that they’re wasting their time if the facilitator already knows what the answers will be.

In the next installment in this series, I’ll explore some questions that are helpful for eliciting business requirements. These requirements define the organization’s business objectives for undertaking the project, define the product vision, and enable scope definition and management.

This series of articles describes some questions a BA might consider asking during elicitation discussions—as well as some to avoid. The articles are adapted from my book More about Software Requirements: Thorny Issues and Practical Advice (Microsoft Press, 2006). A classic resource of good questions for discussing requirements for any type of project is Exploring Requirements: Quality Before Design by Donald Gause and Gerald Weinberg (Dorset House, 1989). Roxanne Miller also suggests hundreds of questions to help the BA with requirements elicitation in her book The Quest for Software Requirements (MavenMark Books, 2009).

Don’t forget to leave your comments below.