by Karl Wiegers | Oct 13, 2014 | Business Analysis |
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?” Some organizations use the term “business requirements” to refer to any requirements received from the business, but I’m specifically using that term to refer to the objectives the business has that led to launching a software project in the first place. 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...
by Karl Wiegers | Jul 21, 2014 | Business Analysis, Uncategorized |
There is no single correct way to document specific requirements information. Every BA needs a rich tool kit of techniques at her disposal so that she can choose the most effective requirements view in each situation. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I offer some ideas about how to make that choice. Often, it’s valuable to represent information at both high and low levels of abstraction. The high level offers a big-picture perspective, whereas the low level of abstraction presents the nitty-gritty details. Certain audiences only need the high-level view, whereas developers and testers do need to see all those specifics, as well. An effective requirements analysis technique is to create an alternative view of the requirements from the initial set of information and examine it for problems. Here’s an actual example. I once reviewed a requirements specification for a client who was developing the firmware for a device for testing integrated circuit components. The spec contained a long table that listed the various states this device could be in and what behaviors lead to changes from one state to another. Table 1 shows a portion of this table. I needed to know if all possible states were described and that the allowed state changes were all correctly specified. But how could I judge that? Missing requirements are hard to spot precisely because they don’t exist. I decided to draw a state-transition diagram from the information in the original table, which appears in Figure 1. A state-transition diagram is a simple analysis model that provides a high-abstraction view of such a...
by Karl Wiegers | Jul 17, 2014 | Business Analysis, Uncategorized |
An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable. This article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), briefly describes some alternative types of requirements views to consider. Analysis Models Analysis models are diagrams that present information visually. The table below lists several of the graphical analysis models that are available to the BA. Some of these date back to the structured analysis movement of the 1970s and 1980s. Others are part of the Unified Modeling Language, which provides a rich set of conventions for object-oriented analysis and design. I don’t have the space to describe these various techniques in detail here. See my book with Joy Beatty titled Software Requirements, 3rd Edition (Microsoft Press, 2013) for descriptions and examples of several of these—and other—modeling notations. Note that some requirements authors use the term model to describe any method for representing requirements information, including a list of textual functional requirements. When I say model or analysis model, I’m referring to a diagram that represents requirements information visually, generally at a higher level of abstraction than written requirements offer. I highly recommend that you use standard notations when drawing these kinds of diagrams. There are enough types of models in the software literature to cover nearly every situation, so you should almost never have to invent a new kind of diagram. Remember that these are communication...
by Karl Wiegers | Jul 15, 2014 | Business Analysis, Uncategorized |
If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.” Unfortunately, we have no absolute “terrain” for requirements: every representation is a map! Even though you can’t tell which representation is correct, differences between them indicate problems. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I’ll explain the value of creating more than one view of your requirements. Consider the figure below. A use case presents a high-level view of requirements from the user’s perspective. It describes some goal the user needs to accomplish with the help of the system, expressed as a sequence of interactions between a user and the system that leads to an outcome of value. A primary purpose of the use case technique is to help the BA derive the functional requirements that developers must implement to let users perform a use case. These functional requirements represent a second, more detailed view. The BA might also draw graphical analysis models, diagrams that represent additional views of the requirements. The BA should be able to relate the functional requirements to elements shown in the models to make sure that these complementary views agree. Suppose a tester were to write some test cases—thereby creating yet another view of the...
by Karl Wiegers | Jul 11, 2014 | Business Analysis, Uncategorized |
There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant. The first man wrapped his arms around the elephant’s leg and said, “Why, an elephant is just like a big tree.” “No,” said the man who held the elephant’s tail, “an elephant is like a rope.” The third man felt the side of the elephant and reported, “This elephant is like a big wall.” The fourth man gripped the elephant’s trunk and declared, “You’re all wrong. The elephant is like a giant snake.” The fifth man rubbed the elephant’s tusk and said, “I think an elephant resembles a spear.” “No, no, no!” said the final man, who touched the elephant’s ear. “An elephant is like a big fan.” The blind men were all correct. The elephant has all the characteristics they described, but no single feature of the elephant provides a complete description of what an elephant is all about. Each man had but a limited view of the elephant and could draw conclusions only from that view. There’s an analogy with software requirements. I learned long ago that no single view of the requirements tells us everything we need to know about them. Often it’s desirable to represent requirements in multiple ways, thereby giving the readers a richer, more holistic understanding of the requirements elephant. Unfortunately, nearly every requirements specification I have read contains just a single view: natural language text. The clever business analyst can do better...
