Skip to main content

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.

Classifying Customer Input, Part 2

Written by Karl Wiegers on . Posted in Articles. 1 Comment on Classifying Customer Input, Part 2

Feature BA May1 18897364 XSIn the first part of this two-part series I described some cues that help the business analyst detect when a customer has presented some input that could be classified as a business requirement, use case, business rule, or functional requirement. This article continues the discussion to help you classify customer input into several other categories of requirements knowledge.

Quality Attributes. Statements that indicate how well the system performs some behavior or lets the user take some action are quality attributes, also called quality factors, quality of service requirements, and sometimes simply nonfunctional requirements. Listen for words that describe desirable system characteristics: fast, easy, intuitive, user-friendly, robust, reliable, secure, and efficient. Chapter 12 of my book Software Requirements, 2nd Edition provides guidance on writing quality attributes.

You’ve probably been asked to build user-friendly software, but I’ll bet you’ve never been asked to build user-hostile or user-surly software. Everybody wants user-friendly software. However, it does you no good to write down a requirement that simply states, “The system shall be user-friendly” or robust, or intuitive, or any of these other good things. Those are not useful requirements because we don’t know just what they mean yet. But the customer has an important and legitimate idea behind each requirement, which you’ll need to suss out.

If you hear this sort of vague and fuzzy input, rather than just dismissing it as not useful, regard it as a clue to have a conversation about the statement. Ask the person who provided that input questions such as: “What does user-friendly mean to you? How would we know if this was user-friendly enough? Can you give me some examples of things that you consider as being user-friendly or not user-friendly?” As a BA, you’ll have to work with the users to understand precisely what they mean by these ambiguous and subjective terms so you can write clear, verifiable, and achievable quality goals.

External Interface Requirements. Requirements in this category describe the connections between your system and the rest of the universe. The SRS should include sections for interfaces to users, to hardware devices, and to other software systems, as necessary. Phrases that indicate that the customer is describing an external interface requirement might sound like the following:

  • “Must read signals from “
  • “Must send messages to “
  • “Must be able to read (or write) files in “
  • “Must control “
  • “User interface elements must conform to “

Constraints. Design and implementation constraints legitimately restrict the options available to the developer. Hardware devices having embedded software often must respect physical constraints such as size, weight, and interface connections. It’s a good idea to record the rationale behind each constraint so that all project participants know where it came from and respect its validity. Is it truly a restrictive limitation, as when a device must fit into an existing physical space? Or is it a desirable goal, such as a tablet computer that weighs as little as possible?

Unnecessary constraints inhibit creating the best solution. Excessive constraints also reduce your ability to use commercially-available components as part of the solution. A constraint that specifies that a particular technology be used poses the risk of making a requirement obsolete or unattainable because of changes in the available technologies. Certain constraints can help achieve quality attribute goals. An example is to improve portability by using only the standard commands of a programming language, not permitting vendor-specific extensions.

The following are examples of constraints that you might hear from a customer:

  • “Files submitted electronically may not exceed 10 MB in size.”
  • “The browser must use 128-bit encryption for all secure transactions.”
  • “The database must use the Framalam 10.2 run-time engine.”

Other phrases that suggest the speaker is describing a design or implementation constraint include these:

As with functional requirements, the analyst shouldn’t simply transcribe the user’s statement of a constraint into the SRS. Weak words such as identically and consistent need to be clarified and the real constraint stated precisely enough for developers to act on the information. Ask why the constraint exists, verify its validity (the constraint might be obsolete or based on an incorrect assumption), and document its rationale.

Data Definitions. Whenever customers describe the format, data type, allowed values, or default value for a data item or the composition of a complex business data structure, they’re presenting a data definition. “The ZIP code consists of five digits, followed by an optional hyphen and an optional four digits that default to 0000” is a data definition. Collect these in a data dictionary, a master reference that the team can use throughout the product’s development and maintenance. See Chapter 10 of Software Requirements, 2nd Edition for more about data dictionaries.

Data definitions sometimes lead to functional requirements that the user community did not request directly. What happens when a six-digit order number rolls over from 999999? Developers need to know how the system will handle such data issues. Deferring data-related problems just makes them harder to solve in the future; remember Y2K?.

Solution Ideas. Much of what users present as requirements fits in the category of solution ideas. Someone who describes a specific way to interact with the system to perform some action is presenting a suggested solution. The BA needs to probe below the surface of a solution idea to get to the real requirement. For instance, functional requirements that deal with passwords are just one of several possible solutions for an access control requirement.

