by Jenny Boronyak | Oct 23, 2014 | Agile, Business Analysis |
Wow! More people than ever showed up to the Enfocus Solutions Webinar Series last week when CEO John Parker presented The Agile Business Analyst. There were so many questions asked that we couldn’t even begin to answer them during the webinar. The original plan was to publish the Q&A as a blog post, but there were just way too many questions to do that! So, below are a few of our favorites. All answers were provided by the webinar presenter, John Parker. It was really hard to pick just a few. If you’d like to read the answers to all of the questions asked, download the complete Q&A. Q: How do we keep track of the changes made in a system if we don’t document them? A: The changes are documented with user stories, maintaining clean code, and writing an efficient level of system documentation. Agile does not mean “producing no documentation.” Agile documentation is lightweight and sufficient. Q: What do you recommend for system documentation that must be maintained? At the end of the day, organizations need a document outlining business process, business rules, data rules, etc. A: This information is usually maintained in a collaborative business architecture and maintained separately from the team. When an Epic is defined, necessary changes to the business architecture are identified as change impacts. These changes are further refined as Epics are decomposed into Features. Stories simply represent changes to the business architecture. I did not discuss all of this in the webinar, but this is a key part of agile portfolio and program management. Q: How do you make agile work...
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 | Sep 22, 2014 | Business Analysis |
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 business analyst 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. 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...
by Karl Wiegers | Sep 3, 2014 | Business Analysis, Uncategorized |
Written by Karl Wiegers and Joy Beatty The leader of a corporate requirements organization once posed a problem. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?” In another organization, a BA experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked. These questions exemplify the challenges that can arise when trying to engage BAs, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that he’ll get what he needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as you are; if they were, they’d probably all become business analysts! Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not...
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...
