Suzanne and James Robertson, authors of numerous publications in the requirements field, launched a video course called "Requirements: The Masterclass LiveLessons--Traditional, Agile, Outsourcing (Video Training)"
The course is designed for people in different roles who contribute to requirements elicitation and representation, it describes variations on the requirements process for specific environments, like traditional, agile, outsourcing and acquisitions of off-the-shelf solutions. Throughout the videos several requirements approaches and activities are described, covering both problem identification and solution discovery. Techniques on how to collect, write, trace and validate requirements are detailed during the course.
InfoQ interviewed Suzanne and James Robertson on these video lessons to get further insights into some of the topics addressed:
InfoQ: You mention four different profiles as targets for this Master Class. Can you describe how each one will benefit from it?
We have found over time that requirements is a domain that includes many people, or roles.
First, the most obvious, and the ones that get the greatest benefit from this course, are business analysts. These are the people normally charged with discovering the requirements, and the course provides tools, techniques and ways of thinking that make the requirements discovery more accessible and more effective. Business analysts understand the need for effective and accurate requirements discovery.
Product Owners, Product and Program Managers, have a responsibility for the accuracy and advantages of the requirements for their products. These people could skip over some of the more detailed lessons, but the ideas of scoping, business events, working with stakeholders, quality, advantages from requirements, prototyping, and a lot of the other topics, will contribute to them being able to produce the desired result for their products.
Agile teams need requirements — you cannot build the right product unless you discover the right requirements. Agile teams go about their requirements differently. In the course we have a number of chapters specifically on agile, and look in some detail at how to write the right stories — the stories that contain the right requirements. Most of the remainder of the course is applicable to agile teams, and how they can ensure the correct final product.
Users and end customers for the product also have something in the course for them. This group participates in the requirements activity by providing their needs. However, simple as this sounds, it is not at all straightforward. There is a difference between stating a solution that they believe will solve the problem, and providing a clear statement of the real business problem to be solved. This course shows users and software customers that the problem is wider and more subtle, and how they can use the tools and thinking approaches to better understand their own business problem, and how that fits into the systemic needs of the organisation.
InfoQ: Regarding requirements, the approach to be followed depends on the specific environment of the company and the project. Could you please highlight main differences between traditional and agile environments when working with requirements?
The apparent difference between traditional and agile requirements, is that traditional projects build a complete specification before any development takes place. On the other hand, agile projects use stories to negotiate the product at a higher level, and the atomic requirements are produced on a “just in time” basis. However, as time goes on, we see a blurring between these two opposites, and traditional requirements are more likely to be developed iteratively, while agile projects are spending more time in upfront analysis rather than rushing into a solution.
InfoQ: And between outsourcing and off-the-shelf solutions?
Outsourcing generally requires a complete specification before the outsourcer can start work. Off-the-shelf solutions already exist, and the requirements activity is to find the OTS solution that most closely matches the organization's needs. This of course means that you must know your requirements if you are to find a suitable OTS product.
InfoQ: You drew and introduced the Volere Process as a support for the requirements' related processes. Could you please elaborate on it?
The Volere requirements process is a framework for discovering, communicating and managing requirements. The framework is based on solid systems engineering principles and provides a knowledge model for talking about requirements knowledge at various of levels of detail. The framework is designed so that individual projects can choose the level of requirements detail, trawling techniques and iterative delivery that suits the constraints of their project and industry.
InfoQ: Regarding Agile Environments, we are used to the role of the Product Owner. You talked about the importance of the Eventual Owner and its needs. Could you tell some more about this Persona?
The eventual owner is the person or organization for whom the software is being built. In some cases, if the software is being built in-house, then the eventual owner is the organization that employs the developers. In other cases, software products are built for sale and the eventual owner is the person or organization who buys the product for use by the employees. In either event, it is absolutely crucial that the eventual owner's needs are satisfied by the product.
The product owner role in agile projects is someone, who as part of their duties, represents the eventual owner. Experience tells us that it is clearly difficult to find product owners with suitable business analysis experience, and with enough knowledge of the eventual owner's business to be able to provide complete requirements for the product. Many agile projects have found that the skills of business analysts are necessary to accurately discover the eventual owner's needs.
InfoQ: May you describe the Agile Requirements Process and the roles involved?
The roles in agile projects should not be thought of as rigid roles. The whole idea of agility is to be adaptable, and different projects have different needs when it comes to determining the requirements for the product. Instead of being driven by roles, it is more helpful to consider what you are trying do discover and communicate. Regardless of roles it is necessary to firstly define the scope of the business being affected by the product, to break this into business events (we describe business events in the course) and from these derive the business stories. These stories are at a fairly high level and need to be sliced before development takes place.
InfoQ: Many Agile teams rely on User Stories. How do User Stories relate to requirements and how to discover the right ones?
I think uses stories are not a good idea as a starting point, because it implies that you already know who the user is and what functionality is part of the finished product. This is quite different from understanding the eventual owner's business, and what a product would have to do to improve their business. In the course we advocate writing business stories, which describe parts of the functionality of the business, without yet being concerned about any possible future solution. Once the business is correctly understood – keep in mind that this requires analytical skills as individual stakeholders’ descriptions of the business are quite often unreliable — the business analyst can record part of the business in story form.
The business stories are at too high a level to be implemented, and have to be sliced by the development team to fit their iterations or sprints. You can think of the sliced stories business stories as (mainly) user stories, and they represent a collection of atomic requirements. These atomic requirements are fleshed out by the business analysts and developers during the development iteration.
InfoQ: An highlight from the lessons is the importance of starting well. Could you please share some techniques to guarantee that the correct foundations are laid down?
Yes, it is supremely important to start well. The course proposes that you start with the trinity of scope, stakeholders, and goals. The scope is the scope of the work to be improved; the stakeholders are the people with an interest in this work; and the goals set down the business value to be achieved by the product.
So we stress in the course that is important not to presume that you know the solution. Too many projects begin by assuming a solution, and the project rushes into delivering that solution without ever looking up to see the real needs of the business. The course strongly suggest that you understand the business before attempting to derive a solution for it.
InfoQ: During requirements discovery it's mandatory to reach the essence of the problem. You talked about the Brown Cow Model. Can you please detail on this?
The Brown Cow model is a way of looking at the problem from different viewpoints. This approach is used to clarify what we need to see at different times, and to be able to communicate more effectively with a variety of stakeholders. Briefly the Brown Cow model provides you with the ability to look at the problem from a variety of points of view (what and how, and now and the future) rather than trying to look at everything at once. “How” represents a technological view of the problem, and includes software, hardware, people and anything else used to implement a solution. “What” is the essence of the problem, and represents the real problem that you would see if you can strip away all of its technological accompaniments.
We also divide “Now” from the “Future” to enable us to communicate about the current state – either technological or essence – and what the future state of the work might be. Thus we get the four quadrants of the model: How-Now, What-Now, Future-What, and Future-How. The last mentioned should normally be the last viewpoint to be taken. Unfortunately, many projects start with the Future-How, which means they are presuming a solution without considering what the problem is.
InfoQ: Generating ideas is a core technique to find the right solution. Can you share some tricks?
The first thing to do when generating ideas is to get to the essence of the problem. The essence is what you would see if you were able to strip away all the technology, people and procedures, that are part of the current implementation. This clean view of the problem enables you to think more clearly about it. The idea of generating ideas is to improve the existing essence. In other words, to make the work work better.
Two (out of many) techniques that we use most often, are constraint removal and innovation triggers. Constraint removal is looking at all the constraints that exist in the current piece of work, and questioning whether or not they are real. You ask the question, “What happens if I remove this constraint?" Often, by simply asking this question, it generates new ideas.
Innovation triggers are remarkably simple. One of the triggers is information. You look at the problem and ask the question, “What information would be useful to the people involved in this work, and what information do they currently get which is not useful?" By having a creative session about information, you discover what people really need to know in order to do their work. Sometimes the information answers are surprising.
Another innovation trigger we like to give our groups is convenience. The question is simple: “What can we do to make the work more convenient to the people doing it?” We as consumers have learnt that convenience is very important to us, and any project team need to make their solutions as convenient as possible if they are to be accepted by their audience. I know this sounds obvious, but too few teams actually stop and put effort into making their products more convenient for their customers.
InfoQ: Sketches, wireframes and other forms of prototyping are often used to leverage communication. As this happens in the discovery phase, your advice is to throw them away. Shouldn't this work be useful for communication with development teams?
When we advocate throwing away the sketches and wireframes, we do so to stop the development team working solely on improving the prototype. The objective is to find out the real needs, and the incremental improvement of a prototype might well prohibit you from finding out all the underlying needs. However we realize that some prototypes do in fact include good design ideas, and for these we suggest putting them in a section 26 of the Volere a template, “Ideas for solutions”, so that you can review them when you have a better understanding of the problem.
InfoQ: You mentioned that looking for deviations is a powerful weapon to uncover hidden requirements. For that, you introduced the concept of Misuse Case. Could you explain it for us?
Misuse case is a play on words. "Use case" is a common term and we're simply asking the question, what could somebody do to misuse it? We often refer to the protagonist and the antagonist. The protagonist is the person you're in favor of, that is the normal operator of the product, and you want him or her to succeed. However, your protagonist may well make errors and these can be regarded as a misuse case. The antagonist is deliberately trying to abuse the product, either stealing from it, wrecking it, or taking some other unwanted action. Again we suggest building misuse case scenarios to document both intentional and unintentional misuse.
InfoQ: Please give some advice on the requirements strategy for someone about to start a new project.
The most important pieces of advice that we can pass onto somebody starting a new project are:
1. Don't presume to know the solution. The majority of projects fail because of poor requirements work, and this is usually because the team have pursued a presumed solution without really understanding the real needs of the eventual owner's organization.
2. Get to the real business problem as soon as possible. We refer in the course to the essence of the problem. When you arrive at the essence it is far easier to uncover the real needs.
3. Define the scope of the problem, tor the scope of the work that you are about to improve. Without a clear definition of scope it is far too easy to wander off course and end up with a solution that does not address the real needs.
4. Don't assume that the project will automatically deliver value. If you don't already have it, write a value proposition and ensure that your project will in fact deliver value — measurable value — to the eventual owner's business.
5. Lastly, you must ensure that you are solving the right problem. This sounds incredibly obvious, and if you have considered the first four points, you are almost certainly solving the problem and will deliver value to the eventual owner.
About the Book Authors
James and Suzanne Robertson have, over many years, helped hundreds of companies improve their requirements techniques and move into the fast lane of system development. Their video course and seminars on requirements, business analysis, and design are widely praised for their innovative approach.
The Robertsons are principals of the Atlantic Systems Guild, a well-known think-tank specialising in the human dimensions of complex system building. They are also the coauthors of “Mastering the Requirements Process – edition 3” (Addison-Wesley, 2012) and the developers of the Volere requirements techniques.
