• Mastering The Requirements Process

Mastering the Requirements Process, Second Edition, sets out an industry-proven process for gathering and verifying requirements with an eye toward today's agile. The NOOK Book (eBook) of the Mastering the Requirements Process by Suzanne Robertson, James C. Robertson at Barnes & Noble. FREE Shipping on $25. “If the purpose is to create one of the best books on requirements yet written, the authors have succeeded.” —Capers Jones Software can solve almost any problem.

'If the purpose is to create one of the best books on requirements yet written, the authors have succeeded.' —Capers Jones It is widely recognized that incorrect requirements account for up to 60 percent of errors in software products, and yet the majority of software development organizations do not have a formal requirements process. Many organizations appear willing to spend huge amounts on fixing and altering poorly specified software, but seem unwilling to invest a much smaller amount to get the requirements right in the first place. Mastering the Requirements Process, Second Edition, sets out an industry-proven process for gathering and verifying requirements with an eye toward today's agile development environments. In this total update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs while doing the minimum requirements work according to the project's level of agility. Suzanne Robertson and James Robertson have, over many years, helped hundreds of companies improve their requirements techniques and move into the fast lane of system development.

Their courses and seminars on requirements, analysis, and design are widely praised for their innovative approach. The Robertsons are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building.

They are also the coauthors of Requirements-Led Project Management (Addison-Wesley, 2005). James Robertson 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 courses and seminars on requirements, analysis, and design are widely praised for their innovative approach. The Robertsons are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building. They are also the coauthors of Requirements-Led Project Management (Addison-Wesley, 2005).

InfoQ: This is the third edition of your book, why so? What has changed since the second edition that warranted a whole new book? Agile development methods are more mainstream and people are wanting to know how requirements should be done in an agile environment. However, the book is not just about agile, it covers the full spectrum of the business analyst’s task in discovering and communicating requirements. Talking to a lot of business analysts we kept hearing some confused and contradictory messages about business analysis and system development. There seem to be quite a few people who are confusing their methodology with good practice.

We wanted to point out that there are some basic tenets that have to be observed. For example – “Requirements are not really about requirements” – the task is to study the work carried out by the business, as that is where requirements originate. You can’t specify the appropriate product unless you understand the work.

The other truths are things that we know are useful for business analysts to keep under consideration. InfoQ: Aren’t “requirements” unfashionable today – how do approaches like Lean Startup and Agile impact the work of defining requirements today? It does not matter how you develop your software. If it does not meet the needs of the business, in every respect, it is lousy software. (I am not sure who first said that, but it is true.) Many of today’s fashionable methods concentrate on the solution, and pay little regard to the real problem to be solved.

Sure, they produce software quickly, but that is of no use at all if they miss the real reason for building the software. As we said above, requirements is not about producing a large specification (most modern teams with in-house development do not do that anyway), but understanding the problem. We also have to consider that a large amount of development is done offshore. If you plan on having your software built in India or Russia, you had better have a pretty good specification or you’re wasting your money. Again, you need to solve the right problem. We cover strategies for these different kinds of development in the book – obviously you go about your requirements activity differently depending on how you are doing your development.

InfoQ: You present the Volere Requirements Process - please can you briefly explain the process and what makes it unique? We like to think of it as not a lockstep process, but a framework for discovering and communicating the real needs of the business. The process is made up of activities that have to be done somehow by somebody, in some order, to some degree of detail. And while we suggest to readers how they might do these activities, we understand that differences in organisations’ structure and history makes it necessary to approach these tasks in different ways. The important thing is getting the right result for each part of the process. The Volere process is unique because it is based not on somebody’s idea of how things should be done, but on observations from the field of successful requirements discovery and implementation. We talk about tangible things you need to achieve, rather than focusing on procedures like having a stand up meeting at 09:30 every morning.

InfoQ: You place a lot of importance on the concept of a product being 'optimally valuable' - why so? If it is not valuable to the business then it is a waste of resources to build it. Optimally valuable means that you build a product that is no more capable than it needs to be, that you spend no more developing it than its value warrants. The idea is firstly to be aware of the value your product brings to the business - it must solve some significant business problem. By being aware of its value, you can then ensure that you spend no more on its development than its value warrants. It is fashionable to refer to all software as “customer value”.

However it is no such thing unless it is providing a service to the business that is both measureable and beneficial. If it is optimally valuable, then you will have achieved both qualities.

InfoQ: You have a veritable menagerie of animals in the book - horses, elephants, rabbits and 'brown cows' - please can you explain some of the metaphors here? The first three are analogies. We are asking the reader to consider his or her project. Is it a small, fast, short-lived project?

If so it is a rabbit project and you should do only certain things and omit others. For example, we suggest that rabbit projects should certainly discover all their requirements, but that they do not have to write a comprehensive specification.

Rabbit projects can abbreviate their specification. On the other hand, if you are outsourcing or are working on a military, medical or some government projects, you are an elephant.