Suppose you’re working on the requirements for a new point-of-sale system for a chain of stores that ship packages around the universe. Perhaps a user representative tells you, “Then I select the state where I want to send the package from a drop-down list.” The phrase from a drop-down list indicates that this is a solution idea. The user is envisioning a specific type of user interface control. The prudent BA will ask, “Why from a drop-down list?” If the user replies, “That just seemed like a good way to do it,” then the real functional requirement is something like, “The system shall permit the user to specify the state where he wants to send the package.” This statement gives the developer a lot of flexibility in choosing the most appropriate interaction mechanism.

However, maybe the user says, “I suggested a drop-down list because we do the same thing in several other places and I want it to be consistent. Also, it prevents the user from entering invalid data, and I thought we might be able to reuse some code.” These are fine reasons to specify a specific solution. Recognize, though, that embedding a solution idea in a requirement imposes a design constraint on that requirement. It limits the requirement to being implemented in only one way. This isn’t necessarily wrong or bad; just make sure the constraint is there for a good reason.

The thrust of these two articles is that you can’t expect your customers to present a succinct, complete, and well-organized list of their needs. Instead, they will present you with a wide variety of inputs, all of which seem important to them, and it’s up to you—the BA—to sort through what you hear to phrase it in a useful way and park it in a sensible location. That’s a big part of what requirements analysis is all about.

Don’t forget to leave your comments below.

Classifying Customer Input, Part 1

Written by Karl Wiegers on . Posted in Articles.

Feature Apr17 35919235 XSAs 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.Karl Fig1

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 so that .” 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 “
  • “Must conform to” “
  • “If , then “
  • “Must be calculated according to “

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.

Don’t forget to leave your comments below. 

The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

Written by Karl Wiegers on . Posted in Articles. 2 Comments on The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected.

The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than whyand means essentially the same thing, but it has a more collaborative feel to it.

When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information:

  • The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
  • Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is true. It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
  • Asking why can reveal implicit requirements that no one thought to mention yet.
  • The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
  • Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
  • Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
  • Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.

 

Asking why might save you a lot of work. One project was replacing an existing customer relationship management (CRM) system with a package solution. Senior management directed the team to use out-of-the-box features from the package as much as possible and to limit the extent of configuration or changes to the package. One user representative asked that a specific function be added, a counter that indicated how many times a customer had used a certain product feature. It would have cost a significant amount to modify the core package to accommodate this requirement.

 

When the BA asked why that function was needed, the user said that the function was present in the current CRM application. The BA probed further: “What exactly does this counter show?” “Why do you check it?” “What action do you take depending on what it tells you?” This discussion eventually revealed that several stakeholders all thought that someone else was using the data. In reality, no one used it at all! By asking “why” a few times, the BA and user representative agreed that the function wasn’t needed, thereby saving a significant amount of money.

A BA needs to be a bit of a skeptic. Don’t believe everything you hear, and don’t accept it all at face value. Ask “why” enough times to give you confidence that you’ve got the real requirements in hand.

(adapted from More about Software Requirements by Karl Wiegers)

Don’t forget to add 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. Karl produced this article for Enfocussolutions.

 

The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

Written by Karl Wiegers on . Posted in Articles.

(adapted from More about Software Requirements by Karl Wiegers)

“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected.

The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than why and means essentially the same thing, but it has a more collaborative feel to it.

When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information:

  • The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
  • Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is true. It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
  • Asking why can reveal implicit requirements that no one thought to mention yet.
  • The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
  • Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
  • Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
  • Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.

Asking why might save you a lot of work. One project was replacing an existing customer relationship management (CRM) system with a package solution. Senior management directed the team to use out-of-the-box features from the package as much as possible and to limit the extent of configuration or changes to the package. One user representative asked that a specific function be added, a counter that indicated how many times a customer had used a certain product feature. It would have cost a significant amount to modify the core package to accommodate this requirement.

When the BA asked why that function was needed, the user said that the function was present in the current CRM application. The BA probed further: “What exactly does this counter show?” “Why do you check it?” “What action do you take depending on what it tells you?” This discussion eventually revealed that several stakeholders all thought that someone else was using the data. In reality, no one used it at all! By asking “why” a few times, the BA and user representative agreed that the function wasn’t needed, thereby saving a significant amount of money.

A BA needs to be a bit of a skeptic. Don’t believe everything you hear, and don’t accept it all at face value. Ask “why” enough times to give you confidence that you’ve got the real requirements in hand.

Improving Your Requirements Processes

Written by Karl Wiegers on . Posted in Articles.

