Your Requirements Arena
This chapter is from the book
This chapter is from the book
This chapter is from the book
All projects are different. Regardless of whether they are greenfield developments or product alignment initiatives, none of them solve exactly the same business problem, exploit the same business opportunity, need the same solution, have the same team leaders and members, use the same approach, or have the same resources and customers.
No matter the differences, however, all of them have something in common: They must all solve the right business problem. They all have the same need to discover the right requirements if they are to deliver the right solution.
It would be foolish to say that there is a requirements discovery and solution development process that fits everyone’s needs. On the other hand, if you are to successfully deliver the solution to your client’s business problem, there must be some kind of process. The alternative is anarchy, and nothing of note has ever been developed out of mayhem. The idea of a thousand monkeys with typewriters eventually writing a Shakespeare play is fantasy.
We can safely say that to do meaningful work, there must be some kind of meaningful, orderly process that fits your organization and the nature of your business problem.
What follows in this book is a presentation of requirements discovery and solution development activities, their complexities and conundrums, their subtleties, thinking, and rationales, their advantages and obstacles, their outcomes and outputs, and how you can put all this together to make your own successful requirements discovery and development process.
Let us look at how this works.
A Requirements Process
The process we discuss in this book is not—absolutely not—a lockstep process to be blindly followed in the hope that in the end, the right solution will emerge. Instead, we’ll use the process to provide a guide to the activities that are required for you to uncover the real needs for the solution that solves your customer’s real business problem.
Figure 2.1 shows the generic version of the Volere process. Start by looking at the ellipses—these represent the activities you use to discover the requirements and develop the solution. As we go through the book, we’ll explain how the activities relate to each other and what outcome each activity achieves.
)
Figure 2.1 The Volere requirements process showing the activities and main flows of information. The activities have feedback between them; they also iterate. The requirements knowledge each one generates is stored centrally in the requirements repository, which can take several forms: specification, story map, product backlog, and so on. Having such a central repository means that everyone and every activity has access to the required information.
Each activity in the Volere process has a role to play. Each contributes in some way to the requirements—in whatever form they take—for the solution to be built or bought to solve the business problem. The Project Blastoff activity establishes the scope of the problem space, the stakeholders involved in the business, and the goals of the project. These form the foundation of the remaining activities. The Prototype for Requirements activity is a quick way to explore the problem space and the potential solutions for the business, and the Trawl for Requirements activity examines the problem in different ways and produces atomic, measurable requirements. Design the Business Solution is an activity that uses the requirements knowledge to produce a workable end-to-end business solution.
The Volere process provides activities that define the thinking needed to discover and communicate requirements. It becomes your process when you order, overlap, partition, and decide which parts of the generic activities to emphasize so as to make a process that works the way you need it to.
To show you the defined activities of the process and how you might vary them according to the solution’s needs, we present three variations. The first is a project using agile development and agile requirements. Next is a milspec effort in which a precise specification must be written. The third is a regular commercial project, which is probably what most people use.
Keep in mind that the process that fits you is most likely an amalgam of the ones you are about to see.
Kodiak, an Agile Project
Let us say that you work for (or perhaps own) a small startup, or you work for a large organization, and it wants you to produce a new product. Your product could be anything; however, we can say that if it is to succeed, it must be innovative and bring its customers a different kind of experience. Your team decides to call the initiative Kodiak after the bear Ursus arctos middendorffi.
Speed is important, but the Kodiak team members know that speed must not be considered the sole criterion for their success. Sure, they would like the Kodiak product to be first on the market, but it is far more important that the product solves a real business problem and provides a satisfying and worthwhile customer experience. If you look at some of the most successful companies in the world today, few of them were the first to market with their products. However, all of them made the best product. Apple was not the first company to produce a smartphone; Amazon was not the first bookseller (that’s how it started); Microsoft was not the first to build a PC operating system; Instagram was not the first social media platform (neither was Facebook); Google was not the first search engine. However, all of them succeeded because they turned out to be the best.
The best way to be fast is to get the right answer; that is, to develop the right product and not endlessly revise a flawed product. The team adopts a “Think slow, act fast”1 approach. They know if they start building the product without first clarifying what they are trying to do, they will not be fast at all. Think slow—get it right—then act fast—rapidly build the right product—is their most effective way of proceeding.
During the Project Blastoff they hold a few meetings to nail down the vision for the product, the scope of the problem space, the actual business problem their product is intended to solve, and the constraints on the product that come from the infrastructure that their product must fit into. The Kodiak approach is illustrated in Figure 2.2.
)
Figure 2.2 The requirements arena for a fast-moving agile project. The size of the ellipse and whether it is shaded or not indicates the emphasis placed on that activity. In this case, most of the effort is expended on Prototype for Requirements with some interaction with Trawling and Designing. The solution is developed progressively.
As soon as they have enough of a foundation for the project to have a shared understanding of what they are trying to do (and what they are trying to do is not to build a product but to solve a business problem), the Kodiak team switches to prototyping alternative solutions, or parts of solutions. Prototypes here mean quick sketches with minimal detail, quick mockups and wireframes, a variety of models, and anything else that is adequate enough to convey their ideas. The team wants to move fast. By using sketches, they can rapidly explore possibilities. They are not afraid to throw away ideas; they know they will have better ones.
This is agile requirements discovery. When the team has a working prototype of part of the solution, they hand it off to the development team who, using Scrum or one of the other agile methods, builds the first increment of the product. Meanwhile, the requirements team progresses in an iterative manner. Their prototypes experiment with different aspects of the proposed solution, and when they are satisfied that what they have is a feasible chunk of functionality, they write stories. The stories are added to their story map, which is a part of their requirements repository. They will be retrieved as needed by the development team for the next increment. (There is more on stories and story maps in subsequent chapters.)
The prototyping effort is not just directed at the intended product but includes the infrastructure surrounding the product. Kodiak process models start when the customer decides to, or has a need to, use the product. The models include actions the customer might take before and after touching the product. The team members are thinking about the customer’s experience and how their product contributes to it. When they are testing their prototypes, it is less about seeing if the prototype works and more about seeing if it provides an outcome that the customer finds valuable.
The point of this prototyping approach is that it enables the team to rapidly explore the problem space by using sketched prototypes to demonstrate outcomes. When the outcome matches the desired outcome, the team and the customer know that they are solving the right problem. Understanding the real business problem allows the team to explore the solution space quickly and inexpensively. As the prototypes progress and are enriched by additional information, they become the basis for writing the correct requirements and stories.
Grizzly, a Milspec Project
This project was named by the team members after Ursus arctos horribilis, and is not a reflection on the nature of the project. Grizzly is a project in which the client is from the medical, military (hence “milspec”), or aeronautical space, or some other arena in which it is necessary to produce a complete specification before much, or any, of the development starts. You might call the Grizzly project a traditional, waterfall, linear, or serial project. These terms mean that there is a real need for a complete specification. For example, if you are outsourcing the development of the product, you need a complete requirements specification to give to your outsource supplier.
The Grizzly project hinges on the requirements specification it produces. The specification must be complete and, in the case of military or medical products, provable. By this we mean that the team must be able to validate that each requirement in the specification is correct and verify that all of the requirements have been developed and tested for compliance.
You might also find Grizzly projects taking place in organizations whose standards demand a complete requirements specification for each initiative. This specification-led approach is not uncommon, and there are usually good reasons for it. However, we strongly urge you to consider whether the milspec approach (illustrated in Figure 2.3) is appropriate for you, or whether your organization uses it because “we’ve always done it that way.” If the latter is the case, please look at the lighter-weight alternatives presented in this chapter.
)
Figure 2.3 This adaptation of the process is concerned almost exclusively with building a requirements specification either for outsourced construction or because there is a need for a complete and provable specification. Requirements discovery for this kind of initiative is concerned mainly with the Blastoff and the Trawling activities. These are shaded in the diagram.
The Grizzly team will first do a thorough Blastoff. The scope of the problem is critical: This kind of project must establish a realistic and precise boundary to the problem being solved. Otherwise, there is a real risk of scope creep setting in late in the project. It is also crucial to ensure that the proposed scope is suitable for a solution to deliver the proposed benefits. Cost overruns and nondelivery of promised benefits affect most large projects, and milspec projects tend to be large. Having a thorough Blastoff is a major step in avoiding a failed project.
When they know they have built a solid foundation, the Grizzly team spends a lot of its time in the Trawl for Requirements activity. The team members ask a lot of questions and interview stakeholders, run workshops, write scenarios, and perform any of the other trawling activities (we’ll look closely at these things in Part IV). They are discovering details of the customers and their work. All the trawling techniques are designed to discover requirements, which are progressively added to the requirements repository. In this case, the repository is composed of a specification and ancillary documents.
The Grizzly team writes their specification using the Volere Requirements Specification Template. This template can be found in Appendix A, and you will see it used throughout the book. Think of the template as a comprehensive guide to what needs to be included in a specification, and how you might write it.
Generally, for this kind of project, the requirements specification is complete and validated before the requirements work is considered finished. (It’s never really finished, but for the sake of brevity, let’s say it is.) Now the specification is handed off to the developer. This can be an in-house development team or an outsourced one. In either case, the specification must be precise enough for the right solution to be developed.
In some cases, it is required that the spec be verified. This means that the developer must be able to demonstrate that every requirement in the specification has been correctly implemented and comprehensively tested. For medical and military solutions, this verification is pivotal, which in turn means that your specification must be written to be an accurate benchmark for those doing the verification. Later we discuss how to write accurate and testable requirements.
Polar, a Typical Commercial Project
The third of our bear teams, this time Polar (Ursus maritimus), is engaged in the kind of project that is happening in many organizations all over the world. This project will deliver an insurance product, or one that does banking, government, e-commerce, customer resource management, enterprise resource management, internal information, mail campaigns, analytics, reporting, or one of hundreds of other possibilities.
The Polar team members use all the activities in the process fairly evenly. There is no extra emphasis on experimentation and prototyping, and although innovation should be part of every project, there is limited opportunity here for breakthrough advances. The Polar variation of the process is shown in Figure 2.4.
)
Figure 2.4 The requirements arena is wider this time. A typical project cycles between the Blastoff, Trawling, Prototyping, and Design activities. The Polar team spends some of the time prototyping—they are experimenting with both new technology and new ways of working in the business. Trawling is where they ask lots of questions and establish the business rules and current way of working.
Project Blastoff is important for any development effort to establish the scope of the project and its goals and stakeholders. Scope here is the extent of the business area that the proposed solution affects. It is wider than just the software solution, as the surrounding business infrastructure is usually a crucial part of any solution. The Polar team will use a context diagram (that’s the one labeled Work Scope in Figure 2.4) to establish the extent of the business problem they are addressing. Having a well-defined scope enables the team to make estimates of the amount of effort needed to discover the requirements and develop the solution.
The goals must be clear to the team. That sounds obvious, but unless the goals are presented in some measurable way, there is a significant risk that different team members will have different interpretations of what is to be achieved. Once the scope and the goals are established, the Polar team can get on with discovering the requirements for the solution.
When a project is in the commercial sector, it is highly likely that ready-made solutions exist. You might know of these as OTS (off-the-shelf), open-source, or legacy systems. They will form part of, and possibly most of, the delivered solution. In this case, the team would do a certain amount of exploration and verification of the ready-made outcomes by prototyping various scenarios using different customizations. In some cases, the team could model the outcome if the business processes were changed to suit the ready-made solution. This latter case would cause a degree of interaction between Design (to determine the new configuration of the business) and Prototyping (to model and test the outcomes of the new designs).
This prototyping approach might seem to be mixing implementation concerns—how something is done—with the business requirements—what it has to do. However, in this case the employment of ready-made components changes the emphasis of requirements discovery from What is needed? to Will this ready-made component do what is needed?.
Trawling would play a major part—the Polar team would have to gather considerable detail about business requirements to ensure that the chosen ready-made solution incorporates the established business rules of the organization and integrates with the way that people need to work.
Artificial intelligence (AI) component(s) might be an intended part of the solution. These can be treated somewhat like a ready-made component, but there is a different aspect that falls to the business analyst. Any AI engine is only as good as the questions, or prompts, put to it. Unless the prompt specifies exactly what the AI is to produce, its results will be flawed. Writing prompts is the same as writing requirements, albeit in a different form. The task is the same: Discover exactly what is needed and write the prompt that conveys exactly that need.
Design the Business Solution is an activity that is happening all the time. Design is not about screen layout and colors and sliding windows, but about coming up with the best business process. This includes not only the developed automated solution, but also the human activity that surrounds it. In other words, the design activity is just as much about designing the business activity as it is designing the solution. Software is not the only component you have available to deploy in a business solution—people and devices also play a part. In some cases, there might be no software development, but there will still be a process change, and this has to be both designed and specified for the people to understand the new process.
When you get to Develop the Solution, the requirements team members are probably not the same people who develop the solution. However, for a successful implementation, the developers and the business analysts will liaise closely. Feedback from the developers is part of requirements discovery.
Of course, this does not have to be a serial process in which a complete specification is developed before any development takes place. On the contrary, it is advisable that you use an iterative and incremental approach. That is, the Polar team will discover a unit of the requirements and hand it off to the developers. While the developers implement that part of the solution, the requirements for the next iteration are being discovered. These are implemented for the next iteration. Note the iteration arrows in Figure 2.4. This results in an incremental delivery of the solution, giving the customer the opportunity to make a phased deployment in the organization.
Finally, you should note that Polar projects are not always concerned with improving an existing business. In some cases, the organization is not trying to solve an existing business problem, but wants to exploit a business opportunity. The process remains the same. The difference is that instead of trawling an existing piece of business, the team elicits the requirements for a solution that will capitalize on the opportunity.
Polar projects vary. For the sake of effectiveness, treat each as unique; examine the business problem and determine which of the activities in the Volere process, and how you will iterate through them, would yield the best results.