Elephants are slower and larger and have a need for formal documentation (try getting a new airplane past the FAA without a complete specification). Horses fit in between these two. By giving a name and image to the style of project, business analysts are better able to talk about the differences between projects and act accordingly, and not spend time doing things that don't really have to be done. The Brown Cow model is a thinking tool that looks at different views or abstractions of the problem area. The first quadrant of the model is called How-Now, and we immediately thought of that English elocution exercise when you have to say, “How now brown cow?” Silly but memorable.

InfoQ: You talk about finding the real problem, and getting the 'essence' of the business - why is this so important? Too many projects leap into building the first solution that comes to mind, or the solution that the user has asked for.

While there is a chance that this might be exactly what is needed, history and statistics tell us that it is usually not the case. Too much software (and consumer products) are built to solve the wrong problem. Because the development team have concentrated on their solution and not taken enough care to study the business that is to deploy their solution.

The essence of the problem is an abstraction: what would this be if we did not have to take into account any technology? In other words, what is the real problem when it is not being distorted by the proposed solution? Or we could say that another way; the essence represents the underlying problem to be solved. If you don't discover the essence, then you are solving the wrong problem. InfoQ: You have a section providing advice in the form of 'strategies for today's business analyst' - what are some of these strategies and why are they needed? One is for external development, in other words if you are outsourcing. The strategy shows you which activities are important, which deliverables you need to produce and how to assess when the level of detail is sufficient for your particular situation.

Another strategy is for iterative development. If you are using an agile method then it’s iterative and you need to be sure that you are spending your time on the most relevant and valuable details. This strategy again shows what you need to do to work efficiently within your method. We developed the strategies because it is clear that not all organizations should work the same way. We have provided alternative ways of working on requirements to suit the characteristics of your own organization. InfoQ: You talk about Fit Criteria and Rationale as being important - what are these, and why do they matter? They matter because if you do not have them, you probably do not have the right requirement.

Mastering The Requirements Process

Rationale is the reason or justification for the requirement. “Why do you want this?” is actually more important than “What do you want?” If the business analyst and the developer know why something is required, they can produce the best solution. The fit criterion is a measurement of the requirement. You derive this when you have a rationale. For example, suppose you have a requirement that says, “I want a product that is easy to use.” This is valid, but not yet helpful. Now ask for a rationale: “Why do you want this?” “I want my customers to voluntarily switch to using the new system.” Now you can derive the fit criterion along the lines of “Within six months, 70% of customers have adopted the new system and have abandoned the previous one.” The fit criterion is in effect the acceptance criterion, and the designer/developer has to make the new system attractive enough to achieve the target.

Note here that “easy to use” was a proposed solution—it would not guarantee that customers switched. By including a fit criterion, you are stating the essence of the problem. InfoQ: What makes a 'good' requirement? One answer to the question is that a good requirement solves a relevant and worthwhile problem, and has a cost in proportion to the value it provides its owner. However, we suspect that was not your intention in asking the question. So we should say that a good requirement is unambiguous (that’s why we have a fit criterion), is solving the right problem (the rationale should take care of that) and is written so that all interested parties can understand and agree with it.

Of course it must be testable, and again, the fit criterion is also there for that purpose. InfoQ: How does the Volere process support agile/iterative development practices? By not being a rigid process, and by concentrating on the discovery of the real needs. The real requirements have to be found otherwise your project builds the wrong, or at best sub-optimal, product. The Volere approach is that you do not have to find all of the requirements and write a complete specification before proceeding, but you must be able to demonstrate the essence of the problem you are solving. Many of the agile techniques use story cards. We have included a section on how to write good stories, and how to avoid the problem that many stories have of dealing with a solution and not the underlying problem.

InfoQ: How does this process support innovation - if we are simply gathering requirements where do new ideas come from? Innovation is most important. If there is no innovation then the value of the delivered product is probably zero – it did not deliver anything new. And the idea of “gathering requirements” usually leads away from innovation.

As we said above you are not asking, “what do you want?” but “why do you want it?” Innovation in the requirements sense is not inventing a new piece of technology, but finding a new way of doing the work. By discovering the underlying reasons for the work, the business analyst can lead the innovation charge to find not just a better way to do the work, but better work to do.

This transforms a business analyst from a stenographer who gathers and documents requirements to an innovator who studies the work and discovers valuable innovations. The Volere process suggests that between the What-Now and Future-What quadrants of the brown cow model (you’ll have to buy the book to understand that completely) you consider innovation, and how you can improve the work that in turn improves the business.

Improving the work is after all, the purpose of any software project. About the Book Authors Suzanne Robertson and James Robertson have helped hundreds of companies improve their requirements techniques to enhance system development. Their courses and seminars on requirements, analysis, and design are widely praised for their innovative approach.

They are principals of the Atlantic Systems Guild, a well-known consultancy specializing in the human dimensions of complex system building. They are also the co-authors of 'Requirements-Led Project Management' (Addison-Wesley, 2005) This article is based on the 3rd Ed. Of the book, 'Mastering the Requirements Process: Getting Requirements Right' by Suzanne Robertson & James Robertson, published by Pearson/Addison-Wesley Professional, Aug 2012, ISBN, Copyright 2013 Pearson Education, Inc. For more info, please visit the.