KW_Feature_Feb14Books on business analysis and requirements engineering, such as my own Software Requirements, describe dozens of “good practices” that can help any organization improve the way it develops and manages requirements for its products. Learning about the practices is one thing; implementing them and reaping the benefits is quite another. Putting better practices into action is the essence of software process improvement. In a nutshell, process improvement consists of using more of the approaches that work well for us and avoiding those that have given us headaches in the past. However, the path to improved performance is paved with false starts, resistance from those who are affected, and the frustration of having too little time to handle current tasks, let alone improvement programs. The ultimate objective of software process improvement is to reduce the cost of creating and maintaining software. There are several ways to accomplish this:

  • Correcting problems encountered on previous or current projects
  • Anticipating and preventing problems that you might encounter on future projects
  • Adopting practices that are more efficient than the practices currently being used

If your team’s current methods seem to work well (or if people insist that they do despite evidence to the contrary), people might not see the need to change their approach. However, even successful software organizations can struggle when confronted with larger projects, different customers, long-distance collaborations, tighter schedules, or new application domains. An approach that works for a co-located team of five people with a single customer doesn’t scale up to 125 project participants located in two different time zones who are serving hundreds of corporate customers. At the least, you should be aware of other approaches to requirements that could be valuable additions to your software engineering tool kit. Let’s begin our journey through requirements process improvement by seeing how requirements activities relate to various other key project processes. Changing how your projects handle requirements will of necessity affect these other processes, and vice versa. If you want to succeed with requirements improvement, you’ll need to get the owners of these other process areas to play along.

How Requirements Relate to Other Project Processes

Requirements lie at the heart of every well-run software project, supporting and enabling the other technical and management activities. Figure 1 illustrates some connections between requirements and other processes; the sections that follow briefly describe these process interfaces.

KW_Feb14

Project planning. Too often, project deadlines and staff allocations are determined before the requirements are well understood. It’s no wonder then that so many projects overrun their schedules and budgets. A more realistic approach is to make requirements the foundation of the project planning process. The planners select an appropriate software development life cycle and develop resource and schedule estimates based on the requirements. Thoughtful planning might indicate that it’s not possible to deliver the entire desired feature set within the available bounds of resources and time. The planning process can lead to reductions in the project scope or to selecting an incremental or iterative to deliver functionality in planned chunks.

 

Project tracking and control. Project tracking includes monitoring the status of each requirement so that the project manager can see whether construction and verification are proceeding as intended. If not, management might need to request a scope reduction through the change control process. If you find early on that your team isn’t implementing requirements as quickly as planned, you’ll need to adjust the expectations to reflect the reality of your team’s productivity. Sometimes this means reallocating lower priority requirements from the backlog into later iterations than planned. It doesn’t matter whether you, your managers, or your customers like this or not: that’s just the way it is.

 

Change control. After a set of requirements has been baselined, all subsequent changes should be made through a defined change control process. The change control process helps ensure that:

  • The impact of a proposed change is understood.
  • All people who are affected by a change are made aware of it.
  • The appropriate people make informed decisions to accept changes.
  • Resources and commitments are adjusted as needed.
  • The requirements documentation is kept current and accurate.

System testing. The testing and requirements processes are tightly coupled. User requirements and functional requirements are key inputs to system testing. If the expected behavior of the software under various conditions is not clearly specified, the testers will be hard-pressed to identify defects and to verify that all planned functionality has been implemented as intended. An excellent starting point is to start thinking about testing from the very beginning. Think of user acceptance tests for each requirement as you specify it. This is a great way to identify missing exceptions and ambiguous requirements.

Construction. Although executable software is the ultimate deliverable of a software project, requirements form the foundation for the design and implementation work, and they tie together the various construction work products. Use design reviews to ensure that the architecture and detailed designs correctly address all of the requirements, both functional and nonfunctional. Unit testing can determine whether the code satisfies the design specifications and the pertinent requirements. Requirements tracing lets you document the specific software design and code elements that were derived from each requirement.

User documentation. I once worked in an office area that also housed the technical writers who prepared user documentation for complex software-containing products. I asked one of the writers why they worked such long hours. “We’re at the end of the food chain,” she replied. “We have to respond to the final changes in user interface displays and the features that got dropped or added at the last minute.” The product’s requirements are an essential input to the user documentation process, so poorly written or late requirements will lead to documentation problems. The long-suffering people at the end of the requirements chain, such as technical writers and testers, are often enthusiastic supporters of improved requirements engineering practices.

The central point here is that you can’t modify your requirements practices in a vacuum. The thoughtful improvement leader will consider the context and identify stakeholders of other internal processes who would be affected by changes in the requirement development and management processes. By engaging those counterparts in a collaborative effort to improve the way your teams approach requirements, everyone will come out ahead.

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. Karl produced this article for Enfocussolutions.