Praise for Mastering the Requirements Process

“Suzanne and James Robertson have been Requirements Masters for many years. The fourth edition of their classic text brings an increased focus on business events, how events relate to stories, and prototyping. There’s even a chapter on how AI could aid in requirements discovery. The conversational writing style makes the content easily accessible.”

—Karl Wiegers, PhD, co-author of Software Requirements and Software Requirements Essentials

“I was delighted to get my hands on this edition of Mastering the Requirements Process. MRP, as it is affectionately known, has been the reference guide for many business requirements projects for near-on 20 years. But requirements processes are changing. Generative AI and more focus on creative thinking to innovate are becoming mainstream. This new edition integrates them all into MRP’s comprehensive and easy-to-understand process guidance. A must for forward-thinking businesses.”

—Prof. Neil Maiden, Bayes Business School, City, University of London

“The fourth edition of Mastering the Requirements Process is completely rewritten. It brings new insights into methods for requirements work in agile software development and how to work with AI. Instructive and relevant examples deepen the understanding of the complex subject, as well as making the book entertaining to read.”

—Aase Tveito, Senior Advisor, IT Department, The Arctic University of Norway

“I love the emphasis on prototyping and ‘fit criteria’ in this new edition. There’s so much practical common sense here. Whatever role you have on your project, if you want it to succeed, I suggest you read this book.”

—Nick de Voil, De Voil Consulting

“This book is a hidden gem, not just for systems work, but for anyone dealing with people, especially knowledge workers. James and Suzanne show how to better figure out what is needed and how to better express that so people can understand, collaborate, and implement successfully.”

—Mike Russell, C-level executive and consultant

“Suzanne and James Robertson have done it again! Their magisterial work on requirements has been renewed and refreshed for the world we live in now, to suit the wide range of approaches used. I particularly enjoyed the section on prototyping, covering a huge range from sketches to putting an analyst in a cardboard box! Throughout the book, you’ll hear their hard-won experience guiding you on the best way to understand and deliver precisely what customers need. Bravo!”

—Dr. Penny Pullan, author of Business Analysis and Leadership, Virtual Leadership, and Making Workshops Work

“In this latest edition of Mastering the Requirements Process, James and Suzanne have taken the solid foundations of all their work on what constitutes good requirements and made it completely relevant and useful for today’s organisations. The ecosystem of requirements elicitation, identification, communication, and implementation is evolving, and our requirements approaches have to adapt along with this evolution. James and Suzanne show how to do this in a way that is accessible, interesting, and practical for anyone involved in working with requirements for sociotechnical systems, irrespective of the development methodology or approach being used.

“Filled with examples and stories from their deep experience, Mastering the Requirements Process, Fourth Edition, warrants a place on the bookshelf (or ebook catalog) of anyone serious about producing good technology systems.”

—Shane Hastie, Global Delivery Lead, Softed, part of Skills Development Group

“Requirements are the essential building blocks for developing successful products and services. However, defining well-formed and relevant requirements requires knowledge and skill that is founded on clear, up-to-date advice and guidance. This book provides such guidance, emphasising the importance of understanding the business context, identifying the actual problem to be solved, and avoiding the too-early leap to solutions, while also explaining that requirements are not waiting to be ‘gathered’ but require the skilful application of professional techniques. Written in their unique, engaging style, James and Suzanne Robertson’s new edition of Mastering the Requirements Process is both informative and comprehensive and is an essential reference guide for all requirements definition practitioners.”

—Dr. Debra Paul, CEO, AssistKD

“As an inveterate modeler and signatory to the Agile Manifesto, I need a book that will tell me how to gather and test requirements in a manner that fits in with the particular development process that I am using on this project. This book does exactly that.”

—Stephen Mellor, Independent consultant

“Mastering the Requirements Process is an essential resource for business analysis and business architecture. For over 10 years, I have extensively used this methodology to develop bespoke requirements engineering and business architecture methodologies in both the not-for-profit and investment banking sectors. The Volere Methodology provides a solid theoretical foundation, enabling practitioners to adopt a systems thinking approach to accurately identify and define business problems before developing appropriate solutions. Its emphasis on Business Use Cases allows for a precise identification of problem scope and underlying business processes. In my current role, Volere’s holistic approach has indirectly led to the development of a comprehensive Business Process Architecture, which has become a crucial strategic asset. The methodology’s focus on thorough analysis and clarity has consistently enabled us to design effective, transformative solutions. Volere is an invaluable guide for any professional looking to enhance their requirements process and drive meaningful change within their organization. I have eagerly anticipated the fourth edition and look forward to applying its new guidance in practice.”

—Sukhdev Kandhola, Director of Business Analysis and Business Architecture

“This book is the bible for product managers and business analysts alike. I’ve seen many projects fail or incur delays and extra costs due to missing requirements. This book teaches the most important skill: solving the right problem and delivering value to the business. The grail of product management.”

—Julien Andrieu, Product Manager

“In 1999, I attended James Robertson’s workshop on Mastering the Requirements Process in Austin, TX, unaware of the profound impact it would have on my career in the tech industry. The workshop included the comprehensive book of the same title, which I read from cover to cover, eager to apply its insights to my role at IBM. I was involved in software development projects, where overhauling the development process wasn’t workable, but I could adapt elements of Volere to improve outcomes. This approach proved instrumental in two pivotal projects. The first project involved integrating our Japanese and U.S. hardware manufacturing ERP systems. This required clearly defined and testable requirements to ensure success. The stakes were high, but applying lessons learned from the workshop led to a remarkable 72% reduction in project duration and an 87% decrease in IT expenses, all while avoiding any critical failures. Our second major project was an extensive ERP upgrade that was crucial to IBM. Failure would jeopardize 14% of our most profitable revenue stream. Again, getting clearly defined and testable requirements was critical. We integrated elements of Volere into the project. As a result, we could have unit and regression testing focusing on testing instead of discovering missed requirements and/or incorrect requirements. By getting our requirements correct and complete right up front, we avoided downstream discovery. This resulted in the project being delivered on time and 63% under budget, with a successful delivery free of critical failures. These experiences underscored the value of mastering requirements gathering and analysis, lessons I’ve carried with me into retirement. My bookshelf still houses the first edition of Mastering the Requirements Process, alongside the third edition, while the second edition found a new home with a colleague seeking to enhance his skills in the field. As I reflect on these achievements, I await the fourth edition with anticipation, a testament to the enduring relevance of the principles I first encountered in 1999.”

—John H. Capron, Former Technical Team Leader and Development Manager, IBM

About This eBook

ePUB is an open, industry-standard format for eBooks. However, support of ePUB and its many features varies across reading devices and applications. Use your device or app settings to customize the presentation to your liking. Settings that you can customize often include font, font size, single or double column, landscape or portrait mode, and figures that you can click or tap to enlarge. For additional information about the settings and features on your reading device or app, visit the device manufacturer’s Web site.

Many titles include programming code or configuration examples. To optimize the presentation of these elements, view the eBook in single-column, landscape mode and adjust the font size to the smallest setting. In addition to presenting code and configurations in the reflowable text format, we have included images of the code that mimic the presentation found in the print book; therefore, where the reflowable format may compromise the presentation of the code listing, you will see a “Click here to view code image” link. Click the link to view the print-fidelity code image. To return to the previous page viewed, click the Back button on your device or app.

Mastering the Requirements Process

Fourth Edition

James Robertson

Suzanne Robertson

with Adrian Reed

Hoboken, New Jersey

Author photos courtesy of James Robertson and Suzanne Robertson

Figure 1.1: rolandtopor/Shutterstock

Figure P2.1, spectroscope: morphart/123RF

Figure 3.1: Everett Collection/Shutterstock

Figure 3.2: Kamenetskiy Konstantin/Shutterstock

Figure 6.2: Rasstock/Shutterstock

Figure 6.4, photo: Kristo-Gothard Hunor/Shutterstock

Page 128, photo: bowie15/123RF

Figure 11.6: georgejmclittle/123RF

Page 147, photo: szefei/Shutterstock

Figure 16.3: Ljupco Smokovski/Shutterstock

Figure 27.1: Sakarin Sawasdinaka/Shutterstock

Figure 27.2: Nerthuz/Shutterstock

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at corpsales@pearsoned.com or (800) 382-3419.

For government sales inquiries, please contact governmentsales@pearsoned.com.

For questions about sales outside the U.S., please contact intlcs@pearson.com.

Please contact us with concerns about any potential bias at pearson.com/report-bias.html.

Visit us on the Web: informit.com/aw

Library of Congress Control Number: 2024940192

Copyright © 2025 Pearson Education, Inc.

All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, request forms and the appropriate contacts within the Pearson Education Global Rights & Permissions Department, please visit www.pearsoned.com/permissions/.

ISBN-13: 978-0-13-796950-0

ISBN-10: 0-13-796950-3

$PrintCode

To our partners in the Atlantic Systems Guild, who
over the many years have provided wisdom, companionship,
advice, arguments, knowledge, vexation, and good times.
Thank you, Tom, Tim, Peter, and Steve.

Contents at a Glance

Foreword

Preface

Acknowledgments

About the Authors

PART I • Requirements Are the Root of Everything

1 Requirements Fundamentals

2 Your Requirements Arena

PART II • Project Blastoff

3 Understand the Real Problem

4 The Value of Solving the Problem

5 Goals-Scope-Stakeholders

6 Customer Segments

7 Business Events

8 Prioritizing the Business Events

9 To Go or Not to Go?

PART III • Prototyping for Requirements

10 Generating Sacrificial Candidate Solutions

11 Prototypes, Prototypes, Prototypes

12 Ready-Made Solutions

13 Creative Candidate Solutions

14 Probing and Exploring the Candidates

15 Using Prototypes as the Specification

PART IV • Trawling for Requirements

16 The Essence of the Problem

17 Business Events and Business Use Cases

18 The Brown Cow Model

19 Workshops

20 Scenarios

21 Stories

22 Business Process Models

23 Stored Data

24 Other Trawling Techniques

PART V • Writing Good Requirements and Stories

25 Functional Requirements

26 Non-functional Requirements

27 Fit Criteria and Rationale

28 Writing Good Stories

29 Acceptance Criteria

PART VI • Designing Business Solutions

30 Business Solutions

31 Determine the Extent of the Automation

32 Designing Information and Functionality

33 Designing Using Ready-Mades

PART VII • Requirements Repository

34 Requirements Specification

35 Story Map

36 Quality Thinking

37 Completeness Check

38 Managing Requirements

PART VIII • The Conduct of Business Analysis

39 Your Process

40 The Importance of the Early Days

41 People

42 Systems Thinking

43 Artificial Intelligence (AI)

44 Learning as You Go

45 Requirements and Innovation

Appendix A The Volere Requirements Specification Template

Appendix B Stakeholder Management Templates

Appendix C Volere Requirements Knowledge Model

Glossary

Bibliography

Index

Foreword

My first project as a business analyst was a crash course in the importance of effective requirements development. When I joined the team, the system was on the verge of entering the integration testing phase and was scheduled to go into production six weeks later. It quickly became clear, even to me, that it wouldn’t do that. The “requirements document” was an incomplete user interface specification authored by a former employee. With no mortgage experience, I had to improvise test data, watch it break the system, and collaborate with developers to resolve issues. For two years, we watched the scope balloon as we adjusted to change after change driven by overlooked areas of the business, the introduction of new products, and failed integrations.

If we had used the methods you will read about in Mastering the Requirements Process, many of those problems would have been avoided. We would have properly identified all the systems we needed to interact with and the interactions between them. Working through a list of business events that could occur as a mortgage is processed and funded would have shown us the full scope of functions we needed to build. It would have been obvious that the initially planned scope and timetable were impossible from the beginning, and we would have been able to respond to that reality early on rather than dealing with constant unpleasant surprises.

Still, we got it functioning despite our “process” and not because of it. As I struggled through the project, I began looking for books and other resources to help me get better at this—after all, I knew I wasn’t the first person to run into this kind of problem, and others must have come up with solutions.

Eventually, as I continued my search for better ways of doing things, I was introduced to a group of people who were working to create a professional association: the International Institute of Business Analysis. As a member of its board and executive leadership team, I led the development of the Business Analysis Body of Knowledge (BABOK Guide) through multiple revisions and translations, with the goal of helping other business analysts get better at delivering change.

Very early in developing the BABOK, we asked ourselves what it meant to discuss business analysis as distinct from requirements engineering. Business analysts craft software requirements to solve business problems. Our job isn’t just to ask stakeholders what they want an application to do but to discover what they need and how to make their businesses work more effectively. Our mission is to change the business to accomplish its purposes more efficiently and effectively.

In Mastering the Requirements Process, the Robertsons will show you how to apply a business analysis methodology that has been honed and refined for decades. It is rooted in solving business problems, not just developing a software application. Their methodology, Volere, is designed to guide you from identifying a business problem and exploring alternative ideas for possible solutions, to selecting the one that is the best fit and then developing detailed requirements and testing and validating a working solution. This method doesn’t just scratch the surface; it takes a deep dive into your stakeholders’ goals and objectives and the value a proposed solution will create for your customers. It starts by exploring the context of your system, as defined by the business events it must respond to, the outcomes that should result from those events, and the interactions it will have with other systems and stakeholders.

Modern software development practices have progressed beyond big-bang waterfall approaches, and Volere has progressed alongside them. In this book, the authors show you how Volere can be tailored to your organization’s and industry’s demands. Whether you work in a highly regulated business environment that must comply with rigorous oversight of systems development or in a startup that can see shifts in the business environment overnight, the guidance in this book will prove invaluable. Mastering the Requirements Process is filled with examples of how the processes in this book can be adapted and modified to meet the demands of your project, business, or industry.

Volere is not just about defining the project and solution scope; it’s a comprehensive methodology that equips you with practical, tested tools and advice. Reading Mastering the Requirements Process is like having an expert by your side as you navigate these challenges. It advocates the use of prototypes to explore the solution space and help customers articulate their needs and desires. It delves into identifying and defining use cases and user stories in response to business events and effective acceptance criteria to ensure that your system delivers the required business outcomes.

Mastering the Requirements Process would have made my professional journey much easier if it had been available. I’m glad it exists today to guide the new generation of business analysts. Whether you’re facing your first project as a business analyst or you’re an experienced professional looking for ways to have a greater impact on the organization you work for, this book is a vital resource that belongs on your bookshelf.

Kevin Brennan

Business Architect & Professor

May 2024

Preface

In the years since the third edition of this book came out, much has happened. America has had three presidents; the United Kingdom got through five prime ministers; electric cars, some of them capable of autonomous operation, became mainstream; the Large Hadron Collider came online; we had the COVID-19 pandemic, which gave rise to remote working; personalized medicine advanced significantly; wireless earbuds became ubiquitous; social media and smartphone apps had explosive growth; smart homes let people turn on the oven remotely; fortunes were made and lost on crypto currency; and online dating brought automation to romance.

Given the significant changes to our world, we thought it was time to revisit requirements discovery and how it has been changed (for the better) by collaborative requirements documents, artificial intelligence, the ubiquity of off-the-shelf solutions, recognition of the business analyst role, and more.

To bring the subject up to date, this edition is an almost complete rewrite of earlier versions.

For example, we spend a lot more of the book on how quickly sketched prototypes can be used to explore the problem space. (They are also used to explore the solution space, but that comes later.) We have had success with teams that show their rough prototypes, or candidate solutions, to stakeholders. The stakeholders are asked to question their business problem by trying to explain why a candidate would, or equally importantly, would not, solve the problem.

Off-the-shelf solutions have become very much a part of today’s development initiatives. We prefer to call these “ready-made solutions,” as while they can be something that is bought “off the shelf,” they can equally be a legacy solution, or part thereof, some open-source product, or something borrowed from headquarters. Whatever its nature, there is a need to determine if in fact a ready-made will be a good fit with the organization, and following that, what requirements are there for successfully deploying the ready-made.

Agile development techniques have become more mainstream since the previous edition. In this one, we assume that the BA might prefer to write agile stories and use a story map to writing the traditional specification. That said, the traditional specification still plays an important part in a large number of development initiatives. We needed to write about both.

Speaking of agile, we have often been asked, “As a business analyst, how do I work with agile development teams?” This is obviously an important issue for business analysts, product owners, and agile team members. We have set out a way that requirements discovery and agile development can synchronize and be more effective together.

We also needed to more closely examine the “early days” at the outset of an initiative. One of the consistent factors of failed projects that we have noticed is the lack of clear objectives and solid vision of what the initiative is meant to achieve, and why. The “early days” is the time in a project’s life when the crucial decisions are made. We look at how a team can set their objectives, and thereby dramatically increase the chances of success of the project. The “early days” is when a business analyst makes some of his most valuable contributions.

In this and previous editions, we write about Volere. Volere is a framework for discovering, recording, communicating, and managing requirements. Over the years, Volere has evolved. It has been used on many types of projects, and the feedback from them provided improvements to both the technical aspects of Volere and its sociological ones.

This edition brings the subject up to date, and answers the many questions we have been asked by the business analysts and product owners over the past few years. We hope that it also answers some of your questions.

London, May 2024

Register your copy of Mastering the Requirements Process, Fourth Edition, on the InformIT site for convenient access to updates and/or corrections as they become available. To start the registration process, go to informit.com/register and log in or create an account. Enter the product ISBN (9780137969500) and click Submit. If you would like to be notified of exclusive offers on new editions and updates, please check the box to receive email from us.

Acknowledgments

There are three names on the cover, but it needed the contributions of others to make this book what it is.

First, we need to acknowledge the time and effort put in by our technical reviewers. In no particular order: Adrian Reed, Debbie Paul, Karl Wiegers, Kevin Brennan, Nick de Voil, Shane Hastie, Kathy Reynolds, Aase Tvieto, Penny Pullan, and Stephen Mellor. All of them made valuable contributions to this book by correcting our errors, pointing out places where we were pedagogically wandering off piste, and making suggestions that made significant improvements. We also need to acknowledge Kate Elizabeth Robertson for her help with the nursing examples. A heartfelt thanks to all of you.

Haze Humbert led the team at Pearson, and without her efforts the book would not exist. It was she who wrangled this book from the beginning. Her guidance, encouragement, patience, discipline, and general wisdom have helped us enormously. Thank you, Haze, and thank you Menka Mehta, you made things work so smoothly. Audrey Doyle put in a heroic effort to correct the manuscript. That this book is readable is largely due to Audrey’s turning garbled sentences into readable prose. We also want to acknowledge the exacting work done by the production team: Sandra Schroeder and Julie Nahil at Pearson, and Maureen Forys at Happenstance Type-O-Rama.

Thank you everybody.

About the Authors

James and Suzanne Robertson have been leading voices in the requirements and business analysis arena for quite some time. The popularity of their books and courses attests to the efficacy of their requirements techniques and their communication skills.

James and Suzanne gave up managerial positions in Australia to move to Europe to travel and take on freelance work. After leading various projects, they moved to New York and ran the seminar division of Yourdon. At the time Yourdon was the preeminent training company in the United States.

The Robertsons cofounded the Atlantic Systems Guild with fellow Guildoons Tom DeMarco, Tim Lister, Steve McMenamin, and John Palmer. Later, Peter Hruschka joined them from Austria. The Guild is a think tank in the business analysis and associated areas, and for years operated out of a loft in the meatpacking district of New York. To date, the Guild has published 49 books. This edition brings up the half century.

Away from work, James and Suzanne enjoy cooking for themselves and having friends around for dinner. Their food repertoire is wide: There is a lot of Asian food, especially Japanese (the Friday night sashimi is amazing). French, Italian, and British also compete for a place on the dining table.

James and Suzanne live in a 200-year-old house in London. When not taken up by writing and house repairs (a 200-year-old house needs more maintenance than a 20-year-old software system) they ski and hike in the French Alps.

Part I

Requirements Are the Root of Everything

This is a book about business analysis and requirements discovery. We need to discover the requirements because they underpin everything we build or buy. The requirements for the house or apartment where you live had to be established before the building was erected. There are also requirements for the phone you carry around. These must be carefully discovered before the phone goes into production. A quick online search will reveal dozens of phones that failed in the marketplace. They failed because they did not meet the requirements of the buyers or they had too many features that nobody needed.

Apart from phones, there are countless examples of failed products and failed projects. The lesson from all of them is clear: Requirements have to be right before anything can work correctly.

Let’s turn away from failures and look at our changing world. Change means that in order to remain relevant, your approach to requirements discovery must adapt to each new situation.

For example, the widespread adoption of agile techniques means that business analysts are becoming part of the agile team and are discovering the requirements in sync with the agile team’s development efforts. Business analysts are now writing both stories and conventional requirements.

Off-the-shelf (OTS), or as we prefer to call them, “ready-made,” solutions now make up a significant part of most business solutions. The business analyst’s role with ready-mades is to help find the most appropriate combination of ready-made, legacy, and new-build solutions and to ensure that the result is a seamless fit within the organizational ecosystem.

Artificial intelligence (AI) is changing the landscape. AI has become a part of many business solutions, and like everything else, AI needs requirements. This time, however, the requirements are written as prompts, but the same principles apply. The correct prompts are needed for the AI bot to function correctly as part of your business solution.

AI also plays a significant role as a smart assistant to the business analyst. AI might help you check specifications, suggest requirements, or find ready-made solutions. The possibilities are endless and exciting.

There is an emphasis in this book on using rapid prototyping to explore both the problem space and the solution space. We are advocating that quickly sketched prototypes help you and your stakeholders visualize and better understand the real business problem. We also suggest that sketched prototypes are a way of unlocking the team’s creative potential and coming up with innovative and valuable solutions.

Despite all the advances in our businesses and our technology, there is still a fundamental truth that underlies everything: the fundamental need to understand the problem and discover the requirements for a solution to that problem. This is a theme that we will return to throughout the book—the need to get the right requirements for the right solution to the right problem. This is probably the only facet of business analysis that has not and will not change.

So let us look at some of these fundamental truths—principles that guide and inspire your requirements discovery.

1

Requirements Fundamentals

Requirements Fundamental 1

Requirements are not really about requirements.

Requirements exist. As soon as you have any business activity, you have business needs. Requirements are a description of what your solution must do to satisfy those needs. This means that requirements exist whether you discover them or not and whether you write them down or not. However, for any solution to succeed, you, the business analyst, must discover all its requirements.

That said, the requirements activity is not principally about writing requirements or stories (for the moment, we’ll treat these as equivalents). Instead, the critical part of the requirements activity is understanding your customer’s business problem. The art of requirements discovery is discovering the real problem and not an apparent one. Once you do that, you have the basis for building the solution that satisfies your customer’s needs.

“Business,” “business problem,” “problem space,” and “work” all mean whatever activity your customer is concerned with, be it commercial, scientific, academic, government, military, cloud, web, mobile app, or any other kind of activity, service, or consumer product.

Requirements Fundamental 2

If your solution does not have to satisfy a need and produce a desired outcome, then you can build anything.

However, if it is meant to satisfy a need, then you must understand that need in order to build the right solution.

The word “solution” might mean a software solution, but it also refers to holistic solutions that incorporate human activity, machines, AI, ready-made software, or any other mechanism.

We have found that the most useful solutions are those for which the business analysts and the solution builders have a correct understanding of what the solution is intended to accomplish. This understanding comes from an intimate knowledge of the work that your customer’s business does now. Additionally, you need to understand how that work should be carried out in the future.

We use the term “requirements” to refer to a description of a business need. The requirements specification can be written as a set of atomic requirements, stories, models, or some combination of these.

When these points are understood and agreed to, then the requirements discovery is about rapid exploration of the problem space to determine what is needed by the business to make the most beneficial improvements. The result of this is a specification of a solution that will bring about these improvements. You might write this specification as a set of atomic requirements, or you might prefer stories, or models (we shall discuss stories, models, and other requirements artifacts in subsequent chapters), or some combination that describes the functionality of the solution (what it will do) and the quality attributes of the product (how well it will do it). For the moment, let’s refer to these as the requirements. Without knowing the requirements, there is little chance that any solution emerging from the development project will be of much value. Apart from a few fortuitous accidents, solutions fail unless their requirements have been understood.

“ On two occasions I have been asked, ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. ”

—Charles Babbage, speaking about his Difference Engine, one of the early (about 1820) mechanical forerunners of the modern computer

This truth must emerge: You must come to the correct understanding of the requirements, and have your client agree to them; otherwise, your solution or your project will be seriously deficient.

Requirements Fundamental 3

Any solution must be beneficial for its customer.

The customer is the person or organization that is the ultimate possessor of the solution. This could be an organization that acquires the solution for its business, or an individual who buys the solution for work or another reason. The term “user” is used as an alternative to “customer,” as either is the ultimate possessor of the solution. The customer might pay for the development of the solution or might also buy (or be given) the solution.

A note on roles: The person most responsible for discovering and analyzing requirements we call a business analyst. The product owner manages and prioritizes the product backlog of requirements or stories to be developed. A developer, sometimes called the solution builder, is the one writing the software. For non-software solutions, other equivalent roles apply.

The customer pays for any disruption to the business that happens when the solution is deployed. On the other side of the ledger, the customer should receive a net value from your solution. To describe that relationship very simply, your customer is buying a benefit.

Figure 1.1

Requirements are the root of everything. Good roots: good solution. Bad roots: bad solution.

Part of the role of the requirements discoverer is to determine what the customer values. In some cases, providing a small system that solves a small problem provides sufficient benefit for the customer to consider it valuable. In other cases (perhaps many others), finding a solution with more extensive capabilities provides a much greater value, but comes with a much higher price tag. The choice depends on what your customer values, and how much she values it.

Requirements Fundamental 4

There is an important difference between building a piece of software and solving a business problem.

Many software development projects concentrate solely on the software. This might seem reasonable—after all, most software projects manage to produce some software. However, concentrating almost exclusively on the software is a little like trying to build the Golden Gate Bridge by concentrating on steel. The software, if it is to be valuable to the customer, must solve the customer’s business problem.

We build an awful lot of software. Millions (if not billions) of lines of code are produced each year. Much of this code produces the wrong results—it simply does not solve the correct problem. And yet, this is not down to poor requirements, it is down to the project rushing into building a presumed solution without discovering the real requirements.

We cannot stress enough that software is there to solve a business problem. Clearly, then, any development effort needs to start with the problem, and not with a presumed solution.

Requirements Fundamental 5

Requirements do not have to be written in any particular way, but they have to be correctly understood.

It sometimes seems that the aim of the requirements activity is to produce the largest specification possible. It doesn’t seem to matter that very few readers can understand much of it, and that even fewer will read it. It appears that the requirements writers believe that their work will be appreciated in direct proportion to the magnitude of the specification.

The form of your requirements output (we shall talk later about storing the requirements in a repository) can be varied. But whatever form you choose, it must record clearly and accurately whatever has been decided and agreed. These written requirements must precisely transfer thoughts from the mind of the customer into the head of the developer, or the person selecting one of the available ready-made solutions.

You will find that when your requirements are in a written form, you and your stakeholders can see them and question them, all of which helps to make them precise. Later in this book we shall discuss different formats for your requirements, and additionally how you can make them unambiguous and easy to understand.

Requirements Fundamental 6

Your customer won’t always give you accurate information. Sometimes he just doesn’t know what he needs.

Requirements discovery must consider the difficulty stakeholders have when they are trying to describe what they need. It is no simple task to envisage a solution to the problem, particularly when the problem is not always completely understood. Given the complexity and scale of today’s businesses, it can be very difficult for individuals to understand all the appropriate parts of the business.

In this book we advocate the use of quick prototypes (sketches, process models, scenarios, simulations, etc.) as safe-to-fail experiments. We use them to rapidly explore the problem space. We know that when customers see and experiment with tangible diagrams and models, they are more able to articulate their problem.

The business analyst must perform a juggling act. In some cases she must record the customer’s request; in some cases she must persuade the customer that what is being asked for is not what is needed; in other cases she has to reengineer the customer’s presumed solution to find the real business problem; and in some cases she must come up with an innovation that is not what the customer asked for, but results in a better solution. In all cases, she should not believe everything she is told.

The tricky business of pronouns: We, the authors—one male, one female—think that constantly reading “he/she” and “his or hers” is jarring and disrupts the flow. Similarly, we think that using “they” instead of a gender pronoun is awkward and depersonalizing. So, we have opted to intersperse “he” and “she” randomly.

Requirements Fundamental 7

Good solutions do not come about by chance. There needs to be some kind of orderly process for developing them.

Any meaningful endeavor needs an orderly process. Random applications of steel and concrete do not produce buildings; there is a defined process for designing and erecting such structures. Similarly, there is a defined and systematic process for making movies. Your motorcar was designed and built using orderly processes, and your last airline flight was the result of a set of orderly processes that were followed verbatim (you hope). Even artistic endeavors, such as novels and paintings, have an orderly process that the artist follows.

These processes are not lockstep procedures where you mindlessly follow every instruction without question, in the prescribed sequence, without variation, ticking all the boxes as you go. Instead, orderly processes comprise a set of tasks that achieve the intended result, but leave the emphasis and degree of application to the person or team using the process.

In the next chapter, we show you the Volere¹ requirements process; an orderly process for discovering the requirements and determining the best solution for them. As we go through the book, we shall look in detail at the activities of the Volere process.

FOOTNOTE 1

Volere is a framework for discovering, communicating, and managing requirements at all levels and in all environments. It has been used and adapted over several decades in commercial, industrial, governmental, and academic environments. The intention is to provide business analysts with the appropriate degree of formality for their own situations.

Most importantly, the people who are active in the process must be able to see why different tasks within the process are important, and which tasks yield the best value for the requirements and development effort.

Requirements Fundamental 8

Requirements, if they are to be implemented successfully, must be justifiable, measurable, and testable.

Adding a justification to a requirement—the Rationale in the Volere format; the “So that” line of a story (more on these later)—means that you are displaying the value of that requirement. Adding a measurement (the Fit Criterion of the Volere format; the acceptance criterion in a story) means that your customer can tell you whether it is exactly what is needed. Additionally, the developers and testers of the solution can define test scenarios allowing them to ensure that it does indeed comply with its requirements, and thus contribute to solving the business problem.

Any requirement can be measured, even the softer look and feel or usability ones, as we’ll see later. It is safe to say that if you cannot find a measurement for a requirement, then it is not a requirement, but merely an idle thought.

Requirements Fundamental 9

You, the requirements discoverer, will change the way the customer thinks about his problem, either now or later.

When you come to understand the requirements, especially when they come from different stakeholders, you start to build prototypes and abstractions, and establish a vocabulary. When you present your prototypes and models of the business processes, when you work with the stakeholders to find the essence of the work, when you have clear and measurable requirements, and when you reflect your findings back to the stakeholders, it will change (for the better) their thinking about their business problem.

Once people have a better understanding of the real meaning of their requirements, they are likely to see ways of improving them. Part of your job is to help people, as early as possible, to understand and question their requirements so that they can help you to discover their problem, and what they need to solve it.

2

Your Requirements Arena

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.

Requirements don’t just happen. There has to be some kind of orderly process for discovering and refining them.

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.

Think slow, act fast.

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”¹ 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.

FOOTNOTE 1

This expression comes from Bent Flyvbjerg, a mega project expert, in his discussion on why projects fail. Flyvbjerg shows how doing the proper planning avoids the catastrophes that many projects become. He expounds on this in the book How Big Things Get Done (Macmillan, 2023), which he coauthored with Dan Gardner.

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.)

Testing a prototype is less about seeing if a solution works and more about seeing if it provides an outcome that the customer finds valuable.

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.

This prototyping approach enables the team to rapidly explore the problem space.

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.

A milspec specification must be complete and provable.

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.

Ready-made solutions are part of your requirements discovery.

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.

Review

Our intention in presenting the above three scenarios—Kodiak, Grizzly, and Polar—is to demonstrate that the process is meant to be flexible. Different projects and different teams use it differently according to what they need to accomplish.

It is extendable—you can add your own techniques into the mix. You would do this when you have some specialized technique you want, or need, to use. For example, your organization might use data mining, and you make this an extension of Trawling.

It is methodologically agnostic. As we showed with the Kodiak project, it links with and synchronizes with agile development techniques such as Scrum or one of the other development techniques. As shown in the Grizzly project, you can use a serial or waterfall approach and produce a complete specification before development; or as the Polar project did, use an iterative approach and produce a phased delivery of the solution.

For the rest of the book, we shall look at the activities and deliverables of the process in more detail. This will give you an appreciation of what each one of them does, how to do it, and where it would be most appropriate.

By the way, the book is meant to be flexible too. Jump between the different parts according to your needs.

Part II

Project Blastoff

One of the joys of product development, whether it be software, service, or hardware, is getting it right. Getting it right means delivering an end result that fits perfectly into your customer’s business and solves a business problem that your customer needs to have solved. It should also provide value to you and your key stakeholders.

How do you make that happen?

Let’s start by not presuming to know the solution. That’s worth repeating: Until you fully understand the problem, and the true extent of the problem, any proposed solution is no more than a presumption. Of course, it is hard to resist the siren call of a bright, shiny solution that seems so cool and, let’s face it, fashionable (see Figure P2.1). But does that solution really work in the context of your customer’s business? Does it provide genuine value? Is it solving the full extent of the problem? Is there a solid business case for developing a solution?

Figure P2.1

Presuming to know the solution doesn’t always work.

Presuming to know the solution can be expensive. Every year, thousands of IT projects are abandoned, or they are completed and the delivered solution is soon discarded because it fails to solve the real business problem. Millions and millions of dollars (or euros) are wasted by these projects, and worse, they have consumed resources that could well have been employed for gainful purposes.

“ Projects don’t go wrong so much as they start wrong. ”

—Bent Flyvbjerg, How Big Things Get Done

Instead of presuming, let’s think about delivering the right solution. To do this you start by setting a solid foundation for the project. We call this foundation-building activity Project Blastoff—it gets the project off the ground.

The Blastoff activity is a meeting of the key stakeholders. Its purpose is to achieve agreement about the problem to be solved, the scope and size of the problem, and the people involved in the problem. There is a strong connection between these factors, and by establishing them, the requirements team can proceed with confidence that they are heading in the right direction and are on the road to delivering the right solution. The Blastoff activity is highlighted in Figure P2.2.

Figure P2.2

The Project Blastoff activity establishes the trajectory of the project.

The Blastoff brings together the decision makers and people with authority to decide on the direction of the initiative. These key stakeholders reach a consensus on the right business problem to solve. They also determine the scope of the problem. As part of the Blastoff meeting, the stakeholders agree on measurable goals of the development effort. We have more on these deliverables in Chapter 5, Goals-Scope-Stakeholders.

The Blastoff confirms that the goal is realistic and achievable, the problem to be solved is well understood, and the people involved are willing and appropriate. Without these things, any project may well wander in a cloud of uncertainty until it falls off the cliff. With these things you have an arbiter throughout the project of what is within and what is beyond your scope. You also have a measurable objective to keep the team focused throughout the initiative. And by knowing the appropriate stakeholders, you have a constant reference to your sources of information.

The decisions you make during Blastoff are the most important of the whole project. Take whatever time is needed to make them wisely.

3

Understand the Real Problem

There is a difference between a problem and a solution. The solution is meant to solve the problem, but it can only do so if the problem is properly understood. The problem is that we don’t always know what the problem is.

Any software and/or hardware system, any consumer product, or any offered service exists to solve its customer’s business problem. If it fails to solve the customer’s problem, then it is useless. Some products are built to provide entertainment, and again, if they fail to entertain, they are useless.

The problem is that we don’t always know what the problem is.

And yet, each year millions—perhaps billions—of dollars are spent on projects that deliver solutions that fail to solve the right problem, or fail to solve any worthwhile problem at all.

Sometimes the damage is relatively small. A project runs for six months, maybe a year or so, before the customer pulls the plug saying that the solution so far is not what they need, nor will it ever be.

Sometimes huge amounts of money are spent before it becomes evident that a solution is not solving the real problem. For example, in the United States, the Federal Aviation Administration’s Advanced Automation System for air traffic control cost between $3 billion and $6 billion before being scrapped. Försäkringskassan SAP, a dental health service system in Sweden, cost the equivalent of $1 billion before the project was declared not fit for purpose and canceled. In the United Kingdom (failed projects are a global phenomenon), NHS Connecting for Health, a patient records system, was mostly scrapped after burning through £12 billion. Among other failings, it failed to solve the real business problem. Standard Business Reporting, a system being built for the Australian Taxation Office for electronic reporting, had a take-up rate of 2% to 3%. Clearly it was not solving any problem that 97% of its intended customers had.

Technology was not the cause of these failures. We can build technology to do almost anything; we can write software to do most things that we can imagine; we can build services and consumer products to do most things short of abolishing gravity. No, the failures cited above came about because they didn’t solve a problem that their customer had; they were solutions built without first understanding the problem they were meant to solve.

Look at your project’s budget. How much of it is allocated to investigating the business problem versus building the solution? How many people on the team are doing problem and requirements discovery? If the answers are “not much” and “not many,” you have to ask why the most fundamental part of the project—the business problem to be solved—is receiving so little attention. It’s like building a car without knowing what kinds of roads (if any) it is meant to be driven on, how many passengers it is meant to carry, and what market segment it is aimed at.

All too often, we presume to know the solution and rush into building it without enough knowledge of the problem it is meant to solve. All too often, this approach fails. Our solutions have one thing to do: Solve the real business problem. So, let’s look at how we discover what that problem is.

The Problem

Florence Nightingale (1820–1910) was an English nurse serving in the Crimean War (1853–1856), which was fought between Russia and the Allies (history tends to repeat itself). It was through her work there—she organized care for wounded soldiers in Constantinople—that she became regarded as the founder of modern nursing. Nightingale realized that soldiers were dying, not from their wounds, but from infections picked up in the hospitals. See Florence tending her soldiers in Figure 3.1.

Figure 3.1

Florence Nightingale discovered why the soldiers were dying.

Once she understood the real problem, she could solve it. Nightingale set about cleaning the hospitals and spacing the beds farther apart. This stopped soldiers being infected by the hospital itself and prevented them from infecting each other. Many lives were saved due to her understanding of the real problem to solve.

A problem, as we use the term here, is a business situation that requires intervention. Sometimes a problem arises because something has gone wrong, but usually the problem comes about because of change. Often this is a change to the ecosystem that surrounds the customer’s business: The laws for that industry sector change, customers change their behavior, or one of the adjacent systems changes its connections to the business.

Sometimes there is a change that presents an opportunity—a technological advance means that the customer can do some of the business differently; changing market sentiment allows new products or services to be developed.

Any kind of change presents a problem. Some of these need to be solved.

Whatever it is, there is a change that necessitates your customer either changing or replacing part of his business. Sometimes the change is generated internally—your customer has the opportunity to do something differently or do something different.

“ Problems are only opportunities in work clothes. ”

—Henry J. Kaiser, American industrialist

Whatever its origin, there now exists a business problem that you need to discover and understand before you can solve it.

The Real Business Problem

It is obvious that if your solution doesn’t solve the real business problem, then it is a waste of time and money. The industry you work in and the organization you work for are usually good at solving problems. But first they must discover the real business problem.

There are several factors involved in finding the real problem.

Don’t presume to know what the problem is.

The first thing is not to presume to know what the problem is. In the Florence Nightingale episode above, the presumed problem was that the soldiers’ wounds were causing them to die, and so the effort went into treating the wounds. Nightingale chose to stand back and ask if that was really the problem. From that came the understanding that it was the infections the soldiers picked up in the none-too-clean hospitals that were causing most of the fatalities.

Then there is scope. Your scope of study must be broad enough for you to be able to see enough of your client’s business to understand what it is meant to do. We will look at scope in Chapter 5, Goals-Scope-Stakeholders, and urge you to pay attention to it. The problem is often wider than it first appears to be, so include anything that might be part of the problem. It is always easier to cut back later than to add things later.

The next factor in finding the real problem is the presumed solution. This happens when the client, the project leader, the manager, someone, insists that they know the solution. They don’t know the solution; they presume to know the solution. And the further presumption is that the team should now rush ahead and build this presumed solution. Unless the problem is trivial, presuming to know the solution is unlikely to lead to the delivery of the correct solution.

“ If I had five minutes to chop down a tree, I’d spend the first three sharpening my axe. ”

—Abraham Lincoln

Similarly, some projects suffer because someone has a cherished solution and insists that it is the one to build. Clinging to a cherished solution prevents people from seeing the problem they are meant to solve. You also find teams that solve the problem they want to solve. These teams operate on a “Never mind the problem, this is the solution we think we should build” basis.

Presumed solutions usually hide the real problem.

So let’s turn our backs on presumed solutions and consider real problems. The real problem is the business situation that requires a correction of some kind. Consider the following examples of business situations needing a business analyst’s intervention.

● “Our level of fraudulent use is well above the industry average.”

● “It is not possible to verify foreign credentials.”

● “The law has changed, and we are no longer compliant.”

● “Malicious cyber activity threatens our customers’ ability to access their bank accounts with complete security.”

● “Some of our solutions do not comply with the GDPR (General Data Protection Regulation).”

Alternatively, the business situation might present an opportunity.

● “Developments in electronic payment systems allow us to offer more convenient ways for our customers to pay for their goods.”

● “Advances in in-car entertainment systems mean that we can present our content to drivers and their passengers.”

● “People are more mobile, and we want them to be able to listen to music wherever they are.”

These are business situations—they reveal the problem to be solved. For example, “Some of our solutions do not comply with the GDPR.”¹ The business problem is noncompliance, and you start with that.

FOOTNOTE 1

The General Data Protection Regulation is a European Union regulation that has now been adopted worldwide. It sets the standard for privacy and the protection of private data. In most countries, noncompliance can bring hefty fines.

There are several presumed solutions—upgrade the solutions to make them compliant; outsource the problem to GDPR experts; buy new solutions that are compliant; ignore the problem and risk the fine—but none of them can be the right solution. Until you understand the problem, guessing at solutions is unproductive.

Instead of guessing which solutions might work, let’s look at what you might do to uncover the real problem.

Step Back

To see the real problem, you must step back far enough from it to see the wider picture and all the factors that can influence the problem space.

For the GDPR situation, stepping back means finding all the data that is noncompliant, whether that data is important, which solutions use that data, where in the organization the data is used, and more. What you are discovering here is the extent of the noncompliance and what impact that has on the organization. By knowing enough about the problem, you can make the right decision on what to do about it, whether it is serious, or whether the impact of noncompliance is so minimal that it can safely be ignored.

Ask Why

Figure 3.2

Step back and take a wider view of the problem.

Why is the organization noncompliant with the GDPR? Because nobody upgraded the solutions to make them compliant. Why did nobody do it? Because nobody is assigned to the problem. Why is nobody assigned? Because the organization has no mechanism for this kind of compliance work.

You might ask why a few more times, but this seems to be at the root cause of the problem. In other words, the problem is that the organization is unable to remain compliant. There might be other solutions that are also noncompliant; it depends on how far you stepped back, as described above. In Figure 3.2, every time she steps back, she gets a broader view of the problem.

Is There Some Underlying Factor That Causes the Presumed Problem?

Asking why a few times revealed the underlying factor, which is a systemic problem. That is, it has no institutionalized way of ensuring compliance. As regulations and laws changed, they were either incorporated into existing solutions on an ad hoc basis or ignored. This underlying factor points again at the problem, which is that the organization is unable to remain compliant.

What Is the Root Cause of the Situation?

This is the same as asking why several times. Your intention is to get to the source of the problem, and not to see the manifestation as the problem. In other words, you need to treat the cause, not the symptom. The cause here is the lack of a mechanism for continuously ensuring compliance, which is another way of stating the problem.

Are There Any Assumed Constraints in My Perception of the Problem? Or Does It Contain Elements of a Solution?

These two things are similar, so you can treat them together. If you say that the problem is that the organization is unable to remain compliant, then there is no constraint or solution present. On the other hand, if you had said that the problem is that the IT department has no compliance person, then that introduces a constraint—the problem belongs to IT—and a solution—the person to check for compliance.

By removing the constraint and the assumed solution, you arrive at a problem statement where the problem is owned by the organization. This is correct, as there is no other entity that can own it—the problem is the organization’s problem. Checking for and removing constraints and solutions from your statement of the problem usually results in a clean definition of the real business problem.

The exception that allows technology in your problem statement is when that technology is an external constraint. For example, “Customers can pay using credit or debit cards, bank transfers, or PayPal.” Those payment methods are outside your scope and are part of the physical world (the business ecosystem) that your solution will eventually be part of.

If I Solve the Problem, What Will the Measurable Effect Be?

We could be cynical and say that the measurement is the lack of fines the organization is being hit with. However, it is better to measure the effect on the organization. A compliant org is a happier place, and as there is now a mechanism in place to ensure continued compliance should the GDPR change, the measurement now shifts to the organization’s ability to react to changes in other laws. In other words, by solving this problem, the organization will solve future compliance problems more easily. If you want to express this in monetary terms, you will need to estimate the savings and efficiency of future maintenance to ensure compliance.

The Goal Statement

The goal is to solve the real problem.

Your project has a goal, and that goal is to solve the real business problem. We have been discussing ways of finding the real problem. So now let’s say that you and your stakeholders have reached an agreement on what it is. Furthermore, you have agreed that this is not only the real problem, but the right problem to solve. That is, it is beneficial to the organization to find a solution for it.

You should write a goal statement for the project. Without it, there is a real danger that the project wanders off course, or that team members lose sight of what they are meant to be doing. We suggest that writing a goal statement helps reveal whether you have found the real problem, and the best way to write it uses the format purpose-advantage-measurement.

The purpose is the desired business outcome of your development effort. When you write a purpose statement, it should point at an outcome and not at a presumed solution. For example, the purpose is not to build a website, the purpose is to sell our product to customers who predominantly use mobile devices.

Let’s take an example and see how it unfolds.

Residents of a suburban community have been complaining about traffic in the streets. The residents feel that people are driving far too fast through their neighborhood. They are concerned about letting their children play outside, as they feel it is unsafe. They also complain about the noise and volume of traffic.

Let us say that you work for the local government authority and have been handed this problem. What is the real problem? Is it that there are too many complaints from residents? If that is the problem, then you could solve it by blocking off all mechanisms that can be used to complain.

But it appears that the problem is the traffic itself. However, you cannot banish all traffic from the neighborhood. The residents (these are the people who vote in local elections) would be extremely unhappy if they could not drive to their own homes.

So, it is not the existence of traffic, but the way the traffic behaves. Let’s take a stab at writing the purpose statement:

Purpose: The purpose of the project is to regulate traffic on suburban streets.

However, “regulate” is a solution—it’s an action to take. The risk of statements like this is that the development team can easily end up building the wrong solution. If we replace that presumed solution with the desired business outcome, the statement looks like this:

The goal is not to build a solution, but to solve the business problem.

The purpose is to have less traffic, for it to flow at an even speed within the posted speed limits, and to reduce the number of accidents.

There is no mention of how that might be achieved. That would be determined by the business analysts studying the situation and discovering the requirements for an even traffic flow.

That appears to be the correct goal. Correct in that it addresses the real problem of speeding vehicles, uneven flow resulting in stopping and starting, and accidents caused by disparate vehicle speeds. If the traffic were more even and within the speed limits, it would also feel safer to walk in the streets. (Assume that this is a community with footpaths beside the streets.)

Let’s take this a little further. Why do we want to have such a purpose? What advantage is there? The advantage part of the purpose-advantage-measurement format will confirm whether you are solving the right problem. To be the right problem, the advantage of having a solution to it has to be something that somebody wants. So, the advantage statement is this:

Advantage: Reducing the number and leveling the speed of vehicles will result in safer and more pleasant neighborhoods. There will be fewer accidents, and vehicle emissions will be reduced by eliminating stop-start traffic.

There are enough different customer segments that want this: the residents, the local traffic authority, the police, the environment. The last one is not, strictly speaking, a customer segment, but it will be a beneficiary of this initiative.

Purpose-advantage-measurement finishes with a measurement. In this case you could measure average speeds, the time it takes for a vehicle to traverse the neighborhood, and the number of reported accidents (evenly flowing traffic has been shown to reduce collisions between vehicles). The measurement is along these lines:

Measurement: The number of cars entering the regulated areas will not exceed 250 vehicles per hour and will travel within the posted speed limits. Traffic accidents will be reduced by 15% from current numbers. Residents’ complaints will go down by 25%.

Note that there is still no mention of how this is to be achieved, only what must be achieved. With this measurement, you can go back to the stakeholders and confirm whether this is indeed solving the real problem. From the residents’ complaints, it appears that it is.

However, when you present these outcomes to your stakeholders, it is possible that they realize that’s not what they wanted at all. In that case, you rework the purpose-advantage-measurement until you achieve agreement. You must have this agreement to ensure that you are solving the real problem, and that the rest of the development effort will deliver the right solution.

Review

Finding the real business problem and making sure that everyone understands it goes a long way toward a successful development project. It stands to reason that if a project does not solve the right problem, then any solution it produces will be useless. On the other hand, useful solutions are used—they do something that their customers need.

The Blastoff is the beginning of the journey, and the decisions you make early on are the ones that have the greatest impact. One decision—determination, really—is what problem are you solving? Note that this is the problem, not the solution. Solutions are easy to find; problems are a little bit harder. Perhaps this is why so many projects skip the problem bit and jump straight into a solution.

The business problem to be solved is independent of any potential solution. So, the best place to start is to look for the essence of the problem. (We’ll have a lot more to say about essence in Chapter 16, The Essence of the Problem.) Look at your statement of the business problem your solution is meant to solve. Does it contain any technology? Does it mention web, phone, software, cloud, internet, laptop, app, server, mesh, or anything else that is a way of doing something and not the something to be done? If it does, then it sounds like it is a description of a solution, and not a statement of the problem. Rewrite it, and keep rewriting, until you have erased any trace of any possible implementation. That’s when you have reached the essence of the problem.

And if you don’t have a technologically agnostic problem statement, or any statement at all, do not go past this point until you do. You can only reach a destination when you know what the destination is. Yours is to solve your customer’s business problem—but first you have to understand it.

Development projects fail for many reasons: politics, incompetence, lack of resources, and so on. But when it comes to successful projects, with the exception of some serendipitous accidents, none has ever succeeded without first understanding the real business problem it was meant to solve.

Resources

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), put out by the International Institute of Business Analysis, is a comprehensive guide to business analysis and requirements discovery. Chapter 2 covers planning a project’s business analysis.

How Big Things Get Done by Bent Flyvbjerg and Dan Gardner (Macmillan, 2023). This is an excellent book, and while it is not about IT projects specifically, the authors have very useful things to say about starting any project in the right way.

Be a Great Problem Solver—Now! by Adrian Reed (Pearson, 2016). This is a quick read and has some terrific tips for getting a project underway.

5 Whys: The Effective Root Cause Analysis by Oliver Roderich (self-published, 2021). A simple approach to finding the real problem.

Practical Project Initiation: A Handbook with Tools by Karl Wiegers (Microsoft Press, 2007). This is about building a solid foundation for your project. The author discusses some of the key project initiation practices.

4

The Value of Solving the Problem

In the previous chapter, we talked about finding the real problem. It is not always easy to do that, so you might prefer to come at it another way. Solving the customer’s real problem will provide value to him. So perhaps you might try starting by thinking about what value your solution will bring to your customer.

Start with a simple question: Does your customer value your solution? Simply because you deliver some software (or service or product) does not necessarily mean that the customer receives any value. The customer can only receive value if you solve the real problem. So, it follows that the real problem to solve is the one whose solution enables the customer to realize value when he uses it. The real problem and customer value are inseparable—discover the problem and it will lead you to the value. Conversely, if you understand what your customer values, it leads you to the business problem that the customer wants solved.

What Does Your Customer Value?

In this part of the book, we are talking about the Blastoff, and how its role is to establish the foundation for your requirements activity. This foundation is vital to your cause—it is where you determine whether your efforts will deliver the right solution. Part of being right is that the solution, when delivered, enables your customer to realize value from it.

Customer value is your customer’s perception of whether he received enough in return for his investment. We all experience this almost every time we buy something. You must have eaten at a restaurant and afterward thought, That was far too expensive for the quality of the food. You didn’t receive enough return for investing in the price of the meal—it was poor value for money. That jacket you bought years ago and still wear a lot—that’s good value for money. And that smoothie maker you don’t use all that often but got for a low price—to you, that’s still good value for money.

Of course, value is not always monetary value. We receive value when something provides a pleasant experience, or saves us time when we use it. Sometimes we value convenience. Sometimes we value something because it has a pleasing appearance, or makes us, in our opinion, appear better or smarter.

Your customers make the same kind of value decisions. Sometimes they are concerned with the price of your solution. For example, if the customer spends $100 to buy your solution off the shelf, does she perceive that she gets more than a hundred dollars’ worth of value from it? Sometimes the cost of development must be considered when assessing value. For example, if a company spends $1 million developing an actuarial solution, does the increase in accuracy of its statistics and calculation of insurance risks and premiums bring a benefit to the company?

In the previous chapter, we discussed goals and how you could state goals using the purpose-advantage-measurement construct. Value and advantage are the same thing, but we can look more deeply into value. For example, you saw this in the previous chapter as part of a purpose-advantage-measurement statement:

Advantage: Reducing the number and leveling the speed of vehicles will result in safer and more pleasant neighborhoods. There will be fewer accidents, and vehicle emissions will be reduced by reducing stop-start traffic.

This was stated as an advantage, but it can only be advantageous if someone values it. So, who values it?

● Value to residents: Quieter streets, more careful driving meaning the streets are calmer, people feel safer and are less worried about their children’s safety when walking on the sidewalks and crossing the streets

● Value to police: Constant-speed traffic, which has been shown to produce fewer accidents, thus fewer accidents to attend and fewer speeding tickets to write

● Value to the environment: Less pollution, as there are fewer emissions from steady-speed cars than from cars in stop-start conditions

● Value to the sponsor (this is the road authority): Safer streets, fewer complaints from residents, and less wear on the street surface

Not all of these can be monetized, but the well-being and environmental values make this a worthwhile project. Note that in the above scenario, the environment and the police were recipients of value. The police and the environment would not always be involved, but you should always look beyond the obvious customer to find others that could value your solution.

Most of the time you provide a solution to enable your customers to do their work. Value comes when your solution gives your customers an advantage when they use it. That is, the customers will be able to do their work in a better way.

Work often means sitting at a desk using a computer to do daily tasks. To provide value, your solution must make these tasks easier, more effective, faster, or more accurate, or it must provide extra functionality that enables the customer to do something that he could not do before.

Work can also include using an app to do online banking, get a boarding pass, or pay for something. Work can include some of the millions of things we humans do every day.

The point of understanding customer value is straightforward: During the Blastoff, you are establishing whether or not to go ahead and acquire a solution. One of the factors that you consider is whether that solution will bring value to the customers doing their work.

Functional Value

You enable functional value when your solution has functionality that solves the customer’s business problem. If the problem was so severe that it threatened to cripple the business, then your customer will obviously place a high value on your delivered functionality (providing it solved the problem). And if it does solve the problem, your customer might also be willing to spend more on your solution and still perceive it as valuable.

Sometimes functional value is achieved when your solution improves the customer’s business, usually by making some business process(es) easier or cheaper. This kind of improvement can be quantified, which makes it easier for your customer to assess value.

A value statement describes the value your customer receives when you solve her business problem.

You might consider writing a value statement. This is not strictly necessary, but the point of your project is to deliver value, and if you cannot articulate that value, then perhaps the project is not valuable.

A value statement clarifies the situation. It describes the value the customer receives when you solve his problem. This value statement guides the team in their requirements discovery and development. You can write your value statement any way you like, but we suggest something like this:

As a [type of customer]

I receive value when [outcome for the customer].

Functional value statements might be:

As a bank customer,

I receive value when I can see a projection of my current balance alongside my expected debits for the remainder of the month.

As a subscriber to a music streaming service,

I receive value when my family can share the music.

As a sales supervisor,

I receive value when all of my salespeople have immediate access to current inventory and can submit their customer’s order from wherever they are.

As head of claims,

I receive value when the average time needed for an accurate claim’s adjustment is less than 15 minutes.

The functional value might be delivered to the customer when your solution makes a business process cheaper or faster or more accurate:

As a delivery service to distribution centers,

I receive value when all my deliveries are completed within 30 minutes of the scheduled time.

We can conclude from this value statement that deliveries to the distribution centers were previously not very punctual, which might have had serious consequences. The functionality that provides accurate deliveries is valuable—it helps retain customers. If your solution makes money or saves money for your customer, then customer value will be proportional to the increase in revenue or savings. Of course, your customer will include the cost to develop or buy your solution in her assessment of value.

You might well have more than one functional value statement; just don’t have 50 of them.

Psychological Value

Psychological value is provided when your solution brings benefits such as pleasure, satisfaction, and convenience. Later in this book we talk about non-functional requirements such as usability and humanity requirements—psychological value is closely linked to that type of requirement. We also talk later about customer experience; that is also part of psychological value.

In many cases, projects are run to develop a solution whose main purpose is to provide a more pleasant/novel/exciting/easy/accessible/learnable/convenient/[insert your own adjective here] experience for its intended user. These are psychological values.

Value statements like this are appropriate:

As a supermarket,

I receive value when my customers find they prefer to use the self-checkout devices instead of the manned checkout desks.

That kind of value statement would need to be augmented by a measurement:

As a supermarket,

I receive value when my customers find it attractive to use the self-checkout machines,

And I will know this if within three months of their introduction to the stores, 65% of checkouts are completed using the self-checkout devices when human checkout operators are available.

Or:

As a music streaming service,

I receive value when my customers enjoy streaming from my service,

And I will know this when I have 85% customer retention.

Receiving Value

Figure 4.1 shows how value varies according to who or what receives the value. There is often more than one party who might receive value from your solution. It is worth considering them as part of determining that you are solving the real problem.

Figure 4.1

Value from the solution comes in different ways to different parties.

The Sponsoring Organization

The sponsoring organization usually wants the solution for its employees, and it is willing to pay for it. The organization either builds the solution through its in-house IT department or buys a ready-made solution. In some cases, the organization might commission a third party to build the solution.

Regardless of how it acquires the solution, value to the sponsoring organization comes when the solution improves the work of its employees. For example, the solution might enable the employees to do their work more efficiently and save money, enable them to do work that they could not do before and generate revenue, or enable their work to fit more readily into the organization’s infrastructure.

Naturally, the cost of buying or building the solution must be commensurate with the value of having the solution. Additionally, it might take several years before the investment in the solution pays off.

Your task as a business analyst is to help estimate the impact your solution will have on the workplace, and to help estimate the cost of acquiring it.

The Building Organization

The building organization—Microsoft, Adobe, Oracle, Salesforce, and thousands of others—receives value when customers buy their solution. The building organization receives value when it sells enough of its solution to offset the development costs and provide enough revenue to realize a profit. To assess this value, you must estimate the revenue from sales. Estimating sales is beyond the remit of most business analysts, but your part is to provide information regarding what potential customers would value.

One source of information on consumer value comes from Bain & Company. This management consulting firm built an excellent analysis of consumer values incorporating 30 elements of value. These are arranged in a hierarchical pyramid based on Maslow’s hierarchy of needs. The four levels of the pyramid are Functional, Emotional (we call this one psychological), Life Changing, and Social Impact. A link to Bain & Company is listed in the Resources.

Some organizations provide their solutions for free. These are the open-source providers that build their solutions using enthusiastic volunteer labor, and then distribute the solution freely. No money changes hands; the value comes from the satisfaction of providing an exemplary solution and having customers use it.

The other type of building organization is the one that builds a solution on commission from a sponsoring organization. These are software houses and outsourcing companies. Value is received by simply charging enough for the commission to make a profit.

The Customer as User

The customer as user is someone who is usually given the solution to help him do his work. Here you are looking at the value of making his work better. This might be enabling the employee to make better decisions, do the work more quickly, or make it more convenient, easier, or more error-free. You would assess the value mainly by productivity gains.

The Customer as Purchaser

The customer as purchaser is someone who buys the solution and receives value when it does something useful for her. For example, she might edit her photographs, or use a word processor to write a novel. Or she might receive value if the solution she bought is a game and she enjoys playing it. How much value she receives would depend on how useful or enjoyable the solution is to her.

Other Recipients of Value

There may be others. The solution might be something that is beneficial to the environment. For example, it could be a solution that reduces the number of deliveries that are made by the organization. It could be a solution that contributes to the local community. Let’s say that an HR solution provides as a by-product a web page of employees who are willing to spend some of their time volunteering for local charities or volunteer organizations.

Usually, solutions are built to bring value to the sponsoring organization, but we can always hope that others get some value too.

Review

Customer value needs to be part of your requirements activity. The purpose of any development project, whether it is to develop software, a consumer product, a service, or anything else, is to solve a business problem and by doing so, provide value to the customer of the solution. The organization sponsoring the solution must also receive value from the solution. If it does not provide value, then it is less than worthless—it has cost money to build, but nobody needs it.

Take the time to state up front what value your project intends to deliver. Please keep in mind that simply building the software/product/service does not necessarily deliver value. The value statements keep you and your team focused on what you are trying to achieve. Which means that all the time, effort, and money expended during the project is aimed at providing the business value.

Resources

Bain & Company’s Customer Values Analysis. At the time of writing, you can find this well-presented analysis at https://media.bain.com/elements-of-value/#.

Value Proposition Design: How to Create Products and Services Customers Want by Alex Osterwalder, Yves Pigneur, Greg Bernarda, and Alan Smith (Wiley, 2014). This is a companion to their Business Model Generation, and it explains the tools and processes needed to create solutions that your customers want. There is an online companion at https://www.strategyzer.com.

Return on Software: Maximizing the Return on Your Software Investment by Steve Tockey (Addison-Wesley, 2008). This is a comprehensive introduction to software engineering economics. It should be a part of every software project.

5

Goals-Scope-Stakeholders

The goals set down the desired future state of the customer’s business, along with the business advantage of meeting the goal. For example, it should be 15% faster or cost 12% less; it should take no more than 15 minutes on average to process a claim; it should provide a customer experience that results in a 40% retention rate. Scope is the problem space. It is the part of your customer’s business that is to be improved—fulfillment, patient tracking, monitoring production line temperatures, or whatever it might be. Stakeholders are the people who are involved in that part of the work—they do it, they know things about it, they are impacted by it, and they have ambitions for it.

The goals, scope, and stakeholders are established during the Blastoff. Figure 5.1 shows how the goals are the determining factor for the scope of the problem space. People—we are calling them stakeholders—work in or have an interest in the problem space. These stakeholders in turn are the people who influence or determine the goals. This is not an infinite loop, but you could expect to go around it a couple of times before your goals-scope-stakeholders stabilize.

Figure 5.1

The goals-scope-stakeholders trinity is the foundation for your project. The goals of the project establish the scope of the business problem to be solved. The scope establishes the stakeholders who need to be involved, and the stakeholders in turn establish the goals for a solution that improves their business.

You are establishing these elements early in the project. The intention is to give the project a solid foundation and provide a clear direction for the project team. However, there will of course be times when circumstances warrant adjusting one of two of these elements. When this happens you must make the change, but the point is that you remain in control and that the team knows precisely what they are trying to achieve.

Goals

We have yet to see a project succeed with unclear goals. From time to time, happy accidents occur when the project team, or a lone person, stumbles upon a winning solution. The microwave oven, penicillin, Velcro, chewing gum, saccharin, and so on—all are fortuitous accidents. But let’s face it, you’re unlikely to stumble upon an enterprise resource planning system or accidentally build an email client. If you plan on succeeding, you need a clear and unambiguous—and ideally ambitious—goal to aim for.

Keep in mind that the goal is not to build a piece of software.

It is supremely important to keep in mind that the goal is not to build a piece of software—it is to solve a business problem. You might do that by building some software, but that is not your goal. Solving the business problem is.

It is more than likely that you are given a goal at the beginning of a project. The goal is usually derived when management makes the business case for a project to solve a business problem or take advantage of an opportunity. Despite the goal being handed down from on high, it is not immutable.

A real goal must demonstrate value, and you must be able to measure it.

Start by examining the goal. Our colleague Nick de Voil suggests examining it out loud with key stakeholders, even if they’ve already been through a round of discussions pre-project. It never hurts and often helps a lot to revisit this to ensure that it does in fact deliver value to your customers. Moreover, this value must be able to be measured in some way. Goals that are not measured are not helpful. For example, the goal “We aim to increase our mindshare with the customer by synergizing core competences” is not a real goal; you cannot ever tell if you have met it or not. To be a real goal it must demonstrate value, and you have to be able to measure it.

For example, the value might be measured along these lines.

● Our solution reduces the cost of connecting a new subscriber by 12%.

● Our solution makes the claims process 15% faster.

● Our solution reduces our required staffing to one agent per 500 subscribers.

● Our solution has a turnaround time of less than one second.

The value might be qualitative.

● Our solution improves the user experience.

● Our solution has a more pleasing design than our competitors’.

● Our new solution is better liked than the old one.

At first, the items in the above lists might seem a little touchy-feely, however they can all be measured once you have established what people mean by what they are saying. For example, qualitative goals can be measured by things such as the following:

● Customer retention

● Customer satisfaction

● Customer surveys

● Voluntary usage uptake

● Lack of requests for modification

● And more

Obviously, these measurements are taking place after the product has been built. Isn’t it then too late to discover that the customers hate it and are turning to a competitor? Yes, of course. Which means that you must make certain that your qualitative goals can be met before building your solution.

You can do two things. If your product is a bet-the-existence-of-the-organization-on-it product, then you would build multiple prototypes and test those against a representative sample of your customer segment. The resources spent on this kind of testing pay off handsomely if it prevents you from putting the wrong product on the market.

The second thing is knowing the measurement of success. If you, as a business analyst or UX designer, know how the solution is going to be measured, then you put considerable effort into making sure that it meets its quantitative and qualitative measurements.

Purpose-Advantage-Measurement

As we are talking about the goals of the project, it is worth revisiting the purpose-advantage-measurement way of formatting the goal that we met in the previous chapter. When you are trying to discover the real goal, think of it in terms of these three components. Each of these focuses on one aspect of the goal. When you put these three together, it becomes evident whether the goal statement provides an unambiguous guide for the project.

The purpose is what you are trying to achieve by doing the project. For example:

The purpose of the project is to help college students find and buy used or discounted textbooks, and to sell the textbooks when they are no longer needed.

The purpose of the project is to optimize the routes for the delivery drivers.

The purpose of the project is to minimize the time needed to check out in our fashion stores.

The purpose is not enough on its own. Purpose, advantage, and measurement are needed together to state the goal. The advantage justifies the purpose—it asks why the purpose is important. For example:

Lower-priced textbooks result in students paying less for their books. These might be bought from brick-and-mortar stores, or online. Students selling their books after use further reduces costs.

Optimized routes result in more deliveries being made, with less fuel consumption and thus less pollution.

A faster checkout makes the checkout experience more enjoyable and reduces or eliminates the number of customers who abandon their baskets when they see the checkout is taking too long.

The other aspect of stating the advantage is to evaluate whether or not it is worth pursuing, and whether the return on investment is appropriate for the necessary expenditure of resources.

The measurement has two reasons. It makes the purpose and advantage clearer, and it gives the project team the ability to know when the problem has been solved. For example:

Students pay on average no more than 40% of new-book prices for their textbooks. This is measured taking into account the cost of purchased books and sold books.

The measurement for the checkout project at the fashion stores is this:

Checkout—paying and bagging—on average takes no more than 45 seconds, not counting the customer time needed to produce a credit card or phone.

Purpose-advantage-measurement is a tool for discovering the real goal. It is an exploratory tool, intended to help stakeholders with diverse views of the problem to converge on an agreed goal. A single sentence stating the goal is infinitely arguable. But by having three elements of the goal, stakeholders find it easier to discuss, understand, and subscribe to each piece.

Additionally, a goal expressed as purpose-advantage-measurement enables the team to keep the project on track and to know when they have built a successful solution. It also provides a clear view of the desired outcome of the project.

Achievable Goals

We have talked about how to formulate the goals, but that is not quite enough. You also need to know if you can achieve that goal. There is little point in starting a project if the goal is to enable travel from New York to London in seven minutes—you’re never going to achieve it.

We suggest that you look at the constraints surrounding the problem space to see if there are any that would cripple the project. Constraints are not just time and money, but business conditions and the technological ecosystem. There is a full discussion of constraints in section 3 of the Volere Requirements Specification Template in Appendix A.

Additionally, there is not much point in having a goal that cannot be achieved within the timeline and the budget. Of course, it is difficult, if not impossible, to set a realistic budget until you know the size of the problem you are dealing with. Next up, we discuss scope and how you can know the extent of the problem to be solved.

Scope

Your customer needs to do some work that—directly or indirectly—is beneficial. Your customer wants to improve that work, and you want to provide a solution to help her do that. However, your solution can only be useful if it fits seamlessly into the customer’s business. That is, it becomes a natural part of the business activities that surround it. To this end, it is important that you think of the scope of your investigation as being the extent of the problem space; that is, the part of your customer’s business that she wishes to improve. Eventually, through your investigation, you learn enough about the work being done within the problem space to determine a solution. The scope of the solution is some, and sometimes all, of the problem space.

Setting the scope is very much about determining the boundary of the problem space. Anything inside the boundary is something that you must study and understand. Anything outside can be ignored (up to a point). However, the interface between the inside and outside is critical and needs to be well defined.

The scope of the problem space is determined by the goals of the project. The goal is to bring about some desired future state of the work being done. So, you must consider a problem space wide enough for you to find a solution that can meet the goals. Consider the abstract context diagram shown in Figure 5.2.

Figure 5.2

This is a context diagram. You use it to define the scope of your problem space. The internal functionality of this problem space is hidden for the moment; the intention of the model is to define the boundary of the work being done and its interface with the outside world.

The problem space to be studied includes any of the work that can be affected by your solution and is under your customer’s control. If you are building a solution intended to automate part of some existing work, then the scope of your study should include those parts of the existing work—human activities, together with any automated systems—that could potentially be affected by the eventual solution. For embedded systems, there may be no human activity in your work, but the scope must include any devices that can be changed or in some way affected by the current development. Even if you are building an electro-mechanical device, such as an NFC card and phone reader, where most of the human participation occurs outside the solution boundary, your work context must still include the work that the human will be doing with the device. After all, you need to discover what the customer making the payment would like to do with the machine, not just what is currently possible.

If your intended solution includes, either partially or entirely, a ready-made component, then that must be inside your problem space, along with any human activities, business processes, or other components, whether they are ready-made or you intend to build them.

The work to be studied includes anything that can be affected by your solution.

While we are talking about the context diagram, note its limited, but nevertheless crucial, aim. It shows only the flows of information entering or leaving the work. It does not attempt to show the activities within the problem space. Likewise, it does not explicitly show who or what is doing the work, although this information might be inferred.

As is true of many models, the context diagram is an abstraction that shows a single view. In this case, it shows only the work of the problem scope, the flows of information (and sometimes the material) going to and from it, and the adjacent systems that make up the ecosystem of the work.

As an example of setting the scope of the problem to be studied, let’s look at a simple piece of work that you are probably familiar with: a tapas restaurant.

Carmen’s Taperia

The deal at Carmen’s establishment is that the place mats double as the menu. Customers sit at their table and either they mark the dishes they want on the place mat or the waiter makes suggestions and marks the mat as needed. The waiter also takes the customer’s drink order.

The waiter then takes the marked-up mat back to the waiter station and enters all the ordered dishes. She also enters the drink order into the bartender’s system. The food order is printed on tickets for the chefs and is also added to the display for the pass. (If you’re not familiar with restaurant terminology, the pass is where the cooked food is checked and its presentation finalized before it is passed over to the waiters.) Thus, the pass is the focal point of communication between the wait staff and the kitchen. It is usually presided over by the head chef, or in this case, Carmen herself. She also keeps an eye out for dishes that are taking too long to be prepared or delivered.

Carmen’s operation is shown diagrammatically in Figure 5.3.

Figure 5.3

A rich picture of food ordering and delivery to customers at Carmen’s Taperia

Carmen’s goals are to reduce the errors and ensure rapid delivery of the food. Additional goals are to sell more food and provide a richer experience that encourages customers to come back. The activity where the waiters enter the food and drink orders is currently error prone, and she would like to improve monitoring the orders at the pass and ensure their rapid delivery to the tables. You have been hired as a business analyst to help bring about a solution for Carmen.

Keeping in mind Carmen’s goals, think about the scope of the work you need to study to find a solution to meet those goals. The scope defines the extent of the problem space and so should include all the activities that could influence your choice of a future solution.

Don’t be tempted to presume to know the solution.

Don’t be tempted to presume to know the solution. For example, a presumed solution here would be to scan the place mats and print the orders for the chefs. Or for the customers to use their phones to scan a QR code and enter their orders on an app. However, if you concentrate exclusively on a presumed solution, you miss the richness of the surrounding business.

For example, an important part of the business from Carmen’s point of view is the interaction between the waiters and their customers. Carmen wants the interaction to be friendly. She wants the waiters to be knowledgeable about the food so that they can answer customers’ questions and suggest new things for them to try. “The gambas al ajillo [prawns with garlic] are fantastic today, and you’ve got to try the chipirones [baby squid]. Have you ever tried our albóndigas [meatballs]? I’ll get the chef to make you a sample—it’s on the house.” Carmen knows her food is good, and if some new dish surprises and delights customers, then she will see them again. On the other hand, if you presume the solution is to have the menu on a smartphone app, it all but eliminates interaction with the wait staff. Peering into the small phone screen, customers are more likely to pick dishes that they already know, and they might never get to taste Carmen’s berenjenas con miel (a tapas from Córdoba; fried eggplant with honey), which are absolutely delicious.

The Ecosystem

The business ecosystem is the part of the world that connects and interacts with the problem space that you are studying.

First, there is no such thing as a piece of work that has no connection to the outside world—it does not make any sense. Everything is connected to its ecosystem. For example, your house or apartment exists within an ecosystem that supplies electricity and water to it and drains wastewater from it. The internet is part of its ecosystem. You pay rent for your dwelling, and this payment goes to your landlord, which is part of your dwelling’s ecosystem.

Within your dwelling, you may have a room thermostat, possibly a smart one. The ecosystem for this device includes the heating and/or cooling systems—they are switched on or off by signals from the thermostat. The air temperature of the room is part of the ecosystem, as it is sensed by the thermostat. The thermostat might be connected to the electricity or connected to the internet. All of these things make up the thermostat’s ecosystem.

Everything is connected to something.

Everything is connected to something. It is these “somethings”—devices, services, systems, businesses, people, and so on—that are of immediate interest. We call them adjacent systems, and they connect to the work by delivering data or material to it or receiving data/material from it.

Adjacent systems behave like any other systems: They contain processes and consume and/or produce data. You are interested in them because they are often consumers of the information or services provided by your work, or because they supply information or material needed by your work. You can see these relationships by looking at the data flows on a context diagram, as demonstrated in Figure 5.4. It is through these informational connections that the adjacent systems influence the work.

Figure 5.4

The context diagram for Carmen’s Taperia. Note that the waiters and the food and drink preparation are inside the scope. The work’s ecosystem here is made up of the suppliers and the customers. These are shown as adjacent systems.

Note that in Figure 5.4, there are no data flows going to the suppliers to order food or drinks. This is because the ordering activity is outside the scope you are considering. For that reason, it is not shown in the rich picture in Figure 5.3.

However, suppose that when she sees the context diagram, Carmen thinks about the difficulty of ordering supplies and the time needed to do it. She would like to change the scope to include the ordering activity within the problem space. Now, ordering data flows would be shown going to the Drinks Supplier and the Food Supplier. Note that this change has altered the goals a little and will affect any cost estimates that have been made at this stage.

To find the adjacent systems, you sometimes must venture outside your own organization. Look to the customers for your organization’s products or services. Look to the outside automated systems and organizations that supply information or services to your work. Look to the other departments that have connections to the work. Within reason, the wider you make your investigation, the more useful your solution is likely to be.

Do not be limited by what you think might be the limits of an IT system. Instead, try to find the farthest practical extent of any influence on the work.

You will usually find that your work is also closely connected to one or more IT systems, often within your own organization. Sometimes you are making an enhancement to an existing IT system. In this case, the IT systems, or the parts that you are not changing, are adjacent systems. The interfaces between your work and the existing IT systems are critical. Although these interfaces may prove difficult to describe, unless you define them clearly you can never know the extent of your work, and eventually the extent of your product.

One of the interfaces you are interested in is the interaction with Carmen’s customers. You must understand and define this interface if you are to understand its functionality. In other words, you are studying what happens during the interaction so that you know that any future solution will fit comfortably with the way this restaurant runs. It is important to keep in mind that this is the scope of the work you are about to study, or if you like, the scope of the problem space. Note that this is not the scope of a solution.

Also note that the chefs are included in your scope despite the fact that Carmen has no intention of automating the cooking. A large part of the attraction of this restaurant is the imagination that goes into the tapas, along with the skill of the preparation. Carmen wants to retain that, but there could well be opportunities for improving your solution by better understanding the needs of the chefs, how they interact with the pass, their scheduling needs, and so on. For example, if they have some easy way of knowing that the same dish has been ordered by three different tables at more or less the same time, then it stands to reason they might want to cook all three at the same time. Would the chefs like to see the trends in that day’s orders? Do they need to be reminded if individual dishes on a table’s order have not been cooked or dispatched? It is only by including the work of the chefs within your scope that you will ask such questions and discover better, richer requirements.

During the Blastoff and in the early stages of analysis, it is important to focus on understanding the problem. So, your context diagram should be about the scope of the problem. It is too early to fixate on any presumed solution.

Zone of Influence

When you are thinking about the scope of the problem, you should also be thinking about the scope of the goals. Part of the goal is always to improve your customer’s business area. However, this goal by itself is possibly not enough. A common reason for wanting to improve a business area is to influence the behavior of part of the ecosystem.

Let’s revisit Carmen and her restaurant serving up Spanish tapas. The context diagram in Figure 5.4 shows a central area called Problem Space for Carmen’s Taperia. This is the space you plan to study with the goal of improving it. To improve it you will introduce your solution, which will change that space. Carmen wants you to make this improvement, so we shall call that space a zone where you have a charter to change. In this zone you may make the necessary alterations. Figure 5.5 shows this zone.

Figure 5.5

The charter to change zone and the zone of influence have been overlaid on the context diagram. Anything outside these zones is considered unchangeable. Here we see that Carmen wants to heavily influence her customers and have a slight influence on her food supplier. The drinks supplier cannot be influenced or changed in any way.

Carmen’s goals are a little wider than the charter to change. She wants to influence the behavior of her customers. She cannot order her customers to do something—they are not employees (if they were, they would be in the charter to change zone)—but your solution should do things to influence the customers.

Previously you read “An important part of the business from Carmen’s point of view is the interaction between the waiters and their customers.” Her goal here is to influence the customers so that they try new things and to make the restaurant experience better. So, you include the customers in your zone of influence. A little of the Food Supplier adjacent system is included—the potential for influence is limited—but none of the Drinks Supplier is—it is a large multinational company and impossible to influence. (Carmen buys from this supplier because she gets better prices.)

Including some or all of an adjacent system in your zone of influence means that you pay attention to the requirements for the functionality that is part of the interaction with that adjacent system. In Carmen’s case, you spend some effort eliciting the requirements for the functionality that produces the flows of information that go to and from Carmen’s customers. In this case, these flows are carried by the waiters, and so the functionality is to provide the waiters with all the information they could possibly need to influence the customers.

To influence a customer’s behavior, the solution provides functionality that has the potential to cause a change in the way the customer interacts with the organization. A well-known example is Amazon Prime. Amazon offers a subscription to Prime membership that entitles the Prime customer to perks such as next-day delivery and some free video and music. Amazon did not order the millions of Prime customers to pay the annual subscription—it can’t do that. Customers are not part of the charter to change zone, but the functionality on the customer-facing side of the organization influences (persuades, if you like) a change in customer behavior.

When you are setting your scope, you need the goals. The goals guide you—almost command you—when setting your charter to change and your zone of influence.

Your charter to change zone is that part of your client’s business that she wants you to change. This zone includes any automated solution you produce, and the people and devices that surround the automation. They have to change their work practices to fit in with the new automation.

Your zone of influence is whatever parts of the surrounding ecosystem your solution should have some kind of influence on. The zone of influence is almost always made up of humans—it’s hard to influence a machine—and any influence is voluntarily accepted by the included adjacent systems.

By all means, draw these zones on your context model. They are determined by the goals of the project. However, you might find that your zones cause you and your stakeholders to rethink and somewhat modify the goals. As we said earlier, your requirements process is not a procession, but a flexible framework to guide your requirements discovery.

A Presumed Solution

We have shown you an example of a context diagram of the problem space in Figure 5.4. Now let’s look at the downside of presuming a solution and ending up with a context diagram that shows only the solution. Consider the context diagram shown in Figure 5.6, where the scope is restricted to the presumed solution.

Figure 5.6

This is what not to do. The scope here is too narrow—it shows only the presumed solution.

One of Carmen’s goals is to reduce the errors and ensure rapid delivery of the food. Let’s say that someone has leapt to a presumed solution of scanning the place mats and printing the orders for the chefs. The context diagram in Figure 5.6 shows the restricted scope of this presumed solution.

People think about how to solve the problem rather than what the problem is.

Why has this happened? It is usually because people think about how to solve the problem rather than what the problem is. (As a business analyst, you will have experienced your users telling you a solution rather than the problem that needs to be solved). So, they take their presumed solution as the starting point for the requirements.

What’s wrong with this? The big problem is that it misses too much of the business activity that would benefit from being studied. If you were to understand the work being done by the waiters and chefs, you would most likely come up with a solution that could improve their work while retaining the spirit of the taperia, which Carmen has gone to a lot of trouble to build up. By excluding these people and their work from the scope, you risk delivering a very sterile, unimaginative solution that fails to take advantage of the rich opportunities of a wider scope.

By including the waiters and chefs in the scope of study, it does not mean that you intend to automate them. It does mean that any solution you devise will be much more attuned to their work. It means that your solution could well provide functionality that helps them do their work more effectively.

Let us conclude this section on scope by saying there are some important things to keep in mind when deciding the scope for your project.

● Step back—see the wider view and understand what the business is doing.

● Understand that there is a difference between the business problem to be solved and a presumed solution.

● The wider your scope of study is (within reason), the better your solution will fit into the real world.

For the sake of your requirements and development effort, it is important to set the scope as firmly as possible and as early as possible. You cannot guarantee that it will not change for the duration of the project, but if you want to avoid scope creep—the usual suspect for runaway projects—then set it as accurately as possible in the first instance, and carefully control any changes. The context diagram is useful. Make good use of it.

The Context Diagram

The context diagram is versatile. It does the following.

● Demonstrates the scope or extent of the business area to be studied (you can also call this the problem space)

● Shows all the data entering and leaving that business area

● Arbitrates on what is in and what is not in the scope of development

● Determines the business events (more on these later)

● Helps estimate the cost of the project

● Indicates the complexity of the business area

● And on the soft side, is a focal point for your work

Despite its versatility, the notation for the context diagram is simple. You probably figured out how it works from the examples given above, but it’s worth a closer look at the mechanics.

Figure 5.7

The incoming data, and sometimes material, is transformed by the process and becomes the outgoing data.

The diagram works on the straightforward principle of data in–process–data out. Figure 5.7 shows this simplification.

If you were to extend this principle of data in–process–data out to any business area (or problem space), it would appear as in Figure 5.8.

Figure 5.8

An abstract view of the context diagram. The context diagram of your problem space will look something like this. It shows the data in and out, and the business ecosystem in which this piece of business exists.

Around the periphery of the business area are the sources and consumers of the data. These are called adjacent systems (they are also known as external entities or terminators). Just as your business area is a system, it is surrounded by other systems. These adjacent systems both produce data to be used by your piece of business and are the recipients of data produced by the business.

The important part about adjacent systems is that they are outside the scope of your control; you do not have permission to change them, but you can influence them, or negotiate with them if changes to their input or output need to be made. Otherwise, they are off-limits, and your interest only goes as far as the data that they produce or receive.

It is useful to note that the person normally called the end user is not an adjacent system, but is part of the business area you are studying. The reason for this is that you must understand that person’s work and therefore must include it inside your scope.

Let’s have a look at a couple of other examples of context diagrams.

The functionality of the Young Musicians Site context diagram shown in Figure 5.9 would mainly be about the website, and obviously automated. However, there would also be some manual work done inside the circle. Humans would be needed to monitor context to ensure that the site’s standards are being upheld, to arbitrate in case of disputes of authorship of songs (this happens a lot), and to monitor the activity. This is all to say that the central circle on a context diagram usually contains a mixture of manual and automated processes.

Figure 5.9

A music site for young musicians. The site is for unsigned or independent musicians to upload samples of their work in the hope of being noticed. If you look at the flows of data that enter and leave the work area, you can more or less work out what this piece of business is doing.

Now turn to Figure 5.10. The scope here is a driverless subway train. The various sensors (shown as adjacent systems) that surround this piece of work are separate from the train and are not part of the same analysis and development effort. The train must receive data from these adjacent systems to function correctly and safely.

Figure 5.10

The context diagram for a driverless subway train. It would be more complicated in reality, but this is sufficient for the purpose here.

When you build a context diagram for a problem space, all its functionality is hidden for the moment; the diagram exists to set the scope of the problem, not to show how it works. Later you expose the inner workings when you start trawling or prototyping the business events. However, in case you are curious, the functionality for the subway train would include

● Responding to temporary trackside signals (these could be set by track maintenance workers or others)

● Checking that upcoming points are correctly set for the train’s destination

● Checking that the track ahead is clear

● Stopping the train according to the platform guide beacons

● Starting the train when the doors are correctly closed after loading

● Checking that passengers on the platform are clear of the train

● Checking passengers inside the train for unusual activity

● Relaying any emergency passenger signals

● Ensuring that the train’s speed is consistent with the controller’s advice

● And so on

If you are going to draw only one model for your project, then make it the context diagram. Why? Because in the first instance, it is helping you and your key stakeholders decide the precise business problem you are trying to solve.

You can use the context diagram alone to give you a quick indication of complexity. A diagram with 100 flows in and out of the business area is obviously more complex and thus more expensive than one with 30 flows at its periphery. (Don’t be afraid to draw such a model. If there really are 100 flows, then they must be shown. We have seen plenty of examples of this.)

Each flow on the context model indicates some work to be done by the business.

Each flow represents some work to be done by the business area. We’ll talk about this more when we get to business events, but for the moment, consider an incoming flow called Request to open an account. The work to be done here is whatever is needed to establish the account and welcome the new customer to the company. There would be a different amount of work to be done by, say, a change of address request.

If you go around the context diagram and for each incoming and outgoing data flow, estimate the complexity of the work to be done for that flow, use a simple scale such as small-medium-large. For example, let’s say that you have 10 large, 20 medium, and 30 small work items. What remains is to know (or to estimate) the effort needed for each of these categories and do the multiplication.

The context diagram is also an instant arbiter of scope questions:

“Is this feature in or out of our scope?”

“There’s no data entering the business area that is needed for the feature, so it must be out of scope, or we have missed some data.”

“Is our project responsible for time reporting?”

“No, but you can see how the output data gives the information to the controller’s office (presumably an adjacent system) for them to calculate the time records.”

A little later we will see how the context diagram helps to determine the business events, but for now let’s turn to something else: the people involved in your project.

Stakeholders

We began this chapter by talking about the trinity of goals-scope-stakeholders. We have looked at goals and scope, so let’s turn to the next part, the stakeholders.

A stakeholder is anyone with an interest in, or an effect on, the outcome of the solution. The customer, the person (or organization) who will ultimately possess and use your solution, is the most obvious stakeholder. There are others. For example, the project sponsor is a stakeholder; a subject-matter expert is a stakeholder; a security expert; someone who benefits from the solution’s functionality, such as the manager of people who use the solution to do their work; the marketing department; and so on.

Stakeholders are the source of the requirements.

You are trying to solve a business problem, and that probably means talking to many people. The people who are potential sources of requirements are your stakeholders. You must ensure that you include those who are authorized to make decisions, as well as those who are not authorized but have knowledge about the work.

The stakeholder map (Ian Alexander, one of its originators, calls it an “onion diagram”) in Figure 5.11 identifies common classes of stakeholders that might be represented by one or more people in your project. There are potentially dozens of types of stakeholders for any project, and you can find a comprehensive list in the form of a spreadsheet in Appendix B, Stakeholder Management Templates. You can use this spreadsheet to manage your stakeholders by identifying who they are and what involvement you need them to have. Check out Appendix B soon, but for the moment we’ll look at some of the stakeholders in the diagram. Keep in mind as we do that some roles will overlap, or individuals may have more than one role.

Figure 5.11

The stakeholder map shows the organizational rings surrounding the intended solution and the types of stakeholders who inhabit these rings. Use this map to help determine which stakeholders are relevant to your project.

You can use this generic diagram as a starting point for talking about your stakeholders and discovering which are relevant to your project and which others you need to add.

At the center of the stakeholder map is The Intended Solution. Notice that it has a vague, cloudlike shape—this is intentional. At the start of the requirements activities, you cannot be certain of the precise boundaries of the solution, so for the moment we will leave it as being vaguely defined. Surrounding the intended solution is a ring representing The Operational Work Area—stakeholders who will have some direct contact with the solution inhabit this space. In the next ring, The Rest of the Organization, you find stakeholders who benefit from the solution in some way even though they are not part of the operational area. Finally, the outer ring, The Outside World, contains any external (to the organization) stakeholders who can influence the solution or have an interest in it.

It is helpful to discuss some of the more important stakeholders.

The Customer

Your customers are the people you must satisfy with your solution. After all, the customers are the people with the power to reject it.

The customer is the ultimate possessor of the solution. Customers can possess it by being

● The manager of a department who buys or commissions the solution for the people working in the department

● The user of the solution, possibly working for the manager

● Someone who directly purchases your solution

● Someone who pays to use the solution

Perhaps you already know the names of your customers, or perhaps there are hundreds or thousands of unknown people who might be persuaded to pay for your solution. In either case, you must understand them well enough to know what work they are doing, what they find valuable, and what they will pay for. If you are developing open-source software, you still have a customer; the difference is simply that no money changes hands.

There are several customer roles; we wrote about them in the previous chapter. We mention them again, as each of them has different requirements.

The customer as purchaser is someone who is putting up his money to possess your solution. His requirements are those that ensure that he receives value from it. For example, he pays to have your password manager app on his phone, and you must discover what capabilities he needs.

The customer as sponsor is the person who sponsors the acquisition of the solution. This person usually has users working for her, and so her requirements are about ensuring that the staff can work effectively to produce the outcome needed by her department. There is more on this role in the Project Sponsor section below.

The customer as user is the person who possesses the solution because he uses it to do his work. His requirements are those that define the functionality he needs to do his work.

We’ll shorten the role to “users,” and by that we mean the people who will ultimately be the hands-on operators of your solution. In the case of solutions that are not software products, the users are the people performing the service (or whatever your solution is). The better your understanding is of your users, the better your chance is of specifying a suitable product for them.

The Project Sponsor

The sponsor is financially responsible for the development of the solution.

On the simple basis that “money talks,” the sponsor—more accurately, the sponsor’s budget—is paying for the development and has organizational authority over the solution’s requirements. You cannot proceed without a sponsor. If no one is representing the interest of the organization, if no one is putting their hand up and saying “This is my project,” then there is little point in proceeding. If nobody is steering, the ship goes on the rocks.

Your sponsor might have different roles within the organization. For example, the sponsor could be part of the following.

● User Management: If you are building a solution for in-house consumption, the most realistic sponsor is the manager of the users who will ultimately operate the solution. This department is the beneficiary of the solution, so it is reasonable that the cost of construction is borne by the departmental manager.

● Marketing Department: If you build products for sale to people outside your organization, the marketing department might assume the role of sponsor and represent the eventual customers of the solution.

● Product Management: If you have a product that is continually being upgraded to meet market demands (such as a phone operating system), the budget for its development would be with a product manager or a strategic program manager—one of those would be the project sponsor.

Consider your own organization—its structure and job responsibilities. You have to identify the person who takes organizational responsibility for your project. Our project will not succeed without her.

The Business Analyst

The business analyst’s responsibility is the discovery and analysis of the requirements. This usually involves determining the business problem that has caused the project to be initiated. When the business problem is correctly identified and understood, the business analyst studies the activity in the problem space. The objective is to identify the solution to the problem and produce the requirements for that solution.

The business analyst’s tasks include producing correct requirements and/or stories. To be usable, requirements and stories must be accurate. We shall talk a lot more about writing accurate requirements and stories later. For the moment, we can say that they must be measurable, testable, verifiable, and agreed to by the appropriate stakeholders.

You will find the rest of the skills and responsibilities of the business analyst in the remainder of this book.

The Product Owner

The product owner is one of the Scrum roles. Scrum is an agile software development method that uses iterative and incremental construction of the solution, or “product” in Scrum parlance. Much has been written about Scrum and we don’t need to repeat it here. The Resources section at the end of the chapter has some references.

The primary duties of the product owner are to prioritize the product backlog and to decide what the development team needs to be working on. In other words, the product owner decides which features or capabilities are to be constructed during the next iteration cycle, or “sprint.”

The product owner role is included as a stakeholder because of the product backlog. This is a collection of stories yet to be developed. Stories (sometimes called “user stories”) are the replacement for requirements in the Scrum world. Throughout this book, we use the terms “stories” and “requirements” almost interchangeably. They’re not the same—requirements are usually more detailed than stories. You’ll see lots of examples of both as we look more at requirements discovery.

Scrum has nothing to say about how the product backlog and its stories come into existence. That is the role of the business analyst: It is he who works closely with stakeholders to discover the needs of the business and writes those needs as stories or requirements, and often (and wisely) a combination of both. There is a lot more on how this works, and how you can synchronize the work of the business analyst and the product owner, in Chapter 35, Story Map, where we talk about story maps as a better way of organizing a product backlog.

The product owner has only a marginal role in requirements discovery, but a very active role in constructing the solution (the product). The product owner is included as a stakeholder because she must become very aware of the goals and desired business outcomes of the initiative. The product owner is responsible for the development team constructing their product in accordance with the goals set by the key stakeholders in conjunction with the business analyst. The product owner also liaises with the business analysts throughout development to ensure that the product backlog is being prioritized in line with the priorities of the customer segments and the business events. More on these in a little while.

Other Stakeholders

To find all the requirements, you need to talk to some more people. Your contact with these stakeholders might be fleeting, but it is nevertheless necessary. Any of them may potentially have requirements for your product.

“ Every context is composed of individuals who do or do not decide to connect the fate of a project with the fate of the small or large ambitions they represent. ”

—Bruno Latour, ARAMIS or the Love of Technology (Harvard University Press, 1992)

The problem that you often face in requirements projects is that you fail to discover all the stakeholders, and thus fail to discover some of the requirements. You might also fail to discover some aspects of the problem, goals that need to be satisfied, and constraints that need to be respected. In other words, you need to find everybody with an interest in the solution to discover their requirements.

We list our stakeholders in section 2 of the Volere Requirements Specification Template. You can find this template in Appendix A. The list acts as a checklist for finding the appropriate stakeholders. You will also find the Stakeholder Management Template in Appendix B.

Let’s consider some other stakeholders. You can see these on the stakeholder map shown in Figure 5.11.

● Consultants—both internal to your organization and external—are people who have expertise that you need. Consultants might never touch or see your product, but their knowledge becomes part of it.

● A functional beneficiary is someone who receives something useful from the activity (or the functionality) of the solution, such as a periodic report or ad hoc alerts. It could also be someone whose work is improved by the fact that someone else is using the solution. For example, a manager can monitor his budgets more effectively because his staff are able to make better projections by using the solution.

● A political beneficiary is someone who achieves the perception of power because the solution has been developed. This might be a person who is in a position of authority, and so her requirements cannot be ignored (no matter how much you may want to ignore them).

● A financial beneficiary is someone who is better off because of the solution. This person might be a shareholder or similar whose stock in the organization is more valuable when the product sells. Or the solution saves money by making a business process more efficient, and thus helps the budget of its manager.

● Product managers and program managers are responsible for the ongoing development of a product. Your company might, for example, produce accounting software, and this must be constantly upgraded to keep up with changes in the law, but also to provide new and better facilities to keep ahead of the competition.

● Subject-matter experts may include domain analysts, business consultants, business analysts, or anyone else who has some specialized knowledge of the business subject. Consequently, these experts are a prime source of information about the work.

The greatest problem concerning stakeholders is the requirements you miss when you don’t find all the stakeholders.

● Regulators include people such as government inspectors, any kind of safety inspectors, technical inspectors, or even possibly the police. It may well be necessary to build inspection capabilities into your product. If your product is subject to any regulatory act, then inspection is crucial, as are the requirements from the inspectors.

● Marketing and sales are the stakeholders representing the marketplace. When you are building a product for commercial sale, trends in the market are a potent source of requirements, as is a deep knowledge of the likely consumers.

● Lawyers are the stakeholders for most of your legal requirements. Each year the world is filled with more and more laws. Complying with all of them is daunting but necessary.

● Hostile stakeholders are internal people who do not want the project to succeed. Although they may not be the most cooperative individuals, you would be wise to consider them. Also consider the people who threaten your product: the hackers, defrauders, and other malevolent people. You will get no cooperation from them, but you should consider how they might mistreat your product.

Also consider the adjacent systems and the data flowing to and from them on the context diagram. Look at each adjacent system: Who represents its interests, or who has knowledge of it? When the adjacent system is an automated one, who is its project leader or maintainer? If these stakeholders are not available, you might have to read the adjacent system’s documentation, or its code, to discover whether it has any special demands for interacting with your product. For each adjacent system, you need to find at least one stakeholder.

Review

The Project Blastoff is there for you to set a solid foundation for your requirements discovery. We described the goals-scope-stakeholder trinity. When your blastoff is successful, these three are coordinated to give you the target for your requirements. Are the requirements in scope? Are they contributing to the goal? Are they valuable to the stakeholders?

The Blastoff is also part of your requirements discovery. By determining the scope of the problem, you are determining where your requirements are to be found and which requirements are not part of the problem.

It’s helpful to think of the goal as the highest-level requirement. This is what your project aims to achieve. The goal is not to build a piece of software or some other product, but to solve a business problem, and in so doing, improve the customer’s business.

The goal sets the target, and every requirement that you discover is subordinate to the goal and in some way contributes to the goal.

The scope describes the extent of the problem space. It shows what is inside and what is outside the problem you are analyzing. We suggest using a context diagram to illustrate the scope and be the arbiter of where you study and what is outside your problem.

The scope and the goals are vital to your project. Without them you are doomed to wander in a fog of uncertainty. So, it is important that they be given enough attention to ensure their correctness.

Getting the stakeholders right means that you find the right people—those with the knowledge and authority—to answer your questions and provide the basis for deriving the right requirements.

Before leaving this, we should mention cost. It is only when you know the scope of the problem that you can begin to estimate the cost of, or the effort needed for, the solution. To do otherwise is to invite calamity later when the project runs out of budget or time.

Goals, scope, and stakeholders are the trinity that will pay you back for getting them right.

Resources

The Agile Guide to Business Analysis and Planning: From Strategic Plan to Continuous Value Delivery by Howard Podeswa (Addison-Wesley, 2021). This book is about how product owners and business analysts can maximize the value delivered to stakeholders by integrating business analyst competencies with agile methodologies.

“$1 Million Wasted Every 20 Seconds by Organizations Around the World” by Vanessa Andres (https://bit.ly/40gvMwg). This article discusses a study conducted by Project Management Institute that shows that on average, organizations globally waste 9.9% of every dollar due to poor project performance and that around one in three projects (31% globally; 28% in Canada) do not meet their goals.

Business Analysis Agility: Delivering Value, Not Just Software by James Robertson and Suzanne Robertson (Addison-Wesley, 2018). This book looks closely at how real value is the result of solving the business problems that the stakeholders really need to have solved.

6

Customer Segments

A customer is the ultimate possessor of your solution. She might have your solution on her computer or device, having paid for it or gotten it for free; or she might have bought or commissioned the solution for her staff to use. For the purposes of segmentation, let’s say that a customer is someone who, directly or indirectly, uses your solution to do some kind of work.

You are interested in the work that people need to do with your solution. For example, a customer might be using your solution all day to schedule the transportation of consumer goods from his company’s distribution center to retail stores. Or the customer’s work might be more fleeting, such as logging on to request a report. Or the customer might come to your website to browse your offerings and buy something from you, or to chase up a delayed delivery. There are thousands of possibilities for customers using your solution.

There is also the possibility that you have thousands of customers.

However many customers you have, they do not necessarily behave the same way. They have different motivations, and some of them are using your solution to do different things. To provide the appropriate solution, you can’t aim at everybody (try to please everybody and you’ll please nobody). There is a need to segment your customers and investigate the business problem of each of the segments.

As an example, buyers and sellers on eBay are two different segments, each with different tasks to do and different aspirations. It would not make sense if you were to try to discover the requirements for both sets of people at the same time.

The most useful way to segment your customers is to consider their needs and what they want to do with your solution. It might be necessary to further segment on demographics—for example, by age, income, or education. You will do this only if it makes a difference to the way that different demographic groups might use your solution.

Having identified the segments, you can prioritize them so that you can choose the order in which you work on them.

Customers and Their Segments

The customers we are talking about are your customers as users and/or customers as purchasers. We’ll just call them “customers” from here on. There are lots of customers and they are not all the same—so you must subdivide them in order to provide accurate requirements.

Customers are humans, and different humans have different aspirations and values. Also, different humans are trying to do different things. So, the possibility exists that your solution cannot be a one-size-fits-all solution, but a nuanced solution that provides different functionality, and possibly different behavior, for different segments of customers.

You start segmenting your customers according to their needs. You could think of their needs as what they are trying to achieve or the business problem they are trying to solve. You might also consider their pain points, or obstacles to achieving their goals. Disregard, for the moment, the detailed tasks they do; you don’t yet know if these tasks are appropriate or if they are merely the customary things that the customers have always done but won’t necessarily do in the future.

Consider this situation: You are the lead business analyst for a large multinational container shipping and transport company. There are about 20,000 employees around the globe. As you know, containers are those huge steel boxes that you see stacked up on container ships. When they reach their destination port, they are offloaded to be picked up by trucks to carry them inland. Containers are designed to be stackable to make them transportable by ships, and to be the right size to fit on the back of a truck or a railroad car.

A manufacturer will fill a container with the goods, do the customs paperwork, and then seal the container. The transport company (that’s your organization) picks up the container and either delivers it directly by road or rail or takes it to the container terminal for onward shipping to its destination country.

Many of the 20,000 employees are potential customers for your solutions. For example, some of your customers work at arranging bookings for containers to be delivered to manufacturers so that they can fill them with the goods they want shipped. You also have customers who are concerned with scheduling the trucks to drop off and pick up the containers. Other customers predict the need for containers by area and ensure that there is a supply of empty containers to meet demand. Others arrange the ships and dock facilities and so on. Still more customers bill for the company’s services.

The problem your company faces is that it has grown up with a patchwork of solutions, and these solutions are very inefficient at sharing data and communicating with each other. This often results in the same data having to be input to several different parts of your company. This patchwork has led to employees not having ready access to the information they need, and in some cases, salespeople have inadvertently arranged contracts for containers or shipping capacity that did not exist.

An initiative has been launched with the goal of making all data seamlessly available to all employees (wherever authorized). Another goal is for solutions to share their data so that there is very little duplicated data in the organization.

The last thing you want to do at this stage is to presume a solution, which would have one huge data store in the cloud. Someone might go far enough to suggest one large solution for the whole of the company.

Instead of thinking about solutions, let’s look at the customer segments. Your customers are the employees engaged one way or another in the moving of containers to their destinations around the world. The first approach to segmentation would be to look at the activities the employees are doing. You might start with their departments or divisions to give you a first attempt at segmentation. You might adjust these segments as you learn more.

For example, the Shipping department could be one segment, the Scheduling department another. The Predicting department (these are the people who predict demand) has different activity (and needs), but it connects closely with the activities (and needs) of the shippers and the schedulers.

Each of the segments we have discussed—and perhaps a dozen more that we have not listed—have different needs. Each segment needs to be investigated separately, as each requires a different solution.

Without customer segments, you would be faced with trying to find the requirements for 20,000 people—truly impossible. With segments, you have a manageable business problem to solve for each segment. Naturally, once you have a few segments under your belt, you will find that overlaps and similarities smooth the way for you.

Think of your own project situation. Once you have more than a few dozen people who will ultimately possess your solution—these are your customers—it is likely that you have a need to segment them. Treating all the customers equally means that your requirements discovery will be very much less than optimal, as will the eventual solution.

One other reason for segmenting your customers, as we shall see in a while, is to prioritize the segments and work on your requirements discovery for the highest-priority segments. Figure 6.1 illustrates this division and prioritization.

Figure 6.1

The universe of customers is divided into segments according to their business needs, and in some cases, their business behavior. Each segment is studied separately, beginning with the highest-priority segment.

Personas

Having segmented your customers, it is appropriate to consider the possibility of using personas. You create a persona to put a human face on a segment so that you and your team can better visualize the needs and behaviors of the people who make up the segment. Archetypes are the same thing, except the segment is treated as an abstract entity and is given a name to represent the segment’s grouping of characteristics.

A persona is a virtual character that personifies a customer segment.

A persona is an invented personality, an imaginary but nevertheless archetypical representative of a customer segment. You derive the persona through customer research or by surveying the segment to understand their motivations, goals, behaviors, and what they need to do with your solution. Alternatively, you and your team can discuss from your collective experience the attributes of the segment and form your persona from that. The degree of precision needed varies in proportion to both the size of the customer segment and the criticality of the product to be built.

Why use an imaginary character when there are potentially thousands of real people out there? Because for a mass-market product, or one that is to be used by more than a dozen different people, you don’t know, and can’t get to know, all the potential users. But you can know one really well. That is your persona, and although imaginary, his attributes guide your requirements discovery. Almost always, a persona is a better representation of your customer segment than a human proxy.

Most teams write a one- or two-page description of the persona’s behavior patterns, goals, skills, attitudes, and environment. It is also usual, and indeed desirable, to include enough personal details—including an invented name—to make the persona seem real to you and your team.

A team discovering the requirements for a book-finding app wrote this:

Alessia is 27 years old. She works in a large city in the finance industry, drives a small electric car, is a casual user of social media (about 20 minutes a day), reads (two to three hours a day) mainly on her tablet but enjoys the occasional hardback, spends time out with her girlfriends, is educated to degree level, thinks of herself as mildly adventurous, and is always keen to discover new authors. She has disposable income but is careful what she spends it on.

There could be a lot more, but you get the idea by now. You will also find it useful to have a photograph—you can find thousands of photos in the online stock photo agencies. Select one that the team agrees is their mental image of your persona. The team picked Figure 6.2 as the kind of person they think of as Alessia.

Figure 6.2

The team’s photo of their persona. The team developed their persona through research into the customer segment and interviews with potential customers.

A persona helps the team understand the customer segment and think about the segment’s needs. When team members can see a photo and speak about the persona by name, it brings to life what otherwise would be abstract data about customers. The question to ask is not what a set of data wants, but “What does Alessia want?” Or “What would Alessia do in this situation?” Or “What information does Alessia need for this interaction?”

Personas avoid what Alan Cooper (see Resources) calls the “elastic user,” whereby different stakeholders define the characteristics of the product to be everything they have in mind, and to accommodate their own assumptions about the kind of user they are building for. The result is usually too many requirements, some of which conflict with other requirements, and a solution that, by trying to satisfy everyone, satisfies none of its intended audience.

Having a persona also prevents designers from defining the customer as themselves. This “self-referential” approach (see Figure 6.3) almost always yields idiosyncratic results, with most of the real customers failing to appreciate or use the product.

Figure 6.3

The self-referential user considers only herself, and inadvertently disregards the wishes or needs of the real audience.

You probably use some consumer products that fit extremely well with your personal preferences. This is not because the product’s builders know you personally, but because they selected a persona whose attributes matched (more or less) yours. In contrast, if you try to write the requirements for a product to suit your complete universe of customers, the functionality would be so cumbersome as to make the solution so unwieldy that nobody would use it—trying to suit everybody ends up suiting nobody.

The lifelike attributes of the persona give the business analysts and stakeholders a target at which to aim their solution. Persona attributes such as computer literacy, attitude toward technology, cultural taboos, viewpoints, and so on act as a guide to your team.

For example, a few years ago we had the local government council for one of the London boroughs as a client. Part of the council’s responsibilities is to provide meals at home for aged people and others who are not able to provide for themselves. We worked with the team who manage this service, whose objective was to make improvements to the meals and how they were delivered. We jointly derived a persona (we called her Elsie), partly from council data and partly from the personal experience of the social workers. We arrived at a consensus persona that was felt to be archetypical of the meal recipients. The team then began asking, “What service does Elsie really want?” and “How would she react if we provided this service instead of that?” The answers were a revelation to many of the team members; up until now they had been designing this service to suit what they wanted to deliver. Elsie—her photo smiled down on the team—gave them answers that made for a far better and well-received service. See Figure 6.4.

Figure 6.4

The team used a persona to represent their customers. By treating the persona as a real person, they were able to uncover a superior vision of what the future business should be.

Personas are close to vital when it comes to agile development and prototyping. We have seen some agile teams where anybody can contribute stories or requirements. This naturally leads to solutions that lack focus and are often idiosyncratic. On the other hand, a well-developed persona assists the team to be much more precise on the needs of the solution. And if your development team sits down with a single human customer, that customer must be exceptional; otherwise, we urge you to consider a persona as an alternative.

Prioritizing the Customer Segments

A quick glance at a list of your customer segments usually reveals a difference in the importance of the segments. If you only have one or two segments, then prioritizing them is easy. But when you are faced with a longer list of segments, things become slightly more difficult.

Prioritize your customer segments by value.

Customer segments differ in their value to your organization, so it makes sense to prioritize them by value, and to discover the requirements and develop a solution for the most valuable one first.

Before we go any further, we need to remember that value can mean different things at different times to different people. You can think about value to the customers, but as the organization is paying for the development of your solution, it is probably best to start by thinking about what provides value to the organization.

Consider the container shipping company you met earlier. The project is about infrastructure and providing the appropriate data for each business unit. Value to the organization is delivered when you have finished the project, but that is a long way off—it’s a very large business problem. The reason for deriving the customer segments for this organization is to give you a starting point.

As this project is largely about sharing data, the most valuable place to start is the source of the data. There is no actual source of data; it doesn’t bubble up from the ground like an alpine spring. But the segment that creates most of the data is the part of the business doing the scheduling. These customers arrange the movement of containers and so generate the data about where the containers are and where they are going to be once delivered. Sure, the sales segment generates income for the company and therefore could be considered as the most valuable, but the salespeople have to know the availability of containers in order to sell their service. They need data from the schedulers to do that.

Prioritizing segments is not easy, and obviously management needs to be involved. For example, there might be a segment or two where meeting their needs does more to achieving the desired business outcome than others. Your task as a business analyst is to provide information and advise management about the relative value of the segments for the right decisions to be made.

The container company’s segments are complex when it comes to value, so let’s look at a different and simpler situation. This time we can just use revenue.

Gotham Coffee Roasters is a new but growing business supplying coffee beans to the discerning people in the city. Looking at this business you can see reasonably distinct customer segments.

● Direct personal buyers: These people come into the shop to interact with the staff to find the most suitable beans to match their tastes, and to discover new blends and new single-origin coffee. The beans can be ground if the customer wishes.

● Online buyers: These customers usually know what beans they want, and they value convenient ordering and quick delivery.

● Cafes & bars: These customers are concerned with freshness and guaranteed continuity of supply.

● Resellers: These are the stores (usually food shops) that stock Gotham’s beans and sell them to their customers.

Glancing at the above list, you can see that while parts of the customers’ interactions are overlapping, there are also distinct differences that require different solutions. However, there are also commonalities between the segments, so solutions for each segment will not be completely unique.

Gotham’s accounting people tell you that direct personal buyers are the biggest revenue generators; the stores and the personal engagement are very popular. The online segment is next in size, and growing; people apparently like the convenience of buying online. The cafés & bars segment and the resellers segment are currently smaller than the others. You could illustrate this situation as we have done in Figure 6.5.

Figure 6.5

A graphical representation of the proportional revenue of the Gotham customer segments. There is no need to have such a graphic apart from wanting to emphasize the relative value of the customer segments.

Revenue is a good starting point for prioritizing the segments in this case, but it pays to step back and see if there are other factors that should be taken into consideration. For example, is there a desire to grow one segment? Suppose that Gotham’s management feels that having a bigger online presence would be a desirable way to grow the business. In other words, value here means “future value,” or perhaps “desired value.” In this case, you might begin with requirements discovery for the online segment and leave the others aside for the moment.

Prioritizing the customer segments is not the sole responsibility of the business analyst. Rather, it is a joint effort involving management, marketing (if appropriate), the product owner, and other stakeholders. It is advisable to prioritize as early as possible in the project. Doing so means that you are discovering the requirements and developing the solution for the most valuable segments first, and so the organization reaps the advantage that your solution delivers as early as possible.

Review

Identifying, characterizing, and prioritizing customer segments enables a more focused requirements discovery. When you segregate your customers by their needs and aspirations, the result is segments with clearly defined needs. If you construct a persona for the segment—and we urge you to do so—then requirements discovery becomes more straightforward because you only have to discover one persona’s requirements. Your own thoughts as to what the solution should be are subordinated to the “thoughts” of the persona you have generated for the segment. This means a sharper set of requirements.

Your segments should be prioritized. We suggested that you use business value, but sometimes just the estimated number of people in the segment can set the priorities. However you do it, working on the highest-priority segments brings you the highest-value solution.

Of course, there will be overlap of the requirements for the segments, but you will be more efficient by discovering all the requirements for the highest-priority segment, and going ahead and developing those requirements. The requirements for subsequent segments lie in the differences between the customer segments.

Resources

About Face: The Essentials of Interaction Design, 4th Edition, by Alan Cooper, Robert Riemann, David Cronin, and Christopher Noessel (Wiley 2007).

Value Proposition Design: How to Create Products and Services Customers Want by Alex Osterwalder, Yves Pigneur, Greg Bernarda, and Alan Smith (Wiley, 2014). This book is part of the Business Model Generation series and provides tools and techniques to help you define and refine your value proposition for specific customer segments.

CustomerThink, a community and resource hub for customer-centric business professionals offering articles and insights on customer segmentation (https://customerthink.com).

7

Business Events

Business events are the building blocks of business solution design and development. They are also the unit of work that forms the most effective way to discover the requirements. But we are getting ahead of ourselves. Let’s start with the business problem you are trying to solve. You have already partitioned using customer segments, which gives you focused chunks of the problem to deal with and the priority in which you deal with the chunks. Now we’ll look at using business events to give you the ideal partitioning for your further investigation.

Business events are significant happenings that trigger a response from the activity within your problem space. See Figure 7.1.

Figure 7.1

Business events happen when a significant actor outside the business does something that requires a response from the business. There is also a time-triggered business event. In this case the problem space produces a weekly sales report.

Note that the examples that follow talk about the whole of the problem space. This is done for pedagogical reasons: It is easier to discuss business events if they are not layered on customer segments.

We’ll use business events for the remainder of our investigation and development of the solution. The response to each event is investigated, and the result of this investigation is the discovery of the requirements for that part of the problem.

Understanding the Work

In some situations, you have a large number of customers, and they have differing needs. In the previous chapter, we discussed how you can partition them into customer segments. For our purposes here, we will treat each customer segment as a separate piece of work.

There will be some overlap between the segments. The work of each is probably not completely unique, but it is different enough that it is more effective to look at each separately and jump over any duplication you find.

When we talk about a piece of work, consider it to be either the work of a customer segment or the entirety of your business problem space. The examples of work that follow in this chapter ignore customer segments and assume that you are studying the whole of a business problem space.

The work is the activity happening within the problem space. We have defined the problem space by the data that enters and leaves it (we did this in Chapter 5, Goals-Scope-Stakeholders, when we set the scope of the work and built a context diagram). Now we want to investigate the work that goes on inside that problem space. This is the work or activity that is responding to the incoming data and producing the outgoing data.

The work includes human tasks, software, machines, and low-tech devices such as telephones, photocopiers (remember those?), manual files, and notebooks—in fact, anything that is used to produce the customer’s goods, services, or information.

The Scope of the Work

Your context diagram shows how your work fits within its business ecosystem.

Most business areas exist to provide services or products to the ecosystem that surrounds them. The ecosystem is represented on the context diagram by the adjacent systems. The adjacent systems could be automated systems, or customers who buy from or subscribe to the work, or departments, organizations, or other parties that place some kind of demand on or make some kind of contribution to the work.

To provide services or products, the work receives information and signals from the ecosystem, uses these inputs as raw material for its business processes, and responds by sending information, signals, services, or products back to the ecosystem.

As an example, Figure 7.2 shows the context diagram for a piece of work (you can also call this the problem space) that sells capsule coffee and the machines that use the capsules. This work is fully automated—that is, it is online—and it takes the orders from the customers, processes their payments, and passes the orders to the Fulfillment Center for shipping capsules and machines to the customers. The work shown here is surrounded by its ecosystem: the adjacent systems that either supply the data necessary for this work or receive services and information from the work.

Figure 7.2

The context diagram showing the scope of the work. The central area of the diagram represents the work being done in the problem space. The outside world, the ecosystem, is represented by the adjacent systems—Customer, Fulfillment Center, Payment Processor, and so on. The named arrows represent flows of information between the adjacent systems and the work.

What Are Business Events?

Every piece of work responds to things that happen outside it—it’s that simple. For the sake of clarity, because we are discussing the work done by the business, we call these happenings business events. This idea is shown in Figure 7.3.

Figure 7.3

A business event and its response. A business event happens at the moment the adjacent system—an entity outside the business—decides to do something and indicates this to the work by providing the triggering data flow. When this data arrives, the work responds by processing the incoming data and by retrieving and recording stored data.

Let’s look at an example of a business event. Suppose that you are a customer for the capsule coffee company we showed you a moment ago. Let’s also suppose that your supply of capsules is running low, and in order to continue enjoying your morning coffee, you decide to restock. You do this by ordering capsules from the coffee capsule company. That moment—the instant you realized that you needed more capsules—is the business event.

Of course, a business event goes unnoticed unless you tell the business about it. In this case, you signaled the work by placing an order for some capsules, and if it was not already on file, you provided your credit card, shipping address, and so on. This incoming flow of data triggers a response within the coffee seller’s work. The response is to charge your credit card, record the sale, and send a message to the Fulfillment Center to ship the capsules to you. In this organization, the physical goods—capsules and machines—are held by the Fulfillment Center, and no physical material (just data) enters the work.

It might seem a little overcomplicated to think separately about the business event and the triggering data flow, but there is a reason for doing so. The business event in this case is Customer needs capsules. Suppose that you examine this happening, and as usual for a business analyst you ask why: Why does the customer need capsules? Why did he run low? Perhaps a better business analysis question is “Why was he allowed to run low?” Could the work have forestalled the situation by automatically replenishing, or running a subscription service, or something similar? Are coffee consumption habits predictable enough to auto-replenish? Is there a nonintrusive way for the customer to be reminded that his stock of capsules is low? Remember, the real business event is Customer needs capsules. The closer you get to that, the better.

By thinking about the actual event and why it came about, you give yourself the opportunity to discover more about the activity of the adjacent system. The coffee customer is in your zone of influence, so you should be studying him.

Another coffee business event: The customer needs help with his membership, or wants advice on types of coffee, or wants to know when his order will arrive, or has some other query. That’s the business event—The customer needs help. However, he will remain un-helped unless he has some way to inform the work that the business event happened. This brings us to the triggering data flow. You can see this triggering data flow called Help Request on the context diagram in Figure 7.2. When the work receives this flow, it can respond to the business event. It fires up its AI chatbot and through a conversation, provides the answers the customer needs.

The customer does not own or control the coffee company. Nevertheless, in both examples he makes the company respond by processing his incoming flow with the activities to produce the needed outcome.

In some cases, the adjacent system where the business event occurs is an automated system. There’s nothing unusual about this, and you will find that most companies have multiple software systems, and they are constantly passing signals and data between them. Each time this happens it is a business event, and for the system on the receiving end of the data, this is a triggering data flow. It triggers a response just as if the adjacent system were a human.

Business Use Cases

The work area (you can also call this the problem space) always responds to the business event. This response is the processing done to satisfy the request from the outside. It could also be the processing needed to satisfy the business policy that is invoked whenever any time-triggered or conditional event occurs.

In short, the response is processing of some kind, and we call this chunk of processing a business use case (BUC).

It doesn’t matter whether the processing for the business use case is done by people or machines, or any combination thereof. It is simply processing. You can describe it in several different ways, and you will see examples of these as we go through the book.

The business use case starts at the point where the work is made aware that the event has happened: This is the arrival of the triggering data flow. The processing continues until several things have been achieved. The first is that all necessary data has been retrieved and stored. The second is that the desired business outcome of the BUC has been achieved.

Figure 7.4 is a process model that illustrates the BUC for the business event Customer needs coffee. There are several different notations for this kind of model, and you might use a different one for your own work. Don’t worry about the notation; instead, focus on the functionality and the outcome.

Figure 7.4

A process model of the business use case that responds to the business event Customer needs coffee. The work becomes aware of the event when it receives an incoming data flow, and then responds by activating processes to achieve the desired business outcome.

The business event happens when the Customer needs coffee and generates the triggering data flow Capsule Order. It does not matter whether this data flow is generated by the customer by filling in a screen, sending an email request, telephoning, or walking into a brick-and-mortar shop. The result is incoming data that is represented by the envelope icon in the starting event (that’s the circle at the extreme left of the model). When this data arrives, it triggers the response from the work.

When a business event happens, the work becomes aware of it by the incoming triggering data flow and responds by initiating a business use case.

The first of the responding activities shown in Figure 7.4 is the one that checks that there is sufficient stock on hand to fulfill the customer’s order. The database symbol shows that the activity is accessing stored data. (We’ll ignore for the moment the exception of there not being enough stock.) The next activity is to get an authorization from the credit card company, and then it goes on to record the sale and deduct the ordered quantity from inventory (again, the process accesses stored data).

There are two outgoing data flows from this BUC; one goes to the customer to acknowledge that the order is accepted and will be shipped, and the other goes to the Fulfillment Center where the capsules will be picked off its shelves and shipped to the customer. You can see these incoming and outgoing data flows on the context diagram in Figure 7.2.

The desired outcome for the business event has been achieved: The capsules will shortly be on their way to the customer, and the stored data about sales and inventory has been updated.

The outcome for each of your business use cases should contribute in some way to the goals of the project. If it does not, then it is a sign that the business event is not needed or is outside the scope of your project. Finally, you need to check that all the goals have been met. They can only be met if your scope is correct and you have discovered all the business events.

In the above example, the triggering data flow, Capsule Order, originated with the customer who is outside the work. Thus, we refer to this, naturally enough, as an external business event. Now let’s look at another kind of business event.

Time-Triggered Business Events

Time-triggered business events are initiated by the arrival of a predetermined time or date. For example, your bank generates a statement of your banking activity on the last day of every month, or your insurance company sends you a renewal notice a month before the anniversary of your policy. “The arrival of a predetermined time” could also mean that a certain amount of time has elapsed since another event happened. For example, you are sent a reminder if two weeks have elapsed since you were sent the original bill. Note that it does not matter whether the customer receives the output by paper or electronic means.

The usual response to a time-triggered business event is to retrieve previously stored data, process it, and send the resultant information to an adjacent system. The coffee capsule company sends out a monthly Club News Bulletin to all its club members. This gives general coffee advice, announces new coffee, and sometimes offers club members discounts on some capsules. The business event is Time to send out Club News Bulletin.

Figure 7.5

A time-triggered business event, this one happening every month. Data stored by previous business events (data stores are shown as named parallel lines) is retrieved, processed, and sent to an adjacent system(s). Here we see the Newsletter Copy and the Capsule Sales data being retrieved, processed, formatted, and sent to the Club Members.

The response to this business event is to retrieve the copy that the copywriter has generated over the past month and stored in a database within the capsule company’s work. The response also includes an AI module that looks at the sales figures, and where appropriate decides whether to offer a discount on the slow-selling capsules. All that information is formatted and emailed to the customers who have signed up to be members of the club. This response is illustrated in Figure 7.5.

Once the predetermined time for the event arrives, the work’s response is to do whatever is necessary to produce the output. This almost always involves the retrieval and manipulation of stored data. Once again, we use the response to the time-triggered business event—the business use case—as our unit of study.

Conditional Business Events

Conditional business events happen when a condition is met. This condition is usually established by a business rule.

For example, recall the business event where a customer orders capsules from the coffee company. If you glance back at Figure 7.4—the process model of the response—there is an activity called Record sale and reduce inventory. There is a business rule that specifies the inventory threshold that triggers restocking. If a customer order depletes the company’s inventory such that it reaches the threshold, it triggers the business event Need to resupply capsules. The response to this event is to predict how many capsules are needed and to place the order with the Capsule Supplier. You can see the outgoing order on the context diagram shown in Figure 7.2.

Data Conservation

Data conservation is a fancy name for “what comes out must have gone in.” If you look back to Figure 7.5, you can see that the process to generate the monthly newsletter uses three data stores. These are called Newsletter Copy, Club Members, and Capsule Sales. Note that a data store could be anything—automated or manual—that can hold data. As long as it can retain its data over time, we’ll call it a data store.

The data in these stores is put there by external business events. The Club Members data store is added to whenever a customer wants to join the club. There is a data flow on the context model (Figure 7.2) called Club Application. This contains data about the applicant and is stored in the data store Club Members by the processes of the BUC. Similarly, the Capsule Sales data store is added to whenever a Capsule Customer buys coffee.

The data that comes out of a business must have gone into it somehow.

But how does the Newsletter Copy get there? There is no flow on the context model to bring that data into the work area. All the data stored within the work area has to come from the outside, which it does whenever there is a business event. The triggering data flow carries the data into the work where it is processed and stored.

The lack of an incoming data flow carrying the copy means that we have a data conservation error, or more plainly, we have missed a business event. If the coffee company uses generative AI to produce the copy for the newsletter, there must still be a prompt coming from the outside to tell it what to write about, and some data it needs for its language model.

At this stage, that is, early in the project, it would be relatively easy to correct the context diagram and carry on. However, if you discover these data conservation errors later in the project, it will be more serious. It will cause considerable rework to incorporate the missed business events and their stored data.

Why Business Events Are a Good Idea

We may seem to be going to a lot of trouble to describe something that may, at first glance, seem obvious. But this attention to the subject provides a framework for discovering and managing your requirements. Consider that business events:

● Are significant happenings. Business events are more than a mouse click. They represent something that is important to the business.

● Are a natural partitioning theme. They represent the outside world’s view of the problem space.

● Are objective. They are determined by the work’s interactions with the outside world.

● Are the ways your outside customers see your business.

● Ignore internal partitions—departments, systems, technological items, and so on. These hold no interest for outside customers.

● Stop you, to some extent, from plunging into a presumed solution.

● Are cohesive partitions with minimal interfaces between the pieces.

● Are the ideal partition for the discovery of the requirements. You can investigate each event independently of the others.

● Can be used later as implementation units.

Finding the Business Events

Business events are significant happenings that cause the work to respond in some way. To get the work to respond, there can be a triggering data flow, or for a time-triggered and conditional event, there is a resultant data flow on the context diagram.

Let’s make use of that with a different case. Figure 7.6 shows the context diagram for a piece of work that predicts when ice will form on roads and schedules trucks to treat the roads with deicing material before they freeze. Look at the diagram and note the information flows that connect the adjacent systems to the work. For example, the flow called Changed Road is the result of the event that occurs when the Road Engineering department either builds a new road or makes significant alterations to an existing one. The engineering personnel advise the work of the change so that the scheduling work can update its own stored data about roads. The flow called Road Deicing Schedule is the outcome of a time-triggered business event: Every two hours, the work produces a schedule of the roads to be treated and sends it to the Truck Depot.

Figure 7.6

The context diagram for the Ice Breaker work. Note the flows of data entering and leaving the work. These indicate the presence of business events.

Table 7.1

List of Business Events and Their Associated Input and Output Flows for the Road Deicing Work

Event Name

Input and Output

1. Weather Station transmits a reading

Weather Station Readings (in)

2. Weather Bureau forecasts weather

District Weather Forecasts (in)

3. Road engineers advise there are changed roads

Changed Road (in)

4. Road Engineering installs a new weather station

New Weather Station (in)

5. Road Engineering changes the weather station

Changed Weather Station (in)

6. Time to test Weather Stations

Failed Weather Station Alert (out)

7. Truck Depot changes a truck

Truck Change (in)

8. Time to detect icy roads

Road Deicing Schedule (out)

9. Truck treats a road

Treated Road (in)

10. Truck Depot reports a problem with a truck

Truck Breakdown (in) Amended Deicing Schedule (out)

11. Time to monitor road deicing

Untreated Road Reminder (out)

12. Thermal Mapping Supplier updates maps

Thermal Maps (in)

Each flow that enters or leaves the work is the result of a business event; there can be no other reason for an external communication to exist. Looking at each flow, you can determine the business event that caused it. In some cases, several flows may be attached to the same business event. For example, when the Truck Depot advises that a scheduled truck has broken down or will be withdrawn from service (input flow Truck Breakdown), the work responds. Because one of the trucks is now out of service, the other trucks must be rescheduled to compensate for the shortfall, and the resultant outgoing flow is the Amended Deicing Schedule.

Table 7.1 shows a list of business events and their input and output flows for the deicing work. Compare it with the work context diagram in Figure 7.6 and reconcile the business events with the data that flows to and from the work.

Admittedly, you need some knowledge of the work to figure out the business events. To this end, we advise you to start the process of determining business events during blastoff, when the key stakeholders are present. In most situations, you find the stakeholders know the business events (they may not know them by that name, but they will know what they are). Try to identify all the business events during the blastoff. You might miss one or two, but you will find them when you begin to study the work.

Ready-made Solutions

Business events also apply when using ready-made solutions. A ready-made solution is something that already exists and can potentially solve your business problem. It might be a solution to the whole of the problem, or it can be a component that contributes part of the solution. Ready-made solutions can be bought, subscribed to, or acquired as an open-source solution. They can also be legacy solutions. These are whole or partial solutions that your organization has already built or bought. Ready-made solutions are also known as off-the-shelf (OTS) solutions, as commercial off-the-shelf (COTS) solutions, and sometimes as packages. In short, anything that we plan to use without building it from scratch we call ready-made solutions.

If your project proposes to use a ready-made solution or ready-made components then they must respond to the same business events as would any other type of solution. However, with the ready-made solution, your task is slightly different. Instead of discovering what the response to a business event is, you are discovering whether the outcome of the response from the ready-made solution is what you need it to be.

Figure 7.7 is the conceptual view of a proposed ready-made solution. The purpose of the diagram is to illustrate that the ready-made, “out of the box” solution responds to business events. The task is to assess the outcome of each event and compare it with the organization’s desired outcome. The desired outcome would include the data produced by the response, along with the correctness of the algorithms used by the ready-made response.

The objective is to assess whether the business events are suitable, whether the response conforms to the organization’s desired behavior, whether the response needs some modification to be made to the ready-made solution, or in some cases whether the organization needs to change to fit the ready-made solution.

We’ll revisit this later when we look at the Trawling activity in Part IV.

Figure 7.7

The ready-made solution (shown as an open cardboard box signifying an “out of the box” solution) is assessed as to whether the business events it handles match the needed business events and whether the outcome of each event matches the organization’s desired outcomes.

Review

Business events allow you to carve out a rational and cohesive piece of the problem space for further study. Instead of trying to understand the whole of the problem at once, you digest it one business event at a time. Naturally, it’s more effective to analyze moderately sized chunks. These responses—we’re calling them business use cases or BUCs—are independent of each other, so they make an ideal partitioning theme.

By using business events to partition the problem space, you are taking an external view of it. You are not relying on how it happens to be partitioned internally at the moment, or on someone’s idea of how it might be partitioned in the future. Instead, you partition the work according to the most important view of the work: how the outside world sees it.

Later, we will suggest that you develop and deploy the solution one business event at a time. But let’s not get ahead of ourselves. Before doing anything more, we should prioritize the business events.

Resources

Essential Systems Analysis by Steve McMenamin and John Palmer (Yourdon Press, 1984). This book introduced the ideas of essence and business events. Unfortunately, it is now out of print.

Business Analysis Agility: Solve the Real Problem, Deliver Real Value by Suzanne Robertson and James Robertson (Addison-Wesley, 2018). This companion book also looks at business events.

Business Analysis Techniques, 3rd Edition by James Cadle, Debra Paul, Adrian Reed, David Beckham, and Paul Turner (BCS Learning and Development Ltd., 2021). This has a slightly different take on business event analysis.

8

Prioritizing the Business Events

Not all business events are equally valuable to your customer, nor are they equally urgent. While you eventually must discover the requirements for all of them and implement all of them, you obviously cannot do all of them at the same time. And there is no need to.

At some stage early in your development cycle, you should stop, step back, and prioritize the business events you have. It makes sense when you are discovering the requirements to favor those events that yield the best return. The best return in this case comes from economically developing the events that are the most valuable to your organization and your customers.

Keep in mind that you might have already divided the problem space according to customer segments. So here you would be prioritizing the business events within each customer segment.

This chapter is about the factors to consider when determining which parts of the problem are to be given the most and/or earliest attention.

Priority, Priority, Priority

In the previous chapter you saw the context model for a company selling coffee capsules, and we discussed a few of its business events. The context model for this company is reproduced in Figure 8.1, but this time it has been annotated with the numbers of the business events. The numbers of the events do not signify priority; they are simply identifiers. They have been put in this order for reading convenience only. You must put them in priority order.

Figure 8.1

The business shown here sells coffee capsules and machines that use the capsules. The numbers attached to the data flows identify the business event associated with that flow.

This business is straightforward. Customers order coffee and pay at the same time. Either the work holds their credit card or the card number is submitted along with the order. A separate payment company processes the transactions. Authorized orders are sent to the Fulfillment Center, which packages and ships the physical goods. Customers can join the club, which gives them a newsletter and occasional discounts. From time to time, the capsule and machines in the Fulfillment Center are damaged or lost. When this happens, Fulfillment advises the work of the actual quantities of goods.

However, don’t spend time figuring out how this business works. The point of it is to look at the business events and prioritize them.

The numbers on the context diagram are a cross reference to the following list of business events. Note that some of the business events have multiple flows:

Capsule Customer orders coffee

Capsule Customer applies to join club

Capsule Customer orders coffee machine

Capsule Customer requests help

Time to publish Club News Bulletin

Time to forecast stocking needs

Time to order more capsules from the Supplier

Time to order more machines

Fulfillment Center advises actual stock levels

Take a few moments to check this list against the context diagram, and then consider which of the business events you would give the most priority to. You are just guessing at this stage, but it is worth the few moments to consider which of the events bring the most value to the business.

There is no single right answer to prioritization—it depends on multiple factors. Each organization, each project, each sponsor, and each product owner has its own priorities and preferences. While we cannot say which prioritization factors are right for your project and team, we can show you some of the factors that have proved useful over time.

Prioritization is affected by the people doing it. It should not automatically be a management decision. Sometimes fitting in with legacy solutions means different priorities, and these are in the domain of the business analyst, the product owner, and possibly some of the development team. Sometimes dependencies between events dictate priorities, again the domain of the business analyst. Then of course there are management factors such as revenue. The sponsor might need certain events before others. And there would be other people involved.

For the sake of simplicity, let us say that the people involved in the prioritization exercise are the key stakeholders. There is no fixed definition for this term, but most development initiatives have a subset of the stakeholders who are much closer to the initiative and have a greater interest in its outcome.

For example:

● The manager of the department where the solution will be deployed

● The product owner

● At least one of the business analysts

● The project sponsor

● The product manager

● The program manager

Key stakeholders vary from project to project, and exactly who is key is usually dependent on the organizational structure. The nature of the solution also influences who is key.

In short, you, the business analyst, need to find the people who are key to the project and invite them to prioritize the business events.

Estimating Effort

There is another factor needed to prioritize effectively: the amount of effort required for each business event. This effort estimation technique is borrowed from agile development where the team estimates “story points.” We’re in the Blastoff here, and we don’t have stories yet. Instead, we’ll use the story point technique to estimate the effort needed for each of the business events. Let’s change the name to event points to make it easier to visualize. You are estimating each business event with the intention of understanding how much effort it needs to complete the analysis and requirements tasks.

You have a list of business events. We looked at determining these in the previous chapter. Each business event has a business use case. The BUC is the functionality needed to achieve the outcome of the business event. It takes effort to uncover and analyze this functionality, and to write requirements, or stories, for a solution to implement it. You need to know how much effort.

Start your estimating with a smallish team of business analysts. During Blastoff, at best you have a brief description of a BUC, but you also have the experience of the team. Depending on their experience, they have some idea of what is involved.

To estimate the effort for a business event, the team holds a “planning poker” session. Each team member is given a set of “poker” cards with values 1, 2, 3, 5, 8, 13, 20, 40, and 100 event points. These numbers come from Mike Cohn (see Resources). Some teams use T-shirt sizes—S, M, L, XL—but Cohn’s numbers, based on the Fibonacci series, are probably better.

The team starts with a business event, and someone who knows a little about it gives a brief introduction to it. Then each team member uses his experience to allocate the number of event points. Event points represent the effort needed to complete the business analysis for that business event. This is illustrated in Figure 8.2.

Figure 8.2

Estimating the effort required for each business event, and awarding them event points

Estimating effort means considering the complexity of the BUC, the amount of work required, risks associated with the BUC, and the amount of uncertainty about it. Other factors are an assessment of how difficult it will be to get access to the stakeholders, and how much outside knowledge will be needed. Each team member privately makes his best estimate of the effort needed for this business use case to be fully understood and its requirements to be written. He then selects the poker card with the number of event points that represents his estimate of required effort. He puts this face down on the table.

When all members have made their estimate for an event, the cards are turned over and discussed. The discussion continues until the team reaches a consensus on the event points for the business event. Note that this is not the average of the cards, but the consensus value that the team arrives at. If someone gives the event a high score, then he is asked if he knows something that others don’t. If the numbers are widely dispersed, then after a discussion, the cards are played again. And it is worth restating that you’re looking for a consensus, not the average.

You are estimating effort, not time. Event points are not absolute units—you can’t say that 1 event point will take four hours or cost $1,000. You are allocating points on a relative basis—8 event points require a little over half the effort of a business event with 13 event points.

We’ll make several uses of event points. The first is prioritization.

Prioritization Factors

To prioritize, the key stakeholders consider some of the following factors, listed here in no particular order.

● Expected revenue: Back in Chapter 6, Customer Segments, we suggested you prioritize your customer segments using expected revenue as one (perhaps the most important) of the prioritization factors. It is a little more difficult to estimate the expected revenue from an individual business event, but with some help from your accounting department, you can usually make reasonable estimates of revenue per event.

● Business value: This might simply be revenue, but it can also mean the contribution the business event makes toward the goals and benefits of your project.

● Required effort: Is the value of a business event—expressed in event points—worth the effort needed to analyze and implement it? Consideration is given to whether it’s better to do the big-effort or small-effort events earlier.

● Data dependencies: When business events happen, the triggering data flow brings data into the work and stores it. This stored data will be subsequently needed by another business event. You would need a rudimentary data model, or a CRUD table (we’ll talk about CRUD in a subsequent chapter), to know your data dependencies, but this might be a worthwhile prioritization exercise to help the eventual implementation.

● Minimum viable product: If your project intends to develop a minimum viable product (MVP), then the product owner liaises with the business analyst and management to decide which business events are to be part of the MVP. These events are pushed to the top of the list, leaving the remainder to be developed at some later time. Naturally, the remaining events are prioritized before proceeding with them.

● Adjacent systems: Some of the adjacent systems on your context diagram are more important to the business than others. The business events that affect these adjacent systems can thereby be given a higher priority.

● MoSCoW or MuSCoW: This means Must have (crucial); Should have (important but not crucial to success); Could have (nice to have but not essential); and Won’t have yet (include these when time permits). MuSCoW doesn’t tell you how to assign a priority; it is just there to give you a label for your priority assignment.

● Risk: This applies to business events that carry the possibility of failure. Perhaps they involve some new, untried technology, or perhaps customer acceptance of the event is yet unknown. Risky business events should be done as early as possible. There is no point in spending most of your budget and then discovering that something cannot be done.

● Market impact: Is this event one that is innovative and new, and is intended to have a significant impact in the marketplace? If so, move it higher on the list.

● Time needed to develop: These are early days, and we are not yet thinking too much about the implementation of this part of the solution. However, sometimes the nature of the business event suggests that it will be difficult or time-consuming to implement. This is really a product owner’s call as to whether to do the time-consuming things early or late.

● Visibility: Sometimes you find your project running late, or sometimes you have a threat to your funding. You need a success story, or something that brings attention to your solution. Pick the flashiest, most client-pleasing business events and, providing they are not excessively time-consuming, move them up the charts.

Having looked at some of the prioritization factors, you might care to reconsider the priorities for the capsule company’s business events. You saw this a little earlier.

Event 1, Capsule Customer orders coffee, is certainly the revenue earner, and for this reason you might want to start with it and devote a little time to ensuring it is the best buying experience for the customer. However, event 9, Fulfillment Center advises actual stock levels, is the one that establishes the data needed for event 1. This event happens when the fulfillment people adjust their stock counts for damage or loss, and when a new shipment of capsules arrives from the supplier. This event informs the work of the actual stock counts, so it would be the highest priority if you want to establish data dependencies.

You might think about the adjacent systems, and Capsule Customer is the most important of all. For this reason, you might consider all the events connected to the customer as top priority and work on them first. These are the ones that make the most obvious contribution to the project’s goals.

There is no single right answer, but using the prioritization factors, you and your key stakeholders can reach agreement on the priority of the business events.

Your own list of business events for a project that you are doing at work would likely be longer than the above list. This makes the prioritization task a little harder, but the longer the list is, the more necessary it is to prioritize.

The priorities of the business events can change. As you discover more about the work and the business problem, you might need to alter your thinking about priority. Similarly, it is quite possible that the problem space changes. By having the priority factors and your list of priorities, you and your stakeholders have a mechanism for reprioritizing.

Approval Voting

Approval voting is an electoral system that is particularly effective when multiple parties or candidates are contesting an election. It is especially suited for those European countries that have lots of smaller political parties, and is used in some American cities.

You start with the candidate business events. You have a list with, say, 20 to 40 business events on it, and you want to reach a consensus with the key stakeholders as to the relative importance of these events.

Approval voting works by stakeholders giving one vote for each of the business events that they approve of and want to see implemented early. Each stakeholder can vote for as few or as many of the events as they approve of. (Voting for every event nullifies that stakeholder’s votes.) The winner is the one that has collected the greatest number of approval votes.

The advantage here is that the winner is a consensus of the key stakeholders. But it’s not just the winner you are concerned with. Approval voting gives you the chance to see the distribution of approval votes, and it clearly shows the ranked support, or lack thereof, of each of the business events.

Approval voting is possibly the fairest way of determining priority. It can be thought of as a popularity contest, but if some events are popular with a significant number of key stakeholders, those events must be crucial, and thus high priority.

Business Analysis Planning

You now have two things to use for planning the business analysis work. One is the event points—representing the effort needed for an event—and the other is the priority in which the business events are to be tackled.

Starting with the highest priority, you need to allocate events to team members. It makes sense to give the one with the highest event count to the team member who is most productive. We know there is a significant difference between people when it comes to productivity. You only need to look around your office to see this.

For the sake of illustration, let’s say there are three team members, and we’ll call them Alpha, Beta, and Gamma. Alpha is more experienced and is good at getting the work done. Gamma is young and inexperienced, and so is not yet as productive as Alpha. Beta is somewhere in between the others.

The top three events on the priorities list have event points of 3, 8, and 13. You give Alpha the 13-pointer, and Gamma gets the 3-point event. When you estimated the event points, difficulty and uncertainty were two of the factors you used. What better than to ensure that Alpha—and other Alphas in the team—tackle the difficult, uncertain events.

As time goes on, you can begin to get a sense of the speed, in terms of event points, the team is achieving.

Review

On a personal level, you prioritize when you decide whether to go to a movie or have an early night. You prioritize when you decide your monthly spending budget. Your government prioritizes when it decides the national budget. Prioritization, as we are discussing here, means determining what is valuable to the organization and the project. This is the important stuff, and you do it early. This way, when you run into the inevitable deadline problems, you’re left with the less consequential stuff. It also has a psychological effect that the team works on the best stuff early in the project when enthusiasm is highest.

Prioritization is illustrated in Figure 8.3.

Figure 8.3

The business events are prioritized, and the highest-priority events are trawled and prototyped to discover the requirements. The process is iterative.

Prioritize early; prioritize often.

Prioritization varies from project to project—the prioritization factors vary according to the situation. They also change throughout the project. This means that of course you prioritize early, but you also prioritize often. Whenever there is a change to the scope, the stakeholders, or the goals, it is an indication that there might be a need to reprioritize. As you progress with your project, things change, and some of these will change your ideas on what is important.

Resources

Agile Estimating and Planning by Mike Cohn (Pearson, 2005). Mountain Goat Software (https://www.mountaingoatsoftware.com) is Mike Cohn’s website. He is mainly concerned with agile development, and his guidance on using planning poker for estimation is aimed at product backlogs. We are using planning poker here to estimate business events.

Agile and Business Analysis: Practical Guidance for IT Professionals, Second Edition, by Lynda Girvan and Debra Paul (BCS, The Chartered Institute for IT, 2024). This covers various agile techniques, including MuSCoW prioritization of requirements.

ProjectManagement.com. This website (https://www.projectmanagement.com/#_=_) is not strictly about business analysis and requirements, but it has a range of articles, blogs, and resources on project management. You can find information on task prioritization techniques, including those applicable to business analysis.

International Institute of Business Analysis (IIBA). The IIBA website (https://www.iiba.org) provides access to articles, webinars, and resources related to business analysis practices, including prioritization techniques.

9

To Go or Not to Go?

We have left this discussion on whether to proceed or not until this last chapter of Part II, Project Blastoff. However, that does not mean that any project should leave it until late to decide whether going forward is the right option. To go or not to go is a question that should be asked early and often.

Back in Chapter 5, we discussed goals-scope-stakeholders. Right there is a point at which you have an idea as to the viability of the project and whether it is sensible to proceed. Again, when you look at the real problem to solve, you must ask if this is the right problem to solve. Does anybody really need this? Or should you be looking at another part of the business for a more advantageous opportunity?

In Adrenaline Junkies and Template Zombies (see Resources), together with our Guild¹ partners we wrote about “dead fish” projects. From day one, this type of project has no chance of meeting its goals, and most people know it but say nothing. Despite all the other dead fish littering the beach, this one presses ahead.

FOOTNOTE 1

The Atlantic Systems Guild (https://systemsguild.eu) is a transatlantic partnership of thinkers and practitioners in the business analysis and systems domain.

Dead fish projects happen because people are discouraged from asking, “Should we proceed with this? Should we go or not go?” And yet, given that most projects fail in some way, this is a question that should be asked again and again. Somehow it is seen as shameful to question the legitimacy of a project, and even more shameful to cancel one.

We have now looked at all the things you can do in the Project Blastoff. Using these as ammunition, it is time to put aside any embarrassment and ask if going ahead or stopping the project is the most beneficial thing to do.

Each time you and your team come together to decide whether or not to proceed, there are a couple of things to consider.

The likelihood that the project will be successful. That is, the project delivers a solution that provides the desired business outcome.

Whether the solution will provide a return on investment. Over the lifetime of the solution, it brings enough benefit to warrant the cost of developing it.

It is worthwhile to look at both in some detail. We understand that business analysts are not always involved in this kind of work, but they should be. The business analyst is usually impartial—she has no political investment—and is the closest person to the business problem. The role of the business analyst here is to supply the information that enables enlightened decisions to be made as to project viability.

The Likelihood of a Successful Project

Too many projects end up as dead fish. As previously mentioned, these are hopeless cases and drag on for months despite the team’s objection to the smell of the dead carcass. The bizarre thing here is that all too often, the team knew at the outset that the project was doomed and would end up metaphorically rotting with the other carcasses on the beach.

Let’s avoid that. There are some simple enough checks that reliably indicate the likelihood that your project will be successful, or that you are better off to abandon it now.

Goals

There should be a limited number of goals. We have found that up to five (no more) well-stated, measurable goals can steer the project. More goals than that defeats your ability to focus on the important things and to keep your requirements discovery consistent with the goals.

Then you should ask if the goals are clear and unambiguous. Fudge words and corporate buzzwords are danger signals. However, when the language is concrete enough that everybody can agree on its meaning and thus the goal, your success likelihood indicator moves up a notch.

Does the goal indicate a desired business outcome that will bring an actual benefit to the customer and to your organization? Further, is this benefit measurable? The simple thing to look for here is whether the goal contains numbers. A goal that says “Lower production costs by 4%” can be tested to determine the effectiveness of the solution, whereas “Streamline production” is so vague that almost any solution would qualify.

The reason for having measurable goals is to establish a precise target, and for you and your client to be able to objectively say when you have successfully completed the project.

Risk

Risk is not necessarily a bad thing—we face risks every day. Just leaving your home to go to work involves some risk: Your car won’t start, the train will be late, you will be assigned to share an office with someone you don’t like. But still, you go to work each day because you know the risks and consider the outcome (your salary and job satisfaction) to be worth the risks.

Similarly with development projects: Taking risks is necessary if you are to make advances. Nothing was ever gained without some risk of failure. Bill Gates and Paul Allen knew they were taking a risk when they dropped out of Harvard to start Microsoft. Jeff Bezos knew the risks when he quit his Wall Street job to start Amazon. The point is that there is a difference between calculated risk and recklessness.

But each day people plunge into projects where they have no idea of the risks involved, and thus no idea whether the intended outcome is worth taking the risks.

Have you ever worked on a project where nothing went wrong?

Have you ever worked on a project where nothing went wrong? Neither has anyone else. But did you ever try and figure out ahead of time what could go wrong and do something to prevent it from going wrong, or at least allow for the mishaps by budgeting for them? This, in its simplest sense, is risk management.

The criticality and the cost of your project determine the formality of your risk management. For short, sharp projects, it’s probably enough to sit down with the team and ask: “What kind of mishaps has the organization had with this type of project before? What is the possibility of that happening again? [The answer is not zero.] How severe was the impact of the mishap? Do we need to take mitigating action, or can we deal with it when or if it arises?”

A short list of common project risks might be helpful, shown here in no particular order:

● Inaccurate estimation of cost

● Vague goals

● Too little time allocated to the project

● Inappropriate people on the project team

● Incompetent people on the team

● Knowledgeable or skilled people leaving the project team

● Difficulty of recruiting project team members

● Aggressive deadlines

● Failing to discover the real business problem

● Scope creep

● Lack of stakeholder involvement

● Inadequate knowledge of the technology involved

● Unmet expectations

● Poor project management

● External risks—changes in the market, new laws, and so on

● Poor user uptake of the delivered solution

● Absence of any risk management (yes, it’s a risk)

● Inadequate resources

● Absence of project sponsorship

● Poor productivity

All of the above, and more, have happened and are happening today on development projects. It is folly to deny that none of the above will apply to your project.

For large, mission-critical projects, it is reckless to proceed without formal risk assessment done by a competent risk specialist. The cost of doing it is amply repaid when it reveals risks that, if manifested, could have the potential to cause the whole project to fail.

Whatever the scale, you, your team, and your management need to be aware of risks that might become problems. You can also identify early-warning signs that a risk is coming to fruition and whether you wish to take mitigating steps.

To know if risks are becoming obstacles, Adrian Reed points out the value of having a tripwire. Tripwires were originally wires strung about a foot off the ground around the perimeter of your camp so that if the enemy, or a grizzly bear, tried to sneak up on you in the dark, they would trip over the wire and set off an alarm. In projects, a tripwire is a condition that you set in advance. If this condition is met, it triggers a warning that you need to pay attention to something.

For example, you might set a tripwire about the state of the project. Your tripwire might say that ten business events must be analyzed and implemented by the end of the year. The wire can be tripped for several reasons: lack of stakeholder commitment, incompetent people on the team, uncertainty of purpose, lack of skilled personnel, and so on. Whatever the reason, if you don’t achieve your ten business events, the wire is tripped and you regroup and reevaluate.

Risk is a double-edged sword. You try to avoid some risks, but most opportunities carry risk. Say you are about to implement a radical change to the way your company processes its payroll. If you pull it off, it will save tens of thousands of dollars each year (by being more effective, not by reducing employees’ salaries). The technology needed to do this is as yet untried, but the potential savings mean that this is a risk worth taking. You would of course monitor the risks and perhaps set a tripwire or two.

Tim Lister, our partner in The Atlantic Systems Guild, summed this up very simply: “Risk management is project management for grown-ups.”

Cost

One of the factors that determine whether your project should be allowed to go ahead is whether its cost in time or money is affordable given the benefits.

Estimating cost is not within the jurisdiction of the business analyst. (If you want to know more about it, there are several references in the Resources section.) However, as a business analyst you are the responsible adult in the room when cost estimates are presented. Somebody has to be the grown-up, because most projects fail to deliver within budget. Flyvbjerg (see Resources) points at IT projects that have exceeded budget by more than 400%. According to Gartner studies, 75% of all US IT projects fail to deliver on time and within budget. Other studies have shown that (coincidentally) 75% of IT people do not expect their projects to succeed.

What’s going wrong here? Clearly a large share of the blame must lie with the expectations for the project. Many projects start with seriously underestimated costs. Why? Because people want to do the project, and deflating the budget and inflating the advantages is a very common way to convince management to run the project.

As a business analyst, you cannot prevent that from happening, but you can point out that the estimates are low. For example, look at the number of business events, or the number of flows on the context diagram. If you were to divide the budget by the number of events, does the average cost per event fall on the “reasonable” side of the ledger, or the “fantasizing” side?

Viability

Viability is about whether or not the project has a chance of succeeding. It is not viable to leap off a tall building with the expectation of flying, and yet many projects metaphorically do so.

The point here is that the estimate of time or money needed must be within the budget. If not, either the budget is increased, the scope of the project reduced, or the project abandoned. We are talking about viability here, and an inadequate budget of time or money means that the project is anything but viable.

As a business analyst, you spend time with the stakeholders. This means you are in a position to assess the cultural viability of the project. Is it likely to produce a solution that will fit with the users’ acceptable way of working? Will it be a good match with the prevailing organizational culture?

Technical viability is assessed by asking if the organization has the skills to construct any potential solution. If the team is not familiar with the likely technology, then the viability of the project is compromised.

You should also consider the risks that were mentioned above. If there is a strong chance that one or more of these is likely to become a serious problem, then you need to question the viability of the project.

Ready-made Solutions

For ready-made solutions, the decision to go or not to go is similar to what we have been describing. Your assessment takes in the cost of the ready-made, if needed the cost of modifying the ready-made or changing the organization, and the desirability of the ready-made’s outcome for each business event.

Modifying the organization to fit the ready-made happens more and more often. The cost to consider here is the cost of disruption. The people doing the work have to learn new procedures, which usually brings a certain amount of uncertainty. This affects productivity for a little while after the ready-made is deployed. Organizations don’t go from 0 to 100 in a day; it takes time before productivity is back up to previous levels.

The other cost that might affect viability is whether there are human costs associated with the ready-made. Do people have to do extra tasks because of the ready-made? Do they need training? Do backup and security bring extra work? These things should be brought up as part of your decision to buy or build.

Develop the Business Case

It is unlikely that in the commercial world, you would embark on a project if there were no financial reward for doing so. Perhaps in the military the emphasis would not be on money, but a defense department would want to quantify their return on investment—the number of incoming enemy missiles intercepted and destroyed, the improved range or accuracy of an artillery piece, or some such. Whether it’s commercial, military, medical, government, or internal, we should expect some kind of return for the money and effort we put into developing our solutions.

The role of the business analyst is expanding—they are no longer limited to writing requirements. What we are about to discuss might be thought of as a management task, but our experience points to business analysts becoming more and more involved in developing the business case for the project.

The business case is the justification for your project. It balances the advantages of completing the project and delivering a solution with the disadvantages of not having the solution. The objective is to present the information needed for the organization to decide whether your project is a worthwhile investment.

Business cases often make recommendations but should not be used as a sales pitch for a preferred solution. The business case should be a presentation of the facts. If the facts are clear enough and presented coherently, then arriving at the right decision is more likely.

There is no fixed format for a business case, so when you write yours, or contribute to one as a team effort, you can write it pretty much any way you see fit. However, we suggest the following set of items make a solid business case.

Business Problem

The best place to start your business case is with the business problem you are proposing to solve. We looked at this in previous chapters when we discussed goals, essence, and the real problem. You should elaborate a little on the business problem by including some background. The background should demonstrate why this is a problem. Describe this succinctly; there is no need to rabbit on for page after page. If the problem exists, it will be easily recognized by your readers. You should connect your description of the business problem to the scope, stakeholders, and goals that we looked at earlier. For example:

Orders are taking too long to reach the customers. We are losing customers as a result (5% fewer customers this financial year, revenue is down 6.5%). Six of our competitors are beating us on the time they take to deliver. Our warehouse and its equipment are up to 15 years old, and our fleet of delivery vehicles, and the drivers, are older than average for our industry.

Sometimes the business problem is an opportunity. That is, instead of something needing correcting, there is an opening of some kind that can be taken advantage of. You can treat business problems and opportunities as the same thing.

Value Proposition

You should write a value proposition: a statement of the solution the organization proposes to offer. The value proposition is a promise of the value the solution will provide to a customer segment. Thus, the purpose of the value proposition is to enable a customer to assess the benefits of possessing your solution.

A value proposition might also propose value to stakeholders other than the customer. These are values that would be realized to these ancillary stakeholders when the customer uses the solution. For example, previously we spoke of a traffic regulating solution. The customer for this is the road authority; the ancillary stakeholders who would receive value from the solution are the residents and the police.

Previously we discussed goals, and how goals should be quantified: “Customers are able to acquire a mortgage in less than 15 minutes”; “The cost of claims processing will be reduced by 12%”; and so on. The goal is the value of having your solution.

You might go further with your value proposition and add value drivers: the major capabilities of your solution that help to bring about the value. For example, you’re proposing a solution to allow commuters to use their debit cards, phones, watches, and so on to pay their fare on a Metro system. The value of this is the convenience of fare paying: The time taken for commuters to buy tickets is zero, the customer satisfaction is estimated above 80%, and the cost of fare collection is reduced by 65%.

The value drivers here are

● Connections to debit card payment systems

● Connections to other payment systems

● Automated entry/exit barriers

These give weight to your proposal of value.

Don’t confuse these value drivers—you might think of them as features—with benefits. The automated barriers are a feature; the benefit is faster, cheaper access to the Metro.

Risks and Assumptions

All projects face risks; we discussed this earlier. We suggest that you include in your business case the most impactful risks. You should also include the risk of not developing a solution. For example, “Our competitors are developing similar solutions, and we risk losing customers if we don’t have our own solution.”

Assumptions are part of the business case. Sometimes you are basing your case on assumptions such as “The price of oil will remain over $100 per barrel”; “People will continue working from home and not commute”; or “Younger people will reduce their social media usage by at least 50%.” It is important to bring your assumptions into the light—your management must be aware of them to either endorse or refute them. Figure 9.1 illustrates balancing risk with advantages.

Figure 9.1

The business case is an assessment of whether the advantages that the solution will bring outweigh the costs and risks of building or buying a solution.

Options

Here you show the options that have been considered for the project—including those that were discarded and those still under consideration. Options can be to buy, build, borrow, enhance, revert to manual, outsource the problem, outsource the solution, abandon the commerce, use a sister organization’s solution, and so on. One option that should always be considered is to do nothing and ignore the problem. It’s obviously the cheapest thing to do, and over the years might have saved a few overeager teams from developing sunroofs for submarines.

This section should show the feasibility of the options. These can be any of the following.

● Technical: Do we have the technical resources to buy and install, or build a solution?

● Business: Does it fit the organization? Is the market the right market and ready for this?

● Financial: Do we have the money to build this option, and what is its return on investment?

● Better alternatives: Are there things that the organization could better invest in?

Cost

We previously said that estimating the cost of development is beyond the remit of business analysts. However, it is in someone’s remit, and you should ensure that the estimate of cost is based on something tangible. You as the business analyst can provide tangible assets such as a context diagram, a list of business events, and perhaps a first cut of a data model. All these have factual, countable elements that should be used as input to the estimate.

If you wish to know more about estimating, we refer you to the Resources section at the end of the chapter.

Keep in mind that cost is often wildly underestimated, for political reasons. For example, management might balk if the real costs were presented, and so they are artificially reduced. You need only look at the statistics for cost overruns in IT projects to confirm this. The purpose of a business case is to evaluate whether it is worthwhile developing a solution. The whole case hinges on having realistic estimates of cost, so having hysterically optimistic reduced costs is entirely self-defeating.

Some agile projects like to start out without an estimate of cost, with costs being estimated cyclically as the project proceeds. This might seem attractive, but if eventually the cumulative costs outstrip the advantages, then it turns into a poor choice.

It is possible to estimate costs within a reasonable degree of accuracy. Take advantage of justifying the project on a realistic projection of cost.

Return on Investment

Here you set out the financial justification for the project. First, the value—we looked at this a moment ago. Value is the benefit that the customer receives from having your solution. At this stage (we are still in the Blastoff), you do not know exactly what your solution will be. But that is not the point—the point is to determine whether your organization wants to spend the money and resources to discover what solution will best serve the business need, and then build or buy that solution. The benefit can exist without you knowing exactly how you will achieve it.

The cost of investigating the problem and finding a solution is naturally a significant part of your business case. You state your expectations of cost, along with the resources needed.

A cost that should not be overlooked is the disruption cost of your solution. If, say, your solution is to be deployed in-house, then your users’ productivity will plummet for a period while they learn the new solution, come to grips with their new business process, overcome the natural resistance to change, and so on. The disruption cost should not be ignored, as it is usually significant. To think that users will be 100% effective on day one of the new solution is delusional.

The return on investment (ROI), simply put, is the benefit received from having the solution, less the cost of acquiring the solution.

Of course, you have to take into account the lifetime of the solution. It is unlikely that you receive a positive ROI in the first year—usually it takes longer for the benefit to overcome development or purchase costs. As part of determining the ROI, you must consider the expected lifetime of the solution. If the product will no longer be relevant in five years’ time, then the returns must be achieved before then.

Almost all installed solutions are modified over the years, sometimes extensively so. The expected maintenance costs for your solution need to be part of your determination or ROI.

Resources Needed

It is still early days, and you cannot precisely know the skills, people, and technology that will be needed to build or buy a solution. But you are making the business case, and so must give some indication of the resources that might be needed along the way.

Your organization has likely undertaken similar projects before, so sitting down to coffee with a few project leaders and product owners would give you a reasonable idea of the needs based on organizational history.

The reason for this section of the business case is that your management needs to assess whether these skills and people are available or could be hired.

Time

Consider your window of opportunity. A business case cannot be made to develop a solution if it will take two years, and you know that in two years’ time the solution will be irrelevant.

Your window of opportunity is closed by factors beyond your control. The business ecosystem for your proposed solution is constantly changing. The technological environment is also (rapidly) changing. Market sentiment, the law, and your customers are constantly changing. You cannot expect the world to stand still while you develop your solution.

The time that is most important to your business case is the time between you delivering the solution and the time it becomes irrelevant or superseded. That is the time when you achieve ROI; that is the time to talk about when writing your business case.

Preferred Option

It might be apparent, given all the information you have provided so far, that there is a solution that is noticeably more suitable than any of the other options. In this case it is as well to declare it, but don’t use this section to promote a presumed or pet solution.

Justification

This is the executive summary of the business case. You write your conclusion saying that one of the options is justified and this is why.

To Go or Not to Go

Before we leave this topic, it must be mentioned that there are many other ways that help assess the viability of starting a project to solve a business problem: techniques like SWOT, fishbone diagrams, pestle, and many more. There is no coverage of these techniques here, but to see the most complete list of them, we refer you to James Cadle and Debbie Paul’s book, Business Analysis Techniques (see Resources), where they cover 123 of them.

However, we find that writing a good business case is sufficient in most situations. The main purpose of the business case for you is in collecting the information needed to present the case. Once you have done that and written the case in a coherent and truthful way, it more or less makes the go/no go decision for you.

If the case is feasible and is approved by the person paying for it, then you can proceed with confidence that your solution, whatever it is and whenever you deliver it, will bring a benefit to its customer. And because it is feasible, you will be more likely to be able to deliver it.

In short, the business case gives you the answer: to go or not to go.

An Agile Approach to Blastoff

The Project Blastoff provides a justification for starting the project. However, there are some projects where the team prefers not to do much up-front planning. Instead of debating the wisdom of this approach, let us look at how you might pull it off.

We suggest that it is unwise to start a project without a solid foundation, and we think it is lunacy to start one without a business case. The business case is the justification of the project, and if you have no justification for the project, then you have no business doing it.

There are parts of the business case that are essential for any kind of enterprise. These are things that, should you set out without paying at least some attention to them, you might find yourself wandering in the desert.

Projects fail unless they know the business problem they are solving. Not just an assumed solution to the problem, but the actual problem. The scope of the problem is also needed. Projects without some ideas of the scope are doomed to almost eternal scope creep, and spending time developing solutions for things that are not part of the problem the customer needs solved.

Estimating the cost and time for the project is sometimes shunned in favor of estimating at the beginning of each cycle. But this cannot work unless there is some scale of commitment established at the beginning of the project. Without some limit to the project, it is possible to run up a huge bill with little to show for it.

In any event, it is hard to make the business case if the benefits of the solution are unknown or not quantified, and the cost of achieving that solution is indefinite.

However, Figure 9.2 shows an approach to running an agile project and keeping the up-front planning to a minimum.

Figure 9.2

An agile approach to the blastoff

The cycle starts with the Reduced Project Blastoff. This would, at a minimum, establish the business case for the project. One of the elements of the business case is the advantage to be gained from having the solution. Unless your project is pure research, then it should only exist if there is some measurable advantage to it. Additionally, it is only an advantage if the lifetime cost of the solution is less than the benefit from having the solution.

The scope of the problem must also be established. Without an agreed boundary to the problem, any project is rudderless—it is impossible to tell what is in and what is out of scope, and when to stop discovery and development.

A truncated business case and a defined scope—preferably using a context diagram—is the bare minimum for a Reduced Project Blastoff.

But let’s start with that. The next activity, Go or No Go, is to decide whether to go ahead or to stop the project. Should you go ahead, then the highest-priority business event (or events) is investigated to discover its requirements. This of course depends on you having a list of the business events, but that is easy enough if you have a context diagram.

This event is developed and then comes a Mini Blastoff. The activity here is to assess whether the lessons learned from the previous cycle give you any reason to update the business case. Perhaps you learned that things are going to be much more expensive due to technological problems. Or you learned that some of the features you planned are not needed. Whatever you learned is used to update the business case.

You also use what you learned to estimate the effort needed for the next cycle. Note that you are estimating the effort required to discover and deliver one business event. As we have previously mentioned, a business event is a stand-alone chunk of functionality, and therefore ideal for a cycle. (We’ll have a lot more to say on this in Chapter 35, Story Map, when we talk about using story maps to synchronize requirements discovery and implementation.)

You might also reassess the priorities of the business events here.

When you have updated (if necessary) the business case and estimated the effort for the next cycle, you again decide the go/no go question. And if you decide to go, then you discover the next lot of requirements. And then the next. And so it continues and continues to continue until you either decide that not going ahead is the wisest thing to do or run out of business events, or because you’re doing this on a prioritized list of events the next one is so low priority that you decide not to do it and all subsequent events.

A cyclic process is a learning process. Each time around you learn something new about the requirements and the solution. You also learn about the effort required. Instead of one blastoff, you have many mini blastoffs.

Review

Some organizations, hopefully not yours, are repeat offenders. Project after project fails to deliver, or is abandoned partway through, or, and this is the worst offense, restarts the project, making exactly the same mistake.

The mistake here is launching a project when the chances of it delivering something of value are close to zero.

Of course, this does not apply to all organizations, only those whose teams, or managers, are so anxious to rush in and build something that they fail to stand back and consider whether they should continue or walk away.

Does the business case give ample justification for doing the project? Is there a realistic business case in the first place? Does this project face unnecessary risks (remember that all good projects have some risk; otherwise, they would not make any advances), or have the risks been considered? Is the cost reasonably accurate, and does it indicate that the project will bring a suitable return on the investment of doing the project?

In short, will the project deliver a business solution that repays the effort expended to build it?

Finally, have you and your team stood back and carefully considered whether you should go ahead, or stop before any serious money is wasted?

Resources

Essential Systems Analysis by Steve McMenamin and John Palmer (Yourdon Press, 1984). This book introduced the ideas of essence and business events. Unfortunately, it is now out of print.

How Big Things Get Done by Bent Flyvbjerg and Dan Gardner (Macmillan, 2023). Flyvbjerg is not talking about IT projects directly, but what he has to say about the up-front planning work should be required reading for all business analysts and project leaders. He has something to say about projects that should never have been started.

Making Risk Management Work: Engaging People to Identify, Own and Manage Risk by Ruth Murray-Webster and Penny Pullan (Routledge, 2022). The central theme of this book is that successful risk management is not merely a matter of following processes and procedures but involves creating a culture where everyone in the organization understands, identifies, and takes responsibility for managing risks.

Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco and Tim Lister (Dorset House, 2003). This book provides a practical and insightful approach to understanding and mitigating risks in the software development process. The authors argue that risk is not a bad thing—we must take risks if we are to advance. The book emphasizes the need for proactive risk management rather than trying to eliminate risk entirely.

Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule by Johanna Rothman (Practical Ink, 2015). This book emphasizes the importance of pragmatism and offers a real-world perspective on estimation, acknowledging that software development projects are not always predictable and that perfection in estimation is not the goal. Instead, the focus is on providing valuable, actionable estimates that support effective decision making throughout the project life cycle.

Return on Software: Maximizing the Return on Your Software Investment by Steve Tockey (Addison-Wesley, 2004). The author sees software development not just as an expense, but as an investment that should provide a return. Tockey emphasizes the need to think strategically about software projects, considering their potential long-term benefits.

Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson, and Suzanne Robertson (Dorset House, 2008). This book introduces the concept of the “dead fish” project.

Business Analysis Techniques: 123 Essential Tools for Success, 3rd Edition, by James Cadle, Debra Paul, Jonathan Hunsley, Adrian Reed, David Beckham, and Paul Turner (BCS Learning and Development Ltd., 2021). The authors discuss 123 business analysis techniques.

Part III

Prototyping for Requirements

Prototypes, as we are using the term here, are explorations of the problem space. You can think of them as experimenting with the problem by proposing a solution. History is full of such experiments: Some were tried and abandoned for being impractical; some were tried and, while not developed, led to further experiments in a different, successful direction; and some showed that the product under consideration was worthwhile and viable.

We are using prototypes to rapidly explore the problem, explore the customer’s perception of the problem, and ensure that we are indeed solving the right problem.

Sometimes the customer doesn’t know what is needed and won’t know it until he sees it.

Traditionally, once you have the blastoff deliverables of scope, stakeholders, and goals, you start asking requirements questions of the stakeholders. But when you are prototyping for requirements, you are asking the questions in a different way. You are giving your customer something visual, something more engaging than a list of questions, something that better demonstrates the impact of the proposed requirements. You know your prototyping effort is working when the customer treats a prototype as if it is real—even though she knows it’s not—and comes up with requirements that would make it work even better.

The process schema shown in Figure P3.1 highlights the Prototype for Requirements activity. However, it is not intended to be used exclusively or in isolation. The Trawl for Requirements activity (the more traditional way of discovering requirements) is a parallel activity. You will almost certainly use both. The results from your prototyping efforts determine how much of each you use.

Figure P3.1

Prototyping is used to discover requirements that are added to the central requirements repository (your specification, or story map, or backlog, or whatever way you store your requirements). The more traditional Trawling activity is also discovering and adding requirements to the repository. Later, when we look at Designing and Developing, we’ll again use prototyping to experiment with business solutions.

Before going further, we must point out that “prototype” is the wrong word. Most dictionaries have it that “prototype” means the first, or preliminary, version of a solution from which other forms are developed. For the purposes of this book, we go along with common IT practice and say that a prototype can be anything from a rough sketch (preferred) through to a piece of software that might turn out to be the forerunner of the solution to be built. It might also be some kind of physical model or demonstration, or any other form that makes it possible for people to share ideas. It doesn’t really matter. What matters is how you use your “prototype” to find all the right requirements and confirm that you are solving the right problem.

ISO 9241-210: “A prototype is a representation of all or part of an interactive system that, although limited in some way, can be used for analysis, design and evaluation.”

We are talking about sacrificial prototypes. They are sacrificial because you do not intend to have your prototypes evolve into the solution. You are using the prototypes to explore the problem, and after the exploration, you throw away the prototypes but keep the knowledge.

These are probably just sketches of possible candidate solutions. You are using these sketches to question your customer about the impact of the candidate solution. You ask questions like: Why does this candidate solve the right problem? What would you do if you had this solution, and why would you do it? Would this candidate cause problems in other areas of your business? Does this candidate trigger other ideas? Then you ask yourself what you learned about the problem and what you learned about the requirements for the solution to the problem. This is illustrated in Figure P3.2.

Figure P3.2

The business analyst and the customer explore the business problem using sacrificial candidate solutions.

Sometimes using prototypes brings out better answers when you are trying to uncover the real business problem to be solved. By looking at some visual representation of a possible solution, your customers are better able to envision the impact and the suitability of the solution, and whether it addresses their real business problem. While there is no guarantee that your candidate will morph into the final solution, you are presenting the customer with something that appears to be more real than abstract questioning.

10

Generating Sacrificial Candidate Solutions

Sacrificial candidate solutions are there for you to explore your customer’s business problem. They are “sacrificial” as they will most likely be discarded after they have served their purpose of discovering and experimenting within the problem space. You keep the knowledge but throw away the candidate.

They are “candidates” because you generate several of them, and test each to see what effect it would have on the problem space. They are “solutions” because they could potentially act as a solution, but their purpose here is to give you a vehicle for learning more about the business problem.

It is important to have multiple candidates. The usual practice is to look for one right answer; find an answer and then stop. Job done. In fact, we might not even look for the one right answer—we might presume the answer and proceed as if it is the right answer. It might be, but more often, it might not be. There is always the “second right answer.” This was proposed by Roger von Oech (see Resources). Instead of looking for the answer, look for answers. Plural. Instead of digging in and defending the first answer, think about rephrasing the question, think about using the Creative Triggers (coming up soon) and looking for the second (and third and fourth) right answers, which will probably—almost certainly—be a better solution.

Generating multiple sacrificial candidates means that you and your stakeholders have to think more, but you also have to look at the problem differently. Instead of one solution, you have a choice of solutions to pursue.

Multiple Candidates

The idea behind generating multiple candidates is that a single candidate is simply not enough to open your mind to all the possibilities. If you only have one candidate, then it is probably the presumed solution, and you have not thought enough about the problem. With only one candidate you are denying your customer (and yourself) the opportunity to explore the business problem. It is, after all, this exploration that reveals the real problem and uncovers the requirements that otherwise would have remained hidden.

“ If you want to have a good idea, have lots of ideas. ”

—Linus Pauling

Consider the candidates shown in Figure 10.1. The business problem here is that college students must acquire the textbooks that are required reading for their courses. The diagram presents five alternative candidate solutions. They range from the simple and obvious of buying the book at a store, through using an Espresso Book Machine to print the book in the store. The point of having five (and sometimes more) candidates is that you and your stakeholders probe each of them to look for viability and whether they are solving the right problem and producing the right outcome for the customer. Importantly, have you and the stakeholders understood the problem?

Figure 10.1

Consider the five candidates that were generated for the same business problem. The business is students getting their required textbooks.

The idea is to have ideas because ideas can morph into other ideas. Candidates, once seen and examined, can be changed to become something else. A good example of this is the iPhone. The iPhone is a product that was so good, and in 2007 (the time of its release) so extraordinary, that it sold so well that within a year all the major electronics companies were pushing out their own iPhone copies. Yet the iPhone didn’t start out as a phone. It began as a project to develop a tablet (much later to become the iPad), and it was after some of the Apple designers talked about how they hated their clunky, keypad-driven phones of the time that the idea came to combine a phone with the touchpad technology of the tablet. The rest is history.

“ If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. ”

—Steve Jobs

When you are prototyping, you are generally working closely with your customer. If you find that the customer is not asking lots of questions and coming up with requirements, it could be a sign that he doesn’t recognize how your prototypes are part of his world. If this is happening to you, rework the prototype with enough characteristics that your customer recognizes it. These characteristics could be specific technology, names of people, places, jobs, existing systems … anything that the customer relates to. This often kick-starts the communication, and the customer now recognizes that this is real; it is his problem you are talking about.

Just as prototypes and ideas can change, the problem you are looking at might change as well. When your customer sees a candidate, she says, “What is the problem that this solution is solving? It is not exactly my problem.”

In Chapter 14, Probing and Exploring the Candidates, we discuss how you probe your candidates to find their suitability and applicability. This probing looks at such things as the impact of the candidate solution, whether it is feasible, whether it solves the right problem, and so on. But to have meaningful probes, there must be several candidates. When there is only one candidate and the probe reveals flaws, you become locked into improving it instead of using it as a springboard to find new and better ideas.

Don’t Be Pygmalion

Pygmalion was a character in Greek mythology. The legend tells how Pygmalion, a sculptor, made an ivory statue that represented his ideal of womanhood. The statue was so beautiful and so perfect that Pygmalion fell in love with it. We tell the story here to say that it is important not to become so enamored with your prototypes that you block out any criticism of them. A candidate is there for you to explore ideas, not to fall in love with.

By the way, Pygmalion’s story has a happy ending. At the altar of Aphrodite, Pygmalion wished for a bride who was “the living likeness of my ivory girl.” When he returned home and kissed the statue, he found that she was now a living woman and that she was, happily, in love with Pygmalion. They married and had one or two children (the myths are none too clear on this point). However, you don’t have the goddess Aphrodite looking out for you. So please don’t fall in love with your prototypes. They won’t come to life.

It is important that you see your candidates as sacrificial. Think of yourself as another character from Greek mythology, Medea. Medea marries Jason of Golden Fleece fame, and later kills their children. Your candidates are only as long as they help you and your customer explore the business problem and see how different solutions can have different outcomes. Naturally enough, you are searching for the outcome that is most beneficial for your customer.

“ Daring ideas are like chessmen moved forward. They may be beaten, but they may start a winning game. ”

—Johann Wolfgang von Goethe

Time Flies, But You Are the Pilot

Prototyping is not meant to be eternal. Obviously, coming up with new sketched prototypes takes time, and time is a finite and valuable resource. Timeboxing the prototyping activity is one possibility, but we like to think that the team will know when they have exhausted the possibilities. If a day or two go by with no new candidates emerging, then it is probably time to concede that there are no more. Don’t be in too much of a hurry to pull the plug on the prototyping activity, but don’t let it go on once it has ceased being useful.

Review

The idea is quite straightforward: Generate multiple—three or four or five or more, if you like—candidate solutions for your customer’s business problem. The idea is less to find a solution than to explore the problem. You are exploring by testing each of the candidates against the problem to see what you and your customer learn. You could of course just ask questions about the problem, but your customer might answer according to his own idea of a solution to the problem. By presenting and probing each candidate solution, you are inviting the customer to think beyond his own presumed solution and see a bigger and better picture.

It is possible that one of your candidates goes on to be further refined and eventually turn into the delivered solution, but for the moment, we are concerned with rapidly exploring the problem space and learning as much as we can about it. For it is only by understanding the real problem that you can come up with the right solution.

Resources

Thinkertoys: A Handbook of Creative-Thinking Techniques by Michael Michalko (Ten Speed Press, 2006). This book presents creative-thinking techniques for approaching problems in unconventional ways. On the entertainment side, it has dozens of useful hints, tricks, tips, tales, and puzzles.

Be a Great Problem Solver—Now! by Adrian Reed (Pearson, 2016). This looks at generating a range of possible solutions for business problems. The author also explains the trap of selecting the first solution that comes along, and looking for long-lasting answers.

A Whack on the Side of the Head: How You Can Be More Creative by Roger von Oech (Grand Central Publishing, 2008). One of the original books on how to have good ideas.

Prototyping: A Practitioner’s Guide by Todd Zaki Warfel (Rosenfeld Media, 2009). This looks at techniques for prototyping and has a review of many tools used for prototyping.

TED Talks (https://www.ted.com). There are many talks on creativity and innovation.

11

Prototypes, Prototypes, Prototypes

Let’s start by reiterating that we are talking about sacrificial prototypes, and they are being used for the moment as aids to discover and explore the problem and its requirements. The effort you put into these prototypes is mainly done by your brain, not your hands.

There is no point in building elaborate prototypes. These are sacrificial; you’re going to throw them away once they have done their job. We are talking about sketched prototypes. Build no more than you need to get your idea across and to allow your customer to see what you’re getting at and assess whether it is solving the correct problem.

Some of the prototypes you sketch might later be developed into the final product, but only once you and your customer are certain that it is satisfying the real business requirements. For the moment, keep thinking of sacrificial candidates.

“ Prototypes are requirements bait. ”

—Steve McMenamin, CIO, Hawaiian Electric

This chapter gives an overview of some of the types of prototypes available to you. We have no way of knowing which of them will appeal to your customers, and for the moment, neither do you. So try them, and find the ones that your customers relate to and that you feel happiest with. You are trying to find and use prototypes that conform in some way to the artifacts and experiences that are most familiar to the customers. They will respond more appropriately when there is some visual representation that they can criticize and change and discuss and argue about.

One more thing: In Part II, Project Blastoff, we spoke about business events, and how these events are the drivers of your customer’s business—your customers will recognize them. The response to each of the events is a stand-alone piece of functionality, and that makes it an ideal candidate for a prototype.

Types of Prototypes

What follows are some prototyping techniques that we and others have found useful. Pick ones you like the look of, and try them. Pick one you have not used before, and try it. Try not to fall back on the same old ones you have been using before—see what you learn by trying one not yet familiar to you.

Give them a prototype they recognize.

Sketches/Low-Fidelity Prototypes/Wireframes

Drawing is 73,000 years old, and you would think that after all that time we would be good at it. With a few exceptions, we’re not. But the good news is that we don’t have to be good, just expressive. Drawing—or as we prefer, sketching—is nothing more than putting together a picture of your candidate prototype. It does not have to be great art; in fact, it should not be. There is value in having rough, unfinished diagrams: Your customers are more likely to make suggestions and ask for changes. That is exactly what you want. If your drawing is too polished, then it conveys the message that it is the design of something, that it is finished and cannot be changed. It’s not finished, and it definitively can be changed. It’s a rough sketch that invites change. These rough sketches are often referred to as lo-fi prototypes or wireframes.

In order to explore a business problem, you are sketching a picture of a proposed solution. So your sketch should show as much of the business as is needed to understand that problem. Don’t restrict yourself to just a screen; show the wider ecosystem. The objective is to ensure that you are solving the right business problem: The more you show of the business, the better the chances of seeing the right problem. The sketch shown in Figure 11.1 illustrates this idea.

Figure 11.1

The sketch of a candidate solution to assist with customs inspections of goods-carrying trucks at international borders

The sketch shown in Figure 11.1 illustrates the prototyping approach to requirements discovery. The sketch is about trucks carrying goods across international (and sometimes state) borders. The customs officials of the arrival country need to be satisfied that the goods are allowed into the country, that any applicable duty and taxes are paid, and that the goods are manufactured to be compatible with national standards. There are typically delays for trucks at borders, as the process of checking the truck’s cargo manifest is cumbersome and slow. The intention is to reduce or eliminate the time taken and still retain the integrity of the customs checks.

Note that the sketch has a wider scope than just the software product on the customs officer’s computer. The scanner is located several miles short of the border. This is to give the officers time to review the truck’s manifest when it is transmitted ahead. Depending on their findings, they will either wave the truck through—they already have all the necessary documentation—or decide to stop the truck for further checks. Perhaps they need to open the truck to inspect the cargo.

All of the above would be explained when the analysts and the customers get together to discuss this candidate solution. They probe the candidate looking for good requirements, for places where the proposition would not work, and for places where it fails to address the complete business problem.

For example, consider the electronic cargo manifests carried by the trucks.

● How can they be standardized in places like Europe where there are several dozen countries sending trucks to other countries, not all of them within the European Union?

● How can all the manifests be made to communicate with this country’s scanners?

● What happens if the manifest is not scanned?

● How do the officers at the border post recognize which trucks are allowed to proceed and which are to be stopped?

● Does the manifest have to be in the truck? If it is electronic, could it be transmitted from the shipper’s office ahead of the truck starting its journey?

● Is the manifest “always on”? That is, can the scanner automatically detect it without any action by the driver?

● What about fraudulent or erroneous manifests?

We’ll stop there. It seems that the business analysts have more work to do. However, it does appear that this candidate solution is exposing more of the actual business problem. So, the sketch has served its purpose so far. You would go on to build more complete and detailed models as your knowledge about this piece of the business grows.

The above example is not a particularly complicated candidate solution—it is more likely that your sketches will, of necessity, be more elaborate. But this example serves to illustrate the possibilities provided by sketching.

You could also sketch a wireframe of the customs officer’s screen such as shown in Figure 11.2.

Figure 11.2

A wireframe of a candidate solution to the customs business. This wireframe demonstrates to the stakeholders the kind of data that is associated with the candidate.

A wireframe, in IT usage of the term, is a very quick mockup of a screen. A wireframe is intended to show the functionality of the solution and should not go into details of screen design. That comes later—while you are exploring the problem, you must dissuade your customers from getting into it. Your wireframe is intended only to demonstrate to your customer how she could work with the candidate.

Go through the wireframe with the customer. For the one shown in Figure 11.2, you would look at the information and verify whether this is feasible. For example, the wireframe shows the truck’s license plate and a silhouette of the kind of vehicle. Is this enough for a customs officer to recognize and stop the truck? Should the solution be expanded to include an automatic license plate reader and lower a barrier to stop the truck? Is the manifest detailed enough? If not, what information is needed, and how would that be acquired?

A wireframe like this raises lots of questions, which is exactly the point of having it.

Before we leave sketching and wireframes, we should mention that we love the spontaneity of sketching on physical whiteboards and paper with the customers around the table. However, there are some terrific collaborative automated drawing tools available. If you work remotely or are a member of a distributed team, you spend a lot of your work time electronically. Having easy-to-use collaborative whiteboards, wireframe builders, and design tools helps your analysis of the business a lot.

Storyboards

Storyboards are borrowed from the movies. Before shooting a movie, the director gets together with a storyboard artist. Using the script, the director decides how each scene is to be shot. This is drawn by the artist and shows where the actors are in relation to the camera, what dialog is to be spoken for that scene, and what directions are to be given to the actors. At the end of the exercise, the storyboard shows the complete movie, scene by scene. It becomes the shooting script, or plan for the movie.

You probably don’t have anything as glamorous as movie actors and elaborate sets in your workplace. However, just as the movie storyboard shows the activity of the movie, your prototype storyboard shows the activity of your candidate solution.

Let’s say that your client wants to enhance the home security solutions that her company sells. You have been given a vague description of the problem: She “would like to automate more of it.” Of course, you could leap in and automate all sorts of things, but it is wise to find out what part of the solutions she is thinking about. The candidate solution shown as a storyboard in Figure 11.3 is intended to give your otherwise vague client something to start the conversation with. By showing your client this storyboard, you are first trying to identify the scope of the problem.

Figure 11.3

This storyboard demonstrates the functionality for a candidate home security solution. The text under each panel describes the action for that phase of the candidate.

You walk the client through the story, and then start to pick it apart. She likes the first two panels. This indicates that this is part of the business problem. Then you get to the third panel, and she becomes hesitant. Food is not part of the security problem as she sees it. So, you cross out the third panel and the part of the fourth one that talks about cooking.

What you have learned is part of the scope of the business problem, and where your investigation should concentrate. For example, the second panel mentions a “random lights program.” For this to be convincing, it should not be random at all, but should mimic the normal pattern of lights for the household. You can dig into this after the walkthrough.

This is a security solution, so the fourth panel might raise some concerns. If it senses the car and unlocks everything, could that be misused? For example, could another car with the same security product drive by the house and unintentionally unlock it? How can the client sell this to customers who don’t keep their car in the garage?

There is more to explore, and the point of the storyboard—indeed, any prototype—is to be a vehicle to help you and your customer explore the business problem.

The role of the storyboard is to illustrate the functionality of a candidate solution in a recognizable way, and to invite questions and criticism. You get together with the appropriate customers, walk them through the story, and probe the candidate until you have agreed either that it is not viable because it is solving the wrong problem, or that it is a potentially workable solution solving the right business problem and worthy of further investigation.

You can enhance the commentary part of the storyboard if you wish to include more information about the action taking place for each scene. For instance, you might include a rationale for the action, or any notes of open questions attached to the scene.

You can also find storyboarding software to help you build your boards; these would be useful if you are part of a remote or distributed team. And when you have a quiet moment, check out some of the examples of movie storyboards on the Web. After that, you might then be tempted to add a superhero to your own storyboards, but only if they are smart enough to understand the real business problem.

Mind Maps

A mind map is a combination of drawing and text that mimics the way your brain stores information. It does this by using links between the words and pictures to represent the synaptic connections our brains use.

As an example, let’s look at a mind map that our friend, Joanna Kenneally, drew when she was planning her business. The business provides advice and recipes for people who dine alone at home. This market segment usually does not have well-stocked larders and fridges, and sometimes they find it hard to buy food in quantities suitable for one person. Additionally, they might not be good cooks. Our friend’s business, Good Food for One, provides recipes and advice on cooking when one is on one’s own. Joanna’s mind map is shown in Figure 11.4.

Figure 11.4

A mind map drawn while planning the business Good Food for One. This Web-based business provides recipes, shopping advice, and cooking tips for people who cook and eat alone. Mind map by Joanna Kenneally. Used by permission.

Note the quick sketches and the hastily scribbled words in Figure 11.4. Joanna was in a hurry. She wanted to start her business right away and needed a quick prototype of what it would do. She wanted to record all her ideas and see if they came together to form a viable business. This mind map is not all that legible—she was drawing it for herself, not you. And that will be true for many of your mind maps.

Mind maps are useful devices for organizing your thoughts and gathering those of your customer. You can see the result of your thinking in one diagram—you get an overview and details at the same time—with each of your subtopics teased out to show divergence and connections. Drawing small pictures on your mind map helps; they obviate the need to have words and have the advantage of being more easily remembered than words.

The mind map provides enough information—shown as keywords and links between those keywords—for your customer to get the overall picture. The value here is that it becomes easier to see if things have been missed, if there is sufficient functionality displayed to make a useful solution, and if the parts will come together as a coherent whole solution. You might find it more useful to draw your mind maps in collaboration with the customer and other stakeholders.

Process Models

Process models have been around for a long time in one form or another. However, their antiquity does not diminish their usefulness. There are several competing notations for process models; the most commonly used notations are Unified Modeling Language (UML) and Business Process Modeling and Notation (BPMN). However, when using them as a prototyping tool, we suggest you ignore their finer points and elaborate notation and focus on drawing models that communicate clearly with your customers.

You can build a model in isolation and afterward show it to the customers for their confirmation, but you’ll get a better result by sketching your process model in their company.

Keep in mind that you are sketching a candidate solution. Note the word “candidate.” When you are sketching your process model you have no real idea whether the candidate will make it through to further development.

So, what is a process model? A process model demonstrates a business process. Business processes are usually made up of activities arranged in a sequence of some kind. Business process models use various notations to mirror the flow of these activities, but a rectangle representing an activity is the most commonly used, with arrows to show the sequence of activities.

The candidate solution shown in Figure 11.5 is a proposal for a forum for people to give away things that are still usable but no longer needed—furniture, outgrown children’s toys, games, clothing, books, and so on. While establishing a central point for the exchange of no-longer-needed stuff is thought to be a good idea, it needs to be tested. This model will be discussed by the main stakeholders of the organization, and then further experimented with to ensure that it is a viable solution to the real business problem. Having the candidate solution in a visual form, in this case a process model, gives participants a more accessible way to see and discuss its ideas.

Figure 11.5

A process model of a candidate solution. Begin at the starting circle and read the sequence of activities until you reach the end circle. The notation is simple enough for almost all stakeholders to immediately grasp the meaning of the diagram.

You will find that process models can be gainfully used later in the development cycle when you are designing how the pieces of your solutions fit together. They can also be used when Trawling for Requirements, which is coming up in Part IV. We have a lot more to say about process models there.

Scenarios

A scenario is pretty much a process model without the pictures. We are using the term “scenario” to describe a series of steps that together achieve some business objective. You can use a scenario as a prototyping tool, and simply describe each step of your candidate solution. You would do this when either you don’t like drawing or your client prefers text to pictures. Take this example of a prototype process for managing a company’s fleet of vehicles:

Record all purchased vehicles into the fleet database.

Categorize the new vehicles as cars, vans, and trucks according to the company guidelines.

For all trucks, allocate to heavy goods yards in proportion to managers’ requests.

Attach the appropriate classes of driver’s license to each truck vehicle record.

Allocate vans to warehouses proportionally to managers’ requests and projected demands.

Reserve 10% of the cars to be carpool cars.

Allocate cars to employees considering company, rank, and date of request.

Check the employees’ driver’s licenses and notify them of their allocation.

You would use this scenario to walk your stakeholders through your prototype. For each step, you ask if this is solving their problem. For example, step 4 talks about the appropriate license required for each category of truck. Are there exceptions to this? Do the company’s records of drivers carry an indication of the licenses? Is this step solving a problem that needs to be solved? These questions (and others) about the scenario help you and your stakeholders discover and explore the real business problem.

Scenarios have the advantage that they are immediately recognizable to your customer, so walkthroughs and probes do not have to overcome any notational issues. They are also easy to change, so you and your customer can make updates on the fly as you explore your candidate and whip it into shape.

Scenarios can also be useful later in the development cycle. We’ll talk later about story maps, and you’ll see how the scenario lends itself to being readily converted to stories.

Slogans and Elevator Pitches

● “The ticket you don’t have to buy”

● “Let the customers approve their own loans”

● “Renew without renewing”

● “Sign up in 60 seconds”

● “Banking with inbuilt budgeting”

● “Fleet management for dummies”

The list could go on, but you get the idea. The idea of the slogan touting the benefit was best demonstrated with Apple’s iPod slogan, “1,000 songs in your pocket.” This was of course aimed at potential customers for the iPod, but consider its value as a description of a product that you must develop. It’s all there; all you must do is come up with a device that is small enough to carry around and can store music (and presumably play it to the person carrying the device).

A slogan doesn’t pretend to be a complete description, but as we are dealing with candidate solutions, why not try using a slogan to tout one of your candidates?

The elevator pitch is so named as it is a short description of the candidate, short enough that you can tell it to someone while traveling in an elevator. Elevator pitches are two or three sentences long and should be made up of a short statement of the problem, followed by a short statement of how your candidate would solve the problem. For example:

“Did you know that most employees spend about five hours per day on their email, and on average, only 46% of them manage to clear their inbox each day? Our proposal is to have an automated solution to observe people’s email behavior over time, to see which messages they treat as important and which they consider unimportant. As the solution learns the value that an employee puts on each type of message and each sender, it begins to sequence the employee’s inbox in value order. It continues to observe and improve.”

The value of an elevator pitch is that you can write one in a few minutes.

Cardboard Boxes

The next time you buy an appliance and it comes in a large cardboard box, don’t recycle the box; keep it. Cut a rectangular hole on one side to represent a computer screen or a phone and have one of the business analysts get inside the box. The analyst plays at being the candidate solution and responds to verbal directions given by the customer. The customer is playing through a typical transaction or work scenario.

The rest of the team watches this interaction and notes any gaps in the conversation, whether the analyst’s script fails to cater to the customer’s needs, or whether there are some missing pieces.

Cardboard box prototyping is highly playful and relatively fast. You and your team decide the proposed functionality that the cardboard box possesses. This is told to the analyst inside the box who plays at being the software. You cue the customer to attempt some piece of work by saying something like “The cardboard box is your new system. Use it to try and do the things you need to do to manage the fleet and transfer licenses in and out.”

Techniques like cardboard box prototyping might seem to have a degree of silliness about them. That is not a bad thing—people who play enjoy themselves and are frequently more productive.

Fun helps people to relax, enjoy themselves, and be more productive.

Videos or Video Walk-throughs

There is no doubt about the attraction of video. Humans are visual beings—we are attracted to images, both still and moving. We spend a lot of our time watching some form of video; many people say they learn more easily by watching videos. The popularity of YouTube as a learning resource attests to this.

Since we like learning by watching videos, it stands to reason that presenting a candidate solution to your customer can be done using a video presentation.

The simplest form of this is having someone hold your phone and film you explaining your solution. Of course, it can be more elaborate. There is quite a lot of animation software available that can be used to make convincing demonstrations of your candidate. Alternatively, you can use screen or voice recordings to make your prototype.

However, you must think of video as a presentation tool. That is, once you’ve made your video, it is a fixed entity with very little ability to be changed on the fly.

Hi-Fi Prototypes

High-fidelity prototypes are built using software tools and produce results that have the appearance of working software products. They can either be presentation prototypes, be built using content management systems, or be more functional and built using whatever programming language(s) your organization uses. They are attempting to be a partial version of a potential product.

The hi-fi prototype (we call it “hi-fi” because it is high fidelity and faithful to the look of the finished product) looks real and appears to be a working product. There is a downside, however. Stakeholders might be tempted to concentrate on its appearance and possibly forgo making functional improvements. To do so would defeat the purpose of requirements prototyping.

Putting aside the slight risk of stakeholders misunderstanding their role in the prototyping activity, the hi-fi prototype has a lot to offer. It is interactive, which encourages users to explore its capabilities. The icons and data displayed on the screen are representative of the data and icons used to do the actual work. The stakeholders should feel at home with the prototype: They should be able to click around, update data, and be told whenever they make an error. In other words, the prototype can be a realistic simulation of their real work. An example of a hi-fi prototype is shown in Figure 11.6.

Figure 11.6

Hi-fi prototypes look like the real thing and are often built with content management systems. They provide very realistic prototypes, and customers usually have no trouble experimenting with them.

However, always keep in mind that the purpose of a requirements prototype is to explore the problem. When your customers are clicking around, exploring the candidate solution, you are constantly questioning them about the problem this solution is meant to solve.

Review

The types of prototypes you can build are limited only by your imagination, as are the candidate solutions you are proposing. Keep in mind that the purpose of these prototypes is to explore the problem space and the solution space. To that end, you must regard your prototypes as sacrificial. Quick sketches are easy to throw away—you have not invested time and effort (apart from thinking effort) into them. Elaborate prototypes are harder to discard and there is a tendency to defend them from criticism and changes. So, make them quickly, and change or discard them quickly.

Of course, some of your prototypes might go on to be developed into the solution you deliver to your customer, but for the moment they are exploratory vehicles.

Used wisely, prototypes have a significant role to play in your requirements discovery.

Resources

Prototyping for Designers: Developing the Best Digital and Physical Products by Kathryn McElroy (O’Reilly, 2017). The author explains the goals and methodologies from quick-and-dirty sketches to high-fidelity prototypes.

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures by Dan Roam (Portfolio, 2013). This is one of the early books on using sketched picture prototypes to discover and develop new ideas. The author also looks at how to share your insights with your stakeholders. Check his website, https://www.danroam.com, for further resources. He has other books and training courses.

Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle by Ian Alexander and Neil Maiden (Wiley, 2004). The authors explain how to use scenarios, and present a range of scenario techniques from sketchy to systematic. There are also various IT-related case studies.

Mind Map Mastery by Tony Buzan (Watkins Publishing, 2018). The author originated mind maps five decades ago, and since then this thinking tool has spread worldwide. Mind maps are great for quick prototypes.

The creative design company IDEO provides on its website (https://www.ideo.com/search?query=prototypes) prototype examples of the many different kinds of prototypes it has used.

12

Ready-Made Solutions

Most development efforts include some ready-made solutions. Whether your development intends to deliver a consumer product, a service, or software, some—perhaps almost all—of it will be bought and not built. You might prefer to call this an off-the-shelf (OTS) solution, and it does not matter whether you are buying it (commercial off-the-shelf or COTS), you are getting it free as open-source software, you are subscribing to a cloud computing service or software was a service (SAAS), or it is a legacy solution. Because it exists already, let’s just call it “ready-made.”

In this part of the book, we are discussing prototypes and how they are involved in exploring the problem space and discovering requirements. To satisfy these requirements, you intend to build something or to buy something, often a combination of both. The prototypes you build of candidate solutions must therefore include and demonstrate any potential ready-made components.

When the whole of the solution is intended to be ready-made, your prototypes are used to explore its outputs and outcomes. Before you get something off the shelf, you need to know that it works and satisfies the business problem—just the same as if you built it yourself.

A ready-made solution is only useful if it fits within your customer’s business activities. The intention of the prototypes we are discussing here is to explore how a ready-made would help solve the customer’s business problem.

Most ready-mades require configuring or customizing. The prototypes you are experimenting with here help to discover the requirements for this customization, and any other requirements for integrating it into the customer’s business environment. In some cases, your prototypes might demonstrate the effectiveness of changing the customer’s business area to accommodate the ready-made.

Prototyping with Ready-Made Solutions

In previous discussions about prototypes, we made no mention of whether the functionality of the prototype would be built or bought. So, now let’s look specifically at prototypes in which the intention is not to build, but to acquire ready-made components for some or all of the solution. These prototypes differ from those discussed previously in only one aspect: The ready-made is treated as a black-box piece of functionality that sits somewhere in the sketch. The intention is to show how a business solution would operate using a ready-made to do some or most of the work.

The roles of these prototypes is severalfold.

● The prototype is used to determine the suitability of a ready-made solution. Does it fit into the customer’s business, and will it deliver the results needed for that business?

● The prototype demonstrates the result, given each of the proposed configurations of the ready-made solution. In other words, you are modeling outcomes and testing them against the customer’s expectations and real business needs.

● Prototypes can also be used to assess the suitability of ready-made solutions in various combinations and configurations.

● When assessing suitability, you would also assess how much configuration or customization is viable, necessary, and economic.

● The prototypes are used to assess the feasibility of changing the business process to fit the ready-made solution.

● Your prototypes are part of the input to the acquisition process and might be used to help formulate your Request for Proposal (RFP).

Let’s look at these.

Suitability

Look at the prototype of a business process shown in Figure 12.1. The ready-made solution is shown as a cardboard box representing an “out-of-the-box” solution. This one is in the middle of the process and is being assessed for suitability. Note the data in and data out components on the model. These are there to help you assess whether the input data can be manufactured by the activity on the left, and importantly, whether the output data from the ready-made is suitable for the remainder of the activities in this business process.

Figure 12.1

The diagram is a prototype showing a business process. The first process in the chain is intended to be custom-built. The cardboard box icon is used to represent the ready-made or “out of the box” solution. The process continues with another custom-built component, followed by a manual activity, before the process reaches its conclusion.

In this case, you assume that the ready-made solution is some component that is available on the market, or as an open-source product. It can also be a piece of legacy software that the organization already owns. Whichever it is, you are testing the prototype for its suitability. Suitability is determined by whether the ready-made solution can transform the input data to the desired output data. It doesn’t matter how it does it, as long as the result is correct.

You could also use this prototype as a model of the desired future business. In this case, the prototype shows a business process that the team knows they can put together, providing they can acquire a ready-made solution that meets their data requirements. In this way, the prototype helps you to discover the requirements for the ready-made.

Figure 12.1 shows a prototype of a situation where two processes (the ones on either side of the ready-made) must be built to accommodate the ready-made. In this case, the functionality of the ready-made is such that it appears worthwhile to adapt the business to fit it instead of the other way round. Subsequent exploration and probing will reveal the feasibility of this approach. Keep in mind when doing this that the prototype, including its ready-made, is a candidate solution. There might be other, better candidates.

Impact

Systems thinking helps you to assess the impact that any activity has on connected activities. A simple example: I have a payment activity and decide to change it to stop accepting credit and debit cards. This alteration has an impact on the buying activity; customers now must pay cash. This in turn would impact the browsing activity: A lot of customers would not shop with me, because they cannot pay using a card.

“ Systems thinking is not worrying about the first or second consequence of an action, but the third, fourth and fifth. ”

—Steve McMenamin, personal communication

Figure 12.2 is a prototype model of a ready-made component that has been inserted into an existing business system, probably to replace an aging legacy system. The aim of the prototype is to illustrate the impact of the ready-made.

Figure 12.2

A ready-made solution is plugged into an existing business. The diagram uses shading to illustrate activities that are impacted by the ready-made.

The ready-made becomes part of six business use cases, shown as BUC1, BUC2, and so on. The shading shows the extent of the negative impact on each of the BUCs. Negative impact means that you must configure or customize the ready-made, or rebuild the connected activity to accommodate the ready-made.

Let’s start with BUC1. This BUC is fine as it is; the lack of shading signifies that you have determined that there is no negative impact caused by the ready-made.

BUC2 has a problem. There is some impact (shown by the shading) that requires some modifying action. This could be to modify the activity or to modify the ready-made (the diagram does not show which).

The required modification might be a simple configuration. Configuration is when the ready-made includes the ability for the customer to use parameters. These might change the appearance of forms or reports, or change the terminology, screen layouts, simpler parts of the functionality, and so on. The ability to be configured is usually built into ready-made solutions, is quite straightforward, and mostly can be done quite quickly.

Customization requires more effort. It means your developers have to reprogram part of the ready-made’s code. This is done only when configuration cannot produce the required functionality. The problem with customizing is that some modifications can take the ready-made out of the upgrade path. That is, for each new release you must re-add your customization modifications.

BUC3 is also problematic. The shading on the activity closest to the ready-made indicates that there is a need for some kind of change with either the activity or the ready-made. If the change must be made to the activity, and it is a manual activity, then the person or people who do that activity need to have their work description altered. If the activity is automated, then it must be reprogrammed. Alternatively, it might be the ready-made that needs to be configured or customized.

BUC3 also communicates with the outside world. Let’s say that the arrow connecting the ready-made to the adjacent system is some kind of data flow—an invoice, a report, a tax return, or something else. The shading in the adjacent system indicates that there is some negative impact—the data in the flow is not what the adjacent system is expecting. The consequence of this impact is that either the ready-made is modified to produce the data flow that is required by the adjacent system, or you have to negotiate with the adjacent system to get it to accommodate the data in the form in which the ready-made produces it.

BUC4 shows a different kind of problem. There is an impact on the activity adjacent to the ready-made, and this impact has an impact on the next activity in the flow. This is the “ripple effect.” It is so called because one activity can impact another, and another, and the impact travels like ripples on the water and can reach quite distant activities. This is where systems thinking comes in—the art of looking at all the components of a system to see how any one of them can affect any of the others. Sometimes, because of the ripple effect, an activity is impacted by a ready-made even though it is several activities away from the ready-made.

Your task is to assess what is needed to correct the situation shown in BUC4 and make that part of your assessment of the suitability and viability of the ready-made.

BUC5 shows no impact, and thus the ready-made is suitable straight out of the box. BUC6 shows some negative impact to both the activity and the adjacent system that supplies data to the activity. Again, you assess what needs to be done to make the ready-made acceptable to the organization, or whether the situation is so critical that the ready-made is not suitable to become part of the business system.

The purpose of this kind of prototype is to assess the impact. For a situation such as the one shown in Figure 12.2, you evaluate whether the advantage of the ready-made is sufficient to justify the needed modifications. The modifications can be adjustments to manual activities or automated activities, configuration or customization of the ready-made, or negotiations with the adjacent systems.

You would also build prototypes of alternative ready-mades—there are always several to choose from—and gauge their impact. Most of the time, the ready-made with the least impact is the one to acquire. Here you measure impact by the effort needed to configure or customize, and the downside of having a customized ready-made (you have to re-customize after each upgrade).

This evaluation is best done using business use cases. We spoke about these back in Chapter 7, Business Events. Each of these has a defined starting point (the business event) and a defined ending. The data at either end of the BUC is also defined. Your evaluation is based on the difference between the desired data and the data needed and produced by the ready-made.

Does It Solve the Problem?

We should now turn our attention to whether the ready-made solution solves the business problem. Keep in mind that you are exploring the problem space. You use candidate solutions that include ready-made components to do this. And like any other prototype, it must solve the real business problem.

Figure 12.3 illustrates a prototype in the form of a process model. In the middle of this candidate process you have proposed a ready-made component. The activities on either side of the ready-made can be existing activities, or ones you intend to build. The question now is whether this prototype of a process solves the business problem.

Figure 12.3

A prototype showing a ready-made component as part of a business event

This prototype is about one business event and is triggered by the arrival of the leftmost data flow. You need to add a definition of this flow of data to ensure that the activity can function correctly. Similarly, the data that leaves the activity and enters the ready-made must be whatever the ready-made expects. And so on for all the activities if you are to determine the correctness of their functionality. Having determined that the prototype is functionally correct, you turn to looking at the problem space to see that it is solving the right problem.

Your exploration of the problem space using this prototype would be along these lines.

● Does this prototype solve the real business problem?

● Does it suggest a different problem would be the right one to solve?

● Does the ready-made component included in the prototype change your thinking about the problem to solve?

● Does the ready-made include functionality that suggests a better way of solving the problem?

● Does it have functionality that suggests a different business problem to solve?

● Does the prototype indicate that you should build a different prototype for this problem?

● What else did I learn from the ready-made that helps discover the real problem?

And then of course:

● Does the ready-made produce the correct outcome for this business process?

Let’s say that you have probed the problem using some prototypes that include ready-made components. Let’s also say that you have found that, with a few adjustments, one or more of them work correctly and solve the business problem. Now you can choose one of the available ready-made solutions.

Choosing Ready-Made Solutions

Prototyping can help you to choose your ready-made solutions. Let’s look at how this works.

Figure 12.4 shows a variation on the context diagram. We discussed this diagram when we talked about the Blastoff. For simplicity’s sake, this context diagram shows one ready-made solution. (It could also be a collection of them, but the effect for our purposes here is the same.) In this case, the scope shown in the diagram is the part of the customer’s business that you are studying prior to installing your solution. The ready-made solution can be real or desired. It is real if you know that it exists; it’s on the market or available through open source. It could also be a legacy component. It can be a desired ready-made in that you do not know if such a solution is on the market, but you would like to choose one that has the capabilities that the prototype calls for.

Figure 12.4

The diagram is a prototype of a ready-made solution in your customer’s business. The ready-made is shown as a cardboard box within the scope of the problem space, which is indicated by the large circle.

The prototype indicates the business events by showing the flows of data coming from and going to the outside world. The outside world is portrayed by the adjacent systems, or the squares around the periphery. Earlier (in the Blastoff) we discussed business events and how they involve one or more flows of data connected to an adjacent system.

For example, suppose that you want to subscribe to a service provided by a business such as a movie service, a newsletter, or live news. This business event is Customer wants to subscribe. The business knows this event has taken place because the customer sends a flow of data containing his enrollment details. You show this flow of data on your context diagram.

You know the data content of the flows that are attached to the business events. You know this because they exist in the current incarnation of the business; it has been processing them for some time. If the piece of business is completely new, then you have to learn what data the adjacent systems need to supply or expect to receive. In the case of the subscription, the data would be your personal details, a credit card, your preferences, and so on.

This means the context diagram, its business events and flows of data, are your starting point for assessing the ready-made solution.

The context diagram is your starting point for assessing the ready-made solution.

You make use of the data flows by matching the inputs and outputs to and from the proposed ready-made. You are assessing whether they are suitable in their current form, whether they need to be modified, or whether the ready-made needs to be configured or customized. Alternatively, you might need to build some processes to adjust the data to or from the ready-made. By knowing the data content of the existing flows, you can match them to the flows needed or produced by the ready-made.

When we are talking about “existing,” we recognize that most software development projects are replacing or enhancing some existing pieces of the customer’s business. Usually, your client has been in business for some time, so the existing business processes, for better or worse, can be used as the starting point. Your prototypes should reflect the existing reality.

Naturally enough, you want the ready-made solution to be able to handle all the business events. If it cannot do so, then you need to discover the requirements for processing the uncatered-to business events and assess the cost and inconvenience of either configuring or customizing the ready-made, or building additional software.

In Figure 12.5, you see prototypes of alternative solutions. Solution A uses only ready-made components. This arrangement requires more detailed analysis—you need to determine that all of the interfaces between the ready-made components are, in fact, compatible. This kind of solution would probably require significant configuration or customization to make it functionally workable.

Figure 12.5

Alternative prototypes. Solution A uses only ready-made components. In solution B, the ready-made solution is surrounded by existing or to-be-built activities.

For solution B, other activities surround the ready-made solution. The activities can be existing ones that are to be reused by the new solution, or activities that you intend to build. They can be automated or manual activities. This arrangement gives you the opportunity to study the activity that would surround the ready-made and ensure that it synchronizes with the rest of the business area. Either the business area can be adapted to fit the ready-made or the ready-made can be adapted to fit the business. Most likely, you’ll use a combination of the two.

Prototypes give you a preview of possible solutions using ready-mades. Rather than buy a ready-made and then wonder what to do with it (don’t laugh, it’s happened many times), your prototype gives you the opportunity to explore how well the ready-made fits into the organization and how well it solves the business problem. Moreover, it does that without spending much money.

A Strategy

Most of the ready-made solutions that you are considering are large and complicated (if the problem was small and easy, you would probably build the solution yourself). Rather than assess the whole of the ready-made solution, it’s best to decompose it into manageable chunks, and business events are the most convenient chunks to use.

If you start by building a context diagram as we discussed above, it reveals the business events. Alternatively, you can, in conjunction with your customer, construct a list of business events. Your ready-made supplier should be able to match your list of business events with the transactions carried out by the ready-made.

You probably want to build a table for the next part. We show an example of such a table in Figure 12.6. The table should list all the business events relevant to your problem space. For each event, assess whether the ready-made caters to it, and if so, how closely its input and output match your customer’s existing or desired input and output.

Figure 12.6

A table showing the fit of the business events with the proposed ready-made solution

The idea is to show, event by event, the fit of the ready-made solution against your business needs.

You can be as elaborate as you want. You can show the fit of each business event, whether it matches or needs customization, additional functionality, changes to the business procedures, and so on. The objective of the list is to give you a picture of how well the ready-made solution fits into your customer’s organization, or how much of a gap there is between the ready-made and the organization’s needs.

You might also consider allocating points for fit, deducting points for configuration (which is usually easy), and deducting a greater number of points for customization (which is generally harder). The points would vary according to the cost and inconvenience of the configuration or customization. Certainly, if you are assessing competing ready-mades, a point scoring approach will serve you well.

We shall leave this here. There is more to working with vendors to assess the capabilities of ready-made solutions, but that is getting a little far off the topic of prototyping. However, what you do with your prototypes, the list of business events, and their data inputs, outputs, and outcomes make a valuable contribution to your RFP, a common way to approach vendors. We have more on RFPs later.

Review

Prototyping should be thought of as exploratory modeling. You build prototypes, which are sketches, storyboards, process models, or some other quick-and-dirty model of a candidate solution. You use these to explore the problem space.

When it comes to including ready-made components in your prototype, you are transitioning from a prototype where there are no constraints to one where there is a very real constraint. The ready-made exists, and it is more or less fixed. Its functionality must therefore contribute to solving the business problem. Which in turn means that you must spend some time understanding the functionality of the ready-made before including it in your prototype.

You are building these prototypes to help you understand the business problem and whether the ready-made can help to solve it. Your prototypes model this situation and help you to assess whether the ready-made is a good enough fit or whether it needs customization. Alternatively, your prototype might reveal that the most effective course of action is to change the organization to accommodate the ready-made.

Ready-mades are rarely the dream solution that, right out of the box, is a perfect fit with the organization. Your prototyping efforts provide crucial information, not only on the requirements for the ready-made and their customization, but also on what the organization can expect should it decide to deploy the ready-made.

Resources

Software Requirements, Third Edition, by Karl Wiegers and Joy Beatty (Microsoft Press, 2013). Karl and Joy have some things to say about COTS solutions.

Off-the-Shelf IT Solutions: A Practitioner’s Guide to Selection and Procurement by Martin Tate (BCS, The Chartered Institute for IT, 2015).

“How to select a software vendor using the Request for Information (RFI) and Request for Proposal (RFP) technique,” an article available on the website of UK business management consultant Blackmetric (https://blackmetric.com/downloads).

Bridging the Gap has articles on specifying requirements for COTS or SAAS projects (bit.ly/3QOYMs7).

13

Creative Candidate Solutions

Too many people think that coming up with good ideas and innovative solutions is someone else’s job. It’s not someone else’s; it’s yours. Every business analyst, product owner, developer, product manager, and business stakeholder must consider that innovation is a crucial part of their job. We are not here merely to build things the customer asked for, but to challenge, to provide alternatives, to come up with original ideas that are beyond—and better than—what the customer asked for. After all, if no innovation occurs, then any new solution will be much the same as whatever it replaces.

The business analyst’s task is not to deliver exactly what is asked for, but to find something better.

For example, look at your phone. How many of the apps that you see were the result of someone asking for it, and how many are there because the designers came up with a great idea that proved to be very useful (or entertaining)? And while you’re looking at your phone, consider how many people asked for a flat phone with a touch screen to replace the keypad phones that went before it. Almost nobody, and yet each year, over a billion touch screen phones are sold.

We must innovate; that is beyond questioning. Yet many people do not consider themselves to be innovative or inventive. It’s not true; you can be innovative—but you might need a little help.

In this chapter, we look at a few techniques that can help you to come up with innovative solutions. As we said several times so far when talking about prototypes, you need to come up with multiple candidate solutions. Read on to find out how you can come up with fresh ideas for your candidates.

Creative Triggers

Creative triggers provide inspiration for innovation. Think of the trigger as a guide to an idea—the trigger is not the idea, it’s what to have an idea about. The triggers are there to, well, trigger an idea for you.

The following triggers might sound too general, and perhaps too obvious. They are, but they belong to that category of things that are obvious once they are pointed out.

Participation

People like to participate. The success of social media attests to people’s desire to participate and share their photos and opinions and read what other participants have to say. From a business analyst’s point of view, you should think of customers as people who want to participate in the business. People want to do things for themselves that previously were done for them. Air travel, banking, and shopping are all examples of this.

People like to participate.

Companies such as Amazon encourage customers to participate in their business by writing reviews of products they have bought. On Amazon, you can say anything you want about a product. The company makes no attempt at censorship, except for filtering for profanities and blatant advertising. Other customers read these reviews and often make buying decisions based on what other participants have said. Shoppers tend to trust reviews from their peers more than those from outsiders. This and other kinds of participation involve customers more closely with a business, and thus, they are more likely to be repeat customers.

Monzo, a UK neobank,¹ has a community page. Its customers participate by posting messages about their good experiences or difficulties with the bank. When you read the messages, you get the sense that Monzo’s customers enjoy participating in the community, they enjoy helping each other when there are problems, and they like the sense of belonging. The Monzo app also has many articles on how to manage your money. Clearly, the company has thought about connecting to its customers and encouraging their participation. In a crowded field, Monzo is currently the largest UK neobank.

FOOTNOTE 1

Neobanks are smaller, more nimble banks that operate exclusively online through their smartphone apps and sometimes their websites. They occasionally target a particular market segment or community. They are also known as “fintechs” and “challenger banks.”

For your project, ask the team and the stakeholders: “What can your solution do to provide more customer participation? How can we involve the customer in the work?”

Convenience

People love convenience; what’s more, they are willing to pay for it. We pay much more to buy a mobile phone than to buy a landline one. We do this because it is infinitely more convenient to carry a phone around with us instead of being constrained by a cord connected to the wall. We also hate inconvenience. Studies have reported that up to 97% of consumers say they have backed out of making a purchase because of the inconvenience of the purchasing and/or checkout process.

In several countries, particularly Australia, Mercedes-Benz dealers are located very close to airports. Why? Convenience. People who buy Mercedes cars are especially likely to be affluent people, and especially likely to be people who fly on business. The near-airport dealer provides a convenience: When the car must be serviced, the owner takes it to this conveniently located dealer, and the dealer drives the owner to the terminal to catch her flight. When the owner returns, the dealer picks her up at the terminal with the car fully serviced. The car has been washed, and any clothing left on the back seat has been dry-cleaned.

Figure 13.1

Online shopping is convenient, and is increasing its share of the retail market each year as more and more people turn on to its convenience.

These benefits might at first seem trivial, but put yourself in the position of a Mercedes owner: You are most likely affluent and busy. Anything—and that means anything—that is more convenient is welcome. People value convenience and are willing to pay for it.

But it is not only the busy Mercedes owner who values convenience; the user of your proposed solution also values her convenience just as we all do. Think of the devices and services you own that are there primarily to make your life more convenient. Think of how convenient online shopping is (see Figure 13.1).

Ask what it is that your solution can do to make life more convenient for its user. Think about your favorite consumer products—they are probably your favorites because they are so downright convenient. Or look at the way that successful software products work; the most successful are almost always the ones that are convenient to use and provide the most convenience. Ask what it is that the customer is trying to do. Then ask what your solution can do to make the task easy and convenient for them.

Often, less is better. When people sign up for your service, can you take out any requests for information that are not absolutely essential? Can you find a shorter, more convenient way for people to sign up? As an example, many neobanks ask potential customers to send a video of themselves and their passport in the same take. That is much more convenient than finding a notary to sign an affidavit that the potential customer has correctly identified himself, and then mailing that in.

Are there some steps in your business process that can be reduced or eliminated? Can you remove things from your website that are rarely if ever used? People find uncluttered sites more convenient and gravitate to them. As an example, look at the sparseness—and the success—of Google’s home page.

And then we must pay for things. If your solution requires its customers to make a payment, then the process must be as convenient as possible. That seems obvious, but how many times have you found that paying for something online is anything but convenient? And did you ever go back to that store? Think hard about your own solution’s payment process. Build prototypes of it and reduce it to the bare minimum.

By making your solution as streamlined and convenient as possible, you make life easier for your customers, probably keep them longer, and make your own life easier when your customers don’t need as much support. Best of all, your customers will love your convenient solution.

Connections

We love to be connected. No, let’s be honest here: We are addicted to being connected. The number of users (about one-third of the world) and the amount of time they spend on social media attest to an almost pathological need to tell our friends and followers about our lives and thoughts. People check their phones 150 times per day (this is ten times more than they laugh). Surveys have found that more than half the population consider themselves to be highly addicted to their smartphones. These people leave their phones on 24/7, and often sleep with the phone beside the bed.

Given that your customers—if they are like most of the modern world—are people who value connectedness, it seems sensible to give them as much of it as you can. Your next question must be, “What can my solution do to build a better connection between my organization and its customers?” Alternatively, the question might be, “What can my solution do to build better connections between my customers or users?” See Figure 13.2.

Figure 13.2

The stronger the connections you can establish with the solution’s customers, the better.

Having people participate in the work makes for a stronger connection. Travelers book their own flights and transport, we use an app to have a taxi or car service come and pick us up, we shop online and arrange for the delivery, and even in supermarkets we select our own goods from the shelves (there used to be sales staff to do that for us) and then check ourselves out (there used to be checkout people to do that for us). We participate in lots of business activities and don’t seem to mind doing so.

Putting your business on a smartphone app is connecting to your customer. The traveler who booked her own flight has the boarding pass on her phone. Updates on the flight status, gate number, boarding time, and alerts when it is time to go to the gate all connect the customer more closely to the business. And when she feels connected to an airline, she is more likely to continue flying with that airline.

Being responsive establishes a closer connection. The response your solution makes is its message. Customers measure organizations by the way they respond. For example, the vacuous phone announcement, “All of our agents are currently busy. Your call is important to us, so please stay on the line and we will respond as soon as we can,” damages the connection between the customer and company. Companies that promptly answer the phone, or at least offer to phone back, connect strongly to their customers.

When you are prototyping candidate solutions, check each one for responsiveness. What opportunities does the candidate have to be more responsive to its user, or what can it do to connect more strongly? Remembering the customer’s name, preferences, and previous orders is a way of remaining connected. Can you build in any additional information messages to the user? An example would be keeping people informed on the status of their orders. Or can you offer a better help facility? Does the candidate tell its user what it is doing? Can you find a better way to connect your candidate to its end user? Can your candidate solution make the customer feel ownership of the solution? That is about the strongest connection you can make.

Software support websites are another example of connectedness. Someone with a problem asks a question about their problem, and other people, hopefully experts, offer their advice on how to solve the problem. With a few exceptions, they are not paid to do this; they do it because they enjoy participating and connecting with other people. People who use these support sites usually feel more attached to the software product.

Information

Think about your business customer: He wants information, wants more of it, and wants it without delay. If you don’t believe that, then look at the astonishing success of Google. What is Google’s product? Information. Almost half of the total internet population uses Google each day to find information. The billions of daily hits on Google indicate that our thirst for information is relentless and unquenchable.

This dictum also applies to your customers. They know that many organizations are willing to supply as much information as they want, so you must specify your product in a way that it tells the customer everything he needs or wants to know.

But the product must do more than just pump information at the customer; it has to deliver useful information. Some of this makes your product more convenient—you provide all the information needed to make it easier for the customer to carry out the transaction.

Information enables people to make decisions.

Information enables people to make decisions. Figure 13.3 shows a London bus stop. Public transport is both ubiquitous and heavily used in London. At the time of writing, the London bus fleet is almost 9,000 buses and 19,000 bus stops. Many of the stops are equipped with a sign like this showing in real time the expected arrival of the buses.

Figure 13.3

The electronic readout of expected bus arrival times. The 453 has just left and the 30 to Marble Arch is “due.” You can see it arriving. If you want to get to Sudbury, you have a minute to wait, and if you just missed the 453 to Marylebone, there is another in three minutes.

This kind of information enables passengers to make decisions: Do I wait for the bus? Do I walk to the nearby Tube stop? Do I hail a taxi? The effect of these signs is that passengers at bus stops are much more patient because now they know where their bus is. They don’t become anxious wondering if one will ever come for them, and they don’t spend time looking down the street for their bus. They know when it is arriving.

Now consider the solution you are working on. What information can it provide, and what can you enable its customer to do with that information? Information without enabling action is probably not useful.

Feeling

Systems and products are accepted or rejected based on how the consumer feels about them. This might at first seem to be very subjective, but an awful lot of buying decisions and acceptances are subjective. When you deliver your solution to its customers, they have to feel good about it and feel good about using it; otherwise, there is a strong possibility they will reject it. For example, you must know someone who bought a phone and then realized they didn’t like it and couldn’t wait to get rid of it. Or someone who bought any other kind of product—particularly clothing—and after a while realized that they didn’t feel good about it and dumped it. (This someone might have been you.) Or have you ever, when comparing apps for your computer, selected the one that made you feel good about it?

Making a solution feel good is about making it as usable and convenient as possible. See the situation as your customer sees it. What is he doing when he comes to use your solution? By understanding the viewpoint, the goals and desires of the customer, and taking the trouble to think about the customer, you are in a better position to think about what you can provide to make her feel good about your solution. We don’t mean pleasing colors and catchy music, but actions that are natural and logical and that fit into her world.

Lastly, you must make your user or customer feel that you are being responsive to his needs. That is, your solution must be innovative enough to make your customer feel that you have understood his request and are doing all you can to provide the most appropriate answer. Your response is the strongest message you can send to your customer. Your customers measure you by the way you respond to them—how you answer their questions, how you support them, how you keep them informed about your products and services. Responsiveness makes your customer feel better about your solution.

Speed

Figure 13.4

The door close button in an elevator. This button is often repeatedly pressed in the hope of having the door close more quickly. In many cases, the button is not connected to anything and has no effect. It’s there to make people think they’ll be on their way sooner.

We want things to be fast. Figure 13.4 shows the door close button in an elevator. Why do people press this button? They want the door to close a few seconds before it would automatically close. Why? What are they going to do with those few seconds? We don’t need to save time; we just want the door to close more quickly.

Most drivers exceed the speed limit a few times in their driving day. Why? The speed limit is there to ensure safety, yet people apparently want speed more than safety. We grow impatient if we must wait more than a day for something we bought online to arrive. We click repeatedly if a website does not respond instantaneously. We sigh deeply and roll our eyes if the person ahead of us at the checkout line seems to be taking too long.

Using the speed trigger, you ask what your candidate solution can do to make it be faster or appear faster to its customer. Can you make it faster by cutting out a step or two from the business process? Can you make it appear faster by providing some form of distraction if you know your solution needs time to extract information from distant databases? Can you hold information so that the customer does not have to reenter it? In short, think of anything that makes the solution appear—or be—faster.

What Would Your Grandchildren Do?

This trigger is simple: Imagine the solution that your grandchildren will use. Of course, you cannot see into the future—technology is evolving so quickly that it’s difficult to imagine what you’ll be using in five years’ time, let alone 40 or 50 years.

However, the question is meant not to be answered, but to be asked. It’s there to let you dream up creative solutions without bothering too much about what’s possible. It’s hard to think of a world without, say, electricity. Yet people before the 19th century would have struggled to imagine a world with electricity. But being difficult does not mean that it’s impossible.

The best part of this technique is that it encourages you to make giant mental leaps. We tend to think in evolutionary terms—next year’s phone will be an improvement on this year’s, and the year after that another improvement. Now let’s jump over the next few years; your grandchildren won’t have phones. What will they have? You try to imagine it, and whatever you come up with, let it influence your candidate solution.

Focusing on grandchildren (you could even try great-grandchildren) directs you to think into the unconstrained and unknown future. This is a technique that asks you to avoid thinking about constraints in your current world, and project into some imaginative future world.

Lateral Thinking

Lateral thinking is a problem-solving technique that can also be used to come up with better, more innovative solutions. The term “lateral thinking” was first used by Maltese psychologist Edward de Bono. It involves rejecting traditional step-by-step logic, or “vertical thinking,” and looking at the problem with an unconnected, or lateral, view.

As an example of lateral thinking, answer this question: A person falls out of a 40-story building and survives. How? Vertical thinking will focus on the obvious answers: a parachute, a magic landing pad, Superman plucks him out of the air, and so on. But none of those are the right answer. Lateral thinking means that you ignore the progression of vertical answers given above and approach the problem by questioning all the components and assumptions. In this case, the person survives because he fell out of a ground floor window. Previously you might have assumed that because the building is 40 stories, he went off the top.

A man walks into a bar and asks for a glass of water. The bartender pulls out a gun and points it at the man’s head. The man says, “Thank you,” and walks out. Why? The answer to this will not be found by using any of the components of the problem. What is the answer? Keep reading, it’s at the end of the chapter.

The value of lateral thinking is that it asks you and your team to look for solutions by thinking about the problem completely differently. Ignore all the obvious and predictable solutions, and see the problem “sideways,” or laterally. You will be pleasantly surprised.

Removing Constraints

A constraint is a restriction on the problem space. It is not a physical restraint, like a pair of handcuffs, but some stated or unstated limitation on the project, the design of the solution, or the way in which it must be solved. When you pretend for the moment that the constraint can be removed or significantly altered, you can often uncover a new and better solution. For example:

“What if we had only $1,000 to spend to develop a solution?”

“What could we do if we only had three months to develop a solution?”

“What if we did not have to obey the law?”

“What if we did not have to deliver the parcels?”

“What could we do if … ?”

Not all constraints are real; some are assumptions. People assume that because something has “always been done this way” that it always must be done that way. Challenge this assumption by asking what happens if you remove it. Sometimes the assumption is wrong, and the constraint turns out not to be real. In this case, you can remove it.

Removing constraints as we mean it here is an innovation technique. It’s not that you will remove the constraints (sometimes you do), but imagining the situation if the constraint did not exist often leads to different ways of thinking about the problem. This in turn leads to different, more innovative solutions. See the example in Figure 13.5.

Figure 13.5

Metro systems all over the world probably asked “What if travelers didn’t have to buy a ticket?” which led to ticket barriers accepting debit cards.

For example, suppose there is a constraint that says you must make a profit. Take this constraint and ask, “What if we gave our product away?” This at first might seem counterproductive and pointless, but think about solutions where the product is given away. The most obvious example is Google, which gives away its search facility. The search engine cost Google a considerable amount of money to build and run, but by giving away its search facility, it can attract a huge audience and make an eye-watering profit from advertising to that audience.

Amazon most probably said something along the lines of “What if we didn’t charge people for delivering their goods to them?” which led to Amazon Prime and its free delivery and hundreds of thousands of loyal subscription-paying customers.

Whenever you encounter a constraint, challenge it. Is it a real constraint? And what would happen if you removed it?

Consider the newspaper you read on your tablet device or phone. When newspapers first went online, almost all of them put out a daily edition, just as they had been doing for their print version. Then somebody asked, what happens if we remove the constraint of the daily edition? It means we don’t have to wait until tomorrow to publish a breaking story. Removing this constraint meant that online newspapers could move to the hybrid model where the daily edition is supplemented by, and often replaced by, new stories covering breaking news.

Constraints are all around us and sometimes taken for granted, like obeying the law. You have to look hard to find them, and when you do, ask what happens if you take them away.

Combination

Combination means taking existing components and recombining them in different ways to make something new. Johannes Gutenberg changed the world when he combined the wine press with a coin stamp to make his movable type printing press. Today a phone has been combined with a camera to the joy of the millions of selfie takers. The hybrid car, combining electric and internal combustion engines, is another example of successfully combining two technologies.

Anything you need probably already exists.

The raw materials for combination are the technology, solutions, processes, ideas, and so on that have already been built. There is so much stuff out there that it is safe to say that anything you need already exists. The raw materials should not only be thought of as individual components lying about but could be complete systems or processes. Your team might use only parts of these systems or use them in their entirety. We wrote about ready-made solutions in Chapter 12 and elsewhere. Combining ready-mades with existing solutions often provides an innovative result.

However, the raw material does not always come in a neatly labeled box ready to use. You might have to look at the abstract essence of whatever it is to see how, by changing the subject matter, you can use it as one of your components.

The task here is to take a moment with your team and ask if you really have to build something from scratch, or if you can take some existing components and combine them in a new way to make all, or most, of your new solution.

Review

None of the techniques mentioned above are magical fairy dust that will make you the most inventive person since Thomas Edison. They are, however, triggers that might just give you the inspiration that results in a better solution.

The objective is to come up with several candidate solutions. If one of the techniques makes that easier, then good. If one of them makes you look at the problem differently, then better.

There are of course lots more creativity techniques. The intention in this chapter is to describe some of the most used ones. But it helps to keep on looking for other creativity techniques and ways of thinking that help you to discover new ideas.

The answer to the lateral thinking puzzle of the man walking into the bar and asking for water is that he had hiccups.

Resources

Creative Confidence: Unleashing the Creative Potential Within Us All by Tom Kelley and David Kelley (Crown Currency, 2013). The founders of IDEO explore how creative thinking can be harnessed to create innovative software products.

The Innovator’s Toolkit: 50+ Techniques for Predictable and Sustainable Organic Growth by David Silverstein, Philip Samuel, and Neil DeCarlo (Wiley, 2012). As the title says, these are tools to help you innovate. The book goes on to explain why, when, and how to use them.

The Creative Contrarian: 20 “Wise Fool” Strategies to Boost Creativity and Curb Groupthink by Roger von Oech (Wiley, 2021). The author uses the analogy of the wise fools who were consulted by kings and emperors to find ways of overcoming entrenched and obsolete solutions. This is most appropriate for finding better, more innovative ways of solving the business problem and avoiding the presumed solution.

Lateral Thinking: A Textbook of Creativity by Edward de Bono. This is the classic book on this subject. De Bono shows how to avoid “vertical thinking”—that is, serial problem solving—and come at business problems “laterally.” The results are creative and ingenious solutions.

Design Sparks (https://designsparks.io; from Bayes Business School) is an AI-enabled online tool to help you find more creative solutions. You start with your problem statement, then Design Sparks uses AI and established creative problem-solving techniques to respond with inventive directions. These are curated by CebAI’s design and creativity experts.

14

Probing and Exploring the Candidates

At this stage, you have multiple prototypes of sacrificial candidate solutions. You have multiple candidates because it is important to have a range of alternatives; they facilitate a more thorough exploration of the problem space. Besides, having alternative candidates helps to avoid falling in love with your sole prototype.

The prototypes are candidates—they are proposals generated to explore the problem space, not be a forerunner of something you build. Calling them “candidates” means that you have a number of them, each one trying to solve the problem in a different way. However, until they are proven, each of them remains a hypothesis, and you are probing to prove whether the hypothesis is true.

Candidates are sacrificial. You have built them as a learning experience: If a candidate does not teach you anything, then you discard it. We are probing the candidates, not so much as a test to see if the candidate solution works, but to explore the problem it is proposing to solve.

We often call these “safe-to-fail probes.” We have borrowed the term from Dave Snowden (see Resources), and the implication is that you are not betting everything on any candidate. You have not invested a lot of time building a candidate, so not much is lost if it isn’t useful. It might seem unproductive to generate candidate solutions and then test them to destruction, but if the result is that you solve the right business problem, every hour spent is doubly worthwhile. Having said that, your probing should be done as quickly as possible.

Probing

You are examining multiple candidate solutions to explore the problem space, and hopefully, some of your candidates lead you to more adventurous, alternative problem spaces. The objective is to study the problem by seeing how well, and why, a candidate would solve the problem. Conversely, you learn something when a candidate doesn’t solve the problem. You and your client are exploring the problem space. It’s not unusual to hear something like this: “I don’t know what I need, but I will know it when you show me something that I don’t need.” These candidate solutions are there to help you uncover the real problem.

You are probing to determine whether the candidate does one of the following.

● Reveals nothing new about the business problem.

● Reveals that you are solving the wrong problem.

● Reveals that you are solving a different problem. However, the candidate is innovative and so attractive to your customer that he prefers to change his requirements to fit the candidate.

● Confirms that you are solving the right business problem and the outcome of your candidate is what is desired.

You are also exploring the candidates for their suitability, desirability, and feasibility within the business ecosystem. In addition, you are using the candidates to explore the problem space and ensure that the candidate is addressing the customer’s real business problem.

● Is it solving the right problem, and is it the right problem to solve?

● Ask the customer, “How does this solve your problem?”

● Ask, “Why does it solve your problem?”

● Is the premise of the candidate correct?

● Or was it assumed and is not representative of the real problem?

● Does the candidate solution have the correct functionality?

● Is the outcome of this candidate the desired outcome?

● Is it acceptable to its customers and users?

● What is the impact of this candidate on the surrounding business ecosystem?

● Does this candidate provide real business benefit to the customer?

● Is it economically feasible?

● Is it needed? Does the functionality contribute to the customer’s business? Will it be used?

Let’s look at some of these using the business of Athena’s Wines. The wine business is competitive, and wine buyers have a lot of choice as to where they buy their wine. Athena’s customers appreciate the high-quality wine she sells, and they also appreciate convenience. (See the reference to convenience as a creative trigger in the previous chapter.) Athena has done some research, and one of its findings is that wine customers are very appreciative of fast delivery. Athena sees a business opportunity if she can provide fast and convenient home delivery of her wine.

So, at this stage the business goal looks like this:

Purpose: To provide a fast, convenient home delivery service for Athena’s wines within the city

Advantage: An increase in customer satisfaction with her business

Measurement: Any order can be delivered within four hours, and customer approval is above 85%.

Athena feels that if she introduces a service that her customers appreciate, or become dependent on, she will establish a closer, more permanent link to them. And if her customers like the service, they will tell others. The intangible benefit for this initiative is closely connected customers, leading, she hopes, to tangible benefits of more sales and improved customer retention.

Figure 14.1 is a candidate solution for Athena’s business problem in the form of a storyboard.

Figure 14.1

This storyboard prototype shows a candidate solution for a wine company. Take a quick look at it—we are going to probe it to demonstrate how prototypes are used to explore the problem.

Let’s talk through this candidate to see how it addresses the business problem.

In panel 1, the customer’s order is received in the existing brick-and-mortar shop. Customers like to talk to Athena about the wines they are selecting, so many of them come to the store. They can also order on the phone or through Athena’s website or app.

In panel 2, the order is sent to the warehouse, where it is picked and made ready for dispatch. The order is not immediately dispatched, as panel 3 shows, but waits for two hours to see if other orders come in that can be delivered at the same time.

In panel 4 the time has arrived, and the warehouse staff load the order (or orders) into the autonomous vehicle, which then navigates its way to the delivery address. Once there (panel 5), the vehicle phones the customer to come out and collect his wine (panel 6).

Does the Candidate Solve the Right Problem?

The purpose of this sacrificial candidate is to help you determine if it solves the right problem. So, you now have to question the problem that this candidate purports to solve.

This prototype is about delivery, so the first question to your customer, Athena, is about whether her real problem is the delivery of the wine.

She has said she wants “a service that her customers appreciate, or become dependent on, and that will establish a closer, more permanent link to them.” The autonomous delivery candidate looks cool, but is it the best thing to establish “a closer link to the customers”? Also, is making closer links Athena’s real problem? You use this candidate to question Athena as to whether the outcome of autonomous delivery is the outcome she needs.

For example, is the right problem to solve the one about establishing a relationship with the customers based on convenience and speedy delivery? Or could the right problem be about ensuring that the customers get wines that they like? Should you be proposing a candidate to Athena where she curates individual customers’ selections (perhaps with a little help from AI) so that they always get wines they enjoy, yet have an interesting variation between orders? In other words, customers will come to be assured that everything they buy from Athena fits their tastes.

Or could the right problem be about the range of wine that Athena carries? For example, could you prototype another candidate where customers have access to a huge selection of wines, many of which Athena does not stock? The autonomous delivery vehicles from the earlier prototype could be used to pick up wine from another wine merchant’s stock before delivering it to the customer.

The point of any candidate is to cause you and Athena to carefully consider whether you are attacking the right problem. If it turns out to be the wrong problem, the candidate is still valuable because it has led you in a better direction.

Discard the candidate; keep the knowledge.

Let’s press on with our probing.

Does the Candidate Solution Have the Correct Functionality?

Let’s revisit the autonomous delivery candidate shown in Figure 14.1. The question now is, does it work? That is, does this candidate’s functionality achieve the right outcome?

Panel 1 is fine—Athena’s customers have been ordering from the website for some time. Some of her customers prefer to phone or come in and discuss the wine with Athena. She likes this, as it allows her customers to explore different wines and maintain a personal connection with her business.

Panel 2 is about picking the wine in the warehouse. This relies on the correct information being given to the warehouse staff, so you should satisfy yourself that the output of panel 1 is suitable. Getting the right bottles off the shelves and into cartons can be achieved. The business has been doing that for some time.

So far, so good.

Panel 3 is about waiting for an amount of time. This time delay is proposed to allow other orders to come in so that the vehicle can deliver to multiple addresses during a trip. Keep in mind that Athena operates in a densely populated city. While waiting is very easy to functionally achieve—just do nothing—it might cause other problems. For example, customers will know that this wine merchant has autonomous delivery vehicles and will probably expect to have their wine quite soon after they order. People hate to wait.

On the other hand, some customers might prefer to phone in or tap in their order while they are at work and ask for delivery in the evening. Autonomous vehicles can run all night and there is no need to pay penalty rates to human drivers.

So, we have to say that the functionality as it stands—a two-hour wait—is problematic. Probably the best thing to do is to have some functionality whereby Athena can set the delivery time to take into account her customers’ requested times.

In panel 4, the warehouse staff load the vehicle. This might not work if the delivery is earmarked for the evening and the staff have gone home for the day. Another potential problem with this activity is whether there are enough autonomous vehicles available. This would conflict with the goal of fast and convenient deliveries.

Panel 5 has the vehicle arriving at the destination address and phoning the customer with a message that it is outside and to come and get their wine. What happens if the customer is not at home?

The customer comes out to retrieve their wine in panel 6. Functionally, this is straightforward—get a couple of cartons out of a vehicle and carry them inside. However, one of the questions you ask is whether the solution is acceptable to all customers. For example, elderly or disabled customers might not be able to manage it, and some customers might not be willing to come out into the street and retrieve their wine. We’ll come back a little later to this one.

We also need some functionality to ensure that each customer retrieves his own wine from the autonomous van and not somebody else’s. Additionally, it must stop people from putting anything into the van.

So, with a few corrections, this candidate would be functionally correct.

But that is not enough.

Exploring

Let's look a little into using this prototype to explore the problem and solution.

Is the Outcome of This Candidate the Desired Outcome?

The outcome of this candidate is that an order of wine can be delivered at almost any time of the customer’s choosing, provided they are willing to retrieve it from the autonomous vehicle.

For this you must go back to Athena, the wine business owner.

● Is that the outcome she wants?

● Or have the analysis team presumed that this is a desirable outcome?

● Does this outcome significantly improve her business?

● Will it attract new customers, or at the least, provide a better experience for her existing customers?

● Will the cost of the solution outweigh the benefits, both tangible and intangible?

● What risks are incurred if she were to go ahead with this solution?

In an earlier chapter we wrote about the goals of the project, and discussed how the goal should be measurable. Assessing the outcome of a candidate is measuring how close it comes to fulfilling the project’s goal. The autonomous vehicle service would go some way toward Athena’s goal of fast, convenient delivery.

Earlier we questioned Athena’s goals and proposed some alternatives—curating a customer’s selection and accessing a wide range of wines. If either of these had been determined to be the right goal, then prototypes of these candidate solutions would be questioned in the same way as we are questioning the fast, convenient delivery candidate.

You might find that when you come to explore outcomes as we are doing here, it reveals that the candidate is solving the wrong problem, and that the goal is not what was originally thought.

This candidate does not offer any outcome other than delivery. The ordering and warehousing parts of the solution are already in place, and this candidate does not appear to improve them in any way. Sometimes candidates offer ancillary outcomes, but that does not appear to be the case here.

This is now in the hands of Athena and her goal. Either she wants the outcome of this candidate—fast delivery at most times of the day—or the candidate has missed its mark. Either way, you have learned something about the problem space, and hopefully learned something that triggers a new and different candidate.

Is This Candidate Acceptable to Its Customers and Users?

Part of the delivery candidate is that the end customers must come out and unload the vehicle themselves.

● Will they be happy to do that? If they have settled in for the evening, would they want to come out into the cold to carry in their wine?

● Are they the kinds of people who would find that acceptable?

● Are they people who are able to carry boxes of wine into their homes?

● Would they feel safe unloading a wine-carrying vehicle at night?

● Would they feel that unloading the vehicle is a good trade-off for getting their wine quickly and at convenient times?

These are the kinds of questions that you and your team need to ask. After all, if the wine customers refuse to unload the autonomous vehicle, then the candidate solution is worthless.

What Is the Impact of This Candidate on the Surrounding Business Ecosystem?

When you install a solution in your customer’s business, it has an impact on that business; it disrupts it in some way. If your solution interacts with external customers, then it impacts their activity. This impact might be beneficial, or it might not. In any event, understanding and assessing the impact is vital if you are to provide the right solution. Which is why we suggest that you assess the impact while the solution is still a candidate.

Figure 14.2 shows a candidate solution surrounded by its business ecosystem. The solution must interact with the elements of the ecosystem, and some elements interact with other elements. The elements might include internal operations, or external suppliers, or external receivers of something from the organization.

Figure 14.2

The candidate solution has to fit into the business ecosystem. Note the connections of the candidate to the ecosystem and the interconnectedness of the elements of the ecosystem.

Figure 14.2 shows The Market, which represents either the external customers for this organization or any other group of people who are external yet interact with the organization.

Other Software Systems must be assessed if they interact with this candidate. It might require a painstaking search through the documentation of the software to assess the impact of the candidate.

A candidate usually interacts with people, who can be inside or outside the organization. The impact here is the effect it has on their job or their way of working. Sometimes the impact might be functional—they must do something different to accommodate the candidate—or it might be personal in that it affects their feeling for the job and the way they think about their job.

Your client wants the candidate to have a beneficial impact, which could be that the candidate enables people to do their jobs more easily: A business process can be made faster or cheaper which could make it easier and quicker for external customers to make their transactions with the organization. Perhaps the candidate can save the organization money, or it causes external customers to buy more of the organization’s product. Perhaps the candidate takes advantage of a business opportunity and provides a way for the organization to operate in a new market.

Beneficial impacts are what drive your development effort. And of course, the benefit must be greater than the cost of achieving it. Most beneficial impacts can be costed—money saved by a better process or extra revenue generated. Some are harder to evaluate purely financially. For example, taking advantage of a new technology might be done purely to keep up with the competition. This has a financial advantage, but it is over a longer term and harder to evaluate. Giving your customers the ability to do something they could not do before might not have an immediate financial gain but could nevertheless be quite beneficial.

Most candidates have some negative impact. They would cause disruption, require retraining of the users, and so on. However, any negative impact must be substantially overcome by the benefits; otherwise, you should discard the candidate.

Does This Candidate Provide Real Value?

Consider Athena of the wine business, as she is paying for your development efforts. She would receive value if this candidate solution resulted in either an increase in the number of her customers, more wine being sold, or an improvement to the experience for her wine-buying customers that resulted in better customer retention. To predict whether any of those factors will come to fruition, you need to do a little research on the wine-buying customers. Do those customers feel there is value in having their wine delivered more promptly, and delivered at more convenient times? Would this value be lessened by having to go and retrieve the order from the delivery vehicle? Some wine customers might consider that to be a negative value.

Your customer research would survey the audience with questions such as these.

● Do you need fast home delivery?

● Do you want to unload the autonomous vehicle yourself?

● Would this service make you more likely to buy your wine from Athena?

● Would it cause you to recommend Athena’s Wines to somebody else?

● Would you become a customer of Athena’s just to receive this service?

You are attempting to assess whether this solution will provide value to the wine customers, and as a result bring value to Athena. The size of the investment in the solution obviously dictates how much effort you put into this research. Your marketing department might also hold strong views on the value of your candidates. Somehow, and it is not always easy, you need to assess value.

This assessment must be honest. When you read about failed IT projects, a recurring theme is that the projected value of the solution was overstated. Often ludicrously so. Be honest and careful assessing value, as the success of the initiative depends on it.

Let us say that customer response has been mainly negative, and so it is looking a little shaky for this candidate. It does not appear to provide enough value for either Athena or her customers for it to be taken any further. But let’s press on with our exploration.

Is This Candidate Economically Feasible?

It is plain that a solution is of little value to your organization if the cost to construct it and operate it outweighs its economic advantages. There is an exception where the solution produces intangible benefits that the organization is willing to pay for. Either way, you must assess the (tangible and intangible) economics of any candidate.

In Athena’s case, you go through each panel in the storyboard and estimate its cost. In this case, the first two panels introduce nothing new—it is safe to assume that your client has existing mechanisms for taking the orders and warehousing—but the third panel, the one about waiting two hours, may introduce some cost.

What does it cost to have an order sitting in the warehouse for two hours? Does this cause some kind of lost opportunity? For example, do the wine customers want their wine to be delivered as soon as possible after they order it? The intention of the two-hour wait is to potentially reduce delivery costs by delivering several orders in one trip. If that happened often, then fewer autonomous delivery vehicles would be needed. This means you compare the savings in delivery costs against the potential for harm caused by the two-hour delay.

Panel 4 in Figure 14.1 introduces the autonomous delivery vehicle. You would now need to assess the cost of purchasing or leasing the required number of vehicles. Add to that the cost of maintenance, insurance, and the real estate cost of housing them when they are not out delivering wine. To be economically feasible, these costs must be considerably less than the extra revenue the service brings.

Double-Loop Learning

Normally, we solve problems in a single-loop manner. That is, each time we fail to solve the problem we go back and try to solve it again, each time using a different or modified solution to the problem. When a probe reveals that a candidate solution is not viable, you go back and either select a different candidate or use what you have learned to modify and improve the candidate. Thus, the candidate solution changes for each single loop of the cycle.

Be willing to admit that you might be wrong, question everything, and revisit your assumptions about the problem you’re trying to solve.

Double loop means that instead of repeatedly trying to solve the same problem, you loop further back to the original problem and question it. Could it be that you are trying to solve the wrong problem? Could it be that there is a better problem to solve? Could the original problem be incorrectly defined, and by correcting it, would you have a more relevant problem to solve? Or could it be that your attempts to solve it prompt the customer to realize that this is not the right problem to solve? Figure 14.3 illustrates this double-loop approach to problem-solving.

Figure 14.3

Double-loop learning. The attempt to solve the problem using a safe-to-fail probe reveals that the problem was not solved. A single loop goes back and probes a different solution. A double loop goes back and questions whether you are trying to solve the right problem.

Let’s go back to Athena and her wine business. In Figure 14.1, you saw the candidate solution that used autonomous vehicles to deliver the wine orders. Let’s say that the exploration of the autonomous delivery vehicles revealed that while it is possible to implement such a system, it would have a low uptake by customers, and so it is not going to bring much value to Athena’s business. This discovery is valuable. You haven’t spent a lot of time on your prototypes, but you have learned a lot. The prototype has been sacrificed to the pursuit of understanding the real business goal.

So, now you do a double loop back and question Athena about the business problem she’s trying to solve. Here’s where it gets interesting.

We’re in a double loop here, so we’ve stepped back to question the goal of the project. Does it conform with the goals of the company? In line with most commercial companies, Athena has a goal of making a profit. This delivery project has its own goal, which is not necessarily to make a profit, but it must contribute to the company’s overall goal.

The double loop means that you ask Athena if fast delivery is the right goal. It seemed like a good idea at the time (as do many projects), but it’s only the right goal if the wine customers value it. When we probed the candidate, it turned out that customers placed little value on autonomous vehicles and speedy deliveries.

We referred to these as safe-to-fail probes. Safe-to-fail means that the project does not fail even when a candidate fails. Let’s call the delivery candidate a failure, but it’s really a success. You’ve saved Athena an expensive and potentially damaging development effort that would have resulted in an unwanted solution.

Also consider the knowledge you gained by probing the candidate. During the probe, some of Athena’s customers said that they don’t value speed so much as they value convenience. What her customers really want is to arrange convenient delivery times and to know when the delivery will arrive.

“I need to order it now but don’t want it delivered until Saturday.”

“I don’t get home from the office until 7 p.m., so I want it delivered between 7 p.m. and 10 p.m.”

“I sometimes have to wait around for a delivery that is coming that day. If I knew exactly when it would reach me, I could go out to run errands and be back in time.”

This example might seem exaggerated, and indeed it is, but it is also not far away from situations that, in our experience, occur frequently. We have exaggerated a little and simplified a lot to illustrate what can happen when a project sets out to solve a problem that is not the right problem.

You will find that probing candidates can be difficult. People are stubborn when their ideas are challenged. People are reluctant to let go of cherished ideas regardless of the evidence stacked against them. People tell you you’re wasting time finding the real problem and it’s better to get on and build something.

Let’s say we have overcome resistance, and everyone is accepting that we were solving the wrong problem. We’ll return to building some candidate solutions to help Athena’s customers order wine and have it delivered at a convenient time. Figures 14.4 and 14.5 are prototype sketches of candidate solutions you and the team subsequently put together.

The process model shown in Figure 14.4 would need a little enhancing. For example, when the customer selects the delivery time it would be more efficient for this activity if it started with the company offering a default time, which would be the time it knows deliveries are to be made in the customer’s area. The process should also allow customers to cancel if they cannot get a convenient time slot, and you would also need another process for people to rearrange their delivery times, and perhaps more. We’ll ignore these for the sake of brevity.

Figure 14.4

A process model of the ordering process

You would use the prototypes shown in Figures 14.4 and 14.5 to explore a little more. Is it feasible to offer delivery at any time the wine customer wants? Does the business have to use autonomous vehicles to deliver outside normal working hours? Could delivery be done by having a special relationship with a small delivery company that is willing to deliver at almost any hour? Is Athena’s problem not just getting the wine to her customers, but being able to make a profit by having the capacity for on-demand delivery?

We can leave it here. There would most likely be more exploration and probing to do, but by now you have the point that although they are prototypes of candidate solutions, they are actually devices for discovering more about the problem.

Figure 14.5

A prototype screen to experiment with and probe to determine if it satisfies the wine customers’ requirement to know when their wine will be delivered

Review

It is important to generate multiple candidate solutions. You cannot hope to satisfactorily explore the problem space with only one. If there is only one, then it is almost certainly a presumed solution. This means that little if any thought has gone into establishing the real business problem, and the team is rushing into the first solution that presents itself.

Among your solutions, you might consider including a wild-card candidate. This is a candidate that is far-fetched, playful, gravity-defying, and almost impossible to deliver. It might not make the grade in the end, but along the way it might inspire some better ideas and fresh approaches to the problem.

“ Play is the highest form of research. ”

—Albert Einstein

It is also important that you think of your candidates as sacrificial. You are not betting the farm, or your own ego, on a candidate solution. If you throw one away, there is a reason to do so, and that reason is usually that you have learned more about the problem and discovered that this candidate doesn’t fit the problem. It’s okay to be wrong early. It’s expensive if you’re wrong late.

You are probing to find flaws. If a candidate is flawed, you might be able to repair it and re-present it for another probe. Or you might pick another candidate. That’s single-loop learning.

It is more valuable when flaws in the candidate cause you to go back and rethink the problem. That’s double-loop learning.

When you are prototyping, you are building multiple sacrificial candidate solutions, examining them, and probing them, possibly to destruction. Why? It’s a learning experience. When it helps you and your customer to uncover the right business problem and the best solution for it, it is valuable learning indeed.

Resources

Cynefin: Weaving Sense-Making into the Fabric of Our World by Dave Snowden and friends (Cognitive Edge–The Cynefin Co., 2020). The Cynefin Framework is designed to help deal with uncertain, complex systems. We find the thinking behind the Framework useful for probing candidate solutions.

Return on Software: Maximizing the Return on Your Software Investment by Steve Tockey (Addison-Wesley, 2008). Tockey discusses the engineering economy and how software practitioners can appreciate the organizational ramifications of their candidate solutions.

Teaching Smart People How to Learn by Chris Argyris (Harvard Business Review Press, 2008). This book is aimed at business in general, but the author’s discussion of double-loop learning is powerful and applicable to business analysts.

15

Using Prototypes as the Specification

Sometimes it is possible that a candidate prototype can serve as the specification. But only sometimes, and regardless of what we say here, this should not be used as your mainstream approach. There are too many opportunities for a prototype to mislead the developers, which would defeat the point of using it as a specification.

However, when your project is smaller and not mission critical, and when the application domain is well understood by the developers, you might get away with this. You probably will have to add some more detail, but judiciously using a prototype as the specification can sometimes work.

It is worth repeating that prototypes, as we are suggesting you use them, are intended to ensure that you are solving the right problem. They help you interrogate the customer about his problem, not his solution.

Let’s say that you have been prototyping your customer’s problem and by now have several prototypes. (See Figure 15.1.)

Figure 15.1

By now, you have several prototypes of the different business events. Some of these might be used as the specification for development.

We have suggested that most of your prototypes are about one business event. The business event triggers the work to respond with a chunk of functionality (which we call a “business use case” or “BUC”). The BUC represents one transaction from the point of view of the outside world—your external customers or similar. Because it is a discrete unit of functionality, it is an ideal unit for development.

Let’s see how this might work.

The Prototype as the Specification

Let’s look at an example. This one is a neobank and it wants to add a facility to help customers save money for a special purpose: a vacation, a house deposit, an engagement ring, or something else. The team built the prototype shown in Figure 15.2. They proposed to call the feature a “pot,” as in the pot of gold at the end of the rainbow. The pot is a separate account within the customer’s main account and is treated individually. That is, it does not show up as part of the customer’s balance, and it is not available to be spent unless the customer deliberately releases the pot. Pots earn interest at a slightly higher rate than regular savings accounts.

Figure 15.2

The prototype for a savings pot feature for the neobank. The team chose to use a process model to show the candidate functionality.

The activities in the prototype start with the bank customer requesting to open a pot. This activity would include some checks that a pot is appropriate. For example, if the customer has a balance of, say, only $5, then there is little point in him having a pot. There will be some business rules that apply to this activity. We discuss business rules fully in Chapter 24, Other Trawling Techniques, but briefly they are the “laws” that the business has established for itself. You would need to find all the relevant business rules and attach them to this activity for the developers to know what to build.

The next activity is the customer naming his pot. This is to give the customer a connection to the particular purpose for which he wants to set aside money. It would be more inspiring to have a pot named “Tropical Holiday” than one simply named “pot.” If the customer wants it, a start date for the pot can be set. You would attach this brief description along with any other details to this activity.

Then the customer sets the rules for the pot. For example, he might want to lock away the money (from himself) until vacation time rolls around, or Christmas is on the horizon, or there is a special birthday or anniversary coming up, or he is just saving for some luxury item. You would have to add a description of this activity for the developers to build the right solution.

The deposit amounts in the final activity specify whether an amount is to be deposited in the pot whenever his salary is banked, or if payments made from the main account are rounded up and the spare change goes into the pot. There can be other ways of building the pot which the customer specifies here. Again, you need to describe this activity in enough detail for the developers to build the right solution and add any business rules that apply to this activity.

So far, so good. You could almost hand this prototype to the developers, with the addition of the details mentioned above. You would also add information about how the pot connects to the existing customer accounts database. There will be some security issues, the look and feel must be consistent with the rest of the bank’s app, there might be some operational issues, and so on. It would be worthwhile to look at the Volere Requirements Specification Template (see Appendix A) and use it as a checklist for the other non-functional requirements.

This candidate solution is relatively straightforward and should be able, with the enhancements mentioned above, to be handed over to the development crew.

However, before doing so, you should consider the risks involved. If this piece of business is crucial to the existence of the organization, then under no circumstances should you consider the prototype to be the specification. If your business rules are numerous and complicated, then this shortcut is not for you. On the other hand, if the domain is well-understood, the developers are familiar with the type of application to be built, and the product owner is confident that the right solution will be built, then go ahead. Whatever you do, don’t do it without honestly considering the risks.

What to Do with the Prototype

The preceding chapters looked at building and probing prototypes. So now, let’s see how you make use of what you have been reading. For the sake of convenience, the Volere process that has also been discussed elsewhere is shown again in Figure 15.3.

Figure 15.3

The Volere process showing its activities

In preceding chapters, we have been talking about using the goals and the scope established by the Project Blastoff to build prototypes as a way of exploring the business problem. We must stress that the intention of these prototypes is to prompt your customer to give you (and possibly himself) a better, more correct understanding of his problem.

The prototypes are throwaways. Once they have helped you discover the real business problem, they have served their purpose. Normally, you would switch to trawling for requirements to find the details of the problem space.

However, in some cases, as we have just seen, prototypes can have a further purpose. You have several options for how to proceed, as illustrated in Figure 15.4.

Figure 15.4

The options available for further use of a prototype. For option A, the prototype is discarded, but its scope and problem are trawled. Option B’s prototype is used during the Trawling activity, and for option C, the prototype can be used for Designing and Developing.

Normally, when the prototype has done its job and you are satisfied that the real business problem has been discovered, you would trawl the problem space exposed by your prototype. You can discard the prototype—it has done its job. This situation is shown as option A in Figure 15.4.

Normally, the prototype would reveal the scope of the business problem, which should be in accordance with the scope determined during the project blastoff. However, it is not uncommon to find that the initial scope needs to be adjusted because of discoveries made during the prototyping and probing efforts. It is also quite possible that your prototyping has changed your understanding of the business problem, and that requires the scope to be reworked.

Typically, you would have been building your prototypes, one for each business event. We discussed business events in Chapter 7, Business Events, when we were discussing the Project Blastoff. If you jumped over that part, it is worth revisiting it for the discussion about business events. They are the backbone of your requirement and development efforts. As each business use case is a discrete unit of functionality for the complete solution, you can treat each prototype as a separate case when deciding what to do with it.

Option B in Figure 15.4 is when the prototype has revealed the real problem and its scope, and the solution demonstrated by the prototype is a good basis for trawling its requirements. To put that another way, the prototype shows a solution that has the right scope and the right functionality to solve the problem. So, in this case, you keep the prototype as a reference for your trawling when you discover the detailed requirements for that solution.

In some cases, the prototype can be used as a development specification with some additions. This is shown as option C. There is a discussion above on how to do that. Keep in mind when doing this that your prototype must fit with the overall design of the business solution. It is obviously necessary to have consistency between the various parts of the total solution.

Subsequent chapters discuss the activities mentioned above. Please jump to whichever of them would be most useful to you. But before you leave, there is one more thing to consider.

Evolutionary and Sacrificial Prototypes

The preceding chapters have discussed building sacrificial prototypes of candidate solutions. The reason for building the prototypes (you should always build several of them) is to propose a solution that might solve the problem. As you probe this candidate solution, you and your customer learn more about the problem. It is sacrificial—you fully intend to discard it if it doesn’t solve the problem or it doesn’t reveal any more of the problem.

You might keep a successful candidate prototype to serve as a focus for the exploration of the business problem. If it illustrates the problem or shows insights that are useful, then add it to your requirements repository.

However, in some cases your prototype could be evolutionary. See Figure 15.5.

Figure 15.5

The suggested way of using prototypes to incrementally build the complete solution

So far, the prototype is a sketch of a solution, a “paper” prototype, if you will. It shows enough of the needed functionality for you or your developers to turn this into a piece of code to make a very rudimentary version of the solution you intend to deliver. You know from your prototyping and probing activities that it is solving the right business problem. The few hours spent prototyping now pay off—you can proceed with complete confidence.

Go back to the customer with this rudimentary version and work with him to refine it. To do this you might need some of the trawling techniques that are discussed in subsequent chapters. The aim is to have your prototype evolve into the delivered solution.

You can think of this process as being both evolutionary and incremental. Each business event evolves into its final form. Then, it is added incrementally to the end solution.

Review

This is a book about requirements. Requirements are a crucial part of any development effort. If the requirements are not right, then your solution cannot be the right one. However, you would like to discover the requirements as quickly as possible. This means developing your requirements to the point that the correct product can be built.

In some cases, it might be possible that the prototypes you built to explore the problem can be a significant part of the requirements. Naturally enough, you need to enhance the prototype with the relevant business rules and the appropriate non-functional requirements. You must be honest about the risk of doing this, but it might be worthwhile.

A further use of your prototype as a specification is when your developers can use it to build a rudimentary version of the intended product, which is subsequently developed iteratively. It is necessary for the customer, and probably other stakeholders, to be closely involved in this iterative development, as each increment of the product serves as a prototype. If the increment does not produce the right result, then you discard it and rework it. Again, you must be aware of the risks associated with this approach.

Your prototypes are intended to be experiments. Sometimes they can be more than that.

This brings us to the end of the prototyping chapters. There are several types of prototypes you can build, and there are several ways of using these prototypes. Experiment with them and decide which is best for you and your project.

Part IV

Trawling for Requirements

Trawling is metaphorically dragging a net—much like a deep-sea trawler’s fishing net—through the customer’s business to learn about and scoop up its requirements. You might think of this as illustrated in Figure P4.1.

Figure P4.1

Trawling is metaphorically dragging a net through your customer’s business to scoop up its requirements.

The requirements you are trawling for are the requirements for a solution to the customer’s business problem. As mentioned before, the problem can be an opportunity, the need to replace a legacy solution that can no longer cope with the demands placed on it, a change to the technology, or a change to the business environment that necessitates a new solution or modification to an old one. Or simply that something is broken.

Whatever the cause, we call it a business problem. To find a solution for it, you must first understand that problem.

This is trawling: going through your customer’s problem space, investigating it, modeling it, and doing whatever it takes for you, the business analyst, and your customer to reach a clear and unambiguous understanding of that business problem. From your understanding of the functionality and data used by the business problem, you derive the requirements for its solution.

The requirements we are talking about here fall into three main categories. Functional requirements are the things that your solution must do. For example, it must record a bank deposit, calculate interest on a savings account, accept an application for an account, and so on. Non-functional requirements specify how the functionality must be carried out; for example, how fast, how secure, how easy to use, how private, and so on. Constraints are restrictions that your solution must comply with. For example, it must run as an app on a phone, it must use data from an existing legacy system, and so on.

You can see a complete description of all the requirement types in Appendix A, The Volere Requirements Specification Template.

Let’s say that you have had a successful Project Blastoff—or achieved enough of the Blastoff outcomes to be sufficient—and you are happy to start looking at the problem space. Alternatively, you might have been doing some Prototyping for Requirements and find that you need to look more closely at some of the business processes that the prototypes have revealed, or there are questions that your prototypes are not answering. So you Trawl for the Requirements. Figure P4.2 shows how these activities relate to each other.

Figure P4.2

The Trawling activity involves working with the customers and discovering their business needs. These are usually recorded as requirements or stories and added to the requirements repository.

Trawling and prototyping should not be seen as mutually exclusive activities. They overlap to some extent, and you will most likely find yourself switching from one to the other for the same area of study. Prototypes can help you explore the problem, and trawling can help you uncover the complete details of the business. They are not meant to be separate activities, but complementary ways of discovering the real requirements.

Trawling is conventional business analysis. That is, you’re asking questions, running workshops, writing scenarios, or using any of the other trawling techniques. All of them are designed to discover requirements, but it is unlikely that you use all of them. At least, not on the same project.

As you are going through this section, please keep in mind that you should only do as much trawling as you need to. After all, the fisherman’s (or woman’s) goal is to catch enough fish, not to catch all the fish in the ocean. That may seem obvious, but too many projects seem to become locked into their trawling and carry on with it far beyond what is needed.

After you’ve done some trawling on a particular subject, ask yourself if you have learned enough to understand what contributes most to the overall goals of the project. If you’re not sure, then it’s an indication that you need to do some more trawling.

What follows are a number of chapters, each dealing with a different trawling technique. Pick the techniques that you think will deliver the best value to you. You can always come back later to find others that might be equally useful.

The best guidance is to use the trawling techniques that work best with the people you are trying to communicate with. If you find that a technique is not helping you discover requirements or that people seem to be irritated or vague, then change your approach rather than sticking with whatever it is you’re using. Some people respond well to direct questions and other people prefer that you quietly observe their work and ask for clarification later. Some people know, and are very clear about, what they need (although this is not nearly as common as one would hope). Other people need examples to help them discover what they really need.

The point is that you should try the techniques in the following chapters and use the ones that are most effective for you and your customers.

16

The Essence of the Problem

We have been spending some time talking about how a problem and a solution are different things. For example, there is a difference between “search” and “find.” The essence of the problem is to find something; searching is merely one way of doing it. You might want to know David Bowie’s birthday—you can search for it using a search engine. That’s a solution. But the essence is to know his birthday, and you can come to know it in other ways. For example, you could write to the David Bowie fan club, speak with people who knew him, or look it up in the register of births in Brixton, where he was born. Regardless of how you solve it, the essence is to know his birthday. (It’s January 8, by the way.)

The essence is an abstraction, it’s conceptual, it has no real-world technology, and that is what makes it such a powerful requirements tool. By shaking off any implementation technology, both current or proposed, human or organizational, you are left with only the problem itself, or as we are expressing it here, the essence of the problem. You could say that the essence is the soul of the problem, but not its body.

This chapter is about finding the essence of your customer’s business problem, and about the difference between a problem and a solution. Unless you fully understand the former, the latter cannot be right.

The Problem

A lot of flawed solution development happens because the team and the stakeholders confuse the problem with the solution. Stakeholders frequently ask for a solution without stating the problem it is meant to solve. Development teams often rush into a solution because they presume that it is the right solution, or it’s the solution they feel they should build. These projects often don’t end well.

A problem is an abstract thing. A solution is a physical thing.

It is useful to keep in mind that the difference between a problem and a solution is that a problem is an abstract thing whereas a solution is a physical thing. The problem has no physical incarnation; it exists only in the mind. The solution exists in some tangible artifact: It’s the computer on your desk or the device in your hand; it’s the software running on your device; it’s the consumer product you bring home from the store; it’s the list of instructions for an employee to follow.

If you are to solve the right problem, first you have to find it. To do that, you need to take a solution-free view of the problem. Let’s consider abstraction as a way of doing that.

Abstraction

The writer Yuval Noah Harari, in his book Sapiens, talks about how Homo sapiens were able to dominate their close neighbors, the Neanderthals, and might have caused the Neanderthals’ extinction. The reason behind this is that, probably because of a random genetic mutation, sapiens became able to believe in abstract ideas. An example of a useful abstract idea here is government and authority. These are abstract concepts that we have, and we all (more or less) believe in them. Sure, you can see government buildings, watch the people’s representatives debate the great issues of the day, and you can see written constitutions, but you cannot actually see or touch government. Government itself is an idea, an abstraction. It’s an agreement that we have some elected people run our country and make the rules for living together. And the forms that governments take—democracy, monarchy, totalitarianism—are also abstractions, as are capitalism and socialism. You cannot see, hear, touch, or smell any of them. You cannot see or touch authority. Yes, there are traffic lights, but it is the abstraction that a red light means stop that regulates traffic and keeps you safe on the streets.

Back to the sapiens and their domination of the Neanderthals. Because of abstractions such as authority and hierarchy, the sapiens could organize themselves. They were smaller and weaker than the Neanderthals, but when it came to a mass fight, the sapiens used their organization and tactics (both abstract concepts) to win the day. “Thag, you take your troop and go to their left, and Rog, you take this group and feint right, while Gan takes his boys to the top of the cliff and throws rocks at them.”

It probably wasn’t exactly like that, but note the abstractions that we take for granted: the authority of the person giving instructions, forming soldiers into a troop; the feint; the tactics; and so on. Without the ability to use abstractions, the Neanderthals were unorganized individuals and were no match for the organized sapiens and their tactics. So, we can say that you, a descendant of the sapiens (and not of the Neanderthals), are here today because of abstraction.

Another example of an abstraction—and possibly another contributor to you being here today—is marriage. Sure, there are rings and wedding cakes, but you cannot touch or see marriage itself. It is an idea, an agreement between two people. Yes, it has legal status, but law itself is an abstraction. It’s something that we humans made up for the greater good. The company you work for and its hierarchy are abstractions, as are all other ideas that we subscribe to.

Before we disappear down the rabbit hole of abstraction, let’s see how it affects us when it comes to the business problem we are meant to be solving.

Essence

Back in Chapter 3, Understand the Real Problem, we included a quotation from Abe Lincoln about sharpening his axe before starting to chop down a tree. This notion of preparedness brings up a quotation from Albert Einstein in which he said that if he had only one hour to save the world, he would spend 59 minutes defining the problem. The reason for spending time on the essence—an abstraction—is to discover the real problem and avoid what happens in many organizations where people waste their entire 60 minutes building solutions to the wrong problems.

When you are trawling for requirements, much of what you hear is a customer’s or other stakeholder’s idea for a solution, but not a description of the underlying problem to be solved. This could be a terrific solution, but more likely it is a solution limited by the stakeholder’s experience and imagination. Moreover, as yet, you and your stakeholders have no idea whether it is solving the right problem. Your task as the requirements discoverer is to interpret what your stakeholder is saying and make the necessary abstractions to uncover its essence.

Separate the essence of the problem from any proposed solution.

How the work physically accomplishes its functionality—the technology, the instruments, the computers, the people, and so on—is its implementation, as illustrated in Figure 16.1.

Figure 16.1

The essence usually lies buried under its means of implementation. The task is to strip away the physical artifacts to uncover the essential problem.

For example, you might be streaming your music, playing music stored on your phone, playing a vinyl record, have the radio on, or be at a live concert. The essence is the same: You’re listening to music. Music is still music no matter how you produce or reproduce it. You arrive at the essence of the problem by ignoring the current or proposed implementation, and underneath that you can find its essence, which is the fundamental reason that the work exists.

“ Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. ”

—Antoine de Saint-Exupéry, Wind, Sand and Stars (Reynal & Hitchcock, 1939)

There are several reasons for finding the essence. The first, and most important, reason is that you solve the right problem: This is obvious but often overlooked. The second reason is that finding the essence means you avoid the presumed solution. Unfortunately, people tend to express their needs in technological terms: “I need a content management system”; “I need a mobile device app”; “I need a drop-down menu.” These presumed solutions are often “flavor of the month, bright shiny object” solutions that might solve the problem but are far more likely to disappoint.

Ask Why—Again, and Again, and Again

The essence exists regardless of any technological implementation.

You can often reverse engineer the essence from a technological implementation by asking why repeatedly until you arrive at a statement that is clear of any technology and is the essence of the problem.

Asking why is standard practice that is ingrained, or should be, into every discoverer of requirements.

Asking why is standard practice that is ingrained, or should be, into every discoverer of requirements. It is probably the most effective technique for getting to the essence of the problem. Some people say that you should ask why five times. This might get you the right answer, but if repeated too frequently, will get your face slapped. We prefer to think of it as asking why as many times as you need to until you arrive at an essential answer and are satisfied that you have discovered the right problem.

For example, consider this story we came across:

As a university professor

I want to search for a book by title

So that I can check its price and availability

Let’s ask why a few times.

I want to search for a book by title

Why does he want to search? “Search” is a solution to something; it’s not the problem. Why does he search? Because he wants to find. Finding something is the real business problem. Can you find it without searching? Sure, but that’s not the point. Let’s go on with uncovering the essence:

Why does he want to find a book?

He’s putting together a reading list for his students.

Why does he want to search by title?

He explains that’s what he’s always done. But that implies that he already knows which book and does not leave any scope for finding new books.

Why is he looking for a particular book?

Because he wants it to be part of his reading list.

Why does he want to check the price?

Because the university sets a book budget for courses.

Why does he think the price he finds is the price students will pay?

(Students might find a secondhand copy of the book or be given one.)

Why does the university’s budget apply?

The university wants students to be able to afford the books they need for their courses. This means that it’s necessary to limit the amount of money students have to pay.

Why does he check the availability of the book?

Because students have to be able to buy it.

Does “availability” mean available everywhere?

Or just the place the professor is searching?

By now it is obvious that the professor has not told you the real business need. So, let’s jump right to what the essential story should have been. You can see the difference between the professor’s presumed solution and the essential problem that we arrived at by asking why:

As a university professor

I can assemble a reading list for my students

So that the list contains my preferred books, the books are available, and the students can acquire the books within the university’s budget for my course

Compare the essence with the solution given originally. You can imagine how the solution for the essence would bring far more value that the originally-proposed solution.

Asking why works in many situations. You are trying to get past the presumed solution, past people telling you how they think the problem should be solved, to get to the real business problem.

Technological fossils are technological solutions that have been part of a system for many years, and yet the reason for them has long since disappeared. For example, look at your credit cards. Do any of them have raised numbers? Why are the numbers raised? The embossed numbers were introduced to be used with carbon-paper card imprint machines. You probably don’t know what those are, because they disappeared 25 to 30 years ago when chip-and-pin cards were introduced. And yet, raised numbers still seem to be a requirement for some card issuers.

Technological fossils are things that are mistakenly accepted as essence. Part of finding the essence of the problem is to look for these fossils in your customer’s organization. You can uncover them by asking why. If you don’t get an answer that relates to essence, you probably have a fossil.

The moral of this story is that for any piece of technology—no matter how beguiling, state of the art, and attractive it is—you must abstract out the technology and see its underlying essential purpose. Or, to paraphrase President John F. Kennedy, “Ask not what your technology can do for you, ask what you’re trying to do with the technology.”

Referred Pain

“Referred pain” is a medical term. It concerns pain that is felt in one part of the body, but the cause of the pain lies elsewhere. The most common example is sciatica. The symptom is a pain felt in one or both legs, but the problem is a slipped disk pinching a nerve in the spine. Treating the leg will do nothing to eliminate the underlying problem.

Take the example of referred pain shown in Figure 16.2. The staff at a large organization are complaining that they are on hold for far too long before they can speak to the internal help desk. You could attack this problem by hiring more people to man the help desk. You could eliminate waiting on hold by implementing a register-and-call-back system. You could play calming music for the caller.

Figure 16.2

Referred pain. The symptom of the problem is with the help desk, but the cause of the problem lies elsewhere.

These solutions address the symptom and leave the cause of the problem untouched—they are treating the referred pain. The root cause of the problem has nothing to do with the help desk; it is with people needing the help desk. By investigating why staff need help, you could, or should, be able to improve the organization’s systems. By making its systems easier to use and more comprehensible, you reduce the need for help. Perhaps your investigation uncovers a lack of training. If the staff were better trained, they would be more productive, need less help, and, as a bonus, not waste their time on hold waiting for the help desk. Treating symptoms—playing music, in this example—without understanding and addressing the root cause is only superficially effective at best. Before you can solve the problem, you need to uncover the essence of the problem.

Figure 16.3

What causes long supermarket checkout lines?

Disguised Problems

Sometimes problems are deeply disguised. Consider this example: Store managers at a supermarket chain are concerned with the age of their point-of-sale (POS) system. Some of them say that customers have been complaining about long checkout lines (see Figure 16.3). The IT department has suggested developing a new POS system.

What is the disguised problem here? The IT department seems to be solving the problem that it wants to solve. It is keen to develop a new POS system, but it is far from clear that a new system would do much to alleviate the real problem.

Why would it not? The POS system is old, but does that necessarily mean it is slow? And would that be the only cause of long checkout lines? Probably not. Consider these possible causes of long checkout lines.

● There are not enough checkout registers.

● There are not enough checkout clerks.

● The checkout clerks are too slow.

● The barcode scanners malfunction frequently.

● The people hired to pack the customers’ bags are not fast enough or are in the parking lot fetching abandoned shopping carts.

● The design of the checkout area is slowing things down. (We have observed a checkout line where the shopping carts were too wide to fit through the checkout, causing shoppers to carry their goods to the belt.)

● The lines are long but fast moving. This still qualifies as “long checkout lines” even if it does not inconvenience customers.

● The environment in which shoppers wait in line is unpleasant, which causes them to think they spend a lot of time in line.

● There are sweets displayed near the lines, and parents have trouble restraining their kids from grabbing the sweets. This kind of annoyance makes any wait seem longer.

● People in individual lines always think that other lines are moving faster than theirs. This might lead shoppers to complain of “long lines.”

This list could be longer, but let’s stop there. Admittedly, the list is speculative, but it points out that until the real cause of the “long lines” is known, it would be folly to spend money rushing into developing a new POS system. The right problem to solve might well still be hidden, and the right solution to the right problem might well be far cheaper than a new POS system.

Suppose you interviewed the supermarket’s customers and found that “long checkout lines” means people perceive that the lines move too slowly. You might solve this quite easily by having one feeder line that branches to individual checkouts as they become available. This system of queuing appears to be faster because people are moving more quickly, and it might make people stop complaining. It would be worth trying—the cost would be little more than a few retractable queue barriers. If complaints lessened where it was tried, then you’re on your way toward knowing the real problem.

You might also consider approaching the problem laterally. People are complaining about the time spent checking out, so why not consider slowing it down and have one lane designated as the “slow lane”?

The objective is to cater to people—sometimes older people—who feel pressured once they get to the checkout to do it as quickly as possible. Some people are worried that they are “in the way” and want to avoid keeping people behind them in the queue waiting. Some of them are lonely and want to take as long as they possibly can to prolong the conversation at the checkout. Customers for this lane might also be people with an impairment that slows them down, people who suffer anxiety attacks, parents with several young children to control who want extra time, or people who simply don’t care how long checkout takes and welcome a leisurely approach.

By having a dedicated slow lane, staffing it with somebody who is sympathetic to the people using it, and warning people in a hurry that this is the slow lane, you might remove other sources of friction and cut down on the number of complaints. It is worthwhile spending a little time exploring a solution such as this.

Without observing the situation, interviewing real customers, and unmasking the disguised problem—the essence of the problem—any money spent is likely to be wasted.

Review

Getting to the essence of the problem is quite possibly the most valuable thing you can do for your project. By scraping away the presumed solution, the existing solution, the bright shiny technology being proposed, you get to the underlying essence.

This underlying essence is the real problem. It exists regardless of how anybody chooses to implement it. The essence is the right problem. That’s the one you have to solve.

Everything in your project relies on solving the right problem. This sounds incredibly obvious, but the thousands of development projects that fail each year attest to the fact that this is not always observed.

However, by understanding essence, by asking why enough times, by looking past the assumed solutions, you can ensure that your project solves the right problem and delivers the right solution.

Resources

Essential Systems Analysis by Steve McMenamin and John Palmer (Yourdon Press, 1984). This is the book that introduced the concept of essence. Whether you know about this book or not, it has been hugely influential in the field of business analysis.

Critical Thinking: A Concise Guide, 3rd Edition by Tracy Bowell and Gary Kemp (Routledge, 2009). Critical thinking is about challenging and questioning information that is presented to you instead of just accepting it. This is an important skill for a business analyst trying to get to the essence of the problem.

The Root Cause Analysis Handbook: A Simplified Approach to Identifying, Correcting, and Reporting Workplace Errors by Max Ammerman (Productivity Press, 1998). Understanding the root causes of a problem is another way of getting to the essence of it. This book presents a walk-through example that illustrates root cause analysis and shows how to implement it.

The Critical Thinking Community, The Foundation for Critical Thinking (https://www.criticalthinking.org). This online resource offers articles, courses, podcasts, and teaching materials on critical thinking.

Khan Academy (https://www.khanacademy.org). Khan Academy provides excellent free courses on a number of subjects—math, science, and so on. In this case, we are suggesting their critical thinking courses.

17

Business Events and Business Use Cases

Business events are events that are significant to the piece of your customer’s business that you are now studying. Business events are also significant to requirements discovery because whenever a business event happens, the business must respond to it.

The response to a business event is a business use case or BUC. The BUC is a collection of the activities and data needed to satisfy the instigator of the business event. If the business event is a customer wanting to listen to a piece of music on a streaming service, then the response—the BUC—is to locate the music and stream it along with some recommendations for future listening.

You are interested in business use cases because when you are building prototypes, trawling, discovering the requirements, specifying, and implementing, BUCs are the most convenient and consistent unit of functionality.

Business Events

You met business events back in Chapter 7, Business Events, when we were discussing the Project Blastoff; however, they are so important to what you are doing that it will be helpful to have a short recap here.

As Figure 17.1 illustrates, most business events are triggered in the outside world. That’s where your business customers, other computer systems, and other organizations trigger business events. Because they start outside the problem space, we call these external events.

Figure 17.1

An example of a business event. The business event happens the moment the plane reaches a point where the pilot should request permission to land. The pilot then radios Air Traffic Control for permission. The response to this incoming request is that the controller arranges a landing slot and radios the outgoing data back to the pilot. (Note that this is very much a simplification of what actually happens with ATC.)

Another type of business event happens because of the passage of time. It’s called a time-triggered event, and it happens when a certain date is reached, a certain time of day is reached, or a certain amount of time has elapsed since something else happened. Figure 17.2 shows an example of a time-triggered business event and its BUC.

Figure 17.2

A time-triggered business event. This one is initiated when a predetermined date is reached. In this case, this organization sends customers their monthly credit card statements on the 15th of every month. It does not matter whether the statements are sent via mail, email, or a link. The response to the event Monthly statement due date has arrived is to retrieve the customers’ transactions for the month and collect them into statements, which are sent to the customers.

Conditional business events, the third type of event, happen when a condition is met. For example, most countries have a law that requires banks to report any personal deposits exceeding a specified amount. Let’s say the amount is $10,000, and one day Ron Slick deposits $50,000 into his account. Ron might have been up to no good, and the tax people would like to know about it. Because Ron’s deposit exceeded the $10,000 reporting condition, it triggers a conditional business event, Report deposit to the tax authority. Or suppose that your point-of-sale (POS) system deducts each sale from inventory, and during the processing of a sale it detects that the number of blue jeans in inventory has fallen below the allowed threshold. In other words, a condition has been met, and this triggers the response that will request more jeans be brought up from the stockroom.

What Is a Business Event?

We will be using the term “business event” a lot over the course of this book, so you should be clear on what it means.

A business event is a happening—a time has been reached, a condition has been met, or in the case of external events, an adjacent system decides something. For example, in Figure 17.3, you see someone deciding to insure her car. Of course, if she wants to get the car insured, she must notify the insurance company. She does this using the triggering data flow Insurance Application. It is called a “triggering data flow” because—fairly obviously—it is made up of data, and it triggers a response from the insurance company: setting up the policy, arranging premium payments, and so on.

Figure 17.3

The business event happens when the owner decides to insure her car.

Note that the business event happened the moment she decided to insure the car. We are talking about business analysis here, so as an analyst you must be inquisitive and ask, What was going through her mind at that moment? For example, how did she pick the insurance company? Was it random, or was it after carefully comparing the policies and rates of different companies? Go further with your analytical role and ask if you (actually your client’s organization) can do that for her. Extending the work by offering a comparison site could be very good for your customer’s business. There are probably other possible opportunities.

Consider buying a book. Suppose you are in a brick-and-mortar bookstore (they still exist, and most are thriving). You’ve picked a book off the shelf, and you decide you want to buy it. That moment of decision is the business event. Of course, for this business event to mean anything you must inform the bookstore that you wish to buy the book.

It is important to see the business event and the triggering data flow as separate (but connected) things. The business event is what happens; the triggering data flow is what the business needs to learn in order to respond to the event.

Giving business events a good name is helpful. The general way of doing this is to form the name from the adjacent system name plus what happened. For example, in Figure 17.3, the name would be Car owner wants to insure her car.

You would normally determine the business events and list them during the Project Blastoff. This is so that you have a better understanding of all the pieces within the scope of your task. To make the development project more responsive to your client’s needs, you prioritize the events. We talked about how to do this prioritization in Chapter 8, Prioritizing the Business Events.

Let’s assume you have a prioritized list of the business events that are part of your problem space. Remember, you might have assigned the priority based on some combination of factors that add up to the best value. So, let’s start trawling your most valuable events.

The Business Use Case

The business use case—the BUC—is probably the most convenient chunk of functionality to trawl. It is not an arbitrary unit but is clearly delineated. It has a known and defined starting point—when the incoming data arrives at the edge of the business—and a defined ending point—when all the appropriate processing has been done, stored data has been retrieved and/or stored, and any needed data has been sent to the outside world. This is illustrated in Figure 17.4.

Figure 17.4

The response to any business event is a business use case. The BUC is a collection of activities that process the incoming data and continue to do so until all the activities that make up the BUC have completed their tasks, all the stored data has been retrieved and/or stored, and any outgoing data has been dispatched.

A business use case is the response to a business event. It is always a collection of identifiable activities and the data that is needed by the activities or stored by the activities. Because it is this collection of activities and data, you can say that it is a collection of the requirements needed to respond to the business event.

The business use case is a collection of the requirements needed to respond to the business event.

You can readily isolate a business use case because it has no processing connections to other BUCs; the only overlap between BUCs is their stored data. Therefore, different analysts can investigate different parts of the problem space without the need for constant communication between them. This isolation of each business use case makes it easier to identify the stakeholders who are experts in that part of the work, and they can (with your help) describe it precisely and in detail.

Business events are known to the stakeholders (they’ll know what they are without necessarily knowing the term “business event”), and they can show you how the organization processes the BUCs. For example, it would be easy enough to find someone in your favorite bookshop who can take you through the process of selling a book, or someone in your insurance company who can show you how the company processes a claim. You can sometimes see the activities within the BUC, and there is always a stakeholder or two who can describe them for you. You are using the BUC as a guide to find your way around the customer’s world and identify the pieces that functionally belong together to support a cohesive piece of the business policy.

Trawling the BUCs

You are trawling the BUC to discover the real business problem and to discover the requirements for a future solution. Subsequent chapters discuss how you can trawl. For the moment, we are establishing what you are doing. Consider Figure 17.5.

Figure 17.5

The business analyst and the customer select from the prioritized list of business events. They trawl each business event’s BUC. The output can be any recording of the BUC’s functionality.

We must stress that you get the best results if you trawl one business use case at a time. You are doing several things when you’re trawling:

● Establishing that the BUC contributes to solving the right business problem

● Establishing that the BUC is the desired response to the business event

● Discussing the BUC with the stakeholders to explore whether there is a better response

● Ensuring that any ready-made solutions work correctly within the BUC

● Discovering the requirements or stories for the BUC

The output from the Trawling activity is input into the Design and Development activities. (Figure 17.5 shows how the Trawling activity fits into the overall process.) The record of the BUC is a statement of what the response is to be. When you design and develop, you decide how it is to be.

The Desired Future BUC

Sometimes you have a piece of your customer’s business that does not exist at the moment, but the customer wants it to exist. Or possibly it does exist, but the customer wants any future solution to be different. In this case, you need the people with their vision of the future to describe what they have in mind.

This works when you start with the business events and for each of them, you model what their desired future incarnation is to be. When the intention is to use ready-made solutions to be part or all of the solution for this BUC, then the ready-made, naturally enough, becomes part of any model you build of the desired future state. However, you need to tread a fine line between using ready-mades and leaping into a presumed solution. Your models of the future state should ensure that you are getting to the essence of the problem.

Figure 17.6 shows the requirements discoverer using a storyboard with the customer.

Figure 17.6

The customer describes how he wants the future BUC to work. The business analyst is recording the desired future state using a storyboard. Note that the analyst is modeling one BUC. This BUC is the response to the business event Customer wants to open a bank account.

Using a storyboard to illustrate the problem space allows your customer to confirm the situation and discuss whether this is the best approach to solve the problem, and whether it provides value to the organization.

The desired future BUC is a significant achievement. It is for this BUC that you write your requirements or stories. We have a lot to say about requirements and stories later, but for the moment, the emphasis is on establishing a coherent partitioning and framework for your requirements and stories.

Prototyping and BUCs

In earlier chapters, we looked at the idea of using prototypes to help uncover the real problem and some of the requirements for a future solution. The intention of the prototyping activity is to model the business use cases one at a time. You won’t necessarily model all of them, and sometimes it is convenient to combine BUCs, but your analytical task will be more focused if each of your prototypes concentrates on a single BUC.

The advantage to you is that you know the start and end points for your prototype. This would be clear if you had used, say, a process model for your prototype, as illustrated in Figure 17.7. The starting event (the circle on the left of the model) represents the business event. The flow of activities makes up the business use case, and the end state is when all the data has been retrieved and stored, and outgoing messages sent.

Figure 17.7

A process model is used to prototype a candidate solution. The advantage of using BUCs here is that the start and end points are very clearly defined.

Describing the BUCs

You need to describe the functionality of the BUC. This is so that you and your stakeholders can arrive at a recorded agreement on what the BUC has to do in order to make the correct response to the business event.

The BUC description contains the processes, the data, the decisions, and the outcome of the BUC. You can describe these in a number of ways. For example, the process model shown in Figure 17.7 has four activities. These are chunks of functionality, and the names of the activities are sufficient to describe what the BUC does.

Alternatively, you could use a scenario to describe the BUC. A scenario is a list of steps, and each one is some piece of functionality that contributes to achieving the processing goal of the BUC. A simple example is to take each of the activities of the process model shown in Figure 17.7 and arrange them in a numbered list. Normally, your scenarios would be a bit meatier, but you get the idea. In Chapter 20, Scenarios, we’ll look in more detail at scenarios.

You can also use stories (coming up soon), data models, and almost anything you wish as long as your description sets down the functionality needed to achieve the objective of the business use case.

Review

Business events and business use cases allow you to carve out cohesive pieces of the problem space for study, modeling, and prototyping. By coming to an agreement with your customer about the functionality to be done by each of the BUCs, you come to an understanding of the optimal solution to support that functionality. And it is from these BUCs that you write the requirements.

If you are using ready-made solutions, they too respond to business events. Additionally, they must respond to your customer’s business events in a way the customer finds acceptable. There is no real need to trawl the internal workings of the ready-made solutions, but your responsibility is to ensure that the input and output data closely match the needs of your customer’s business.

Business events give you an external view of the customer’s business. This is because the business events are happenings, and many of them happen in the systems that surround your problem space. You are not relying on how it currently happens to be partitioned internally, or on someone’s idea of how it might be partitioned in the future, or “features” or some other arbitrary partition. Instead, you chunk the problem according to the most important view of it: how the outside world sees it. This means that you end up with a solution that is more responsive to the real demands of the outside world, and thereby more valuable to its owner.

You will probably go on to implement your solution one BUC at a time. There is more on implementation in subsequent chapters, but for the moment, it is useful for you to have the necessary functionality grouped into BUCs.

The chapters that follow discuss some of the approaches you can use to trawl your BUCs.

Resources

Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson (Addison-Wesley, 1992). This book introduced the idea of use cases. We have modified Jacobson’s approach considerably, marrying use cases to business events, to make them more useful for business analysis.

Essential Systems Analysis by Steve McMenamin and John Palmer (Yourdon Press, 1984). McMenamin and Palmer originated the idea of using business events and event partitioning for analysis work. They referred to them as “events.” We have called them “business events” to make the intention more meaningful. They also introduced the idea of essence. Sadly, this book is out of print.

Business Analysis Agility: Solve the Real Problem, Deliver Real Value by Suzanne Robertson and James Robertson (Addison-Wesley, 2018). This delves into finding the essence of the problem, and then designing a suitable business system to implement the essence.

18

The Brown Cow Model

The Brown Cow model is a way of organizing your thinking. When you’re trawling the problem space, you are working with your customers, your stakeholders, and your team and examining different aspects of the business problem and its solution. The Brown Cow model is a way of compartmentalizing these aspects so that everybody concerned is clear on exactly what is being discussed and what each aspect contributes to understanding the problem and the solution.

Previously, we looked at the essence of the problem. The essence is an abstraction that removes any physical implementation devices to reveal the underlying policy of the business problem. It would be advantageous to have an orderly way of keeping these two viewpoints—how something is done and the essence of what is done—separate but linked. This is the role of the Brown Cow model.

How Now, Brown Cow?¹

FOOTNOTE 1

In case you were wondering, the model gets its name from the phrase “How now, brown cow?” This is used in English elocution lessons to teach students their rounded vowel sounds. It isn’t clear when or where the phrase originated, but “how now” is an archaic greeting. How-Now is the first quadrant of the Brown Cow model, and thus gave the model its name.

Figure 18.1 shows the Brown Cow model. There are two axes. The horizontal axis divides What from How, and the vertical axis divides the current situation, or Now, from the proposed solution, which we will call Future. Each quadrant of the model focuses on a single viewpoint. This is particularly useful during team discussions when different people are talking about different aspects of the problem. Use the model to refocus and help people understand each other. You get people to focus with questions like “Are we talking about what’s happening with the customer’s problem at the moment, or what she wants to have in the future?” “Is this supposed to be a technological view of the solution, or an essential view?”

Figure 18.1

The Brown Cow model showing the four viewpoints of the problem space

Sometimes people talk about “As is” and “To be.” Taking only those two views is inadvisable because they ignore the important difference between the physical and the essential thinking about the problem. “As is” and “To be” encourage rushing from one solution to another and discourage creative thinking. They ignore what “could be.”

How-Now

Start with the bottom-left quadrant of the model shown in Figure 18.1. This is the How-Now quadrant, and as its name suggests, it shows how things are happening at the moment—or, if you like, the current implementation of your customer’s business.

This How-Now model of your customer’s business shows the physical devices used to process the business activities—things like the computers and software (let’s think of software as a physical thing for the moment), the people, possibly their departments, transportation devices, machines, and so on. The aim of such a model is to establish a baseline, to ensure that you are studying the correct part of your customer’s business, and to have the stakeholders recognize their work, as illustrated in Figure 18.2.

Figure 18.2

The analyst and the customer establish the current technological way of working.

Do not spend more time than necessary modeling in this quadrant. Your aim is to get enough of an understanding of the current situation to be able to move on. This is, after all, a view of something you are planning to change.

Do not spend more time than necessary on modeling the How-Now quadrant.

What-Now

Moving above the line, you get to the What-Now quadrant. The word “what” means just that: what the business is doing, and not how it is doing it. In other words, this is the essence of the current problem space.

If you took the How-Now view and abstracted it by stripping away all its technological devices, you’d arrive at its essence. You would see the things that have to be done no matter how they are done or who does them. This view, the What-Now view, enables you and your customer to see the real business being conducted at the moment, without the distraction of its technology.

It’s necessary to have a clear view of the current essence because a lot of it must be included in any future solution. Many development projects are renewal projects—an old, tired, creaking solution is being replaced by a new and hopefully better one. In this case, you should consider minimal models of the How-Now view, only enough to help you discover its essence—the What-Now—of the problem space. This view gives you the underlying business policy and business rules of the current solution.

There is often a realistic proposal that the future solution will include ready-made components or that the entire solution is a ready-made one. (Ready-made components can be off-the-shelf [OTS] solutions, software as a service [SaaS], open source, or something else. The point is that you don’t build it yourself; it is made for you.) Having a clear and agreed-upon understanding of the current essence is vital if you are to select the right ready-mades. Any future ready-made solution must be capable of processing most or all of the current essence. You allow, of course, for reasonable customization and configuration of the ready-made (we looked at this in Chapter 12, Ready-Made Solutions), or reasonable modifications to the current business processes. But the starting point for selecting a ready-made solution should always be the current essence.

We’ve started talking about the future, so let’s move there.

Future-What

Although many projects are renewal projects, it is highly unlikely that anyone would just take what they have at the moment and reimplement it using a new technology. Admittedly, there are some projects in which the objective was to rewrite a suite of old COBOL applications in a modern language (younger readers will have to ask their parents what COBOL is), but they were usually done because there are very few COBOL programmers today; they retired long ago.

Often, your customer wants what she has now along with some enhancements and some alterations. Moving away from the What-Now view and adding your customer’s changes gives you the Future-What.

The Future-What is the most important quadrant of the model.

Note the name: The Future-What is the essence to be implemented. Without seeing the essence of the new business, you risk any future solution not solving the right business problem. This means the Future-What is the most important quadrant of the model. You might choose to start with this one and revert to the Now views if you need to. If you have a good handle on the idea of essence, then we urge you to start with this one.

If your project is a greenfield project—one starting completely from scratch, with no legacy solutions—then Future-What is the place to start your planning. You need to start with What. There is little point in thinking about solutions (How) before you know the essential business to be carried out.

If using a ready-made solution has been mandated, then it should not be thought of as technology, but treated as essence. This means that any ready-mades you plan to use show up in this essential, Future-What view.

The two What or essential views involve “above-the-line thinking.” (The line being the horizontal one diving How from What.) In the abstract, essential world, you are unconstrained by technology and are free to imagine what could be. Here is where you challenge the existing policies, the work practices, the “but we’ve always done it this way” mindset. Here is where you use creativity and innovation to explore new and different ways to achieve the organization’s goals.

We looked at deriving innovative solutions in Chapter 13, Creative Candidate Solutions. The creative techniques that can be used when prototyping are entirely appropriate when moving into the Future-What view.

We urge you to consider above-the-line thinking as an opportunity to bring about a better piece of business for your customer. Time is usually a scarce resource on projects, but spending time on the Future-What viewpoint is never time wasted.

Future-How

The Future-How shows the technology and people (and any other devices) you plan to use to bring the essence into the physical world. You are moving from the abstract to the tangible. You are showing how the business will work in the future.

This quadrant usually overlaps with the work of the solutions architect, and sometimes the enterprise architect. You are treading in their domain when you start to allocate the essence to the available processors. Those architects can be very helpful with this view.

Future-How is the technological view of the solution you plan to build. It shows the software or hardware components, the people, and any other device you plan to use. This is the view that is the basis for your detailed requirements. And because you based your future implementation on the essence of the problem, you can be confident that your requirements are the right ones.

How to Use the Brown Cow Model

First, the Brown Cow is intended to be used as a thinking framework and not a procedure. We have spoken about the quadrants in a sequence, but the intention is not to slavishly build a model for each quadrant. If yours is a replacement project, then there might be some advantage to looking at each quadrant, but only if you are getting some value from each view. Otherwise, jump in and out of the quadrants wherever you need that viewpoint.

Some teams keep the skeleton of this model in a visible location so that team members can refer to the viewpoint they are discussing. When you build models—process models, prototypes, scenarios, and so on—it can be useful to tag them with the view they portray.

You don’t have to build elaborate models. A list of business events and their outcomes is often enough to serve as an essential model for the whole of the problem space. The details of the processing of each business use case can be done later.

Additionally, you don’t have to build models at all. Brown Cow is a tool to allow you to compartmentalize your thinking, or to direct your thinking to the quadrant that is most useful to you and your team at the time. How you record your thinking is a choice that you and your team make. Models are convenient, but whichever form works for you is the right one.

Prototypes usually take the Future-How view—they are solutions, after all. You should derive the essence from your prototypes to ensure that you are solving the right problem. Prototypes are meant to be disposable, so not much harm is done if you discover that one of yours does not satisfy the required essence.

Now the bad news: Some projects start with the Future-How and never leave it. When you start in this quadrant you’re starting with a presumed solution. There is no reference to the actual business rules and policy that the solution must incorporate. There is every possibility that this presumed solution is solving the wrong problem.

We strongly suggest in these situations to take the proposed solution and extract its essence. In other words, you reverse engineer it into the Future-What, as illustrated in Figure 18.3. By doing so, you can see whether the presumed solution covers the complete essential business policy.

Figure 18.3

Reverse engineering the essence from a presumed solution

We suggest that you capture the essence of the proposed solution with a list of business events and their outcomes. You examine these outcomes and ask if they contribute to the goals you established in the Project Blastoff. You might also build a context diagram of the proposed solution and compare that with the one you built during the blastoff. Now you can have an informed conversation with your stakeholders and resolve the discrepancies.

Review

The Brown Cow model is a framework for thinking. Each quadrant represents a different viewpoint of the same problem space or solution space. The advantage to you is that you can clearly differentiate between the views you’re taking at any given time.

We must stress that the viewpoints are not intended to be taken in a sequence where it is not practical or effective to do so. However, in some cases, you may choose to work methodically through the four viewpoints, starting with the How-Now and ending with the Future-How. But this would be because you need to untangle a complicated situation, and separating the viewpoints helps everybody have a clear vision of what’s happening.

It is, of course, not necessary to build models (or some other representation) for each quadrant. You might choose to do that for only one or two of the segments. The intention of the Brown Cow is to aid your thinking about the problem. Whether you commit your thinking to a diagram is up to you. Whatever you do, it is a matter of necessity to think clearly, and being able to separate your viewpoints is very much a part of that clarity.

The emphasis in this book is on solving the right problem. Being able to separate viewpoints, and in particular, separate the essential—the what—from the implementation—the how—gives you a much better chance of seeing the real problem. This means you spend a lot of your time thinking “above the line.” This is the horizontal line on the model that separates the What from the How, or the essence from the implementation.

Brown Cow is a thinking tool, and so should be a vital part of your trawling activities.

Resources

You can see Suzanne explain the Brown Cow model at https://www.youtube.com/watch?v=ckWaVRkM3dI&t=239s.

19

Workshops

Workshops are one of the most commonly used trawling techniques. A workshop will typically involve you, the business analyst, and the right combination of specialized stakeholders, all of whom have an interest in the solution.

Workshops can cover any scope, but you will probably find that they are particularly helpful when you concentrate on one business use case. We discussed before how the business use case, the BUC, is the collection of functionality and data that respond to the business event. A workshop is particularly useful for the stakeholders to discuss what they want and need this BUC to be.

Workshops bring about synergy—interaction that produces results that are greater than the sum of the results individuals could produce on their own. The participants work together to come to a consensus on what is needed and wanted. This synergy between the participants also brings ownership and engagement. When people feel they have contributed—in any way whatsoever—they have a stake in the success of the outcome. If your workshop is about a solution, then the participants own that solution and will now do what’s needed to make it succeed.

Most of all, workshops are a time for exploration and discovery. They should be freewheeling affairs where everybody contributes and all ideas are exposed for better or worse until the optimal result is achieved.

BUC Workshops

Let us assume that you have called a workshop to explore the required functionality of a business use case and to discover some or most of its requirements. Of course, you hold workshops for other purposes, but as we are concerned with requirements discovery, let’s focus on that kind of workshop. Figure 19.1 illustrates such a workshop.

Figure 19.1

The workshop records the proposed functionality of the business use case using models, scenarios, sketched prototypes, or other means.

Outcomes

Your workshop should focus on outcomes. One outcome should be an imaginative and functionally correct BUC description that is ready for further exploration for its requirements and eventual development.

There is also the outcome of the BUC. That is, when it is implemented, the BUC produces a result that is beneficial to the organization and/or the customer. Another outcome of the BUC is that it works correctly within the constraints of the customer’s organization. That is, it must not disrupt (within reason) other business processes. A little bit of systemic thinking can be useful here.

Sometimes you do not have access to the real customers to get their needs. In this case, you would use a persona. We discussed personas in Chapter 6, Customer Segments, where we described a persona as “an invented personality; an imaginary but nevertheless archetypical representative of a customer segment.”

When the team has built a persona, the team members are familiar with the attributes of the persona and use that knowledge to discuss how the persona would react to some of the suggestions. What would the persona expect from this BUC? Would the persona accept it?

Your authors know of teams that have a physical representation of their persona in their workshops. The most striking was the team that had a life-size cardboard cutout with a photo of their persona (found on the internet) as its face. It was slightly surreal when team members talked to the persona. It was also effective.

Regardless of your representation of the persona, the outcome of the BUC being discussed by your workshop must be that it works correctly, satisfies the customer’s (in this case, the persona’s) needs, is beneficial, and is an attractive business solution. A well-run workshop should be able to achieve all of these goals.

Outputs

Along with the outcome, the workshop produces outputs. In Figure 19.1, the team is writing a scenario. Scenarios are coming up in the next chapter, but in the meantime, they are a step-by-step description of the BUC’s functionality: Step 1, do this; Step 2, do that; Step 3, do something else; and so on.

You might also build a process model (coming up in a few chapters). This is a graphical representation of the functionality of the BUC. There are other models, and they will appear in subsequent chapters. It doesn’t really matter which model you use as long as all the meeting participants understand it.

One other useful output from the workshop is a collection of business rules. Business rules are the internal “laws” that govern the activities of the organization. These will be cited by the appropriate participants and should form part of your requirements repository. Business rules are focused on the organization. They originate internally or are imposed by external organizations—governments, regulators, and so on—and any solution you build must comply with them. Many of the requirements for your solution are derived from the business rules, as obviously, it is a requirement that business rules are followed.

Non-functional requirements often come out of workshops. When you are discussing and exploring the BUC it is common for people to come up with non-functional requirements that apply to the functionality under discussion. For example, for a BUC in which a customer is making a bank transfer, your workshop participants would likely want to talk about security and usability, the enterprise architect would want to talk about interoperability with the bank’s payment system, and the marketing person would want to talk about look and feel. Your task is to capture these non-functional requirements and add them to the growing collection for the BUC.

Mechanics of a Successful Workshop

There are a few things you can do to make your workshops effective. None of this is rocket science. And although it is certainly not the fun part of workshops (the discussion part), it is nevertheless important.

The Right Participants

Your workshop participants must be people who have a genuine interest in the business use case under discussion. Representatives of the customer segment should be part of the workshop’s makeup. They can be human representatives, or it can be your persona. The objective is to have knowledge of the customer and what the customer needs the solution to do for him. Your workshop should be made up of willing participants, preferably influential ones.

The right people are those who can either make the decisions or have the business or technological knowledge to support the decisions. The people who do the work and their leaders make up the former group. Business analysts, product owners, and developers are among the latter group. Your organization is unique, so the right people have different roles and titles, but you can recognize who they are by asking each participant at the beginning of the workshop what they think they can contribute to the workshop, why they are interested, and what they would like to get from the workshop.

We realize how hard it can be to get the right group, but without the right attendees, your workshop cannot be effective.

The Right Workshop Space

This is obvious, but it helps a lot. Simply put, it is difficult for participants to contribute effectively if they are constrained by their environment.

If your workshop is online, ensure before the workshop that everybody is comfortable with the technology. It is annoying and a waste of time to participants if they have to wait while somebody fumbles with their computer’s settings to load the software or get their microphone or camera to work. And although people have been using this technology for some time, it still happens that someone’s settings have changed and now interfere with the online meeting.

Collaborative whiteboards are useful for workshops. When every participant has a pen, they can write on the whiteboard at their moment of inspiration. Just ensure before the workshop that everybody’s operating system allows them to use your chosen whiteboard and that everybody is familiar with the way it works.

When you are able to bring people together in the same physical room, take the time to check the room if you are not already familiar with it. It is frustrating to participants when they discover that the whiteboard pens are missing or have run out of ink, or there’s no flipchart paper, or they cannot see the screen showing a remote participant. You almost always have to rearrange the furniture so that everybody is comfortable. These are small things, but they distract from your aim of getting the maximum value from your workshop.

A Facilitator

Someone has to be in charge. Someone has to coordinate people’s comments and contributions. This would normally be you, the business analyst, but occasionally, people prefer to bring in someone with facilitation skills. We would not for a moment suggest that you hire an expensive outside facilitator, but often in organizations there is somebody who is able and willing to facilitate your meeting. This is particularly effective if the number of participants becomes too large for you to handle.

The Discussion

The discussion should be a facilitated free-for-all. That’s contradictory, but it indicates the lively atmosphere of a good workshop. The facilitator encourages everyone—including the shy ones—to participate. The participants introduce their ideas whenever they have them.

The discussion is about a business use case. The intention is to capture its business needs and what its most beneficial outcome could be. This means discussing the needed functionality and the business rules that regulate or require that functionality.

Workshops work because they are a forum for the interested parties to contribute their ideas on the composition of the BUC. They discuss what the BUC should do and how it should do it. This is the time to introduce innovations and new ideas that will make the BUC more valuable.

In short, the discussion brings together the thinking of the people who are most qualified to decide on the best BUC.

Visual Artifacts

Humans respond to what they see. Our environments and our evolution have resulted in people whose visual sense is their strongest stimulus.

Your workshops should be visually active. Building diagrams, models, and prototypes on screens and whiteboards provides a focus for your participants. If people merely sit around the table and talk, the meeting is far less productive (possibly inconclusive) than if they have the focus of something visual to aim their remarks at. This is shown in Figure 19.2.

Figure 19.2

A workshop using a visual artifact as the focus for the participants

These visuals can be prototypes, scenarios, process models, stories, story maps, or anything that captures the ideas coming from workshop participants.

Some people are reluctant to draw anything in public, so many workshops find it effective to have someone act as a scribe. The scribe records what is being said and draws diagrams as the participants describe their ideas.

Having visual representations gives people not only a focus, but a sense of progression as they see their ideas transformed to a visual reality.

Draw, don’t talk. Of course, you must talk, but draw while you’re talking.

A Call to Action

Your workshop should end with a call to action. Actually, many actions.

During the workshop, you discuss many issues. Most of these require some further action, or actions, that should not be done during the workshop but taken offline. Each action must have an owner—someone who is responsible for ensuring that the action is carried out. Each action preferably has a deadline, and the owner agrees that the allowed time is reasonable.

The call to action is a list of everything that requires further work. Make sure everyone is given this list so that they all know what has to be done, who is doing it, and when it will be done by. This is the kind of information that fuels project teams.

Review

Workshops are where the facilitator (this could be you, the business analyst) brings together the right group of knowledgeable stakeholders to discuss a business use case. The intention of the workshop is to discover the requirements for the BUC.

The requirements are not necessarily the detailed, atomic requirements that are delivered to the developers. More likely, the requirements are represented by models and scenarios that define the intended functionality at a higher level.

The workshop is a discussion using visual artifacts. These artifacts—process models, wireframes, scenarios, and so on—are built while the discussion is going on. They are the result of the discussion, a record of the discussion, and also the output of the workshop. It is later that the business analyst will derive the detailed requirements from the workshop’s output.

This chapter was intended to introduce workshops and provide the basic information to get you started with them. Once you have a workshop or two under your belt, you will want to know more about the conduct of workshops. We refer you to the books listed in this chapter’s Resources section.

Resources

Requirements by Collaboration: Workshops for Defining Needs by Ellen Gottesdiener (Addison-Wesley, 2002). Refreshingly, this gives a lot of emphasis to the human side of software development. The book explains how to plan and conduct requirements workshops so that the requirements are more effectively defined through collaboration.

Making Workshops Work: Creative Collaboration for our Time by Penny Pullan (Practical Inspiration Publishing, 2021). This gives step-by-step guidance for running engaging, effective workshops. The author is very visually oriented, and her simple graphics are used to illustrate and communicate the findings of your workshops.

20

Scenarios

For each business event, there is a response: the business use case, or BUC. In this chapter, we will discuss recording the functionality of the BUC, and by doing so, discovering its requirements. Here, we’ll look at using scenarios to record this functionality. We looked at workshops earlier. A scenario is often used in workshops to capture the thoughts of the participants as you’re discussing the desired functionality for a BUC.

A scenario is a limited series of functional steps that are needed to complete the work of the BUC. They are written in plain text; they describe the business needs rather than the technological ones and can be understood by business stakeholders with no technical training.

The scenario starts out as a requirements discovery tool. Later, it is used to show the developers how the atomic requirements hang together. We should mention that you can add exceptions and alternatives into your scenarios to make this tool quite utilitarian. We’ll look at these as we go along.

In short, scenarios are easy to understand, are useful and flexible, and make a valuable requirements tool for your Trawling activity.

What Is a Scenario?

The scenario describes the actions of a business use case.

A scenario, to give it its proper meaning, is an outline of a plot, or a postulated sequence of steps. In requirements work, we use this term to mean the plot of a section of the work you are studying. The use of “plot” in its literary sense is intended to imply that you break the work into a series of steps or scenes, and by explaining these steps, you explain the work.

Previously, we discussed how to partition the problem space using business events. Each business event has a functional response: the business use case. You write a scenario for most, if not all, of the BUCs.

Consider the following scenario, which is the response to the business event A movie fan wants to go to the movies:

The moviegoer asks for movies based on her previously recorded preferences.

The moviegoer filters the movies based on the time of the screening and the location of the cinema.

Reviews of the shortlisted movies are provided on demand.

The moviegoer selects a movie.

The moviegoer buys a ticket online.

Ticket details and a QR code are sent to the moviegoer’s phone.

The moviegoer can elect to send messages to selected friends with details of the movie and an invitation to join her at the movies.

The moviegoer checks parking availability and public transport options for the cinema.

The moviegoer sets an alarm to remind her when it is time to leave for the movies.

How would you use this? In several ways.

If you need to record the current way that your customer does her work, then you can interrogate and record the results in a scenario format. Ask “What do you do next?” and “What comes after that?” and add the responses to your growing scenario. This is the How-Now view from the Brown Cow model discussed in Chapter 18, The Brown Cow Model. You don’t always need to do this, but it can be a useful way to arrive at a consensus on the work.

Or, probably more usefully, you could use the scenario to elicit what the customer wants to do in the future. At the same time that your customer is telling you what she thinks she wants, you are looking for the essence of it, and trying not to simply record her presumed solution.

When you are in a workshop, the scenario can be used to record a consensus of the participants’ views and ideas. Just like the individual customer, you are always suggesting and shaping and innovating to arrive at the optimal flow of the work.

For the moviegoer’s scenario, you would go back over it looking for improvements. You are looking to see if any of the steps can be replaced with a more essential version. There is still some technology in the scenario—buying the ticket online; receiving the ticket on a cellphone—but as these are mandated by external entities, which means there is no feasible alternative, it is okay to include these technological items. In fact, you are treating them as agreed constraints.

Scenarios with Ready-Mades

If your project intends to use a ready-made (off-the-shelf, open-source, legacy, etc.) solution, then your scenario is used to show the customization steps and any additional steps to make the ready-made work in the customer’s environment. For example, let’s have a business event where an existing bank customer wants to set up an additional special-purpose account. The BUC scenario would be as follows:

Perform in-house security check on the application.

Ready-made account solution (with configuration) opens the account.

New account routed to existing ready-made customer resource management (CRM) solution.

Generate app page for the new account.

Send acknowledgment message to the customer.

Step 1 is there because the bank’s policy is to do its own security checking and not rely on an outside service. The security checking can be done immediately with no break to consult with a human, so it is considered to be a single step.

Step 2 is done by the ready-made (you would give it its real name). The functionality of the ready-made does not have to be documented by your scenario; it’s all hidden inside and you don’t have to worry about it. This is, after all, the reason you’re buying the ready-made. As long as you know the data in and data out, you can ignore its internal functionality. However, the scenario mentions “configuration.” Most ready-mades need some kind of configuration to work as desired. You have to tell it the rules for accounts and prices, what exception handling you want, and so on. We suggest that you specify the required configuration using a separate but linked document.

Step 3 is the way this bank operates and is not part of the accounts ready-made. However, the bank has an existing CRM ready-made. In this case, the communication between the accounts solution and the CRM is already established, and there is no need for any special implementation.

Steps 4 and 5 are things the bank wants to do when its customers open a new account. These will need to be developed in the usual way.

Using Scenarios

You need to reach a consensus on your scenarios. Often, the most expedient way is to write the scenario and then present it to the customer and the stakeholders. You invite criticism; you invite changes. You make changes to help everybody reach an agreement that this is what the solution will do whenever this business event occurs.

Write your scenarios using from three to ten steps.

Write your scenarios by breaking the functionality of the business use case into a series of steps, with each step being some meaningful and recognizable activity. Ideally, you should aim for between three and ten steps. These numbers are not carved in stone, and nothing untoward will happen to you if you use more than ten steps. However, if you end up with dozens of steps, either you have a gigantic business use case (impossible for normal commercial work) or you are writing your scenario with an unnecessarily meticulous level of granularity. The aim is to keep the scenario simple enough to be readily understandable. Three to ten steps usually achieves this goal.

The next example is the business use case for checking a passenger onto an international flight (see Figure 20.1). This business event happens when the passenger arrives at the check-in desk. Either he has not checked in online, or for some other reason—like dropping off bags—he needs to go to a check-in desk. Here’s Sherri, one of the agents describing the check-in process. Keep in mind that she is describing the current way of working—the How-Now view of the work—which you are using to start your investigation:

Figure 20.1

An airline check-in for an international flight. As we go through the scenario for this case, see if it matches your experience of checking in for a flight.

“I call the next customer in line. When he gets to my desk, I ask for some kind of identification of his flight. I can get the record locator (that’s the six alphanumeric characters code) from the QR code on the passenger’s phone, or if they have not checked in online, I ask for their name and the flight they are on. Most people don’t know the flight number, so I usually ask for their destination. They must know that!

“I make sure I have the right passenger and the right flight. It would be pretty embarrassing to give away someone else’s seat or to send a passenger to the wrong destination. Anyway, I locate the passenger’s flight record in the computer. If he has not already given it to me, I ask for the passenger’s passport. I check that the picture looks like the passenger and that the passport is still valid.

“If the computer has not already assigned a seat, I find one. This usually means I ask whether the passenger prefers a window or an aisle seat, or, if the plane is already almost full, I tell him what I have available. Of course, if the computer has assigned a seat, I always ask if it is okay. One way or another we settle on a seat, and I confirm it with the computer system. If needed, I can print a paper boarding pass at this stage, but I usually do the bags first.

“I ask how many bags the passenger is checking and, at the same time, verify that he is not exceeding the carry-on limit. Some people are unbelievable with what they want to carry into a fairly space-restricted aircraft cabin. I ask the security questions about the bags and get the passenger’s responses. I print out the bag tags and securely attach them to the bags, and then I send the bags on their way down the conveyor belt.

“Next, if the passenger does not have a boarding pass on his phone, I print one. This means that I have done everything as far as the computer is concerned. But there is one more thing to do: I have to make sure that everything agrees with the passenger’s understanding. I read from the computer screen where he is going, what time the flight is, and what time it will board, and if a gate has been assigned I tell him that too. I also read out how many bags have been checked and confirm that their destination matches the passenger’s destination. I hand over any documents and wish the passenger a good flight.”

Now, sketch out the scenario. Break the story down to the steps that you consider to be the best ones to capture the normal path through the story. There are no hard-and-fast rules about how you accomplish this—just write whatever seems logical to you. After all, you are the person who is going to use the scenario; it might as well fit with your view of the work. Later you will adjust it with your subsequent activities, but for the moment let us suppose that this is your first draft:

Find the passenger-booking record using the QR code from the passenger’s phone or ask for the passenger’s name and flight.

Check that this is the right passenger, flight, and destination.

Check that the passport is valid and belongs to the passenger.

If the passenger is not checked in, allocate a seat.

Ask the security questions.

Check the baggage onto the flight and print and attach the bag tags.

Print the boarding pass (if needed).

Do a final check of the flight details and tell the passenger to “Have a nice flight.”

In a workshop, stakeholders are invited to participate and revise the scenario until it represents a consensus of what the work should be.

Confirm this scenario with the interested stakeholders. It is in plain English (or whatever language you’re using) so that the stakeholders can participate and revise this scenario until it represents a consensus view of what the work should be. Once a consensus is reached on the work, start to formalize the scenario. Along the way, you will learn more about the work.

The first part of the formalized scenario identifies it and gives it a meaningful name.

Business Use Case Name: Check passenger onto flight.

Next, you add the start-up mechanism—the trigger—for the business use case. It usually consists of some data or request (often both) arriving from outside your work area. There are also time-triggered business use cases, in which case you state the time condition (an hour or a date is reached, an amount of time has passed since another business use case, and so on) that initiates the use case.

Trigger: Passenger arrives at the desk with passport and flight ID or destination.

Now add any preconditions that must exist when the business use case is triggered. Preconditions indicate the state of the work at initiation. Usually, this means certain other business events must have occurred before this business use case makes any sense.

Preconditions: The passenger must have a reservation.

The check-in desk is not the place to be if you do not already have a reservation. While it may seem like good customer service to allow passengers to make a reservation at the check-in desk, the amount of time needed for this transaction would no doubt annoy the other passengers standing in line.

Actors are the people or systems that connect to or do the work of the business use case. Usually, one actor triggers the business use case, and then one or more others participate in the work.

Actors: Passenger (trigger), check-in agent.

The passenger triggers the business use case by arriving at the check-in desk; he is also the recipient of the business use case’s output. The passenger interacts with the agent to carry out the work of the business use case. Although the agent manipulates any automated product being used, that action should be thought of as simply the current implementation; it has no binding significance. The essential business is triggered by the passenger, who, in some future incarnation, might be more closely involved. Self-check-in seems obvious, but don’t leap to the first solution that comes along. The point of the requirements investigation is to make sure you understand the work before choosing a solution.

The Essence of the Business

The scenario now represents the current incarnation of the work. If you think back to the Brown Cow model from earlier, this scenario belongs to the first quadrant of the model: the How-Now view of the work.

To move above the line and look at the What-Now and Future-What views, you must consider the essence of the problem. To do so, go back over the scenario and eliminate any technological bias while simultaneously asking the question: “What does the business really need to do?”

The essence is not a better solution to the problem. It is the real problem.

The essence is not a better solution to the problem. It is the real problem. You find the real business problem when you eliminate all the technological camouflage that normally makes up a description of some work.

Assume for the normal case that everything works perfectly.

Also, for the moment, consider only the normal case scenario. The normal case (sometimes called the happy path) is when everything works perfectly. Of course, everything does not always work perfectly, so later you go back over the same scenario and explore the exceptions and alternatives.

Let’s revisit the check-in scenario, and this time change the language to be technologically neutral. The How-Now version is:

Find the passenger-booking record using the QR code from the passenger’s phone, or ask for the passenger’s name and flight.

The passenger and the record locator are both constraints on the work. The passenger comes from outside the work. The record locator is a constraint imposed by the current computer system. In this case it is a real constraint, not because a computer system uses it (the computer system belongs to the airline and therefore can be changed), but rather because it is used by travel agents and other bodies outside the scope of the organization. For this reason, we accept that it is a constraint. However, the record locator is merely a means to an end. The essence of the work is to find the passenger’s reservation. Let’s rewrite step 1 to reflect this understanding:

Locate the passenger’s reservation.

Stating it in the essential manner, without the technological artifacts, allows us to think of better ways to implement it. If you want to rush ahead, you can see that there are several possibilities for the future solution. Machine-reading the passport or face recognition spring to mind as a way for passengers to identify themselves.

But for now, put those ideas for future technology aside and consider that the essence of the problem is to connect the passenger with his reservation. The How-Now scenario reads:

Check that this is the right passenger, flight, and destination.

This step focuses on ensuring that the passenger is who he says he is and that the reservation matches his expectations for the flight. Let’s write the essential step 2:

Ensure that the passenger matches the reservation.

Next, the How-Now scenario checks the passport:

Check that the passport is valid and belongs to the passenger.

The passport step contains no technology (apart from the passport, which is a constraint); therefore, we can consider it to be the essence and we do not change it. However, you need to specify what is meant by valid, so this warrants a few words of explanation. We suggest enhancing this step by adding the appropriate business rules:

Check that the passport is valid and belongs to the passenger.

3.1 The passport must be current.

3.2 The passport must not expire within three months of the end of the complete trip.

3.3 The passport must be valid for travel to the destination country.

3.4 Visas (where needed) must be current.

3.5 There must be no “refused entry” stamps from the destination country.

Alternatively, you might simply leave this step as it was and refer to notes to complete the business rules for step 3.

Check that the passport is valid and belongs to the passenger.

See procedure guideline CAA-175.

This is the essence of the problem. There is an unyielding constraint that the passenger has a passport—this is international travel you are dealing with. Ignore for the moment countries within the Schengen Agreement; that is, countries that allow travel between them using an identity card only. These are alternatives and you’ll come back to them later. The airline’s management needs to enforce the rules on passports because the airline is responsible for returning any passengers who are refused entry at the destination country. All in all, this seems like a mandatory constraint, so keep it as part of the essence.

The same technique of scrubbing away the technology and getting to the essence is employed for later steps in the scenario. Keep working through it until you and your interested stakeholders agree that it is an accurate, but not yet detailed, portrayal of the essence of the work. When you are finished, it should look something like this:

Business Event: Passenger decides to check in.

Business Use Case Name: Check passenger onto flight.

Trigger: Passenger arrives at the desk with passport and flight ID or destination.

Precondition: Passenger must have a reservation.

Actors: Passenger (trigger), check-in agent.

Locate the passenger’s reservation.

Ensure that the passenger matches the reservation.

Check that the passport is valid and belongs to the passenger.

See procedure guideline CAA-175.

Allocate a seat if not previously allocated.

Get the correct responses to the security questions.

Check the baggage onto the flight.

Give the passenger the boarding pass and proof that the bags have been checked in.

Wish the passenger a pleasant flight.

You should add an outcome to the scenario—that is, the desired situation at the successful conclusion of the business use case. Think of it as the stakeholder’s objectives at the time he triggered the business use case.

Outcome: The passenger is recorded as checked onto the flight, the bags are assigned to the flight, a seat is allocated, and the passenger is in possession of a boarding pass and bag reclaim information.

We have left the outcome of the BUC until the end. We have done that for symbolic reasons. That is, you get to the end of the processes for the BUC, and this is the outcome you have achieved. You could, however, put the outcome at the beginning of the scenario and call it the desired outcome. Think of it as the process steps you are about to read are all aimed at achieving this desired outcome. Whether you put the outcome at the beginning or the end, you should think of it as the center of interest for the business use case.

Alternatives

Alternatives arise when you offer an intentional choice of user actions.

Alternatives arise when you wish the user to have a choice of possible actions. These choices are intentional; they are wanted and defined by the business. They usually exist to make the work of the business use case more attractive and convenient to the actors. When you buy things online, for example, you can decide whether to place your selected goods in a shopping cart awaiting checkout or bypass the shopping cart and have them shipped right away by clicking “Buy now.” These deliberate choices offered by the vendor are alternatives.

In the airline check-in commentary above, for some countries, passengers did not need passports and could use an identity card. Treat that as an alternative.

The work reacts differently depending on which alternative is selected. Suppose that you are sending a small package to someone and want to use the postal service. You buy the postage online through the postal service’s website, but before you print the shipping label showing the postage paid, you have a choice of how to get your package into the post. One option is to take it to the post office. In this case, you will be offered the location of the nearest post office and several others nearby. You could elect to drop it in one of the drop-off boxes scattered around the city, in which case the site tells you the nearby ones. You could elect to have your mail carrier collect it; in which case you book a pickup day and pay a small fee. The following is part of a scenario. Let’s say that you are up to step 5.

Arrange getting your package into the postal system.

Alt 5.1 Take the package to the post office.

Alt 5.1.1 Provide nearby post offices.

Alt 5.1.2 Include post office QR code on mailing label.

Alt 5.2 Use a drop-off box.

Alt 5.2.1. Warn the customer about the maximum size of parcels for drop boxes.

Alt 5.2.2 Provide nearby drop boxes.

Alt 5.2.3 Include drop-off QR code on mailing label.

Alt 5.3. Collection.

Alt 5.3.1 Select a collection day from those available.

Alt 5.3.2 Inform the customer of the fee and add it to the postage.

Alt 5.3.3 Add collection instructions and QR code to the mailing label.

Print mailing label.

You find alternatives by examining each step of the normal case. Look for instances where the step may be carried out differently, or the user or customer can be given a choice. These choices are sometimes interesting from the point of view of improving the work or providing a better service.

Exceptions

Exceptions are unwanted but inevitable deviations from the normal case.

Exceptions are unwanted but inevitable deviations from the normal case. They are unwanted in the sense that the owner of the work would rather that they did not happen, because they have the potential of preventing the actors from achieving the desired outcome of the BUC. Nevertheless, we know that they will happen from time to time, so we have to cater to them. For example, a passenger might have a dead battery on his phone and cannot retrieve his boarding pass, an online customer might forget his password, or a passenger could arrive at the airport having left his passport behind.

We must pause here to urge you to delay looking for exceptions until you are satisfied with the normal case (or happy path) scenario. It is far too easy for stakeholders to get carried away with exceptions, and your workshop can be quickly derailed by needlessly chasing exceptions that might never happen. It is only when you have agreed to the normal case that you can methodically work through it by looking for the exceptions and deciding what to do about them.

The goal of the exception scenario is to show how the work handles the exception: in other words, which steps must be taken to rejoin the path of the normal case (if possible). You can write a separate scenario to show the exceptions, but in most cases, it is more convenient to add the exception steps to your normal scenario.

You find the exceptions by examining each step of the normal case and asking questions such as the following.

● What happens if this step cannot be completed, or does not go to completion, or comes up with a wrong or unacceptable result?

● What can go wrong at this step?

● What could happen to prevent the work from reaching this step?

● Could any external entity disrupt or prevent this step?

● Could any technology used to implement this step fail or become unavailable?

● Could the end user fail to understand what is required of him, or misunderstand the information presented by the product?

● Could the end user take the wrong action—intentionally or unintentionally—or fail to respond?

There are many questions you can ask, each of which seeks to find a different potential error. We suggest that you make a checklist of the questions pertinent to your particular situation and add to it each time a new project discovers new questions.

We have also seen some successful attempts to use automation to help with this task. Our colleague Neil Maiden at City University in London developed a scenario presenter that works with a normal case scenario to automatically generate a list of potential exceptions. It also uses rich-media scenarios where additional information in the form of photographs, movies, sound, and so on is integrated into the scenario.

We know from experience that the exceptions have the potential to necessitate a great amount of remedial rework if they are not found at requirements time, so look carefully for things that could go wrong. You can ignore the scenario in which the work is struck by a meteor, or giant flying squids eat the internet, but almost anything else is possible.

Misuse Cases and Negative Scenarios

Misuse cases show negative or harmful possibilities, such as someone abusing the work or attempting to defraud it. Examples include users deliberately entering incorrect data, customers using stolen credit cards, and pranksters making fictitious calls or transactions, planting a virus or other malware, or engaging in any of the myriad other things that can be done to harm the work.

“ Maybe ‘abuse cases’ sounds like a bad pun, but the idea of the Negative Scenario (Burglar impersonates householder, Alarm Call Center Operator colludes with Burglar, etc.) is important. ”

—Ian Alexander, Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle

It may be helpful here to think in terms used by novelists and to use the idea of the protagonist and the antagonist. The protagonist is the hero or main character of the story: the good guy, the user, the person using your solution as shown in your normal use case scenario. While you want your protagonist to win, you should also think of your protagonist as someone who is forgetful, slow, distracted, or not paying attention. Go through the normal case scenario, and for each step, ask what could be done incorrectly. It may be simpler to write a new scenario for each misuse, as the ramifications of a misstep may be complex enough to warrant their own separate story.

Examine all the steps for the normal case and ask if there is a possibility of someone opposing or misusing that action.

So much for the protagonist. The antagonist is the person who opposes the work, seeks to harm it, or wants to defraud it. Hackers and fraudsters are the most commonly thought-of examples of antagonists. Examine all the steps for the normal case and ask if there is a possibility of someone opposing or misusing that action. In this case, the ramifications upon discovering an antagonist’s misuse may be to simply stop the execution of the business use case.

Whether you annotate the normal case with the misuse steps or write a separate misuse scenario depends on the complexity of the situation and the comfort level of the stakeholders.

Review

We have been discussing how to write a scenario; a natural language tool for describing a business use case. The intention of the scenario is to help you and your stakeholders come to a mutual understanding of the functionality of a business use case. Writing the BUC scenario tests whether sufficient study has been done or whether the business analyst needs to investigate further.

You can, if it is helpful, write a scenario for each Brown Cow segment. The How-Now segment gives you a view of how the work is done at the moment. This is useful as a starting point, as it gives your stakeholders a recognizable snapshot of part of their work. The What-Now segment shows the essence of that work, and you use it to ensure that the problem it solves is indeed the real business problem.

The Future-What scenario describes the desired essential activity. This view shows what the solution must do to achieve the goal of the project. It improves on the What-Now by incorporating the improvements desired by the customer.

The Future-How view brings the abstract essence into the real, technological world. It shows how the physical processors (computers, humans, devices, etc.) implement the essence. It is this view that forms the basis for writing your detailed requirements.

Your scenarios start out as a trawling tool and eventually morph into a specification tool.

Resources

Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle by Ian Alexander and Neil Maiden (Wiley, 2004). This book explores the use of scenarios and provides techniques for effective scenario writing.

Writing Effective Use Cases by Alistair Cockburn (Addison-Wesley, 2000). Although primarily focused on use cases, this book provides valuable insights into writing effective scenarios for business analysis.

21

Stories

Traditionally, stories are used by agile teams to specify a piece of functionality to be developed. While they are waiting to be developed, they are assembled into a backlog. These stories are known as “user stories.” However, as we are discovering requirements, it is premature to be thinking about users. The term “user” implies that you envisage someone sitting in front of a computer, which in turn implies that you have a solution in mind. As you are in the process of discovering the business problem, it is definitely unhelpful to be thinking about the solution.

In this chapter, we show you how to make use of stories in a different way. These are not “user stories,” but stories about requirements. This is a trawling technique, so while we use the format of the user story, we’ll drop the “user.” We start by writing stories for the business events, and so we’ll call them “business event stories.”

The Business Event Story

Business events are happenings in the real world that cause the solution space to respond. Just to remind you, a business use case (BUC) is the chunk of functionality that your solution uses to process and complete the response to the business event. For example, a customer wanting to renew her insurance is a business event. The processing needed to accomplish the renewal—checking the terms, accepting the payment, sending out the policy documents, and so on—is the business use case.

So, this is where you begin to write stories—at the business event level. These are stories that are descriptors of the business use cases. As business event stories are high-level stories, there is some detail to be added later.

Some people refer to high-level stories as “epics.” However, there is no satisfactory definition of an epic apart from “a high-level story that may contain other stories or epics.” This is not useful—it means an epic could be almost anything. The definition does not provide any scope, or any boundaries to the amount of functionality it might cover.

So, instead of using this vague, overused, and imprecise term, we use the business event as the basis for our stories. You know exactly what a business event is: You know why it is triggered, where it starts, where it ends, and exactly how much functionality makes up the response to the business event. If you write a story for the business event, then it’s a story that is a bounded, independent, traceable descriptor of the solution’s response to the business event. The response is triggered the moment an external entity initiates a request and ends when the request is completely fulfilled.

A business event story is a bounded, independent, traceable descriptor of the solution’s response to the business event.

The business event story is bounded and independent in that the functionality it includes is not connected to any other business event stories. It is traceable because all the business events have one or more data flows on the context diagram, and the context diagram is where it all begins. See Figure 21.1.

Figure 21.1

The business events show on the context diagram because there are one or more boundary data flows associated with each event. The business event stories can be derived using the adjacent system and the functionality of the response to the business event. There is one story for each business event.

You have probably spotted that this bounded, traceable story is an ideal candidate for a development iteration or an implementation unit. But that’s just a bonus to come later; for the moment, we are concerned with discovering the requirements that are needed to solve the business problem.

For each business event, you write a story. It looks like this:

As a [customer segment]

I can [functionality that responds to my business event]

So that [business value].

The customer segment is the adjacent system that initiates the business event. The flow on the context diagram triggers the functionality of the story. Of course, at this stage the functionality is simply a summary description—you’ll explore it and discover its details later. However, it should be an accurate description of the functionality needed to provide the business value described in the last line.

Figure 21.2

This is an extract from the Requirements Knowledge Model, which is discussed in detail in Appendix C, Volere Requirements Knowledge Model. This part of the model shows that the scope of the work can be subdivided into Business Events, and for each business event, you write a Business Event Story. These will later be broken down into the functionality that makes up the response to the business event.

Note the scope of the business event story. It begins with the adjacent system that triggered the event, describes the response the business makes, and states the business value generated as a result. In other words, business event stories are about the business.

The business event story gives an overview of the functionality. Later, you might need to break it down in order to see its functional composition. This is illustrated by the data model in Figure 21.2.

Figure 21.2 shows entities called Functional Story, Detailed Task, and Atomic Requirement. This is the way we organize the breakdown of the top-level Business Event Story, and they are needed when you start to develop your solution. We shall come back to these in a lot more detail when we discuss story maps in Chapter 35, Story Map.

Until then, let’s stick to business event stories.

The Story Format

As mentioned above, the suggested format of a story is as follows:

As a [customer segment]

I can [some functionality that responds to my business event]

So that [business value].

Let’s look at the story elements more closely.

“As a”

As a [customer segment]

The first part of the story points at the customer segment, which can be a person, some people, a system, or an organization that receives the benefit of the story. The customer segment is also the initiator of the business event. Or to put it another way, this is the adjacent system from the context model. See Figure 21.1.

Be as descriptive as you can, and whatever you do, don’t write “As a user.” That is meaningless and gives no indication as to what the solution should be doing, who it should be doing it for, or why it should be doing it. On the other hand, “As a cargo loader” or “As a rider wanting to find a rental bike” or “As a bank customer wanting an overdraft” or “As a professional photographer” gives a clear pointer to what the story is about.

As we suggested in Chapter 6, Customer Segments, you might be using a persona for your requirements discovery. A persona is an archetypal representation of a customer segment and is intended to give a human face to the characteristics of the population of the customer segment. You might prefer to personalize the story by writing “As Alice,” or whatever name you have given to the persona representing the customer segment.

To get good requirements, you need to ask some analytical questions.

● Is this customer segment important? You obviously don’t want to spend time in the early stages developing solutions for unimportant customers. Ask if this customer segment makes a significant contribution to meeting the goals of the project.

● Does the importance of the customer segment align with the priority given to the business event when you prioritized the events during the blastoff?

● Is this customer segment the real initiator of the business event, or should you be looking at someone further away from the problem space?

● Is this the real beneficiary of the story? Or should you investigate further and find the real one?

● Do you know this customer segment well enough to know what it needs and what will be beneficial?

You might have to come back to some of these questions after you have written more of the story.

When your business event is time triggered, don’t write “As a clock.” The “As a” should cite the beneficiary. Time-triggered business events usually have to do with reports, statements, reminders, and so on. The beneficiary of these is usually the receiver of the output of the business event story.

For example, let’s say that the business event is Time to remind policyholders that their insurance is about to expire. This would happen a month before the anniversary of each policy, and the beneficiary of the event is the policyholder:

As a policyholder

I can be reminded of the expiration of my policy

So that I can renew in time and maintain continuous coverage.

Examples of other beneficiaries: Producing monthly bank statements is a staple of most banks. The customer segment in this case is the bank customer. The benefit is that the customer is updated with her financial position. A monthly (or weekly, or daily) sales report is produced for someone’s benefit. That person, or group of people, is named in the “As a [customer segment]” line of the story; for example, “As the Sales Director.”

The reason for going to a little trouble over the beneficiary is that the beneficiary must be important to the goals of the solution. This importance helps with prioritization. For example, “As the Chief Operating Officer” immediately makes the story important; “As the facilities superintendent,” not so much. Be as descriptive and accurate as possible, it helps you discover the real requirements.

“I can”

I can [functionality that responds to the business event]

Here are examples of what to write:

As a music fan

I can open an account with the streaming service

As a tax compliance officer

I can be informed of all bank customers who have made deposits over $10,000

Resist writing “I want.”

The functionality should be a description of what a solution will do to enable the beneficiary to achieve a business goal. You must also ensure that you are writing about the needed functionality and ignore how it would be done. Whatever you write on this line, ask if it is a solution masking the real need. Remember that there is a difference between a problem and a solution, and that by writing “I want” instead of “I can,” you are in danger of adding a solution to this part of the story.

Here is an example of what not to write:

As an iOS user

I want to sync data with an Apple Watch

So that I can track calories burned more accurately

Note the “I want” line. Syncing data is a solution; Apple Watch is a solution. By filling this line with a solution, the actual functionality is pushed onto the “So that” line. Tracking calories is an activity; it has a verb. However, you still don’t know why this guy wants to track his calories.

Is he trying to balance calories burned with calories ingested? If so, then this solution is not going to work. Where are his ingested calories? And what does syncing data have to do with calories? What is this “data”? It remains unsaid. This story is unlikely to lead to a solution that will satisfy anyone’s needs. And while we’re looking at it, the “As a” line is completely useless. It gives no indication as to why this story is important. Anybody with any requirement can be an iOS user.

If you delete the solution about the Apple Watch and write the following (which, incidentally, was written as part of the original story, so it appears to be needed):

I can track calories burned more accurately

tracking burned calories more accurately seems worthwhile, but more accurately than what? Perhaps we could turn it into this:

I can track my burned calories

The story would then make sense if it ran something like this:

As a health-conscious person

I can track my burned calories

So that I can ensure my daily caloric intake is balanced with calories burned.

The story is improving, and it now suggests that we can take it further. For example, is the “So that” line the real business value? If you asked why, you would find that this person is concerned about putting on weight. So, let’s rewrite the story as follows:

As a health-conscious person

I can ensure my daily caloric intake is balanced with calories burned

So that I maintain my healthy weight.

Keep in mind all the time that you are discovering requirements. Your stories are aimed at eliciting the real needs of the business problem. Revisit your stories as we did above, and ensure that the end result is a story that demonstrates an important business value.

Keep in mind all the time that you are discovering requirements. Your stories are aimed at eliciting the real needs of the business problem.

To this end, the story’s functionality should be a complete but not detailed description of what has to be done to respond to the business event. For example:

As a music fan

I can establish an account

So that I can stream music from the service.

As a policyholder

I can renew my insurance at the best available rate

As a highway patrol officer

I can be alerted if any vehicle in my vicinity is stolen or otherwise of interest

And so on. You have to work with your customer to be certain that the functionality is what is needed; in other words, you are discovering the requirements.

“So that”

Now we arrive at the most important part of the story: its rationale. Some people leave this out, and worse, some authors advocate leaving it out. Don’t. Without it, you cannot know if your story is correct or even useful. The line is:

So that [business value].

Let’s take this story from a receptionist at a busy health clinic:

As a medical receptionist

I can use any one of five different patient attributes

So that I can quickly locate any patient regardless of their means of identification.

This looks like a reasonable justification for this story. You have to talk to the receptionist and determine if it is solving an important problem. The receptionist tells you that when patients arrive, they don’t always have their patient number, but they will have a date of birth, an address, an appointment time, or their Social Security number or National Insurance number (or the equivalent depending on the country). This is a busy practice, and the receptionist needs to quickly and accurately identify people and flag their records for the doctor/nurse/practitioner. This rationale aligns with the goals of the project. It makes a constructive contribution to the eventual solution. It’s a valid story, and the rationale (“So that”) provides real business value.

We left the highway patrol officer’s story without a rationale. The complete story is:

As a highway patrol officer

I can be alerted if any vehicle in my vicinity is stolen or otherwise of interest

So that I can locate and stop the stolen vehicle as rapidly as possible to question the driver and passengers.

This provides business value to the officer, as well as to the police service (which is your customer for this project). In some cases, a business event has more than one beneficiary. For example, an insurance policyholder receives a business benefit when he renews his insurance: His insurance coverage continues. Additionally, the insurance company benefits from the revenue. You could continue this line and say that an employee of the insurance company benefits because she remains employed, and so on.

As a rule, stick to the beneficiary who receives business value directly from the outcome of the business event. If you absolutely need to, append other beneficiaries to the business event story.

On the other hand, consider this story and its rationale:

As a marketing manager

I want a content management system

So that I can manage and provide quality content and experience to my readers.

This story does not give us any real business value. Why does this manager want to “provide quality content and experience”? Surely the benefit comes when potential customers (not “readers”) respond to the marketing overture. The fact that someone is reading the literature is almost irrelevant. They might be reading it for their own amusement and have no intention of buying anything, or they are idly passing the time in the dentist’s waiting room.

The content management system is a presumed solution, and so should play no part in a requirements story. Perhaps the objective might be achieved with a content management system, but there might be alternatives that are better suited to the real purpose. Regardless, by including it in the story, the writer omitted the business value and gave the business analyst no chance to assess the importance of the story.

Presumed solutions should not be part of your stories.

It gets worse. The frivolous “So that” line spoke of quality content. This too is a presumed solution; it’s presuming that if the content is high quality, it will be more effective. This might be true, but equally might not. Additionally, would the employment of the content management system guarantee high-quality content?

And what did he mean by “quality content” anyway? You should talk to a real marketing person before specifying “quality content and experience” and determine the real business value of this story. Otherwise, you have no idea if this story makes any real contribution to the goals of the organization.

Let’s try to rescue this story by rewriting it as follows:

As a marketing manager

I can have enticing marketing material sent to potential and existing customers

So that I achieve an improved take-up rate.

Your development project is intended to produce business value. Writing stories that have no business value is pointless.

In case you’re wondering, the examples of poor stories in this book have not been carefully constructed by your authors to illustrate the points. They are other people’s stories being cited as good examples of how to write a story.

Keep in mind that you are using stories as an aid to discovering requirements. We have discussed above how you interrogate each part of the story to ensure its correctness. You can also interrogate the story as a whole. For example, you can ask analytical questions such as: “Why do you want to do that?”, “Where is the business benefit?”, “Is that really the initiator of this business event?”, and so on, until you arrive at the real business need. See Figure 21.3.

Figure 21.3

Stories are being used here to examine the problem and discover the requirements.

Stories alone are insufficient to serve as the requirements for your solution. However, they can be very useful to you in your efforts to discover all the requirements.

Figure 21.4

The stories discussed in this chapter are stories about business needs. When these are known to solve the right business problem, the developers take over and extend the business stories with stories needed for implementation reasons.

Review

Writing a story for each business event gives you a collection of high-level stories that cover all the functionality needed by the problem space. Each business event has a purpose, and this is reflected in the “So that” line of the business event story. Your analytical efforts are to ensure that the “So that” rationale describes actual business value and that it aligns with the goals of your project. Or to say that a different way, the collection of “So that” justifications delivers the goal of the project.

Once the business event story is accepted, you dig deeper into the details of the functionality for the event. This means that you have to do some trawling—workshops, interviews, process models, stored data, and so on—to uncover the atomic requirements. Later, the developers add technological requirements to your business requirements (see Figure 21.4). Following chapters look at these topics.

For the moment, concentrate on the business event stories. If these accurately define the business outcome of the event, then they are the foundation for what is to come. By getting these stories right, you give yourself every chance of delivering the correct, most valuable solution.

Resources

User Stories Applied: For Agile Software Development by Mike Cohn (Addison-Wesley, 2004). The author is concerned with writing “user” stories aimed at agile development. However, his knowledge of stories is worth pursuing.

Agile Alliance (https://www.agilealliance.org). This organization provides resources on topics from user stories through articles, webinars, and conference materials.

The Mountain Goat Software Blog (https://www.mountaingoatsoftware.com/blog). Mike Cohn’s blog contains valuable insights and articles on user stories.

22

Business Process Models

Business process models demonstrate a set of activities that together achieve a business objective. Business process models can be in a number of forms—for example, UML activity diagrams, BPMN diagrams, data flow diagrams, or flowcharts. What you use or call them doesn’t matter. It’s what you do with them that matters.

If you are familiar with process models, skip ahead. If not, take a look at the simple process model depicted in Figure 22.1. The process model shows the business activities—each one a recognizable chunk of functionality—and the sequence in which they are organized to achieve the goal.

Figure 22.1

An example of a process model from DC Comics

Process models are a tool to help you find requirements. Once you have drawn your process model and agreed on it with the customers and stakeholders, you can readily derive your requirements or stories from it. The activities on the model provide a suitable amount of functionality to qualify as a story. Or if you are writing detailed requirements, you can extract them from the relevant activities on the process model.

As Figure 22.2 shows, you can use process models in various situations. They are useful for prototyping when you want to show the functionality of a candidate solution. They are used in the Trawling activity when you might want to model the current state of the work under study or you’re proposing some future process to your customer. Solution designers might also use process models to illustrate how their design achieves its purpose.

Figure 22.2

Process models are used in several of the requirements discovery activities.

Process models are a tool to help you discover the right requirements and/or stories. And as we mentioned above, you can derive your requirements and stories directly from the process model. In some cases, with willing developers, you might be able to develop the needed software directly from the process model.

Our approach to process models for requirements work is an informal one. We have no interest here in formal process models using elaborate notation. Process models for the business analyst are quick sketches aimed at eliciting information. Let’s start by looking at their notation.

Notation

Before we go too far, we should warn you not to get involved in notation wars. Sometimes people get very passionate about issues such as whether and how to show data, whether a process should be a circle or a rectangle or a rectangle with rounded corners, how conditions should be shown, and so on. You’re a business analyst; your process models are for you to communicate with. As long as your customer and other stakeholders understand your diagrams in the same way, you’re using all the notation you need.

However, it is useful to know that there are two popular notations: Unified Modeling Language (UML) and Business Process Model and Notation (BPMN). You can use either to document, or invent, a business process. BPMN has the most comprehensive modeling vocabulary, but you should only use a minimal subset—just as much as you need to communicate with the stakeholders. BPMN and UML, when used in a cut-down form for trawling purposes, are not that dissimilar. Use whatever subset of either notation works for you and your stakeholders.

You should be sketching your models, so hand-drawn diagrams are all that are needed. Please don’t spend time and money on one of the dedicated apps for drawing these things. You need nothing more than a pencil and paper, or a whiteboard, virtual or real. We propose that you draw the models as you’re talking to your customer, your team, and other stakeholders.

Activity Diagrams

This is a quick introduction to basic activity diagrams.

Figure 22.3 shows all that you need, probably more than you need, in a UML activity diagram.

Figure 22.3

The basic notation of the UML activity diagram

In Figure 22.4, note the initial icon called the “start event.” This is the happening that triggers the process—it is in fact a business event. This is convenient, as most of the time you draw a process model of a business use case, or the response to one business event.

You probably won’t use much of the notation shown in Figures 22.3 and 22.4. We want you to know that the notation is there, but we will use a subset for our examples.

Figure 22.4

A subset of the BPMN model

Data Flow Diagrams

Data flow diagrams are the simplest and most natural and minimal notation to show business processes.

The data flow model differs from other process models in that it shows the data that is input and output from each activity. Including the input and output from a process guides the person creating the diagram into a more “natural” functional partitioning. The activities are natural in that they are whatever is required to transform one piece of known data into another.

The example shown in Figure 22.5 repeats the airline check-in process we discussed in Chapter 20, Scenarios.

Figure 22.5

A data flow model of the airline check-in process that was shown as a scenario in Chapter 20

The notation of the data flow model is this: Around the periphery are the adjacent systems that you first saw in the context model when we were discussing scope in Chapter 5. They are exactly the same when used here. The activities are shown as circles. The arrows represent flows of data between the activities; the name attached to each data flow indicates the contents of the flow.

The other notation is the parallel lines enclosing stored data. Stored data can be either a complete database or individual entities/classes from your data models. For reference, the notation is shown in Figure 22.6.

Figure 22.6

An overview of the data flow notation

We encourage you to draw data flow models one business event at a time. However, when there is a need to show a wider business area, perhaps the entire problem space, the data flow model works very well. You would possibly want to do this when looking at the How-Now or “As is” view of the work in order to establish the starting point and help define the scope.

Figure 22.7 shows an example of looking at the wider scope.

Figure 22.7

A data flow model illustrating the full extent of a problem space

Data flow models are very business friendly, and we believe that the addition of recognizable data flows helps stakeholders have a rapport with your models of their work.

Business Events and BUCs

Business events are an important idea, and we have spent some time discussing them. The advantage of combining business events and process modeling is that the business event gives you well-defined start and end points for your models.

In Chapter 20 we looked at scenarios, and you saw the example of an airline passenger and his bags being checked onto a flight. Please refer back to that scenario if you wish and compare it with a process model of the same business use case in Figure 22.5. Consider your stakeholders and consider what you need to communicate. In some cases, a scenario would be preferable, and in others, a diagram will best convey the needed information. A scenario can be more detailed, but in some cases, the higher level of abstraction that a diagram provides is preferable. We leave it to you to experiment and decide which form of representation is most appropriate for the situation.

Figure 22.8 shows the business use case where the passenger checks onto a flight. It is triggered by the passenger arriving at the desk, bringing with him the data needed to check in. It ends when the outcome of the BUC has been achieved. That is, the passenger and his bags are successfully checked onto the flight. It means that all the data has been processed and the needed parts of the data have been stored, the outputs—boarding pass, bag tags—have been produced, and there is nothing left for this BUC to do.

Figure 22.8

An activity diagram showing a passenger checking in for a flight. This is the equivalent of the scenario and the data flow model shown previously.

In Figure 22.8, note the swimlanes, the dotted lines that divide the work between the participants. Swimlanes are optional, and they are a double-edged sword. They provide a clear explanation of who is doing what in the current implementation—the How-Now view. However, it is highly likely that different processors will be used in a future solution; in which case the swimlanes can be misleading. And they must never be taken as a constraint. They are there to explain the current work and must not be considered unchangeable. We suggest that when you are modeling the essential view—What-Now and Future What—you omit swimlanes.

The activity diagram shows parallel processing. For example, the Check Bags and Print Boarding Pass activities can be performed at the same time. The black bar shows the point at which processing can be split and become parallel. This is called a fork node.

The activity diagram also shows a join node—the second black bar on Figure 22.8. This symbol means that all processing must reach this point before proceeding. In the case of the airline check-in, the entire process cannot end until both the bag tags and the boarding pass have been printed.

Diamonds can be used to denote decisions, just as they are in traditional flowcharts. We tend to leave them out where the conditions are obvious or can be shown by attaching guard conditions (the words in brackets at the exit of an activity). When using activity diagrams during requirements work, simplicity is more useful than correct and complete use of the notation.

When to Use Process Models

The short answer is whenever you like. A better answer is that whenever you are discussing a business process, you should consider sketching a process model.

When You Are Getting Started

Suppose your customer sells a product that is quite specialized. Your client’s customers make customized orders. You could start with a very simple process model, as shown in Figure 22.9.

Figure 22.9

This was sketched early in the project as a high-level model to illustrate the business flow.

The activities in Figure 22.9 are high level—they simply group the detailed processing into useful chunks. A high-level model such as this is used to start the discussion with your stakeholders. The first activity, Customize the Order, is a human activity where Kevin and the customer decide on the customization of the product. The activity is annotated to indicate that it is a human activity. This is a complicated activity and will need some trawling to see if it could be improved. Fulfill the Order and Shipping are both to be done by ready-made components. This is flagged by the addition of the “out of the box” symbol. Finally, Hesta in accounting does the billing manually.

The two activities to be done by the ready-mades do not have to be specified in detail (you can think of them as black boxes), apart from any configuration and the data interfaces into and out of them.

This model would be used by the requirements discoverer to get an agreement from the client that this is the correct response to the business event Customer wants to place an order, and to highlight the areas where further investigation is needed.

When You Are Prototyping with Models

Prototyping, as we use the term for requirements discovery, is building a number of candidate solutions. These are probed and explored to determine if they solve the right business problem. We discussed prototyping in earlier chapters.

Let us say that your client is a fashion retailer and wants to have an innovative way for her customers to shop, one that will attract younger, more trendy shoppers. Now let’s say that you and your team brainstorm candidate solutions. So that you can discuss them and show them to your client, you sketch process models such as the one shown in Figure 22.10 as part of your prototyping sessions.

Figure 22.10

A sketched candidate prototype using a process model

You have annotated your process model with some figurative elements to make it potentially more attractive and understandable to your client. You could use this model to explain to your client that the clothing displayed in the store is currently grouped according to designer, as it is in many large department stores. As a result, a shopper in one designer’s area would not know what was available in other areas. This solution allows shoppers to be made aware if there are alternatives to the item they have picked off the rack. Perhaps the idea of a robot delivering clothing might be a little bit startling to a shopper, but then, it might be fun to have a friendly robot following you around the store carrying the clothing you have selected so far.

You would discuss and argue these things with your team and your client, changing the process model as needed, and probing it to ensure that this candidate is viable. Keep in mind that this process model is a prototype. If it doesn’t work out, you discard it and go on to the next one.

When You Are Doing How-Now Modeling

One of our clients, a medical insurance organization, realized it had grown so quickly that it lost control of its internal business processes. Members of each department were more or less making up their processes as they went along and building ad hoc software to suit themselves. This resulted in very little coordination between different departments, and soon enough, management realized the business was inefficient due to its tangled and overlapping processes.

We started by having the people who worked in different departments sketch process models of some of their most important processes. These models were depictions of what existed at the moment—the How-Now view.

When they brought these models together, it became obvious that there was a lot of redundancy due to different departments duplicating some—quite a lot, actually—of their business processes. They used the models to put together a What-Now view—the essence of the business. The duplication and overlap were eliminated, and data that could be shared was centralized. The resultant set of essential process models was then used as the basis for further improving and then reimplementing their systems.

Review

Process models are a trawling tool that are at their best when proposing, documenting, or demonstrating a business process. Much of your analytical work has to do with business processes: what has to be done when a student wants to register at a university; what activities are needed when a cargo agent needs to book an air shipment; and so on.

A process model gives you a graphical way to show a business process to your stakeholders. The diagramming notation is not so complex as to be daunting to those unfamiliar with it. Which is, by the way, why we have been urging you not to become involved with the rich language of BPMN and UML and to stick to a basic subset that uses only a few symbols.

We spoke about process models back when we were discussing prototyping. A process model can be a great way to demonstrate a proposal. After all, your prototypes are candidate solutions, which are almost always a business process.

Process models also play a part in process improvement. By building a graphical model of an existing process, it becomes easier for your stakeholders to locate the chokepoints, redundant activities, and inconsistencies.

The ability to see the process laid out in graphical form also makes it easier to see the essence. For each activity on a model, you ask why. Why is this process here? What does it contribute? Is it part of an essential policy, or is it there for some technological or organizational reason?

Finally, there is communication. Once your stakeholders become familiar with, or at least unafraid of, the diagramming notation, you can demonstrate and communicate more fluidly. Showing your client an essential process model and using it to explain a proposed new way of working brings clarity to the conversation. Sure, you need words to fill in the details, but the model provides the road map for your communication.

Resources

BPMN Quick and Easy: Using Method and Style. Process Mapping Guidelines and Examples Using the Business Process Modeling Standard by Bruce Silver (Cody-Cassidy Press, 2017). As the (rather long) title suggests, this is an entry to BPMN, and also provides style rules for building your models.

Learning UML 2.0: A Pragmatic Introduction to UML by Russell Miles and Kim Hamilton (O’Reilly, 2006). This demonstrates UML and describes how to draw UML models. The activity diagram is the one you would use most. The book also discusses how to use UML as a prototyping tool or during the Trawling activity.

There are also endless online resources for UML and BPMN.

23

Stored Data

Every organization, every solution, every system stores data. Your phone (a solution) stores data: Your phone numbers are data, your messages are data, your banking app stores data, your to-do list is data, your calendar, your settings, your notes … the list is endless.

We process data all the time. When you make a payment using a card, phone, or watch, you are processing data. The data representing your money is moved from your account to the recipient’s account. When you look at your card statement, you are looking at stored data that has been processed and stored for every transaction in the past month.

Data is all around us; it is part of every problem space and solution. Knowing more about it helps you learn more about the processes that surround the data, as well as the requirements for the processes and the data.

Data and process are joined at the hip. You can’t have one without the other. There is no such thing as data that is not processed; there is no process that is not processing data. Both have requirements, which is what we are interested in here.

Before going too far into this, we have to say that the business analyst is not designing a database. The business data models that we are discussing here are input to the database design process, but for the moment, let’s talk about the business data.

As we are concerned only with business analysis, we shall stick to modeling the essential stored data. Also, because we are concerned with business analysis and requirements discovery, we are using a simplified notation for our data models. You will also come across class diagrams (from UML), entity relationship diagrams, and other notations. By all means use those if your company so decrees, but the models you see here are sufficient for your trawling.

When you are trawling, you are usually trawling for business processes. All processes use data one way or another, so discovering the data is a way of discovering the processes. Alternatively, discovering the processes also discovers the needed data.

Let’s look at stored data and how it is connected to requirements.

Data Models

Data models are an abstraction of the real world. A data model is made up of entities that reflect real-world things. (You can use the UML term “classes” if you prefer.) In the real world, things are connected, so the data model shows relationships (associations in UML) between the entities. For example, you have a bank account—a thing—and it is linked to your debit card—another thing.

These things can be represented by data. The debit card has a number, your name, expiry date, CCV, and so on. These data items—we’ll call them attributes—belong to an entity, which naturally enough you would call Debit Card. Your bank account also has an identifying account number, account balance, and so forth. Because it is a thing that is uniquely identifiable, it too is an entity. When you buy something, the transaction must be recorded (another entity) so that the transaction amount can be debited from your bank account.

If you are trawling this business, the aforementioned things become entities on your data model.

Entities don’t stand alone; they are linked to other entities by relationships. Relationships represent some real-world associations needed by the business. These relationships are established by business processes. For example, when your bank issued you a debit card for your account, it established the relationship between the card and the account. When you use your card to buy something, the transaction has to be linked to your card and your bank. Figure 23.1 shows the resultant data model.

Figure 23.1

Three entities and the relationships that model the activity of your debit card

The big deal about data models is that by trying to build one for the data stored in your problem space, you have to discover the data entities and how they relate to each other. It is by questioning what the data is and how the pieces are linked that you discover more about the business you are investigating.

Let’s look at an example. Some countries are introducing charges for heavy trucks using their highways. This is beginning to happen in European countries, but it is a possibility for some cash-strapped states in the United States to raise a little revenue from trucks driving through interstates within their borders. The countries or states do not want to install toll barriers—barriers slow down traffic. Instead, they probably want some electronic sensing system to detect trucks on their highways.

Let us say that you are trawling this piece of business to find its requirements. These requirements will eventually be used to construct a (probably automated) solution.

What entities spring to mind? Truck is an obvious one, as is Road. You need these two because you are charging the truck for using the road. The entities on the data model are not themselves data—they have no alphanumeric value—but they can be thought of as “containers for attributes.” Attributes are the individual items of data that have an alphanumeric value: a date, an amount of money, a name, the price of something. Each attribute must belong to its relevant entity. You can’t have an attribute of, say, credit card number, in an entity called Stock Item.

The entity Truck would have attributes including the license plate number, the country or state issuing the license plate, the type of truck, its weight, and so on. This entity on your data model represents not just a single truck, but all the trucks that may use the roads. This is why the word “class” can be used to refer to entities; it’s the class of the thing of which there are many instances. Because there are many of these things, each one must have a unique identifier. In this case, the license plate together with the country or state of issue identifies an individual truck. By the way, you need the state or the country as part of the identifier, as it is not beyond the bounds of possibility that a plate from one state could have identical characters to that from another.

The next data entity to represent a real-world thing is the Road. The Road would have data attributes such as a road identifier—Interstate 70, county road 57, European or national road numbers —and some geographical data, permitted uses, and so on. The road identifier is needed because there are lots of roads in the problem space.

Now we have to link these two things. However, they don’t directly relate to each other for the purpose of this business. Sure, a truck can drive on a road and a road can carry a truck, but the business charges for each instance that a truck uses a road. This means we need another entity, this one a conceptual or intangible one, which we call Journey. See the partial model in Figure 23.2.

Figure 23.2

The partial data model reflecting the narrative of the business as we have it so far

There is more of this model to come, but let’s pause here and consider what we have. Keep in mind that we are trying to understand a business and find its requirements by building a model of the data that it stores.

So far, we have three entities on this model; Road and Truck are obvious. The third entity, Journey, needs some explanation.

A truck will drive along many roads, and a road will carry many trucks. When you investigate the business, you find that it needs to keep track of which truck drove along which roads. This is data and thus needs an entity to store it, so you create the Journey entity to contain it. Naturally enough, there has to be a new instance of Journey created whenever a truck drives on a road.

The lines between the entities represent the relationships (associations in UML terminology) between them. Note the characters attached to the relationship line: “1” means a single instance, and the “*” means many instances of the entity.

An instance of Journey can belong only to one Road—you can’t be simultaneously using several roads—whereas over time a road will experience many instances of Journey. An instance of Journey can only be created by a single truck, but the truck will use roads many times, and for each time there must be a new instance of Journey to record that particular usage.

To show this you put an “*” at the Journey end of the relationship, and as there can only be one Truck making an individual journey, you mark the Truck end of the relationship with a “1”. Similarly, an instance of Journey can only be made on one Road, but a Road will be used many times, so that is tagged with a “1” and a “*”. It’s easier to call this a “one to many” relationship. These cardinality (or multiplicity) notations are there to tell you a little more about the business.

Let’s get on with the requirements for this piece of work. The data model and the business policy are mirrors of each other. To carry out the policy, any business needs data. You can find functionality by finding the data, or having found some data, determine the functionality that uses it.

You interview the road authority and ask about their business policy for charging for a Journey. Do they charge for the distance a truck travels on a road, or the time spent on the road? Does the weight of the truck come into the charging calculation? Does the truck’s cargo affect the charge?

The answers to these questions bring a need for data.

The road authority tells you that they intend to charge for the distance traveled on a road, which is probably the most viable way to do it. However, roads can be very long—hundreds or thousands of miles/kilometers—and a truck might not traverse the full distance. Ideally, you would charge the truck from the exact point it entered the road to the exact point it left the road. However, to monitor every possible entry and exit from a highway would be prohibitively expensive and problematic. The stakeholders tell you that there are already gantries (or overhanging signs) erected across roads to provide signage—distances to cities along the way, upcoming exits, traffic conditions, and so on. As these exist, they have known geographic locations, and it is probably feasible to add scanners to monitor truck activity. This means the gantries can be used as checkpoints for measuring distance. It is not as precise as entry/exit monitoring but is deemed to be good enough. A scanner every 50 miles or so would be sufficient.

Now we need more data, specifically about the Gantry. When a truck passes its first gantry it establishes a new instance of Journey, which is attached to the Gantry entity. As the truck passes subsequent gantries, they too are attached to the Journey entity. This continues until the truck stops passing gantries and the distance traveled can be calculated. Figure 23.3 shows the revised data model.

Figure 23.3

This version of the data model introduces the gantry. Gantries have scanners attached to detect trucks. The gantries are needed to determine the distance of a truck’s journey on a road.

The data model is mirroring the business policy. It also gives you requirements. For example, there is now a requirement to establish the gantries in the solution. There will in fact be a new business event to establish a gantry, and another to delete it, change it, and so on.

Similarly, the data attributes of Journey need to be used (you cannot have data that is not processed, just as you cannot have a process with no data). The attribute Distance Traveled is the basis for charging. From the relationships, you know which truck made the journey and which road was used. This information is used to send out an invoice. Your solution must retain a history of the invoices, so more stored data in the form of another entity is needed. This one is attached to Journey because that is what you are billing for.

You are discovering requirements, either by deriving them from a data model or by using the data model to drive your discovery. Let’s question the cardinality of the relationship between Journey and Invoice. Is it—reading left to right—one to one, meaning that one invoice is sent for one journey (i.e., as soon as the truck’s journey has ended, an invoice is generated)? Or is the cardinality many to one, meaning that one invoice is sent for a collection of all the journeys a truck made within a billing cycle? You go back to the stakeholders to discuss this. It’s an issue you have to resolve, as it would be easy to presume the wrong approach. You write your requirements for whichever approach is selected.

Then we have the problem of the invoice—who exactly is invoiced? You can’t send an invoice to a truck, so presumably it must go to the truck’s owner. Now it becomes more complicated. Some—probably most—of the truck owners are large haulage companies and have many trucks. Should the authority send an invoice for each journey, or for all the journeys the owner’s trucks have completed in the billing cycle?

Consider the data model as it is shown in Figure 23.4. This represents what we know so far on the business policy and the data needed to support that business policy. If the road authority had wanted to charge for the weight of the truck, then more data would be needed as an attribute of the Truck entity. Additionally, if the truck’s cargo influences the road-charging calculation, we would need another entity called Cargo with a relationship with the Truck.

Figure 23.4

The completed (so far) data model of the road-charging business

But let’s leave it here. The point of the exercise is that you can discover the stored data and the functionality needed to process that data at the same time. And discovering one helps you discover the other.

You can discover the stored data and the functionality needed to process that data at the same time. And discovering one helps you discover the other.

Business Events

Business events are significant to the data model because it is business events that bring data into our solutions, and then later process the data and send it to the outside world. These flows of data into and out of the business area are shown on the context model (see Figure 23.5). Each flow on this model is connected to a business event.

Figure 23.5

The context model for the road-charging problem space

This is a simplified view of this piece of work; the real thing is much more complicated. However, this will suffice for our purposes.

An important business event occurs when a truck passes a gantry. We can assume that the gantry scanners have license plate recognition technology to identify each truck as it passes. This business event triggers the incoming flow Truck Detected, the data of which would include the truck license plate number, the time the truck passed the gantry, and probably more. The response to this business event is to create a new instance of the Journey entity, or to update the Journey entity if one had already been created by the truck passing an earlier gantry on this road. The Journey entity is linked to the Truck and Gantry entities. These will later be used to calculate the invoice.

The business cannot magically know about trucks, so the trucks have to be registered. This is another business event that establishes the Truck entity and connects it to the Owner. This ownership needs to be established if the business is to send the right invoice to the right owner.

Another business event would establish a new owner, and so on. Following is the list of business events derived from the context model, in no particular order:

Owner wants to open an account

Owner wants to register a truck

Truck passes a gantry

Time for invoices to be sent

Road Maintenance builds a new road or changes one

Road Maintenance installs a scanner in a gantry

Hang on to that for a moment while we look at the CRUD check.

CRUD Check

The CRUD check—Create Read Update Delete—is used to ensure that you have all the business events, and that all the data entities are relevant and correctly used. It works like this:

Every entity must be Created. They don’t magically fall out of the sky; they have to be created and it takes a business event to create one. Creating an entity makes no sense unless it is used, so there must be at least one business event to Read the entity. Some of the entities are Updated (by business events) and some might be Deleted (also by business events). So, we are using the entities from the data model and the business events to build the CRUD table.

At this point, let’s take a small diversion.

You don’t have to build the data model to find the entities. As previously mentioned, an entity is something that is identified. It is also a thing that itself has no alphanumeric value, but attributes of data with values are attached to it. This means you can make a list of the entities by looking for things in the problem space that are identified and about which data is kept. For example, an account always has a unique account number. A truck has a license plate and state of issue, which uniquely identifies any truck. Roads have numbers and the authority has data about them. All these things are entities, and you can build a CRUD table by simply listing them. End of diversion.

Next, you populate the CRUD table by listing all the entities in the first column. Then, ask what business events process it. All data must be processed in one way or another, so you’re asking which business event creates, reads, updates, or deletes that entity of data.

Figure 23.6 shows a populated CRUD table. It uses the entities from the data model shown in Figure 23.4 and the business event numbers from the list above.

Figure 23.6

The CRUD table showing the entities and the business events that create, read, update, or delete them. This table is complete with what you know to date. As you progress with your investigation, you will fill in more of the table.

The CRUD table is a check of the completeness of your knowledge to date. Its purpose is to find any missing business events and data entities. For instance, the table shows that the Account entity is created by business event 1 when an Owner wants to open an account so that her trucks can legally use the roads. It is read by business event 4 when it is time for the invoices to be sent.

We have intentionally omitted the housekeeping business events. These are things like Owners changing their details—address, company name, and so on. We have left out all the deletions—a gantry is removed, an account is closed, a truck is taken out of service, and so on. These are omitted to make it easier for you to see what is happening by not having cluttered models. But you can expect your models back at work to be more cluttered.

If you look through the table, you can see the combination of business events and data entities that complete the work of this piece of business. Or not quite. Note that there are some blank cells on the table. These indicate that something is missing.

For example, the Invoice entity is created by business event 4, but there are no other events that use it. Data that is created should be read; otherwise, it has no purpose. In this case, the lack of a read business event can be explained if there is another solution—say, an adjacent accounting solution—that uses the Invoice entity. Otherwise, the blank cell would indicate a missing business event.

The Gantry entity is neither updated nor deleted—we said we have omitted the housekeeping events. The Journey entity is updated by business event 3. This is the business event that happens when a truck passes a gantry. The business use case responding to the event calculates and updates the Distance Traveled attribute.

And so, you work through the CRUD table. You’re looking for entities that are not read, updated, or deleted. If there is not a business explanation for this, the explanation is that you are missing a business event. If there is an entity that is read without being created, then the explanation is certainly a missing business event. By the time you have worked over the whole table, you can be certain that you have all the events and all the data.

Review

The world sometimes seems to be divided into two kinds of business analysts: those who model process and those who model data. But there is every reason why you should become an analyst who models process and data and, ideally, does it in parallel.

Data models are revealing. The stored data of a piece of business reflects its business policy. You store data because you need it to run the business, and the data is stored, read, updated, and deleted by business processes. These processes exist because of the business events that the business responds to. Data is brought into the business by the triggering data flow belonging to a business event and leaves the business on the outgoing flow of a (usually time-triggered) event.

You can look at a data model and ask what business event creates, reads, updates, or deletes this entity. Alternatively, you can look at the data attributes of data flows connected to business events and ask what entities of data these belong to.

Data entities represent the things that are important to the business. Anything that is uniquely identified or has data stored about it is important and so becomes an entity on your data model. The relationships between the entities are determined by the processing done by the business. That is, whenever a business event happens, the responding BUC will form or update a relationship. To do this, it will create and/or read the entities that it is linking.

When you come to build or buy your solution, it requires stored data to support its functionality. This probably means a database. The business data model we have been discussing here is a conceptual model. However, it shows the necessary data, and that makes it the foundation of the database design. The database designers take your conceptual model and add the technological pieces to turn it into a database design. However, database design should not influence the way in which you see the business’s stored data. Your model is of the essential data needed to support the business activities, and you are using it for requirements discovery.

Resources

Data Modeling Made Simple: A Practical Guide for Business and IT Professionals by Steve Hoberman (Technics Publications, 2009). Hoberman is an engaging writer and his take on data modeling is both straightforward and comprehensive. He shows you how to model data and, importantly, when and why you should.

Data Modeling Essentials by Graeme Simsion and Graham Witt (Morgan Kaufmann, 2004). This is the third edition of this popular book, and it takes you through the basics and theory of data modeling, discusses the stages of applied data modeling, and addresses advanced subjects including business rules.

Any of the books on UML discuss the class diagram. This is UML-speak for data models.

24

Other Trawling Techniques

We have been looking at different methods of trawling for requirements. You will use some of these methods a lot, most noticeably workshops, scenarios, and process models. There are also other techniques that are equally useful but that do not need an entire chapter to themselves.

The task of discovering requirements needs a certain amount of flexibility. If one technique is not working for you and your stakeholders, then switch to another. Use several at the same time. Additionally, some approaches are more appropriate to different circumstances. We advise you to have a well-stocked toolbox so that no matter what the target, you always have the appropriate tool.

Two very important tools are the ones on either side of your head. Listening is where you learn the most, provided you’re listening and not just hearing. Listening is caring about what is being said and listening beyond the words to the sometimes-unspoken essence of the conversation. And of course, that gray thing you have between your ears is equally important.

Another useful tool is “Why?” Asking why repeatedly is one of the most effective ways to discover requirements. It is only by arriving at the underlying—and often unspoken—essence of the problem that you are able to discover the right problem to solve and the right requirements to solve it.

There are other practices that are useful for requirements discovery. However, these are practices that are not often used but people have written whole books about them. We feel it is beyond our remit to try to deal with these things exhaustively here—things such as ethnography, or studying the situation through close observation of the participants, seeking to understand their motivation; family therapy, or understanding that you don’t have to get people to agree with each other, but you do have to get them to communicate with each other (we could use a lot of that in our legislatures); the Soft Systems methodology; systems thinking; psychology; and more. These are soft sciences, which are hard to describe and learn but can be useful when the problem is complex and its participants are unsure. Most of these are referenced in the Resources section at the end of the chapter.

What follows are some techniques that are not so soft and that at some stage will be useful to you.

Apprenticing

Apprenticing—based on the old idea of masters and apprentices—is a wonderful way to observe and learn the work as it really happens. In this case, you are the apprentice, and the user of the current solution assumes the role of master craftsman. You sit with the user at her place of work, learning the job by making observations, asking questions, and perhaps doing some of the work under supervision. This technique is also sometimes known as “job shadowing.”

Apprenticing is particularly useful for in-house work. The underlying assumption for apprenticing is that users are currently doing work, and you, as the business analyst, have to understand their work and the purpose behind it. This work could be clerical, commercial, graphic arts, engineering, or almost anything short of brain surgery.

It is unlikely that many users, sitting in a conference room or on a remote call, can explain what they do in enough detail for you to understand the work and thereby capture its requirements. When users are away from their work, they tend to generalize. While generalizations can be useful, they do not provide all the detail you need for your requirements discovery.

“ Nobody can talk better about what they do and why they do it than they can while in the middle of doing it. ”

—Hugh Beyer and Karen Holtzblatt, Contextual Design: Defining Customer-Centered Systems

Nor can you expect users to have the presentation and teaching skills needed to present their work effectively to others. Conversely, almost everyone is good at explaining what they are doing while they are doing it. Apprenticing cannot take place in high-security environments (unless you have the appropriate clearance), nor will it be effective in very high-pressure, busy situations like air traffic control.

Most of the time you are talking to people in normal offices and workplaces. It is here that a user can do a running commentary of the work as it happens, and that commentary provides the details that might otherwise be lost. While she is working, the user can describe her task precisely and tell you why she is doing things. If the explanation is not clear, the apprentice (that’s you) asks questions: “Why did you do that?” “What does this mean?” “How often does this happen?” “What happens if this piece of information is not here?” You also get to see the things that can go wrong, the special cases, and the workarounds she uses when things are not normal. Through the process of apprenticing, you come to see all the cases and the actions the user takes for each of them.

Apprenticeship can be combined with modeling. As you observe the work and the user explains it, you sketch a model of the tasks and their connections with the other tasks (see Figure 24.1). As you build your models, you feed them back to the user and confirm that they are correct. You use this feedback to raise questions about any areas of uncertainty. These models would certainly be about the How-Now, but they might well serve as the starting point for envisioning the future, improved solution.

Figure 24.1

The requirements analyst learns the work while sitting at the user’s desk, sometimes building models of the work while learning it.

When you are apprenticing, you are an interpreter as well as an observer. When you are looking at the current work, you must abstract away from what you see to overcome the user’s close connection to the physical incarnation of the work. In other words, the artifacts, the technology, and other inputs that are currently used must be seen as a product of a previous solution designer. But times have changed. Today it may be possible to do things in ways that were impossible yesterday. Better ways may now be available that take advantage of up-to-date technology, ways that use streamlined processes, ways that simplify the work or automate some or all of it.

But first you have to abstract. While you are learning the work by seeing it done in real-world conditions, you are abstracting from the current technology to find the underlying essence of the work. We looked at essence a little earlier, and if you need a refresher on finding the essence of the business, feel free to divert back to Chapter 16, The Essence of the Problem.

Needless to say, apprenticing is about finding the real problem that your future solution should solve.

Interviewing

Interviewing is used by almost all projects, as it is really a part of all elicitation techniques. Despite its omnipresence, we suggest that you do not use interviewing as the only way to discover requirements. Rather, you should conduct interviews in conjunction with the other techniques discussed in this chapter and elsewhere.

Interviewing the stakeholders is a technique that is commonly employed but is not without its problems. Just as with apprenticing, the interviewer relies on the interviewee to know—and be able to verbalize—knowledge of the work. Interviewing may work very well when people are knowledgeable about their work, but that knowledge is often restricted to their own immediate area. There are likely to be few people in the organization who understand enough of the business to be the sole person to describe it for you.

Some business analysts draw up a questionnaire and send it to the stakeholder in advance of the interview. While this preparatory step gives some structure to the subsequent interview, we have found few stakeholders who are motivated enough, or who have time enough, to fill in a questionnaire prior to meeting the analyst. We suggest that you send a brief agenda listing the topics that you wish to cover in your interview along with the planned duration of the interview. This notification at least gives the stakeholder a chance to think in background mode, to have needed material close by, or to ask subject-matter experts to be present.

Stakeholders should not remain completely passive while being interviewed. Instead, you must involve them by building models—process models, scenarios, and so on—during the interview. This approach of creating something visual provides a feedback loop between you and your stakeholders, and it means you can test the accuracy of what you are being told.

Feed back your understanding. Build models while you are interviewing the stakeholder.

Try these guidelines to make your interviews more effective.

● Set the interview in context—explain the scope of what you wish to cover. This step is necessary to avoid the stakeholders talking about something irrelevant to your purpose. It also gives them a chance to withdraw gracefully if they have not prepared for the interview.

● Limit the duration of the interview to the time stated in the agenda. We find that interviews running for more than an hour (90 minutes tops) tend to lose focus.

● Use business use cases as an anchor for the interview. Stakeholders recognize business use cases (although they may not necessarily call them by that name), and it makes for more directed conversations if you talk about their work one business use case at a time.

● Ask a question (more on this in a moment), listen to the answer, and then feed back your understanding.

● Draw models and encourage the customer to change them. There are plenty of models you can use to help you communicate your understanding of a process—for example, data flow diagrams, activity diagrams, and rich pictures. You can also construct data models for information and mind maps to link different subjects. (Rich pictures are covered later in this chapter; there is a citation for mind maps in the Resources section.)

● Use the stakeholders’ terminology and artifacts, both conceptual and real. If the stakeholders do not use their own language, then you force them to make technological translations into terms they think you will understand. Sadly, this usually leads to misunderstandings. By contrast, if you ask questions about their terminology, you inevitably make new discoveries.

● Thank the stakeholders for their time, and tell them what you learned and why it was valuable. After all, they have lots of other things to do. Talking to you is not the reason they are employed, and they often view the interview as an interruption to their work.

● Write down what you were told. We guarantee you’ll have more questions.

Asking the Right Questions

Let’s look at this by using an example. Say that you’re working on a project to build a solution to manage the deicing of roads in winter. (You saw this project in Chapter 7, Business Events.) The solution must involve a network of weather stations that sense temperature and pressure. Let’s say that you are interviewing the chief engineer.

The business event you want to explore this time is Road engineering installs a new weather station. Your questions should focus on what the work does to respond to this business event.

Business Analyst: “What happens when your engineers install a new weather station?”

Chief Engineer: “They let us know where the new weather station is located, and we keep a record of it.”

BA: “How do you keep this record?”

CE: “I’ll show you the spreadsheet that we use.”

BA: “Thank you. I’d like a copy of it, if possible. I see that you keep track of the weather station number, geographical coordinates, and installation date. What else do you keep track of?”

CE: “We have another computer system where we have the maintenance history for each weather station. There are some double entries, but that’s the way it is.”

BA: “Is there any data you record that you don’t have any use for?”

CE: “Yes, we record information about the crew that installed the station and how long they took to do it. Nobody ever looks at that. It’s a hangover from earlier days.”

BA: “Are there any other facts about the weather station that would be useful to you?”

CE: “Well, we would like to know the manufacturer and performance of each weather station.”

BA: “What do you mean by performance?’

CE: “Which weather stations need the most maintenance. This would help in planning which new technology we spend our budget on. However, we’ve never been able to do that in the past.”

BA: “Would it be acceptable to you if you had a new system that integrates all the information about the weather stations, their maintenance, and their performance?”

CE: “What, you mean all on one screen?”

BA: “Possibly. It would be something that makes it possible for you to track a weather station and its lifetime performance.”

CE: “That sounds great, but I’d have to check it with some of the engineers.”

BA: “Well, once I’ve made sure that I have all the facts about the weather stations properly defined, then I could do a quick mockup to show the engineers our ideas. How would that be?”

CE: “I like the idea.”

BA: “Thanks for your time. I’ll go back and review my notes and the samples you have given me, and I’ll send you a brief summary of this interview. I might need to phone you with a couple of questions. Then, I’ll make an appointment to explore the mockup with the engineers. Is this approach okay with you?

CE: “Yes, it is. Thank you.”

The Brown Cow viewpoints help you explore the business use case as it is now, its essence, and what it might be in the future.

In this interview, the business analyst uses the Brown Cow viewpoints to help explore the business use case. He starts by asking how the work is currently done (How-Now) and discovers the spreadsheet and the other computer system for maintenance of the weather stations. He asks, “What else do you keep track of?” to discover the attributes that are recorded (What-Now) when a new weather station is installed. The question about “What other facts” and the one about unused data are designed to uncover data that is not currently recorded or is recorded and not made use of (Future-What). Raising the idea of an integrated system and a mockup (Future-How) is signaling the chief engineer that there will probably be a better way of doing things once the BA has properly understood the business of installing weather stations.

Note that the BA used a lot of open questions. These begin with “What,” “How,” “When,” “Where,” “Why,” or “Who” (the “W” words), and they encourage the stakeholder to give a detailed answer rather than simply “Yes” or “No.”

Listening to the Answers

Being a good listener means being able to understand someone else’s meaning behind their words. This is difficult. We assign meanings to words based on our own assumptions, experience, and preoccupations.

Also, especially when conducting an interview, we are often afraid of silence. Silence might be interpreted as lack of experience or lack of competence. In fact, the reverse is true: It is comforting to have some silence and time for reflection.

If you want to improve your listening skills, you can learn a lot from the fields of psychology, sociology, and family therapy. These disciplines have realized that to help people with problems, you first have to understand what those people mean by their words. In their book Clean Language, Wendy Sullivan and Judy Rees talk about the power of “attending exquisitely” to another person’s words. One of their hints on improving listening skills is “Put your attention on what the other person is actually saying rather than on the person themselves, or what you think they might mean by their words.” Another helpful piece of advice: “Repeat back some of their words or phrases exactly as you heard them.” By doing so, you demonstrate that you are, in fact, listening to what that person is saying, and this feedback encourages them to expand further on what they mean by their words.

Most of all, if you want to become a better listener, don’t talk; develop an appreciation of silence.

Business Rules

Business rules are the internal “laws” of an organization. They are self-governing; the organization formulates them both for internal policy reasons and to comply with industry standards and regulations, and of course the laws of the country. They exist to direct operations, people, and systems as to the rules they have to follow when they do their work. Such rules can apply to any aspect of the organization, from top management to the lowest-level process. They can be as all-encompassing as “Employees are directed not to commit any crime” or as detailed as “The help desk employees will report to their supervisor any cases that are still unresolved 48 hours after the first contact.” Business rules can be written down, or they can be understood by employees and verbally transmitted.

Some organizations have a process to methodically gather and record their rules. Others approach this task less formally, collecting business rules only as they arise during projects. Sometimes new business rules that are discovered during a project are recorded; other times, sadly, they are not. You will find that business rules are expressed at varying levels of specificity. You have to extract your requirements from the business rules whatever state they are in.

Take this business rule as an example:

The maximum length of a truck driver’s shift is eight hours.

This business rule potentially affects the requirements for solutions involved with the following:

● Establishment of a shift

● Monitoring shifts

● Who has to be informed

● Recording of each shift

● Scheduling trucks (you can’t schedule an assignment if the driver cannot finish it within his eight-hour shift)

This means that your trawling uncovers requirements for registering the beginning and the end of a shift, alerting the depot management if any shift exceeds this limit, warning the driver if he is approaching the shift limit, not scheduling shifts longer than eight hours, and so on. The point is that all business rules can give rise to requirements, but first you have to find the business rules.

At the outset of the project, you should ask for the business rules applicable to the project. Work through each business use case and ensure that all appropriate business rules are embedded into whichever model of the business use case you are using. Business process owners are invaluable in helping to find and interpret the applicable rules.

Your business use case scenarios (or other models) are a sufficient and useful repository of the business rules. You might consider recording new business rules as a by-product of your requirements discovery. However, if the organization does not have a formalized way of keeping its business rules, then your business use case documentation is, for the moment, a place to keep them. Be aware that some business rules apply to more than one business use case, and for this reason, among others, you should discuss with your management the establishment of a central repository.

Rich Pictures

A rich picture is a graphical representation of your problem space. Usually, a rich picture has a wider scope than just the proposed product to be built and thus has the greater value of showing the proposed product within its ecosystem.

There are no fixed conventions for rich pictures; you simply draw whatever symbols, icons, or pictures you wish, or write whatever text you feel is appropriate. All of these represent elements that are used in the business. When you are drawing a rich picture, you are forced to think deeply about the problem to be able to represent it pictorially. This is an exercise known as action learning. But let’s not talk about pictures, let’s look at one.

The rich picture shown in Figure 24.2 identifies the problem space for a project to build a dive computer. (Dive computers are used by scuba divers to capture their time underwater and their blood nitrogen levels, and to warn the diver when it is time to start surfacing.) A rich picture is particularly effective for capturing the scope of the problem. We discussed this in Chapter 5, Goals-Scope-Stakeholders. Rather than just focusing on the dive computer, the rich picture identifies all the elements in the world that might have an effect on the problem and the solution.

Figure 24.2

The rich picture of a scuba diving problem space. Various elements and actors are shown, together with some of their connections.

A technique for drawing a rich picture is to choose one element of the problem. Start with the most obvious one—in this case, the Dive Computer. Take a wider view by asking the question: What else in the problem space might have requirements that affect the dive computer? Suppose you say the Diver has requirements about the different types of dive computer. There are a number of existing Manufacturers. Some divers want a connection between their Air Tank and the computer; what sorts of air tanks exist? The diver might buy a computer from one of the Dive Shops … and so on. You keep on expanding the problem space by asking why you want to know about each element and whether it raises requirements that are relevant to the problem space. If you are not sure whether an element should be included in the rich picture, then include it but only until you are sure it has nothing to do with the problem you are trying to solve.

Rich pictures are used at the beginning of a project to ensure that all the stakeholders concur that it is an accurate portrayal of the scope and activity of the customer’s problem.

Creativity Workshops

Asking people what they want doesn’t always result in the best future solution. Companies have gone out of business by providing only what their customers ask for. This is because customers ask for incremental improvements to what they have at the moment. People generally don’t know what they want until they see it. However, as soon as they see a new and innovative solution, they will abandon the old supplier and buy from the new. And it’s not just high-tech companies (Nokia, Motorola, Blackberry, etc.) that fall into this pit. Companies providing everyday business solutions disappear too.

So, for the moment, let’s put aside asking what is wanted and see if we can come up with better ideas that might bring better and more desirable solutions.

As a consumer, you buy new products or services if they offer you a genuine differentiation and advantage over your previous products, or they are things that were previously unavailable. Part of the task of a business analyst is to set aside the presumed or asked-for solution and try to discover something better.

The fundamental idea of a creativity workshop is to make use of the group effect. There is the myth of the lone inventor working in isolation in a lonely attic, but it is only a myth. Almost all innovation comes from a team. Thomas Edison is credited with hundreds of inventions, but it was Edison’s team of engineers who were doing all the hard work. Edison owned the company and got most of the credit, but it’s his team that deserves it.

You must also be prepared to work hard, and to fail. Thomas Edison’s tongue-in-cheek comment, “I have not failed. I’ve just found 10,000 ways that won’t work” sums up working and failing. But “failing” only means that an experiment didn’t work, and you learn from it. The “failure” prompted you to try again. In the end, you find something that works, and works better than what your customer has at the moment.

The rules of running a creativity workshop are simple.

Get the right people. You need at least four, but don’t go over about eight. Imaginative people are naturally the best ones, but as long as you avoid obviously negative people, you’ll find that most people will contribute.

Make sure everyone understands the topic. They have done their homework and have come to the workshop with knowledge of the problem and the goals of the project. You’re wasting time if you have to spend the first half of the workshop explaining what you need to achieve.

No evaluation, no criticism, no debate, no idea killers. Nothing stops creativity more than a naysayer pouring cold water on ideas. It doesn’t matter if an idea is not viable, would cost too much, would be too disruptive, is not “our way of doing things”—the idea will lead to another, better one. For the moment, any idea is a good one. Later, you can sort the gold nuggets from the chocolate teapots.

Have wild ideas and lots of ideas. Not all of these ideas will turn out to be useful, but the more ideas you have to play with, the more likely it is that one of them will turn out to be the game changer.

Combination and improvement are encouraged. Build on other people’s ideas and use their ideas to trigger your own.

Remove constraints. Pretend, for the moment, that a constraint is not a fact of life. What happens if you remove it, or carry on as if it were not constraining you? What ideas come from the new situation?

Combine ideas. Take the phone and the camera, for example. Who would have thought that two such disparate things could be combined to universal popularity?

The thrust of the creativity workshop is to find innovative solutions that are demonstrably better than the current situation or any presumed solution that has been put forward. It is only by innovation that we advance. Consumer technology would still be in the 19th century if we gave people only what they asked for.

Document Archeology

Document archeology is a technique of searching through existing reports, documents, and files, looking for underlying requirements. It is best used when you have some existing or legacy system, and plan to modify or renew it.

Documents can be paper documents, electronic files, or screens. Doing archeology on them intends to uncover their underlying requirements. Document archeology entails reverse-engineering new requirements from the documents used or produced by the current work. Along the way, you look for requirements that should become part of the new product.

Obviously, not all of the old work will be carried forward; because something exists in a document does not mean that it automatically has to be part of a new solution. Nevertheless, where a current system exists, it will always provide plenty of material that is grist for your requirements mill (see Figure 24.3).

Figure 24.3

In document archeology, you start by collecting samples of all documents, reports, forms, files, and so on. Gather anything that is used to record or send information, including regular telephone calls. User manuals are rich sources of material—they describe a way to do work. Help desk records tell you what has gone wrong.

Inspect the documents (for simplicity’s sake, the term “document” means anything you have found), looking for nouns, or “things.” These can be column headings, named boxes on forms, or simply the name of a piece of data on the document. If you hearken back to Chapter 23, Stored Data, you’ll recognize that these “things” can be data entities or attributes of entities. For each “thing,” ask several of these questions.

● What is the purpose of this thing?

● Who uses it and why?

● What are all the uses the business makes of this thing?

● Which business events use or read this thing? If you have built a CRUD table, it will help here. Alternatively, this will help you build a CRUD table. (The CRUD table is discussed in Chapter 37, Completeness Check.)

● Can this thing have an alphanumeric value? For example, is it a number, a code, or a quantity? This indicates whether it is an attribute or an entity.

● If it is an attribute, to which entity does it belong?

● Does the document contain a repeating group of things?

● If so, what is the collection of things called? This is most likely an entity.

● Can you find a link between things? These can be relationships on your data model.

● Which process makes the connection between them? Check your business use cases.

● Which business rules are associated with each thing?

● Which processes ensure that these rules are obeyed?

● Which documents give users the most problems?

These questions will not, in themselves, reveal all the requirements for the product. They will, however, give you plenty of background material and suggest directions for further investigation.

When doing document archeology, you search for capabilities from the current work that are needed for the new solution. This does not mean you have carte blanche to replicate the old one. You are, in fact, gathering requirements because you plan to build a new solution. Nevertheless, an existing system will usually have some capabilities in common with its replacement.

We suggest that you incorporate document archeology into your data modeling approach, because most of the answers from the questions listed earlier are commonly used in the latter discipline.

Customer Experience Analysis

Consider customer journey maps as a trawling tool. Customer journey maps, or customer experience diagrams, are a simulation of your customer’s interaction with the organization for a given set of transactions to achieve a goal.

Customer experience might sound a little touchy-feely, but it pays to keep in mind that customer experience has emerged as a crucial factor in achieving success for most organizations. As a business analyst, you are concerned with how your customers see your organization, and through that vision you determine their needs.

The customer journey map is drawn from the customer’s, or external, point of view. It does this by breaking a significant transaction—sometimes a set of transactions—into the steps that a customer (not the organization) makes to reach her objective. Having made the map, you analyze each touchpoint and identify the customer’s needs and problems for that point. In other words, the map gives you a methodical guide for your trawling.

Consider the customer journey map shown in Figure 24.4. We’ve taken a reasonably uncomplicated scenario by way of illustration; there is no need to have anything more complex to see how this works.

Figure 24.4

A customer journey map showing the steps to having your refrigerator repaired

Note the symbols beside each touchpoint on the journey map; they indicate the potential needs of the customer through both the happy and painful points. You can travel the customer’s journey and analyze and derive the requirements for each step. Sometimes you might have to observe the customers in action to see their needs.

The journey map can give you a different perspective for discovering your customer’s requirements. It is drawn from the customer’s point of view, so it is an external portrayal of the business. Wherever there is a touchpoint, it probably means that there is some internal process to handle it. These internal processes would be investigated, perhaps using process models or one of the other techniques mentioned above.

An example: Let’s say that you work for a repair service, and your project is to improve the service experience. The relevant customer segment receives value when the refrigerator is once again in good working order and is repaired at a cost the customer considers reasonable.

Let’s walk through the journey map shown in Figure 24.4. Start at the point where the fridge breaks. This is an unhappy experience, but there is little that you as a repair service can do about the fact that it broke. You didn’t make the fridge, but you will fix it. Next up is the customer finds a repair service step. At this point, the customer has a need for information. Consider what kind of information would be most useful and what you, as the repairer, should supply. Makes and models of fridges and the most likely quick fixes for them would be at the top of the list. You might also consider warranty conditions. Think about other informational needs. If you supply better information than the competition, your service becomes superior to theirs, and presumably attracts more customers.

Arrange engineer’s visit also has information needs. The customer needs to arrange a mutually agreed time, find out what repairs will cost, and determine if she should do anything before the engineer arrives.

Unloading the fridge is never pleasant, because the customer must find a place for all that food, and unless she can borrow space in the neighbor’s freezer, a lot of the frozen stuff is going to be wasted.

Next is the engineer’s inspection. This has been tagged for unknown or unclear needs. Think about what the customer is doing when the engineer is inspecting the refrigerator and assessing the repairs. Is there any useful information that can be given to the customer? Is there a need for the customer to arrange entry for the engineer if the customer is not at home? Is there a need for clear explanations of what has to be done? Does the engineer need additional material or information to explain things to the customer?

For the step receive engineer’s quote for the work, put yourself in the place of the customer. What do you need to know? How should the quote be delivered? What additional information would be beneficial for the customer to receive? Examples could include time to complete; alternatives to repairing the appliance; warranty; payment options; cost of a replacement appliance; and access conditions for the engineer.

We’ll leave you to follow the remainder of the journey to the end, but we want to mention one touchpoint: Waiting to see if working properly has unknown needs. Is there a need to give the customer information to help test whether the fridge is working? Or perhaps information on how to correctly adjust the fridge now that it is working again?

Travel the Same Journey as Your Customer

A customer journey map illustrates how a customer sees your organization. There is no need for your customers to understand the internal workings of your organization, but you need to. The journey map gives you a structure for discovering both the customer’s and your organization’s needs.

If you, as a service organization, are serious about finding all your customer’s needs, and through that improving your service, be your own customer. Make calls to your own customer support team. Try to sign up for an account at your own online service. Disable your own fridge and call the company. Be the customer and critically consider each step of the way, asking what processes your organization initiates, whether you could make the customer’s experience better, whether the process could break down, what risks you and the customer face at each step, what is needed to make the journey better and more effective, and what can be eliminated or changed to make the path smoother.

Review

In this and preceding chapters, we looked at the techniques used when you’re trawling for requirements. There are other techniques, but the ones we have covered are the ones you are most likely to use, and also the most effective. If you are thirsty for knowledge of business analysis techniques, then James Cadle, Debra Paul, Adrian Reed, and others have produced a book titled Business Analysis Techniques—123 Essential Tools for Success. As the title attests, this book has plenty more techniques if you feel the need. This book is listed in the Resources section.

You will probably use a combination of techniques, switching between them as circumstances dictate. You are working with your customers and stakeholders, so you must be sensitive to their ways of working and choose the techniques that your customers react best to and thus give you the best return for your trawling efforts.

Figure 24.5

Suggested trawling techniques for each Brown Cow quadrant

Another use for the Brown Cow model that you met earlier is to be a guide to techniques you might use in each quadrant. While you are at perfect liberty to use whatever you want wherever you want, this guide might be useful. Figure 24.5 shows the Brown Cow matrix and the suggested techniques for each quadrant.

You don’t have to trawl the entirety of the problem space before moving on. The intention is to do as much as necessary for your team to make a start on subsequent activities. If you are trawling each business event at a time, then as you find the requirements for each one, the later activities shown in the Volere requirements process (see Figure P4.2) can begin, and by the time that business event is implemented, you have completed requirements discovery for the next one.

Trawl for Requirements—Design—Develop—Repeat.

Resources

Writing Effective Business Rules by Graham Witt (Morgan Kaufmann, 2012). The author provides templates from which natural language (understandable by stakeholders) can be generated. Unambiguous business rules are a solid foundation for your requirements.

Rich pictures, a tutorial, and an explanation are available at the Open University website (https://bit.ly/49cOetT).

Soft Systems Methodology in Action by Peter Checkland and Jim Scholes (Wiley, 1999). This is the original work that established the distinction between hard systems that can be engineered and soft systems thinking in which the focus is on making sure the process of inquiry into real-world complexity is itself a system for learning.

Contextual Design: Defining Customer-Centered Systems by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1998). Beyer and Holtzblatt were early pioneers with the idea that it all starts with the customers and that studying them leads you to understanding what they need.

Business Analysis Techniques: 123 Essential Tools for Success by James Cadle, Debra Paul, Jonathan Hunsley, Adrian Reed, David Beckham, and Paul Turner (BCS Learning and Development Ltd., 2021). This book has other information on many of the techniques discussed above, as well as other techniques.

Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Dave Gray, Sunni Brown, and James Macanufo (O’Reilly, 2010). This book provides visual and interactive techniques for facilitating workshops, brainstorming sessions, and other collaborative activities.

Mind Map Mastery: The Complete Guide to Learning and Using the Most Powerful Thinking Tool in the Universe by Tony Buzan (Watkins Publishing, 2018). Buzan invented mind maps and they are now used extensively throughout the world.

We also have a video series on mastering the requirements process. It covers the whole of this book (https://bit.ly/2Aykw2U).

Family Therapy: An Overview, Eighth Edition by Herbert Goldenberg and Irene Goldenberg (Cengage Learning, 2012). The important idea from family therapy is to put communication ahead of consensus.

Ethnography: Principles in Practice by Martyn Hammersley (Routledge, 2007). This is an introduction to ethnographic principles and practice, including ethnography in the digital world.

Part V

Writing Good Requirements and Stories

Think of your developers as housebuilders. To get the house you want—whether they are building it from scratch or renovating an existing structure, and whether they are using traditional construction materials or putting together a modular home—you must tell them exactly what you want. If you don’t specify where you want the windows and doors, how high the roof should be, and what ready-made fittings (windows, floor coverings, heating, etc.) you want, the builders will build pretty much whatever they want, and it almost certainly will not be what you want. It is obviously not practical to let them build something and if you don’t like it, have them demolish it and start over. Yet that is close to what some software projects do. (The analogy is appropriate, as many software projects cost about the same as building projects.)

It is safe to say that to get the end result you want, you must specify what you want. If you want a double-width entry door, you must say so. Otherwise, if your request is open to interpretation, the builders might give you a single door, or perhaps they will gold-plate their efforts and give you a triple-width door. You also must tell the builders the purpose of what they are building so that they can select the best set of materials and construct the product in the most appropriate way. If you fail to tell them that your building will be used to store heavy machinery, then you might well find that the floors collapse under the weight. Similarly, the environment comes into play: You would like your bedroom to be on the east side of the house to catch the morning sun.

The instructions you give to the builders are parallel with the requirements and stories you give to your developers. They must be clear, be unambiguous, and indicate why whatever it is they specify is needed. Your developers, like the builders, will build you the correct solution if they understand your requirements and understand why they are building it.

Moreover, your requirements must be testable. For the builders, this is straightforward. When you want a window opening, you give them the measurements—6 feet wide by 4 feet high, or 180 by 120 cm. You can measure whatever they build to test for compliance with the specification. Similarly, requirements for software or any other solution must carry a measurement to allow testing. It’s a little more difficult than saying 6 by 4, but the ability to test a requirement is well worth the effort to find the right measurement. We’ll come back to measurements and acceptance criteria (they’re more or less the same thing) in a few chapters.

Over the next few chapters, we look at requirements and stories and explain how you can write better ones. Please note that if you normally write stories, even though the next three chapters appear to be talking about traditional requirements, there is plenty of information that is also applicable to stories.

By the way, writing requirements and stories is not a separate activity. You would be writing them as you discover them during any of the requirements activities.

25

Functional Requirements

Functional requirements are what the software product must do; what actions it must take to satisfy the business need. For example, it might be to calculate a premium, or plot a trajectory, or record a transaction, or check a password, or any of the almost infinite number of things that our software solutions do. It’s a functional requirement because it describes some activity, whereas a non-functional requirement (covered in the next chapter) describes the qualities or properties of that functionality.

Functional requirements come from the business activity that you discover when you are trawling or prototyping. From that activity—a mix of current and proposed future activities—you determine how much of it is to be done by the software. Let’s look at how you write functional requirements so that the developers can build the right software. Figure 25.1 depicts the process.

Figure 25.1

The required functionality is discovered by the Trawling and Prototyping activities. The output from discovery is converted into detailed functional requirements.

As an example of a functional requirement, the following describes an action that the product must do to provide value to its customer:

The product shall predict which road sections will freeze within the selected time parameters.

You write many such requirements. The complete collection serves as the specification of the product to be built. When your requirements are the right requirements, the developers have no trouble understanding them, and they build the right product: one that solves your customer’s business problem.

Uncovering the Functional Requirements

When you are trawling or prototyping (we talked about these earlier) you are working with your stakeholders and customers. You’ll find that they mainly talk about functionality:

I need a solution to manage the food on the shelves. It has to alert staff when any item falls below its threshold, and also to identify which products have passed their “display until” date. Of course, the solution has to provide the total wholesale value of the entire store and the turnover for each hour.

Your customer is describing desired functionality. For the parts of the functionality that you and she decide to automate, you write functional requirements.

It is of course possible to write these functional requirements at the time your customer describes the needed functionality, but that would result in a disconnected, incoherent, and incomplete set of requirements. You cannot be certain when the customer describes her situation that she has told you everything, and you cannot know how any one requirement would impact another.

To organize your requirements, we suggest that you take rational slices of the whole of the solution’s functionality and write the requirements for each slice. It will come as no surprise that business events are the proposed way of slicing the functionality.

Every business event (we have discussed these several times before) has a functional response we call a business use case (BUC). The BUC can be set down in several ways, but the easiest one of these to discuss is the scenario. (We covered scenarios in Chapter 20, Scenarios.)

The scenario is made up of a limited number of steps, each of which is a slice of the BUC’s functionality. These steps are generally small enough that it is a straightforward task to write the atomic functional requirements from them.

The word “atomic” is used to say that while there are components of the requirement—subatomic particles—there is no need to divide the requirement into smaller slices.

If you are using prototypes to uncover the needed functionality, then a prototype might involve more than one business event. Depending on the kind of prototype you have built—process model, screen wireframe, storyboard, video, and so on—you can separate its business use cases, and from there write its functional requirements.

For ready-made solutions (as previously mentioned, these are also called off-the-shelf solutions, software as a service, cloud solutions, and other names), functional requirements are written for any needed configuration or modifications to the ready-made. There is a distinction between the two. Configuration means you’re using the ready-made’s functionality as intended. That is, you are adjusting parameters supplied by the vendor to adapt the ready-made to your particular situation. Modification means making changes to the ready-made that cannot be done by configuring parameters. There are also requirements for auxiliary applications needed as front-end or back-end processes for the ready-made.

Deciding the Solution’s Functionality

Functional requirements specify the actions that your solution has to take to support your customer’s business, whatever that may be. So far, the discussion has been concerned with the customer’s business, but your customer may not always desire to automate the entirety of the business. So, you and your customer determine the extent of the automation.

Consider Figure 25.2. The process model (shown as a data flow diagram, but any notation works equally well) shows a BUC. The business event happens, and the triggering data flow enters the workspace and sets off a chain of activities to respond accordingly to the event. This is standard for any business.

Figure 25.2

Determining the product boundary

Let’s say that the customer wishes activity A to be done by a human. There are reasons for such a decision: registering incoming visitors, checking credentials, and so on. This means that activity A is outside any automated product. Activity B uses the data from activity A to access data that is stored digitally (on an in-house server or the cloud), so the accessing activity must be automated. Activity C is also part of the automated product, for the same reason. This results in the product boundary being drawn between activities A and B.

Alternatively, you might move the product boundary so as to include activity A in the automated product—let’s say that it does not have to be done by a human after all. So now the product includes all of the work’s response to the business event. This is quite common—online shopping, a telephone banking app, email, and so on—and you will want to have such a product boundary many times in your requirements work.

You could also move the boundary to the right and include less of the BUC in your product. There are many possibilities, and there is a lot more on this in Chapter 31, Determine the Extent of the Automation.

Let’s say that you and your customer have agreed on the product boundary. The activities inside this boundary make up the product use case (PUC). You write the requirements for all the activity contained by the PUC.

Figure 25.3 illustrates the part of the Requirements Knowledge Model that shows how BUCs, PUCs, and atomic requirements fit together. It also shows the equivalent components if you are using stories. These story components are explained in Chapter 28, Writing Good Stories. Note that the complete Requirements Knowledge Model is in Appendix C, Volere Requirements Knowledge Model.

Figure 25.3

The part of the Requirements Knowledge Model under discussion. The asterisks indicate that many instances of an entity (also called class) participate in the relationship.

You see in this partial model how either the BUC or the business event story is the response to the business event. The product use case or functional story indicates the part of the response you choose to include within the scope of the product. This is then broken down into its atomic functional requirements, or detailed tasks for stories.

Before we leave this, we should mention the part of the BUC that fell outside the product scope. This is the activity/activities to be done by humans. The requirements for this should be written or assembled so that they become part of an operations manual. This manual could include different artifacts such as a list of instructions, business process models, activity diagrams, flow diagrams, screenshots, example forms, functional requirements, or anything else that explains to the humans what they are intended to do. In whichever way it is assembled, it should describe the functionality to be done by the human workforce. You can think of it as a requirements specification for humans.

Now let’s look at how you would write the functional requirements.

Writing the Requirements

To write requirements we need something to write about. Fairly obviously, this is the functionality needed by the solution to support your customer’s business. As mentioned previously, a scenario describing the functionality of a product use case is a good place to start. We discussed scenarios in Chapter 20.

Simply put, each step from the scenario is converted to functional requirements. This is illustrated in Figure 25.4.

Figure 25.4

Each of the scenario’s steps is decomposed into its functional requirements. The collection of functional requirements specifies what the product must do to fulfill the business outcome of the PUC.

The following scenario describes a product use case for a solution that predicts when ice will form on roads and sends a schedule to the truck depot showing which roads have to be treated and when. You have seen snippets of this previously.

Product use case: Produce Road Deicing Schedule

Engineer provides a scheduling date and district identifier to the product.

Product retrieves the relevant thermal maps.

Product uses the thermal maps, district temperature readings, and weather forecasts to predict temperatures for each road section in the district.

Product predicts which road sections will freeze and when they will freeze.

Product schedules available trucks from the relevant depots.

Product advises the engineer of the schedule.

Including three to ten steps in the scenario should give a reasonable level of detail, without making it too complex for nontechnical stakeholders.

The steps in this product use case scenario describe the product’s response to the business event, Time to schedule deicing. Having a limited number of steps—we suggest between three and ten—in the scenario prevents you from getting enmeshed in details and ensures that the scenario is written in stakeholder-friendly language.

Once you and your stakeholders have agreed on the scenario, for each of the steps ask, “What does the product do to complete this step?” For example, the first step in the scenario is:

1. Engineer provides a scheduling date and district identifier.

What does the product do to complete this step? The first thing is fairly obvious, so this is your first functional requirement:

The product shall accept a scheduling date.

When you ask the stakeholders whether there is anything special about the scheduling date, they tell you that due to imprecise forecasts, they schedule no more than two days in advance. This information suggests another functional requirement:

The product shall warn if the scheduling date is neither today nor the next day.

Another requirement from the first step is:

The product shall accept a valid district identifier.

You discover another requirement when you inquire what is meant by “valid.” The identifier is valid if it identifies one of the districts for which the engineer has responsibility. It would also be valid if it is the identity of a district that is intended by the engineer. This leads us to two more functional requirements:

The product shall verify that the district is within the deicing responsibility of the area covered by this installation.

The product shall have the engineer verify that the requested district is accurate.

The objective is to write enough functional requirements for your developers to build exactly the product that your client is expecting and that your user needs to do the work.

The number of requirements you derive from any step is not important. However, it can sometimes be an indicator of too much or too little granularity. Experience tells us that it is usually fewer than six. If you uncover only one requirement from each step, it suggests either the level of detail in your scenarios is too granular or your functional requirements are too coarse. If you find you are writing more than six requirements per step, it suggests that either your requirements are too fine-grained or you have a very complex use case. There is no hard rule here, but it is worthwhile to pay attention to the granularity of your requirements.

Regardless of granularity, the objective is to write enough functional requirements for your developers to build exactly the product that your client is expecting and that your user needs to do the work.

Let’s consider another of the product use case steps from our example scenario:

4. Product determines which roads will freeze and when they will freeze.

This step in the PUC scenario leads us to write three functional requirements:

The product shall determine which areas in the district are predicted to freeze.

The product shall determine which road sections are in the areas that are predicted to freeze.

The product shall determine when each road section will freeze.

Now continue in the same vein, working through each step from the scenario. When you have exhausted the steps, you should have written all the functional requirements for the product use case. You should test whether you have completed the PUC by walking through the requirements with a colleague and demonstrating that the product use case provides the correct outcome for the customer.

You can do the same thing using a process model. Figure 25.5 illustrates this.

Figure 25.5

The activities on a process model are able to be decomposed to a collection of functional requirements.

The Snow Card

So far, the requirements have been no more than “the product shall …” statements. You need more detail. The best way to do this is to introduce the snow card. Figure 25.6 shows one.

Figure 25.6

The snow card carries the attributes of a requirement.

The snow card shows the attributes of a requirement. It is an idea borrowed from American architect William Peña. Peña was an advocate of architectural programming, which has many parallels with requirements discovery and recording. Peña’s teams used blank cards that they taped to a wall for recording requirements and issues for the buildings they were designing. We adapted his idea by adding field headings such that when a card is filled in, it provides a rigorous definition of a requirement.

We are not for a moment suggesting that requirements work is filling out forms. We are suggesting that you can make use of the snow card’s fields to write better requirements. Similarly, we are not suggesting that requirements should be written on paper cards; most people find an electronic “card” is easier to work with and share.

In any event, it is not the medium of the card but its contents that are important to us. We will get to all of the content in good time, but first consider the Description and the Rationale. These are the “what” and the “why” of a requirement.

The examples shown above are the description of the requirement, but there is more to a requirement than that. We suggest—strongly suggest—that you add a rationale to your requirements to show why the requirement exists. In some cases, this might be obvious, but in many circumstances, it is a crucial component of the requirement.

For example:

Description: The product shall record roads that have been treated.

This might seem at first glance to be a routine requirement and of no great importance. Now let’s add the rationale for this requirement:

Description: The product shall record roads that have been treated.

Rationale: To be able to recognize untreated roads and highlight potential danger.

The rationale indicates whether the requirement is worthy of some special attention.

Now it looks a little more serious—human lives could possibly be at risk, or at the very least, the owner of this product would not be carrying out his statutory duties. With the inclusion of the rationale, you give the developer the opportunity to build a better solution; one that makes this information readily accessible to the functionality that discovers the untreated roads. Clearly, the rationale indicates that this requirement is worthy of some attention.

Now consider this example:

Description: The product shall record the start and end time of a truck’s scheduled activity.

This is a normal kind of requirement, one that would not cause much comment. But does it contribute any value to the product? Let’s look at two possible rationales:

Rationale: The truck depot foreman wants to know which trucks are being most used.

Or:

Rationale: Trucks are to be scheduled a maximum of 20 out of 24 hours to allow for maintenance and cleaning.

Now we are getting somewhere. The first rationale says that the requirement is low priority and might not be worthwhile implementing. After all, the depot foreman can discover the trucks’ usage simply by reading their tachometers. However, the second rationale indicates that this is a valuable requirement: If it is not implemented, then the truck fleet will suffer.

By knowing why something is there, the developers and the testers know much more about the effort they should expend on it.

By including a rationale with the description, the requirement itself becomes more useful. By knowing why something is there and how important it is, the developers and the testers know much more about the effort they should expend on it. It also indicates to future maintainers why the requirement exists in the first place.

The rationale also helps to overcome the possibility of inadvertently writing a solution instead of the real need. For example, the following requirement description is written for a machine to sell bus tickets for a city bus company:

Description: The product shall provide the bus network route map on a touchscreen.

The description is actually a solution to the problem. When the rationale is added, the real need becomes visible:

Description: The product shall provide the bus network route map on a touchscreen.

Rationale: Passengers have to provide their destination for the fare to be calculated.

The rationale indicates that the real requirement is for passengers to provide a destination. How they do so is best left to the user experience designer and the solution architect. The touchscreen might be the best way to accomplish this goal, but then again, it might not. If tourists were prominent users of the buses, then they would not be familiar with the layout of the network, and finding the stop on a map might be a very slow process. This would not please passengers standing behind them in the queue to buy tickets. Also, if the network is divided into zones for charging purposes, then for regular commuters, it might be more efficient to have a way to indicate the number of zones to be covered and to ignore the actual stops. After all, a destination can be a stop or a zone.

Regardless of how the need is finally implemented, it is clear that writing both the description and the rationale leads to discovery of the real requirement.

Why is this aspect of requirements development important? Because it is far too easy to hide important functionality by describing an implementation, and it is far too easy to select the most obvious implementation when better ones may exist. Regardless of how the need is finally implemented, it is clear that writing both the description and the rationale leads to discovery of the real requirement. It also leads to more accurate requirements. Often, the rationale clarifies the requirement and you then update the description. You might also find that when presented with your proposed rationale, your customer realizes that you have been given the wrong description. And so it goes.

We have not yet talked about how to ensure that each requirement is measurable and hence testable. We do this by adding a fit criterion, and this is so crucial that we have devoted Chapter 27, Fit Criteria and Rationale, to it. There are more attributes to a requirement; they are shown on the snow card in Figure 25.6. We shall come back to these later, so for the moment, we can leave the functional requirements as a description and rationale only.

Technological Requirements

Technological requirements specify functionality that is needed purely because of the chosen technology. In the example of the PUC that produces the deicing schedule, the product interacts with an external thermal mapping database. Suppose the designer decides that handling this interaction via an internet connection is the best option. Because of this technological choice, the product has a need to establish a secure connection. This need is a technological requirement; that is, it arises purely because of the chosen technology. If the designer had selected a different technology to handle this part of the work, the result would be different technological requirements.

The technological requirements are not there for business reasons, but rather to make the chosen implementation work. We suggest that the technological requirements are identified as such. Stakeholders must clearly understand why a requirement appears in the specification, so it is important that the technological requirements are not introduced before the business requirements are fully understood.

Level of Granularity

Requirements are written as a single sentence with a single verb.

Note the level of detail or granularity in the preceding examples—the requirements are written as a single sentence with a single verb. When you write a single sentence, you make the requirement readily testable and far less susceptible to ambiguity. The functional requirement describes an action, so there is always a verb, and preferably a single verb. The action is what the product must do to satisfy a business need.

Functional requirements are verifiable by your business stakeholders. This is not to say that you have to show every requirement to them, but when you need to, you want them to understand enough to come to an agreement as to whether this is the real business requirement.

Additionally, a reasonable developer is able to build the correct product. “Reasonable” might be arguable, but today’s developers are, for the most part, pretty good. If your developers say they cannot build from the requirement, then you must suspect that your requirement is too vague or ambiguous.

Note the form “The product shall …”; it makes the sentence active and focuses on communicating what the product is intended to do. It also provides a consistent form for the developers and other stakeholders who need to have a clear understanding of what the product is intended to do. You can of course substitute “will” for “shall” (some people claim it is grammatically better), but be consistent with whichever you choose. Some people prefer to omit “The product shall” and write:

Record the salt capacity for each truck added to the fleet.

Use a separate component of your requirement to indicate the priority of the requirement.

Please don’t try to use the description to indicate priority. Sometimes people use a mixture of “The product must,” “should,” or “could” to indicate the priority of a requirement. This practice results in semantic confusion, and we advise against it. Instead, use one consistent form for writing your requirements’ description (“The product shall …” is probably the most common), and use the priority attribute on the snow card to indicate its priority.

Conditional Requirements

Sometimes you need to add a condition to a requirement. This happens when the requirement comes into play when certain processing circumstances have occurred. For example:

If a road scheduled for treatment has not been reported as treated within 30 minutes of its scheduled time, the product shall issue an untreated road alert.

Alternatively, you might find that the requirement reads more easily if you write it with the condition at the end:

The product shall issue an untreated road alert if a road has not been treated within 30 minutes of its scheduled time.

Avoiding Ambiguity

Whether the sources of your requirements consist of written documents or verbal statements from interviews, you should be aware of the enormous potential for ambiguity and the misunderstanding that ambiguity can cause. Ambiguity arises from several sources.

First, the English language is full of homonyms. English contains an estimated 500,000 words in normal usage and about the same number of technical, scientific, and other specialized words. Normal-language words have been randomly added by many different people and from many sources over a long period of time. This growth has led to different usages and meanings of the same word.

It is difficult to imagine why, when the language contains a huge number of words, so many of them have multiple meanings.

Consider the word “file,” which is used so commonly in information technology. In addition to meaning an automated storage place for information, it means a metal instrument for abrading or smoothing; a collection of documents; a row of people, as in “single file”; a slang term for an artful or shrewd person; a verb meaning to rub away or smooth; and more recently a verb used by lawyers when they “file suit.” Of course, “suit” itself also means the clothing the lawyer wears in court, as well as a set of playing cards such as hearts, diamonds, spades, and clubs. It is difficult to imagine why, when the language contains so many words, so many of them have multiple meanings.

When writing requirements, we have to contend with more challenges than just homonyms. If the context of your product is not clear, then it will also lead to ambiguity. Suppose you have the following requirement:

The product shall show the weather for the next 24 hours.

The meaning here depends on the type of requirement and what is near it in the specification. Does the requirement mean the product is to communicate the weather that is expected to happen in the forthcoming 24 hours, or must it communicate some weather and continue to do so until one full day has elapsed?

We advise you to group your requirements by product use case and write your requirements one PUC at a time. This system of organization will, to a large extent, reduce ambiguity. For example, consider this requirement:

The product shall communicate all roads predicted to freeze.

Does “all” refer to every road known to the product? Or just those roads being examined by the user? The PUC scenario tells us that the user has previously identified a district or an area within the district. Thus, we may safely say that “all” refers to the geographical area selected. In fact, the meaning of almost any requirement depends on its context. This is quite a good thing because we do not need to waste time by laboriously qualifying every word of every requirement. While anything has the potential to be ambiguous, the PUC scenario, by setting a context for the requirement, minimizes the risk of ambiguity.

You can also make your requirements less ambiguous by including a glossary of terms in your specification. This is why section 4 of the Volere Requirements Specification Template—Naming Conventions and Terminology—exists. The terminology you define there should be used consistently throughout your requirements definitions.

You should try to eliminate pronouns from your requirements and replace them with the subject or object to which the pronouns refer. (Note the potential ambiguity of the preceding sentence if we had said “they” instead of “the pronouns.”)

When you write a requirement, read it aloud. If possible, have a colleague read it aloud. Confirm with your stakeholder that you both reach the same understanding of the requirement. This may seem obvious, but “send the bill to the customer” may mean that the bill goes to the person who actually bought the goods or that the bill is sent to the account holder. It is also unclear whether the bill is sent immediately after the purchase or at the end of the month. And does “bill” refer to an invoice, a bill of materials, or a bill of lading? A short conversation with the appropriate stakeholders about the definition and consistent use of terminology will clarify the intention.

Grouping Requirements in Your Specification

We have spent a fair amount of time talking about business events and how they make the discovery of the requirements easier. What they also make easier is the development of the product. We discussed deriving a product use case from the business use case (from a BUC to a PUC), and suggested that you write your requirements one PUC at a time. The PUC is a separate and distinct amount of functionality. It is a natural choice to be a unit of development.

This leads to saying that because you are probably writing your requirements from a scenario or a process model, as discussed above, you keep the requirements grouped in their PUCs. This gives a context to the requirements, making it easier for the developers to understand what is needed.

Additionally, grouping by PUC makes any specification easier to read.

Requirements for Ready-Made Products

Requirements for solutions using ready-made components are in effect no different from requirements for custom-built solutions. Some of the requirements are written to configure or customize the ready-made product, but they are still written in the form “The product shall …”.

Functional requirements written about the configuration of the ready-made product specify what the product will do when it is configured. “The product shall …” tells the developer what functionality is needed, and she uses the configuration capabilities of the ready-made to make it perform as desired.

You also must specify any needed customization. Here the functional requirements specify the required changes to the ready-made. They are the same as before in that they specify needed functionality, and the developer builds that into the ready-made. It is necessary to make it clear to the developer which parts of the ready-made are being changed, and additionally what ready-made functionality has to be removed.

Integrating the ready-made with existing IT solutions and their operating environment is usually a major part of your requirements work. Here you write requirements for any changes needed to the ready-made to make it compatible with existing databases. This entails mapping the ready-made’s data to existing corporate data. Required changes to either the ready-made or existing interfacing systems are specified with functional requirements.

In some cases, you need to build front-end or back-end applications to provide data to or receive data from the ready-made. These are partly the same as regular apps but need additional functionality to integrate the data. A front-end application would normally be acquiring data to populate the ready-made’s databases. Here you write requirements to ensure smooth integration between the incoming data and the ready-made. On the other side, the back end, many of the requirements have to do with making the ready-made’s data work with existing systems.

In these cases, requirements are written as we have been describing them.

Review

Functional requirements specify what the solution must do to satisfy the business need. They are written as an action: “The product shall …”, followed by a verb. The functional requirements should be a complete and unambiguous description of the product’s functionality.

Functional requirements are derived from the product use cases—the portion of the business use case that is to be done by the product. The most convenient way we have found to generate the functional requirements is to write a scenario that breaks the PUC into a number of steps. Examine each step and ask, “What does the product have to do to accomplish this step?” The things that it does are the functional requirements.

A process model achieves the same result. You examine each of its activities and ask the question as above. You write the functional requirements from the answers.

We suggest that you write these requirements (for the moment) using two components: a description and a rationale. As we work through the book, we discuss how to formulate the rest of the requirement’s attributes.

One thing that you will probably notice is that your requirements sometimes evolve. We mentioned above that when you write the rationale for the requirement, it sometimes causes stakeholders to reconsider what they have asked for. You update the description accordingly. You might also find that as you specify more and more of the product, you revisit existing requirements and reconsider and, sometimes, change them. However, by saying this, we are not advocating uncontrolled requirements hacking. Rather, we advocate that you keep an open mind about your requirements and be prepared to change them if circumstances warrant a change.

When you have sufficient functional requirements to achieve the outcome of a product use case, it is time to move on to the next one. As you progress through these PUCs, you may discover that a requirement you defined for one PUC also applies to other PUCs. Reuse the requirement you have already written by cross-referencing it to all relevant PUCs.

When all of the product use cases have been treated, you will have defined the requirements that completely and unambiguously specify the functionality of the product.

When all of the product use cases have been treated this way, you will have defined the requirements that completely and unambiguously specify the functionality of the product.

Resources

The best resource for writing functional requirements is the template packaged in Appendix A, The Volere Requirements Specification Template.

26

Non-functional Requirements

Non-functional requirements can make or break your solution. The non-functional requirements (NFRs) specify the qualities your product must have if it is to succeed with your customers, in the marketplace, in the office, and in its operating environment. Non-functional requirements specify how well your solution performs its functional requirements.

Imagine for a moment that you are an engineer. You work for the electricity company that supplies a city and the surrounding area. Your job is to monitor the flow of electricity in the city and make adjustments to the supply as demand ebbs and flows over the day and from season to season.

Your IT people are building a new solution to provide you with the functionality that allows you to see the supply in real time on an array of screens. This information should allow you to intervene whenever you detect some abnormality that needs your correction. Some of this monitoring functionality will be automated, but the role of the engineer is to intervene and make adjustments if the situation becomes critical.

Now imagine the non-functional requirements that apply to this electricity monitoring and correcting solution. Non-functional requirements are designated by types, and these types are shown in the following list.

Look and Feel: The appearance and style of the solution

Usability and Humanity: The solution’s ease of use, and any special considerations needed for a better user experience

Performance: How fast, how many, how available, how scalable, how accurate the functionality must be

Operational and Environmental: The operating environment of the solution, and any considerations that must be considered for this environment

Maintainability and Support: Expected changes, and the time needed to make them; also, specification of the support to be given to the solution

Security: Access, integrity, privacy, recoverability, and auditability of the product

Cultural: Special requirements that come about because of the culture and customs of people who come in contact with the solution

Compliance: The laws and standards that apply to your solution

The requirements types you see on this list have been derived from a large collection of specifications that we have written over the years. From these we extracted the most useful properties for solutions to have. For convenience, we grouped them into eight major non-functional requirement types, and within those, subtypes or variations on the type. You can see the complete list and discussions on all the non-functional types in the Volere Requirements Specification Template. You find this in Appendix A.

Later in the chapter we’ll discuss each of these requirement types fully. For now, we’ll introduce them by looking at some practical examples. We’ll choose some of the NFRs that are relevant for the electricity solution. Let’s go back to our engineer.

Think of the functional requirements as those that cause the product to do the work and the non-functional requirements as those that specify the quality of that functionality.

The obvious first choice of non-functional requirement for your electricity solution is Security. Unless you are a highly qualified engineer you have no right to be messing around with the city’s electricity supply. Thus, the obvious security requirements must include provisions for preventing unauthorized people from accessing this solution. You also need security requirements to warn an operator if the consequences of her actions could be detrimental.

An even greater threat to the city’s electricity supply comes from cyberattacks. Hostile actors with bad intentions can bring down an electricity grid, so some of your security requirements are aimed at keeping the grid safe from any variation of a cyberattack.

Next up is Operational and Environmental. These have to do with the operating environment of a solution. In this case, your solution would need to connect to and interact with the statewide or national electricity grid, with each of numerous suppliers putting electricity into the grid, along with some city-owned systems that supply information about traffic, human movement, weather, and other factors.

Compliance requirements would also be high on the list. These have to do with laws that apply to your solution. In this case, the electricity monitoring solution would be subject to various city and state regulations applicable to the electricity supply. The engineer wants to be certain that her actions are within the law.

Look and Feel non-functional requirements are significant. The engineer would not want screens with a cartoonlike interface. Like most engineers, she wants a professional or engineering look to the solution. Its appearance must also make her feel that it is reliable.

The UX designer would work with you to design the final screens, but first you need to determine the requirements for the look and feel. Most of all, you want the interface to fit seamlessly into the engineer’s world so that it feels like the natural way for her to do her work.

Let’s look at a different situation to see some other examples. This time you are an insurance adjuster working for an insurance company specializing in automotive insurance. You are responsible for processing insurance claims made when policyholders damage their cars.

Usability and Humanity requirements are important here. Although you are a skilled adjuster, you need usability that gives you convenient access to all the information you need in order to settle insurance claims. You need to be able to see the police report on the accident and the body shop’s quote for repairs (possibly several of these), and you need to consider any personal statements made by people involved in the accident. So, the usability requirements specify a solution that allows you to process the claims quickly and accurately.

Cultural non-functional requirements are important to you, or at least to your employer. This loss adjustment solution is to be used in different states and in different countries. Local culture must be taken into account to ensure that no matter where they are, adjusters can understand the language and the technical terminology being used.

Look and Feel requirements specify that your adjustment solution is compatible in appearance with the other applications that you use. The insurance company has interface standards, and these non-functional requirements specify conformity with them.

Compliance requirements are important because the solution naturally would have to comply with insurance law applicable to the country or state of the insured’s motor vehicle.

Privacy, which comes under the heading of Security, must also be specified. The privacy requirements would specify that personal information about the policyholder is not released or available to anyone except the insurance adjuster and his supervisor.

Some of the other types are also applicable to this example, but now let’s turn to a more general look at non-functional requirements. To understand the significance of non-functional requirements it’s useful to consider a company that early on recognized the impact that non-functional requirements can have. The most obvious example of such a company is Apple. Apple’s attention to look and feel, usability, security, operability, and so on has made its products both extremely popular and much imitated. People are willing to pay a premium to have them.

Similarly, your choice of household appliances is often based on non-functional requirements. All dishwashers wash dishes—it’s their ease of use, their speed, and their environmental credentials that make the difference to consumers.

Non-functional properties may be the difference between an accepted, well-liked product and an unused one.

Spend a moment thinking of the end users of your solution. You have to provide the functionality that is needed for them to do their work. The non-functional requirements are those that make the product fit into the users’ world. If you get the right non-functional requirements, they bring about solutions that are readily, even enthusiastically, welcomed by their intended users.

PUCs and NFRs

A product use case, a PUC, is the part of the response to a business event that is done by the automated product. In the previous chapter, we discussed how a scenario can be used to describe the product use case by showing it as a number of processing steps, and for each step, you determine the functional requirements.

Non-functional requirements, however, do not fit so neatly into this way of partitioning. Some of them can be linked directly to a functional requirement, some apply to the product use case as a whole, and some apply to the entire product. Figure 26.1 shows possible links between the functionality and the associated non-functional requirements.

Figure 26.1

In this example, the product use case has three functional requirements, each having some non-functional properties. The use case as a whole must meet certain usability requirements, whereas the look and feel requirements relate to the entire solution.

Non-functional Requirement Types

Let’s look at each type of non-functional requirement in detail.

As you read through these requirement types, keep in mind that sometimes it is difficult to say exactly which type a requirement is. When this sort of uncertainty arises, it could indicate that you have several requirements posturing as one, or that you have one of those not-uncommon requirements that is just too difficult to categorize. If this bothers you, then you can give a requirement multiple types. Don’t sweat it. The category is not important. The requirement is.

There is one other thing to keep in mind as you go through the various non-functional requirements: For the moment, we are dealing only with the description and rationale of the requirement. Some of the examples we give might seem a little vague, ambiguous, or loosely worded. The method of attack is to initially capture the stakeholder’s intention for the requirement. Later you will add a measurement—this is the fit criterion—to the requirement to clarify it and make it testable. For example, you might write a fit criterion for a usability requirement that specifies how quickly a first-time user can learn to use the product and achieve certain tasks. Or you might specify the improvement in usability and thus efficiency that the new product must achieve.

We discuss fit criteria in the next chapter, but for the moment we ask you to accept that it is possible to measure such things as “attractive,” “exciting,” “easy,” and other adjectives that appear in the descriptions of non-functional requirements.

Look and Feel Requirements: Type 10

The Type number refers to the section of the Volere Template in Appendix A.

Look and feel requirements describe the intended spirit, the mood, the style of your solution’s appearance. Keep in mind that these requirements are about the intention of the appearance and are not a detailed design of an interface. For many projects, the prime look and feel requirement would be something like this:

Description: The product shall comply with corporate branding standards.

Or:

Description: The product shall conform to the established look and feel of the owning organization’s products.

These requirements do not in any way attempt to say that the company logo must occupy 10% of the screen, nor do they talk about the colors or the typefaces to be used. They simply state that the product must comply with the established branding standards. These standards are published elsewhere—your organization has a department (usually the communications department) or group responsible for these standards—and you and your UX designer have access to them.

Sometimes the look and feel requirements have nothing to do with corporate standards. For example, they might have to specify the appearance of an app. Appearances matter, and first impressions are important. Think of your favorite app, on either your computer, tablet, or phone. Why do you like it? The answer to that might be complex, but a significant part of it has to do with the way it looks. It does not have to be beautiful, but its appearance must be consistent with what it is doing. You don’t want your bank app to look like your music app, which in turn should not look like your office apps. In some cases, you might have a particular situation where the appearance of the solution is crucial to its success.

Look and feel requirements specify the spirit of the solution’s appearance. They are not the design of the interface.

Let’s say that you are discovering the requirements for a solution to be used by a police force. In this case, you would write a look and feel requirement that the solution must have “a police look and feel.” Perhaps it would be more helpful to write the requirement as “Similar to the look and feel of existing solutions at police headquarters.” This kind of requirement might seem mere and obvious, but imagine if you had not specified any look and feel, and the developers implemented the solution with an inappropriate appearance. Cops are cops, and they want their gear to look like police gear. You don’t have to describe how to achieve a “police look,” but you must specify it.

Can you measure and test whether it has a “police look and feel”? Yes. You could measure the product’s approval or acceptance by a test panel of police officers. Or you could measure its adherence to established police solutions. The reason for the product having a “police appearance” is to have it accepted and used by police officers. If your test panel accepts it and uses it, then you have achieved a solution that fits the requirement. By the way, you would probably test the “police look” of the product using mockups and prototypes, and thus avoid the expense of building the real thing and risking it being rejected.

Consider whether some of the following sample look and feel requirements are appropriate for your current or next project.

The product shall

● Appear simple to use

● Be approachable so that people do not hesitate to use it

● Appear authoritative so that users feel they can rely on it and trust it

● Conform to your customers’ other products

● Be attractive to children or some other target audience

● Be unobtrusive so that people are not aware of it

● Appear innovative and state of the art

● Be professional looking

● Be conservative

● Appear intriguing

● Be exciting

● Be cool

If you’re thinking that some of the above are vague and untestable, then please withhold judgment until we have talked about fit criteria. We’ll get to that in the next chapter, where we discuss how you can add a measurement to the requirement that allows any of the above to be tested. So initially, your look and feel requirements might appear to lack substance, but your intention is to capture the desired feel of the solution, and later you make it measurable, and thus tangible.

Today, in some application areas, software has become a commodity, and the distinction between the functionality of competing products has largely disappeared. In such cases, it falls to the non-functional requirements to differentiate one product from another. Usually, the noticeable and exceptional products have a distinctly superior look and feel.

You should always consider the audience for your product and whether they require some special appearance or feel to the solution. Your client has in mind the kind of experience she wants visitors to the site to have, and much of that experience is down to your look and feel requirements.

If you have a few moments and wish to amuse yourself to good avail, think of a product and come up with look and feel requirements for one or more of the following customer segments:

● Gen-Z

● Sailors

● Vampires

● Mothers

● Taylor Swift fans

● Submariners

● Gormogons

● Residents of Coober Pedy

● Heavy metal streaming audience

To reiterate the key point, the look and feel requirements describe the intention of the appearance and are not the design of the interface. To design the product at this stage would be premature—you do not yet know the complete requirements of the product. Designing is the task of the product’s designers and UX designers, once they know the requirements.

Usability and Humanity Requirements: Type 11

How many times in the past year or so have you downloaded an app to your device, used it for a few days, a few hours, or perhaps a few minutes, and then deleted it? The first reason for deleting it would be that it lacked the functionality you needed or it asked you to pay for something that was not valuable to you. The next reason would be its poor usability: You found it so awkward or opaque to use that you just gave up on it.

Why was it unusable?

● Sheer incompetence (there is nothing in this book that can help with that).

● The app’s builder never thought about usability requirements (there is a lot in this book that can help with that).

● The builder didn’t bother to find out anything about the kind of people who would be using it or the circumstances under which they would be using it.

This can happen at any time, but it shouldn’t. As consumers, we have become intolerant of poor usability and demand that the products we use, whether they are software, consumer goods, or services, be easy to use and likable. Usability might be one of the key factors that determine whether your customers accept or reject your solution.

Usability requirements make the solution conform to the user’s abilities and expectations of the user experience.

The usability and humanity requirements specify a solution that conforms to the users’ human abilities and expectations. So, you must consider your target customer segment. What kind of people are they? What kind of product do they need to do their jobs? The usability and humanity requirements ensure that you make a successful solution for them. This is illustrated in Figure 26.2.

Figure 26.2

Consider the capabilities, knowledge, and circumstances of your intended audience when writing the usability requirements. Imagine what it’s like to do this job. Ask what would make this product fit most seamlessly into this person’s world.

As an example of usability requirements in real life, let’s look at Amazon. The Amazon site is easy to navigate, which makes it easier for customers to find things—this, of course, being the purpose of the site. It is also friendly and makes you feel like a valued customer. You can write reviews, get guidance from fellow customers and Amazon’s recommendations, check out and arrange delivery easily, return products conveniently, see your past orders, and so on. Amazon’s attention to the non-functional requirements has made it so attractive to shop at its site that people do just that. Many people. As a result, Amazon has become the world’s largest online retailer and has made its owner staggeringly rich. (We are not promising Bezos-like riches if you pay attention to non-functional requirements, but it might help.)

The circumstances of your intended customers have an impact on your usability requirements. Will your customer be juggling other apps at the time of using yours? Will she need to consult the grocery shopping list, send a photo of a product to her spouse, and make a payment at more or less the same time?

Does the customer for your product have a disability? For example, customers who are partially sighted or have poor eyesight should be considered. Seniors sometimes struggle to use some apps, not because the seniors are incapable but because they just can’t read the miniature typefaces on the screen. Colorblindness can hamper a customer’s ability to use a solution. About 1 in 12 males are red-green colorblind (yes, these are the important traffic light colors) and might be part of your usability requirements.

The usability of a product affects productivity, efficiency, error rates, and so on. It also affects acceptance: whether people actually use the product or are able to use the product. Carefully consider what your customer is trying to achieve with the product before writing usability requirements. For example, you might write one of the following sample requirements:

The product shall be usable by customers with no previous experience of it.

The product (an accounting solution) shall be usable by people with no formal accounting training.

The product shall be used in cold conditions and the operator might be wearing heavy gloves.

The product shall be used by office staff with ten years of schooling and fluency in English or Spanish.

The product shall be easy to learn by certified mechanical engineers.

“Easy to use” and “easy to learn” are slightly different characteristics. Easy-to-use products are designed to facilitate an ongoing efficiency, so perhaps some training is necessary before using the product. For example, suppose you were specifying a product to be used for some repetitive tasks in an office by clerical workers. You would be well-advised to make it easy to use, even if the ease of use means training people to use the product. The ongoing efficiency will pay for this extra effort many times over.

Adobe Lightroom (Photoshop, or any of the other professional-level photo manipulation products) is a case in point. Lightroom is a comprehensive product that offers an amazing wealth of options for the manipulation of digital images to its intended audience of photographers. The Lightroom learning curve is a steep one: There is a lot to be learned, and we would venture to say that it is not particularly easy to learn (at least it was not for one of your authors). However, once learned, Lightroom’s features make manipulating images a straightforward—even easy—task. Given the depth of functionality needed to do the task and its inherent complexity, Adobe has made its product easy to use once you have learned how to use it.

By contrast, easy-to-learn products are aimed at those tasks that are done infrequently and, therefore, may be forgotten between uses—yearly reports, rarely used features of a software product, and so on. Products that are used by the public for which no prior training is feasible—telephones, internet connections in public places, and dispensing machines—need to be easy or quick to learn.

Your requirement might be as follows:

Description: The product shall be easy to use by a member of the public on the first attempt without training.

Rationale: This new checkout product will save a considerable amount on the cost of transactions, so we need our retail customers to voluntarily switch to using it.

The rationale provides a justification of the customer’s need, and also provides rich information to the builder of the solution. In this case, the rationale says that this has to be a solution that attracts people to use it; otherwise, there is no point in building it.

We had a client who asked for the product to be “friendly.” Because we could not immediately think of a suitable measurement for this requirement, we felt, naturally enough, that we could not write the description as “friendly” and leave it at that. Some questioning revealed that the product the client wanted would appeal to the personnel consultants who were to use it. He knew that the consultants would be more productive if they switched to the new product, but he also knew that they would not use it, or would use it badly, if they didn’t like it.

With that understanding, the requirement began to look like this:

The product shall be liked by the personnel consultants.

We suggested to the client that we could measure the number of consultants who, after an initial training period, preferred to work with the new product rather than their old way. The client agreed with this plan: He said that he would be satisfied if 75% of the consultants were using the product after a six-week familiarization period.

Thus, we had the description and rationale for our usability requirement:

Description: The product shall provide the preferred way of working for the personnel consultants.

Rationale: To build the consultants’ confidence in the product and achieve a 75% take-up rate

Usability and humanity requirements can cover areas such as these:

● Rate of acceptance or adoption by the users

● Productivity gained as a result of the product’s introduction

● Reduction of error rates

● Usage by people who do not speak the language of the country where the product is to be used

● Personalization and internationalization to allow users to change to local spelling, currency, and other preferences

● Accessibility to people with disabilities (this is sometimes mandated by law)

● Use by people with no previous experience of the product (an important, albeit often-forgotten consideration)

● Able to be used during the hours of darkness (this caters to vampire users)

Usability requirements are derived from what your client is trying to achieve with the operability of the product, and from which kind of experience the users expect. Naturally, the users’ characteristics and circumstances make a difference to their expectations. You, as the requirements analyst, have to discover these characteristics and determine which levels of usability will turn the product into a useful and pleasant experience for them.

Before you write your usability requirements, it is essential to have a very clear picture of who will be using your product. In Chapter 6, Customer Segments, we discussed the process of constructing a persona: a virtual person that is a distillation of the majority of your users. You survey your user community, to derive this archetypal character to represent that community. As a consequence, you write the usability requirements to suit the persona—the embodiment of almost all of the people who will actually use your product—instead of writing them to suit your own personal preferences or the preferences of just one or two of the loudest users.

Take a break and amuse yourself with usability requirements for some of these users. The product can be anything you choose:

● Round-the-world sailors

● Circus clowns

● Rock concert attendees

● Zombies

● Members of the US Lawn Mower Racing Association

● The most boring people in the world

Pay attention to usability, as it often leads you to discover the differentiating factor between yours and competing products.

Performance Requirements: Type 12

Performance requirements are written when your product needs to perform some tasks in a given amount of time, or do some tasks to a specific level of accuracy, or have certain data storage capacity, or achieve a certain volume of throughput.

Think about the performance needs of the product if it is to be successful. For example:

The product shall identify whether an aircraft is hostile or friendly within 0.05 seconds.

Capacity is another performance requirement. This requirement is one of the most critical ones for an ATM network, or other distributed solutions:

The product shall support 50,000 concurrent users.

We previously mentioned a solution that predicts when ice will form on roads and schedules trucks to treat them with deicing material. The client for this solution wants to sell it to road authorities around the world. These authorities are responsible for geographical areas of varying sizes, so the client needed to ensure that the product could handle the largest area covered by any potential client. Initially, we would have written the requirement as follows:

The product shall accommodate the largest geographical area of any road authority in the world.

Of course, this is not a practical requirement to hand over to a designer, so eventually we refined it:

Description: The product shall be able to analyze 5,000 roads.

Rationale: This is the anticipated maximum number of roads in the area of any potential customer for the product.

When you are thinking about performance requirements, consider such aspects as these:

● Speed to complete a task

● Accuracy of the results

● Safety to the operator

● Volumes of data to be held by the product

● Number of concurrent users or transactions at peak times

● Minimum acceptable performance

● Ranges of acceptable performance

● Throughput, such as the rate of transactions

● Efficiency of resource usage

● Reliability, often expressed as the mean time between failures

● Availability—the uptime or time periods when users can access the product

● Fault tolerance and robustness

● Scalability of most of the above

● Performance that is an improvement over any current solution by a specified percentage

The last aspect mentioned would require your organization to benchmark the performance of any previous system. Without such a benchmark, it would be impossible to tell if a new solution outperformed the old one. You might consider benchmarking the system to be replaced during your Blastoff. This way, you and your developers have a target to aim at.

Performance requirements can include the risk of damage to people or property. If your product is a lawn mower, then there is a genuine need for the product to avoid cutting off the user’s toes. Isaac Asimov included the following requirement in his laws of robotics:

A robot shall not injure a human being or, through inaction, allow a human being to come to harm.

Hardware is not the only potential source of damage. You should consider whether your software product could cause damage, either directly or indirectly. The ice-predicting product schedules trucks to spread deicing material on roads. Because environmental damage from this material can be serious, the following requirement is necessary:

Description: The product shall schedule deicing activities so that the minimum necessary amounts of deicing material are spread on roads.

Rationale: To minimize environmental damage to the area adjacent to treated roads

In some cases, you may want to specify a performance requirement for the outcome of a product use case. For example, we found this performance-related requirement:

Description: When a scheduled truck reports that it has broken down, the product shall provide a substitute truck that can arrive at the breakdown within 30 minutes of the breakdown notification.

Rationale: To make the road safe as soon as possible

Performance requirements come mainly from the operating environment. Each environment has its own set of circumstances and conditions. The people, machines, devices, environmental conditions, and so on all place demands on the product. The way your product responds to these conditions—how fast it has to be, how strong, how big, how often—dictates the appropriate performance requirements.

Operational and Environmental Requirements: Type 13

Operational requirements specify what the product has to do if it is to operate correctly in its environment. In some cases, the operating environment creates special circumstances that have an effect on the way the product must be constructed:

Description: The product shall be waterproof, shockproof, and able to withstand freezing temperatures.

Rationale: The product shall be used in and around trucks at night and during rainstorms, snow, and freezing conditions.

Not all products must operate in extreme environments; most products are built to operate on laptops or workstations installed in offices with an uninterruptible power supply. However, within any office, it is almost always necessary to interoperate with existing solutions. The operational requirements in these cases specify what your product must do to successfully collaborate with other products.

Sometimes the collaboration is with external systems, or there is a need to access external databases. These items show up as adjacent systems on the work context model:

The product shall interact in compliance with the Visa International and Regional Operating Regulations issued January 15, 2023.

To find the operational requirements, look at your product boundary and consider the needs of each adjacent system. Interview the representative of each of these systems to find its interoperational requirements.

If you are intending to use ready-made products as part of your solution, then here is where you specify the interoperability requirements. These requirements would specify what is needed to achieve correct interfacing between the products, or what customization or configuration is needed to complete the solution.

You should also consider the uniqueness of the environment when using ready-made solutions. Because something works in one place does not mean it works in another. For example, a ready-made that works perfectly well in a UK hospital might be unsuitable for a US hospital. The environment and work practices would be quite different.

The people who make up the workforce are considered part of the operating environment. Our colleague Aase Tvieto works at a Norwegian university. She told us about the installers of an accounting system who were not told that a lot of people from outside Norway worked at visiting academic jobs at the university. These people were contracted to receive their payments in foreign banks. This omission led to a system that struggled to account for foreign currencies, and caused a considerable amount of frustration and inconvenience to both the visiting academics and the university’s administrative staff.

You might have to describe the physical environment affecting the users when they use the product. This often means special constraints are placed on the way the product is constructed. For example, if the product will be used by people in wheelchairs, or while people are driving, in the dark (remember the vampires), in a hurry, and so on, then you must specify that constraint.

Mobile devices have their own special set of requirements:

The product shall survive a drop of 10 feet (3 m) onto a hard surface.

The product shall be usable in variable lighting conditions.

The product shall conserve battery life.

If you are building products for sale, you should include any requirements needed to turn the product into a distributable or saleable item. It is also appropriate to describe any requirements that relate to the successful installation of the product.

Maintainability and Support Requirements: Type 14

Usually, at requirements time you do not know exactly how much maintenance your solution will undergo in its lifetime, nor do you always know which type of maintenance it will need. But you do know, beyond any uncertainty, that it will need maintenance. Almost anything you build today will still be around in five years (and probably more). Despite the unpredictability of events during the life of your solution, you can, to some extent, foresee some of the maintenance for certain products. Consider whether any changes might occur in the following areas:

● The organization that deploys your solution

● The technology used by your solution

● Other technology that affects your solution

● The operating environment

● Attitudes within the marketplace

● Laws that apply to the product

● Changes to the government (either by democratic or revolutionary means)

● User demographics

● Business rules

If you know or strongly suspect that the product will undergo relatively heavy maintenance due to expected changes, then specify the types of expected changes and the amount of time allowed for those changes.

If you are creating a software product that should be able to run on several different operating systems, then specify them:

Description: The product shall be readily portable to Android and iOS.

Rationale: We anticipate moving into the mobile device market.

Here you are saying to the developer that you want to be able to implement the product on another platform at some point in the future, and that you will hold her accountable for the adaptability of the product to a new device. When you attach the fit criterion (coming up in the next chapter) to this requirement, you should specify the characteristics of the device and the expected time or effort necessary to make the transition.

The deicing product had this requirement:

The product shall be translated into various foreign languages. As yet, the languages are unknown.

This requirement had a major effect on the product’s designers. They designed the interface in such a way as to make it easy to add new languages and new alphabets. Also, they took into account the fact that different languages sometimes mean different cultures and different ways of presenting data.

As well as specifying that the solution must be able to be opened up, requirements might also impose constraints. For example:

Description: The product shall be written using the organization’s standard technology stack.

Rationale: Developers can maintain the codebase.

Support requirements are also covered in this section of the requirements specification. In some cases, your client may indicate that the product will be supported by the existing help desk; in other cases, the product must be entirely self-supporting. By making this point clear at requirements time, you ensure that the designer builds in the appropriate mechanisms for contacting the help desk or providing answers for questions likely to arise with usage.

Security Requirements: Type 15

There are a number of ways to look at security. The “CIA trinity”—confidentiality, integrity, and availability—has become quite standard. Confidentiality covers access and privacy; integrity covers both integrity and audit; availability covers the acceptable amount of downtime that a solution is allowed. This also covers how much loss of data is acceptable. We have presented these in a slightly different order below, and we have also considered that availability is covered as a performance requirement (see above).

We also refer you to the National Institute of Standards and Technology (NIST; https://www.nist.gov) and suggest you check its Cybersecurity Framework.

Shari Lawrence Pfleeger, a security consultant, points out that security can be thought of as having four aspects.

Access: The product’s data and functionality are accessible to authorized users and can be produced in a timely manner. Other access requirements focus on denying access to unauthorized people.

Privacy: Data stored by the product is protected from unauthorized or accidental disclosure. Privacy can also be considered to be a compliance or legal requirement, but we will deal with it here as a security issue. Privacy also includes specifying how long data can be retained.

Integrity: The product’s data is the same as the source, or authority, of the data, and is protected from corruption.

Audit: This is what the product has to do to allow complete verification of its operations and data.

Access

Access means the solution’s data is, well, accessible. In other words, the product stores its data in a way that users can get at it and understand it.

In a security context, access requirements specify what the product has to do to ensure that the product’s data is available only to authorized users. At the same time, the security employed must not hinder or unreasonably delay the authorized users from getting what they want when they want it.

When you write this kind of requirement, you are specifying the allowable access—who is authorized, under which circumstances authorization is valid, and which data and what functions are accessible to each authorized user. For example:

The product shall ensure that only authorized users have access to the [name of] data (or function).

The term “authorized” may also need some further explanation. For example, are all authorized users authorized all the time? Does access depend on the time of day or the location of the user at the time of access? Is there a need for some kind of emergency override? Must a user collaborate with another authorized user to gain access? In other words, is the authorization conditional? If so, write these conditions as a requirement.

Alternatively, you might write this kind of requirement as a roles and permissions table. That is, roles on one dimension, functions on the other and intersections showing who can access what parts of the solution’s functionality and data.

You don’t normally specify security technology. However, your client might have already implemented some security technology—biometrics, passkeys, and so on. In this case, your security requirements should specify this technology as a technological constraint.

Privacy

Privacy is a concern to more and more people, and particularly to organizations. We are dealing with privacy under the heading of security, but these requirements could also be envisioned as compliance requirements. Most Western countries have laws governing privacy of personal information held within computer systems. The European Union’s GDPR (General Data Protection Regulation) is being adopted by more and more countries—including the United States—as their own law. GDPR is regarded as the toughest privacy and security law in the world, hence the take-up by other countries, not just those processing data within or exporting data from the EU.

We suggest that you speak with senior management to determine how serious they are about privacy. For example, is management 100% committed to the privacy of customer data, or are they prepared to sail a little closer to the wind? You also need to spend some time with the company lawyers and standards custodians, and work with them to interpret the relevant privacy laws whether they be GDPR or local regulations. This is done so that you can specify privacy requirements in a way that they are both adequate for their purpose and understandable to the developers.

If GDPR is too far-reaching for your needs, then you would write requirements for what the product has to do to ensure the privacy of its data. This capability is partly controlled by access, as we discussed earlier, and partly by the product ensuring that its data is not sent or distributed to unauthorized people. This means the product must have control over what copies—including printing—of the data can be made and distributed.

Privacy breaches can lead to loss of customer confidence, to penalties, and to fines. If your solution holds personal information about the organization’s customers, then it must protect that information. Significant fines can be levied if that private information is ever released, either accidentally or intentionally, from the organization.

For your own amusement, try some privacy requirements for the following:

● Politicians

● Crooks

● Girlfriends or boyfriends

● Chefs

● Cats

Integrity

Integrity means that the data held by your solution corresponds exactly to what was delivered to the product from the adjacent system. The adjacent system is the originator, and therefore, the authority for the data. You must consider requirements for preventing the loss or corruption of data and, should the worst happen, what the solution does to recover lost or corrupted data. You might also consider what happens when the original data changes. Does your version of the data remain, or should it be updated to reflect its new status?

In our deicing example, weather stations send data about temperature and precipitation to the deicing solution. The weather station originates the data so that any copies stored by the deicing solution must be faithful to the weather station’s version. Here is the appropriate integrity requirement:

The product shall ensure that its road temperature data corresponds exactly to the data transmitted by the weather station.

You should also consider other integrity requirements, such as those that cause the product to prevent unintentional misuse by authorized users—the most common form of data corruption. Naturally, the product must protect itself against improper usage by outsiders as well. It must also protect itself from bad data being imported.

Integrity also covers those requirements to prove the integrity of the product after some abnormal happening. These events can include such things as a power failure, an exceptional operating condition, or unusual environmental conditions such as a fire, flood, or bombing.

Immunity is also the concern of the security requirements. You specify requirements for the product to protect itself against malevolent software such as viruses, malware, denial-of-service attacks, Trojan horses, and any of the many other variations on the theme of attacking a computer system.

Backup, recovery, and archiving requirements are needed to maintain the integrity of the product’s data in the event of any unwanted disruption. You should talk to your operations people to determine what steps are needed by the product to prevent loss of data. You need to speak with your accountants and legal team to determine what archiving is needed.

Auditing

Auditing is part of the security section of your specification. Most accounting products have a requirement that they be able to be audited. This should ensure that no mistakes are made and that the results shown by the product are correct. Audits are also used to detect fraud or misuse, so audit requirements are often written to say that the product must leave an audit trail. The precise nature of your audit requirements must be negotiated with your own auditors, who naturally are stakeholders for your project.

Audit requirements are standard for any product dealing with money or valuable information or assets. Their inclusion often results in requirements for the product to retain its records for a given time.

Audit may also mean that the product maintains data on who has accessed which information. The intention of this kind of requirement is to ensure the integrity of the product’s information:

Description: The product shall retain a journal of all transactions for the statutory period.

Rationale: This is required by the auditors and by accountancy laws.

… And No More

Charles Pfleeger, a security consultant, suggests adding “… and no more” to your requirements. This phrase means that the product must do exactly what the requirement specifies and no more than it specifies. For example, if the requirement is to find a name and address from a file, then the product must not change the name and address after finding them, or transmit the name and address in contravention to the privacy requirements as discussed above.

Consider this access requirement:

The product shall allow access to authorized users.

The “… and no more” heuristic yields a complementary requirement:

The product shall ensure that only authorized users are able to gain access.

For security reasons, you might consider adding an overriding requirement to your specification:

The product shall not do anything except that which has been specified as a requirement.

Sometimes well-meaning product builders make the product perform faster or be bigger than specified, or they add unspecified features. While these properties may be beneficial to one or more parts of the product, they may well have a detrimental effect on the product as a whole or on the security of the product. We know of several cases where unauthorized or unspecified features added to a bank’s website opened serious security loopholes. Make sure that your development team does not build in extra features or properties without first negotiating their inclusion as requirements.

Clearly, security is essential. It should be assigned a priority that reflects the value of misusing the product. For example, if your product is to be used by a bank, or if it processes credit card or financial trading transactions, then the value of misuse (in financial terms) is high. Similarly, if your product is intended for the military, then misuse may result in loss of life (perhaps even your own) or loss of a military advantage. Thus, for financial, military, or life-support products, security has the highest priority, and consumes more of the budget, than many commercial systems.

You should consider calling in a security expert as a consultant stakeholder. Software developers are not usually trained in security, and the security of some functionality and data is so important that you need experts to advise on the security requirements.

Cultural Requirements: Type 16

Cultural requirements specify special factors that would make the product unacceptable because of customs, religions, languages, taboos, prejudices, or almost any other aspect of human behavior. Cultural requirements are needed when you try to sell a product into a different country, state, or organization, particularly when its culture and/or language is different from your own.

While “hello” and “stop” are almost universally recognized words and have the same meaning in all cultures, most other words don’t. In English we have a single word for “you,” whether we are speaking to one or many people (excluding the Southern “y’all”). Many other languages, however, have a different word for the plural and singular “you.” Matters become even more complicated in those languages that have a different “you” depending on the familiarity of the contact. In French, for example, you use the formal vous to speak with people in a business situation—especially superiors—and tu when speaking to family and close friends. To use tu too soon in a relationship can be thought of as rude. In Denmark, the familiar du is used almost always except when speaking to old people, when you say de. To use the formal de is considered stiff and unnatural by most people.

Sometimes cultural requirements are not immediately obvious. We take our own culture for granted, and we don’t give a lot of thought to how other people might perceive our products and ourselves. If your product is to be used outside your own country, and in some cases outside your own local region or state or even your own organization, consider whether you should call on the services of a cultural expert.

Cultural requirements are often unexpected, and at first glance they sometimes appear to be irrational, such as vampires will not enter your house unless you invite them in. But you have to keep in mind that the reason behind the requirements lies outside your own culture. If your reaction is “Why on earth do they do it like that?”, the answer is probably culture. It is also worth noting that different professions might have cultural differences. The culture of, say, engineering is quite different from that of marketing.

Following are some cultural requirements you might consider.

Religious observances:

The product shall not display religious symbols or words associated with mainstream religions.

Cultural sensitivity:

The product shall not display terms, icons, or images deemed unsuitable by the communications director (or whoever makes that kind of decision in your organization).

Spelling:

The product shall use American spelling.

Forcing political or cultural alignment:

The product shall offer the choice of language in the order appropriate for the region of the country.

This last requirement comes from Belgium, where three languages are spoken; each region naturally considers its language to be the most important. It is considered inappropriate to offer French before Flemish if the user is logged in from Flanders.

The more we build products for use in different walks of life, by different professions, and for different socioeconomic groups in different countries, the more we need to consider cultural requirements.

Cultural diversity and inclusion mean that your solution should not discriminate or fail to include minorities. Sometimes this means that you must allow individual users to nominate their own titles, pronouns, and honorifics. In any event, there is an overarching requirement:

The product shall not discriminate against recognized segments of society.

Bear in mind that some of these cultural diversity and inclusion requirements might also be compliance requirements.

Compliance Requirements: Type 17

The cost of litigation is one of the major risks for OTS software and it can be expensive for other kinds of software as well. You must make yourself aware of the laws that apply to your kind of product and write requirements to ensure that the product complies with these laws. Even if you are building software for use inside your own organization, be aware that laws applying to the workplace might be relevant.

A compliance requirement looks like this:

The product shall comply with the Americans with Disabilities Act.

This is a very broad requirement, and you would need to sit down with lawyers to determine all of the parts of the ADA that are applicable to your product. That would probably result in you writing multiple requirements to ensure compliance. You need to consult with your lawyers to determine what these requirements should be.

You are required by law to display copyright notices, particularly if you are using other people’s products. Additionally, products are required by law to display warning messages if there is any danger that some dim-witted user might do the wrong thing with it. For example, a blanket made in a southeast Asian country carries this warning:

Warning. Do not use this blanket as a hurricane shelter.

A label on a child’s scooter:

This product moves when used.

Start with your company’s lawyers; they have far more experience with the law than you. Here are several things that you can do to facilitate compliance.

● Examine adjacent systems or users—that is, the entities that have contact with your product. You can use your context diagram to identify them.

● Consider their legal requirements and rights. For example, are any of the disabled-access laws applicable? Does the adjacent system have any rights to privacy for the data that you hold? Do you need proof of transaction? Or nondisclosure of the information your product has about the adjacent system?

● Determine whether any laws are relevant to your product. For example, are data protection, privacy laws, guarantees, consumer protection, consumer credit, or right to information laws applicable?

● Check laws like the Sarbanes-Oxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), Privacy and Electronic Communications (EC Directive) Regulations, General Data Protection Regulation (GDPR), EU Consumer Laws, Federal Trade Commission Act, Financial Services and Markets Act, and more.

There’s more. Lots more. We urge you to consult your organization’s lawyers. After all, they are paid to give advice on matters of legal compliance.

Standards

Compliance requirements are not limited to the law of the land. Some products must comply with industrial or professional standards. For example:

The product shall comply with our ISO 9001 certification.

There is also the possibility that your solution must comply with organizational policies. There may be internal standards or there might be rules that apply to your or your customer’s organization. For example, there might be rules about improper use of the solution, or there might be standards over and above any national standards.

Now that we have considered the content of the non-functional requirements, let’s look at ideas for finding them.

Finding the Non-functional Requirements

Like all requirements, the non-functional ones can come to light at any time. Nevertheless, there are certain places to look that provide better opportunities to discover them.

Business Use Cases

We have stressed the efficacy of business events for the discovery of requirements, and they will pay off once again here. The business use case, the BUC, is the response to a business event. It is the functionality that is triggered by an external adjacent system (when the business event happens) and continues to execute until the functionality needed to achieve the outcome of the business event has been completed.

If you look closely at this functionality and the triggering adjacent system, the non-functional requirements become easier to see.

Take, for example, the BUC shown in Figure 26.3. This diagram plays loosely with diagramming notation, but that is deliberate to illustrate the point.

Figure 26.3

A business use case that is triggered by an adjacent system, in this case a nurse in a hospital. The BUC accesses a database of patient records and other medical information.

Now let’s look at the adjacent system, the nurse, and ask what non-functional requirements are needed for her.

Usability requirements would be high on the list. Nurses are typically busy, and solutions aimed at them must be highly usable, highly efficient, and with a logical workflow. Usable solutions are responsible for fewer errors being committed, which for hospital work is pretty important. For example:

Description: The product shall have a logical workflow.

Rationale: Hospital experience has shown that familiar working practices result in fewer errors.

There is also a usability requirement to do with your solution being consistent with other solutions that she operates:

Description: The product shall appear familiar to nurses.

Rationale: Nurses are too busy to learn new interfaces. We want nurses to start using the solution on their first exposure to it.

Of course, you could think of this requirement as a learnability requirement. The types of requirements often overlap.

Look and feel requirements also come into play. The appearance has to be medical—a nurse would not want to operate a solution that looks like a game:

Description: The product must have a medical or clinical appearance consistent with other hospital products.

Rationale: Nurses will feel more confident and be more willing to use the solution if it has an appearance that is compatible with the nurses’ work.

This requirement is slightly more difficult to quantify, but you will be able to write a suitable fit criterion for it after you have read Chapter 27, Fit Criteria and Rationale.

Operational requirements are also there to be discovered. This business use case will probably have to operate by linking to several databases, several medical devices, and imaging devices, and of course must be available throughout the hospital. You would write quite a few operational requirements to accommodate the interfaces with these other devices.

Privacy requirements must be treated very carefully. This is a medical solution, so there are probably patient records available to it. These are highly confidential, and there are severe penalties for disclosing them. To get the privacy requirements, you must sit down with the hospital administrators and lawyers and probably several other specialists.

Compliance requirements are needed to ensure that the product does not transgress relevant laws and standards that apply to medical solutions. Again, the lawyers are valuable stakeholders.

Of course, there would be a lot more to it than space permits here. The point is that you can take each business use case individually, and by inspecting its functionality and its adjacent systems, dig out its non-functional requirements using the checklist in the template to help you.

The Template

The Requirements Specification Template in Appendix A has more explanation and examples of the non-functional requirements. You can use this template as a checklist of non-functional requirement types when interviewing your stakeholders. Go through the template looking at each of the subtypes of non-functional requirements and probe for examples of each.

Prototypes and Non-functional Requirements

You can use prototypes to help uncover non-functional requirements. At requirements time, the prototype usually takes the form of a whiteboard sketch, a paper prototype, a wireframe, or some other quick-and-dirty mockup of what the product might be like. The intention here is not to design the product, but rather to ensure that you have understood the needs by reverse engineering the requirements from the prototype. We discussed this process in Chapter 10, Generating Sacrificial Candidate Solutions.

In the case of the road deicing solution, let’s say your stakeholders respond favorably to a sketch of a screen showing the roads to be treated in a glowing, cold blue color, the safe roads in green, and the treated roads in yellow. This is illustrated in Figure 26.4, albeit without the color. This prototype yields at least these usability requirements:

Figure 26.4

A sketched prototype of a screen for the road deicing solution. The screen is a proposal for the engineers and is used to elicit requirements.

Description: The product shall clearly distinguish between safe and unsafe roads.

Description: The product shall make any unsafe roads obvious.

You do not yet know that “a glowing, cold blue color” is intuitive—you need some ergonomic input, help from a UX designer, or user surveys for that. Nevertheless, the intention is clear from the prototype.

Go over your prototypes using the template. For each non-functional type, which requirements does the prototype suggest? Go through the prototype carefully, keeping in mind that the prototype is not the requirement, but rather a simulation of the requirements.

The Client

The client for the product may also have expectations that are relevant to your quest for non-functional requirements. In many cases, the reason for building a new product is to provide a service to the users or to the customers of the business, and the attractiveness of that service depends on its non-functional qualities. For example, providing portable, highly usable, or secure functionality may be crucial to the development effort. Alternatively, your client may say that if you cannot provide a live, interactive display of the current trading position, then he does not want the product. Thus, your client becomes the prime source of the critical non-functional requirements.

Once the functional requirements are met, the non-functional qualities may be what persuade potential customers to buy your product. After all, your own buying decisions are often influenced by the non-functional properties of the products you bought. Also think about the non-functional requirements of products that you admire.

Table 26.1

Finding Non-functional Requirements

Who or What Is (Are) …

Do They (Does It) Have These Requirements?

The users (Template section 2)

Look and Feel (Type 10)

Usability (11): Are there any special considerations for this kind of user?

Security (15): Do you have to protect the users, or protect against them?

Cultural (16): Is there a risk of offending or misleading your users?

The operating environment (5, 6, 8)

Operational (13): Particularly collaborating products.

Performance (12): Demands made by the environment.

Maintenance (14): Consider proposed changes to the environment.

The client, customer, and other stakeholders (2)

Look and Feel (10)

Usability (11)

Cultural (16)

The adjacent systems (6, 8)

Compliance (17): Include special rights for this kind of adjacent system.

Operational (13)

Performance (12)

Table 26.1 summarizes the questions to ask for a use case or a functional requirement. Ask your client to what degree these questions are relevant to the product you are specifying. Your client, or the marketing department, is the source of information about what will make customers buy the product.

For each use case or the product as a whole, consider the factor in the first column of Table 26.1. When you have adequate knowledge of this factor, use it as a trigger to start questioning your stakeholders about the requirement types in the second column.

Don’t Write a Solution

We have already mentioned the inadvisability of writing a solution instead of a requirement. This practice is so widespread (especially with non-functional requirements) and potentially so serious that you will forgive us if we mention it again.

Don’t presuppose a solution or enforce a solution by the way you write your requirements. By the same token, don’t adopt a current solution to a problem and write that as the requirement. Suppose, for example, that you write a security requirement like this:

The product shall require a password to access account data.

Now the designer is forced to use a password in the solution. As a result, even if a better security device than passwords is available—and there absolutely are—the product builder may not use it. In this case, writing a solution as the requirement prevents the designer from searching for an alternative, and probably better, solution.

By writing:

The product shall ensure that account data can be accessed only by authorized users.

you are asking the product designer or a security consultant—people qualified to do this—to find the most effective security solution.

Apart from potentially solving the wrong problem, one of the main concerns with writing a solution instead of a requirement is that technology is constantly changing. Solutions lock you into one technology or another, and whatever you choose may be out of date by the time the product is built. By writing a requirement that does not include any technological component, you not only allow the designer to use the most appropriate, up-to-date technology, but also allow the product to change and adapt to new technologies as they emerge.

To follow the guideline of not writing solutions, examine your requirements. If any of them contain an item of technology or a method, ask why the requirement exists. Rewrite the requirement to suit your answer, and ask why again. Do this three times. At that stage, the requirement is as good as it is ever likely to be.

Review

Imagine a world where an automated process takes longer to do than if you had done it manually; where your phone was so difficult to use that it required you to frequently refer to the instruction manual in order to use it; where your neighbor could see your transactions whenever you used your online banking; where the appearance of your mail app so repulsed you that you stopped using it; where the websites you visit use questionable cultural language; where your notes app does not connect to any other app and cannot receive messages from the internet; where the internet must be reconnected each day, and then runs slowly and intermittently; where none of your household appliances are easy or pleasant to use.

This dysfunctional world is where nobody thinks about non-functional requirements.

Despite their obvious importance, you should not overly worry about what type of non-functional requirement one is. Take, for example, an NFR about colorblindness. Is it a usability requirement, or is it about accessibility? Or perhaps compliance? It doesn’t matter. As long as you have discovered the requirement, it’s fine whatever you call it.

For example, take the case of a non-functional privacy requirement about compliance with GDPR (which you could consider to be a security requirement or a compliance one). Complying with GDPR uncovers a range of associated requirements, both functional and non-functional:

The solution shall allow a manager to create a Subject Access Request report and send it to a Data Subject on request.

That is a functional requirement. The following one looks like a functional requirement but is actually a compliance non-functional requirement:

The solution shall store all data within the European Union.

(You might find an equivalent requirement within the United States.)

The solution shall allow corrections to be made to data where a Data Subject notifies the company of an inaccuracy. (Functional requirement)

The moral of the story is to not worry about whether a requirement is functional or non-functional, but to worry about finding all the requirements.

Resources

The Requirements Specification Template packaged in Appendix A of this book is the most comprehensive source of non-functional requirements available. And you already own it.

The Arc42 Quality Model (https://quality.arc42.org) distills the qualitative aspect into the eight most important system qualities.

The Quest for Software Requirements by Roxanne Miller (MavenMark Books, 2009). This book is an excellent guide to non-functional requirements. Miller starts with general business analysis skills, then has many, many questions you ask to drive out non-functional requirements.

Business Analysis Agility: Solve the Real Problem, Deliver Real Value by James Robertson and Suzanne Robertson (Addison-Wesley, 2019). This looks at how to enhance your story map with the non-functional requirements.

The Business Analysis Body of Knowledge (BABOK Guide) by the International Institute of Business Analysis (IIBA, 2021). This primarily addresses the domain of business analysis, and touches upon non-functional requirements in the context of requirements analysis and documentation.

Software Requirements, Third Edition by Karl Wiegers (Microsoft Press, 2013). This book offers insights into modern requirements practices, including non-functional requirements.

User Stories Applied: For Agile Software Development by Mike Cohn (Addison-Wesley, 2004). While primarily focused on user stories, this book touches on non-functional requirements and how they should be incorporated into agile projects.

27

Fit Criteria and Rationale

Why do we need to measure? Remember when you bought your phone? One of the factors you considered was its storage capacity—you needed one with enough storage. When you went to the phone shop or went online, “enough storage” was not listed as an attribute of any of the phones on offer. However, “enough storage” is one of your requirements. Storage costs money, so you don’t splash out and buy the largest capacity they have. Instead, you calculate how big your photo and video collection is, how much music you want to hold in the phone, how many apps you have and their data amounts, and so on. From all of this you arrive at a number, and let’s say the number is 512GB. So now you go looking for a phone with 512GB of storage, as this fits your requirement.

Note what happened. Without thinking too much about it, you converted an imprecise requirement, “enough storage,” into a precise requirement, 512GB. This precision enabled you to go forward with your purchase.

Another requirement is that you don’t want to spend too much money on the phone; you have plenty of other things to do with your money. Here we have numbers again—you are willing to spend, say, 500 dollars/pounds/euros, and so look for these numbers displayed alongside the phones. Nobody lists the phone as costing “not too much money.” Once again, you translate a human requirement into numbers.

That was easy. Let’s be a little more ambitious. Let’s for an enjoyable moment say that a proverbial rich uncle has bequeathed you a considerable amount of money, and you and your partner decide to use the money to build your dream house. You purchase a block of land and hire a well-regarded architect.

You now have to turn your needs into numbers. You have lots of friends, so “A kitchen big enough to cook for my friends” needs to be converted to measurements (as does the dining space). How much space do you need between the center island and the cooktop? You don’t want to take too many steps between the two, but you want your partner to be able to walk behind you without having to squeeze through. (Squeezing your partner should probably be left until after dinner and the guests have departed.)

You want a pantry cupboard “big enough to hold the spice collection; the bottles of vinegars, oils, and sauces; other ingredients, and a week’s supply of food.” This has to be converted to measurements. As does the wine cellar where your newfound wine collection is to be stored (Uncle Albert left you his extensive wine collection along with the money).

Figure 27.1

Architects’ plans naturally include detailed measurements to ensure that construction is done to match the requirements.

It is the architect’s task here to find out what you need, and to develop precise plans with measurements so that the builders build exactly the house for you. See Figure 27.1. Unless they have precise measurements, the builders will build what they imagine you want or what they feel like building. Additionally, if they do not build exactly to the measurements, there is a possibility of running afoul of local construction codes and having to demolish and rebuild.

This is analogous to what happens in software construction. Unless you hand over a precise measurement of how you intend to measure the delivered product, the results are almost certain to be at best disappointing, and at worst a complete waste of time. The latter means you probably have to demolish and rebuild.

Architects use feet and inches or millimeters, but requirements can’t be measured that way. We need another way to measure, and this is the role of the fit criterion.

Why Does Fit Need a Criterion?

When you have a requirement for the product to perform some function or to have some property, the testing activity must demonstrate that the product does indeed perform that function or possess the desired property. To carry out such tests, the requirement must have a benchmark such that the testers can compare the delivered product with the original requirement. The benchmark is the fit criterion—a quantification of the requirement that demonstrates the standard that the product must reach.

“ The idea is for each requirement to have a quality measure that makes it possible to divide all solutions to the requirement into two classes: those for which we agree that they fit the requirement and those for which we agree that they do not fit the requirement. ”

—Christopher Alexander, Notes on the Synthesis of Form

You should also consider the builders of the product. It stands to reason that once they know the criterion for the product’s acceptance, they will build to that standard. If they are told their product will be used underwater, and the acceptance criterion is that the product must operate for as long as six months at a depth of 3,000 feet (900 m), then they are unlikely to deliver something with a sunroof (see Figure 27.2).

Figure 27.2

If they know the performance criterion that the product must meet before it is accepted, the builders will strive to build a product to meet that criterion.

Possibly the most challenging part of testing a requirement against an agreed-upon measurement is defining the appropriate measurement for the requirement. It is tricky, but certainly not impossible.

Let’s suppose that your stakeholder is inexperienced and asks for a product that is “user friendly.” This is an incredibly vague and overused phrase, and what it means to you is likely not the same thing as what it means to your stakeholder. However, once you can measure “user friendliness”—that is, put numbers against it—then you and the stakeholder are able to arrive at an identical understanding.

Additionally, the measurement of friendliness is passed along to the developers, who treat it as a benchmark. They now know how you and your stakeholder will test the delivered product: You will measure it against the fit criterion.

So how do you find a measurement for “user friendly”?

First, you need to understand the reason for the requirement. This is where the rationale comes into play. The rationale is the same as the “So that” part of a story. Please use whichever term you prefer. Ask the question, “What is the justification for this requirement?”, or as that seems a little formal, “Why do you have this requirement?”

Suppose that after some interrogation, your stakeholder reveals that as far as he is concerned, “a user-friendly product will be liked by the customers who are intended to use it.” A little more probing reveals that “liked by the customers” means they voluntarily change over to this new product, and don’t hesitate before using it.

Description: The product shall be user friendly.

Rationale: We need customers to voluntarily change to the new product, and not hesitate before using it.

This explanation gives us something to measure: the duration of hesitation before using the product, the time elapsed before complete adoption of it, or the user satisfaction level after a period of usage.

Fit Criterion: On average, customers commence using the product within five seconds of encountering it for the first time.

Or:

Fit Criterion: Eighty percent of customers are voluntarily using the product within six months of its release.

Or:

Fit Criterion: Customer surveys between six months and a year after launch give a satisfaction rating of greater than 75%.

Some of these criteria might seem a little expensive to test, but this is an important requirement. The rationale tells you that customers should start using the product voluntarily. If customers do not switch over to the new product, then the project is a failure. With a requirement this important, it is worth putting some effort into its development and testing.

All of this goes to say that to make it precise, a requirement cannot be just a text description. It also needs a rationale and a fit criterion to be complete.

A fit criterion and the acceptance criteria for a story are more or less the same thing. We’ll come back to acceptance criteria later.

The Rationale for the Rationale

Quite often, stakeholders tell you their perceived solution to the problem, rather than their real need.

The rationale is the reason, or justification, for a requirement. We have found that attaching a rationale to the requirement makes the real need become apparent. Quite often, stakeholders tell you their perceived solution to the problem, rather than their real need.

For example, suppose the dialogue with your client goes something like this:

“I need a screen to show me where all of my trucks are.”

You need a rationale for this. One approach is to ask why.

“So that when I get a request from one of my customers to pick up some goods and transport them, I can find the truck closest to the customer.”

“Why send the closest one? Could it be occupied at the time?”

“Well, yes, I need vacant truck.”

“What about the destination? Do all trucks go to all destinations?”

“No, some of them won’t go interstate. This is because of their license.”

“So can we say that the reason—the rationale—for this requirement is not to see all the trucks but to find the nearest available, suitable truck?”

“Yes, that’s really what I need.”

So now you have the requirement like this:

Description: The product shall assign the nearest available suitable truck to the customer.

Rationale: The truck should arrive at the customer’s location as soon as possible.

Finding the requirement’s rationale is the first step in discovering the real need. And discovering the real need is really the rationale for your job as a business analyst.

Sometimes, instead of giving you a solution as the supposed requirement, your stakeholder gives you a requirement that is so vague as to be (for the moment) unusable. In the example given previously, the client asked for a “user-friendly” product, but you could make sense of it when you learned that the rationale was that the project needed the users to readily adopt the product.

Suppose the rationale had been different. Say, instead of ready adoption, the client gave you a rationale that indicated a “user-friendly” product is so easy to use that its users make fewer errors than they do with the current product. The corresponding requirement has a different meaning, and the resultant fit criterion is completely different.

Description: The product shall be user-friendly.

Rationale: Users must find the new product easier to use than the current product so that they make fewer errors.

Fit criterion: The average error rate for all user input shall be less than 1.5%.

The rationale is not only a guide to help you find the fit criterion, but also a means to help you know when you have several different requirements masquerading as one. One stakeholder says “user friendly” means the product is pleasant to use, another says “user friendly” means the product is exciting, and yet another says a “user-friendly” product encourages users to make return visits to it. In this case, you have three different requirements, each with its own fit criterion that measures the desired property.

You must communicate a way to measure the requirement’s real meaning.

Additionally, the rationale provides the basis for making decisions about how to implement the requirement. Put yourself in the developers’ shoes: You usually must choose between several possible solutions, and if you understand the thinking underlying the requirement, you can come up with the most appropriate solution. Also, when you need to make trade-off decisions, it helps if you understand the relative importance of the requirement to the business, and the effect that it will have if the requirement is not correctly implemented.

Description: The product shall ensure that the buyer is connecting from an approved country.

Rationale: Some countries do not have copyright laws, and our suppliers prohibit us from selling into those countries.

Let’s not forget the testers’ need for a coherent rationale. There are many ways to design tests for requirements’ fit criteria, some of which involve much more time and expense than others. A tester needs to understand the reason for a requirement if she is to make the best decision about where to spend testing time and money. We have more to say about testing in Chapter 36, Quality Thinking.

Later, when a product is being used and maintained, the rationale still has a vital role. You can work out what a software product is doing by reading the code and observing the people who use it. But suppose you need to make a change to a product: If you do not understand why the product does what it does, you reduce the odds that you will make the correct change and increase the odds that your changes will corrupt some related but distant part of the product—the ripple effect. The problems that arise from a lack of understanding of the rationale partly explain why software maintenance is so time-consuming and expensive.

The rationale is the cognitive thread that connects your customer’s business and the delivered product. It is through knowing why something exists that the business analyst/product owner is able to discover the correct statement of need and the developers are able to construct the correct product.

When asking stakeholders for their rationale for a requirement, you might appear to be like the child constantly asking a parent, “Why?” So be it—that is the role of the requirements analyst. You have to ask why, and keep on asking why, until you get to the real reason for the requirement. But you haven’t finished yet, because you still have to pass along a way to measure the requirement’s real meaning. That is why you derive its fit criterion.

Finding Fit Criteria

To find an appropriate fit criterion, start by analyzing the description and rationale you have established for the requirement.

Description: The product shall make it easy for a buyer to find his chosen music.

Rationale: Music buyers are familiar with the internet and are accustomed to convenience and fast response times. They will not tolerate slow or awkward searches for their chosen music.

The rationale tells you that the requirement is about speed—which is fairly easy to quantify—and awkwardness—which is about complexity and perceived ease. For the speed component, imposing a time limit for a search is appropriate. Suppose your market research personnel tell you 9 seconds is the limit of the target audience’s tolerance; to be better than the competition, you are aiming for 6 seconds for your own product. Keep in mind that this is measuring the customer’s actions, not the time taken to search the catalog.

In terms of “awkwardness” mentioned in the rationale, your ergonomics people and market research both say that buyers must be able to find a wanted piece of music in no more than three actions (an action here means a click, a gesture, a menu selection, voice command, or some other conscious action on the user’s part).

Your measurement for these, expressed as a fit criterion, is this:

Fit Criterion: An average music buyer shall be able to locate any piece of music within 6 seconds, using no more than three actions.

Note that the time limit of 6 seconds also directs the designer to make it obvious to the music buyer what has to be done to find the music. A limit of 6 seconds means that there is very little time for hesitating and figuring out what to do next.

If you can’t measure a requirement, it is not really a requirement.

Some fit criteria may, at first, be unattainable because of business or real-life constraints. In other cases, your client may not be willing to spend the amount required for the implementation to meet the criterion. Thus, sometimes you might negotiate an adjustment to the fit criterion so that it allows for the product’s operating environment, the intended usage, and the client’s budget. Think of these adjustments as business tolerances. As you are certain that some of the intended users of the product will be below-average performers, you would adjust the fit criterion to read as follows:

Fit Criterion: Ninety percent of music buyers shall be able to locate any piece of music within 6 seconds, using no more than three actions.

Scale of Measurement

Any requirement can be measured. All you have to do is find a suitable scale with which to measure it.

The scale of measurement is the unit you use to test the conformance of the solution to its requirement. Take, for example, a usability requirement. You can measure the time needed to learn a product, or the time taken before achieving a particular level of competence, or perhaps even the error rate of the work done using the product.

You can measure anything.

Scales of measurement exist for all non-functional requirements. Performance requirements can be measured by time taken or availability percentages. Compliance requirements can be measured against the relevant laws and regulations. Look and feel requirements can be measured by conformance to preexisting corporate branding standards. Operational requirements can be measured by the accuracy and exchange speeds between processors in the operating environment. Cultural requirements, because they have to do with human acceptance, are usually measured by acceptance from marketing and customer relations.

So far, the only thing that we have not been able to find a scale of measurement for is love. We cannot find any way of measuring how much you love someone. Readers are welcome to send suggestions.

Fit Criteria for Non-functional Requirements

A non-functional requirement is a quality that the product must have, such as usability, look and feel, performance, and so on. The fit criterion is, therefore, a measure of that quality. Here we examine fit criteria for all the different types of non-functional requirements.

Let’s look at an example. Your authors came across this requirement for a consumer electronics product aimed at a teenage market:

Description: The product shall be cool.

Even vague, ambiguous requirements can be measured.

This requirement at first sight might seem hopeless and unable to be measured; there is no deterministic scale of coolness. If you look a little bit more closely, however, you find that “cool” is a term often used to mean “something that is desirable or impressive to have, or to be.”

When we asked why the product had to be “cool,” we were given a rationale that consumers had to be attracted to the product, and to want to own one and be seen to own it. To satisfy this need, we had to first measure the product’s attractiveness to its intended audience. The first attempt at a fit criterion was this:

Fit Criterion: Forty percent of the people who see the product on display in a store pick it up.

Naturally, you would not go live with the real product and see if it met the test; you would follow the lead of most electronics companies and test mock-ups with representative groups of the target audience.

We improved the fit criterion to this:

Fit Criterion: Forty percent of the target audience who see the product on display in the store pick it up and hold it for at least 5 seconds.

We also felt that if the person who had picked up the product showed it to someone else, it indicated that she felt that the product was desirable. The “Hey, look at this” gesture indicated the value she put on the product. Thus:

Fit Criterion: Forty percent of the target audience who see the product on display in a store pick it up, hold it for at least 5 seconds, and show it to a companion (if one is present).

Of course, an even better fit criterion would have been a measure of whether people actually bought the product, but given the target market, we had to take into consideration the fact that not everyone would be able to afford it. Therefore, simply picking up, holding, and showing the product was seen as the first test of how desirable it was, or how envious nonowners would be. The client called this the product’s coolness.

Of course, “coolness” must go beyond the store display. We needed to add other requirements that specified how convenient the product was to use. Clearly, a cool product must be very convenient—cool—to use.

Earlier in this chapter, you saw an example of a requirement that specified a “user-friendly” product; the client said that “user friendly” meant the staff liked it. You can measure “like”: If the staff likes the product, they will use it. You can measure how quickly they start using it, how much they use it, or how soon word gets around that the product is good and users encourage one another to use it. All of these criteria quantify the client’s desire that the staff like the product and use it (see Figure 27.3).

Figure 27.3

You can measure your users’ liking for a product by surveying their work practices before and after the product is introduced, by measuring how long it takes them to start using the product once it is available, or by surveying them after a period of use to ascertain their liking for the product.

You could write a fit criterion like this:

Fit Criterion: Within three months of introducing the product, 60% of the users shall be using it to carry out the agreed-upon work. From those users, the product shall receive a 75% or more approval rating.

Note how you clarify the requirement when you add its fit criterion. By negotiating a measurement, you transform the requirement from a vague and somewhat ambiguous intention into a fully formed, testable requirement.

You will find that it is usually not possible to get the complete, measurable requirement from your first interview. Indeed, it is highly unlikely that your stakeholders will express themselves in such precise terms. We suggest you go with the flow; don’t slow down your requirements-discovery processes to make the requirement measurable, but rather get the stakeholders’ intention—you write this as the description—and the rationale. Then, analyze your understanding, write your own best interpretation of the fit criterion, and improve it by discussing it with your stakeholder. You both need to agree that your proposed fit criterion is an accurate measurement of the requirement.

Product Failure

The fit criterion might be determined by asking your stakeholder, “What would you consider a failure to meet this requirement?” Suppose you have this requirement:

Description: The product must produce the road deicing schedule within an acceptable time.

Clearly, the scale of measurement here is time. Your client can tell you how much time she thinks would constitute a failure. For example, the client would consider the product unacceptable if the engineer has to wait more than 15 seconds for the schedule to become available. This means you have the following fit criterion, with suitable business tolerances applied:

Fit Criterion: The road deicing schedule shall be available to an engineer within 15 seconds of the request being made for 90% of the times that it is produced. It shall never take longer than 20 seconds.

Sometimes, however, you may discover there is no agreement on a quality measure, and hence there can be no fit criterion. In these circumstances, it is probable that the original requirement is not really a requirement. Perhaps several requirements have been lumped together into one requirement; in this case, each of the sub-requirements would then have its own measurement.

Alternatively, perhaps the requirement is so vague, and its intention so unrealistic, that it is not possible to know whether it has been satisfied. For example, there is no possible fit criterion for this requirement, and so it must be rejected:

Description: I want a product my grandmother would have liked if she were alive today.

Subjective Tests

Some requirements have to be tested using subjective tests. For example, if a cultural requirement for a product to be used in the public domain is “not offensive to any group,” then the fit criterion must be along these lines:

Fit Criterion: The product shall not be offensive to at least 85% of a test panel representing the makeup of the people likely to encounter the product. No more than 10% of the interest groups represented in the panel shall report that they felt offended.

The business tolerance here allows for the fact that you cannot count on 100% of humans passing any test. In this case, the business tolerances shield the product from the lunatic-fringe extreme views, while at the same time allowing “offensive” to be measured.

Although fit criteria are measures of the product’s performance, it is sometimes more cost-effective to test prototypes built specifically for the purpose.

For this kind of testing, it is usually more cost-effective to test prototypes or simulations built specifically for the purpose than to test the delivered product itself. You would hate to put in the effort to build the real thing and then find your audience thought it offensive.

You can use subjective tests for your fit criteria, but the numbers you use in fit criteria are not subjective. Suppose you have a fit criterion of “reduce the time to perform [some task] by 25% of the current time.” This means that the current time must be known and documented, not just guessed. The reason for the target of a 25% reduction must be well-understood and agreed to by the client, and not just your subjective feeling as to what is acceptable. The reasoning behind wanting 25% —and not 20% or 30% —should be backed by empirical data taken from a study of the business.

Standards

Sometimes numbers are not appropriate, or you can create a better fit criterion by citing a standard. For example, the requirement mentioned earlier that the product is “not offensive to any group” could be handled by citing your organization’s standards of conduct. Alternatively, your communications department might have standards for what is and what is not allowed to be said or displayed for public consumption. By citing that the product must comply with that standard, you are in effect setting the benchmark for lack of offensiveness.

Sometimes other standards may apply to the kinds of products you might be developing. As an example, the ISO 9241-11:2018 standard covers the ergonomics of human interactions with computer systems. A short glance at the ISO list of standards reveals many others that you might cite in your fit criteria.

Compliance requirements have a built-in standard: the law. You could cite the appropriate law as your fit criterion, but as it is likely to be unfathomable to you and your development team, the simple approach is to allow your legal department to give their opinion that the solution matches the standard of the law.

Let’s look at each type of non-functional requirement and consider how you might write the appropriate fit criterion.

Look and Feel Requirements

Look and feel requirements specify the spirit, mood, or style of the product’s appearance and behavior, and the impression the user gets when using the product. Additionally, many companies require their products to be cloaked in company colors. The rationale for this requirement is either adherence to branding standards or a desire to enhance customer recognition. These two points are slightly different, however.

Let’s look at branding standards first. Your organization has a communications department, which is responsible for the branding standards. Thus, the fit criterion should specify the target standard and state who or what is to certify the product’s compliance.

Fit Criterion: The product shall be certified as complying with this year’s corporate branding standards by the head of communications.

Where the rationale is customer recognition, we suggest a fit criterion along these lines:

Fit Criterion: Sixty percent of the target audience will recognize the product as belonging to the corporation within 5 seconds of encountering it for the first time.

Look and feel requirements may start out as touchy-feely statements of intent. However, by determining the rationale and looking for its measurable aspects, you will always find a suitable fit criterion.

Usability and Humanity Requirements

Usability and humanity are the requirements for the customers’ experience when using the product—in other words, the fitness for use by its intended users. Products are typically required to be easy to use, easy to learn, able to be used by certain types of users, and so on. To write the fit criterion for each of these requirements, you must find a measurement scale that quantifies the objective of the requirement.

Some examples:

Description: The product shall be intuitive.

To measure “intuitive,” you must consider the people to whom the product must be intuitive. In the road deicing example, you are told the users/actors are the road engineers; they have engineering degrees and meteorological experience.

Rationale: The road engineers must find it easy and intuitive; otherwise, they will not use it.

Now that you know this rationale, “intuitive” is much better defined.

Fit Criterion: A road engineer shall be able to produce a correct deicing forecast within 10 minutes of encountering the product for the first time, without reference to any out-of-product help.

Sometimes “intuitive” really means “easy to learn.” In this case, you ask how much time can be spent in training, and the resultant fit criterion might look like this:

Fit Criterion: Nine out of ten road engineers shall be able to successfully complete [list of selected tasks] after one day’s training.

Look for the real meaning of the requirement, and confirm it by having your stakeholders agree that your proposed fit criterion is the correct measurement of that meaning.

Fit criteria for usability requirements might also quantify the time allowed for given tasks, the error rates allowed (quantifying ease of use), the satisfaction rating awarded by the users, ratings given by usability laboratories, and so on. Look for the real meaning of the requirement, and confirm it by having your stakeholders agree that your proposed fit criterion is the correct measurement of that meaning.

Description: The product shall be pleasant to use.

Rationale: We want people to enjoy using it so that they continue to visit our site.

Fit Criterion: Seventy percent of a representative test panel return to our site more frequently than they do to the 10 other similar sites available to them.

Accessibility requirements specify how easy it should be for people with common disabilities to access the product. This could result in a fit criterion like this:

Fit Criterion: The product shall be certified to be in compliance with the Americans with Disabilities Act (ADA).

It may also be necessary to specify the relevant parts of the act and the body responsible for certifying compliance.

Performance Requirements

Most of the time, your performance requirements will be easy to quantify; we tend to use numbers when we describe things such as speed, accuracy, capacity, availability, reliability, scalability, and similar characteristics of the product. Typically, then, the nature of the performance requirements will suggest a measurement scale. Let us look at some examples.

Suppose you have this requirement:

Description: The response shall be fast enough to avoid interrupting the user’s flow of thought.

The word “fast” indicates you should measure time. Here is a suggested fit criterion:

Fit Criterion: The response time shall be no more than 0.25 second for 95% of responses, and no more than 1 second for the remainder.

Similarly, the fit criterion for an availability requirement might be written as follows:

Fit Criterion: In the first three months of operation, the product shall be available for 98% of the time between 8 a.m. and 8 p.m.

A fit criterion may be shown as a range. This is particularly appropriate for performance requirements. For example:

Fit Criterion: The product shall allow for 30,000 downloads per hour, although 50,000 per hour is preferred.

The point of using a range is to deter the developers from constructing a product that could be overly expensive, and to make the best design trade-offs to fit the budget and design constraints.

If the requirement is given to you in correctly quantified terms, then the fit criterion and the requirement are the same.

As most performance requirements are themselves quantified, it should be straightforward to write appropriate fit criteria. If the requirement is given to you in correctly quantified terms, then the fit criterion and the description of the requirement are the same. In that case, write one or the other.

Operational and Environmental Requirements

Operational requirements specify the environment in which the product will operate. In some cases, the product must be used in adverse or unusual conditions. Recall our example from the road treatment solution:

Description: The product shall be used in and around trucks at night, and during rainstorms, snow, and freezing conditions.

The fit criterion for an operational requirement is a quantification of the successful usage in the required environment. For this operational requirement, its fit criterion quantifies the ability of the product to withstand the conditions. For example:

Fit Criterion: The operator shall successfully complete [list of tasks] within [time allowed] in a simulation of a five-year storm,¹ and the product shall function correctly after 24 hours’ exposure.

FOOTNOTE 1

This is an accepted quantification of meteorological conditions. It means that (theoretically) you experience this severity of storm once every five years. Unfortunately, climate change means that five-year storms now happen more frequently.

Operational conditions may also specify that the product must coexist with partner, or collaborating, systems. The fit criterion in this case will cite the specification of the partner system or the way to communicate with the partner:

Fit Criterion: The interfaces to the Rosa Weather Station shall be certified as complying with the National Transportation Communication ITS Protocol (NTC/IP).

This criterion is testable—by engineers from NTC—and points the product’s builders toward a known and accepted standard.

Additionally, most things in your operating infrastructure have standards. For instance:

Fit Criterion: The product must comply with HTML Living Standard 2024.

Maintainability and Support Requirements

Maintainability requirements specify expectations about the maintenance of the product. Usually, the fit criteria for these requirements quantify the amount of time allowed to make certain changes. This is not to say that all maintenance changes can be anticipated, but where changes are expected, it is possible to quantify the time allowed to adopt those changes.

Fit Criterion: All functionality must be migrated to the new website with no more than 10 minutes of unavailability of the site.

Security Requirements

Security is too important to be left to the whims or the goodwill of the developers. Your organization probably has some security standards in place, either specific to the industry or specific to your type of product. Alternatively, you might make use of existing international standards. For example:

Description: The product shall comply with ISO/IEC 27002:2022.

Fit Criterion: The product shall be certified as complying by an appointed certification body that is compliant with ISO 17021.

The example is very general, and you might need more detailed requirements. However, the point is that the fit criterion ensures that your security requirement is testable.

We treat access as part of security. Here you might write your fit criterion for an access requirement in the form of a table. The table would show the roles or names of authorized people, together with the type of access (read/add/change/delete) each is allowed.

Cultural Requirements

Cultural requirements, by their nature, are subjective and slightly more difficult to quantify. The fit criterion is usually based on who or what will certify the product’s acceptability.

Description: The product shall not display religious symbols or words associated with mainstream religions.

Fit Criterion: The communications department shall give the opinion that the product displays no words or symbols that could be construed as religious.

In almost all cases, your communications or HR department can be considered to be the authority when dealing with cultural issues. This fit criterion is a general-purpose one that could be included in most specifications:

Description: The product shall not discriminate against any segment of society.

Fit Criterion: The communications department/HR shall certify that the product is culturally acceptable for all segments of the target audience.

Compliance Requirements

Compliance requirements specify which laws the product must conform to. As a result, this fit criterion applies to most compliance requirements:

Fit Criterion: Your client will win a court case brought by someone who uses your solution.

However, fit criteria must be able to be tested in a cost-effective manner, and court cases are too expensive to be indulged in lightly. Thus, the majority of fit criteria will be along the following lines:

Fit Criterion: The legal department/company lawyers shall certify that the product complies with the [appropriate laws].

A compliance requirement that applies to almost anything you do is GDPR (General Data Protection Regulation). This originated with the European Union, and it applies to all member countries and to all organizations doing business within the EU. GDPR is considered to be the gold standard for data protection, and as such it has been adopted, either wholly or in a slightly modified state, by many other countries and states. Just one example: the California Consumer Privacy Act (CCPA) has many similarities with the GDPR.

The requirement would be:

Description: The product shall comply with GDPR (or the local equivalent).

Fit Criterion: GDPR compliance shall be certified by [the name of your organization’s compliance department].

Smaller organizations probably do not have their own compliance sections, in which case it is down to the business analysts and especially the product owner to ensure compliance. There can be significant penalties for noncompliance with privacy laws.

Compliance requirements are also written to ensure that the product complies with cited standards. Most standards are written by organizations that either have people who certify compliance—“standards lawyers”—or issue guidelines as to how you can certify compliance for yourself. In either case, fit criteria can be written to specify how compliance with the standard is to be verified.

Fit Criteria for Stories

The normal form for stories (As a - I can - So that) does not include provision for fit criteria as we have been describing them here. However, that is no reason to disregard measuring your stories. As you are reading this, keep in mind that we discuss acceptance criteria in Chapter 29.

This depends on whether you write separate non-functional stories or add non-functional qualities to your functional stories.

For separate non-functional stories, the fit criterion and the acceptance criteria are the same thing. Write it whichever way you choose. We will also look at acceptance criteria for stories in a few chapters.

Some non-functional requirements are solution wide. For example, security requirements or look and feel requirements apply to the whole of your solution. However, in some cases you would append non-functional requirements to functional stories. In these cases, we suggest that you add a fit criterion along with each one. This leaves the developers in no doubt as to what is required to complete the functional story.

Fit Criteria for Functional Requirements

A functional requirement is something that the product must do—an action it must take. The fit criterion specifies how you will know that the product has successfully carried out that action. For functional requirements, there are no scales of measurement—you can’t use numbers here. The action is either completed or not completed.

For example, suppose that you have this functional requirement:

Description: The product shall keep the music subscriber’s listening history.

Rationale: The product must be able to recommend new music based on the apparent preferences of the subscriber.

The rationale is enlightening; it tells us that we have to know not just what the music fan has listened to, but the type of music it is. The product must be able to find new musicians that perform the kind of music the buyer likes. This would give you the following:

Fit Criterion: At the end of a listening session, the product shall have added the listened-to artists, the songs, the genre, and the mood of the music to the subscriber’s history. The history data can be ranked to provide the best recommendations.

Another one:

Description: The product shall stream the subscriber’s selected music.

Rationale: This is what the subscriber is paying for, and how the artists earn their money.

Fit Criterion: The music is streamed; after 2 minutes the artist royalty is recorded, the stream is added to the subscriber’s history, and similar music will be played at the end of the chosen stream if there are no more subscriber selections.

Here the fit criterion is elaborating on the simple description, and in doing so, is setting down the post conditions for when the requirement is executed.

Fit Criteria and Data

For many functional requirements, completion depends on satisfying an authority that the product has correctly performed the action. The authority in this case is either the source of the data or the adjacent system that initiated the action.

If the action is to record something, then the fit criterion is that the recorded data complies with the data as it is known to the authority. For example:

Description: The product shall record the weather station readings.

Rationale: The readings are necessary for preparing the deicing schedule and must be kept for audit purposes.

Fit Criterion: The recorded weather station readings shall be identical to the readings as recorded by the transmitting weather station.

The authority in this case is the weather station: It initiated the action, and it is the source of the data. You can say the requirement is for the product to faithfully store the data (allow for the product to make necessary manipulations to the data) as sent from the weather station. If this procedure is done correctly, then the product’s data conforms to that transmitted by the station.

The fit criterion does not indicate how this conformance is to be tested. Instead, it is simply a statement that the tester uses to ensure compliance.

If the functional requirement is to make some calculation, then the fit criterion says the result of the calculation must be consistent with the authority’s view of the data. Where the requirement is “the product shall check …,” the fit criterion is “the checked data conforms with …” and again cites the authority for the data. “The product shall calculate …” results in a fit criterion of “the result conforms to …” and gives the algorithm (or source of the algorithm) for the result.

The general rule for functional requirements is that the fit criterion ensures that the function has been successfully carried out.

Defining the Data

For the fit criteria to be complete, your specification must contain definitions of the terms used in the fit criteria.

Because functional requirements often have to do with manipulating data, it is as well that we take a quick look at defining that data. This means making use of the data dictionary. The dictionary is found in section 7 of the Volere Template in Appendix A. The dictionary gives definitions of the data by defining the content of data flows and data entities.

For example, within the Ice Breaker solution there are references to something called Road Section. If you were to look in the data dictionary for the specification of this solution, you would find this definition:

Road Section = Road Section Identifier + Road Section Coordinates

You can then expect to find a definition of each attribute of Road Section. For example:

Road Section Identifier = *Unique identifier for 500 meters of road. The maximum number of road sections per road is 10,000.*

Another strategy for defining the data is to define each term as part of the fit criterion of each individual requirement. However, as you will usually reference the same term in more than one requirement, it makes sense to maintain a central dictionary that can act as a cross-reference between requirements. Your growing understanding of the data means that you progressively build a business data/information model that specifies the essential stored data for the requirements you are specifying.

Test Cases

You might find it feasible to write test cases for your functional requirements.

You might find it feasible at this stage to think about writing test cases for your functional requirements. This approach is promoted by several agile techniques wherein the tests are written before the code is. The basic idea is to focus the developer to concentrate on learning the fit criterion for any part of the functionality.

You can do the same thing with your requirements discovery: You can write test cases. However, we understand that many business analysts feel they should not be writing test cases. If you like the idea but don’t want to do it, might we suggest talking to your testers. In our experience, testers are really happy to add test cases to requirements. There is a benefit to you that comes from sitting beside testers while they write test cases: They can only do it if they are certain of the real intention of the requirements. This gives you the opportunity to verify that you do have the right requirement—the one that satisfies the real business need. When you see how the tester intends to validate the requirement, you can be certain that the delivered solution will indeed satisfy the business need.

This is “testing before testing.” That is, the tester is testing the requirement before the solution is built. “Testing before testing” is most effective, and involving the testers early in the development cycle is always beneficial. And by the way, testers are the best people to tell you whether or not your functional requirements are testable.

Testers are the best people to tell you whether or not your functional requirements are testable.

Fit Criterion for Project Purpose

We have already discussed writing the fit criterion for the project’s purpose. We didn’t call it a fit criterion back in Chapter 5, we called it a measurement. However, it’s really the fit criterion for the project. Let’s look quickly at this idea again: The project’s purpose is a statement of the reason for making the investment in the project. If you go to the trouble and expense of developing a product, then it makes sense to have an objective benchmark to measure the delivered product against.

The measurement of the purpose is the same as a fit criterion for an individual requirement. The difference is that the fit criterion measures a single requirement, whereas the purpose’s measurement is the benchmark for the entire solution.

Fit Criteria for Solution Constraints

Constraints are a special type of requirement—they are global requirements—and they need to be specified correctly just like any other type of requirement. Section 3a of the Volere Template (Appendix A) includes the solution constraints. These constraints place restrictions on the way that the problem must be solved; you could also say they mandate a solution to the problem. For example:

Description: The software part of the product must run on Android and Apple iOS.

This requirement reflects management’s decision to use the two most popular mobile operating systems. This decision may or may not have a sound technological basis, but that is beside the point for our purposes here. You are being told that any solution you deliver has to comply with this constraint.

We can test compliance—either you comply with the requirement, or you don’t—as long as whatever it is that you have to comply with is measurable. For example, you can test whether you have complied with a law, but you can’t test whether you have complied with a constraint that states, “You shall be happy.” In the case of the mobile OS constraint, you could write the following criterion:

Fit Criterion: All functionality of the software shall operate as specified when run using Android 12 and later and iOS 16 and later.

Similarly, all other constraint requirements—for example, implementation environment, partner applications, commercial off-the-shelf software, open-source software, workplace environment, time budget, and financial budget—have fit criteria.

Review

The fit criterion is an unambiguous benchmark that the product has to meet.

A fit criterion is neither a test nor the design for a test, but rather a benchmark that the delivered product must be tested against. It is used as input to build test cases through which the tester ensures that each of the product’s requirements complies with its fit criterion.

Quantifying or measuring the requirement gives you a better opportunity to interact with your stakeholders. By agreeing on a measurement, you confirm that you have understood the requirement correctly, and that both you and your stakeholders have an identical understanding of it. As a by-product, you will also find quantifying it ensures that the requirement is both wanted and necessary.

Including a fit criterion in a requirement or a story encourages testers to participate in the requirements process. Testers should be involved early in the development cycle, and they are particularly helpful at requirements time when you are writing your fit criteria. This is not to say that the testers must write the fit criteria for you, but just that testers are the best source of knowledge about whether something can be tested and whether the fit criterion contains the appropriate quantification. In other words, the testers are excellent consultants for the fit criteria.

The fit criterion is the real requirement.

The fit criterion, not the description, is the real requirement. The description you write is the stakeholder’s way of stating the intention of the requirement. If your stakeholders are like most of us, they speak using everyday language, which is, unfortunately, often ambiguous and often not precise enough. You need to clarify the requirement with a fit criterion that is stated in unambiguous, precise terms and probably uses numbers or a measurement to convey its meaning.

Fit criteria are also a vehicle for reaching a consensus among multiple stakeholders. Your attempts to clarify and measure will almost always result in hidden meanings becoming visible, hidden requirements bubbling to the surface, and, most importantly, the stakeholders agreeing on what is needed.

You derive the fit criterion by examining the requirement’s description and rationale, and determining which quantification best expresses the user’s intention for the requirement.

Fit criteria are usually derived after the requirement description is written. You derive a fit criterion by examining the requirement’s description and rationale, and determining which quantification best expresses the user’s intention for the requirement. You may sometimes find that this close examination results in changes to the requirement, but these changes are for the better and should be considered quite normal; their occurrence simply means the requirement was not properly understood in the first instance. With patience and persistence, and with the wise use of measurements, you can ensure that each of your requirements is unambiguous, testable, and real.

Resources

Requirements Engineering: From System Goals to UML Models to Software Specifications by Axel van Lamsweerde (Wiley, 2009). This is a comprehensive overview of requirements engineering, including discussions on specifying and validating requirements with measurable criteria.

Notes in the Synthesis of Form by Christopher Alexander (Harvard University Press, 1964). Alexander introduced the concept of “fit” to measure the fit of architectural designs against the way people needed to live.

28

Writing Good Stories

This is a book about requirements and business analysis, so when we talk about stories, we talk about them in a way that is useful for the business analyst. The prime task of the BA is to understand the business problem. As this understanding matures, the analysts and appropriate stakeholders determine the solution that best solves the problem.

In Chapter 21, Stories, we described the business event story and how you can use it to determine the beneficiary and outcome of the business events. This means that a business event story is the linchpin of the analysis that follows. The story’s event is isolated, and the analyst trawls, interviews, models, prototypes, and does whatever else is required to discover the set of requirements needed to respond to the event.

In this chapter, we want to revisit business event stories and discuss what makes a good, and therefore valuable, story. But before doing so, we need to make clear the intention of these stories.

First, these are not “user stories.” Normally, stories are used as descriptors of some action that a user does with a computer. The problem with this is that it assumes a solution: If there is a user, then there is a solution for the user to use. Assuming a solution also assumes that the problem is known and understood. We have learned from bitter experience that at requirements time, the problem cannot be assumed, that the stakeholders do not always understand the real problem, and that rushing into a presumed solution often—too often—produces a result that is an almost complete waste of time.

But you know that. You are reading a book about business analysis and requirements, which you would not be doing unless you understood the facts of business analysis life.

So, let’s press on and talk about business event stories, and what makes a good one.

Business Event Stories

Back in Chapter 21 we discussed the format of the business event story. It’s the same format as the user story, but it has important differences in meaning. The format we’re talking about is this:

As a [customer segment]

I can [some functionality that responds to my business event]

So that [received business value].

Let’s start by looking at a bad story and making it better. We’ll take this example of a solution for an employment agency that matches applicants to jobs. It has this story:

As a user

I can search for jobs.

On its own, this is of little use. You don’t know whether to include the story in the solution or not. You don’t know who a “user” is or why users would want to search for jobs. Having a facility for someone to search for jobs does not necessarily provide value. So, let’s step back.

The employment agency wants to match the best candidates with suitable jobs. Value to this client comes when the best candidates are put forward to the employer. Obviously, employers will stop using the agency if it sends along unsuitable candidates. So, we can improve the story to this:

As a candidate

I can search for jobs.

What is the justification for this story? Why does a candidate want to search for jobs? Let’s say that the candidate wants to search for jobs so that he can find prospective employment. Keep in mind that “searching” and “finding” are two different things. The candidate does not want to search for jobs, the candidate wants to find a job.

So let us modify the story so that it provides some relevant value to the candidate:

As a candidate

I can find jobs that meet my and the employers’ criteria

So that I will have the best chance of being called for an interview for the job I want.

The candidate’s criteria would be attributes like location, salary range, job description, type of company, employment conditions, social activities, and so on. The employer’s criteria would have attributes like experience required, other skills, attitude toward work, past employment, salaries, and other first-line determinants that provide some filtering of candidates. You can define these criteria in the data dictionary (section 7 of the template in Appendix A).

Now we’re getting somewhere.

We have moved from searching to finding, which implies that the solution will do the matching, not the candidate or the employer. Naturally, a good solution would provide an override, but for the moment, we can say that most of the employment would be done by matching the most suitable candidates to the available positions.

When the story talked about searching, it was talking about a solution to the problem, and as such, it masked the essence of the problem. Additionally, when the story was changed to “find,” it suggested that candidates don’t have to log on each morning and search for jobs; they can be notified when the solution makes a match. This gives more time for the candidate to polish or enlarge her skills and become more attractive to employers.

We will need other stories for the employment agency. A candidate must be able to post her profile to show her attributes, and the employer needs to post job vacancies with the desired attributes for candidates. There would also be stories so that employers and candidates can modify or delete their job postings and candidate profiles.

Going a little further with these employment stories gives us the following:

As an employer

I can post a precise job profile

So that I can find a limited number of the best candidates for the position.

The “So that” line is important. It demonstrates the value that the story delivers to the beneficiary. The employer does not want to waste time interviewing unsuitable candidates, she wants the best of them. Also, she does not want to interview dozens of people for the job; there is no time for that.

Admittedly, the “finding” story would be harder to implement than the simplistic “A candidate can search for jobs,” but it provides real value to the candidates, the employers, and the owner of the solution. The latter is significant, as its business viability is at stake here.

So, let’s look deeper into stories and what makes a good story.

Properties of Good Stories

We are talking about writing good business event stories as an aid to discovering the requirements. The story will help you if it concentrates on the customer’s business problem. Here we look at each component of a story, how to discover them, and how they work together.

We start with the beneficiary of the story.

As a [Customer Segment]

The customer segment gives an indication of what that person or thing is wanting to accomplish, and what functionality is appropriate.

As an occasional flier

As a regular flier

As a platinum-level frequent flier

These are different customer segments and would have different functionalities available to them. For example, platinum flyers can book their seats in advance, and occasional flyers have to pay if they want to select their own seats.

The customer segment is the first part of the information your story has to communicate. The next part looks at what the segment needs to do.

I Can

Note that you should write “I can” and not “I want.” Writing “I want” often results in a solution. For example:

As a cyclist

I want to follow my friends’ cycling routes

So that I can join them on rides.

After “I want,” the writer launches into an assumed solution. Perhaps she envisioned a map with the cycle routes highlighted. Who knows? What she really wants to do—this is the business problem—is to cycle with her friends. But let’s think about that for a moment. What do you need if you are to cycle with your friends? The thing that jumps out is that your friends have to tell you their cycling intentions before they set out. There is little point in knowing that Sally and Fatima like cycling along the canal towpath unless you know when they next plan to do so. In other words, the route without a start time is useless.

Instead of “I want,” let’s try “I can.” What must a cyclist be able to do if she is to cycle with her friends? The answer is she needs to know her friends’ intentions; that is, when and where they plan to cycle.

However, that suggests that our cyclist is willing to go along with whatever the friends suggest. Perhaps what she needs to be able to do—this is the “I can” part of the story—is to arrange a cycling outing with the friends she wants to cycle with. Perhaps some of her friends are planning a mountain route, but this weekend she wants something gentler.

So, the story really is about making arrangements:

As a cyclist

I can arrange a mutually acceptable cycling excursion

So that I can cycle with my friends.

Note that the original proposed solution masked everything—there is no need to build an app or anything at all. Simply forming a cycling group on one of the messaging apps would allow our amiable cyclist to find riding companions. In requirements discovery terms, this is great. By discarding the assumed solution and unearthing the real need, the good story writer has found a business problem that requires almost no development activity.

To summarize, “I can” must show a business result. It should show some functionality that enables the customer segment—the “As a” line—to achieve the story’s business value. A statement of this value comes next.

So That

So that … is important. This is the part where you specify the value, or benefit, of the story. If the story lacks value, it should be discarded. If the story demonstrates high value, then it should be prioritized to a higher rank. The value of a story helps the product owner/team leader plan the development; it helps the developers understand the rationale of the story and thus influence some of the features; it tells the testers how much effort to put into testing the product. In short, knowing the value of a story is valuable.

The following is a bad story we found, and it shows why getting to the real value is crucial:

As a bank account holder

I want to check my balance online

So that I can keep a daily balance 24 hours a day.

First, let’s get rid of the “I want” line; it’s an assumed solution and has little to do with the value of this story. The writer is assuming that logging on is the only way to achieve the need, but it’s not necessarily the way to do it.

The “So that” line, the justification, is also wrong: “24 hours a day”? Only insomniacs want to know their bank balance at 3 a.m. But “daily balance” is the part that raises the serious questions.

Asking why repeatedly is almost always the thing to do. If you ask this account holder why he wants to keep a daily balance, what answer could he give?

● I’m filthy rich and want to see all my money and gloat.

● I want to know if anybody has fraudulently taken money from my account.

● I’m quite poor and want to know how much is left in the account.

● I want to know if I can afford the new iPhone.

● … and possibly more.

Working through each of these possibilities, we start with the filthy rich justification. This is unlikely to be true because anybody who is filthy rich would have most of their assets tied up in investments and property. The bank balance is only part of, and probably a very small part of, their total wealth.

Obviously, fraud is a concern of most bank account holders, but knowing just the balance is only partially helpful. To know if somebody has plundered your bank account, you need to know all the transactions that have occurred since you last looked at the account.

The next two answers come down to the same thing: Simply knowing the balance is not necessarily helpful. What account holders need to know is how much money will be left after all the contracted payments have been made. Contracted payments are things like the electricity bill, the phone bill, insurance, the car payment, rent and so on. The information that is valuable to the account holder is what will be left until the next payday. The phone lover wants to see if he can afford the iPhone; the poor person needs to see if there’s enough for new shoes for the kids.

So, our story needs drastic surgery. We suggest this:

As a bank account holder

I can be aware of my bank situation

So that I know my current and discretionary balances.

The story now provides something that is valuable to the account holder. Of course, it is now more difficult to develop than the original assumed solution. However, the original provided so little value that developing it would not provide much of a return to the bank. All banks offer to hold your account so that you can access it online or by phone. The bank that provides the more valuable facility as shown in the final story is much more likely to attract customers in the competitive market.

The bank account holder also mentioned that he wants to check for fraudulent activity. The assumed solution for that is to provide a list of recent transactions. The account holder would have to scan the list looking for abnormalities. However, most of what he looks at are the normal transactions: paying the electricity bill, direct payments of subscriptions, payments to known tradespeople, legitimate shops, and so on. These fit into a pattern of certain amounts for certain things. Look at your own bank transactions, and you’ll see that they are the same or similar every month. So, to know about fraudulent activity, the account holder really needs to be alerted when there are any transactions outside her normal pattern. The resultant story is this:

As a bank account holder

I can be aware of any abnormal transactions on my account

So that I can know immediately if fraudulent activity has taken place.

When you look at any value statement in a story, ask why that is valuable. And keep asking why until there is no further answer. “Why do you want to know your discretionary balance?” “I want to know if I can spend money.” It’s the same thing; in other words, there is no further answer to the question.

In earlier chapters, we discussed the essence of the problem, and essence applies here. Is the value statement getting to the essence of the business problem? If not, ask why a few more times. Does the “So that” line leave the solution to the problem unsolved? This example is taken from an energy monitoring situation:

So that I can see my daily energy usage

This is not solving the real problem. Knowing your daily usage is not all that helpful. Knowing which appliances and which heating/air conditioning levels consume the most energy is useful. Knowing how to use your heating/air conditioning more economically is more useful. Knowing which alternative suppliers are cheaper and provide a comparable level of service is still more valuable. The “So that” line should read as follows:

So that I can find the cheapest source of energy

To get to genuinely useful stories, you must

● Ask why, and ask it repeatedly.

● Get to the essence of the problem.

● Discard any assumed solutions.

Recognizing real value is your job; this is requirements discovery. You discover what is really needed and record it in a way that everybody can understand the need, and what a solution must do to satisfy that need.

INVEST

The INVEST acronym was coined in an article by Bill Wake, and it is useful for our requirements discovery purposes here. The following inspection of the INVEST elements does not put exactly the same meaning as Wake used, but then he was approaching stories from a developer perspective. This is how it works from a requirements perspective.

Independent

For use with requirements, a story should be a separate piece of functionality, and one that is recognized as being able to stand alone. That is, the customer and the BA can explore it and find its requirements without having to refer to other chunks of functionality. Business events have this attribute.

Naturally enough, independence makes stories based on business events ideal units for development. In some cases, they will be too large for one development iteration and need to be split, but each of the sub-stories are functionally related and would be ideal targets for subsequent iterations.

We are suggesting that initially, you write stories for each business event and take advantage of its independence.

Negotiable

Negotiable means that the initial business event story is a placeholder for requirements, and the detailed requirements are negotiated with the customer. The story written at the business event level is not a detailed story, nor is it incomplete. It is a placeholder waiting for its detailed requirements to be discovered.

Valuable

Stories have to provide some value. Otherwise, you are wasting yours and your client’s time.

The value of a story comes in the “So that …” line of the story.

But not all stories are equally valuable. By having the value as part of each story, it allows you to prioritize your stories. This allows you to work on the most valuable stories first, leaving the less valuable ones until later (if at all).

Estimable

For developers, this means that they can estimate the effort needed for development. This is needed for planning iterations and other development tasks. It is less important for the requirements discovery activity. Besides, when you are writing a business event story, you really have only a vague idea how much effort it would take to implement that story, but this is probably enough to help with prioritization of your business event stories.

Small

This quality applies only to the development activity, where small stories are needed for iteration planning. For our needs here, the business event story is whatever size it is. Later, when we talk about story maps, we will demonstrate how to break down stories to make them small enough for development planning.

Testable

Requirements stories are testable in that the value line of the story can be tested. If the story reads “So that I can continue my insurance coverage,” then you are able to test whether the insurance is in fact continuous.

A better meaning for “testable” is that the story enables the customer to identify its value and confirm that the story’s functionality is something needed by the business.

Please don’t feel that you have to run each story you write past the gauntlet of an INVEST test. These attributes are here to give you some guidelines on writing good stories.

Non-functional Properties

All the stories that you have seen so far in this chapter specify the solution’s functionality. We know that for a solution to be successful, it must be usable, attractive, and secure; fit seamlessly into its operating environment; comply with any relevant laws and electives; and so on. These are the non-functional properties.

Back in Chapter 26, we discussed non-functional requirements. Everything in that chapter applies to stories. However, if you and your team are writing stories, then you need a way to record the non-functional requirements.

You have some options.

Append the non-functional requirements to each appropriate functional story.

Some non-functional requirements are solution wide. Write these as we set out in Chapter 26.

Write separate non-functional stories.

Option 1 is preferable, as each non-functional requirement then carries its own fit criterion.

Option 3 would look like this as a usability requirement:

As a cabin attendant

I can easily understand the cabin control panel

So that I can use it correctly after one day’s training.

It would look like this as a compliance requirement:

As a human resources officer

I can securely access employees’ records

So that the company complies with all GDPR provisions.

However you decide to do it, ensure that the non-functional requirements are not left to chance or to the goodwill of the developers.

Review

As a reminder, we are using stories to help with requirements discovery. We suggest that the stories are written one for each business event. The format of the story helps you to ensure that you have discovered the right business events.

For example, the “As a” line nominates the customer segment for the story. The customer segment is the beneficiary of the story, and you must determine that this is a worthwhile beneficiary.

The “I can” line is an overview of the functionality of the response to the event. Elsewhere we refer to this as the business use case. We cannot stress enough that this line should not be a solution to the problem. If it is a solution, it is likely masking the real business need of the story.

The “So that” line justifies the story—it is the business value of the story. You can think of this as the benefit provided to the customer segment in the first line. You should examine this line carefully. Any stories where the stated value is weak (or missing) can be either given a low priority or discarded.

Business event stories are high-level stories. They are there to guide your requirements discovery. That is, for each story, you trawl or build prototypes to drive out the detailed requirements.

Later, we will look at how you can make use of these stories when you build a story map. The map is simply another way to uncover the details from the business event story.

Resources

User Stories Applied: For Agile Software Development by Mike Cohn (Addison-Wesley, 2004). Cohn is one of the best writers on stories, and this is a comprehensive treatise on the subject. It covers the principles of user story writing, along with various techniques and best practices.

The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson (Pragmatic Programmers, 2017). This is a comprehensive introduction to agile software development and includes practical guidance on writing user stories.

If you need more on writing stories than we have provided in this chapter, there is a huge amount of information to be found online. Be aware that the different authors have different takes on user stories, and not all of them are suitable for requirements discovery.

Agile Alliance (https://www.agilealliance.org).

Scrum.org (https://www.scrum.org).

YouTube. There are lots of video tutorials and presentations on user stories on YouTube.

29

Acceptance Criteria

Acceptance criteria are a way to set a benchmark, a standard, that any delivered solution must meet. Naturally, it must be clear and binary. Clear in that the customer agrees that she is willing to accept a solution that meets the criteria, and binary in that either the delivered solution meets the criteria or it is rejected.

In Chapter 27, we looked at fit criteria. Acceptance criteria are more or less the same thing: Both are concerned with making requirements measurable and testable. The difference is mainly in how you write them.

Stories are written to describe something—some functionality or non-functional attributes—that the customer needs to be included in the delivered product. The acceptance criterion looks in the other direction. It states whether that thing, whatever it is, has been successfully included in the delivered product.

Acceptance criteria should be written in the customer’s voice. The criteria should demonstrate the scope and the functionality that the customer needs from the story. They should also be written early. They give precision to your stories; just as fit criteria bring precision to your requirements. Try writing acceptance criteria in parallel with writing the business event story. It’s a great way to drive questions out early.

Write acceptance criteria in parallel with writing the business event story.

Let’s look at how to write acceptance criteria.

Given/When/Then

Given/when/then (from now on, we’ll call this GWT) is one of the most common forms of writing acceptance criteria (which we can abbreviate to AC) and is quite suitable to use when discovering requirements. And it works extremely well with business event stories.

Given/when/then is a construct that defines the start and end states of, well, anything, but in our case, we’ll use GWT for our business use cases. You write a GWT statement so that the stakeholders can understand the transaction and confirm that the GWT conditions are what they desire. The statement is as follows:

Given that [a context]

When [an action is carried out]

Then [a set of observable outcomes should occur]

Let us say that we have a business event, “A potential customer wants to subscribe to our streaming service.” The following is the business event story for this:

As a movie fan

I can subscribe to the service

So that I can stream movies as I wish.

“Given” specifies the state of the solution’s universe before the story begins to execute. For example, you could say:

Given the potential subscriber is a real and identifiable person, living in an approved country, with an acceptable means of payment

“When” is an action that takes place, and “Then” is the result of that action. For business event stories, read the “When” part as the business event. For the above movie streaming service:

Given the potential subscriber is a real and identifiable person, living in an approved country, with an acceptable means of payment

When a potential customer wants to subscribe to our streaming service

Then an account is established for the subscriber, his payment method is charged for the first month’s subscription, and he is given logon details.

Let’s take this example of a story:

As a road engineer

I can generate a road treatment schedule

So that the depot and the truck drivers are made aware of which road sections are predicted to freeze within the selected time parameters.

You could write the acceptance criterion thus:

Given the weather forecast is available and was forecast within the previous 15 minutes, and all weather stations are online

When an authorized engineer supplies the appropriate time parameters and areas to be forecasted

Then the product produces a schedule of road sections where temperatures are 32°F (0°C) or below, and either moisture is present or precipitation is predicted within the next hour.

Another example:

Given a road is part of the district being monitored by the product

When the driver reports the road has been successfully treated (roads are treated by trucks with a human driver)

Then the road status is changed to “safe” and the road is removed from the predicting activity for the next four hours.

You can see that the acceptance criteria and the story are both saying the same thing (as they should). Some teams prefer to replace the story with the AC in its Given-When-Then form.

That’s fine when you are working at the business event level. As the business event story moves into development, it is sliced into smaller units of functionality to make implementation more manageable. This means that your acceptance criteria become more detailed—they are specifying a subset of the business use case—and they begin to focus on more technical matters.

However, you must always keep in mind that requirements, whether they are written as stories or acceptance criteria, must be testable. If something is not testable, then it has no place in your solution.

When you write the acceptance criteria for a story, the GWT statement is setting down the testable end conditions for the functionality it covers.

This is the GWT for the business event “Customer wants to watch a movie”:

Given a customer has an account and is correctly logged on

When a customer wants to watch a movie

Then the movie will be streamed until it ends or is paused or stopped by the customer.

The “Then” line is testable. You can determine absolutely that a movie is streaming to the right destination, you can test that it runs to its ending and the credits have rolled, and you can test the other “Then” conditions. Moreover, your stakeholders can agree that what they need to happen does in fact happen.

Another example:

Given the customer’s payment method is current and there are items in the basket

When the customer signals that she wants to check out

Then the delivery address is confirmed, the customer’s chosen payment method is debited, and the items in the basket are recorded as sold and transferred to the fulfillment system.

We have been talking about GWT statements at a business event story level. This is intentional, as it is at this level that GWT is most effective. As mentioned, the “When” part is when the business event happens. The “Then” statement is the outcome and must be agreed to by the stakeholders that this is the outcome they need. If there is no agreement, then you have more work to do to discover the real intention of this business event. This is a crucial part of your requirements discovery.

Later, your stories are broken down for implementation reasons, and you can still write GWT statements for all of the lower-level components. However, keep in mind that these lower-level components contribute to the goal of the business event. So, in many cases, you can abbreviate the acceptance criteria to a checklist of items to be achieved by whatever unit of functionality you are dealing with.

A word of caution: Some teams end up writing GWT statements to such a granular level of detail that each story ends up looking like a huge requirements document. Try to avoid this; the purpose is to produce a testable set of stories, not to produce a specification longer than The Lord of the Rings.

Who Writes the ACs, and When?

Business analysts are the ideal people to write the acceptance criteria for stories. Business analysts—the requirements discoverers—are the people closest to the customers and what they need to achieve. Most of what you have read so far in this book is about understanding the customers and what is needed for their work. In some cases, product owners or product managers write ACs, but care must be taken that they are written from the perspective of the customer and not based on the needs of the product.

We strongly suggest that you write acceptance criteria early in the project at the point you establish the business events. If each business event has its GWT statement, everybody understands the importance and the effect of each of the business events.

It also gives your client the information she needs to assess the value of the project overall. GWT deals in outcomes, so having them for all business events enables the development team and the client to agree on the necessary outcomes for the delivered solution to fulfill the client’s requirements.

Review

Given/when/then is not the only way to write your acceptance criteria, but it is effective and so widely used that there is little point in talking about alternatives. How you write your acceptance criteria is not important; that you write acceptance criteria is very important.

Your acceptance criteria set down the litmus test for the business use case that responds to a business event. In other words, GWT says that when this business event happens, providing the solution space is in the nominated state, the solution provides this desired outcome.

Without specifying the outcome, you cannot be sure that your solution is what is needed. It is the acceptance criteria that set down what your customer will accept.

Resources

Discover to Deliver: Agile Product Planning and Analysis by Ellen Gottesdiener and Mary Gorman (EBG Consulting, 2012). The authors mention how GWT can be used in business analysis.

Part VI

Designing Business Solutions

A business solution—you might also call it a business system—is an end-to-end assembly of components—devices, software, people, communications, machines, and so on—that are put together in such a way that they fulfill the requirements and produce the desired outcome for the business.

A software solution—which we usually call the “product” and some people confusingly call a “system”—will most likely be a part, and probably a significant part, of the business solution.

Designing is where you use the requirements to decide what to build, what to buy, what to borrow, and what combination of software, hardware, people, devices, and so on make up your solution. This is where you decide if ready-made components are the best fit for your solution, and whether to modify the organization or modify the ready-made. Whether it is more efficient to build a new piece of software or modify an existing one. Whether to automate or do something manually.

“ Design is not just about what it looks and feels like. Design is how it works. ”

—Steve Jobs

When we talk about design, we are not talking about screen layouts, or selecting colors or typefaces or button styles. We have people better qualified than business analysts and users to do that. In any event, the appearance of the solution is only important once you know what it has to do and who will be doing it.

Design permeates every activity in the development cycle. Consider the Volere process shown in Figure P6.1.

Figure P6.1

The Volere process showing the activities for discovering the requirements through to developing the solution. Although it is shown as a separate activity, design plays a part in the other activities.

You are designing in almost every part of the Volere process, so let’s look at it from the beginning. During the Project Blastoff activity, when you select the scope of the work to be investigated it is a design decision. You select a scope that isolates a part of the organization in need of renewal or repair. Or perhaps your scope is of a completely new piece of business. Either way, you are making design decisions as to the extent of the scope of the problem space. Do you have a larger scope to achieve a more comprehensive solution, or do you have a smaller scope to produce a more focused solution?

Then, as you derive sacrificial prototypes in the Prototype for Requirements activity, you make design decisions. These sacrificial or conceptual sketches of business processes are to explore the problem space and drive out new ideas. You discover requirements by designing potential solutions. Then, in conjunction with your customers, you determine whether or not they would solve the business problem and whether or not it is the right problem to solve. Paradoxically, you use design thinking to explore the problem space.

If you intend to deploy ready-made components, you are designing when you make your selection as to which ready-made is the best fit with the business problem. You are designing when you decide whether to customize a ready-made solution and leave the organization as it is, or use a ready-made and change the organization to fit it. These are design decisions.

You make an important design decision when you select the scope of the solution. This is when you decide how much of the work or the problem space should become the business solution. Some of the business solution will be made up of automated products. The scope decision you are making here determines which parts of the original problem benefit from being automated and which should be done by humans.

When the solution is being developed, the developers make design decisions. These are at a lower level than the broad-brush strokes of the business analyst, but nevertheless, they have an impact on the resultant business process.

“ Design adds value faster than it adds costs. ”

—Joel Spolsky, web programmer, writer, and creator of Trello

Designing business solutions is an iterative, nonlinear process. Design is part of most of what we do, and so it is vital for the business analyst to be involved in design. You might not call it design, you might not think of it as design, but when you consider that design is necessary to make your solution work properly, you see that part of your requirements discovery involves design.

Getting the requirements right is one part of the deal. Designing, the other part, is deciding on the best possible way to implement those requirements in the real world of your customer.

30

Business Solutions

The task of business analysis is sometimes seen as producing a set of requirements from which to build a piece of software. However, it has to be more than that. The software by itself is probably not useful until it becomes part of a wider business solution. Unless the software satisfies the needs of the entity supplying input to it (part of the wider business) and provides outcomes that are valuable to the receivers of its outputs (also part of the business), then it is of little value.

So let us take a broader look at business solutions and their components, and why you are solving a wide problem, not a narrow one.

A business solution is a physical reality. Which means that we must move away from the abstract world above the line—the essence of the problem—and think about the physical world of machines, IT systems, people, and devices below it. The “line” we are referring to is the horizontal line on the Brown Cow model (you met this model back in Chapter 18) separating what from how. This is illustrated in Figure 30.1.

Figure 30.1

The Brown Cow model highlights the transition from the essential view above the line to the physical reality below it.

A lot of business analysts find this model useful when they are discussing requirements. “Are we talking above the line, what the requirements are, or below the line, how they will be implemented?”

In this chapter, we are talking about below the line, as we are now concerned with how to implement the requirements.

Business Outcomes

Business solutions are what is needed to produce the desired business outcomes. A business outcome is the end result of activity within the business. Naturally enough, you would like the outcome to be valuable to the organization. In most cases, value comes when the business can produce its products or services effectively and economically. You are designing a business solution to do that.

But your client organization is probably already in business producing those products and services, so now you are tasked with designing a better way of doing it. That is, your business solution might be designed to be 10% faster or cheaper, or be more convenient, or utilize technology to make it easier for customers to buy the products or services. Achieving this business outcome is the goal of your project. Or to say it another way, you are designing a business solution to achieve a desired outcome.

A business solution is usually made up of multiple components. It almost always uses software working with other types of components including hardware components, people, electronic devices, and anything else that can be used to meet the requirements. Figure 30.2 shows the possible components for a business solution.

Figure 30.2

A business solution is usually made up of one or more components. These components can be anything needed to achieve the desired business outcome.

Your task as the designer of the business solution is to assemble the pieces that fulfill the business requirements. The process of designing a business solution includes making decisions about these pieces—what to build, what to buy, what to reuse, what to do manually, and so on. This is illustrated in Figure 30.3.

Figure 30.3

The assembled pieces make up the business solution.

Consider this little example of a business solution: Your authors recently bought a floor-standing reading lamp from an online retailer. This is a lamp with a requirement that it must be tall enough to illuminate the book of someone sitting on the sofa and reading. Possibly an image that sprang to your mind, as it did to ours, was that the delivery carton would be a tall, awkward package. Not so.

The business analysts working for the lamp company had correctly identified the real scope of the business solution. That is, they found that the lamp would be sold online, and so would need to be delivered by a courier or mail service. This meant they had a requirement that the lamp could be conveniently packaged. The product designers produced a solution to this requirement by designing a lamp whose central stalk is in sections and can be screwed together. When assembled, the joins are all but invisible.

The lamp, which stands about 5 feet high (1.5 m) when assembled, comes in a box the size of a large chocolate box. (They enhanced this metaphor by printing a ribbon on the box. See the photo in Figure 30.4.) This box fulfilled another business solution design requirement—that the package is a regular shape. Regular shaped packages are easier to handle, making the product attractive to online retailers. It can be readily stacked, it fits nicely into warehouse shelving, and it’s easier to ship. Attracting online retailers, as well as brick-and-mortar stores with their limited storage space, adds to the success potential of the product.

Figure 30.4

The packaging for the reading lamp. The box is about 16 inches (40 cm) on the longest side.

It gets better: The protective wrapping that surrounded the stalk was easily torn away, making it very convenient to assemble the lamp. We had it up and running in a few minutes.

Note that the business analysts did not design the product but discovered the extent of the business solution. In this case, it extended from the manufacturing process, through fulfillment, and all the way through the mailbox to the customer assembling it. Looking at the breadth of this business solution meant that the business analysts discovered the requirement that the product had to be able to be shipped in a smallish box. It was then up to the product designers to find a way to achieve that.

Business solutions are a collection of the elements needed to achieve the desired business outcome.

In the example of our reading lamp, the desired business outcome for the company is to sell enough lamps to run at a profit. The business solution to achieve this is made up of all the needed elements—design, the manufacturing process, sales, shipping, payments, customer relations, and so on.

However, you will rarely be asked to design a business solution for the entire organization. Except for startups, organizations are usually too large and too complex to be taken on at one time. Most likely you would be designing at a smaller scale, a part of the organization, or a new feature to be added to the existing solution.

Shoe Fitter

As another example of a business solution, a sports shoe company selling athletic shoes online wants to reduce the number of returns. Analysis shows that many of the returns are because the customers find that the shoes they bought are not a comfortable fit.

The company wants to include a shoe fitting process as part of its online selling, which means that the business analyst must discover the requirements and design a business solution to solve this problem. You can overcome the problem of poorly fitting shoes by having a brick-and-mortar shop where the customers can try on the shoes before they buy. This is not an option for an online retailer, so the business analyst needs to find the requirements and design a business solution that simulates the customer trying on the shoes in the shop. Having discovered the requirements, the business analyst’s proposed solution is shown in Figure 30.5.

Figure 30.5

The business solution that enables customers to find the running shoe with the best fit. The box icons indicate ready-made components.

A walk-through of this solution is needed.

The solution is an add-on to the company’s existing e-commerce site. It starts with the customer specifying their gender,¹ the kind of surface (road, trail, track), and the amount of money available to spend on the shoes. The customer then prints a grid, which the website supplies. He then photographs his feet on the grid in various positions.

FOOTNOTE 1

Shoes for females are designed to a different shape. For the same length shoe, the version for males has a wider heel and toe. This makes it a poor fit and inadvisable for a female to run in a shoe intended for males.

Once the customer has taken sufficient photographs (he is guided on how to do this by the site), he uploads them for analysis. This part of the business solution analyzes the shape and size of the customer’s feet. From the database of available shoes and their characteristics, the solution finds a short list of the shoes that provide the best fit.

The customer browses the short list and can call up more from the inventory if required.

Once he selects his shoes, the next component in the business solution is a ready-made ordering system that takes the order, and once processed, hands it off to the client’s existing payment process. Once the payment is made, the existing fulfillment system picks the shoes from the warehouse and dispatches them to the customer.

The business solution has almost designed itself. Once the requirements are discovered, the pieces of the solution fall into place. The innovation here is being able to determine the precise shape and size of the feet by photographing them on the grid. After that, processes are more or less evident, and the ready-made systems are brought into the picture. The company has been in business for some time, so these ready-made components are available and can be used as is, or with minimal modification.

The important thing is not to rush into a solution, but to discover the real business need and then find the right business solution for it. Well-designed business solutions are, after all, the engine rooms of successful businesses.

Review

A business solution is what a business does to achieve its desired outcomes. You might be designing a business solution for the whole of the business, but more likely your solution is for a part of the business. Whatever the apparent size of the problem, it is necessary to step back and see its real extent. We referred earlier to this as finding the real scope of the business problem.

All too often, designers fail to appreciate that their design has to fit into an ecosystem. This ecosystem is made up of other parts of the business, and sometimes parts of the outside world. By concentrating on just the software part of the solution, the designer produces a result that fits badly into its surroundings.

To design well, you must step back and see the entirety of the business problem. Once you have the big picture, you put together the components that are needed to solve the problem. These components can of course be software, but can also be people, devices, networks, ready-made components, and anything else that can do the job.

Resources

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp, John Zeratsky, Braden and Kowitz (Simon & Schuster, 2016). The authors, from Google Ventures, show how you cause the Sprint design process to design, build prototypes, and test business solutions. It’s an excellent resource for teams looking to rapidly prototype and validate product ideas.

Design a Better Business: New Tools, Skills, and Mindset for Strategy and Innovation by Patrick Van Der Pijl, Justin Lokitz, Lisa Kay Solomon, and Erik Van Der Pluijm (Wiley, 2016). This book offers a holistic view of innovation and prototyping in the business context. It provides tools and methodologies for creating prototypes and testing them as part of a broader innovation strategy. It includes case studies and real-life examples from both large and startup organizations.

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers by Alexander Osterwalder and Yves Pigneur (Wiley, 2010). This introduced the Business Model Canvas (which has been much imitated) for designing your business process. The Canvas is a one-page framework that presents key elements of a business model in a visual way and helps you think about the components of your business process.

The Design of Everyday Things by Don Norman (Basic Books, 2002). This has been around for some time and remains the definitive text on design principles and how they apply to everyday objects. The same principles also apply to information and functionality design.

31

Determine the Extent of the Automation

Most of the time in this book we have been talking about requirements in a fairly abstract way. Now we need to think about how these abstract requirements might be brought into the physical world. We usually do this by automating them.

There is a caveat. When you decide on your automation, no matter how attractive the technology may be, you still have to satisfy the essence of the business problem. Designing business solutions is not about selecting the coolest technology and making beautiful products. It is about coming up with the most effective solution for implementing the essence. In this case, the objective is to determine an automated product that, apart from satisfying the requirements, is desirable to its customers, provides a business benefit, and is something the organization has the capability to build.

What Should You Automate?

An early step is to consider the extent of the automation. Working on the assumption that there is an intention to meet some or all of the requirements with automation, we now need to consider which requirements can be included in the automated solution. In other words, we are looking at where to place the automation boundary.

Let’s start with the simple example illustrated in Figure 31.1. Here you see a business process. The solution designer has, in conjunction with the client and the end user, decided that the first activity in the business process should be manual. The remainder of the activities in the process are to be automated.

Figure 31.1

A conventional design for a business process. The first activity in the business process is manual, and thereafter, the activities are automated.

This solution is a fairly conventional one; you see it all the time. Let’s say that a customer phones the organization with a simple request. Because it’s a telephone call coming from a human customer, the designer decides that the best solution is to answer the call using a human. Of course, it could have been automated, but in this case a service representative needs to talk to the customer until the rep is certain that she understands what the customer wants. At that stage, she inputs the customer’s request into the automated solution.

That was a simple solution. Now let’s look at something a little more sophisticated. This is a scenario of a hospital nurse treating one of her patients. This is a How-Now scenario that describes the current way of working.

Nurse retrieves the patient’s medical records.

Nurse approaches the patient and decides if this is a good time to visit.

Nurse uses the information from the medical records and examines the patient. She considers the state of the patient.

Nurse decides on the appropriate treatment: whether the treatment is emergency or routine, whether to summon a doctor, and whether further tests have to be run.

Nurse treats the patient, either alone or with the help she has summoned. The treatment can be entirely manual or might involve medical devices.

Nurse records the treatment.

Nurse decides if there is a need for follow-up treatment, or whether the situation can be covered by routine visits.

Nurse records her follow-up treatment decisions.

For this scenario, go through each step and decide if it is a suitable candidate to be either fully or partially automated.

Step 1 should be automated—patient records are most likely to be digital files, and indeed are more usable if they can be processed by some automation. Possibly your choice here relies on the existence of digital records, or a commitment to build another business process that will digitize the medical records. The lack of an automated medical records system could of course mean that you have no choice but to make this activity a manual one.

Obviously, step 2 is a human activity—the nurse is the best judge as to whether now is the time to visit the patient.

Step 3 is where the nurse considers the state of the patient. Automate? Or use the skills of the nurse to make the assessment? To make a judgment you need to ask what the nurse is looking for when she examines and assesses the patient. The scenario is not detailed enough as it is, so you need to look deeper into this activity. Is she making a subjective judgment based on the demeanor of the patient? Is there other patient health data that would help her make the assessment? Could this activity be entirely automated using data collected from patient monitoring devices?

Figure 31.2

The automated portion of the activities is shown in a darker shade.

Analytical skills are needed here to determine the true nature of this activity. Although it is attractive to automate as much as possible (saving labor costs, possible improvement in accuracy, speed, etc.), there might be some parts of this activity that should always be done by a human professional. Possibly a physical examination by a competent nurse is the best of all solutions.

And so on through the remainder of the scenario. Please take a moment to go back over the scenario and consider your choice for each of its steps. Some of these will be easy choices, and some will make you pause and think about the problem more deeply. If you have never been in a hospital as a patient and don’t know any nurses or doctors, then try to imagine what it would be like if you were a patient. Or you might stream a few medical shows and see what you learn. We hasten to add that business analysis is not normally done by watching television, but in some cases, it might be a useful discovery technique.

In situations such as the one discussed above, you will probably end up with a design like that shown in Figure 31.2. Here you see that most of the activities are partially automated, shown by the shading of the activities. Most of them show that the nurse uses automated assistance to complete the activity. The one at the right-hand end of the process is fully automated.

Iterative and Evolutionary Design

Design is an iterative activity: It is rarely a straight-line trajectory from the beginning through to the final product. You must allow for this and take advantage of it. As you design more, you learn more, and you change your design to fit the new circumstances.

As you are working through your automation decisions, you find that automating one part of a process causes you to reconsider your choice for another part of the process. You revise and continue. This is not a bad thing; all good products evolve from their earliest incarnations.

However iterative and evolutionary it might be, design is not endless. You should always, albeit reluctantly, either set up a time box for it or define exit criteria so that you have an agreed endpoint. But while you are designing, at various times—perhaps these can be pegged to your development cycle—it pays to step back and review your design by asking yourself the following questions.

● Does the component or process I am designing fit comfortably into the overall business solution?

● Is the design evolving into the best possible solution for my customer segment?

● Is there some enabling technology that would make my design better?

● Can I make use of AI for some of my processes?

● Can my customers help me improve the design?

● Can I find an even better way to design this solution?

● Am I still solving the right problem? Or is my design becoming irrelevant?

Sometimes when you step back, you see a problem that requires you to rework the design. This is no bad thing, provided you are still within your time box. When you are forced to rework, you will almost always find your subsequent design to be better than your initial design. Such is the effect of iteration.

Change happens. Part of stepping back is looking over your shoulder to see if there are changes in your organization or in the outside world that impact your design. There will be at some stage.

Changes do not always come from outside your project. Your design activity overlaps your discovery activity, and the possibility of discovering some new facet to the problem is always there. As you design, you raise more questions, the answers to which might cause a change to the design. So be it.

Prototypes Can Help

We looked at prototypes in earlier chapters. Keeping in mind that we are using the term “prototype” to mean some kind of sacrificial model, you can make use of prototypes when you decide the extent of the automation.

For instance, Figure 31.3 shows a simple process model where the designer is experimenting with different automation boundaries. The designer has looked at the activities and considered how much of the process can be automated. Working from right to left, the designer proposes the extent of the automation by drawing an automation boundary (shown by the dotted lines). For each proposed automation boundary, the designer has sketched the interface that would result from implementing that proposal. The intention is to demonstrate the possibilities of different automated solutions and to help the stakeholders make their decisions on the extent of the automation.

Figure 31.3

The designer is experimenting with different automation boundaries and sketching the resultant interface for each of them.

Figure 31.4

A prototype of a business process that administers medication to hospital patients

That’s a very abstract example. Let’s look at something a little more concrete. We previously looked at a nurse in a hospital, so let’s revisit that idea, but this time we’ll look at another part of a nurse’s duties.

Nurses make scheduled rounds of their wards administering medication to patients two or three times a day. There is an overriding concern that the right medication is administered to each patient. The nurses feel that while they could use some automated help, it is vital that they are the people to administer the medications and ensure that each patient is properly treated.

A prototype of this process is shown in Figure 31.4. Let’s walk through it.

Here you are considering the extent of automation when designing business solutions. You must start with two questions.

How much of this can you beneficially automate?

How much does your client want you to automate?

Let’s look at the process and see if we can answer those questions. The process begins when a nurse is assigned her rounds. (It is common practice in hospitals for two nurses to be assigned to this so that they can check each other, but let’s simplify the prototype by having a single nurse.)

When the nurse is assigned, the proposed automation (shown as the first shaded ellipse) sends her assigned rounds and the needed medication to her tablet. At the same time, the auto solution sends a list of the medications needed to the dispensary. The patient records and the patients’ medications would already be digital files, so this is an area of activity that you would automate. Besides, nurses should not be doing routine clerical work.

The nurse checks the medications out of the dispensary. This has potential for automation. It is simple enough for a robotic solution to collect the needed meds and assemble them for the nurse. Many retail pharmacies have this capability. Does hospital management want to automate this step? Or do they want to keep some human control here?

Once she has the required medications, the nurse begins her rounds. For each patient, she assembles the prescribed pills or medicines. She would be wheeling around a trolley with each separate medication in its own container. Here she has to assemble one pink pill, a blue one, and two yellow ones (or whatever is prescribed for this patient). She then ensures that the patient takes the medication (and doesn’t spit out the nasty-tasting pink one) before checking him off on her rounds assignment.

This is repeated for each patient until she has come to the end of her rounds.

The hospital has expressed a preference for this part to remain a manual operation. You could use a robot to run around and dispense medication, but the hospital wants patients to receive a smile and a cheerful word or two from a nurse.

At the end of her rounds, the nurse hands back any unused medications. This brings up a possibility for further automation. When the nurse checked the medications out of the dispensary, she was given the medications in bulk. When she arrived at a patient’s bedside, she had to assemble the patient’s prescribed medication from her bulk containers. A possible automated solution could be used in the dispensary where each individual patient’s medication is assembled robotically. Would the cost of building or buying the robot provide enough benefit to be worthwhile? Is it better for the nurse to carefully hand-assemble the medication for the patients or simply give out preassembled packages?

Consider the prototype a little, and feel free to mark up your own automation proposals—which is exactly what you would do in a workshop with the nurses and hospital administrators. The objective is to find the most beneficial and acceptable extent of any automation.

Architecture

Architecture comes into play during solution design. Your organization probably has people looking after both enterprise architecture and solution architecture. These are constraints on your design work—you must form your business solution to incorporate their restrictions. It is well beyond the scope of this book to describe how architecture is done. However, we should point out that the business analysts must liaise with the architects when designing business solutions.

Enterprise architecture imposes one lot of restrictions. The enterprise architect is concerned with the various solutions that make up the structure of the organization, and with the parts of the organization that produce or consume business data. Enterprise architecture is there to ensure that all the solutions work harmoniously together. Any solution you propose must fit seamlessly into the enterprise.

Solution architecture is similar except that it is concerned with only the solution under development. The solution architect ensures that all the components and mechanisms of the proposed solution are able to work cooperatively to produce the desired outcomes.

“ Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan. ”

—Eero Saarinen, Finnish-American architect and industrial designer

Some architecture decisions should be made early in the project. These are actually some of the non-functional requirements we looked at earlier, like interoperability, scalability, availability, security, and so on. These apply to the entirety of the solution and determine some of your later architecture decisions, which means that these decisions come early in the project.

Each organization has its own unique approach to architecture. These range from anarchic to highly organized, often dependent on whether the organization is in start-up mode or sustainability mode. It is therefore impossible to offer any specific advice in dealing with your own architectural situation. However, there are people in your organization who can help you fit your solution into the established architecture.

Review

As a business analyst, you might be discovering the requirements for consumer products or services, but most BAs, most of the time, are discovering requirements for software that fits into a business solution. You start by looking at the whole of the problem space and analyzing it. When you have a satisfactory understanding of it, you and your client determine which parts of it can be beneficially automated.

It is prudent to not assume automation at the outset and not discover requirements only for the software part of the solution. Instead, concentrate on discovering the essence of the requirements for the business problem, and then decide if automation provides the best solution.

Along with the decision of whether to automate, you are deciding the characteristics of your solution. Some examples include

● Making the solution as elegantly simple as possible.

● Presenting the solution’s information in a logical, natural order.

● Keeping your solution consistent with other solutions used by the customer.

● Orienting the solution toward the people who are to use the solution. Keeping people at the center of your design thinking will give you the best solution.

And then there is the holy grail of design: useful, usable, used.

Your solution must do something useful for your customer. Otherwise, it joins the yottabytes¹ of unwanted software in a cloud somewhere. Usefulness is largely determined during Blastoff when you set measurable goals for the project.

FOOTNOTE 1

Approximately a million trillion megabytes.

Being usable is partly down to the UX designer (see the next chapter) and partly down to the way that you, the business analyst, understand the user and arrange the business events and the processes that respond to the events.

A solution will be used if it achieves the two properties above.

Resources

Business Process Management: Concepts, Languages, Architectures, Fourth Edition, by Mathias Weske (Springer, 2024). This book provides a comprehensive overview of business process management, including the role of automation. It can help you understand the fundamentals of business process analysis and automation.

Arc42 (https://arc42.org) is a website about solution architecture. A lot of it is in German, but you might like the company’s free template.

The Harvard Business Review website (https://hbr.org) has articles on automation, business process optimization, and decision-making in the context of digital transformation.

32

Designing Information and Functionality

You are designing a business solution; something that is used by an organization to do work. That much is obvious. However, some of that work will be done by humans, and usually by humans interacting with computers. Humans have different needs from computers: Computers can process huge amounts of data, but humans can’t really process data. They need information.

So far in your exploration of the problem space, you have been thinking in terms of abstract functionality and data. We have been urging you to think of the essence of the problem, and not worry too much about how this essence could be installed into the real, physical world.

Now comes the time to turn abstract functionality into usable interactions and turn abstract data into information. See Figure 32.1. Your design should enable your users to understand what they are dealing with; to understand what they can do with it and what it can do for them. Further, it should enable them to easily find the information and functionality they need to do their tasks.

Figure 32.1

Your business analysis so far has concentrated on understanding and documenting the essence of the problem. Now you have to turn that abstract essence into real-world interactions and human-understandable information.

User Experience = Information + Functionality

We are reaching an area of design where the business analyst is collaborating with a user experience (UX) designer.

UX designers are employed to produce a solution that makes people want to buy it and/or use it. User experience design is a significant topic and one that we consider to be beyond the scope of this book. However, we take a brief look at it here because this kind of design plays a large part in solution development, and it has some parallels with your role as a business analyst.

UX design aims to produce a usage experience that is pleasing and interesting, usable and intuitive, as well as relevant to the culture and aspirations of the user. Simply put, if you provide a pleasing experience that users enjoy and wish to repeat, then those users are far more likely to accept your solution. They will willingly use it, not ask for changes, and they will work effectively with it. This means you have produced a solution that works the way your users feel it should work.

UX design should not be left to amateurs. It comprises a combination of several disciplines and, if it is to be done properly, should be handled by experienced or professional people. UX design usually involves cognitive psychology, user interface design, human–computer interaction, and a liberal amount of prototyping.

The business analyst is not expected to be a UX designer: Her domain is the essential business functionality and non-functionality, which are the foundation for UX design. The essence is augmented by the personas that you or the UX designer generated and by observations of users during requirements discovery. You have gained insights into their way of working, the kind of people they are, their knowledge, how much pressure they experience when they work, their preferences, and so on. You also know what they need to accomplish with this solution.

That is what you as a business analyst bring to the table. Figure 32.2 illustrates how the UX designer and the business analyst meet. The BA brings knowledge of the required functionality and data. The designer brings UX skills. Together they bring about the most usable solution.

Figure 32.2

Where the business analyst and the UX designer meet

Let’s step back from the UX designer role for the moment and consider what is being designed.

Let’s start with information. Information is what we use to make decisions. Information about the weather enables you to decide whether to take an umbrella. Information about different running shoes (lightness, flexibility, stability, cushioning, etc.) enables you to decide which is the best for you. Information about an insurance claim and its background enables the claims adjuster to make decisions about the company’s liability.

The user has a mental model of the information, and you should present the information to fit this mental model. If you, as a customer of an online retailer, have ever struggled on a website to find the next piece of information you need, it is because the designer’s mental model of the information is different from yours. For example, you might want to know the shipping costs before entering your credit card details. You might think that entering your delivery address should come before selecting a carrier. The task of the business analyst (and that of the UX designer) is to understand the user’s mental model and design accordingly.

As a business analyst, you know the data stored by the solution space. For example, you might have built a data model (class diagram, entity model) to demonstrate this data. Each class on the diagram has a unique identifier—we looked at this in Chapter 23, Stored Data. Let’s say that you have a class of data called Subscriber, and its unique identifier is Subscriber Number. This class is part of Figure 32.3.

Figure 32.3

A partial data model showing a few of the classes needed for a subscription solution

Back to the user’s mental model. Let’s say that your user is an employee of a music streaming service. What is her mental model of the data? How does she want to see it? Does she want to see a list of subscribers in Subscriber # order? Most likely not, as that is the order in which people subscribed, and that is probably of no use. So, what sequence of information would conform to a user’s mental model? A group of subscribers by area? All the subscribers to a particular Service? Subscribers whose subscription anniversary is approaching (to alert them that it’s time to renew)? For any of these options to make sense, you need to know what the user is doing and why she is doing it.

But you already know that. Any user activity is part of the response to a business event. For each business event, there is a business use case that describes the activity of the response. We talked about this earlier, and you might have built a process model or a scenario, or some other way to model and understand the functionality of response. You might have UX people working alongside you when you are discovering this functionality.

Now you and the UX designer collaborate to put the data and the functionality together. You are designing how the user can make use of the functionality and the data to achieve the desired outcome of the business event.

Your role here is to feed your requirements knowledge to the UX designer. But it’s more than that. The UX designer looks at the problem from the point of view of the user. You, on the other hand, look at it from the point of view of the business. These two views have to come together. The business objectives have to be met, and the user has to have a solution that she finds pleasant and convenient to use. Otherwise, she will not use it or will use it badly. Either one can subvert achieving the business outcome.

On the other hand, a solution whose functionality is exactly what is needed, and whose usability is excellent, guarantees that the desired outcome is achieved in the best possible manner.

What happens if your organization does not employ a UX designer? In this case, you as the business analyst are the person best placed to fill the role. You have accumulated knowledge of the problem through your prototyping and trawling activities. You have become acquainted with the people who are to use your solution; you might have built a persona for some of the customer segments. You understand the desired outcomes for the business events. All of that is the raw material for the design of the product.

The next step is to collaborate with the user to work through her interactions. You have to walk a fine line between seeing the problem from the user’s point of view and listening to that person so hard that you end up with an idiosyncratic solution that pleases only one person—that particular user.

The design process is iterative, and we suggest that you do a lot of your collaborative designing on a whiteboard. Yes, there are software screen prototyping tools, but the task is to design a flow for the activity, not fiddle with the colors of the buttons.

We strongly recommend that if you are to undertake the UX responsibilities, you read as much as you can and attend a few training courses. UX is not as easy as it looks. You can see this by all the examples of poor UX design. This chapter’s Resources section has some suggestions for UX information. Nothing you do without UX training will be as good, but your BA training is the next best thing.

Review

Designing the information and functionality is where your requirements discovery comes face-to-face with your customers. Literally. You (and your UX designer) are crafting the way that the customer will use the data you have discovered, and the functionality that you have trawled, prototyped, probed, challenged, and invented. Your requirements discovery provides the raw materials for designing the information and functionality.

We have suggested that designing the information and the functionality is important enough to have a UX designer collaborate with you, the business analyst. This ensures that the customer gets to reap the benefit of your requirements work by having a product that does exactly what he needs it to do.

Resources

User Experience Foundations by Nick de Voil (BCS, The Chartered Institute for IT, 2019). The author provides a straightforward but authoritative description of UX and explains why it works. His chapter on interaction design is worth the price of admission.

Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces by Carolyn Snyder (Morgan Kaufmann, 2003). The author is a usability engineer, and here she shows how to create and test paper prototypes for different kinds of user interfaces.

Interaction Design: Beyond Human-Computer Interaction, 3rd Edition, by Helen Sharp, Yvonne Rogers, and Jenny Preece (Wiley, 2011). This book advocates a multidisciplined approach to interaction design; one that should resonate with business analysts. It sets out the principles of interaction design and how to apply them.

About Face: The Essentials of Interaction Design, 4th Edition, by Alan Cooper, Robert Reimann, David Cronin, and Christopher Noessel (Wiley, 2007). Cooper is one of the pioneers of interaction design. This edition expands the topic to include interactions with smartphones and tablets.

The User Experience Team of One by Leah Buley (Rosenfeld Media, 2013). This is a lightweight approach to UX design that business analysts might find to be a useful addition to their requirements practices.

Seductive Interaction Design by Stephen Anderson (New Riders, 2011). This looks at how to make your product more engaging and what motivates your customers to interact with your product.

The UX Collective website (https://uxdesign.cc) offers a wealth of articles and resources for UX design.

The website for the Nielsen Norman Group, founded by Jakob Nielsen and Don Norman, has an extensive collection of articles, reports, and usability guidelines (see https://www.nngroup.com).

33

Designing Using Ready-Mades

Most likely, the next development effort you are engaged in will involve some ready-made components. These can be very small things, such as a module of plug-in code, or something quite large, such as a customer relationship management (CRM) system that spans the whole of the customer life cycle. Or they can be something between these two. In some cases, you install the ready-made solution on your in-house servers, and in some cases you use cloud services or you outsource the functionality to a provider. In other cases, you reuse components from an existing legacy system. Sometimes you pay for your ready-made either by purchase or by subscription fee, and other times it is open source and free. Ready-made solutions and components are varied, but they have one thing in common: They have to provide the functionality and data needed to produce, partially or fully, a workable business solution for your client.

We use the term “ready-made” to refer to any component or complete solution, no matter what it is. This is off-the-shelf (OTS) software that you might buy, borrow, or reuse. In fact, it is anything you don’t build yourself.

The task of designing is different when you are using ready-mades. Here the task is to select, assemble, and integrate the optimal collection of ready-mades. The aim, as always, is to devise the business solution that best solves the business problem.

In some cases, the optimal solution might be to deploy the ready-made straight out of the box, in other cases the ready-made needs customization or configuration to fit the organization, and in some cases, it is best to adopt the ready-made and modify the organization to fit it. The same process applies if you are using an open-source (or any other free) product. The only difference is that a request for proposal (coming up next) is not used. You just download the product and evaluate it.

Let’s look at how you go about designing your business solution using ready-mades.

The Request for Proposal

A request for proposal (RFP) is a document that you generate to invite vendors of ready-mades to propose their solution to your business problem. You can invite any number of vendors depending on the likelihood of their having suitable ready-mades to propose.

Before we get into RFPs, we should mention two other documents that can be used when dealing with ready-made vendors. We mention them briefly here, as you will probably come across them, but we don’t intend for this chapter to go into the minutiae of each possible document.

If you are working for a government organization, you might augment or replace the request for proposal with an ITT, invitation to tender. The intention of both documents is close enough that we will deal only with RFPs here.

An RFI, request for information, is a document sent out, usually to a wide audience of potential vendors, requesting information about their products. This is used in some early stages to examine possibilities and try out potential approaches to a solution. The form of an RFI can be pretty much whatever you want it to be. It can be much less constrained than an RFP, as you are casting your net very wide looking for possibilities.

Let’s go back to the request for proposal. From a business analyst’s point of view, your responsibility is to provide enough information in the RFP for vendors to make sensible proposals. The information should be complete enough for the vendor to correctly understand the problem, yet not so restrictive that you cut off creative solutions to the problem.

Once you have received the vendors’ proposals, the task then switches to evaluating the proposed ready-mades. You are evaluating whether the ready-made is a perfect fit (it almost never is), how much configuration and/or customization is needed to make it fit, or whether it is better and cheaper to change the business process to fit the ready-made. Having looked at an array of ready-mades, you might decide that building your own solution is your best option.

Figure 33.1 illustrates the usual way of generating an RFP.

Figure 33.1

The artifacts used to generate a request for proposal

The first and probably most important artifact that you produce is a model of the scope of the problem. You do not want vendors proposing solutions to the wrong problem, nor do you want them to be unclear about the solution you are seeking. The scope model tells the vendor precisely where you want their ready-made solution to fit into your business organization.

Let’s look at an example where your client wants to buy a ready-made warehouse management solution. Your client considers that building a system from scratch is expensive, and he wants the solution up and running as soon as possible. Obviously, whatever you buy must fit into the client’s existing organization.

Start with the scope of the problem. Figure 33.2 is a context diagram for a proposed warehouse management system.

Figure 33.2

The context diagram for a proposed warehouse management solution. This example has been simplified for brevity’s sake. The context diagram is used to help generate the RFP.

Here are some things to note. First, your client has an existing logistics system (shown on the right side of the diagram). This means that any proposed ready-made should not include logistics but must interface with the existing logistics system. Your client wishes to retain manual warehouse workers to store deliveries of new incoming goods. This means that any ready-made must be able to compute the optimal positioning of new stock and generate the appropriate instructions for the warehouse staff. Of course, there is a lot more to warehouse management, and we will see some of it as we press on.

Also note that warehouse management is only one component of your client’s overall business solution. You are looking for the ready-made that is the best fit with the existing systems.

As you look at the context model, consider the flows of data into and out of the solution space. The data content of each of these flows should be defined in your data dictionary (section 7 of the Volere Requirements Specification Template; see Appendix A). Why? Because when you send out your RFPs, you want the vendors to know what data is available and what data you want their solution to produce. You also need to ensure that the vendor clearly understands your data-related terminology. Misunderstandings are both common and costly.

If you look back at Figure 33.1, you see that there are other artifacts that are needed to produce the RFP. The first is a list of the business events. (We discussed earlier how the flows of data on the context model indicate the business events.) These business events represent transactions to be processed as part of the warehouse management solution. Some of these originate outside the business, and others come from other parts of the client’s organization.

The list of business events tells the vendor what events the ready-made has to handle. The names of the events will differ, but it is straightforward enough to find the equivalence between your context diagram and the vendor’s list of events. Comparing the outcomes of each business event is the clearest way to determine how closely the vendor’s solution matches your requirements.

Some of the business events might be complicated, or peculiar to your client’s organization, and will need more detail than just its name and its input and/or output data. For these events, you can write a scenario and sometimes a few (or a lot) of the detailed requirements. It should not be necessary to write all of the detailed requirements; you don’t really care how the ready-made produces its outputs, just that the outcome matches what is needed.

RFP Contents

RFPs vary, and no doubt your organization has its own way of writing one. We cannot override that, but we can suggest some things that should be part of any RFP. There would of course be more things than we show below, but those would be specific to your organization.

You as a business analyst might not be the person ultimately responsible for writing and sending out the RFPs, but your requirements discovery is the most important contributor to it. We suggest that you include the following items in your RFPs:

● An introduction to the project—a half-page overview.

● The goals of the project; that is, the measurable outcome the organization wants to achieve.

● A brief introduction to the organization, what it does, and what its aspirations are.

● A context diagram that defines the scope of the business activity to be done by the ready-made.

● A data dictionary of the data flows on the context diagram. This gives you a better comparison with the ready-made’s inputs and outputs.

● A list of business events. The vendor needs to determine if its solution provides for the transactions you need to process.

● The outcomes expected from each business event. Note that these are outcomes, not outputs.

● Scenarios—but only for those cases where you need to explain the response to a business event.

● Requirements—as many as are needed to explain specific parts of the problem space.

There will also be some other corporate stuff, but this falls outside your remit as a business analyst. These are items like

● Bidding process

● Contractual issues

● Timetable for responding and for delivering

● And so on

Once the RFPs have been sent out and the vendors have responded, it’s time to evaluate the proposed ready-mades.

Selecting the Best Ready-Made

You will make many decisions based on the closeness of the match between your context model and the vendor’s ready-made solution.

The task is to get the optimal fit. This can mean the ready-made causes the least disruption to the organization, or it can mean that it is more economical to adopt the ready-made as is and reorganize the organization. In most cases, you find the ready-made that best matches your business process and modify it where the match is imperfect. Figure 33.3 illustrates the matching part of this.

Figure 33.3

You start with a likely looking candidate ready-made. However, you have to look under the hood to see if it is a real match. The scope and the business events are crucial. These should be a close match to avoid unnecessary customization.

Scope

Scope is the obvious place to start. During the Blastoff activity, you produced a context diagram showing the extent of the problem space and indicating its functionality. You provide this context diagram to the vendors and ask them to demonstrate how their ready-made achieves the required functionality. You also ask how their ready-made treats each of the business events.

You have to know how much of the ready-made is usable within your business solution. See Figure 33.4. It does not have to be, and probably won’t be, a perfect match. You can build any missing pieces yourself or disregard any pieces of the ready-made that are surplus to your requirements. However, the scope of the ready-made should be such that it substantially matches your business problem space, or the parts of it that you want covered by the ready-made.

Figure 33.4

The scope of the proposed ready-made (shown as shaded) is not an exact match with the client’s problem space. The shortfall would have to be made up with custom-built software, or the organization would have to change to match the ready-made.

Business Events

Business events represent the work that your business solution has to do. That is, each business event happens because someone or something needs your solution to do something such as produce data or a product; thus, it is important that the ready-made responds to the “same” business events that the solution you are designing calls for. Of course, they are not the same, at least initially. The ready-made is designed to be customized to fit each unique customer’s needs, so the names start out as generic names. Take, for example, “Create new customer.” You might rebadge this to be “Enroll new subscriber.” This would be a standard workflow to process new customers. You would customize it if you had several types of customer with variations of the workflow for each. This customization would hopefully be done by configuration. The result is that the ready-made provides business events that can be adapted to cater to your business events.

You are not just looking at functionality. It is the outcome of the business event that matters most. If you have not already done so, it is now worthwhile to write the outcome or rationale for your events. If you wrote business event stories, the “So that” part is what is needed here.

The ready-made will not be a perfect match as it comes out of the box, but you are matching the outcome of the configured ready-made with the outcome you need. Non-functional requirements also come into play; they are also part of the outcome. The vendor’s version (after configuration) of the business event must implement all the non-functional requirements that you have discovered.

The point of this exercise is to determine if the ready-made outcomes can be made to match your client’s business events, either by configuration or by customization. You are determining whether the ready-made is able to bring about the correct business outcome for the problem space.

Requirements

There is no doubt that the ready-made must match the requirements. After all, the requirements specify what any solution must do to satisfy the business need. Why have we not discussed this seemingly important issue?

Because it is usually possible to operate at the business event level. If the ready-made—configured or customized—has the same outcome as you have specified for each business event, then there is usually no need for the lower-level requirements to come into play.

The non-functional requirements are different. Security, cultural, and compliance requirements are paramount here. Examine these requirements thoroughly, especially when the ready-made comes from another country. Other countries have different laws and some of these might be showstoppers. For example, privacy laws differ between the United States and Europe. GDPR, an EU regulation, prohibits data from being exported to the United States with its less stringent privacy laws.

There are some situations where you have specialized requirements. For example, you might have requirements about how a calculation is done; your organization might calculate loan interest in a nonstandard way. You might have requirements to do with corporate governance, and these are unique to the company. In these cases, the ready-made must be able to have the facility to include custom-made modifications. There are some ready-mades that prohibit customers from changing the code, which would disqualify them if the need for customization arose.

It is the closeness of the match between the outcomes of the business events that determines the fit of the ready-made to your problem space.

But by and large, it is the closeness of the match between the outcomes of the business events that determines the fit of the ready-made to your problem space. If the outcomes fit, then there is little need to investigate how the ready-made achieves its outcomes.

Scoring

Whatever scoring technique you use, keep it simple. We suggest that for each business event, compare the required outcome with the outcome provided by the ready-made. Award points something like this:

4—meets the outcome “out of the box.”

3—meets the outcome when configured.

2—meets it with a small amount of customization. You have to set your scale of what “small” means in terms of hours/days of effort.

1—meets the outcome with a large amount of customization (you decide what “large” is) or with integration with other existing solution components.

0—cannot meet the outcome.

If you have prioritized the business events (and you should have), then their priorities become multiples of the score. Use the MoSCoW scale (described in Chapter 8, Prioritizing the Business Events) for the following:

Must Haves—multiply the score by 3.

Should Haves—multiply by 2.

Could Haves—multiply by 1.

Won’t Haves—you should not be considering these at all for a ready-made.

You might also consider whether the Must Haves should have a minimum score of, say, 6 to receive further consideration.

There are other factors that you might consider including in your scoring. All constraints must be met, and the non-functional requirements play a significant part. Your security team should assess the security of the ready-made. A failure in the security area disqualifies a candidate, as does any shortfall in compliance requirements. Any ready-made that does not comply with privacy laws must be counted out. Cultural fit is important—does the ready-made work in a way that is compatible with your workforce? If it is too alien, then people will be reluctant to use it.

Most vendors intend to make their products usable, but there are some more sophisticated products that have a long and expensive learning curve. Here you are trying to assess how quickly and easily the ready-made will become an accepted part of your business. Does the vendor offer training in some way to ease the transition? Usability in all its meanings should be part of your scoring.

And while we are speaking of the vendor, you might consider scoring each vendor on their willingness to collaborate while you get the ready-made up and running. Part of this score should be allocated to the level of, and the expertise of, the support offered.

Scoring should also include a cost-benefit analysis and a risk assessment. However, these two are usually the provenance of your management team.

Configure or Customize?

Once you have chosen your ready-made, you know the gaps between the desired business solution and the ready-made component. These can sometimes be filled by configuring the ready-made. This is perfectly normal and is expected. Ready-mades are designed to be configured. You specify the required parameters to be adjusted, and what result the ready-made should produce once configured.

When configuration is not enough, you need to customize the ready-made code. The latter should not be undertaken lightly, as it puts you out of step with future releases of the ready-made. You will have to reinsert your customization for every upgrade.

Despite that, there are circumstances when customization is advantageous. If customizing the ready-made gives you a competitive advantage, or if it is mission critical, then naturally you should do it. Consider the purpose-based alignment model shown in Figure 33.5.

First, let’s consider the scales at the bottom and sides of the model. Whether the business event is mission critical is the place to start. This gives you a very clear indication as to whether spending money customizing the ready-made is a good investment or not. This scale is tempered by the vertical scale of differentiation.

Figure 33.5

The purpose-based alignment model. You use this to help make decisions about configuring or customizing. Diagram derived from work by Kent McDonald.

Differentiation is not the same as different. You can make something different by painting it a different color. Differentiation is having a product that has a clear gap between it and its competitors. For example, there is a differentiation between electric and internal combustion cars. If differentiation is important to you—that is, you want your solution to have a clear advantage over your competitors’—then you measure your business event along the vertical scale. Is it high or low?

Having assessed the business event on both the mission-critical and the differentiation scales, what quadrant does it occupy? For the Differentiating quadrant, the business event is important enough to go to the expense of customizing the ready-made. The Parity quadrant means that you are happy enough to end up on par with your competitors, so you would probably take the cheaper option of configuration.

The Partner quadrant means that this is not mission critical to you, but if you can find a partner organization, you can use its abilities to exploit the differentiation. The Who Cares? quadrant is fairly self-explanatory. Here you do the minimum possible with the ready-made.

There is a reference to the University of Alaska’s white paper in this chapter’s Resources section. This gives a fuller explanation of the model.

Requirements for Adaptation

You have to specify the requirements for either the configuration or the customization. Configuration, as mentioned above, needs you to specify which configuration adjustments have to be made, and the intended outcome of the configured ready-made.

Customization requirements are more serious but are essentially the same as the requirements you have been gathering from your stakeholders. Each business event has its own Mini Blastoff, and you go about trawling for the requirements just as we described earlier.

The difference this time is that you see the ready-made as a set of constraints, and your requirements must cater to those constraints. You still need to get to the essence of the problem, and we have been urging you to write your requirements from the point of view of the business and not the technology. That changes, because now you are writing requirements for additions and adaptation of the ready-made.

Reorganizing the Organization

When the ready-made is a larger-scale solution, it sometimes means that the optimal approach is to buy the ready-made and adapt the organization to fit it. For example, suppose that you are looking at a ready-made for an insurance client. The ready-made is a total solution that provides processes for all of the business of insurance. The current organization has been using a collection of different applications to do its work up until now. Installing the ready-made means disrupting the way people work, but it will, in the long term, provide benefits.

This is largely an economic decision. Is it cheaper to customize the ready-made, or to restructure the organization? Is the ready-made so advantageous that it warrants the disruption of changing the organization?

Figure 33.6

How to accommodate the ready-made: The organization surrounding it is changed.

Changing the organization is fairly serious. You might involve human resources (HR) to help you with estimating the time and effort needed for the reorg. You also have to factor in the stunning lack of enthusiasm you will encounter for this exercise, and that should be factored into this decision. You may also need to consult higher management. See Figure 33.6.

Every organization is different, so it is impossible to describe exactly what you have to do. However, we suggest that you look at each business event. The ready-made will process more or less the same business events as you do at the moment. It will sell goods, renew policies, predict crop prices, or do whatever your current business does.

For each business event, look at what human activity is needed. Is there any front-end processing or back-end activity? Is this different from what went before? If so, you need to describe the human tasks. This is regular business analysis—you study the activity and write requirements for it. Instead of the requirements being used to write some software, your requirements are used to write instructions for a human to do a task. We suggest that usually a scenario, with a few detailed requirements, is sufficient to guide a human on what to do. When the organization has a specific way to do a calculation, or the rules are complicated for whether or not to accept an application, you need to augment the scenario with detailed atomic requirements. This is illustrated in Figure 33.7.

Figure 33.7

Specifying the activities that need to be changed to accommodate the ready-made

Review

Designing using ready-made components or solutions is a regular part of business analysis. Many of the projects you work on will involve, to a greater or lesser extent, the use of ready-mades.

We have set down the business analyst’s responsibilities with ready-mades. While you may not get to make the final choice of the ready-made product, your input to the process is crucial. In order to assess the optimal ready-made, you need more than the glossy brochure or the slick website and their promises of boundless productivity gains and everlasting corporate bliss. You need to understand the business being done and what impact the ready-made has upon that business. This is the task of the business analyst.

It is impossible to specify a definitive process for doing this. Organizations and ready-mades are far too varied for any one set of directions to cover all variations. However, we hope the general guidelines we have provided will help in your selection and deployment process.

The better the RFP is, the better the vendors’ responses will be.

While organizations differ, the request for proposal is almost constant. This document is soliciting candidate ready-mades, and it stands to reason that the better the RFP is, the better the vendors’ responses will be. A large part of designing with ready-mades is to make the best selection. An analogy to this is building something complicated using LEGO bricks. You are searching for the best pieces to make the Taj Mahal, and some pieces fit your construction better than others. The RFP is designed to find the best pieces, so a lot of your effort should go into the RFP that will get you the most appropriate ready-made solution.

Resources

The Purpose-Based Alignment Model, originally from Alaska University, is a useful guideline to help you determine whether to configure or customize your ready-made (see https://insideproduct.co/purpose-based-alignment-model).

Part VII

Requirements Repository

The requirements repository is central to everything. As you can see in the schema shown in Figure P7.1, all the activities both feed into and feed from the requirements repository.

Figure P7.1

The requirements repository is central to your requirements discovery activities. All the activities feed into, or draw from, the knowledge of the requirements stored in the repository.

The requirements repository is like any other: It’s a place to store knowledge. The repository can take several forms. It can be a specification, a story map, a backlog, a collection of artifacts, or some other form of database of requirements. We will discuss these later, and of course the choice of format for your repository is up to you and your requirements team. In this part of the book, we shall set out some options and help you decide which best fits your way of discovering requirements.

The fundamental idea of a requirements repository is this: As you are going about your requirements discovery and elicitation, you are uncovering information that you must store somewhere for later use. For example, you might build a scenario of a process, and as this model conveys information about the problem space or solution space, it is appropriate to store it in the repository. Similarly, when you are writing requirements or stories, these are also stored in the requirements repository. This constant usage means that the repository is a dynamic store of the requirements information you are collecting.

Your requirements repository is the physical incarnation of the Requirements Knowledge Model.

The Volere Requirements Knowledge Model is a language for communicating and managing the knowledge that you discover during requirements-related activities. It is also a model of the knowledge you keep in your repository. Or you could say that the requirements repository is the physical incarnation of the Requirements Knowledge Model.

Appendix C contains the Requirements Knowledge Model along with a detailed definition of all its classes of knowledge and the relationships between them. You have come across this model earlier in this book, but here we revisit it to explain the contents of the requirements repository. It is shown in Figure P7.2.

Figure P7.2

The Requirements Knowledge Model in the form of a simplified class diagram. Each class on the model represents an artifact that could be part of your requirements discovery. The connecting lines represent the relationships or associations that locate the artifact within your requirements knowledge.

If we start at the top left, we see the class (or entity, if you prefer) of the Work Scope. The work of the customer’s business and the problem space are the same thing. We have called it “work” here, as it is a more representative description. Whatever you call it, you would probably record this class using the artifact of a context diagram. Then, as we discussed earlier, you would break the work scope into a number of Business Events. The asterisk on the association connecting these work scope and business events indicates that there are many Business Events for a Work Scope. A business event happens, and the connected Business Use Case or Business Event Story, describes the response of the Work to the business event. So, this class would be recorded using an artifact such as the story, a scenario, perhaps a process model, or whatever else you feel appropriate to document the response.

The purpose of revisiting the model is to discuss storing the artifacts that you collect as you go about your requirements discovery. You will collect or generate an artifact—a BUC Scenario, a Story, a Requirement, and so on—for all or most of the classes in the model. Having a picture of how your artifacts fit together should prove useful when you’re knee-deep in the products of your requirements discovery.

You should give some consideration to the physical incarnation of your repository, especially your specifications and story maps. For example, some teams prefer to have their story maps in the form of paper cards stuck on the wall. Others prefer a software tool of some kind. Many requirements teams are happy using a collaborative word processor or spreadsheet for their requirements specification. Others prefer to use a specialized software tool to store their requirements.

There are a variety of requirements tools, with a variety of capabilities. It is important to match the tool’s capabilities with the way in which you prefer to manage your requirements. In some cases, a tool will offer tracing capabilities so that you can track requirements through implementation and testing. In other cases, being able to collaborate with a dispersed team is more important.

It is well beyond the scope of this book to discuss the available requirements tools. However, if you are choosing a tool, choose carefully. Some of them lock you into a way of working that you and your team may find irksome. The tool is there to support you, not the other way around.

One aspect that we suggest you look for in a tool is how closely its database can be made to implement the Requirements Knowledge Model, and whether it can be configured to accommodate the snow card format for your requirements.

The following chapters discuss some of the options you have for the content and arrangement of the knowledge in your requirements repository.

34

Requirements Specification

If you are using stories for your requirements, then please skip to the next chapter. Here, we’ll start discussing the requirements repository with the conventional requirements specification. This requirements document has been with us for quite some time, but longevity does not mean feeble. The specification plays a vital part in solution development today.

The specification is typically a complete description of the solution to be built. It is generally made up of hundreds, perhaps thousands of functional and non-functional requirements. This document is also known as the software requirements specification, or SRS.

The specification is often criticized because it typically takes time to complete it. Some critics like to point out that by the time the specification is complete, the original problem may have changed. This can be true in some circumstances; however, it must be balanced against the time-saving effectiveness of understanding the problem and having a precise specification of what to build. But you should also adapt the way you build requirements specifications to ensure that you don’t end up with an out-of-date specification. We’ll look at one way of doing this in a moment.

A complete requirements specification is sometimes necessary. In some cases, if you are outsourcing the development of the solution, you would need a complete specification before your outsourcer can start work. In other cases, the outsourcer can start construction and work in an agile way with progressive requirements being fed as needed.

Your work might involve some kind of military application, medical appliance, scientific application, security, or some other situation where it is necessary to prove that the requirements are complete and can be traced to the implementation. In these cases, a complete specification is required. Your organization might have development standards whereby the specification must be complete and provable before construction begins.

So, as we go through this chapter, what we are discussing is relevant whether you are building a complete specification or building your specification incrementally.

The requirements we are talking about in this chapter are those you have met in previous chapters—functional and non-functional requirements. These are the conventional requirements that are typically written as a statement, “The product shall …”, and you can expect to write quite a few of them.

We strongly suggest you use the Volere Requirements Specification Template that you find in Appendix A as a guide. This is a complete description of a requirements specification and its contents. We will visit parts of it in this chapter.

Structure of the Specification

The template is set out so that the atomic requirements are grouped together by type. That is all the functional requirements, followed by the look and feel requirements, then the usability requirements, and so on and so on.

While there might be value in doing this, it is just one way of arranging your requirements knowledge. The specification does not have to be written that way, and it is probably preferable that you write yours one business event at a time. Let’s look at why.

People often speak of “high-level requirements” and “low-level requirements.” While this is usually well-intentioned, the problem is that it is quite arbitrary, and nobody is quite sure exactly or can agree on what is “high” and what is “low.” Of course, you can say that a high-level requirement is one that has lower-level requirements attached to it, but that is close to meaningless and does not locate a requirement in any kind of hierarchy.

However, we do know exactly what a business event is—where it starts, where it ends, and what happens in between.

So, we suggest that you use each business events as your “high-level requirement” and attach the atomic requirements to the business event. This gives your specification a usable structure. Business events are self-contained, so there is no overlap between them. Readers of the specification can select whichever business event they are interested in and focus on its details without distraction.

Let’s look at the specification as a whole. Drawing from the Volere template, we suggest that you have a structure along these lines. You can relate these headings to the template:

Area 1: The Problem

Goals

Stakeholders

Glossary of terms

Scope of the problem space

Business data and dictionary

Area 2: The Solution

Scope of the solution

Area 3: The Business Events

List of business events

Business event 1

{functional requirement}

{non-functional requirement}

Additional material

Business event 2

{functional requirement}

{non-functional requirement}

Additional material

etc.

where { } enclose multiple requirements

Area 1: The Problem sets out the goals of the initiative and the problem to be solved. Most of this comes from the Blastoff, which we discussed earlier. It is crucial that everybody on the project has the same understanding of the problem to be solved, so it is appropriate that this is the beginning of your specification.

The scope of the problem should be defined using a context model, but whatever you use, it should unambiguously define the boundaries of the problem space. It must be clear to everybody on the team what is inside and what is outside the business problem you intend to solve.

Area 2: The Solution deals with how much of the problem that you choose to automate. This should be defined with a second context model, showing the extent of the IT product to be developed and what remains outside the scope of automation.

Area 3: The Business Events should begin with a list of business events. Following this, for each business event, you write your functional and non-functional requirements. We’ve described how to write these requirements in previous chapters.

For each business event, you should include any additional material, such as a scenario or process model of the business use case. This helps readers and developers understand the response to the event. You can also include any additional information that you think will be helpful. You will need to refer to the dictionary of the business data defined in Area 1.

Some of your non-functional requirements will overlap between other business events. This is not serious. You can, if you like, write them once and tag them as belonging to other business events, or duplicate them for each of the relevant events. The second approach makes it easier for the developers, as each event is a complete package. You might, as a courtesy, flag the requirements as duplicated elsewhere.

As you can discover and write the requirements one business event at a time, it makes sense to build the solution the same way. Figure 34.1 illustrates this idea by showing how a requirements specification can be built iteratively. Construction of the solution starts as soon as the specification of that event is complete enough. In the same way, you can develop a business event part by part. For example, you can build the main flow first and the exceptions and alternatives later.

Figure 34.1

The business analysts discover the requirements for a business event. These requirements are added to the specification. Developers begin construction as soon as the requirements for each business event are ready. Construction continues while more discovery is taking place.

The requirements specification defines the solution you want to develop. It should describe exactly what you and your stakeholders intend.

Resources

Software Requirements, Third Edition, by Karl Wiegers and Joy Beatty (Microsoft Press, 2013). This book presents a slightly different way of writing a specification.

The template packaged in Appendix A, The Volere Requirements Specification Template, demonstrates a complete requirements document.

35

Story Map

The story map is a better way of organizing your backlog of stories. It provides a structure that is an understandable overview of the solution to be implemented—understandable to the business stakeholders as well as the development team. The stories for the map are those that we described in Chapter 28, Writing Good Stories. You would have written these as you went about your requirements discovery. A backlog, more correctly a product backlog, is a collection of stories awaiting development. Here we are discussing how your requirements repository could be a story map, and how that can be an effective way of collecting and communicating your stories.

We attribute the story map to Jeff Patton; he introduced them in his book User Story Mapping. We are not using story maps here exactly as Patton described them. We have adapted the map to be more oriented toward requirements discovery, and (for good reasons) some of the terms we use differ. However, the spirit of story maps and how they are used remain the same.

The first thing to notice is that a story map is built and used iteratively. You write stories and add them to the story map as you discover them, and the development team uses the stories to progressively feed their development. So, you can think of the story map as a focal point for the whole effort, or as we are talking about here, a dynamic requirements repository.

The illustrations in this chapter show the story map as if it were being built along a wall using cards or Post-it notes. Indeed, many teams prefer to build their maps this way, as it gives them a large visual representation of the solution. Of course, dispersed teams use collaborative online tools for their maps.

Let’s look more closely at the story map and how you might use it.

The Story Map

Let’s start with what it looks like. Figure 35.1 shows the structure of the story map. Across the top you see Business Event Stories, one for each business event. The diagram shows three business events; you would probably have ten times that many, but space prohibits showing that many here.

Figure 35.1

The structure of the story map. The annotations are the terms we are using for the components of the map.

The top row of the story map gives you and your stakeholders an overview, or the breadth of, the solution you intend to build. It does this by showing all the Business event stories. The problem space, and as a result the solution space, responds to business events, and each one has a business event story.

Each business event needs some automation built for it, and this is specified by the lower-level stories under each business event story.

The first lower level is the Functional stories. These break down the business event story into recognizable chunks of the functionality needed to complete the response to the business event.

Below each functional story are the Detailed tasks. This is quite a granular breakdown of the functionality, and there is no need for any further breakdown.

Business Event Stories

The top row of the map shows the business event stories. It is appropriate that these stories make up the top row of the map because collectively they give a complete narrative on what the solution does.

Consider this: Every business responds to business events. That’s all it does; it responds to the prompts and requests that come from external sources. For example, a customer wants to join a gym, the customer wants to change her method of payment, suspend her membership, re-sign her membership, enter the gym through the turnstile, request a personal instructor session, or any of the other things triggered by outside entities. There are also, as we discussed earlier, time-triggered business events: time to bill the customer for another month, time to send out fitness newsletters, and so on.

By building the top row from stories that describe (at a high level) each business event, the map describes the whole of the business—or more accurately, the whole of the solution that automates the business.

Figure 35.2

Much earlier we discussed how the business events are derived from the flows on the context model. Instead of building a list of the business events, you write a business event story for each of them and add those to your story map.

As they are about business events, these stories can be derived directly from the context model, as shown in Figure 35.2.

Each business event story describes one business event. Using the format of the stories as previously discussed, it looks like this:

As a [adjacent system]

I can [brief description of the functionality of the BUC]

So that [the business benefit, or outcome, of the story].

This is a brief, but for the moment, sufficient description of each business event. By reading the top line of the story map, a stakeholder becomes aware of the complete functionality of the solution, and what it will do to achieve the goals of the development effort.

Functional Stories

The business event story is a summary. The next level below it is made up of the functional stories. These represent the first breakdown of the business events. Each one is a recognizable chunk of the functionality needed to complete the work of the business event. You are breaking down to this level to provide more convenient chunks to develop.

The task is to find the main chunks of functionality. There should not be too many of them—two, three, four, or perhaps five—as these will later be broken down, or sliced, into still smaller chunks.

There is no need to write these stories in the usual format of “As a–I can–So that,” because the business event story has already set down the beneficiary and the benefit, and the functional story inherits them. All that remains for the functional story is to describe that particular chunk of functionality.

Note that in Figure 35.3, the traveler wishes to choose her own flight based upon preferences of time, airline, seating, and airport. So, it is necessary to collect all available information about possible flights and let the traveler review and model the possibilities.

Figure 35.3

The business event story sets out the beneficiary and benefit, and indicates the functionality needed to deliver that benefit. The functional stories break down the needed functionality into convenient chunks.

The functional stories also illustrate that once the optimal flight has been found, a reservation will be made with the airline and the traveler pays for her flight.

If you had been building prototypes earlier, you might have built a process model for this business event. In this case, the functional stories are likely to be activities from your process model. In any event, it is straightforward enough to find chunks of functionality that are small enough to be useful but large enough that you do not have too many of them under the business event story.

The thing to note about the functional stories is that they provide an overview of the functionality that responds to the business event. At this stage, informed business stakeholders should be able to read and understand what the delivered solution is intended to do for them.

Detailed Tasks

Below each functional story are the detailed tasks. These are the basic units of functionality. Their purpose is to show the low-level functionality (also the non-functionality) that completes the work of the functional story. You might think of them as the components of the functional story. You might also think of them as atomic requirements as we described them back in Chapter 25, Functional Requirements, and Chapter 26, Non-functional Requirements.

The detailed tasks belonging to a functional story will probably be executed by the solution in the same continuous piece of time. If you were using the solution that carries out these tasks, you would probably not stop before completing them. If there is a need to stop, it would indicate the need for a separate functional story.

Let’s look at the detailed tasks for the functional story “Find flights to/from destination,” as illustrated in Figure 35.4.

Figure 35.4

The detailed tasks are arranged in a column. These are the base units of functionality needed by the functional story.

You can see from these detailed tasks that as you descend, they add elaboration and sophistication to the functional story. The first two are the fundamental ones; the last three are there to make a better experience.

You prioritize the detailed tasks by putting the most important tasks highest in the column. You could, for example, release a minimal product by delivering only the top two detailed tasks. You would do this to demonstrate the solution’s range of functionality, rather than its depth, as a showcase of the complete solution yet to come.

No doubt, some of the detailed tasks will have been discovered during the investigation and design activities that preceded story mapping. Provided they fit the intentions of the functional story, you can add them to the map at any time.

Having worked on one functional story, you would then move on to add the detailed tasks for the others. You might do this right away, you might wait and do it in a just-in-time manner, or you might, depending on your way of working, leave the detailed tasks for the team to do at development time.

Growing the Map

Now that you have done this for one business event, you do it for the rest of them, but probably not all at once. You are constantly prioritizing the business events, which means that you are always working on the most valuable or most urgent ones. Some of the low-priority events could be delayed for some time.

Additionally, because the detailed tasks that are lower in the column are the more sophisticated and refined tasks, you might choose to leave these until later and add them when you reach a suitable point in your delivery.

Figure 35.5 illustrates a more complete map. Your map would only look like this close to the completion of delivery. Until then, it would be built on demand according to your priorities.

Figure 35.5

A more complete story map. The cluster of stories under each business event story provides the needed functionality and is in increasing levels of sophistication as you descend in the map. Your maps will be much wider (and possibly deeper) than this illustration.

The discovery activities overlap and iterate—you are constantly jumping between them. The construction of the map can start as early as you like; perhaps as soon as you know the customers and their values. As you go about your investigation, you are learning more about the problem space and can use the map as the repository of your increasing knowledge.

The point is that writing the stories and building the map are not separate activities; they are concurrent with other activities that are themselves concurrent activities. This is illustrated in Figure 35.6.

Figure 35.6

The story map is intended to be a living artifact, constantly being added to, modified, and used, hence the two-way arrows.

Enhancing the Map

The map is not restricted to stories. There is other information it can carry.

You know the customer segment for your story. It’s the same as the adjacent system, and it is what you wrote in the “As a …” line of the story. The customer segment is the entity making the demand upon the solution, so it is most likely to be the eventual end user, or beneficiary, of this part of your solution. In Figure 35.7, the beneficiary is the traveler. This information comes from your investigation of the solution space and from your original determination of the customer segments. You can annotate the story with expectations about the users, or a profile, or a persona, to help the designers and developers make this story more usable and convenient.

Figure 35.7

This story map has been enhanced with a profile of the intended customer segment and a wireframe with some suggested interface ideas.

You might consider enhancing your story map with a wireframe sketch of the interface. The intention is not so much to design an interface, but to guide the designers. Keep in mind that, to a user, the interface is the product; by sketching an interface, you are sketching the user’s perception of the product. This paper-and-pencil approach is quick, and most importantly, it gives no indication that the wireframe is anything but a guide.

Stakeholders relate to sketches. Some stakeholders have trouble saying what they envisage, but a sketch done while they are in the room with you can, and probably will, elicit their needs. Sketches invite stakeholders to discuss it and make improvements to both the wireframe and the story map.

Adding Non-functional Requirements to the Map

Non-functional requirements can, and should be, added to your map.

When you investigated the solution space for your proposed business solution, you were partly appraising the solution for its suitability within its environment, and partly appraising the people in and around the problem space. It is these people who you must satisfy, and it is the non-functional requirements—its usability, security, look and feel, performance, and so on—that determine whether they accept or reject your solution.

In short, provided the functionality is met, it is the non-functional qualities that determine the acceptance or rejection of your product.

Please don’t think that the non-functional requirements are something that can be left until late and then bolted onto a story map. You should have discovered most of the non-functional requirements during your investigation while you were discovering the required functionality.

Non-functional requirements are discussed fully in Chapter 26.

When you are building your story map, we suggest that the non-functional requirements are appended to the appropriate stories and tasks on the map. This is shown in Figure 35.8.

Figure 35.8

This shows a single business event and one of the subordinate columns. The non-functional requirements have been attached to the stories and detailed tasks. The non-functional requirements are not stories but needs or constraints that apply to the stories. You might consider using different colored cards for these.

Non-functional requirements are inherited. That is, if the business event story has a compliance requirement, then every story or task belonging to that business event inherits the same compliance need. Similarly, a look and feel requirement attached to a story high in the stack applies to every task below it.

Some non-functional requirements can be solution wide. For example, security requirements usually apply to the solution as a whole. Either repeat the requirement for this business event or tag it to say that there is a solution-wide requirement for this event or treat solution-wide requirements as a separate category of requirements as long as you ensure that they are part of the final product.

Similarly, there are non-functional requirements that apply to more than one business event story. We suggest that you add the requirement to each relevant event story and tag the requirement to say that it is a duplicate.

Prioritizing the Map

Prioritizing means that you are always working on the most valuable part of your problem space and solution space.

We suggest that the best way to start is by prioritizing the business events. You might have done this as you were discovering the events during the Blastoff. We discussed this in Chapter 8, Prioritizing the Business Events. So, let’s assume you know the business events (or most of them) when you start your map. This gives you a map with the business events lined up, say, left to right in priority order. You know that priorities often change as you progress, so it pays to revisit your priorities and reorder the business event stories if needed. As you work on requirements discovery for the highest-priority events, you fill out the story map by adding functional stories, detailed tasks, and non-functional requirements.

You also prioritize the detailed tasks. MuSCoW prioritization is useful here. The categories are

Must have—non-negotiable needs

Should have—not vital to have immediately but are required prior to the solution being considered complete

Could have—nice to have but can be omitted

Won’t have—not a priority at this time

The “Could haves” and the “Won’t haves” can be pushed to the bottom of the map, or, if time is extremely short, discarded. The map shown in Figure 35.9 is fairly complete, but you would not wait until you have a complete map to start prioritizing.

Figure 35.9

A story map showing a possible prioritization approach. The business events on the top row have been prioritized, and then the product owner has decided to develop and release the solution in the order shown by the shaded shapes.

As mentioned, the business event stories should be prioritized early, and then the detailed tasks prioritized almost as soon as you add them.

The releases shown as shaded areas are decided mainly by the product owner, as this is now moving firmly into his territory. Some of the prioritization might now be based on the needs of the product. For example, you might need to implement some parts of the story map to provide data for other releases. But keep in mind that the requirements discovery activity contributes significant knowledge of the business value of the artifacts on the map.

Note how for some of the events, the functional stories have been prioritized such that a release is not for a complete business event story. You might do this, for example, to get early feedback without building the whole event. You might also do it to put out a minimum viable product (MVP). The MVP is used mainly as a proof of concept and should not be used as a substitute for doing the real work.

The usual prioritization criterion is value. Value means value to the customer segment (which most times is the user of your solution). Value might equate to frequency of use (if people use something a lot, they probably value it), it can be convenience, or it can be the take-up of the product. Value is value to your client or to the owning organization. Your client’s priorities are first legal compliance (it’s valuable to stay out of jail), contractual obligations (don’t get sued), supplying the client’s products or services, and then gaining revenue or saving costs.

Although value is the most common criterion for assigning priority, you must consider others. You might think about proof of concept, time needed to develop, risk (do the riskiest business events first), politics, or almost anything else. Whatever your priorities are, they change often; it pays to revisit prioritization frequently.

When we prioritize, we automatically think of the glamorous, high-priority items. But there’s value to you at the other end of the scale. Assigning a low priority to something optimizes your project time; the low-priority items do not have to be built right away, and perhaps they will never be built.

Using the Map Iteratively

The story map is your central repository for requirements knowledge. The map is loaded by the discovery activity, refined by the product owner, and used by the delivery activity.

Figure 35.10 demonstrates how you might use a story map to synchronize the requirements discovery with the solution delivery, but it requires some explanation. The numbers in the text refer to the circled numbers in the diagram.

Figure 35.10

Using the story map for iterative development. The text contains a commentary on how this works.

The business analysis activity has scoped the solution space and has determined the business events. These are added to the story map as business event stories. There will of course be many more than three events, but three will do for the purposes of illustration.

The product owner is responsible for prioritization of the stories, which is best done at the business event level. Let’s say that the product owner has prioritized the map and made the middle business event the highest priority.

The business analysts do a more detailed discovery for this event. This results in adding the functional stories and some of the detailed tasks. As soon as they are added, the delivery activity starts to develop the solution, which, for the moment, remains an incomplete or partial solution.

Meanwhile, the product owner selects the next-highest-priority business event, the business analysts go to work discovering the requirements for this event, and as they add the details, the delivery team uses them to build more of the partial solution.

This process continues to iterate until both the map and the solution are complete, or any remainder is such a low priority that the team agrees not to continue with it.

Naturally enough, the requirements discovery activity must be quick enough to feed the map at a rate that does not delay the delivery. Also, naturally enough, if the stories added to the map are the right stories, then delivery will save time by having the correct understanding of what is needed.

The moral of the story here is that when you are using stories, the story map is the most versatile and useful way to keep them.

Review

We like the story map because it is a very visual presentation of the requirements. It has an overview of the solution along the top row of the map. These are the business event stories and it is the business events with which the stakeholders will be most familiar. By walking your business stakeholders along the top row, you can explain the entirety of the proposed solution.

The functional breakdown of the business, of its stories, is shown by the lower-level functional stories, detailed tasks, and/or atomic requirements that are attached below each business event story. These can be broken down gradually to the level of granularity that you feel is appropriate. There are no hard-and-fast rules about functional breakdown; you do it to give your developers the information they need to proceed with constructing the solution.

As we discussed above, you can enhance your story map with non-functional requirements, wireframe sketches, user profiles, and almost anything else you feel is appropriate to convey the requirements to the developers.

Prioritization is made easier by having the visual display that the story map provides. When you start to build a story map, you are at the beginning of implementation, and so your prioritization will be based on both business needs and the needs of the emerging product. That is, the product owner decides priorities for the stories, according to whatever will make the most coherent and useful partial solution.

An operational advantage of the story map is that it is built iteratively in sync with the requirements discovery. The business analysts add their newly discovered requirements and functional breakdowns to the map in time for the developers to take these stories from the map and use them to produce the growing incremental solution.

Resources

User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton (O’Reilly, 2014). This is the book that introduced story maps and remains the definitive work on the subject.

You can also find useful information about story maps at Jeff Patton’s website (https://jpattonassociates.com/story-mapping), which includes articles, videos, and workshop resources, as well as the original blog post in which he first described story maps.

Other books on agile development mention story maps, but Patton’s book is the most direct source of information.

36

Quality Thinking

In this part of the book, we are discussing the requirements repository. This is the place where all your requirements—regardless of whether they are conventional requirements, stories, models, or anything else—are stored. This repository contains the information needed to develop your solution.

We must start with the premise that if the requirements are not fit for purpose, then neither will be the solution you deliver. Here we look at how you can ensure that your requirements are what they need to be. That the specification (in whatever from) is a precise, complete, and unambiguous statement of the real need. Anything less negates the reason for discovering the requirements.

We by no means suggest that you only start to think about quality when you have all the requirements in a repository. Quality thinking starts early and ends late—it covers everything you do. So, while we talk about testing the requirements, please think of this as a task that forms a natural part of your requirements discovery, and not something done once at the end.

So, let’s talk about testing the requirements with the above caveat. This is testing before building. Testing before building is not a radical idea; most industries test their requirements before building anything. For example, any bridge you drive over was tested before it was built. The testing engineers went over the plans, perhaps ran some wind tunnel tests, some stress tests, traffic simulation tests, and a whole lot more. The point is that the road authority has to be certain that when the bridge has been completed, it will bear the weight of the traffic flowing over it, and it will not collapse due to vibrations caused by vehicles or excess movement caused by environmental factors. Put it this way; would you happily drive over a bridge knowing that it was not tested before construction, that it might not carry the weight of your vehicle, and that there is a possibility of it collapsing before you get to the other side?

Testing the requirements means you are ensuring that they are the right requirements and that the resultant solution is the right solution.

Following are tests you can apply to ensure the quality of your requirements.

Within Scope?

A fairly common problem with development efforts is out-of-scope requirements. It is all too easy for your stakeholders to become overenthusiastic and start generating requirements that are irrelevant to the purpose of your solution.

Scope creep refers to the situation where more and more requirements are added to the solution so that its scope grows beyond what was originally intended. Uncontrolled scope creep usually leads to late and over-budget delivery. And worse, the solution might not provide what was intended in the first place. Naturally, there are times when increasing the scope of a solution brings benefits to the customer. However, scope creep as we are discussing here is not a welcome phenomenon.

Use the context diagram to determine whether a requirement is within scope.

Back in Chapter 5, Goals-Scope-Stakeholders, we discussed how to determine the scope of the problem space by building a context diagram. Here we present another use for the context diagram; this time we use it as a model of the IT solution space, or product, to judge whether a requirement is in or out of scope. Figure 36.1 shows the context model of a product for predicting when ice will form on roads and scheduling trucks to treat the roads before they freeze. You have already seen examples from this project.

Figure 36.1

The context model shows the scope of the solution and the flows of data that enter and leave it.

You have seen how the flows of data that enter and leave the solution space determine its functionality. Naturally enough, when you choose to automate this functionality, you must write requirements for it.

Suppose you are inspecting the requirements for this product, and you have been given this requirement:

The product shall pay truck drivers for working overtime.

Look at the context model in Figure 36.1. There is no data flowing into the product that provides any information about drivers. The product knows about trucks, but not who is driving them. Thus, to accommodate this requirement, you would need to add a number of flows—driver information, work hours, rates of pay, deductions, paychecks, and many other things. Clearly, all of these would bloat the scope of the product.

Either this requirement is out of scope or the scope of the product is incorrect. Given the nature of the other data flows entering and leaving this product, you would almost certainly decide that paying drivers is out of scope.

Now suppose you had this potential requirement:

The product shall record the hours that the trucks are active.

To determine if this requirement is in or out of scope, you need the rationale for the requirement. If the rationale is to provide some kind of report on truck activity, then we can say it is out of scope—there is no flow on the context model that carries such information. On the other hand, suppose the requirement has this rationale:

Description: The product shall record the hours that the trucks are active.

Rationale: Trucks may not be scheduled for more than 22 out of 24 hours to allow for maintenance and cleaning.

The rationale says that the data is kept and used inside the product, and thus there is no reason to add another data flow to the context model. Given this rationale, you can conclude that the requirement is within scope.

The rationale must also make sense within the context of the solution, as creeping requirements often have a rationale that indicates the requirement is out of scope or is beyond the original goal of the solution.

Relevancy

While the context model is a clear indicator of scope, you also have to consider the relevancy of any requirement.

In Chapter 3, Understand the Real Problem, we discussed how you identify the purpose of the project and record it as a statement of quantified goals. These goals serve to determine relevancy of requirements throughout the project.

Does this requirement contribute to the purpose of the project?

To test a requirement for relevancy, compare its intention with the project goals. The test is fairly simple: Does this requirement contribute to the purpose of the project? Does this requirement help make the solution, directly or indirectly, meet the project’s purpose?

Let’s go back to the deicing product. Suppose you are testing its requirements and you encounter this one:

Description: The product shall maintain a lookup table of the times of sunrise and sunset throughout the year.

At first this requirement appears to be relevant. The product predicts the formation of ice on roads, and ice usually forms at night. Thus, this requirement appears to contribute to the project goal:

Project Goal: To accurately predict when ice will form on road surfaces and to efficiently schedule the appropriate deicing treatment.

However, if you dig a little deeper, you discover that the temperature of the road surface is the determinant of whether ice will form, and road temperature is monitored and transmitted by weather stations. Whether it is night or day does not override the actual temperature. As ice is perfectly capable of forming during the daylight hours, there is no apparent reason for the product to have any knowledge of day or night.

Requirements sometimes do not initially appear to be relevant. The requirement may call for the product to do something that seems to have no immediate connection to the purpose. However, without this requirement, the product could not do what it needs to do. As an example, consider this requirement:

Description: The product shall record the salt capacity of the trucks.

At first glance, this requirement appears to have nothing to do with the goal of the product, which is to efficiently schedule trucks to treat roads with deicing salt. But look at the rationale for this requirement:

Rationale: Different trucks have different capacities. The scheduling of trucks depends on their capacity to treat the number of road sections predicted to have ice formation.

Now that the reason for the requirement is apparent, you can say that this requirement is a valid one: It contributes to the goals of the project.

When considering relevancy, pay particular attention to the following sections of your requirements specification.

● Users (Section 2): Who are you building the product for, and is it a product suitable for these users?

● Requirements Constraints (Section 3): Is the product relevant within the constraints? Have all the constraints been observed by the requirements?

● Relevant Facts (Section 5): Have the requirements failed to account for any external factors?

● Assumptions (Section 5): Are the requirements consistent with any assumptions you are making about the project?

Completeness of a Requirement

The snow card (see Figure 36.2) gives you a comprehensive way to formulate a requirement. There are references to the snow card in other chapters in this book; here we look at how you can use it as a requirements completeness checklist. By the way, it does not matter whether you are using paper cards or a digital version, we’ll continue to call it a snow card. It’s the attributes of the card and their completeness that we are interested in.

Figure 36.2

An example of a complete atomic requirement using the Volere snow card. All of the attributes are present, and the analyst has marked the requirement as having no known conflicts with other requirements. This requirement passes the completeness test.

Are There Any Missing Attributes?

The snow card is packaged as part of the Volere Requirements Specification Template in Appendix A.

The first test for completeness uses the snow card as a checklist to ensure that all relevant attributes are present. The snow card is shown in Figure 36.3. The annotations explain the attributes of the card, and in some cases, they suggest a quality check. You should ensure that all the relevant attributes are completed.

Figure 36.3

The annotations explain the meaning of the snow card’s attributes.

Being relevant is important, as sometimes some of the attributes are not necessary, and the card should never be used as a form-filling exercise. If something is not needed, then leave it out. For example, sometimes the description makes it obvious why the requirement is important, and there is little point in writing the rationale. Sometimes the description can be dropped because a clear and readable fit criterion is provided. Sometimes there are no supporting materials.

Naturally, if one of the attributes is missing, then its omission should occur because it is not necessary rather than because it is too difficult or has been overlooked. If the attribute is missing because you are still investigating it (and perhaps waiting for an answer from someone), then include that information in the requirement to keep everyone informed and to forestall unnecessary questions:

Supporting Materials: Waiting for county engineers to supply details of road treatment volumes

The completeness test says that each requirement must have all relevant attributes. If they are not part of the requirement, their absence should be obvious or explained.

Testing the Fit Criteria

See Chapter 27, Fit Criteria and Rationale, for a full explanation of how to write fit criteria.

Requirements can be ambiguous. In fact, any English (or any other language) statement is potentially ambiguous in some way, as well as vulnerable to being misunderstood. To overcome ambiguity, you add a fit criterion to the requirement. This enables you to measure the requirement and so make it both precise and testable.

A fit criterion for an atomic requirement and an acceptance criterion for a story are, in essence, the same. We’ll just talk about fit criteria here, but everything applies to acceptance criteria.

The fit criterion allows the solution to be objectively tested against its requirement.

The quality check here is to ensure that the fit criterion is a reasonable measurement of the requirement—one that allows the solution to be objectively tested against its requirement.

The first question is “Does the requirement have a correctly defined fit criterion?” If not, it is probably not understood well enough. The next question for the fit criterion is “Can it be used as input when designing acceptance tests?” You should also consider whether a cost-effective (within the project’s constraints) way of testing a solution against this requirement exists.

The fit criterion must also meet the purpose of the development effort. We have discussed how the requirement must conform to the project purpose, so it makes sense that the measurement of the requirement must likewise conform to this purpose.

While the fit criterion uses numbers to express the requirement, the numbers themselves must not be subjective; they must be based on evidence. For example:

Description: The product shall be easy to learn.

Fit Criterion: A user shall be able to learn to process an insurance claim within 30 minutes of starting to use the product for the first time.

First ask, “Is this a reasonable measurement of ‘easy to learn’?” Then ask, “Where did the 30 minutes come from?” Is it simply the whim of a stakeholder or the requirements analyst? Or is it based on evidence that a learning curve longer than 30 minutes means the users become discouraged and give up? It is of course useful if the requirement writer has included a reference to the evidence in the Supporting Materials component of the requirement.

Supporting Materials: Internal company document: Brenton Workflow Study, 2022

A fit criterion can also be written using a predefined standard. For example, when the requirement specifies that the product is to conform to corporate branding standards, the fit criterion should cite these standards and refer to the communications department for verification. In this case, your quality check asks if company branding is the correct measurement for the requirement.

Security requirements would probably also use a standard as the fit criterion—either an industry-specific security standard (such as ISO or NIST) or the organization’s own internal security standards.

Where a standard is used, you should check that the standard is appropriate for the requirement and that it is accessible enough for the developers to deliver a product that complies with it.

Whether the fit criterion uses numbers or cites a standard depends on the type of requirement. Performance and usability requirements normally use numbers, whereas look and feel, security, and cultural requirements mostly use standards.

In any event, if a requirement lacks an appropriate fit criterion, you need to revisit it and talk to the stakeholder (shown on the snow card as the Originator).

Consistent Terminology

When a poet writes a poem, he intends that it should inspire rich and diverse visions in anyone who reads it. The requirements analyst has the opposite intention: She would like each requirement to be understood in precisely the same way by every person who reads it.

Requirements specifications are not poetry—they are not even novels where the reader uses his imagination to “see” the story being told. Requirements must have only one interpretation; otherwise, there is a high risk of building a product that satisfies the wrong interpretation of the requirement.

Does the specification contain a definition of the meaning of every essential subject-matter term within the specification?

To specify a requirement such that it has only one meaning, you need, in addition to a fit criterion, to define the terms and the meanings of those terms within the context of the specification. Section 4 of the Volere Requirements Specification Template is called Naming Conventions and Terminology. This section acts as a glossary of the words specific to this project and provides a starting point for understanding the language.

Eventually, each term used in the atomic requirements is defined in section 7, which includes the data dictionary. The terms are given a nonambiguous definition that is agreed on by the stakeholders, and these terms are then used to write the requirements.

Is every reference to a defined term consistent with its definition?

The next test of consistency is to check that each requirement uses terms in a manner consistent with their defined meanings. As an example of inconsistency, the requirements for a television solution that we audited used the term “viewer” in many parts of the specification. Our audit identified six different meanings for the term, depending on where it was used. Had the requirements using this term been allowed to continue in their ambiguous way, the end product would have had some serious problems.

Without an authority—in this case, a data dictionary—that defines the meaning of terms used in the requirements, everyone on the project will make their own interpretation. If the requirements mean different things to different people, the project descends into Babel.¹

FOOTNOTE 1

The Tower of Babel is a biblical story in which the construction of a huge tower had to be abandoned because all the builders spoke different languages. Is that anything like your development project?

Viability

Viable requirements are those for which it is possible to develop and implement a product in a cost-effective manner, and when implemented, the product is operationally successful. In addition, the product must be able to be implemented within the constraints for both the design of the product and the budget for the project.

For example, this requirement is not viable, because it could not be operationally successful:

Truck drivers shall receive weather forecasts and schedule their own deicing.

The problem is that truck drivers do not have the information necessary to predict the time that a road will freeze—they cannot know which roads have been treated and which are in a dangerous condition. Coordinating a number of trucks treating multiple roads stretching over the whole of a county is a matter for centralized control.

Viability is sometimes determined by the intended users. For example, it is probably not viable to pay pensions to the very elderly using cutting-edge, high-tech mechanisms. People who matured at a time when technology was nowhere near as sophisticated as it is now might struggle if your product requires both manual dexterity and a high level of technological skill to operate it.

You might also consider whether the organization is mature enough to cope with a requirement. There is little point in specifying a product for users who need to have engineering degrees to use it when you are employing minimum-wage manual laborers.

Do you have the technological skills to build the requirement? It is an easy matter to write a requirement, but it is often a different, more difficult task to construct a working solution for it. There is little point in specifying a product that is beyond your development capabilities.

Do you have the time and the money to build the requirement?

Do you have the time and the money to build the requirement? Here you have to estimate the cost of meeting the requirement and to assess it as a share of the total budget. (The budget should be shown as a constraint in section 3 of the requirements specification.) If the cost of constructing a requirement exceeds its budget, then the customer value attached to the requirement indicates how you should proceed: High-value requirements are negotiated, while low-value requirements are discarded.

Is the requirement acceptable to all stakeholders?

Is the requirement acceptable to the stakeholders? If a requirement is very unpopular with a significant section of the stakeholders, then history tells us that it is futile to include it in the product. Stakeholders have been known to sabotage the development or operation of products because they disagree with part of it. Users have been known to ignore and not use products because not all of the functionality was as they thought it should be.

Do any other constraints make the requirement nonviable? Do any of the partner applications or does the expected work environment contradict the requirement? Do any solution constraints—constraints on the way that a product is designed—make the requirement nonviable because it is difficult or impossible to achieve?

Requirement or Solution?

The description of a requirement, or the “I can” line of a story, is unfortunately often stated in terms of a solution. We all unconsciously talk about requirements in terms of how we think they should be solved. This is usually based on our personal experience. The result is a statement that focuses on one possible solution—not necessarily the most appropriate one—and usually hides the real requirement.

The problem with requirements that state a solution is that you cannot always know what problem it is solving. For example:

Description: The product runs on the latest version of Chrome, Safari, or Edge browser on Windows, Linux, and Mac.

By nominating specific browsers, the writer has written a solution and not a requirement. What business problem is this trying to solve? Is there a specific reason for using Chrome and Firefox? Or is the writer trying to use the most popular browsers? Then you must ask what happens when new browsers are introduced.

Perhaps—we can’t be sure, but it’s likely—the requirement should be rewritten thus:

Description: The product shall run on the browsers used by 90% of the Web population.

This solves the business problem—reaching the maximum audience—and leaves the browser selection to whatever is popular at the time:

Description: The product must allow users to reset their password by clicking “I forgot my password” and receiving a link to their verified email address.

This kind of requirement might be well-meaning but is so solution heavy that it cripples the product. It invokes passwords and prescribes a process that leaves no room for anything better. The fact that people forget their passwords suggests that passwords might not be the best solution for customers to access their accounts. Unless there is a constraint that mandates this approach, you should go back and reexamine the problem that this requirement is trying (and possibly failing) to solve. You could almost certainly find a better solution.

The point of this is to ensure that you are solving the right business problem, and not invoking some solution that might well be solving something else.

Value of the Requirement

The customer satisfaction/dissatisfaction ratings indicate the value that the customer places on a requirement.

The customer satisfaction and customer dissatisfaction ratings attached to a requirement indicate the value the customer places on a requirement. You can see these on the snow card illustrated in Figure 36.3. The satisfaction rating measures (from 1 to 5) how happy the customer will be if you successfully implement the requirement, and the dissatisfaction rating measures (from 1 to 5) how unhappy the customer will be if you do not successfully deliver this requirement.

Requirements that are absolutely essential have a high dissatisfaction rating: The client will be justifiably annoyed if this requirement is not part of the final product. There are also lots of requirements that are run-of-the-mill. These are the things that are normal for the organization, so nobody gets excited when they are part of the solution. These often have a low satisfaction rating to reflect the humdrum nature of the requirement but have a high dissatisfaction rating to show that they must be part of the delivered product.

Stories typically don’t carry satisfaction and dissatisfaction ratings. It is okay to use MuSCoW ratings instead.

It is important to give the developers and testers a clear indication of the importance of each requirement. Through this, they know how much effort to expend developing and testing each requirement. Naturally, the effort expended should be proportional to the value of the requirement.

The value of individual requirements also plays a part in your prioritization activities. In fact, we strongly suggest that an indication of value is attached to all requirements or stories, or at the very least to the business use case.

Gold Plating

The term “gold plating” comes from the desire of some billionaires or movie stars to have gold-plated bathroom taps. The water does not flow out of gold-plated taps any better than it does from the chrome-plated ones that you or I use, and the water is exactly the same water. The difference is that the gold-plated tap costs more, and might, to some eyes, look a little better. They might also be a way of signaling the wealth of the owner. The term “gold plating” has been taken up by the IT industry to mean unnecessary features or requirements that contribute more to the cost of a product than they do to its usefulness.

Let’s look at an example. Suppose there is a requirement that when a user logs on to the product, it greets her by name. Is that necessary, or is it gold plating? How about if the product accompanies the personalized greeting with a couple of bars of Mozart (or Taylor Swift according to preference)?

Does it matter if this requirement is not included?

While both of the above requirements might be “nice to have,” or “Could have” on the MuSCoW scale, neither of them enhances the functionality or usability of the solution. Would anyone really mind if these requirements were omitted?

A low dissatisfaction rating indicates a requirement that is probably gold plating.

The next, and perhaps more reliable, test is to look at the customer dissatisfaction rating attached to the requirement. A low dissatisfaction rating indicates the requirement is probably gold plating even if it has a high satisfaction rating (who doesn’t like a little gold plating?). After all, when the customer says that it does not matter if this requirement is not included, he is signaling that the requirement does not make a vital contribution to the product.

Also, consider your prioritization. If you have been prioritizing your business events, your requirements, your stories, and the detailed tasks, then the gold-plated ones would have consistently been pushed to the bottom of the pile. If it never reaches the top of the stack, then it is sure to be unwanted, and pretty sure to be gold plating.

We hasten to add that there is a difference between unnecessary gold plating and cool features that either sell the product to the consumer or make it far more acceptable to the user. Some of these features could be considered to be gold plating, but before you delete them, ask whether they add to the appeal of the product or merely add to the cost.

The point is that you should know whether a requirement is gold plating. If so, and you decide to include it, then it should be a conscious choice.

Scope Creep and Your Project

We mentioned scope creep earlier and would like to revisit it, but this time look at the effect of creep on your project. Obviously, if your project is to build a bookshelf and you find yourself repainting your study and adding a new window, then your project is late, over budget, and potentially building something that nobody needs.

The effect of scope creep is shown in Figure 36.4, where the graph depicts the cost of delivering functionality. Look at what happens when the size of the product creeps up by 35%. According to many commentators, this is about the average for most projects. After creep, the effort needed expands by even more than 35%—and yet this is the part of the product that somebody expected to get for free. When the requirements grow beyond what was originally anticipated, the budget must grow in tandem. But how often do you hear, “Just one more little thing—it won’t affect the budget”?

Figure 36.4

The ratio of cost to size is not a straight line: Cost increases exponentially as size increases because more effort is needed for integration work. It is this disproportionate increase in effort that causes many projects to fall way behind schedule or fail completely.

Scope creep has a bad reputation, mostly because of the disruption to the schedules and the bloated costs of product delivery associated with this phenomenon. It is prudent to look at some of the causes of creep and to discuss how we can approach this problem.

Most creep occurs because the requirements were never gathered properly in the first place.

The first thing to address is the scope itself. Perhaps the scope was set incorrectly in the first place. Perhaps it was set before the team and the stakeholders had the opportunity to come to grips with the scale of the problem. Perhaps the scope was not adequately communicated, and some stakeholders did not have the opportunity to include needed functionality. Scopes are sometimes wildly optimistic. For political reasons, an inadequate scope that minimizes the effort and cost is presented by the project committee. Then, as reality catches up later in the project, the scope must be expanded to incorporate the requirements that should have been part of the scope all along.

Once you have addressed the scope, look at the goals of the project. If the goals are unclear or unrealistic, it is very hard to see a realistic scope. If there is a degree of uncertainty as to what the project is intended to achieve, then the scope will almost certainly be wrong. In Chapter 5, you saw the goals-scope-stakeholders trinity. These three elements are interdependent, and if the goals or the stakeholders are incorrect, then the scope is probably also incorrect.

Of course, the scope can change. Changes can happen that have an effect on the scope of the problem. In these cases, the budgets must change to accommodate the new, enlarged scope. Refer to Figure 36.4 for an explanation of the cost of changing scope.

A lot of scope creep occurs because the requirements were never gathered properly in the first place. If the requirements are incomplete, then as the product develops, more and more omissions must, of necessity, be discovered. When stakeholders become aware that product delivery is imminent, they ask for more and more “new” functions. But are they really new? We suggest they are requirements that should have been part of the product all along. They were just not, until now, part of the requirements specification.

Similarly, if the users and the clients are not given the opportunity to participate fully in the requirements process, then the specification will undoubtedly be incomplete. Almost certainly the requirements will creep as delivery approaches and the users begin asking for the functionality they know they need.

We have also observed creep that arose because the original budget was set unrealistically low (often for political reasons). When creep sets in, it was not so much a matter of the requirements creeping but of the product bringing itself up to its correct functionality.

Requirements also change. Quite often they change because the business has changed or because new technological advances have made change desirable. These kinds of changes are often seen as requirements creep. In truth, if changes that cause new requirements happen after the “official” end of the requirements process, then this type of requirements creep could not have been avoided.

Your business analysis role in this situation is to make project management aware that requirements creep is happening and, if possible, to help determine the cause of this creep.

Review

Quality is an attitude; it’s down to you. Quality is not some happy-clappy manager with motivational speeches, slogans, and emails telling you how important quality is to the organization. It’s you, and importantly, your team. When you work with a quality team your work is both excellent and enjoyable, and your output is always as good as it needs to be.

There is a happy equilibrium between doing just enough to put out the necessary requirements, and “analysis paralysis”, where you spend so much time refining the requirements that nothing gets built. Quality thinking in requirements means that you work on your requirements until you are certain that they are the right requirements, and they are written such that the developers cannot misunderstand them. And you do this in a timely manner.

How can you know you have produced the right requirements? There are several ways to know.

The first one is yourself. Are you satisfied that you are writing requirements that, when implemented, will solve your customer’s problem? Are you confident that you’re doing good work, and not just churning out lots of requirements hoping that their sheer volume prevents anyone from knowing they won’t do the job?

Quality starts with you.

You should test your requirements. You can, and we urge you to do this, ask a friend to read and test your requirements. Peer reviews are common and effective. They require an ego-free approach to your work—you must be willing to both criticize your colleague’s work and accept criticism about yours.

You also test your requirements by going over the sections of this chapter—relevance, completeness, gold plating, scope creep, and so on—and checking that each requirement passes those criteria. Is it a testable requirement? Does it have the appropriate fit criterion or acceptance criterion? And is it valuable? Does it contribute to the goals of the project?

You can, and some organizations do, have “guardians” for the requirements repository. These guardians, possibly the lead business analyst and a tester, check all the requirements as they are added to the repository. The guardians have the authority to reject incorrect requirements and ask that they be redone.

Having guardians of the repository mimics what happens in most industries—the requirements are thoroughly tested before any product is built.

A little sidetrack:

The Project Management Institute, in its PMBOK guide, has the following definitions.

Validation: The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers.

Verification: The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process.

You have a part to play in both of these quality aspects.

A lot of validation is done during the requirements activity. You are ensuring that the requirements you write are meeting the real needs of the customer.

Validation also involves having the customer or client agreeing that the delivered solution provides value based on the assumptions and hypothesis in the business case and on the goals of the project.

You might also check whether the delivered solution produces the benefits expected of it. However, this is entering the territory of benefits management.

Your verification task is to work with the testers to determine whether the product in production does what you specified it to do. Quality requirements make this easier by including a correctly measured fit criterion or acceptance criteria. Without that, verification becomes close to impossible.

Quality is an attitude. You decide, and it’s only you who can decide whether you want to do quality work. Wanting to do good work almost always results in doing good work. And we should mention that doing good work with your requirements is always more effective and faster than having sloppy requirements and making lots of time-consuming corrections later.

Resources

Mastering Software Quality Assurance: Best Practices, Tools, and Techniques for Software Developers by Murali Chemuturi (J. Ross Publishing, 2010). This is a comprehensive guide to software quality assurance, from requirements quality through to organizational quality.

The Art of Software Testing by Glenford Myers, Corey Sandler, and Tom Badgett (Wiley, 2011). While this book is primarily focused on software testing, understanding testing processes and strategies is crucial for ensuring the quality of software requirements.

Jama Software’s website (https://bit.ly/460LkWy) has some good stuff on requirements quality under the “Requirements Management and Traceability” heading.

37

Completeness Check

Your requirements repository is where you record your requirements. Regardless of the way you store them—specification, story map, backlog, requirements tool, and so on—at some stage you will find it necessary to check if you have a complete set of requirements. To point out the obvious, if your requirements are incomplete, then the solution you deliver will also be incomplete.

In this chapter, we are looking at a process to ensure the completeness of the requirements. It is not intended to say that you always wait until you reach a stage where you declare the requirements complete and want to check that they are. While this process works admirably well for that purpose, we urge you to progressively apply the ideas in this chapter to your scenarios and process models as you are working on them.

As you work with your stakeholders on a business process, you ask where the data comes from, where it goes, how it is used, and so on. You are also looking at the process to see what activities are needed, what problems can occur, and what to do if a problem or error is encountered. You should try to apply these ideas early in your discovery process.

Let’s get back to checking for completeness. There are several things you can do to start checking the completeness of your repository.

The first should always be to check that you have the non-functional requirements. These are often overlooked or forgotten in the rush to get the new solution out the door. Look through your business use cases and check if they have a reasonable set of non-functional requirements.

For example, if you are developing a financial product but there are no security requirements, something is definitely missing. Similarly, a web solution that lacks either usability or look and feel requirements is certainly in trouble.

Use the Volere Requirements Specification Template (found in Appendix A) as a checklist and guide to making sure that you have the relevant non-functional requirements.

The functional requirements should be sufficient to complete the work of each business use case. To check this aspect, play through each of the business use cases as if you were the solution. If you do everything the requirements call for, do you arrive at the outcome for the business use case? Are your users (ideally, they are with you when you perform this role-play) satisfied that the solution will do what they need for their work?

Look for exceptions. Back in Chapter 20, when we looked at scenarios, we covered exceptions and alternatives. Have you generated enough exceptions and alternatives to cover all eventualities, and do your functional requirements reflect this coverage? If you have scenarios of the business use case, revisit them and, for each step, determine whether exceptions can occur there or whether an exception might prevent that step from being reached.

But of course, all that depends on you having discovered all the business events and their associated business use case. What follows is a short process to ensure that you have a complete set of business events.

Have All Business Events Been Discovered?

You have, at our urging, been discovering and exploring the requirements one business event at a time. The business events are found first by examining the context model and for each flow of data either in or out of the problem space, determining what happened to trigger that flow. These happenings are the business events.

Let’s start with the scope. Figure 37.1 shows the context diagram, and hence the scope, for the deicing solution. (You’ve seen this before.) This predicts when roads are likely to freeze and dispatches a truck to treat the road with an antifreeze compound (it’s mainly salt) before the ice forms on the road’s surface.

Figure 37.1

The context diagram for a solution that predicts when ice will form on roads and schedules a truck to treat the road before it freezes

A quick run around the data flows on this diagram yields the following list of business events and their associated data flows:

Weather Station transmits a reading—Weather Station Reading

Weather Bureau forecasts weather—District Weather Forecast

Road Engineering advises changed roads—Changed Road

Road Engineering installs a new Weather Station—New Weather Station

Road Engineering changes a Weather Station—Changed Weather Station

Time to test Weather Stations—Failed Weather Station Alert

Truck Depot changes a truck—Truck Change

Time to detect icy roads—Road Deicing Schedule

Truck treats a road—Treated Road

Truck Depot reports problem with a truck—Truck Breakdown; Amended Deicing Schedule

Time to monitor road deicing—Untreated Road Reminder

Thermal Map Supplier updates the map—Thermal Map

That gives us 12 business events that cater to all of the flows on the context model.

Now go over the list and look for non-events. The term “non-events” is a play on words—it indicates an event that happens if another event does not happen.

For example, business event 9 is Truck treats a road. What happens if the truck does not treat the road? The work has to do something, and what it does is a non-event (it happened because another event did not happen). The non-event in this case is event 11, Time to monitor road deicing. The work responds to this (non) event by checking whether all roads have been reported as treated and, if they have not, issues an Untreated Road Reminder.

You would then go over the list asking of each event, what happens if this event does not happen? Mostly the answer is nothing; occasionally the answer is that there is a new business event to follow up on the non-happening.

Define the Business Data

The next part of the completeness check involves the business data. This is the data that is stored inside the solution space. It is stored by the incoming data flows when they bring data in from the outside world. Later, this data is read by other business events to do their work. In your solutions, this data will be held by a database or some kind of cloud storage. For the moment, let’s just look at the data and ignore its implementation.

You can, if you wish, build a stored data model. You might have already done this, or you might choose to do it for this completeness check. You can use a class diagram, an entity relationship model, a relational model, or any other data-modeling notation you prefer, as long as it shows the classes of data and the associations or relationships between them. You might prefer to call these things a class of data, an entity, a data object, a thing, or some other name. It does not matter—for the purposes of readability, we’ll use the term “class” and define it like this.

A class of data:

● Represents a type of real-world thing, either concrete or abstract, that is used by the business; for example, a truck, a weather station, a contract, an account.

● Can be given a name that is recognized by the business. It is something that the stakeholders know about.

● Has unique identifiers on each instance of the data in the same class. For example, credit cards have numbers; accounts have an identifying number, as do invoices and insurance policies.

● Is something that needs to be stored and later read by the solution.

● Is a collection of data attributes. The class itself is not data (it has no alphanumeric value), but data is stored about the class.

● Is named with a noun.

● Can be an event that is remembered; for example, agreements, contracts, purchases.

● Can be an adjacent system from the context diagram. The solution most likely keeps data about the customers, banks, suppliers, and so on that are found on many context diagrams.

Some business analysts prefer not to build a model of the stored data, and if you are one of those, consider doing this: Simply make a list of all the classes of stored data. Do this by looking for all the named “things” that are uniquely identified and qualify as a class according to the above list of qualities.

You can start with the flows of data entering and leaving the road deicing context diagram shown in Figure 37.1, or the list of business events and their data flows listed above.

The first incoming flow is Weather Station Reading. This gives you two classes of data: Weather Station (there must be more than one of these and so they are identified), and Temperature Reading (again, there are many of them and they are identified by the time and date of the reading).

The next flow on the list is District Weather Forecast. This gives you two entities: District (there are many of them, so they are identified, and the solution needs to retrieve them, so they will have a unique identifier); and Forecast (again, something remembered by the solution).

The next flow of data is Changed Road, so the solution must be storing data about roads. Roads are a nameable thing; there are many of them and so they have identifiers. The prediction processing needs to know about the roads, so you add Road to the list of data classes.

Try looking at each of the remaining flows on either the context model or the list of events and identify all the things that you consider to be a class of data.

The list we have (in alphabetical order for the sake of convenience) is as follows:

Depot

District

Forecast

Road

Road Section (we snuck that one in, as we guessed that roads are too long and would need to be divided into sections to make forecasting more precise)

Temperature Reading

Thermal Map

Truck

Weather Station

If you prefer to build a stored data model, then yours would look something like the one in Figure 37.2. This is our view of the stored data used by the deicing and predicting solution.

Figure 37.2

This model shows the classes of data used to predict and schedule the deicing of roads. The lines connecting the classes are associations, or relationships, needed by the business.

CRUD Check

Now we arrive at the best part. The CRUD (Create, Read, Update, Delete) check is based on the fact that if there is a class of data, it must be Created. It cannot suddenly materialize out of thin air. There must be something to bring it into the solution space. The something that does this is a business event.

Glance back to the context model shown in Figure 37.1. The incoming data flows are there because business events happen, and when they do, they bring data into the solution via the data flows.

For example, business event 1 on the list shown above is Weather Station transmits a reading. The data flow—conveniently called Weather Station Reading—brings data into the solution where it is stored as the class Temperature Reading. If you look back at the stored data model in Figure 37.2, you can see this class connected to the Weather Station class. This connection records which Weather Station transmitted the reading.

Similarly, if you look over the list of business events, you can deduce the classes of data that are created (this is the C in the CRUD acronym) by each business event.

If the solution needs to create some data, then it must also make use of that data. This is where the solution Reads the data. Reading the data happens when a business event needs to access some previously created data in order to do its work. For example, the business event Time to detect icy roads would need to read the classes: Road, Temperature Reading, Road Section, Thermal Map, Truck, and so on.

Some of the data is Updated. For example, there is a business event Truck depot changes a truck. This would happen if, say, the depot modified the truck to change its salt capacity. This event results in some of the data attributes of the Truck class being changed.

Finally, some data might be Deleted. This is not deleting for the purpose of cleaning up the database, but because there is some business reason for getting rid of some data. For example, under most countries’ privacy laws, if a company holds personal data about you and you no longer wish that to be the case, then if you request it, the company must delete your data.

If you go through the list of data classes and the business events that do something to them—Create, Read, Update, Delete—then you can build a CRUD table.

If you go through the list of data classes and the business events that do something to them—Create, Read, Update, Delete—then you can build a CRUD table. A suggested one is shown in Figure 37.3.

Figure 37.3

Each cell shows the identifier of the business event that creates, reads, updates, or deletes the class. Gaps in the table could mean that there are missing events.

Go over the CRUD table. This is a completeness check and you are looking for missing business events. This is the reason you built the CRUD table.

If a class is read without first being created, it means you’ve somehow missed the creation event. If an entity is created without being read, then either a reading event is missing or some data has been created that has no purpose.

Some data classes—but not all—are updated. Sometimes there is no reason why stored data should ever be changed, and sometimes there is every reason. For example, if a customer changes address (a common enough occurrence), then there must be a business event that alters the address data held for the customer. Look at each of the data entities and imagine their attributes. Is there a reason to change any of them? If so, is there a corresponding updating business event in the table?

Similarly, with the Delete column. Not all data is deleted, but you should check the entities and ask if there is a business reason to remove them from the solution’s stored data. If so, find the appropriate business event.

Look for empty cells in the CRUD table—these might reveal missing business events. For example, the classes Depot and District don’t have any creating business events, yet they are read. Thus, the context diagram is incomplete: It lacks the business events with their incoming data flows needed to create these classes of stored data.

Many of the cells in the Update column are blank. Some of these classes would not be updated; however, you should check their attributes for data that is likely to change—names, addresses, and so on—and add any missing business events.

When you find missing business events, you need to revisit your stakeholders to discover what is needed. This should lead to you updating the context diagram, the event list, and the CRUD table. You might have to iterate once or twice before you reach a stable situation.

Then, at the end of the CRUD table exercise, you can be humanly certain that you have discovered all the business events, and this will lead you to finding all the requirements.

Review

While we are urging you to build your requirements specification iteratively, it is imperative that you can reach a point where you can safely say that the specification is complete. Moreover, you might find that there are times when you want to be able to check that the part of the specification you have built so far is complete. In other words, you want to check the completeness of an incomplete spec.

The CRUD check is a powerful weapon for checking completeness. It’s powerful because it is founded on a simple truth that data in the problem space (and in the solution space) must be created, and if it is created, then it must be used. The creation and the using are done by business events.

The CRUD check neatly ties things together. The data flows on the context model indicate the business events. The business events bring data into or take data out of the work scope. This shows up on the CRUD check as Creating and Reading the data.

We touched very lightly on data modeling, and a light touch it must be. Data modeling is a subject in itself, and plenty of books and training material have been written about it. We felt it was beyond the scope of this book to have a full treatise on data modeling. However, it is an area of business analysis that we urge you to look into much more. There are references in the Resources section that should be helpful.

Resources

Data Modeling Made Simple: A Practical Guide for Business and IT Professionals, 2nd Edition, by Steve Hoberman (Technics Publications, 2009). This is an introduction to data modeling. It covers various techniques and provides real-world examples to help you understand how to model data effectively.

Data Modeling Essentials, 3rd Edition, by Graeme Simsion and Graham Witt (Morgan Kaufmann, 2004). This uses entity relationship diagrams to explain the concepts. ER diagrams are slightly different from the class diagrams we have been showing you, and they are good at explaining ideas that business analysts can use.

There are references to the CRUD check buried deep inside books on database design. However, we do not suggest you read any of them. They are concerned with the physical implementation of the data, and not its business meaning.

38

Managing Requirements

We have been talking about discovering requirements, and among other things, ensuring their correctness and completeness. We also talked about storing them in a repository. So now we turn to the topic of managing those requirements. It is one thing to discover the correct requirements; the next thing is to ensure that the requirements are being properly used.

In this chapter, we discuss requirements management and how you can trace your requirements to ensure that all of them are implemented, and conversely, that the implementation consists only of requirements.

We also talk about tracking the status of the requirements: What state of development are they in? Are they only suggestions for requirements, or have they been implemented and tested? Or somewhere in between? Tracking is not only about understanding the status of the requirements but doing it in such a way that the entire team can see the requirements and thus the status of the project. Visibility is one of the objectives of requirements management.

We also visit the thorny issue of changing requirements. Change is good and bad. It is disruptive and it is helpful. It costs effort and saves effort. And it is like fire—it can consume you if you don’t control it. Later in the chapter we’ll look at how you can manage change.

Let’s start with traceability.

Traceability

Requirements traceability is about establishing and maintaining a link or trace between various project artifacts and the requirements. The purpose of doing this is to ensure that each requirement is consistently and accurately represented throughout the project’s life cycle.

This at first seems bureaucratic, but you should consider whether the benefits of tracing your requirements outweigh the cost.

Traceability provides transparency and helps stakeholders understand how requirements are interconnected with other project artifacts, such as prototypes, design documents, and the final code. Traceability helps with managing changes (discussed below), and by showing the impact of modifications on related requirements, design, and testing. By being able to see the linked artifacts, your change supremo is in a better position to judge the impact of any proposed change.

Traceability of your requirements helps you to ensure that each requirement is tested and validated appropriately. In cases of military or medical projects, it is a legal requirement that you can demonstrate that each requirement is implemented and tested. Even for commercial or scientific projects, validation of the requirements is important. After all, what would be the point of discovering requirements and then not implementing them? Apart from the low-priority requirements you choose not to develop, all requirements should end up as part of the delivered solution. Tracing the requirements helps considerably in locating gaps in the requirements or in the product.

We are using the word “requirement” when discussing traceability. However, you know that individual atomic requirements are assembled into business use cases or functional stories, so you can trace them by one of these groupings.

Tracing requirements can also create a record of how requirements evolve over time.

Traceability Matrix

A traceability matrix is used to document and visualize traceability relationships. It is typically a table where each atomic requirement (or business event, business use case, functional story, or other grouping) is linked to design components, test cases, and other relevant artifacts.

In its simplest form, it would show an identified requirement, the associated test case(s), and the status of the testing, and thus demonstrate the successful implementation of the requirement.

The metric can, and usually should, be more elaborate. You can include an identifier of the module(s) of code that implement the requirement, any design documents, and any prototypes that display information still current to the implementation.

Figure 38.1 shows an example of a requirements traceability matrix.

Figure 38.1

A simple requirements traceability matrix table

The product owner and project manager, and indeed the whole team, use the traceability matrix to monitor the status of the requirements, and how much of the product has been and still remains to be built.

Now let’s look at another way to trace. This one is more comprehensive.

Requirements Knowledge Model

You met the Requirements Knowledge Model before—it is a representation of the information you assemble when you discover your requirements. This time we are using it to demonstrate how it makes it possible for you to trace your requirements. Without having such an underlying structure, requirements tracing would be at best ad hoc, and possibly nonexistent. Consider the model shown in Figure 38.2.

Figure 38.2

The Requirements Knowledge Model. The classes of knowledge you need to trace, and the links between them, are highlighted.

This presentation of the Requirements Knowledge Model highlights the traced classes along with the links between them. Let’s start at the top left with the Work Scope. We previously discussed how you use the scope to determine the business events. This determination establishes that there is a link between work scope and Business Events. This link is shown by the line between the two classes, and the notation along the line says that there are many business events attached to one work scope.

The links between the elements are significant. In this case, you have a work scope divided into a number of business events. For traceability purposes, you need to keep a list of these business events, and obviously, to which work scope they belonged. You would most likely use a requirements traceability matrix to keep track of this information.

The Business Use Case, or the Business Event Story (whichever you are using), is linked to the business event and represents the response that the solution makes to the business event. The model tells us that there is only one of these for any business event. By giving a unique identifier to each business event, you also identify the BUC or business event story.

You would normally automate part or all of the BUC, which might be done with one or more chunks. These chunks are the Product Use Cases (PUC) or Functional Stories attached to the BUC. The association between these classes establishes the link you need for tracing.

The next breakdown is Atomic Requirement or Detailed Task. The Volere snow card has a field for a requirement ID. It is similarly possible to identify a detailed task. Tracing then becomes a matter of maintaining the list of atomic requirements/detailed tasks that belong to the PUC or the Functional Story.

Thus, you can link the chain of classes from the original work scope down to the atomic requirements or detailed tasks. Naturally, you also link in the reverse direction.

Implementation Unit

The model shown in Figure 38.2 shows a link to a class called Implementation Unit. The exact nature of this is not important to our discussion here, but as its name suggests, it is a piece of the final implemented code. It might be an entire application; it might be an identifiable unit of code within the codebase. Its exact nature is not as important as the association between the atomic requirement and the implementation unit. This association is established whenever the developers implement one or more atomic requirements. In other words, it is the existence of the association between the implementation unit and the atomic requirement that tells you that the atomic requirement (or the detailed task) has been implemented.

This is the final leg of the trace. You can now verify that requirements have been implemented, and conversely, that implementation units are the product of requirements.

Tracing

The Requirements Knowledge Model represents the requirements for managing requirements. If you look back at the model in Figure 38.2, you can see other potential traces. For example, there is a link between Business Use Case and Stakeholder. You might choose to trace which stakeholders are responsible for which BUCs. There are also other potential links shown in the model. You and your team choose which of these to maintain, depending on the size of the project in the budget automation you have for this kind of management.

The model shown here does not include other classes of knowledge that you might wish to incorporate in your own model. For example, you can include a Test Case class that is linked to the implementation unit and to the atomic requirement. These links demonstrate that your requirement has been both implemented and tested. You might also include design documents, prototypes, or other artifacts that you choose to trace. Your requirements knowledge model reflects your team’s view of the requirements discovery activity.

You might be doing this using an automated tool, which you would do for large and complex projects. If this is the case, the tool keeps track of the traced classes and the links we have been discussing, and automatically updates them as project artifacts evolve. Lacking such a tool, you can use a manual traceability matrix to satisfy the traces. If your requirements are being handled using a physical medium such as cards or Post-it notes attached to a wall—we spoke about this in Chapter 35, Story Map—then you have a visual link between the knowledge classes.

Industries such as healthcare, aerospace, military, and finance; regulatory authorities; and similar groups require strict traceability to ensure that software meets safety and quality standards.

Traceability is not a one-time activity. It should be maintained throughout the software’s life cycle as requirements evolve and changes are made to project artifacts. Establishing and maintaining traceability is a key responsibility of the requirements management team in any project.

Tracking Status of Requirements

The status of requirements refers to the current state or condition of individual requirements (or business events, product use cases, or functional stories) throughout the software development project’s life. Whereas traceability is concerned with ensuring that requirements are tested and implemented, status is concerned with the stage of completeness that a requirement has reached. This is the concern of a project manager, a product owner, and team members who need to be aware of the state of their project.

Kanban

You might include status in your requirements traceability matrix, or you might find it more convenient to have a separate status matrix. The best way, in our opinion, of showing status is a Kanban board. Kanban originated in Japan and was initially developed by Toyota for its manufacturing processes. It has since been adapted and widely used in various industries, and particularly in agile software development.

The advantage of the Kanban board is that it is a visual representation of the requirements and their stages of development on their voyage through to implementation and deployment. Each requirement is typically depicted as a card, with different columns on the board representing various stages of the workflow. Figure 38.3 shows an example of a Kanban board.

Figure 38.3

A sample Kanban board showing the status of the requirements (shown as documents) for the project. You can choose to use PUCs or stories instead of requirements on your Kanban board.

The Kanban board shows work in progress, and thus the status of the requirements. Each small document icon on the board represents either an atomic requirement, a story, a PUC or a BUC, or possibly a business event. It is a matter for you to choose at what level you wish to track the status. For the moment, let’s call them “requirements.”

Each column represents one stage that the requirement passes through. There are no hard rules for categorizing the status of requirements, but you might find the following useful. These are the column headings shown in Figure 38.3.

● Proposed: Requirements that have been identified but have not undergone formal review or analysis

● Analyzing: Requirements that are being discovered (you might break this down further to reflect different stages of requirements analysis)

● Design: Requirements for which there needs to be some solution design

● Specified or Backlog: Requirements or stories that have been written, have been quality-checked, and are now part of the specification or product backlog

● Implementing: Requirements that are being developed

● Validating: Requirements that are in the validation and verification process

● Deployed: Requirements that have undergone testing or validation to ensure that they meet their specified criteria and are now deployed in production

At the risk of overloading your Kanban board, you might include a column for requirements that are not currently within the project’s scope but may be considered for future releases. You might also keep track of rejected requirements—those that you have considered to be unnecessary, out of scope, or infeasible.

The Kanban board shows work in progress. It would be necessary to add some indicator to the requirement to say that it has completed that stage. You would also include some information on why a requirement was changed, dropped, or included. This might be needed later for verification purposes.

One of the principles of Kanban is that work is “pulled” from one stage to the next. Pull takes place when the condition of the work item allows, and there is capacity in the next stage that permits new work to be accepted. For example, the Design column of the board is fairly full. This indicates that the designers are overloaded and have become a bottleneck—they cannot, at the moment, pull more requirements into their activity. At the other end of the board, the Validating column has plenty of capacity, a signal perhaps to up the tempo of Implementing.

Kanban allows you, or your management, to limit the number of work items that can be in progress at any given time. This limit is set for each column on the Kanban board according to the capacity of the workers available for that task. You limit work in progress to maintain a steady workflow, one of the key factors in eliminating waste. When you can see the requirements and their status you can reduce wait times, minimize delays, and ensure that your requirements discovery moves smoothly and efficiently through the workflow.

A Kanban board does not have to be a physical board. There are many automated tools for maintaining a Kanban board online and for using it for remote, collaborative working. The key point is that it provides a visual representation of the requirements discovery and delivery work in progress. This visualization makes it easy for team members to understand the current status of the requirements, the work that has been done, and the work remaining to be done.

Requirement status should be monitored continually throughout the project’s life cycle, from initial requirements discovery to post-release maintenance.

In summary, tracking the status of requirements is an integral part of requirements management in software development. It ensures that requirements are properly reviewed, implemented, tested, and verified, contributing to project success and effective communication among project stakeholders.

Change Management

Change happens. We know that. But change is never free; it always has some impact on the rhythm of the project or the needed effort.

Many projects complain of ever-changing requirements, of stakeholders changing their minds, or asking for changes after something has been delivered, and so on. The litany of complaints is almost endless.

But it does not have to be this way.

Changes happen for a number of reasons, and some of them we cannot help you with. Corporate politics is one. Sometimes you have stakeholders who align themselves with certain requirements, and having their requirements supplant others, even late in the development, is a matter of demonstrating corporate power. Sometimes the stakeholders change, and you are suddenly dealing with new people who have very different ideas from the old ones.

Some changes happen because of changes to external forces. Sometimes mid-project the law changes, or regulations change, or corporate business rules change. Sometimes technology changes and it becomes obvious that the new technology offers such benefits that the best thing to do is to make changes to accommodate this advance.

You can’t do much to stop these types of changes happening. But you can do things to accommodate them more easily.

Then there are other changes that should not happen.

For example, if the scope of the problem space is not made reasonably accurate at the outset of the project, then changes are almost certain to happen when stakeholders realize during the project that needed functionality has been excluded. It’s also possible that unneeded functionality has been included. Both of these require changes that could have been avoided.

As you are going about your requirements discovery, you are learning about the organization, the work, and the people who do the work. The more you learn, the better position you are in to make assessments of the areas that are likely to be exposed to change. In the template, section 5 deals with assumptions. This is where you record your assumptions about anticipated changes. For example, you might assume that the technology could change, or the marketplace could change, or fashion and customers’ preferences could change. Assuming the change might happen does not mean that it will happen, but you would give this area a lower priority and develop it later to avoid having to redo work if a change happens.

How many changes are you dealing with? If there are a lot of changes, then it could be a sign of poor business analysis. If stakeholders are constantly asking for new things, then it suggests a poor definition of the scope or poor communication during the discovery activities. In this event, it is worthwhile for the team to meet and examine the nature of changes with a view to changing not the requirements, but the way the requirements are gathered.

Prototyping helps to avoid change. Having a mockup helps those stakeholders who are not good at visualization. However, some people fail to grasp what a sketched prototype is showing them, and for these people, you need the actual product.

Incremental or partial development helps here. A proof-of-concept version, or an MVP, or some other sample version can help these people see what the final product will be like and what it does. You are asking them if this is what they imagine they need.

At this stage, if the sample product is a long way from expectations, then we suggest you shut down the project and determine what went wrong. The product will never be any good if it is hacked into place by delivering something and then changing it to meet the flood of user requests. It will only be good if you build it on a solid foundation of a correct and agreed scope and goals of the project, along with requirements that are discovered by understanding the real business problem.

The moral of the story is that good business analysis goes a long way to preempting changes to the requirements, and it requires much less effort than building something and later changing it.

So, let’s turn away from the causes of change and look at how you might handle the change.

Managing Change

The first rule of managing change is that all changes are communicated to a central person—let’s call her the change supremo. This is probably the project manager, but it depends on your organization. Your project is out of control if stakeholders can bypass the supremo and bring their requests to their favorite business analyst or developer.

The change supremo filters all changes. A quick triage reveals whether the change is relatively nondisruptive or has serious ramifications.

● Is the change valid? Does it contribute to the goals of the project and the organization, and also to the intention of the product?

● How much effort is required?

● Does it negate any effort already expended?

● If accepted, would it change the scope of the problem space and/or the scope of the solution?

● Does the change affect only the product, or does it have ramifications in the business?

● Does the change bring value to the project and/or the organization?

● Is it trivial, or gold plating, and can be safely discarded?

● If the change is ignored, what impact would that have?

If the change is accepted by the supremo, then low-impact change requests can be handed off to a business analyst for investigation and resultant requirements.

High-impact changes are those that have a serious consequence on the project’s budget or that significantly alter the outcome of the project. For these change requests, the supremo must confer with a higher authority.

The change management process should be as nonbureaucratic as possible without losing control of changes. A competent change supremo who is close to, or part of, the project would outperform a change committee any day.

However it is done, the cost of incorporating all changes must be recorded. It is vital for project leadership to understand the cost and impact of change, and to warn customers of potential delays to the delivery of the product.

It is also crucial that your project, and future projects, make allowances for change when assessing their viability. Without allowing for the additional cost of changes, it is unlikely that project budgets can be taken seriously.

Finally, the most valuable part of change management is learning where changes come from, and in what stage of the development cycle. Changes made to requirements while they are still being discovered are relatively cheap (or mostly free). Changes made to products already in use are significantly expensive.

By learning where and why changes originate, you are in a better position to adjust your discovery and delivery process to minimize change. You can never eliminate change, but you can tame it.

Review

This book is about discovering requirements. Discovering the right requirements is crucial if you are to deliver the right solution. However, there is a little more to it than just discovery. You have to ensure that the requirements are managed so that they provide the maximum usefulness to your stakeholders and developers.

Managing requirements involves identifying the requirements for traceability purposes, documenting them in a way that makes their meaning clear, prioritizing them so that the most valuable requirements are developed early, and controlling them so that they provide the information needed for the successful development of the delivered solution.

Managing can include ensuring that the requirements are captured in a form that makes them understandable and useful. Previously we looked at how you write stories and atomic requirements. Managing requirements is concerned with collecting all the requirements in a usable form.

Management also includes assessing the assembled requirements to ensure that they are complete, consistent, and feasible.

Prioritization is constructive. It ensures that the requirements are ranked according to their business value and impact on the project or solution’s success.

Traceability establishes and maintains links between requirements and other project artifacts, which ensures that all requirements are correctly treated and eventually implemented.

Change happens throughout the project, and the requirements management task is to evaluate the value and impact of each change. Naturally, it is crucial to communicate the accepted changes to the stakeholders and project team.

In summary, managing requirements is about monitoring and controlling the requirements throughout the project and ensuring that they are correctly developed. After all, you put a lot of effort into discovering them. You should ensure that they are used properly.

Resources

Requirements Engineering: Fundamentals, Principles, and Techniques by Klaus Pohl (Springer, 2010). Pohl writes about approved techniques for discovering requirements and goes on to discuss validating and managing requirements for software-intensive systems. There is additional material on the book’s website, http://www.requirements-book.com.

More information on the traceability matrix is available at bit.ly/49tx7nJ.

Essential Kanban Condensed by David Anderson and Andy Carmichael (Lean-Kanban University, 2016). This is a distilled introduction, but it gives you all the principal concepts and guidelines to Kanban.

The Effective Change Manager’s Handbook: Essential Guidance to the Change Management Body of Knowledge by Richard Smith, David King, Ranjit Sidhu, and Dan Skelsey (Eds.) (Kogan Page, 2014). This is a comprehensive treatise on the subject and comprises chapters from established leaders in the topic.

Part VIII

The Conduct of Business Analysis

We’re getting close to the end of this book, and so far, it has been talking about techniques for business analysis: context diagrams, business events, requirements, stories, models, prototyping, and others. We hope that you have found a collection of techniques that will be helpful to you and your work.

Before we part company, we want to look at the softer side of business analysis: the people-focused side. We want to talk about people and why they are important. We will also talk about the process and how you might look at it before you decide what your process is to be.

As part of the softer side, we also want to visit systems thinking and how that might influence you when you’re investigating and discovering your client’s problem space. And finally, we’ll discuss how innovation makes an incredible difference and should be part of every development effort.

The following (mainly short) chapters on the soft topics don’t necessarily link together or follow any particular sequence. But each provides insights that are intended to make your business analysis better. Some of them show you ideas that you might like to build into your own work practices.

39

Your Process

Anarchy might be fun, but anarchists never build anything useful. Can you imagine anarchists building the pyramids in Egypt? “Listen up, guys. We’ve got these blocks of stone. What do you think we can do with them?” No, the Egyptians had a process that enabled them to put up structures that are still standing 4,000 years later. Cut to today. Would you happily catch the elevator to the 32nd floor if you thought for one moment that the construction company had randomly thrown together some steel, glass, and concrete, and kept doing that until it looked like an office building?

To do anything meaningful, we usually need a number of people. And as soon as you have more than one person involved in your requirements and development effort, there is a need for a process of one form or another. Simply put, if we want multiple people to pull in the same direction, all of them have to know what they’re supposed to be doing. This is the role of the process.

That is not to say that a process should be fixed, rigid, unvarying, and heavily enforced and leave no room for human creativity. It should not be a process that must be obediently followed to the point that the people using the process are reduced to automatons: “That’s step 47 done. Tick. Now do step 48.” Any worthwhile process should be the opposite of the robotic approach. It should be framed around the people and the work they are doing.

It must also be flexible enough to adapt to unforeseen happenings, because we know that we will almost always encounter the unexpected. We can gather information to try to reduce uncertainty, and the right information certainly does that, but there will always be uncertainty. The best we can do is to have a process that allows for deviations when the unexpected happens, or when sticking to the plan would be counterproductive.

Serial or Agile?

We are quite often asked, is the Volere process serial or agile? The answer is yes. It is agile in that you jump from one activity to another in response to happenings, and serial when you ensure that the foundation is solid before moving on to prototype or trawl. It is serial in that you understand what has to be built before building it, and agile in that you build as soon as you have enough confidence in the requirements so far, and the product is built iteratively and incrementally.

Note the “enough confidence in the requirements.” This implies that the business analysts have done their discovery. Working code is not the cheapest way to explore the problem and its proposed solution, nor is it the most effective. So, it makes sense to postpone that code while there are cheaper and more adaptable ways of exploring.

It is both serial and agile when it comes to change. But the nature of change means that we must approach it differently according to the reason for change. Iterative development reduces the impact of change. If you have not built the solution as one monolith, but are assembling it incrementally, then you are reducing the odds that a change will affect what you have already built.

However, the process is aimed at exploring portions of the problem until the likelihood of change is minimized and the risk is acceptable and then building that portion. A lot of change happens because the wrong solution was built before the real requirements were understood. Or it was built in an attempt to display functionality to the stakeholders as a way to discover the requirements. By sketching prototypes, using models and other tools, the team experiments and explores the problem. By working in tandem with the stakeholders, this exploration establishes that the right problem is being solved and that the proposed solution will integrate with the rest of the business. When you know these things—and only when you know them—you can build a solution with the odds of it needing to be changed greatly reduced.

Of course, change happens—technology, politics, and the marketplace all change, as do the customers’ aspirations. We cannot stop change, but we can use our Blastoff time to model and anticipate the kinds of changes that could impact our problem space and make allowances for it. In other words, by being a bit more serial, and especially by establishing the foundations first, we can make it easier to be more agile and accommodate change.

A Common Language

When your airplane is coming in to land at a foreign airport, the pilot and the air traffic controller speak English to each other. You could be on an IcelandAir plane with an Icelandic pilot landing in Reykjavik, and ATC and the pilot still speak English. Why?

Because lives depend on the controllers, the pilots, and everyone else involved understanding each other. By using a common language, words have the same meaning. “Twenty nine right” means the same to both parties, and so there is far less chance of a misunderstanding causing a potentially fatal mishap.

Rarely does anyone die if people on your IT project misunderstand each other (medical and military projects excluded). But the project definitely suffers when the wrong things are built.

One of the advantages of having a known process is that it comes with a common language. The language of the process itself—Blastoff, business event, description, rationale—is defined and becomes known to everybody involved in the process. Similarly, in the Volere Requirements Specification Template, there is a glossary and a data dictionary. These are there to define the business terms so that everybody on the project has the same understanding of the words being used. Without a common language, projects flounder, sometimes producing the wrong solution but mainly living in an inefficient state of misunderstandings and doubt.

As part of the common language, we refer you to the Requirements Knowledge Model in Appendix C. This sets out the artifacts that make up the knowledge you are accumulating about the requirements. Using this model helps to standardize the requirements terminology and so makes for better understanding and for your requirements process to flow more smoothly.

Making It Your Process

Throughout this book, we have been showing you the Volere process (shown again in Figure 39.1). There are a couple more things that we still need to explain to illustrate how you can make this your process.

Figure 39.1

The Volere requirements process

Project Blastoff

Let’s start with the Project Blastoff activity. This is where you set the foundation for your requirements efforts. We cannot stress enough how important it is to correctly and honestly establish the scope of the problem and the goals or benefits that the development effort is intended to deliver. There is a lot more about this in the next chapter, where we take a look at how to avoid some project disasters that came about because the projects had no realistic goals or scope.

In order to discover the right scope and the right goals, you might find it necessary to do some prototyping and experimenting. Although we speak mainly about the Prototyping activity as a way to discover requirements, you might find prototypes useful for modeling the outcomes of different scopes and goals. There are no precise rules for this kind of prototyping, but you should not leave the Blastoff activity until you and your stakeholders are rock-solid on what you want to achieve.

We strongly suggest that your Blastoff achieves a well-defined and universally agreed scope. Well-defined does not mean inflexible. As you move along with your requirements discovery, you usually uncover opportunities. Taking advantage of the opportunity often means adjusting the scope. So be it. As long as you remain in control of your scope and the changes that you make to it, then all should be well.

Although this is usually outside the responsibilities of business analysts, you should be aware that the context diagram—which we recommend as a way of demonstrating the scope—can be used to make estimates. For a project to be successful, you need to start out with realistic expectations of how much effort is involved.

Prototype for Requirements

Prototyping is experimenting. You are not building a prototype that is intended to be the forerunner of the final product. Instead, you are sketching experimental solutions to explore their outcomes. Prototyping means using quick models to explore the problem space.

Another reason for prototyping is to find an alternative to the presumed solution. Sometimes, at the beginning of the project, someone presumes to know the solution. The project is launched to build that solution without questioning it. Distressingly often, the presumed solution is not what is needed, so the effort expended building it is wasted. Prototyping usually discovers the right problem to solve when it demonstrates how alternative solutions yield far better results.

As you go about your requirements discovery, you will most likely find yourself switching back and forth between Prototyping and Trawling.

Trawl for Requirements

In Part IV, Trawling for Requirements, we presented a number of techniques that are productive when working with the stakeholders to discover their requirements. Not all the techniques are relevant to all types of projects. However, we encourage you to try techniques you have not used before and see if they work for you and your stakeholders.

When you are trawling, you almost certainly will encounter ready-made solutions. It is normal practice for organizations to buy something off-the-shelf rather than build everything from scratch. This means that your trawling needs to encompass the ready-made product. This might also have entailed writing the request for proposal (RFP). The most significant part of using ready-mades is adapting them to fit the organization or adapting the organization to fit the ready-mades.

However, before you can use a ready-made solution, you need to discover the real needs of the business. Additionally, you need to decide which of those needs are best served by which ready-made, and how much adaptation is worth doing. This probably means developing a scoring model to assess the relative merits of competing ready-made solutions.

Trawling should not be seen as a stand-alone activity, but as something that works with a close connection to the prototyping and some of the design activity.

Keeping Requirements Knowledge

In some circles, documentation is a dirty word. However, cooler heads know that a certain amount of it is needed. Requirements are needed to give the designers and the developers the best possible guidance on what they are to deliver. Designers and developers need to leave behind enough information about what they did and why they did it to enable future generations to understand the solution.

Anything you develop today will probably have a life of at least five years, and possibly more. This lifetime is needed to give your sponsor or client enough time to get a return on the investment. It costs money to develop solutions, and this is recovered by the improvements to the business processes that the solution enables. However, it usually takes years before the development debt is paid off.

During these years, the solution needs maintenance. Without a guide to why the solution does what it does, the maintainers are at a disadvantage. Understanding what something does is relatively easy, but understanding why it does it is much harder. Any documentation on why decisions were taken will be very welcome in a few years’ time. If the decision was a hard one, we suggest that writing a short piece on why you chose one option over another can pay off later.

You have worked hard to discover the right problem to solve and written the right requirements or stories. There is no reason to discard this form of documentation once the solution has been delivered. After all, each requirement or story carries a rationale. This explains to future generations why each requirement exists.

The requirements repository sits in the middle of the Volere requirements process. Refer to the Requirements Knowledge Model (Appendix C) for an explanation of the information that should make up your repository. This repository can take almost any form you choose: requirements specification, story map, database, spreadsheet, a mixture of the above, or something else. The form of the repository is a team or organizational decision.

Whatever you do, give more than a little consideration as to what device or software you use for this storage, and what form it will take. Your requirements knowledge is valuable. Please don’t be careless with it.

Designing

Designing the solution should not be seen as a separate activity that you arrive at once all the requirements are known. Of course, there are some facets of designing that cannot be done until the requirements are substantially complete, but a lot of design is done well before then.

You are designing solutions when you’re sketching prototypes. You’re designing when you’re thinking about and modeling business processes. You’re designing when you are in the Blastoff and deciding the scope of the problem and what is the best problem to solve.

Design thinking should be part of your requirements discovery. You have to constantly be looking out for opportunities to design something better than what is being proposed. You have to always be looking to see if a business process could be improved by a better design. And let’s face it, apart from the Parthenon and the Japanese Samurai sword, most things could be improved by better design.

Development

Development is beyond the scope of this book. As a business analyst, you might be involved in writing code, but we don’t aim to help you with Python or JavaScript or C#. What we can help with is syncing requirements discovery with the development activity.

We wrote about syncing earlier when we were discussing story maps in Chapter 35. The main thrust is that when the discovery and development are synced, the business analysts are discovering the requirements on a just-in-time basis. See Figure 39.2.

Figure 39.2

The development of the solution is synchronized with the requirements discovery. This diagram was shown in Chapter 35 where there is a full explanation of it.

This requires the product owner, or someone organizing the development activity, to find the parts of the solution that should be the next to be developed. We have urged you to manage your requirements discovery and your development one business event at a time. This makes the synchronization straightforward. The business analysts use the business event as their unit of discovery, and when they deliver the requirements for that business event, the development team has a discrete unit to implement and test. There is usually a small amount of overlap between business events; they share data, and sometimes they have some common functionality. However, this is usually easy to spot, and so the developers can avoid implementing the same functionality more than once.

This assumes that you have an in-house development team, and the solution is one that allows for incremental development. Otherwise, it might be necessary to build the complete requirements specification, and once done, the developers or the outsource contractor starts the work.

The advantage of incremental development is that there is only a short lag between the requirements and the delivery of a partial solution. When the complete specification is written before any development starts, the lag might mean that the specification is slightly out of date. On the plus side, a complete specification gives you the opportunity to check its completeness and correctness before committing to development.

The choice of development tactics depends very much on the nature of the solution, and your organization. The above should help to make the best choice for you.

Review

“ If you can’t describe what you are doing as a process, you don’t know what you’re doing. ”

—W. Edwards Deming

There is obviously a need for some kind of process if you are to effectively discover the right requirements. Such a process includes the activities needed to liaise with the stakeholders, understand their work and future ambitions for their work, and record and communicate those requirements.

However—and we cannot stress this enough—the process is there to guide you. It is not there to rule you. We have provided you with the Volere process. We have described the various parts and activities of this as we worked through the book. This process works straight out of the box, or you can adapt it to fit the circumstances of your workplace and your team. We favor the latter. Volere is not intended to be a lockstep process, but a framework for successful requirements discovery.

Your development team probably uses Scrum or one of the agile methods, so your process must fit in and work smoothly with agile development. We talked in earlier chapters about how to synchronize with your development team.

Finally, we should mention the track record of the Volere process. It has been used by thousands of projects over many years and continues to be adopted and adapted by organizations in many parts of the world. When used wisely, it opens the door to successful requirements discovery.

Resources

Business Analyst: Careers in Business Analysis by Adrian Reed (BCS, The Chartered Institute for IT, 2018). This book looks closely at the role of the business analyst, along with the responsibilities and necessary skills. It also discusses the tools, techniques, and methodologies that are used by business analysts.

Software Requirements Essentials: Core Practices for Successful Business Analysis, by Karl Wiegers and Candase Hokanson (Addison-Wesley, 2023). This presents 20 core practices for requirements planning elicitation, analysis, specification, validation, and management.

Agile and Business Analysis: Practical Guidance for IT Professionals by Lynda Girvan and Debra Paul (BCS, The Chartered Institute for IT, 2024). This introduces agile methodologies and explains these in the context of business analysis.

Business Analysis by Debra Paul, Donald Yeates, and James Cadle (BCS, The Chartered Institute for IT, 2014). This book shows the authors’ passion for business analysis. It describes many techniques commonly used by business analysts. It also looks at Lean and agile techniques for business analysis.

The Business Analysis Body of Knowledge (BABOK Guide) by the International Institute of Business Analysis (IIBA, 2021). This is an international work, and it offers a structured framework for understanding and applying business analysis practices.

Adrian Reed’s Blackmetric website (https://www.blackmetric.com) has an amazing number of resources for business analysts. His blog is interesting, and the free BA Digest is well worth downloading.

40

The Importance of the Early Days

How many large government projects (those costing tens of millions, if not billions, of dollars/euros) finish on time and on budget, and deliver all the promised benefits? Take a minute to think about this. Or take as long as you like; your answer will still be zero.

Think of large project disasters such as the California High Speed Rail that was intended to whisk Californians from Los Angeles to San Francisco in less than three hours. As of 2024, the project has been running for 16 years, and has consumed over $11 billion, yet only a few miles of rail have been laid and the project has been eviscerated down to a section running between Merced and Bakersfield, two barely known locations.

The Sydney Opera House’s original plan had four years to completion and a budget of 7 million Australian dollars. It took AU $102 million and 14 years to complete.

Denver International Airport—a new airport to replace Stapleton—was years late and cost more than $5 billion. This was a 300% increase from the original estimate.

These are construction projects. What about large-scale IT projects that failed? Same results—the answer to the opening question is still zero. Start looking around and you’ll find dozens (look long enough and you’ll find hundreds) of large IT projects that finished late, were abandoned unfinished, or were over budget and did not deliver the benefits that were originally promised.

For example, the Canadian government’s Phoenix Pay system proposed much but turned out to be an almost complete disaster (only 20% of paychecks were accurate, and some people were not paid at all). It was very expensive to fix.

Or take FoxMeyer’s Delta III disaster. FoxMeyer was one of the top pharmaceutical distributors in the United States, worth around $5 billion. Aiming to be more efficient, it launched the $65 million Delta III project in 1993. Despite its high-priced consultants, the delivered software was woefully inadequate, and the company was bankrupt three years later.

How about your own organization? How many IT projects finish on time and on budget, and produce the target benefits? The answer this time is probably not zero, but it is certainly not 100% of the projects either. Large IT initiatives are among the projects most likely to fail—they are only slightly less risky than building a nuclear power plant.

Why Do Things Go Wrong?

Why do most IT projects go wrong? Why do they run late, cost more, and deliver much less than promised? The answer is complex, as there can be a mix of different factors: politics, psychology, poor management, incompetence, inexperience, wrong stakeholders, unrealistic ambitions, hubris, and so on. But there is one common factor for all failed projects: They do not do what should be done in the early days.

We spoke about the early days way back in the chapters talking about the Project Blastoff. It is in these early days of the project’s life that you decide on the things that have the greatest impact on the success or failure of your project.

For example, it is in the early days that you determine the purpose of the project. That might seem blindingly obvious, but it is not obvious at all to the people in charge of failed projects. Consider the projects that set out to build railway lines, or bridges, or roads, or public health or payroll IT systems, where nobody, or not enough people, asked why they were doing it. Or if they did, the answer was so vacuous that it only fooled the instigators of the project and their political paymasters. And the politicians or high-level executives were so keen to start building that they did not want to hear anybody casting doubt on the purpose of the project.

Good planning, the early-days activity we are talking about here, starts with why. “Why are we doing this project?” “What is its purpose?” “What do we want to achieve?” Generally, the reason is to realize benefits to the organization. It might take several (or more) iterations for you and your stakeholders to agree on those benefits and make them tangible and understood by everyone.

Planning before starting is the antithesis of “digging a big hole.” This big-hole metaphor comes from large-building construction such as office buildings, where before you can build anything, you dig a big hole for the foundations. For multistory buildings, you dig down to the bedrock.

You have probably seen the big-hole metaphor at your work. There is a project on shaky foundations (if you will pardon another building construction metaphor), with no proper costing and poorly defined benefits. The project team rushes in and starts building something, anything (digging their big hole), before any real planning can take place. The existence of the “big hole” is expected to dissuade stakeholders from stopping the project or changing direction. “We’ve already started building, it’s too late to stop it.” It is also meant to stop any delay while sensible people try to figure out what it is supposed to deliver.

Similar to measurable objectives is having a rock-solid scope for the project. By this we mean a context diagram with all the input and output flows defined in the data dictionary. It might seem pedantic to insist on this, but projects without a clear and well-defined scope are headed for disaster. Ask anybody who has started house renovations without a clear scope and goals. They will tell you—all of them—that the renovations cost twice as much as they thought and took three times as long (these are conservative figures). Ask anybody who has worked on an IT development project with no clearly defined scope, and they will tell you the same.

For large government projects, the budgets—time and money—are set artificially low. Politicians need to sell their grandiose schemes to the taxpayers, and so the money and time needed are set at levels that can be trumpeted to the public. They do this because people are not going to vote for a project if they know the truth. Britain’s HS2 high-speed rail project had an initial estimate of between £30 billion and £36 billion. Four years after the project was signed off, the price had risen to £56.6 billion. Current estimates are in excess of £100 billion. Taxpayers would not have tolerated a project with a price tag of £100 billion, yet that is what they will end up paying. (As a side note, the ambitions of HS2 have already been scaled back, cutting in half the hyped benefits, “hugely enhanced capacity and connectivity,” but not reducing the cost.)

That’s government. Does it happen in private organizations? All the time. Project initiators need to sell it to the board; predictably enough, costs are underestimated, and benefits overstated. How many of these projects fail? All of them. None of them finish within budget, none of them deliver the promised benefits, and almost all of them deliver benefits that are considerably less than the cost of the project.

Why does this happen so distressingly often? Because people avoid putting effort into the early days where you do your planning. “Planning? That’s not real work. Requirements? That’s not real work. Let’s just get on with digging our big hole.”

“Send ‘em to the movies” was the approach used by our colleague Stephen Mellor. He was referring to the developers, and how it is wise not to start building anything until the planning is done. Another colleague, Steve McMenamin, ran very large projects for several electricity companies. Steve insisted that nobody do anything until a small group had established the vision, plan, and scope for the project. Steve’s multiyear projects always came in on time and on budget.

The Role of the Business Analyst

You are most likely a business analyst, not a project manager. What’s your role in all this? An important one. As a business analyst, you must always challenge assumptions, and where possible, provide evidence that the assumption is wrong. IT projects make too many assumptions at the beginning, many of them dangerous.

First, there is the assumption that this project is unique, and what has happened to other IT projects will not happen to this one. However, you can no more suspend the laws of statistical probability than you can suspend the law of gravity. Your project is an IT project and the mean cost overrun for IT projects is 73%, and 18% of projects achieve a mean overrun of 447%.

The source of these numbers is Bent Flyvbjerg, a consultant on more than 100 projects costing $1 billion or more, who has a database of thousands of projects, why they worked, and where they went wrong. See his book, How Big Things Get Done.

Now that you have seen those numbers, can you safely assert that your project is so unique that it will not overrun by something like 73%?

The planners of IT projects often assume that nothing will go wrong. Another wrong assumption. A quick scan of other IT projects tells you that on every project, things go wrong. Key people unexpectedly leave, there are mismatches between ready-made solutions and their expected behavior, stakeholders become unavailable, managers become disengaged, suppliers are unreliable, performance is less than expected, and on and on. If you assume that nothing will go wrong, it means your project budget has no contingency buffer. Statistics tell us the buffer should be at least 50%.

Setting out to build a presumed solution instead of solving a business problem is a big project killer. Many projects start by presuming to know the solution: We need to build a website, a CRM system, a new payroll system, and so on. Distressingly often, these presumed solutions turn out to solve the wrong problem. As a business analyst, you must challenge the presumed solution and constantly ask why the project needs to be done. By asking why, and sometimes you need to ask many times, you can arrive at the real reason—the real goal of the project—and then start to find suitable solutions.

Finally, and this is incredibly obvious but not always observed, to determine whether the expected benefits will outweigh the costs, you have to measure both of them. Inflating one and minimizing the other always ends badly.

All of these things need to be done by business analysts and project management in the early days, before someone starts digging a big hole.

Resources

How Big Things Get Done by Bent Flyvbjerg and Dan Gardner (Macmillan, 2023). This book talks through many projects that failed because they did not pay attention to the early days. Flyvbjerg is a consultant with a database of thousands of failed projects. He is called into multimillion-dollar projects that get themselves into trouble. It’s also an entertaining read.

The Mythical Man-Month by Frederick P. Brooks (Addison-Wesley, 1995). This has been around for a long time and remains the classic book on the challenges of software project management. It provides insights into why projects can go wrong.

Project Management for the Unofficial Project Manager (Updated and Revised Edition) by Kory Kogon and Suzette Blakemore (BenBella Books, 2024). This is a practical guide for the business analyst who finds herself managing without the official title of project manager.

The Project Management Institute website (https://www.pmi.org) offers a wealth of resources, including articles, webinars, and best practices related to project management.

Harvard Business Review has articles and case studies on its website (https://hbr.org) that can give insights into project success and failure.

41

People

So far, we have been talking about how to discover requirements. We have looked at a process and techniques that, when used well, make a difference to the effectiveness of your work. Now it is time to talk about another element; one that has a greater effect than any technique can hope to achieve: the people element.

Projects (at the time of writing) are staffed by people who discover the requirements and build the solutions. If the employing organization wants these people to do a good job, then it must align its values with the motivators of the people.

In this chapter, we look at some of these organizational values and how they affect the requirements discovery process.

Drivers of Human Behavior

The following draws on work that we did in collaboration with our partners in the Atlantic Systems Guild and that resulted in the book Happy to Work Here—Understanding and Improving the Culture at Work (listed in this chapter’s Resources section).

That book introduced the concept of culture drivers. Culture, as we defined it, is a set of shared beliefs and resultant behaviors. For example, if we all had the shared belief that left-handed people are significantly more intelligent, the resultant behavior would be that we would all listen more attentively when a lefty started to speak.

So, what beliefs can an organization hold that have a beneficial effect on the behavior of its people? We have isolated four such beliefs, which we call culture drivers, and although there are others, these are the four that have the most impact.

The Perceived Value of People

How does your organization see its people? Are they an inconvenient but necessary burden on the bottom line? Are they seen as untrustworthy and error-prone? As lazy and not very competent? If any of these are true, then apart from suggesting you seek employment elsewhere, we propose that this lack of value is having a negative impact on your requirements discovery process. We’ll explore this as we go along.

Does your organization acknowledge that people are its most valued asset?

On the other hand, if your organization acknowledges that its people are its most valued asset, then it hires better people and looks after them. This might seem incredibly obvious, but you can observe whether it’s true by observing its hiring process. Does it put a lot of effort into finding the right talent, or does it simply fill vacancies with the first (or cheapest) person to roll along? Is it more concerned with people’s ability than whether there are enough people to fill the available desks?

As part of valuing its people, does the organization celebrate people for achieving something? Or is it more focused on blaming people when something doesn’t work? There is always an element of risk when people are innovating and trying new things, but if failure is always punished, then few people are willing to take any risks at all. In requirements work, this translates to overly heavy specifications and overly detailed descriptions of every requirement; both of which are a waste of time for normal projects.

Additionally, good, highly valued people are not managed on a minute-by-minute basis. They make their own decisions about what their requirements discovery process should be. They also make responsible decisions about when their requirements are in a state that it is safe to move on, and when more discovery needs to be done.

When they are valued, people gravitate toward processes that are effective, rather than what is prescribed; they opt for processes that are as light-touch as possible, without compromising quality. They have greater flexibility when they put together and use their requirements process.

The Perceived Value of the Team

The next culture driver has to do with teams. Teams are made up of individuals, each of which has his/her own set of skills, abilities, and ways of approaching their work. However, when those individuals come together and form a team, something mystical happens: The team forms its own personality.

One trait of this personality is team self-confidence. Team self-confidence means that the team always presses forward, confident that it can overcome any obstacle that appears and confident that it will recover quickly from any errors that it makes. The self-confident team almost always selects a process that involves prototyping and partial and frequent development cycles that deliver incremental parts of the solution. In other words, the self-confident team selects a riskier process that will deliver results more quickly. If some of the risks result in partial failure, the team is confident that it can recover the situation with no permanent damage to the project. It should be kept in mind that self-confidence is not the same thing as arrogance.

Another team personality trait is the value it puts on excellence. An excellent team always tries to deliver the best possible solution within the constraints. Second best is not good enough for the excellent teams, which in turn engenders pride in the team’s work. Moreover, excellence attracts excellence. Organizations and teams that turn out excellent work are desirable places to work. The best people want to work there because they want to do good work. And so this virtuous cycle means that teams become better and better at adjusting their process to produce solutions that meet the real requirements.

The Perceived Value of Knowledge

Knowledge is one organizational asset that is often handled carelessly. Yet, the knowledge that an organization gathers as it goes about its work is second only to people in terms of value. If we look at this with regard to requirements, then the team or organization that values its knowledge ensures that requirements (the foundation for product development) are recorded in a way that will make sense ten to fifteen years later.

It is tempting to say that the code is the best documentation of what it does. In some, usually simple cases, this is true. However, the code does not reveal why it does something, and often—more than often—the rationale for a requirement is a crucial part of the knowledge. If you understand why something is the way it is, then you are in a position to make improvements and respond to changes in the requirements throughout the life of a product. Being able to pass along the rationale for the requirements means that future maintainers don’t accidentally introduce new problems when making changes by failing to understand why the solution was built that way.

Teams that understand the value of knowledge put a great deal of emphasis on collecting that knowledge in the first place.

Teams that understand the value of knowledge put a great deal of emphasis on collecting that knowledge in the first place. These teams understand that if you are to build the right solution, you must have a correct knowledge of the problem to be solved. They don’t start building until they are confident that they have enough knowledge. Moreover, every team member and most of the stakeholders have equal access to that knowledge.

This means that their requirements repository is carefully curated, is progressively added to as knowledge is gained and refined, and is constantly being accessed and used by team members. Along the way, team members are constantly learning and are sharing their knowledge with their teammates via the repository.

Requirements knowledge can take many forms, but generally it is a specification, a story map, a collection of individual requirements, diagrams, and so on. Because they value knowledge, and the quality of that knowledge, there is nothing in the team’s repository that is not useful.

The Perceived Value of Time

Many projects are obsessed with time—everything is urgent. This obsession mandates that getting the solution finished in the least amount of time is the prime objective. Of course, if aliens from the Yilktor 9 galaxy are traveling at warp speed toward Earth with the intention of enslaving humanity, and your project is to deliver a force field for keeping them at bay, then of course it’s urgent.

However, most of us are not being attacked by Yilktorians, and most of us know that the right amount of time to be allocated to a task is the time needed to produce a high-quality product. We also know that allocating more time—up to a point—improves the likelihood of producing a better product. Having time means that the team can explore alternatives to find a superior solution. It also means the team has time to ensure that the requirements are accurate and are drawn from a wider range of stakeholders.

More time increases the likelihood of producing a better product, but ….

However, spending too much time on a project exposes it to unnecessary risks. On overly long projects, there is a risk that key team members leave; a risk that market conditions change; or a risk that changes in technology mean the product is no longer technically viable. Over time, management at our organizations change. Sometimes this means that new managers change the direction or goals of our projects.

Allocating too little time for a project is also damaging to the final product. Putting people under pressure to deliver in ridiculously short time frames results in products that are lower-quality, bug-ridden, missing some of the requirements, not adequately tested, and so on. It also has an adverse effect on people. People want to do good work, and they resent it when, due to time pressure, they are unable to do so. And if the time pressure is perceived as being unnecessary, they lose respect for the organization and its management.

Time has values that are more than the passing of hours and days. It is a nonrenewable commodity that must be treated carefully. Your choice of requirements process must therefore balance the amount of time needed to achieve the right result against allowing too much time and becoming victim to chance happenings, boredom, and lack of interest.

Review

How you organize your requirements activities should not be dictated by a set of rules or a rigid method. Paying attention to the people and teams you have available and determining which requirements activities are best suited to the people will yield the best value to your situation.

Having an excellent team for your project helps. It helps a lot. But you only get excellent teams when people are given the chance to flourish. Restricting people with unnecessary procedures and rigid processes will not get you an excellent team. On the other hand, allowing people to be flexible with their processes, allowing sufficient time, and being obsessive about producing excellent work attracts the kind of people you need to make excellent solutions.

Resources

Happy to Work Here—Understanding and Improving the Culture at Work by Steve McMenamin et al (Systems Guild, 2021). This looks at how workplace culture goes wrong, and what you can do to make it better for the people at your work.

Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco et al (Dorset House, 2009). How do people on your projects behave? You’re bound to find more than one behavior pattern that applies to your people in this book.

Leaders Eat Last by Simon Sinek (Portfolio; Illustrated edition, 2014). Anything by Sinek is worth reading, and his website, simonsinek.com, has lots of resources. In this book Sinek explores how creating a supportive and trusting environment leads to highly effective teams.

TED Talks ted.com Look for talks leadership, teamwork, and interpersonal skills. Check out Simon Sinek, Brené Brown, and numerous other thought leaders.

Harvard Business Review. Look for articles on team dynamics, and communication to find relevant insights and case studies about people on projects.

42

Systems Thinking

Many people reading this book have the job title “business analyst” or something similar. Analysis means dissection: breaking a system into its components in order to study them. Contrarily, systems thinking is examining a system in its totality. Instead of thinking about the components of a system, you are looking at the connections between the components and the effect that one component can have on others. You are also looking at the outcome of the system and you can think of the outcome as why the system exists.

Systems thinking starts by thinking about your business area—your problem space—as an end-to-end system; that is, a system made up of a set of components that produces something that none of the components can do on its own. So, let’s not look at the components but at the aggregation of the components and the ways in which they interact.

But let’s not stop there. All systems are connected to other systems. This is very apparent when you think of the internet. Via the internet (a system), your phone (another system) is connected to the system that is run by your bank, which in turn is connected to your employer’s payroll system. Think of that delicious moment when your monthly salary pops into your bank account, and try not to think about that less-than-delicious moment when your energy company uses your direct debit mandate (the direct debit system is a subsystem within the bank’s system) to move your monthly payment into its account (yet another system).

Given that everything is connected to everything else, your systems thinking should include the adjacent systems that surround your own problem space. Happenings in those can have an impact on your space, just as happenings in your problem space impact the outside world.

Thinking About Systems

As an example of systems thinking, imagine a clutch of teenagers. Think of each of them as a component in the following social system. Tracey tells Vijay that she is breaking up with him. Later that day Vijay is approached by his friend Billy, who asks Vijay if he wants to go to the movies that evening. Vijay is in a bad mood from being dumped by Tracey and so he says no. Billy wants to go to the movies, so he asks Zuri (who he knows but is not particularly close with) if she wants to go. She says yes but wants to bring her friend Janice. Billy, Zuri, and Janice go to the movies; Billy and Janice get on particularly well and make a date for the following weekend. Zuri loves the movie (she had not heard of it before) and decides to find more of the director’s movies on her parents’ streaming service. Enough about teenagers, let’s stop there.

Now let’s consider that if even one of the components acted differently, then the outcome of the system (the clutch of teenagers) would be different. This time Tracey does not break up with Vijay. Billy and Vijay would not have gone to the movies, so Billy would not have met Janice. Zuri would not know about the director and would not see his other movies.

The point of the story is that Tracey’s action had an impact on Zuri’s movie preferences, and if some of the other participants had acted differently, it would have impacted one or more of the others.

As another example, think of a website selling products online. The website is a system made up of components: the display area where the goods are shown to the customers; checkout; payments; fulfillment; inventory control; warehousing; delivery; returns; and support. (If you prefer, you can think of “components”' as subsystems, features, processes, activities, or whatever.)

When you think systemically, you see the website and its support processes as a network of interconnected components. Connections in this case might be a direct data flow, or it could be that one component stores data that is used by one or more others. That they are connected means that any component can affect almost any other component, and any component is dependent on the actions of the others.

The online selling website is illustrated on Figure 42.1. Imagine it in action and consider what happens with the Checkout activity when someone is finalizing their purchase. It has to ask the Delivery activity for an estimated delivery time (to allow the customer to pull out of the sale if the delivery time is too long), it checks with Inventory that stock is available and asks for it to be reserved for this sale, and it signals the Payments activity to collect the customer’s money. When that is done it records the sale as final on the database. This will be retrieved by the Fulfillment activity that results in the product being delivered to the customer.

Figure 42.1

Think of the website as a network of components with direct or indirect connections between the components. What happens in one affects one or more of the others.

Now consider the requirements. Suppose that you are renewing the Checkout activity. Obviously, you need the requirements for checking out, but you also need the requirements for interacting with the other activities. What data do you retrieve from the Delivery activity? Does it calculate delivery time, or is that a requirement for the Checkout activity? If the Delivery activity does it, what data is needed to do it? Similarly, the other activities have requirements for how they will interact with the renewed Checkout. You also need to look at whether any of those activities impact any of the others and generate yet more new requirements.

Systems thinking means that you are concerned with the wider system. Although you are charged with renewing the Checkout activity, you have to step back and take a wider, systemic view of the big picture of the problem space.

Ripple Effects

There might also be ripple effects. You are probably aware that the “ripple effect” uses the analogy of the ripples spreading out from a stone thrown into a pond. Here we use it to refer to the likelihood that an error in one part of a system causes a failure in another part, which in turn causes a further failure, which in turn … and so on. Ripples could happen if your new Checkout activity had a fault, or introduced some new data, or removed old data, or put data into the database, which in turn caused the Inventory activity to produce incorrect results, which in turn caused discrepancies in the Fulfillment activity. Sometimes you see the ripples right away, but sometimes they travel a long way before becoming apparent.

For the want of a nail, the shoe was lost

For the want of the shoe, a horse was lost

For the want of a horse, the rider was lost

For the want of a rider, the message was lost

For the want of a message, the battle was lost

For the want of a battle, the kingdom was lost,

and all for the want of a horseshoe nail¹

FOOTNOTE 1

Ancient proverb that probably dates back to the 13th century. Benjamin Franklin picked it up for his Poor Richard’s Almanack in 1758.

From the requirements perspective, it means looking outward from the component you are building and determining which other components can be affected by ripples.

To summarize so far, any business area for which you are discovering requirements is never isolated. It has connections to other business areas, which are in turn connected to others. What you do with your business area can affect others, just as those business areas can affect yours. You have to look at the network and avoid constraining your discovery. Your discovery is always wider and more intricate than you first thought it would be.

Step back and see the bigger picture.

External Influences

Consider the following example, which is the ticketing solution for the Mudville² baseball team who play their home games in Mudville Stadium. The initial context diagram for this solution is shown in Figure 42.2. However, systems thinking says that this is not a wide enough scope to accommodate the external influences that can disrupt such a system. Let’s see how this works.

Figure 42.2

The context diagram for the Mudville ticketing solution

FOOTNOTE 2

Mudville is from Ernest Lawrence Thayer’s poem “Casey at the Bat,” written in 1888 for the San Francisco Examiner.

The Team Manager advises the ticketing solution of the matches to be played. The ticketing solution promotes the matches to the fans (there is other publicity, but it does not concern us here), and all being well, the fans buy tickets to the matches. The tickets are sent out as e-tickets.

The ticketing solution uses a database of the stadium seating plan when selling tickets. This shows the blocks of seats in the stadium, and the fans use this to select the seats they want. Different blocks have different prices according to the viewing advantage of that block. Figure 42.3 shows the model of this data.

Figure 42.3

The data model for the Mudville ticketing solution

The stadium is divided into stands, each containing a number of blocks. The asterisk beside Block indicates that there are multiple Blocks in a Stand. The block is made up of a number of Rows (again, the asterisk), which in turn contain a number of Seats. When a seat is sold, a Ticket for the match is created for it to indicate its sold status. The 1:1 on the diagram indicates that a ticket is for one seat only. Access to several blocks of seats from outside the stadium is via a Gate. The gate number is printed on the ticket, and fans are encouraged to enter via the correct gate for their block. This avoids unnecessary movement within the stadium.

The Wider View

How do you know that the context diagram shown in Figure 42.2 is complete? You use systems thinking. A useful entry point for systems thinking is a quotation from American theoretical meteorologist Edward Norton Lorenz:

“If a butterfly flutters its wings in Brazil could it cause a tornado in Texas.”

The quotation comes from a lecture Lorenz gave in December 1972. He was referring to the weather being a chaotic system, and even small occurrences in one place could have a major impact somewhere quite distant. The quotation gave rise to the Butterfly Effect, a metaphor for the principle of chaos theory. We are not dealing with chaotic systems, but we should still consider small happenings that can have significant effects elsewhere.

Even small occurrences in one place could have a major impact on a distant part of the system.

An occurrence can be large or small. Consider these happenings in Mudville. A water main on Casey Street bursts. This causes the street to be closed until the main is dug out and fixed. This would not be interesting to a ticketing system, except that Casey Street is a major access route to Mudville Stadium, and fans with tickets for gates on Casey have to be advised to use alternative gates.

Another happening: During a routine inspection, the support structures under blocks 2 through 5 of the East Stand are found to be in an unsafe state. The stadium manager immediately advises the ticketing solution to stop selling tickets in those blocks and notify fans who have already bought tickets to negotiate an exchange of seats.

FOOTNOTE 3

The first baseball game in the United States was played in Pittsfield, Massachusetts, in 1791.

For really big games (Mudville versus Pittsfield³ is a very well-attended match), the police might issue security restrictions, and again, fans might have to be notified. Additionally, the police have requested to be told when ticket sales exceed a threshold, as they (the police) need to assign extra officers for crowd control outside the stadium.

Coming back to the butterfly, one must have fluttered its wings, because the weather forecasting service issued a warning of an extreme weather event. A huge snowstorm is predicted for game day, and the team managers of both teams decide that for the safety of the fans and the players, they will postpone the game. Now the team manager needs to notify the ticketing solution, which starts the process of notifying fans and issuing tickets for the rescheduled game.

So, we are seeing how happenings outside our problem space can have an impact inside it. Using systems thinking during the requirements discovery means that you step back as far as possible to see the happenings that can potentially impact your solution. You have seen in the above example how you now need requirements to exchange tickets, to notify ticket holders of changes, of rescheduling tickets, and so on. There are also requirements for notifying the police when ticket sales reach a certain threshold.

Using Data to Find Missing Connections

You should also refer to the data. Look at the data entities/classes, and for each one ask what could happen that could impact that data. Here you can use the Create, Read, Update, Delete (CRUD) checklist (described fully in Chapter 37, Completeness Check) to help you discover happenings that you might have missed.

All of this means that the context diagram has to be substantially revised. Figure 42.4 shows the revision.

Figure 42.4

The revisions discussed above are shown using darker lines over the original ones in gray.

The changes to the context diagram have come about because systems thinking says that any system is actually part of a larger system, and therefore potentially subject to the impact of happenings in that larger system. Equally, happenings within the smaller system can have an impact on the larger one.

For example, if the Mudville ticketing system sells lots of tickets for a game, it advises the police, which would then put crowd control measures in place. This might involve closing off streets in the town or drafting in extra officers to help manage the crowd. So, a humble ticketing system causes the town police to act.

Any solution that you deliver has to slot into its ecosystem.

As a business analyst, we suggest using systems thinking as part of your requirements discovery. Any solution that you deliver will have to slot into its ecosystem—the real world that surrounds the solution. Which means that butterflies fluttering their wings could have some meaningful impact on your solution. It is part of your requirements discovery to uncover the butterflies so that the solution is not subject to unforeseen happenings. All potential impacts should become known at discovery time.

Review

Following are heuristics for systems thinking:

● Step back, and then step back further.

● Everything is connected.

● Ripples can travel a long way.

● Think of the holistic system.

● Your solution is part of an ecosystem.

● The solution’s data impacts and is impacted.

● Ask why the system exists.

● Butterflies can be dangerous.

Resources

Thinking in Systems: A Primer by Donella H. Meadows (Chelsea Green Publishing, 2008). This is pretty much the standard text on systems thinking and how to apply it to real-world problems.

Systems Thinking for Curious Managers by Russell Ackoff and Herbert Addison (Triarchy Press, 2010). This presents Ackoff’s f-Laws, 80 or more insights into systems thinking.

The Fifth Discipline: The Art and Practice of the Learning Organization by Peter Senge (Crown Business, 2006). This explores systems thinking as a key component of organizational learning. Senge’s cause and effect diagrams are useful.

The Systems Thinker Magazine (https://thesystemsthinker.com) has articles and case studies on systems thinking and its applications.

The Donella Meadows Institute (https://donellameadows.org) offers resources, articles, and workshops related to systems thinking and sustainability.

Systems Thinking, Systems Practice by Peter Checkland (Wiley, 1993). This book began it all when Checkland wrote about soft systems methodology. This contrasted “hard” systems—which can be engineered—with “soft” systems in which the focus is on making sure the process of inquiry into real-world complexity is itself a system for learning.

43

Artificial Intelligence (AI)

Writing anything about artificial intelligence is doomed. The field is expanding and changing so quickly that a lot of what is written is obsolete almost before it is read. However, it is something that will have an impact on all our lives and will also impact the way we go about discovering requirements. It is already doing both of those and will do it to an even greater extent in the future.

Artificial intelligence (AI) is the name given to intelligent machines, or bots (software, really), that mimic human thinking capabilities. AI bots understand and process natural language and images, and so respond much as a human would. This is referred to as general or strong AI, as it can reason, solve problems, and learn from experience, very much like a human being. General AI is useful for your requirements discovery tasks. You can chat with it, ask questions, and ask for recommendations for requirements.

Narrow AI engines are specialized and designed to perform a specific task. They can also learn from experience and make decisions. Embedding this kind of AI in business processes is beneficial. For example, you might embed AI in a warehouse management solution to monitor stock as it comes into the warehouse and goes out as it is sold. Demand for different items changes due to seasonal demand and fashion. AI would learn which items are in demand, what trends are forming, and predict popularity more accurately than a human could. It would also suggest housekeeping routines whereby the popular, and soon to be popular, items are moved closer to the dispatch bays. Your task as a business analyst is to discover opportunities to use AI as part of your customer’s business process.

AI will establish itself as an essential part of our businesses and business processes. To what extent it transforms from being the faithful servant to controlling more and more of a business remains to be seen. In the meantime, we can get the best of the opportunity that AI provides by using it as an intelligent and useful assistant.

Using AI for Requirements Discovery

You can ask one of the AI bots, such as ChatGPT from OpenAI, to generate a set of requirements for the solution of your choice, and the bot will search a large amount of data looking for specifications for similar applications. It then returns a proposed specification. Job done; take the afternoon off. Or can you?

It might work if you’re prepared to risk your customer’s future business (and possibly your job and reputation) on the accuracy of the AI bot. Also, consider that AI uses historical data to generate its requirements. This means that the AI-generated requirements probably won’t go beyond what exists at the moment. Additionally, some AI bots have been known to sometimes generate completely fictitious results.

However, all of that does not mean that AI cannot be useful to you as a business analyst. It can be very useful indeed, if you think of it as your assistant and not your replacement.

Suppose that you are prototyping, and you’re looking for ideas. You ask your AI chatbot for a process model by prompting it with this:

“I am selling shirts. I need a process to fulfill the orders from my customers. The fulfillment process must include packaging and shipping the shirts to the customers.”

We tried it, and ChatGPT came back with this:

Sure! Here’s a process for fulfilling orders and shipping shirts to customers:

Receive the order: Once an order is placed, you will receive a notification from your e-commerce platform or website.

Prepare the order: Locate the shirt(s) in your inventory and check for any defects or quality issues. If the shirt needs to be printed with a design or logo, do so at this stage. Then, package the shirt(s) securely, ensuring they are protected during shipping.

Choose a shipping carrier: Decide on a carrier for shipping the package. Popular options include USPS, FedEx, and UPS.

Print shipping label: Once you have chosen a carrier, print out the shipping label provided by your e-commerce platform.

Mark as shipped: Mark the order as shipped in your e-commerce platform, and provide the customer with the tracking information.

Deliver the package: Deliver the package to the shipping carrier or schedule a pickup for the package to be picked up at your location.

Follow up: Monitor the shipping status to ensure the package is delivered to the customer successfully. If there are any issues or delays with delivery, communicate with the customer and the carrier to resolve the issue.

Treat this as a starting point, and for each AI-generated step in the process, ask the following questions.

● Is this touching a topic that you have not previously considered?

● Does it suggest one or more processes that have not yet been discussed with the stakeholders?

● Can this be used as is, or is it more useful if modified?

● Does the suggested process suggest that you are solving the wrong problem and should revise your prompt?

● Does it require drilling down to find the details before you can decide its usefulness?

● Should you refine your prompt and see if the chatbot can produce a better process?

● Or would it be profitable to abandon this process and generate another using a different prompt?

The point is not to have AI generate your processes and requirements, but to use it to generate input to your analysis and innovation.

The point is not to have AI generate your processes and requirements, but to use it to generate input to your analysis and innovation.

There are other ways you can use AI for requirements discovery.

You could also ask your AI chatbot to write preliminary stories. Some of them might be useful for your story map; others will need investigation and modification before they become useful. The point is to generate input for your analysis. If you prompt well enough, you could get valid stories from the AI bot, but prudence says that you should check everything carefully.

Natural language processing (NLP) is part of AI and is used to analyze large volumes of text and to identify patterns. You can use this ability in your requirements discovery. For example, you can ask your AI chatbot to analyze your support tickets to determine common themes or patterns from the customer difficulties registered by the support people. These themes indicate the most important areas to deal with and will probably suggest requirements that might not have been obvious before. Similarly, your chatbot should analyze customer feedback and user reviews to find the good, the bad, and the ugly with the current business. Again, this analysis should help you find previously undiscovered requirements.

Analyzing large volumes of customer feedback should give you strong indications for your prioritization. Knowing, not guessing, what is important to your customers should be one of the prime drivers of the priority in which you discover and develop requirements.

Machine learning (ML), another part of AI, builds models from the supplied or training data. The models are predictive; they help you identify potential future requirements. This relies of course on having the right training data. So, let’s suppose that you have the right data on your and your competitors’ products. By analyzing the way that these products are used, it is possible for ML to identify patterns of usage and make predictions on different ways that your product could be used in the future. ML would also identify the features or processes in the products that caused the most complaints or that customers found hard to use.

This is grist for your business analyst’s mill—these predictions are the basis for requirements that can enhance your current product or be incorporated in new products.

Business rules are sometimes hard to find, yet they must be incorporated into any new solutions you develop. They are hard to find in many organizations because there is no central repository. If the organization is using a business rules engine, then the problem is solved—all of the rules are in one place and the only requirement is to consult the business rule engine whenever the solution needs a business decision. That is of course providing all the rules are in the engine. On the other hand, if there is no central repository, then natural language processing (discussed above) can sift through huge amounts of data to uncover the business rules for you.

Data mining techniques can be used to analyze data from various sources to identify requirements. Because there is so much data to mine, you need the help of NLP or a chatbot to do most of the work. You might start with your bot analyzing your customer support tickets to determine the most common problems and write requirements to alleviate or eliminate the problems. You might have the bot trawl social media posts to find what customers like and dislike.

If your customers are willing, chatbots can be used to interact with them directly in a conversational manner. The idea is for the chatbot to explore and uncover requirements that might not have been obvious to you or your customers. There is a caveat: You should never give confidential information to a chatbot. The chatbot sees and remembers everything, and you have no idea what it might do with your confidential information.

AI has a role in requirements discovery if used wisely. It should be seen—at least in the foreseeable future—as an assistant to help you find the requirements. It can also help you find new and innovative requirements that otherwise might not have come to light. To do this, it is of course important that the data you’re using is high-quality data and that the AI algorithms are accurately trained.

You can ask your AI assistant to check your requirements and stories. It can root out ambiguous terms and inconsistent terminology. It might (no guarantees) find gaps in the requirements, or ambiguous or misdirected requirements.

AI is a powerful tool, and it has a future assisting you with your business analysis and requirements discovery.

AI in Business Processes

The next facet of AI comes into play when you propose to have AI as part of your solution. Suppose that you are working on a traffic monitoring system. The intention is to control the traffic lights of a major city, with the goal of maximizing traffic throughput. When the lights are properly coordinated throughout the city, traffic is able to move more quickly and smoothly with fewer interruptions (such as being stopped at the lights, or in gridlock).

Traffic volumes and the needs of drivers vary throughout the day. After the morning commuter rush, delivery trucks with their frequent stops take over, then this is replaced by the lunchtime traffic pattern, and so on until the afternoon commuters return home. Then, the evening pattern kicks in with people going out for their entertainment.

The regular usage patterns make programming traffic lights more complicated, but what makes the task even harder is that these patterns evolve and change over time. Sometimes these changes are gradual, and sometimes they happen quite rapidly. For example, people are coming into the office less frequently, with some weekdays—particularly Fridays—having very little commuter traffic. Seasonal sales can bring people into the city to go shopping. Special events and public holidays have an impact, as does the weather. We have also seen how a pandemic can have a marked impact on traffic.

Enter AI. Your plan is to have a real-time AI component learn the evolving traffic patterns and the volume of traffic in different parts of the city. It will manipulate the traffic lights to optimize the traffic flow according to current conditions.

Now your business analysis skills come into play. AI can only be as good as the questions it is asked. That is, the AI engine has to correctly understand that your intention is to optimize the traffic flow, and exactly what you mean by “optimize.” Does that mean that a vehicle will get to its destination more quickly, or does it mean that because of the smooth flow of traffic, the driver perceives he is getting there sooner, even if his speeds are actually slower? Does “optimize” mean that traffic coming from, say, the north, is given higher priority than that from the west? Your bot cannot “optimize” traffic unless the prompts you feed it lead in the right direction.

Prompting

Prompt engineering, the term for working out the best prompts or questions for AI, should now come up with a prompt that optimizes traffic in the city. As indicated above, you must be precise as to the meaning of “optimize.” The prompt would be much longer than a single sentence, as you are dealing with a complex problem. An embedded AI bot is prompted once at the beginning. Thereafter—if you have prompted correctly—it will learn about traffic and continue to refine its behavior, resulting in a continual improvement in the city’s traffic flow.

Let’s look at the learning part. As time progresses, the AI bot learns what works and what doesn’t. It learns, for example, that fires disrupt traffic, so it learns at which times of the day fires are more likely to occur. It learns how to set the traffic lights to get the fire engines to the fire as quickly as possible.

Your prompt would have had to tell the bot what you want it to learn and what to do with what it learns. Your prompt also tells the bot what it must never do (turn all the lights green), and any other rules it must stick by.

This is a shift in the business analyst’s responsibilities. You are now engineering prompts to produce the optimal results from your AI bot. Your analysis is about reaching a common understanding of the problem, and what role AI is to play in the solution to the problem. AI is not smart enough (yet) to understand what you are trying to achieve unless you tell it.

Your ability to write the correct prompts determines the value that your AI bot can deliver. Writing good prompts starts with understanding the real problem, which is more or less what we have been talking about throughout this book. That is, find the real problem and write the right requirements. Think of a prompt as the requirements for the AI bot. You have already seen that the right approach to requirements discovery leads to the right requirements. The right approach will also, of course, lead you to write the right prompts.

BA skills will evolve over time as AI evolves, but whatever happens, it will be exciting and promises some wonderful business analysis opportunities.

Review

The greatest potential for artificial intelligence, as far as the business analyst is concerned, is for it to be an assistant for discovering requirements. It can assist by suggesting lines of questioning, it can assist by suggesting innovations, and it can assist by reviewing requirements documentation.

AI will become part of most business processes. Your role as a business analyst is to understand what AI can do as part of those processes and to engineer the right prompts to cause the AI bot to perform as needed. This, in a way, is what BAs have been doing all along: discovering the correct problem to solve, discovering the best solution for the problem, and writing the requirements (in this case, prompts) to cause the right solution to be built. Learn whatever you can about AI. It is a significant part of your future.

Resources

As we mentioned at the beginning of this chapter, anything you write about AI is doomed to obsolescence. So, we feel it is hardly productive to give you a list of books and other resources that will be out of date by the time you read this.

At the time of writing, AI is showing explosive growth. New books, articles, and websites are appearing almost by the hour. Our best recommendation for getting an up-to-date list of references is to ask ChatGPT (https://openai.com/chatgpt) or one of the other bots to give them to you.

You might check out How to Create a Mind by Ray Kurzweil (Penguin Books, 2013). This looks at reverse-engineering the brain to understand it and using that knowledge to create intelligent machines.

Sal Khan, the founder and CEO of Khan Academy, in his TED Talk (https://www.youtube.com/watch?v=hJP5GqnTrNo) argues that artificial intelligence will trigger the greatest positive transformation education has ever seen.

44

Learning as You Go

Every time you do something you learn something, and you reuse lessons that you learned in the past. Over time, every individual builds up a store of knowledge, and the more knowledge a person has, the more valuable he is to his employer. However, when he goes home at night almost all of his knowledge goes with him. Fortunately, his knowledge comes back with him the following morning. Inevitably when he leaves the organization, his knowledge leaves permanently.

This situation could be summed up by saying that people learn, organizations don’t. That is, unless the organization has a way of capturing and retaining knowledge as it is acquired. The part of that knowledge we are concerned with here is often called “lessons learned.”

Lessons learned is the process of capturing information about what went right and what went wrong on a project. Learning about successful projects helps other projects adopt the same strategies and techniques. Learning about failures helps to prevent other projects from repeating those mistakes in the future. It is of course important that you are not operating in a toxic blame culture, and that people feel confident to speak freely about their projects, knowing there will be no recriminations.

“ A lesson will repeat itself until learned. ”

—Unknown source

Lessons Learned

Lessons-learned sessions are traditionally held at the end of a project. However, by this time everybody is exhausted, exhilarated, regretful, and probably unwilling to rehash a project that has consumed their life for the last six months or more. It is more likely the lessons will be better learned if they are learned progressively.

Possibly the most valuable lessons-learned session is the one you hold at the beginning of the project. Team members can revisit similar projects from the past with a view to avoiding the mistakes and making the most of the successes. It is useful to keep in mind that even though you think of your project as unique, it should be seen as one of many projects of the same category or with the same characteristics. Your project will be subject to the same problems, setbacks, mishaps, staffing issues, and so on that have plagued others of the same type. It is also worthwhile to look outside your own organization for lessons that have been learned by other people’s projects.

“ One of the strong points in IBM’s project management model is lessons learned, which is conducted on every project. ”

—John Capron, technical team leader, IBM

It is of course profitable to have informal lessons-learned sessions throughout the project. For example, members of a Scrum development team meet at the end of each sprint for a retrospective. These are short sessions where the team discusses what went well, what problems were encountered, and what they could do better. These improvements are incorporated into the next sprint. This should be more or less what you do throughout your requirements discovery. The intention is that if things do go wrong, you and your team learn about them as soon as possible and find a way to prevent them for the rest of the project.

Lessons from Requirements

What lessons can you learn during a requirements discovery effort? We suggest these (in no particular order).

Scope creep: Is the scope creeping? Are new business events being added? Are unexpected requirements occurring? Scope creep is generally not a good thing—it interferes with predictions on the duration of the effort, and in some cases nullifies the point of the development project. It is also useful to check previous projects for creep and from those projects, see how much impact creep had on the project. The extent of the creep is significant. There will always be some creep, but once it starts to exceed 10% to 15% of the original scope, there is cause for concern. When scope creep becomes excessive—say, more than 45%—your project is out of control and you should seriously consider abandoning it.

Effectiveness of requirements: Are the developers producing the expected solution from your requirements? Do they understand the requirements, or are they asking too many questions? If they are, it suggests that the requirements and their support documentation are inadequate. Requirements are crucial to the development effort, and if there are problems with them, the problems should be corrected before significant damage is done.

Stakeholder behavior: Stakeholders, and the way they respond to your requirements discovery, play a major role in the success of the development effort. Are the stakeholders making themselves available, and cooperating when they do? Do you have the right stakeholders? Are they competent and knowledgeable enough to provide the information you need? Are their expectations misaligned with the goals and timetable of the project? If there are stakeholder problems, earlier lessons-learned reports could have warned you about them.

Project timetable: Will you be able to meet the project’s delivery dates? Lessons learned from previous development efforts should warn of this. Some managers love to set deadlines that are deliberately short, but allowing too little time rarely produces the desired result. If your project timetable leaves too little time for the work to be done properly, then you are obliged to raise a red flag and say that the required effort means that an on-time delivery is impossible.

Changing requirements: The important lessons to learn from changing requirements are the reasons they change. Sometimes there are legitimate changes—the nature of the business has changed, or a technological advance enables a different business to be done. Otherwise, if the requirements are frequently changing requirements, it signals that the requirements are not correct in the first place. Alternatively, the requirements might be solutions and not business requirements, and it quickly becomes clear that the solution is solving the wrong problem. There are lessons to be learned from changing requirements—much of the time the problem lies with the requirements process.

Benefit shortfall: As you progress with your requirements discovery, you should be constantly questioning whether the cost of your efforts will outweigh the benefits the eventual solution will bring. The initial enthusiasm for the project often generates unrealistic expectations. The lessons learned from this and previous projects should alert you that the project is unlikely to deliver value.

What went well: It’s not all darkness and disaster. Your lessons-learned sessions should reveal the aspects of your requirements discovery that work well. If some team members report that the stakeholders respond favorably to particular techniques, then more of the team should try them. Similarly, in lessons-learned sessions you will hear about the best stakeholders to talk to, ways to write better requirements, and anything else that the team finds productive and effective.

Recording the Lessons

Lessons learned must be recorded—they are too valuable to leave solely in the heads of the team members. This documentation need not be elaborate, but it should include descriptions of the good things and the bad things, and the recommendations on avoiding the bad things in the future. This documentation should be made available to all stakeholders, and they should be made aware that it exists.

There are several specialized automated tools for capturing and disseminating lessons-learned knowledge. There are also everyday document management systems (your organization probably has one) and intranets and collaborative document systems. If your organization does not already have an automated way of storing lessons learned, given the availability of tools, it should be relatively easy to set one up.

Lesson learning is, or should be, organizational learning. It is of such value to you and your team that it should be a normal part of the way that you conduct your business analysis. Sadly, many teams, and many organizations, ignore the lessons of the past. Sadly, many teams and many organizations repeat them.

Review

Figure 44.1

The virtuous circle of learning lessons. This is a self-reinforcing cycle that continually builds organizational knowledge.

Resources

The Fifth Discipline: The Art and Practice of the Learning Organization by Peter Senge (Crown Business, 2006). Senge was one of the early writers in the field. His diagramming of cause and effect is excellent.

Black Box Thinking by Matthew Syed (Portfolio, 2015). This book explores how learning from mistakes can lead to better decision-making and innovation, with examples from various industries.

The Lean Startup by Eric Ries (Crown Currency, 2011). This book offers insights into the process of building a business by learning from mistakes, iterating, and continuously improving.

The Association for Talent Development (https://www.td.org) has resources and articles on learning and development within organizations and project teams.

45

Requirements and Innovation

Not a lot of people think it is part of their job to be innovative. And yet, it is your (and your team’s) ability to produce fresh ideas that stands between your customer and obsolescence. Without innovation, any solution will be more or less the same as the one it’s replacing. New ideas are needed to keep ahead of your competitors, and to provide better solutions for your customers.

You, as a business analyst, have a responsibility here. You should be constantly coming up with new ideas and not just delivering what is asked for. Challenging the assumptions and the presumed solutions is part of delivering a successful, more valuable solution.

Innovation is most apparent during the Prototype the Requirements activity. Here is where you are exploring the problem space by sketching different solutions. If you are in the early days of the project, novelty is highly valued. By having new proposals, you are in a better position to guide the team away from the presumed solution toward something more beneficial. Innovation does not stop with prototyping—it should be a part of all of your requirements discovery activities. Your trawling, your design, and indeed your development all benefit from innovation. You will find that there is almost a direct correlation between the amount of innovation and the value of the delivered solution.

There is almost a direct correlation between the amount of innovation and the value of the delivered solution.

Dyson bagless vacuum cleaners, the World Wide Web, the iPhone, graphical user interfaces, radar, the jet engine, What3Words, software itself, and on and on—all of these were, at the time of their invention, startlingly different from what came before. All of them are valuable, some incredibly so. All of them were, at the time, innovations. If you look at the world’s most valuable companies, all of them became valuable by being innovative. All of them have a culture for innovation.

As a side note, you might have recognized the above list is made up of things that people were not, at the time, asking for. Yet, once people saw them, they realized how valuable they were. This applies to you. Your innovation sessions should produce solutions, features, and approaches that people have not asked for. When you present them to the stakeholders, they could, and should, realize that they need them.

You can learn to be innovative. You might not turn into the next Steve Jobs or Thomas Edison or Ada Lovelace, you might not invent the transistor or the telescope, but you can learn to make fresh contributions to your project. You can integrate innovation into your requirements discovery process to make yourself and your team more creative, and to look at problems in a more productive way.

The Value of Innovative Requirements

Innovation drives progress. It is progress that allows us to advance and evolve. If we had no innovation, no progress, you would ride a horse to work. Simply put, we need to innovate. We need to find better solutions to our business problems. We need to find ways to become more efficient. We need to introduce fresh thinking to make our solutions valuable to our customers.

Often, the business problem you are working on has an existing solution, and your customer wants to renew and refresh it. There are many reasons for wanting to do this: changes in the marketplace, changes in technology, and so on. Most of the time, on renewal projects, the stakeholders ask for what they have with some incremental improvements. Most of the time, when this kind of solution is delivered, it is met by disappointment. Disappointment in that it doesn’t really provide enough benefit or do enough new things to be considered valuable.

Your role, when you are discovering requirements, is to listen to the stakeholders, but also to think about innovations that could prove valuable to them. Business analysts are not there to obediently record what the stakeholders say they want. You need to innovate to get a better result. So, your requirements should not be exactly what was asked for, but improvements on what was asked for.

Earlier, in Chapter 13, Creative Candidate Solutions, we discussed a number of techniques for having creative ideas. In that chapter, we were talking about building prototypes. However, the techniques from Chapter 13 can be used throughout your requirements discovery process. When a stakeholder asks for something, the innovative response is to accept what is asked for and innovate ways to improve it.

As mentioned above, some of our best innovations are things that nobody asked for. Unless your stakeholders are visionary people, they are probably not going to ask for solutions that are a quantum leap over what currently exists. Which means it is up to you, the business analyst and your team, to be the ones to innovate. These innovations become part of your specification or story map, and then part of the delivered solution.

An Innovation Process and Requirements

It is difficult to say that something as creative as innovation can be described by a process. However, if we look at IDEO, a very successful US industrial design company, we can see something of a process. It looks like this.

Observation: Here people from both IDEO and the client observe the problem they are trying to solve. They also try to experience the problem from the consumer’s point of view.

Brainstorming: IDEO mixes various stakeholders, clients, and analysts to study the problem and come up with a number of possible solutions.

Rapid prototyping: The engineers make quick-and-dirty models to help with visualizing and understanding the problem and the solution.

Refining: Here they narrow down the choices to a few possibilities.

Figure 45.1

The Volere requirements discovery process. Innovation plays a part in all its activities.

Let’s look at how the IDEO process fits with the Volere requirements discovery process. We have been looking at this throughout this book, and it is shown again in Figure 45.1.

The process begins with the Project Blastoff. This is where you work with the various stakeholders to define the problem and its scope. You also decide the goals of the project that is setting out to solve this problem. It is during the blastoff that you are observing and understanding the problem.

In Part III of this book, we spoke about Prototyping for Requirements, and how you create prototypes of candidate solutions. We suggested that you can think of brainstorming and rapid prototyping as the same activity.

Then comes IDEO’s refining and converging. Prototyping is the activity where you are trying to generate as many ideas as possible. In other words, you are having diverging ideas. Then comes the probing activity, which we spoke about in Chapter 14, Probing and Exploring the Candidates. Here you are converging and narrowing down the candidates while learning more about the problem.

The final design of the solution comes when you move into the design arena. This is described in Part VI of this book. Here you take what you have learned from Trawling and Prototyping and craft the solution to be implemented. At this stage there is still room for innovation. You can innovate better ways to arrange components of the solution, better ways to carry out the requirements, better appearance and better workability.

The moral of the story is that you can be, and should be, innovative throughout the requirements discovery process.

A Culture for Innovation

A culture for innovation and a culture for effective requirements discovery are the same. Culture, as we use the term here, is a set of attitudes and behaviors that are shared by your team of business analysts, developers, stakeholders, and other people concerned with the requirements and delivery of the correct and best business solution.

Culture is a “soft” subject—it is impossible to measure, but it can be observed. Let’s look at the observable features of a culture for innovation.

Safety

First up is the organization’s attitude toward safety. Innovation relies on taking risks by having new ideas. It relies on trying things to see if they work. It relies on challenging the status quo and proposing new and different solutions. It relies on fresh thinking.

None of these are possible unless people feel safe. If they think that they will be ridiculed, criticized, or disregarded for the rest of the project, they will naturally be reluctant to propose any potentially risky ideas.

Yet, it is from these risky ideas that we have great solutions. An obvious example is the touchscreen phone that you, and most of the planet, carry around. Imagine the time when the incomplete idea for the iPhone was first aired. What would have happened if Apple’s management had dismissed it?

● “It will kill off the iPod market” (it did, but Apple grew much richer).

● “This thing is more of a computer than a phone” (it is, but that allows apps).

● “Nobody will want a phone without a keypad” (all phones prior to the iPhone had an array of physical buttons to dial with).

Fortunately, the Apple engineers operated in a safe environment. They were allowed, even encouraged, to voice their incomplete ideas.

Consider Thomas Edison, one of the most innovative people ever, and his tongue-in-cheek remark that he had not failed, just found 10,000 things that didn’t work. Edison understood that his engineers needed to take risks and that many of their innovations would turn out to be unusable. But the engineers worked in safety, knowing that they would not be criticized or demeaned if their ideas were incomplete or a prototype did not work.

Edison understood that risk was a necessary part of innovation. His greatest innovation was not the light bulb nor the gramophone, but the electricity distribution grid. He understood that if people were to buy his light bulbs, they first needed to have electricity in their houses.

“Hold on, Thomas, you can’t go running wires all over the city. It’s never been done before. It’ll be expensive. The wires might frighten the horses.”

It is hard to imagine not having electricity flowing reliably into your home, but you have it because Edison was willing to take the risk.

Safety also means that it is safe to challenge conventional thinking. The role of the business analyst is changing. Challenging existing solutions and existing processes has become very much a part of the new business analyst’s responsibilities. It is by being willing to break the old way of thinking that the business analyst can find new things. Naturally, your organizational culture must make it safe to criticize cherished beliefs or processes.

Blame

Safety also means freedom from blame. Consider this: When something goes wrong at your organization, is the first reaction to find what went wrong and why it went wrong? Or is it to find out who went wrong? In other words, is it organizational culture to find someone to blame? It often does not matter whether the culprit is guilty or not—someone must be blamed. In this kind of organization, nobody wants to be impeached, so nobody takes any risks. Nobody challenges the existing processes or solutions. Nobody proposes new ideas. Nobody tries to do anything except conform as closely as possible to the current state of affairs and conventional solutions.

Democracies and Skunkworks

Innovation works best in democracies. All the great innovations have come from democracies rather than from authoritarian regimes. The freedom to experiment is far more effective than an authoritative regime dictating what must be done.

In the same way, bureaucracies are authoritarian. If there is a central planning committee, then it limits innovations to what the committee can agree on. It is likely that very little will be. To overcome their own bureaucracy, some organizations create “skunkworks” projects. The name goes back quite far, but the essence of the technique is to form a small group who are outside the normal reporting hierarchy. The group answers to a single person high in the management structure and nobody else. This manager’s task is to be an umbrella and shield the skunkworks project from any outside interference.

An excellent example of skunkworks came when IBM decided to build a personal computer. At the time, IBM manufactured mainframe and minicomputers, and had a stranglehold on the world’s computing market. But IBM saw that change was in the air. Young people in their parents’ garages were building personal computers that were becoming more capable by the day, but none of them were thought suitable for corporate use. IBM knew that having the IBM badge on a machine would add gravitas, and probable adoption by regular businesses.

IBM also knew that its bureaucracy would strangle the development of something so outside its normal product line. The chairman estimated that going through the normal channels would take four years and 300 people before they had anything like a viable product. If IBM was to get a foothold into the PC market, it needed to get its product there quickly.

This prompted the IBM skunkworks project (it was actually called “Project Chess”). A small number of engineers who used non-IBM technology and non-IBM software were tasked to create their machine in under a year. They even went outside IBM for the operating system (OS). They found it in a Seattle startup called Microsoft run by a 24-year-old Bill Gates. Gates was happy to supply them with his QDOS (the QD is for quick and dirty) operating system.

So, IBM went to market with an IBM badge on the outside of their machine and Microsoft software on the inside. The result was a raging success when very quickly corporate America realized the value of putting a personal computer on employees’ desks.

If you work on a Windows desktop machine, it’s a direct descendant of a skunkworks team working outside the bureaucracy and being free to make its own decisions.

The Sanctity of the Incomplete Idea

Very few ideas are born fully formed—most of them are embryonic. And just like a human embryo, they must go through a gestation period and be nourished and cared for and developed before they are ready to be born into the world.

Some organizational cultures immediately trash any idea that is not obviously fully formed and viable. However, most ideas are incomplete when they are first aired. Choking off incomplete ideas restricts the flow of innovations and discourages people from having ideas. By nurturing and developing incomplete ideas, you get the advantage of group improvement and the likelihood of new ideas emerging.

An example of an incomplete idea being nurtured until it was ready for prime time is the Dyson vacuum cleaner. These bagless cleaners have become the biggest-selling vacuum cleaners in the world, but it took over 5,000 prototypes before it was ready for the market.

At some stage of your life, you will have used WD-40. This is an all-purpose lubricant used to stop hinges squeaking, to loosen rusted-in bolts and jammed door locks, separate stuck LEGO parts, get crayon marks of walls, get chewing gum out of your kid’s hair, and clean the stainless-steel splash panel behind your cooktop. Despite its ubiquity, it is unlikely that many people wonder about its name. WD is for water dispersant, and 40 is the number of attempts the engineers made before they hit on the right formula and had a product suitable to release.

The airplane you fly in today is a descendent, in one way or another, of the Wright Flyer. Orville and Wilbur Wright were not engineers; they ran a bicycle business in Ohio. They were curious about flight, and their curiosity gave them the idea to build a heavier-than-air flying machine. Nobody else had done it at the time. It took a few years, and Orville and Wilbur went through many prototypes. Along the way, they had setbacks, but whenever something did not work they went back, studied the problem, and found a suitable solution. They persisted with their incomplete idea until eventually the Wright Flyer flew for 852 feet in December 1903, at Kitty Hawk, North Carolina.

Was the flying machine an incomplete idea? Sure. At the time, nobody knew whether it was possible or not. Was it a safe environment for Wilbur and Orville to innovate in? Sure. Apparently, they used to argue a lot, but always about the machine they were building; it was never personal. It must have been safe to argue like this; the brothers stayed together until they succeeded and remained close for the rest of their lives.

Enlightened organizations know that their continued existence relies on innovation. As all innovation starts with an idea, these organizations are careful to offer a safe haven for their incomplete ideas. One day they might turn into successful products.

Innovation and Requirements

As much as you would like to, it is probable that you are not going to invent something—such as the Wright Flyer or the iPhone—that will change the world. But that doesn’t mean you invent nothing. Your solutions should be made up of lots of little—sometimes no so little—innovations that you and your team created along the way.

You are not a slave to your stakeholders. Because a requirement is asked for does not mean that it is the final word. It sometimes can be improved upon, or sometimes a better, more innovative alternative can be created. You should operate in the “blue zone.”

We wrote about the blue zone in a previous book, Adrenaline Junkies and Template Zombies. It works like this: Your leader gives you an assignment. This might be the whole project, or it might be to investigate and write the requirements for one business event. The assignment is your “green zone”; it has a purpose and boundaries. The assignment might also have a “red zone”—things that your leader has made specifically off-limits and you should not concern yourself with them.

You start to work on your green zone, and fairly soon you find yourself taking an interest in things outside it. You are venturing into a new area. This is not the red zone; this is a new area. This is the blue zone. The elements in the blue zone are those that would be beneficial to investigate with the potential of including them in your solution.

The criterion for venturing into the blue zone is the potential for benefit to the project and the delivered solution. You don’t ask for permission to go into the blue zone; you just know that it will be valuable.

One reason you might operate in the blue zone is the difference between incremental and innovative. As discussed earlier in this chapter, people, particularly users, tend to ask for incremental improvements: “I need the three screens I have with the current version, but I need a little more data on two of them.” An innovative solution might replace two of the screens with some automation, or it could do almost anything else.

To put this into practice, you must be willing to challenge almost everything you are told. Not by loudly and aggressively attacking each proposal, but by quietly questioning the value of them.

● Can you use any of the innovation techniques or creative triggers from Chapter 13, Creative Candidate Solutions, to generate something that either improves the requirement or is a beneficial alternative?

● Ask what happens if you don’t include this requirement.

● Are you or your stakeholder making assumptions about the requirement?

● Can you approach it “laterally” and see if there is a more creative requirement to be had?

● Is it a requirement or a solution, and what problem is it solving? Is there a more beneficial problem to solve?

Of course, you would not do this to every atomic requirement. Perhaps operating at the business event or functional story level would be more productive. But you are still questioning much of what you are told. You are not exactly being an anarchist, just slightly subversive.

Your task, and here we are paraphrasing Denys Lasdun, an architect, is not to give your customers what they ask for, but to give them something that when they see it, they realize it is what they wanted all along. This is giving customers what they need.

Requirements discovery can be a creative activity. It is a necessary activity and can be made more fulfilling when you mix in a few innovations. Your solutions will be better for it.

And that brings us to the end of the book. If you have read it all the way through, then you have the authors’ admiration and gratitude. Along the way we hope that you have found something—preferably several somethings—that will make you better at requirements discovery and make your requirements and stories more precise and more valuable.

We set out to write this edition to bring you a reliable companion for your requirements work. We also intended to make a noticeable difference to the way that you see requirements and go about discovering them and writing them.

We hope that you have enjoyed our book and found enough wise words to make your investment in it worthwhile and beneficial.

Our best wishes, James and Suzanne

Resources

Creative Confidence: Unleashing the Creative Potential Within Us All by David Kelley and Tom Kelley (Crown Currency, 2013). This is from the founders of IDEO, one of the most innovative design companies. It demonstrates how all of us can be creative.

Inspired: How to Create Tech Products Customers Love by Marty Cagan (Wiley, 2017). This is aimed at IT professionals involved in product development. It has insights into how to innovate effectively.

The Innovator’s Dilemma by Clayton Christensen (Harper Business Books, 2011). This classic book explores disruptive innovation and why it is important to innovate instead of complacently listening to what customers say what they think they want. There is also a companion piece, The Innovator’s Solution, written with Michael Raynor (Harvard Business Review Press, 2013), that provides actionable strategies for creating and sustaining innovation in IT projects.

Adrenaline Junkies and Template Zombies by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson, and Suzanne Robertson (Dorset House, 2009). This is a book to help you understand how people behave on projects.

The MIT Technology Review website (https://www.technologyreview.com), while not exclusively on IT, has articles and reports on the latest trends and innovations in technology.

The GitHub and Stack Overflow platforms are essential for IT professionals to collaborate, learn, and stay informed about the latest software development practices and technologies.

A

The Volere Requirements Specification Template

The Volere Requirements Specification Template is intended for use as a guide for discovering and communicating your requirements. The template provides sections for each requirement type appropriate to today’s software systems. You may download the template from the Volere website and adapt it to your requirements process and requirements tool. The template is process independent and can be used by agile, traditional, and outsourced projects. The template can be used with any combination of automated tools you are using.

The template may not be sold or used for commercial gain or purposes other than as a basis for a requirements specification, without prior written permission and a redistribution license. The template may be modified or copied and used for your own requirements work, provided you include the following copyright notice in any document that uses any part of this template:

We acknowledge that this document uses material from the Volere Requirements Specification Template, copyright © 1995–2024 Suzanne Robertson and James Robertson.

Contents

Volere

Requirement Types

Testing Requirements

The Snow Card

1. The Purpose of the Project

1a. The User Business or Background of the Project Effort

1b. Goals of the Project

2. The Stakeholders

2a. The Client

2b. The Customer

2c. Other Stakeholders

2d. The Hands-On Users of the Product

2e. Personas

2f. Priorities Assigned to Users

2g. User Participation

2h. Maintenance Users and Service Technicians

3. Constraints

3a. Solution Constraints

3b. Implementation Environment of the Current System

3c. Partner or Collaborative Applications

3d. Ready-Made or Off-the-Shelf Software

3e. Anticipated Workplace Environment

3f. Schedule Constraints

3g. Budget Constraints

3h. Enterprise Constraints

4. Naming Conventions and Terminology

4a. Glossary of All Terms, Including Acronyms, Used by Stakeholders Involved in the Project

5. Relevant Facts, Business Rules, and Assumptions

5a. Relevant Facts

5b. Business Rules

5c. Assumptions

6. The Scope of the Work

6a. The Current Situation

6b. The Scope of the Work

6c. Work Partitioning

6d. Specifying a Business Use Case

7. Business Data Model and Data Dictionary

7a. Business Data Model

7b. Data Dictionary

8. The Scope of the Product

8a. Product Boundary

8b. Product Use Case Table

8c. Individual Product Use Cases

9. Functional Requirements

9a. Functional Requirements

Non-functional Requirements

10. Look and Feel Requirements

10a. Appearance Requirements

10b. Style Requirements

11. Usability and Humanity Requirements

11a. Ease of Use Requirements

11b. Personalization and Internationalization Requirements

11c. Learning Requirements

11d. Understandability and Politeness Requirements

11e. Accessibility Requirements

11f. Convenience Requirements

12. Performance Requirements

12a. Speed and Latency Requirements

12b. Safety-Critical Requirements

12c. Precision or Accuracy Requirements

12d. Reliability and Availability Requirements

12e. Robustness or Fault-Tolerance Requirements

12f. Capacity Requirements

12g. Scalability or Extensibility Requirements

12h. Longevity Requirements

13. Operational and Environmental Requirements

13a. Expected Physical Environment

13b. Wider Environment Requirements

13c. Requirements for Interfacing with Adjacent Systems

13d. Productization Requirements

13e. Release Requirements

13f. Backward Compatibility Requirements

14. Maintainability and Support Requirements

14a. Maintenance Requirements

14b. Supportability Requirements

14c. Adaptability Requirements

15. Security Requirements

15a. Access Requirements

15b. Integrity Requirements

15c. Privacy Requirements

15d. Audit Requirements

15e. Immunity Requirements

16. Cultural Requirements

16a. Cultural Market Requirements

16b. Cultural Diversity and Inclusion Requirements

17. Compliance Requirements

17a. Legal Compliance Requirements

17b. Standards Compliance Requirements

Project Issues

18. Open Issues

19. Ready-Made Solutions

19a. Ready-Made Products

19b. Reusable Components

19c. Products That Can Be Copied

20. New Problems

20a. Effects on the Current Environment

20b. Effects on the Installed Systems

20c. Potential User Problems

20d. Limitations in the Anticipated Implementation Environment That Might Inhibit the New Product

20e. Follow-Up Problems

21. Tasks

21a. Project Planning

21b. Planning of the Development Phases

22. Migration to the New Product

22a. Requirements for Migration to the New Product

22b. Data That Has to Be Modified or Translated for the New Product

23. Risks

24. Costs

25. User Documentation and Training

25a. User Documentation Requirements

25b. Training Requirements

26. Waiting Room

27. Ideas for Solutions

The Volere Requirements Knowledge Model (Appendix C) shows the formal structure of the template and the cross-references between the components in the above table of contents.

Volere

Volere is the result of many years of practice, consulting, and research in requirements engineering and business analysis. We have packaged our experience in the form of a generic requirements process, requirements training, requirements consultancy, requirements audits, a variety of downloadable guides and articles, a requirements knowledge model, and this requirements template.

The first edition of the Volere Requirements Specification Template was released in 1995. Since then, thousands of organizations all over the world have saved time and money by using the template as the basis for discovering, organizing, and communicating their requirements.

The Volere website, https://www.volere.org, contains articles about the Volere techniques, experiences of Volere users and case studies, requirements tools, and other information useful to requirements practitioners. Updates to this template and instructions for downloading are also available there.

Requirement Types

For ease of use, we have found it convenient to think of requirements as belonging to a type. Having types is an aid to discovering the requirements and allows for groups that are relevant to a specific expert specialty.

Functional requirements describe what the product has to do, the rules that it has to carry out, what it has to remember, and what processing actions it must take.

Non-functional requirements are the properties that the functions must have, such as performance and usability. Do not be deterred by the unfortunate name for this kind of requirement; they are as important as the functional requirements for the product’s success.

Constraints impose restrictions on the chosen solution. These restrictions might apply to the whole project; for example, budget, time, and skills. Other constraints relate to the technology to be used to implement a solution or business practices that must be conformed with.

Project drivers are the business-related forces. For example, the purpose of the project is a project driver, as are all the stakeholders—each for different reasons.

Project issues define the conditions under which the project will be done. Our reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements knowledge as input to help manage a project.

Testing Requirements

The Volere philosophy is to start testing requirements as soon as you start writing them. You make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. All requirements can be measured, and all should carry a fit criterion.

The Snow Card

The snow card is a guide to writing an atomic requirement. An atomic requirement is not further decomposed. The components of the snow card are identified below.

The snow card can be on paper, which is convenient to use when you are a face-to-face team, or automated, for when you are a remote team. The snow card is shown in Figure A.1.

Figure A.1

The Volere snow card: a guide to the well-written requirement

The following discusses and provides examples for each section of the Volere Requirements Specification Template. Sections may have headings of Content, Motivation, Examples, Considerations, and Form. These help explain the content.

1. The Purpose of the Project

The first section of the template deals with the fundamental reason your client asked you to build a new product. That is, it describes the business problem the client faces and explains how the product is intended to solve the problem.

1a. The User Business or Background of the Project Effort

Content

A short description of the business being done, its context, and the situation that triggered the development effort. It should also describe the work that the user intends to do with the delivered product.

Motivation

Without this statement, the project lacks justification and direction.

Considerations

You should consider whether the business problem is significant enough to warrant the expense of solving it.

Perhaps there is not a problem, just a significant business opportunity your client wishes to exploit. In this case, describe the opportunity.

Alternatively, the project may seek to explore or investigate possibilities. In this case the project deliverable, instead of a new product, would be a document proving that the requirements for a product can (or cannot) be satisfied.

Form

A short text description is often sufficient to provide an understanding of the project. You can choose to support the description with models and photographs.

1b. Goals of the Project

Content

This part of the specification describes what we want the product to do and what advantage it will bring to the overall goals of the work. Do not be too wordy in this section—a brief explanation of the project’s goals is usually more valuable than a long, rambling treatise. A short, sharp goal will be clearer to the stakeholders and improve the chances of reaching a consensus for the goal.

Motivation

There is a danger that the goal gets lost along the way. As the development effort heats up, and as the customer and developers discover more about what is possible, the solution can wander away from the original goals as it undergoes construction. The goals should be very public, and the team should periodically be reminded of them.

Examples

We want to eliminate delays between the customer ordering online and the shipping of the goods.

To reduce road accidents by accurately forecasting and scheduling the deicing of roads.

Measurement

Any reasonable goal must be measurable. This is necessary if you are ever to test whether you have succeeded with the project. The measurement must quantify the advantage gained by the business through doing the project. For example, if the goal of the project is:

We want to eliminate delays between the customer ordering online and the shipping of the goods.

you must ask what advantage meeting that goal brings to the organization. If immediate shipping results in more satisfied customers, then the measurement must quantify that satisfaction. For example, you could measure the increase in repeat business (on the basis that a happy customer comes back for more), the increase in customer approval ratings from surveys, the increase in revenue from returning customers, and so on.

Ask whether your goal is one of the following.

● Service goal: This is measured by quantifying what it does for the customer.

● Revenue goal: Quantify revenue or revenue growth over what period. Alternatively, a revenue goal could be quantified by market share.

● Legal goal: This is not a quantification, but a way of knowing that the product conforms to a piece of legislation.

It is crucial to the rest of the development effort that the goal is firmly established, is reasonable, and is measured. It is usually the latter that makes the former possible.

Form

You can use Purpose, Advantage, Measurement (PAM) to structure your goal

● Purpose: One sentence to explain the organization’s reason for investing in the project.

● Advantage: One sentence describing the benefit that the organization will realize if the project is successful

● Measurement: One sentence or a graph or diagram that quantifies how you will measure whether the benefit has been achieved

Another form for your goals might be to use some kind of goal model. For example, the Extended Enterprise Modeling Language (EEML) includes a goal modeling technique. If your organization is using enterprise modeling, then this provides a connection between the enterprise’s strategic goals and the goal of an individual project.

You can also use a value proposition statement as a way to capture the overall goal of investing in a project. For example, a value proposition statement for the road deicing project could be:

As a Road Authority

I receive value when accidents attributed to ice are no more than specified by the European Road Safety Standard EU-1047-AHG-4.

2. The Stakeholders

This section describes the stakeholders—the people who have an interest in the product. It is worth your while to spend enough time to find all the stakeholders. Missing stakeholders usually means missing requirements.

2a. The Client

Content

This item gives the name of the client (sometimes referred to as the sponsor). It is permissible to have several names, but having more than three negates the point.

Motivation

The client has the final say on acceptance of the product and thus must be satisfied with the product as delivered. After all, the client is the person who makes the investment in the product. If you cannot find a name for your client, then perhaps you should not be building the product.

Considerations

Sometimes, when building a product for external users, the client is the marketing department.

Form

An annotated organization chart showing where the client fits within the organization. A list of the decisions for which the client will be responsible. You can also include a chart showing the review checkpoints and itemizing what you will provide for the client as progress indicators for the project.

2b. The Customer

Content

The person intended to buy the product. In the case of in-house development, the client and the customer are probably the same person. The customer might also be the manager who decides whether the people for whom he is responsible will adopt a new/changed product.

In the case of development of a mass-market product, this section contains a description of the persona developed as the archetypical customer for the product (see section 2e).

Motivation

The customer is ultimately responsible for deciding whether to buy or recommend the use of the product. The correct requirements can be discovered only if you understand the customer and her aspirations when it comes to using your product.

Form

A list of the decisions for which the customer will be responsible. You can also include a chart showing the review checkpoints and itemizing what you will provide for the customer as progress indicators for the project. This might include a list of possible prototypes or simulations that you will provide for the customer during the progress of the project.

2c. Other Stakeholders

Content

The roles and (if possible) names of other people and organizations that are affected by the product, or whose input is needed to discover the requirements and build the product. These stakeholders might work for your organization or might be external.

Following are examples of stakeholders:

● Client/sponsor (refer to section 2a)

● Customer (refer to section 2b)

● Subject-matter experts

● Users of a current system

● Marketing experts

● Legal experts

● Security experts

● Domain experts

● Usability experts

● Representatives of external associations

● Business analysts

● Designers and developers

● Testers

● Technology experts

● System designers

For each type of stakeholder, it might be useful to provide the following information:

● Stakeholder identification (some combination of role/job title, person name, and organization name)

● Knowledge that the project needs from that stakeholder

● The degree of involvement necessary for that stakeholder/knowledge combination

● The degree of influence for that stakeholder/knowledge combination

● Agreement on how to address conflicts between stakeholders who have an interest in the same knowledge

Motivation

Failure to recognize stakeholders results in missing requirements.

Form

A stakeholder map supported by the name of the representative of each role together with the knowledge to be supplied by that role. Figure A.2 shows a generic stakeholder map that you can use as a checklist. You would replace the role names with the specific people/roles/organizations for your project.

Figure A.2

The stakeholder map or “onion diagram” used to identify stakeholders.

Another form you can use to identify the stakeholders is a Stakeholder Analysis Spreadsheet. A sample is downloadable at https://www.volere.org/templates/stakeholder-analysis-download.

An annotated organization chart is also a useful form for defining stakeholders.

2d. The Hands-On Users of the Product

Content

A list of a special type of stakeholder—the potential users of the product. For each category of user, provide the following information.

● User name/category: Most likely the name of a user group, such as clerical users, schoolchildren, road engineers, or project managers.

● User role: Summarizes the users’ responsibilities.

● Subject-matter experience: Summarizes the users’ knowledge of the subject matter/business. Rate as novice, intermediate, or expert.

● Technological experience: Describes the users’ experience with relevant technology. Rate as novice, intermediate, or expert.

● Other user characteristics: Describe any characteristics of the users that have an effect on the requirements and eventual design of the product. For example:

● Physical abilities/disabilities

● Intellectual abilities/disabilities

● Attitude toward job

● Attitude toward technology

● Physical location

● Education

● Linguistic skills

● Age group

● Gender

● Ethnic group/s

Motivation

Users are human beings who interface with the product in some way. Use the characteristics of the users to define the usability requirements for the product. Without a thorough knowledge of the users, you end up building a product that is not connected to the real world. Users are also sometimes known as actors.

Examples

Users can come from a wide variety of (sometimes unexpected) sources. Consider the possibility of your users being clerical staff, shop workers, managers, highly trained operators, the general public, casual users, passers-by, illiterate people, tradespeople, students, test engineers, foreigners, children, lawyers, remote users, emergency workers, and so on.

Form

A simple user characteristics list or spreadsheet containing for each user: User Role + User Name/Representative + all the relevant characteristics (see under Content above) for that user.

2e. Personas

Content

A persona is a virtual person produced using data and team knowledge of the target audience. This section contains a description of the persona, which might include the persona’s name, age, job, family, hobbies, where they live, favorite food, favorite music, likes, dislikes, where they go on holiday, attitude toward technology, attitude toward money, or any other characteristic that could influence the way the persona thinks of the product. It helps if you include a photograph or drawing of the imagined person.

Motivation

By having a persona, you can make the requirements specific to the archetypical person your solution is aimed at. This is a particularly effective technique if you are specifying the requirements for a consumer product or a product to be used by members of the public.

Form

A profile of the persona. Include a photograph of the persona. You can download a suitable one from the internet.

2f. Priorities Assigned to Users

Content

Attach a priority to each category of user. This identifies the importance and precedence of the user and helps you plan how to use your time. Prioritize the users as follows.

● Key users: They are critical to the continued success of the product. Give greater importance to requirements generated by this category of user.

● Secondary users: They will use the product, but their opinion of it has no effect on its long-term success. Where there is a conflict between secondary users’ requirements and those of key users, the key users take precedence.

● Unimportant users: This category of user is given the lowest priority. It includes infrequent, unauthorized, and unskilled users, as well as people who misuse the product.

The percentage of the type of user is intended to assess the amount of consideration given to each category of user.

Motivation

If some users are more important to the product or to the organization, then this preference should be stated because it affects the way that you design the product. For example, key customers represent a significant part of the organization’s revenue and should be given preferential treatment.

Some users may be listed as having no impact on the product. These users will make use of the product but have no vested interest in it. Any special requirements from these users will have a lower priority.

Form

Include the user importance rating on your user characteristics spreadsheet; see section 2d for the information of the core project team. Depending on the culture of your organization, you might need to treat this as sensitive information.

2g. User Participation

Content

Where appropriate, attach to the category of user a statement of the participation that you think is necessary for those users to provide the requirements. Describe the contribution that you expect these users to make; for example, business knowledge, interface prototyping, or usability requirements. If possible, assess the minimum amount of time that these users must spend for you to be able to determine the complete requirements.

Motivation

Many projects fail through lack of user participation. When people must make a choice between getting their everyday work done and working on a new project, the everyday work usually takes priority. This user participation requirement makes it clear from the outset that specified user resources must be allocated to the project.

Form

Include the estimated user participation time, together with the type of knowledge you expect that user to provide, on your user characteristics spreadsheet; see section 2d.

2h. Maintenance Users and Service Technicians

Content

Maintenance users are a special type of hands-on user who has requirements that are specific to maintaining and changing the product.

Motivation

Many of these requirements will be discovered by considering the various types of maintainability and support requirements detailed in section 14. However, if you define the characteristics of the people who maintain the product, it will help to trigger requirements that might otherwise be missed.

Form

Include the maintenance users on your user characteristics spreadsheet; see section 2d.

3. Constraints

This section describes constraints on the eventual design of the product. Constraints are restrictions that must be satisfied.

Constraints are global—they are factors that apply to the entire product. Often you know about the constraints, or they are mandated before the project gets under way. They are probably determined by management and are worth considering carefully—they restrict what you can do and so shape the product. Constraints, like other types of requirements, have a description, rationale, and fit criterion, and generally are written in the same format as functional and non-functional requirements.

3a. Solution Constraints

Content

This specifies constraints on the way that the problem must be solved. Describe the mandated technology or solution. You should also explain the reason for using the technology.

Motivation

To identify constraints that guide the final product. Your client, customer, or user may have design preferences, or only certain solutions may be acceptable. If these constraints are not met, your solution is not acceptable.

Examples

Constraints are written using the same form as other atomic requirements (refer to the atomic requirements snow card for the attributes). It is important for each constraint to have a rationale and a fit criterion, as they help to expose false constraints (solutions masquerading as constraints).

Description: The product shall use calls to mobile phones to communicate with the drivers in their trucks.

Rationale: The client will not pay for a new radio system, nor are any other means of communication available to the drivers.

Fit criterion: All signals generated by the product shall be understandable by all drivers.

Description: The product shall operate under Windows 10.

Rationale: The client uses Windows 10 and does not wish to change to a later version.

Fit criterion: The product shall be approved as Windows 10 compliant by the Microsoft testing group.

Considerations

We want to define the boundaries within which we can solve the problem. The solution constraints should only be those that are non-negotiable, and not the whim of a manager.

Form

Include the constraint requirements as a specific type of atomic requirement in your requirements spreadsheet or database.

Another form for constraints can be diagram(s) of the systems architecture for the new/changed product—see sections 3b and 3c.

3b. Implementation Environment of the Current System

Content

This describes the technological and physical environment in which the product is to be installed. It includes automated, mechanical, organizational, and other devices, along with the nonhuman adjacent systems.

Motivation

To describe the technological environment into which the product must fit. The environment places design constraints on the product. This part of the specification provides enough information about the environment for the designers to make the product successfully interact with its surrounding technology.

The operational requirements are derived from this description.

Examples

Examples can be shown as a diagram, with an icon to represent each device or person. Add interfaces between the processors and annotate them with their form and content.

Considerations

All component parts of the current system, regardless of their type, should be included in the description of the implementation environment.

If the product is to affect or be important to the current organization, then include an organization chart.

Form

A diagram that represents each hardware and software component/subcomponent/device/building block that will be used to implement the product. The diagrams that you use depend on your organization and your projects’ ways of working; the important point is that the implementation environment is unambiguously understandable by the people who have to make decisions about how the functional and non-functional requirements will be implemented.

3c. Partner or Collaborative Applications

Content

This describes applications that are not part of the product but with which the product will collaborate. They can be external applications, ready-made solutions, or preexisting in-house applications.

Motivation

To provide information about design constraints caused by using partner applications. By describing or modeling these partner applications, you discover and highlight potential problems of integration.

Examples

This section can be completed by including written descriptions, models, or references to other specifications. The descriptions must include a full specification of all interfaces that have an effect on the product.

Considerations

Examine the work context model to determine whether any of the adjacent systems should be treated as partner applications. It might also be necessary to examine some of the details inside the scope of the work (see section 6) to discover relevant partner applications.

Form

A diagram or table that identifies all the interfaces between the product to be built and other adjacent systems. Bear in mind that the adjacent systems might be software, human, or hardware. Some adjacent systems are within your organization and hence potentially more easily understood and perhaps influenced. Other adjacent systems are outside your organization and might be difficult if not impossible to influence. A product scope diagram (see section 8a for an example) is often used to define interfaces with partner or collaborative applications.

3d. Ready-Made or Off-the-Shelf Software

Content

This describes ready-made components or solutions that must be used to implement some of the requirements for the product. This could be commercial, open-source, or any other off-the-shelf (OTS) or legacy software. It could also apply to non-software OTS components such as hardware or any other commercial product that is intended as part of the solution.

Motivation

To identify and describe any ready-made components to be incorporated into the eventual product. The characteristics, behavior, and interfaces of the ready-made are design constraints.

Considerations

When gathering requirements, you may discover requirements that conflict with the behavior and characteristics of the ready-made solution. In light of your discoveries, you must consider whether the ready-made product is a viable choice. If the use of the ready-made software is not negotiable, then the conflicting requirements must be discarded.

Note that your strategy for discovering requirements is affected by the decision to use ready-made software. In this situation, you investigate the work context in parallel with making comparisons with the capabilities of the ready-made product. Depending on the comprehensibility of the OTS software, you might be able to discover the matches or mismatches without having to write each business requirement in atomic detail. The mismatches are the requirements that you will need to specify so that you can decide whether to satisfy them by either customizing the ready-made solution or satisfying the requirement in another way, such as modifying the business environment.

Form

Models or written documentation that specifies the functional and non-functional requirements that can be implemented using this ready-made software product.

3e. Anticipated Workplace Environment

Content

This describes the workplace in which the users work and use the product. It should describe any features of the workplace that could influence the design of the product, and the social and cultural aspects of the workplace.

Motivation

To identify characteristics of the workplace so that the product is designed to compensate for any difficulties.

Examples

The single office printer is a considerable distance from the user’s desk. This constraint suggests that printed output should be deemphasized.

The workplace is noisy, so audible signals might not work.

The workplace is outside, so the product must be weather resistant, have displays that are visible in sunlight, and allow for the effect of wind on any paper output.

The product is to be used in a library; it must be extra quiet.

The user will be standing up or working in positions where he must hold the product. This suggests a hand-held product, but only a careful study of the user’s work and workplace will provide the necessary input to identifying the operational requirements.

Considerations

The physical work environment constrains the way that work is done. The product should overcome whatever difficulties exist; however, you might consider a redesign of the workplace as an alternative to having the product compensate for it.

Form

A written description of the workplace; rich pictures showing all the components in the workplace; photographs of the workplace; videos of the workplace.

3f. Schedule Constraints

Content

Any known deadlines or windows of opportunity should be stated here.

Motivation

To identify critical times and dates that influence product requirements. If the deadline is short, then the requirements must be kept to whatever can be built within the time allowed.

Examples

To meet scheduled software releases.

There may be other parts of the business or other software products that are dependent on this product.

Windows of marketing opportunity.

Scheduled changes to the business that will use your product. For example, the organization may be starting up a new factory and your product is needed before production can commence.

Considerations

State deadline limitations by giving the date and describing why it is critical. Also, identify prior dates on which parts of your product need to be available for testing.

You should also ask questions about the impact of not meeting the deadline.

● What happens if we don’t build the product by the end of the calendar year?

● What is the financial impact of not having the product by the beginning of the Christmas buying season?

● What parts of the product are most critical for the Christmas buying season?

Form

A written statement giving the date of the deadline, the reason for the deadline, and the effect of not meeting the deadline.

3g. Budget Constraints

Content

This section shows the budget for the project, expressed in money or available resources.

Motivation

The requirements must not exceed the budget. This limitation may constrain the number of requirements that can be met by the product. The intention of this question is to determine whether the product is really wanted.

Considerations

The intention is to restrict the wildest ambitions and to prevent the team from gathering requirements for an Airbus 380 when the budget can only buy a Cessna. Is it realistic to build a product within this budget? If the answer to this question is no, then either the client is not really committed to building the product or the client does not place enough value on the product. In either case, you should consider whether it is worthwhile to continue.

Form

A written statement giving the amount of the budget and the source of the funding.

3h. Enterprise Constraints

Content

This section contains requirements that are specific to the enterprise that is making the investment in your project.

Motivation

To understand requirements that sometimes appear irrelevant or irrational because they are not obviously relevant to the goals of the project.

Examples

The product shall be installed using only American-made components.

The product shall make all functionality available to the CEO.

Considerations

Is there a company-wide edict that only specified browsers or only specified mobile operating systems are to be used?

Is a director also on the board of a company that manufactures products similar to the one that you intend to build?

Whether you agree with these enterprise requirements has little bearing on the outcome. The reality is that the system must comply with enterprise requirements even if you can find a better, more efficient, or more economical solution. A few probing questions here may save some heartache later.

The enterprise requirements might be purely concerned with the politics inside your organization. However, in other situations you may need to consider the politics inside your customers’ organizations or the national politics of the country. Another way to think about the enterprise requirements is that they are constraint requirements that have been defined by strategic decisions that are outside the obvious boundary of your project scope.

4. Naming Conventions and Terminology

It has been our experience that all projects have their own unique vocabulary that usually contains a variety of acronyms and abbreviations. Failure to understand this project-specific nomenclature inevitably leads to misunderstandings, hours of lost time, miscommunication between team members, and ultimately poor-quality specifications.

4a. Glossary of All Terms, Including Acronyms, Used by Stakeholders Involved in the Project

Content

A glossary containing the meanings of all names, acronyms, and abbreviations used by the stakeholders. Select names carefully to avoid giving a different, unintended meaning.

If the work that you are studying already has a glossary of terms, then use this as your starting point. This glossary should be enlarged and refined as the analysis proceeds, but for the moment, it should introduce the terms that the stakeholders use and the meanings of those terms. This glossary reflects the terminology in current use within the work area. You might also get started by building on the standard names used within your industry.

For each term, write a description. The appropriate stakeholders must agree on this description of the meaning of the term.

We suggest you add all acronyms and abbreviations. We often encounter situations where team members use acronyms but admit they do not know the meanings of those acronyms. This section gives you a place to register your acronyms.

Motivation

Names are very important. They invoke meanings that, if carefully defined, can save hours of explanations. Attention to names early in the project helps to highlight misunderstandings.

As the detailed work progresses, the glossary provides input to the more precisely specified business/work data model and data dictionary—see section 7 of the template. As the analysis data dictionary evolves, many of the definitions from the glossary are expanded in the dictionary by adding their data composition.

Examples

Truck: A vehicle used for spreading deicing material on roads. “Truck” is not used to refer to goods-carrying vehicles.

BIS: Business Intelligence Service. The department run by Steven Peters to supply business intelligence for the rest of the organization.

Thermal Map: A region or other geographical area is surveyed to determine the temperature differences at various parts of the area. The resultant thermal map means the temperature at any part of the area can be calculated by knowing the temperature at a reference point.

Considerations

Make use of existing references and existing data dictionaries. Obviously, it is best to avoid renaming existing items unless they are so ambiguous that they cause confusion.

From the beginning of the project, emphasize the need to avoid homonyms and synonyms. Explain how they increase the cost of the project.

Form

An existing glossary of terms, or a pointer to industry dictionaries, or a list of terms commonly used in the problem domain, along with a sentence describing the meaning and purpose of each term.

5. Relevant Facts, Business Rules, and Assumptions

Relevant facts are external factors that influence the product but are not covered by other sections in the requirements template. They are not necessarily translated into requirements, but might be. Relevant facts alert the developers to conditions and factors that have a bearing on the requirements.

5a. Relevant Facts

Content

Factors that have an effect on the product but are not mandated requirements or constraints.

Motivation

Relevant facts provide background information to the specification readers and might contribute to requirements. They will influence the eventual design of the product.

Examples

One ton of deicing material will treat three miles of single-lane roadway.

The existing application is 10,000 lines of C# code.

5b. Business Rules

Content

Business rules are the “laws” of the organization. These are the rules that might have an impact on the work/business/domain that is the source of the requirements. Relevant business rules are the trigger for requirements.

Motivation

Business rules are mentioned at all stages of the requirements discovery process. It is often difficult to immediately ascertain whether a business rule is or is not relevant to the project that you are doing. This section provides a place to capture the business rules and, as understanding of the work increases, to revisit them and use them as triggers to discover relevant requirements.

Examples

The maximum length of a truck driver’s shift is five hours.

The engineers visit the weather stations for maintenance once a week.

Form

A written statement describing the business rule, the reason for the rule, and the authority for the rule. Alternatively, you can refer to the repository of the organization’s business rules.

At the start of a new project, determine if there are any relevant business rules that have already been recorded. When your project discovers a new or changed business rule, it should be recorded. The business rules are updated by every project.

There are some specialized software tools, or business rules engines, that can help with building a central repository of the organization’s business rules.

5c. Assumptions

Content

A list of the assumptions that the developers are making. These assumptions might be about the intended operational environment but can be about anything that influences the product. As part of managing expectations, assumptions also contain statements about what the product will not do.

Motivation

To make people declare the assumptions that they are making. Also, to make everyone on the project aware of assumptions that have already been made.

Examples

Assumptions about new laws or political decisions.

Assumptions about what your developers expect to be ready in time for them to use—for example, other parts of your products, the completion of other projects, software tools, or software components.

Assumptions about the technological environment in which the product will operate. These assumptions should highlight areas of expected compatibility.

The availability and capability of ready-made components.

Dependencies on computer systems or people external to this project.

Considerations

We often make unconscious assumptions. It is necessary to talk to the members of the project team to discover any unconscious assumptions that they have made. Ask stakeholders (both technical and business related) questions such as these.

● What software tools are you expecting to be available?

● Will there be any new software products?

● Are you expecting to use a current product in a new way?

● Are there any business or environmental changes you are assuming we will be able to deal with?

Assumptions are intended to be transient. That is, they should all be cleared by the time the specification is released—the assumption should have become either a requirement or a constraint (or be proved irrelevant). For example, if the assumption is related to the capability of a product that is intended to be a partner product to yours, then the capability should have been proven satisfactory and it becomes a constraint to use it. Conversely, if a ready-made product is not suitable, then it becomes a requirement for the project team to construct the needed capability.

Form

A written statement describing the assumption along with the effect on the project if the assumption is false. Depending on the complexity of the assumption, it might be necessary to include references to other documents or people.

Understanding of assumptions can be explored and shared by using cause-and-effect diagrams such as Peter Senge’s dynamics models.

6. The Scope of the Work

The scope of the work, or the problem space, determines the boundaries of the business area to be studied and outlines how it fits into its environment.

6a. The Current Situation

Content

This is an analysis of the existing business processes, including the manual and automated processes that might be replaced or changed by the new product. In terms of the Volere Brown Cow model, you refer to this view as the “How-Now” view. Business analysts might already have done this investigation as part of the business case analysis for the project. This is where it might be appropriate to build some business process models. These are models of the processes that the business uses to carry out the work of the organization. The models include roles, individuals, departments, technology, and procedures. They illustrate the workflow and the dependencies between the components of the process.

Motivation

If your project intends to make changes to an existing system, you must understand the effect of proposed changes. The study of the current situation provides the basis for understanding the effects of proposed changes and choosing the best alternatives. Business process modeling does not always lead to building software. Instead, some changes in procedures and the way roles are allocated might prove to be the best way to make a necessary improvement.

Form

There are many different notations suitable for building business process models; for example, activity diagrams, business process diagrams, swim lane diagrams, and data flow diagrams.

6b. The Scope of the Work

Content

The work context diagram identifies the extent of the problem space, or work, that you need to investigate. Note that the work usually includes more than the intended product. This is because you must understand the work that the product will support if you are to build a product that will fit cleanly into its environment.

The adjacent systems on the example context diagram (see Figure A.3) indicate other entities that interact with your work. The interfaces between the adjacent systems and the work context indicate the data that travels between them.

Figure A.3

A work context diagram

Motivation

To clearly define the boundary for your study and hence the requirements effort. Without this definition, you have little chance of building a product that will fit seamlessly into its environment.

Examples

The work context model shown in Figure A.3 defines the connections between the part of the world that is under investigation and other people, organizations, hardware, and software (referred to as adjacent systems). The inputs and outputs represent the data and material that travel between the work and other parts of the world. The work context is the basis for partitioning the investigation and discovering the requirements.

Considerations

The names used on the context diagram should eventually be defined in the data dictionary (see section 7). Without these definitions, the context model lacks the required rigor, and it may be misunderstood.

Form

A diagram showing the inputs and outputs that flow between the work and the adjacent systems or a table that identifies all the inputs and outputs that flow between the work and the adjacent systems. These should be defined in the data dictionary—see section 7b.

6c. Work Partitioning

Content

We use business events to partition the problem space. The content of this section is a list showing all business events to which the work responds. Business events are happenings in the real world that affect the work. They also happen because it is time for the work to do something: for example, produce weekly reports, remind nonpaying customers, check the status of a device, and so on. The response to each event is called a business use case (BUC); it represents a discrete piece of the work. All of the work is made up of the responses to business events.

The event list includes the following elements:

● Event name

● Input or triggering data flow from adjacent system (identical to name on context diagram)

● Output(s) to adjacent systems (identical to name(s) on context diagram)

● Brief summary of the BUC. This is optional, but we have found it is a very useful first step in defining the requirements for the BUC. You can think of it as a mini scenario.

● Classes of business data relevant to this event (you won’t know this early in the study of the event, but as you go into detail, you will start to understand the essential data and you can add it to the event list).

Motivation

To identify logical chunks of the work that can be used as the basis for discovering detailed requirements. These business events also provide the subsystems that can be used as the basis for managing detailed analysis and design. Each business event has a BUC whose details can be studied independently. However, all BUCs connect to each other through shared interest in the stored business data (see section 7a).

Examples

Business Event List

Event Name

Input and Output

Summary of BUC

1. Weather Station transmits reading

Weather Station Readings (in)

Record the readings as belonging to the weather station.

2. Weather Service forecasts weather

District Weather Forecast (in)

Record the forecast.

3. Road engineers advise changed roads

Changed Road (in)

Record the new or changed road. Check that all appropriate weather stations are attached.

4. Road Engineering installs new Weather Station

New Weather Station (in)

Record the weather station and attach it to the appropriate roads.

5. Road Engineering changes Weather Station

Changed Weather Station (in)

Record the changes to the weather station.

6. Time to test Weather Stations

Failed Weather Station Alert (out)

Determine if any weather stations have not transmitted for two hours and inform Road Engineering of any failures.

7. Truck Depot changes a truck

Truck Change (in)

Record the changes to the truck.

8. Time to detect icy roads

Road Deicing Schedule (out)

Predict the ice situation for the next two hours. Assign a truck to any roads that will freeze. Issue the schedule.

9. Truck treats a road

Treated Road (in)

Record the road as being in a safe condition for the next three hours.

10 Truck Depot reports problem with truck

Truck Breakdown (in) Amended Gritting Schedule (out)

Reassign available trucks to the previously assigned roads.

11. Time to monitor road treatment

Untreated Road Reminder (out)

Check that all scheduled roads have been treated in the assigned time, and issue reminders for any untreated roads.

Considerations

Attempting to list the business events and write a one-sentence summary of each BUC is a way to test the scope of the work. This activity uncovers uncertainties and misunderstandings about the project and facilitates precise communications.

We suggest you gather requirements for discrete sections of the work. This means you need a way to partition the work. We have found business events to be the most convenient, consistent, functionally cohesive, and natural way to break the work into manageable units and to be able to trace the details back to the scope of the work.

Form

Business event list/table containing, for each event: Event Number, Event Name, Name of Input, Name of Output(s), and Summary of the business event response. For reasons of traceability, the names of the inputs and outputs on the business event list must match the names on the work context model/table (see section 6.b).

6d. Specifying a Business Use Case

Content

A specification of the details of how a BUC responds to a business event. You can assess how well you understand the BUC by attempting to write its business fit criterion. To do this, ask yourself: How will I know whether this BUC has carried out the intention of the business response to the business event?

Motivation

To understand the detailed business response that must be carried out when a business event takes place and provide a basis for discovering the detailed requirements. The understanding of the BUC also provides the basis for discussing which parts of the BUC should be carried out by the product that will be built. If you are using stories, then the equivalent of a BUC is a business story.

Examples

In the sample specifications included with the download of this template, you will find examples of BUC scenarios.

Business Event: Borrower wants to extend loan

Business Use Case: Decide on loan extension

Trigger: Loan Extension Request

Preconditions: The borrower must have an existing loan for the book in question.

Interested Stakeholders: Chief Librarian, Other Libraries, Auditors

Active Stakeholders: Duty Librarian, Borrower

The borrower gives the loan extension request to the duty librarian.

The librarian finds the book loan agreement for the requested extension.

The librarian finds any other books that are currently loaned to the borrower.

If the due return date on each of the books is later than today’s date

then

the librarian tells the borrower there is a loan extension approval.

the librarian records the loan extension.

otherwise

the librarian tells the borrower there is a refused loan extension.

the librarian records the refused extension.

the librarian asks the borrower to return the overdue books.

Outcome: A decision on book loan extension and the borrower is informed

Considerations

Whatever approach you use to specify the details of a BUC, you should stay within the boundary of the input and output(s) for that business event. If you discover additional input or output data, then it is an indication that you need to make changes to the input/output data on the event list and on the work context diagram.

Form

A BUC can be specified using any combination of models that suits the analyst. The most common approaches are activity diagrams, BUC scenarios, process flow diagrams, sequence diagrams, business stories, mind maps, interview notes …. The only caveat is that the inputs and outputs on your BUC are precisely the same and hence traceable to the inputs and outputs on the corresponding business event.

7. Business Data Model and Data Dictionary

The business data represents the business knowledge that is stored, referenced, and maintained to satisfy the business requirements. The business data provides a way to communicate the essential subject matter independently of the technology used to store the data.

7a. Business Data Model

Content

A diagram of the essential subject matter, business objects, entities, and classes that are germane to the work that you are investigating. It might take the form of a first-cut class model, an entity-relationship model, or any other kind of data model. Figure A.4 is an example of a business data model.

Figure A.4

A business data model

Motivation

To clarify the system’s subject matter, thereby triggering recognition of requirements not yet considered. To discover missing requirements, you can cross-check the data model and the events using a Create, Read, Update, Delete (CRUD) table.

The data model is a specification for all the business data that is relevant to the scope of the work.

Examples

This example is a model of the business system’s data using the Unified Modeling Language (UML) class model notation. This is all the data that is Created, Read, Updated, and Deleted by processes within the scope of the work being studied. See section 6 for more about the scope of the work.

Each rectangle in Figure A.4 represents a class of business data or a “thing” that the work you are studying is interested in. The attributes of that class are defined in the data dictionary (see section 7b). For example:

Figure A.5

A PUC diagram

District = *A geographical area defined by the council*

District Name + District Size + District Coordinates

Similarly, each attribute is also defined in the dictionary. For example:

District Name = *The unique name used by the engineers to identify a district*

You can use any type of data or class model to capture this knowledge. The issue is to capture the meaning of the business subject matter and the connections between the individual parts, and to show that you are consistent within your project. If you have an established company standard notation, use that, as it will help you to reuse knowledge between projects.

For more examples of data models, look at the example specifications that are packaged with the download of this requirements template.

Considerations

Are there any data or object models for similar or overlapping systems that might be a useful starting point? Is there a domain model for the subject matter dealt with by this system?

Form

There are many different types of data models that you can use to model the business data. The ones you are most likely to come across are

● UML class model

● Entity relationship diagrams

● A table showing the class name, relationships between classes, and attributes for each class

The thing to keep in mind is that the data model that you build is a business data model, not a design for a database. Your model is concerned with identifying business classes by making a logical partitioning of all the classes of data within the work context and the necessary business relationships between those business classes. The model is an abstract model because it is not concerned with how the data is implemented; hence it exposes the essential business data within the scope of the work. The business data model is used as input to decide how the data will be implemented. The definitions of the attributes in each business class are in the data dictionary (see section 7b).

7b. Data Dictionary

The glossary described in section 4 of the template is the starting point for establishing a common understanding of terminology. As you start to define the scope of the investigation, you define the data inputs and outputs in a formal data dictionary. The terms that you define in this dictionary, right down to the elemental level, are the same terms that you use when defining detailed atomic requirements.

Content

The data dictionary specifies the content of the following:

● Classes/entities on the business data model

● Attributes of the classes

● Relationships between the classes

● Inputs and outputs on all models

● Elements of data within the inputs and outputs

When implementation decisions are made, the technical specifications for the interfaces should be added to the dictionary.

Motivation

The work context diagram (see section 6b) provides a precise definition of the scope of the work being studied. The product scope diagram (see section 8a) defines the boundary of the product to be built. These definitions can only be completely unambiguous if the information flows bordering the scopes have their attributes defined.

Examples

The following is a partial data dictionary for the road deicing project that we have been using as an example in this template. Note that this version of the dictionary is sorted alphabetically within Type.

When implementation decisions are eventually made, the format of the data is added to the dictionary by the designers/implementors.

Name

Content

Type

Depot

Depot Identifier

Class

District

District Name + District Size

Class

Forecast

Forecast Temperature + Forecast Time

Class

Road

Road Name + Road Number

Class

Road Section

Road Section Identifier + Road Section Coordinates

Class

Temperature Reading

Reading Time + Temperature Measurement

Class

Truck

Truck Identifier

Class

Road DeIcing Schedule

{Road Section Identifier + Treatment Scheduled Date + Treatment Scheduled Start Time + Critical Start Time + Truck Identifier}

Data flow

District Name

*Listed in District Catalog*

Attribute/Element

District Size

*Measured in Kilometers*

Attribute/Element

Forecast Temperature

*Measured in Celsius*

Attribute/Element

Forecast Time

*HH/MM/SS 24-hour clock*

Attribute/Element

Reading Time

*HH/MM/SS24-hour clock*

Attribute/Element

Road Name

*See Road Database*

Attribute/Element

Road Number

*See Road Database*

Attribute/Element

Road Section Coordinates

*See Road Database*

Attribute/Element

Road Section Identifier

*See Road Database*

Attribute/Element

Temperature Measurement

*Measured in Celsius*

Attribute/Element

Treatment Scheduled Date

*YY/MM/DD*

Attribute/Element

Treatment Scheduled Start Time

*HH/MM/SS24-hour clock*

Attribute/Element

Truck Identifier

*Number between 1 and 1,000. Refer to Chief Engineer for list*

Attribute/Element

Critical Start Time

*Treatment started after this time is not guaranteed to be effective*

Attribute/Element

Treatment Scheduled Date

*YY/MM/DD*

Attribute/Element

Treatment Scheduled Start Time

*HH/MM/SS24-hour clock*

Attribute/Element

Considerations

The dictionary provides a link between the business analysts and the developers and testers. The developers add implementation details to the terms in the dictionary, defining how the data will be implemented.

Form

The data dictionary is maintained in a variety of forms, depending on the tools that you have at your disposal. The important issue is that you make it as easy as possible to cross-reference the use of terms in requirements, documents, and models with their definitions in the dictionary. Common forms for maintaining the data dictionary are spreadsheets, databases, and automated requirements tools.

8. The Scope of the Product

8a. Product Boundary

You arrive at the product boundary by inspecting each BUC and determining, in conjunction with the appropriate stakeholders, which part of the BUC should be automated and what part should be done by a human user. To do this task you must consider the abilities of the users (see section 2), the constraints (see section 3), the goals of the project (see section 1), and your knowledge of both the work and the technology that can make the best contribution to the work.

The example use case diagram shows the users (also called actors) outside the product boundary (the rectangle). The product use cases (PUCs) are the ellipses inside the boundary. The numbers link each PUC back to the BUC that it came from (see section 6). The arrows denote usage. In this version of a PUC diagram, we put names on the arrows to make it more precise and traceable. Note that actors can be either automated or human.

You derive the PUCs by deciding where the product boundary should be for each BUC. These decisions are based on your and appropriate stakeholders’ knowledge of the work and the requirements constraints. Note that the PUCs that you come up with must be traceable back to the BUCs.

Examples

The numbers on the PUC diagram in Figure A.5 correspond to the BUC numbers on the business event list (see section 6).

You can see that the PUC diagram is an effective summary for a small number (up to around twenty) PUCs. If you have a larger number of PUCs, then a product scope diagram together with a PUC summary table (see section 8b) is a better approach.

Figure A.6 shows an example of a product scope diagram for the road deicing project. The content of each interface on the product scope diagram is defined in the data dictionary and can also be supported by a prototype or simulation of some kind. Some projects publish a separate document called the Interface Specification Document. The content of that document would be the definitions of the interfaces on the product scope diagram often supported by prototypes and models.

Figure A.6

A product scope diagram

The product scope diagram shown in Figure A.6 summarises the interfaces between the product and the actors/users.

Form

A PUC diagram. A PUC diagram supported by individual functional stories. A product scope diagram supported by individual use case specifications. Specifications and prototypes of the interfaces on the scope diagram.

8b. Product Use Case Table

In practice, we have found that a PUC table summarized by a product scope diagram is an effective way to manage large numbers of PUCs. It identifies the input and output data that defines the boundary of each PUC (see Table A.1).

Table A.1

PUC Summary Table

PUC NO.

PUC NAME

ACTORS/USERS

INPUT & OUTPUT

1

Record Weather Station Readings

Weather Station

Weather Station Readings (in)

2

Record Weather Forecast

Highways Department Clerk

District Weather Forecast (in)

3

Record Roads

Road Engineering Computer

Changed Road (in)

4

Record New Weather Station

Road Engineering Computer

New Weather Station (in)

5

Record Changed Weather Station

Road Engineering Computer

Changed Weather Station (in)

6

Identify Faulty Weather Stations

Truck Depot Engineer

Failed Weather Station Alert (out)

7

Record Truck Changes

Truck Depot Engineer

Truck Change (in)

8

Produce Deicing Schedule

Truck Depot EngineerThermal Mapping Database

Deicing Schedule (out) Thermal Maps (in)

9

Record Treated Roads

Truck Depot Engineer

Treated Road (in)

10

Amend Deicing Schedule

Truck Depot Engineer

Deicing Schedule Change (in) Amended Deicing Schedule (out)

11

Monitor Untreated Roads

Truck Depot Engineer

Roads in Danger (out)

8c. Individual Product Use Cases

This is where you define the details about the individual PUCs listed in your PUC table. You can include a scenario or model for each PUC in your list. Also record your design rationale for choosing this particular PUC. This will save you and others a great deal of time if you need to make changes later or explain the design to someone else.

Form

● A text scenario

● A storyboard

● A low-fi prototype

● A hi-fi prototype

● A formal use case specification including exceptions and alternatives

● A sequence diagram, activity diagram, data flow diagram, or any other type of model that is familiar to your project group

● One or more stories

If you are working with stories, then instead of a PUC scenario you, would write one or more functional stories.

You can assess how well you understand the PUC by attempting to write its fit criterion. To do this, ask yourself: What would I test to assess whether the product has carried out the intention of this PUC?

9. Functional Requirements

9a. Functional Requirements

Content

This part of the specification contains the atomic functional requirements. A full explanation of the atomic requirement and its attributes is included in this template’s introductory material.

Motivation

To specify the detailed functional requirements to be carried out by the product.

Examples

Figure A.7 shows a snow card that has been filled in with an atomic functional requirement.

Figure A.7

The Volere snow card showing a functional requirement

Fit Criterion

Each functional requirement should have a fit criterion, which is a measurement such that the tester can objectively determine whether the implemented product matches, or fits, the requirement.

Considerations

If you have produced an event list (see sections 6c and 8a/b), then you can use it to help you trigger the functional requirements for each PUC. Give each functional requirement a unique number to help with traceability.

Note that if you have not identified the product boundary and are not able to determine the PUCs, then write the functional and non-functional requirements for the BUCs. This is a useful strategy if you are writing business requirements and asking suppliers to tell you which of your business requirements can be satisfied by their ready-made products.

Form

The form that you use to capture and maintain your atomic requirements depends on the tools that you have available to you. Volere snow cards are often a useful aid to help you in discovering requirements, but due to volume and need to be able to make changes, some kind of automated form is the best way to manage and maintain your atomic requirements. Common forms for atomic requirements are

● A spreadsheet (a sample is included with the download of this template)

● A database provided with whatever requirements tool you have available

● A collaborative requirements tool

Whatever form you use to record and maintain your requirements, it is important to be consistent with your numbering and use of terminology so that you can check for completeness and respond to change.

Non-functional Requirements

The sections 10 through 17 describe the non-functional requirements. The form of these requirements is the same as for the functional requirements as described in section 9.

10. Look and Feel Requirements

10a. Appearance Requirements

Content

The section contains requirements relating to the spirit of the product. Your client may have made demands for the product, such as corporate branding, colors to be used, and so on. This section captures the requirements for the appearance that might be important for marketing it to the target audience. Do not attempt to design it until the appearance requirements are known.

Motivation

To ensure that the appearance of the product conforms to expectations about the branding or attractiveness in the market.

Examples

The product shall be attractive to a teenage audience.

The product shall comply with corporate branding standards.

Fit Criterion

A sampling of representative teenagers shall, without prompting or enticement, start using the product within four minutes of their first encounter with it.

The office of branding shall certify that the product complies with the current standards.

Considerations

Even if you are using prototypes, it is important to understand the requirements for the appearance. The prototype is used to help elicit requirements; it should not be thought of as a substitute for the requirements.

10b. Style Requirements

Content

Requirements that specify the mood, style, or feeling of the product, which influences the way a potential customer will see the product. Also, the stakeholders’ intentions for interaction the user is to have with the product.

In this section, you would also describe the appearance of the packaging if this were to be a manufactured product. The packaging may have some requirements as to its size, style, and consistency with other packaging put out by your organization. Keep in mind the European laws on packaging, which require (sensibly) that the package not be significantly larger than the product it encloses.

The style requirements that you record here will guide the designers to create a product as envisioned by your client.

Motivation

Given the state of today’s market and people’s expectations, we cannot afford to build products that have the wrong style. Once the functional requirements are satisfied, it is often the appearance and style of products that determine whether they are successful. Your task in this section is to determine how the product shall appear to its intended consumer.

Examples

Description: The product shall appear authoritative.

Fit Criterion: After their first encounter with the product, 70% of representative potential customers shall agree that they feel they can trust the product.

Considerations

The look and feel requirements specify your client’s vision of the product’s appearance. The requirements may at first seem to be rather vague (e.g., “conservative and professional appearance”), but each requirement will be quantified by its fit criterion.

11. Usability and Humanity Requirements

This section is concerned with requirements that make the product usable and ergonomically acceptable to its hands-on users. Other requirement types that might have an effect on usability are the cultural requirements in Section 16.

11a. Ease of Use Requirements

Content

This section describes your client’s aspirations for how easy it is for the intended users of the product to operate it. The product’s usability is derived from the abilities of the expected users of the product and the complexity of its functionality.

The usability requirements should cover properties such as these.

● Efficiency of use: How quickly or accurately the user can use the product.

● Ease of remembering: How much the casual user is expected to remember about using the product.

● Error rates: For some products, it is crucial that the user commits very few or no errors.

● Overall satisfaction in using the product: This is especially important for commercial, interactive products that face a lot of competition. Websites are a good example.

● Feedback: How much feedback the user needs to feel confident that the product is accurately doing what the user expects. The necessary degree of feedback will be higher for some products (e.g., safety-critical products) than for others.

Motivation

To guide the product’s designers toward building a product that meets the expectations of its eventual users.

Examples

The descriptions in these examples may seem simplistic, but they express the intention of the client. To completely specify what is meant by any requirement, you must add a measurement against which it can be tested—this is its fit criterion. These are some examples of the description of some requirements together with their fit criteria:

Description: The product shall be easy for 11-year-old children to use.

Fit Criterion: Eighty percent of a test panel of 11-year-old children shall be able to successfully complete [list of tasks] within [specified time].

Description: The product shall help the user avoid making mistakes.

Fit Criterion: One month’s use of the product shall result in a total error rate of less than 1%.

Description: The product shall make the users want to use it.

Fit Criterion: An anonymous survey shall show that 75% of the intended users are regularly using the product after a three-week familiarization period.

Considerations

Refer to section 3 to ensure that you have considered the usability requirements from the perspective of the different types of users.

You could also consider consulting a UX designer for your usability requirements.

11b. Personalization and Internationalization Requirements

Content

This section describes the way in which the product can be altered or configured to consider the user’s personal preferences or choice of language.

The personalization requirements should cover issues such as the following:

● Languages, spelling preferences, and language idioms

● Currencies, including the symbols and decimal conventions

● Personal configuration options

Motivation

To ensure that the product’s users do not have to struggle with or meekly accept the builder’s cultural conventions.

Examples

Description: The product shall retain the buyer’s buying preferences.

Description: The product shall allow the user to select her preferred language.

Considerations

Consider the country and culture of the potential customers and users of your product. Any out-of-country users will welcome the opportunity to convert to their home spelling and expressions.

By allowing users to customize the way in which they use the product, you give them the opportunity to participate more closely with your organization as well as enjoy their own personal user experience.

You might also consider the configurability of the product. Configurability allows different users to have different functional variations of the product.

11c. Learning Requirements

Content

Requirements specifying how easy it should be to learn to use the product. This learning curve ranges from zero time for products intended for placement in the public domain (e.g., a parking meter or a website) to a considerable amount of time for complex, highly technical products. (We know of one situation in which it was necessary for graduate engineers to spend 18 months in a training program before being qualified to use the product.)

Motivation

To quantify the amount of time that your client feels is allowable before a user can successfully use the product. This requirement guides designers to understand how users will learn the product. For example, designers may build elaborate interactive help facilities into the product, or the product may be packaged with a tutorial. Alternatively, the product may have to be constructed so that all its functionality is apparent upon first encountering it.

Examples

Description: The product shall be easy for an engineer to learn.

Fit Criterion: An engineer shall produce a [specified result] within [specified time] of beginning to use the product, without needing to use outside assistance.

Description: A clerk shall be able to be productive within a short time.

Fit Criterion: After receiving [number of hours] training, a clerk shall be able to produce [quantity of specified outputs] per [unit of time].

Description: The product shall be able to be used by members of the public who will receive no training before using it.

Fit Criterion: [Agreed percentage] of a test panel shall successfully complete [specified task] within [specified time limit].

Description: The product shall be used by engineers who will attend five weeks of training before using the product.

Fit Criterion: The engineers shall achieve [agreed percentage] pass rate from the final examination of the training.

Considerations

Refer to section 2d to ensure that you have considered the ease of learning requirements from the perspective of all the different types of users.

11d. Understandability and Politeness Requirements

This section is concerned with discovering requirements related to concepts, metaphors, and behaviors that are familiar to the intended end users.

Content

This specifies the requirement for the product to be understood by its users. While “usability” refers to ease of use, efficiency, and similar characteristics, “understandability” determines whether the users instinctively know what the product will do for them and how it fits into their view of the world. You can think of understandability as the product being polite to its users and not expecting them to know or learn things that have nothing to do with their business problem. Another aspect of politeness is that the product should not expect the user to input any information to which the product already has access.

Motivation

To avoid forcing users to learn terms and concepts that are part of the product’s internal construction and are not relevant to the users’ world. To make the product more comprehensible and thus more likely to be adopted by its intended users.

Examples

Description: The product shall use symbols and words that are naturally understandable by the user community.

Description: The product shall hide the details of its construction from the user.

Considerations

Refer to section 2d, and consider the world from the point of view of each type of user.

11e. Accessibility Requirements

Content

The requirements for how easy it should be for people with common disabilities to access the product. These disabilities might be related to physical disability or visual, hearing, cognitive, or other abilities.

Motivation

In many countries, there are laws that require products be made available to people with disabilities or handicaps. In any event, it is self-defeating to exclude this sizable community of potential customers.

Examples

Description: The product shall be usable by partially sighted users.

Description: The product shall be usable by wheelchair users.

Description: The product shall conform to the Americans with Disabilities Act.

Considerations

Some users have disabilities other than the commonly described ones. Some partial disabilities are common. A simple, and not very consequential, example is that approximately 20% of males are red-green colorblind.

11f. Convenience Requirements

Content

The requirements for things the product shall do to simplify tasks, and to expedite and make the customer’s work easier and smoother.

Motivation

People have become more and more accustomed to convenience. Unless your product is convenient to use, your customers will shun your product. Given the technology we have available, there are more and more opportunities for the products we build to do some of the work that the customer used to have to do himself. Products can also do new, convenient things for the customer—often things the customer would not have dreamed of asking for.

Examples

Description: The product shall inform the customer of his bank balance every Monday morning using a secure communication channel.

Description: The product shall identify the customer without the need for asking security questions (e.g., using biometric data).

Description: The product shall process payment for the taxi journey without the need for customer interaction.

Considerations

Look at your stakeholder map and stakeholder analysis (see sections 2d and 2e) and consider what would make the product more convenient for a person in that situation. What would it be like to be that person using the product? Often, people will not mention convenience requirements, because they do not know what is possible. But if the product is inconvenient, people will complain.

12. Performance Requirements

12a. Speed and Latency Requirements

Content

Specifies the amount of time to complete specified tasks. These requirements often refer to response times. They can also refer to the product’s ability to operate at a speed suitable for the intended environment.

Motivation

Some products—usually real-time products—must be able to perform some of their functionality within a precise time frame. Failure to do so may mean catastrophic failure (e.g., a ground-sensing radar in an airplane fails to detect an upcoming mountain), or that the product will not cope with the required volume of use (e.g., a website selling tickets to pop music concerts).

Examples

Description: Any interface between a user and the automated system shall have a maximum response time of 1.5 seconds.

Description: The response shall be fast enough to avoid interrupting the user’s flow of thought.

Description: The product shall poll the sensor twice every second.

Description: The product shall download the new status parameters within five minutes of a change.

Fit Criterion

Fit criteria are necessary when the description of the requirement is not quantified. However, we find that most performance requirements are stated in quantified terms. The exception is the second requirement shown above, for which the suggested fit criterion is:

Fit Criterion: The product shall respond in less than 1 second for 90% of the interrogations. No response shall take longer than 2.5 seconds.

Considerations

There is a wide variation in the importance of different types of speed requirements. If you are working on a missile guidance system, then speed is extremely important. By contrast, an inventory control report that is run once every six months has very little need for a lightning-fast response time.

Customize this section of the template to give examples of the speed requirements that are important within your environment.

12b. Safety-Critical Requirements

Content

Quantification of the perceived risk of damage to people, property, and environment. Different countries have different standards, so the fit criteria must specify precisely which standards the product must meet.

Motivation

To understand and highlight the damage that could potentially occur when using the product within the expected operational environment.

Examples

Description: The product shall not emit noxious gases.

Fit Criterion: The product shall be certified to comply with the Health Department’s standard E110-98. It is to be certified by qualified testing engineers.

Description: The heat exchanger shall be shielded from human contact.

Fit Criterion: No member of a test panel of [specified size] shall be able to touch the heat exchanger. The heat exchanger must also comply with safety standard [specify which one].

Considerations

The example requirements given here apply to some, but not all, products. It is not possible to give examples of every variation of safety-critical requirement. To make the template work in your environment, you should customize it by adding examples that are specific to your products.

Also, be aware that different countries have different safety standards and laws relating to safety. If you plan to sell your product internationally, you must be aware of these laws. A colleague has suggested that for electrical products, if you follow the German standards, the largest number of countries will be supported.

If you are building safety-critical systems, then the relevant safety-critical standards are already well-specified. You will likely have safety experts on your staff. These experts are the best source of the relevant safety-critical requirements for your type of product. They will almost certainly have copious information that you can use.

Consult your legal department. Members of this department will be aware of the kinds of lawsuits that have resulted from product safety failure. This is probably the best starting place for generating relevant safety requirements.

12c. Precision or Accuracy Requirements

Content

Quantification of the desired accuracy of the results produced by the product.

Motivation

To set the client’s and users’ expectations for the precision of the product.

Examples

Description: All monetary amounts shall be accurate to two decimal places.

Description: Accuracy of road temperature readings shall be within ±2°C.

Considerations

If you have done any detailed work on definitions, then some precision requirements might be adequately defined by definitions in the dictionary in section 7.

You might consider which units the product is intended to use. Readers will recall the spacecraft that crashed on Mars when coordinates were sent as metric data rather than imperial data.

The product might also need to keep accurate time, be synchronized with a time server, or work in UTC.

Also, be aware that some currencies have no decimal places, such as the Japanese yen.

12d. Reliability and Availability Requirements

Content

This section quantifies the necessary reliability of the product. The reliability is usually expressed as the allowable time between failures, or the total allowable failure rate.

This section also quantifies the expected availability of the product.

Motivation

It is critical for some products not to fail too often. This section allows you to explore the possibility of failure and to specify realistic levels of service. It also gives you the opportunity to set the client’s and users’ expectations about the amount of time that the product will be available for use.

Examples

Description: The product shall be available for use 24 hours per day, 365 days per year.

Description: The product shall be available for use between the hours of 8 A.M. and 5:30 P.M.

Description: The escalator shall run from 6 A.M. until 10 P.M. or until 30 minutes after the last flight arrives.

Description: The product shall achieve 99% uptime.

Considerations

Consider carefully whether the real requirement for your product is that it is available for use or that it does not fail at any time.

Also consider the cost of reliability and availability, and whether it is justified for your product.

12e. Robustness or Fault-Tolerance Requirements

Content

Robustness specifies the ability of the product to continue to function under abnormal circumstances.

Motivation

To ensure that the product can provide some or all its services after or during some abnormal happening in its environment.

Examples

Description: The product shall continue to operate in local mode whenever it loses its link to the central server.

Description: The product shall provide ten minutes of emergency operation should it become disconnected from the electricity source.

Considerations

Abnormal happenings can almost be considered normal. Today’s products are so large and complex that there is a good chance that at any given time, one component will not be functioning correctly. Robustness requirements are intended to prevent total failure of the product.

You could also consider disaster recovery in this section. This plan describes the ability of the product to reestablish acceptable performance after faults or abnormal happenings.

12f. Capacity Requirements

Content

This section specifies the volumes that the product must be able to deal with and the amount of data stored by the product.

Motivation

To ensure that the product can process the expected volumes.

Examples

Description: The product shall cater for 300 simultaneous users within the period from 9 a.m. to 11 a.m. Maximum loading at other periods will be 150 simultaneous users.

Description: During a launch period, the product shall cater for a maximum of 20 people to be in the inner chamber.

Fit Criterion

In this case, the requirement description is quantified, and thus can be tested.

12g. Scalability or Extensibility Requirements

Content

This specifies the expected increases in size that the product must be able to handle. As a business grows (or is expected to grow), our software products must increase their capacities to cope with the new volumes.

Motivation

To ensure that the designers allow capacity for future growth.

Examples

Description: The product shall be capable of processing the existing 100,000 customers. This number is expected to grow to 500,000 customers within three years.

Description: The product shall be able to process 50,000 transactions per hour within two years of its launch.

12h. Longevity Requirements

Content

This specifies the expected lifetime of the product.

Motivation

To ensure that the product is built based on an understanding of expected return on investment.

Examples

Description: The product shall be expected to operate within the defined maximum maintenance budget for a minimum of five years.

13. Operational and Environmental Requirements

13a. Expected Physical Environment

Content

This section specifies the physical environment in which the product will operate.

Motivation

To highlight conditions that might need special requirements, preparations, or training. These requirements ensure that the product is fit to be used in its intended environment.

Examples

Description: The product shall be used by a worker while standing up outside in cold, rainy conditions.

Description: The product shall be used in noisy, dusty conditions.

Description: The product shall be able to fit in a pocket or purse.

Description: The product shall be usable in dim light.

Description: The product shall not be louder than the existing noise level in the environment.

Considerations

The work environment: Is the product to operate in some unusual environment? Does this lead to special requirements? Also see section 11.

13b. Wider Environment Requirements

Content

Any requirements that relate to greenness, conservation, recycling, global warming, or saving the planet.

Motivation

To consider any aspects of the product that might influence the wider environment. The variety of technology is growing all the time, and every new technology has the potential of damaging the environment. For example, consider the technologies we use to create, consume, and store data. Can you think of any potential damage to the environment? Can you identify a requirement to guard against that potential damage?

Examples

Description: The product shall conform to the established emission standards.

Description: The product shall discourage unnecessary printing.

Description: The product shall advise the user of electricity usage.

Description: The product shall advise the traveler of the carbon footprint of his journey.

Description: The product shall clearly communicate recycling options.

Considerations

People are becoming more aware of how easy it is to damage our environment and are coming to prefer products that help to minimize that damage.

Look at your solution technology and identify anything that is not eco-friendly. Do not restrict yourself to information technology. Consider everything in your solution space, such as machines, furniture, packaging, paper, motorways, lightbulbs, chemicals, and viruses. This is difficult, as every new technology emphasizes advantages, but at the introduction of something new, we often don’t know the long-term effects.

13c. Requirements for Interfacing with Adjacent Systems

Content

This section describes the requirements to interface with partner applications or devices that the product has to collaborate with if it is to operate successfully.

Motivation

Requirements for the interfaces to other applications often remain undiscovered until implementation time. Avoid a high degree of rework by discovering these requirements early.

Examples

Description: The product shall work on the last four releases of the five most popular browsers.

Description: The new version of the spreadsheet must be able to access data from the previous two versions.

Description: Our product must interface with the applications that run on the remote weather stations.

Fit Criterion

For each inter-application interface, specify the following elements:

● The data content

● The physical material content

● The medium that carries the interface

● The frequency

● The volume

● The trigger

● The standards/protocols that apply to the interface

13d. Productization Requirements

Content

Any requirements that are necessary to make the product into a distributable or salable item. It is also appropriate to describe here the operations needed to install a software product successfully.

Motivation

To ensure that if work must be done to get the product out the door, then that work becomes part of the requirements. Also, to quantify the client’s and users’ expectations about the amount of time, money, and resources they will need to allocate to install the product.

Examples

Description: The product shall be distributed as a downloadable app.

Description: The product shall be able to be installed by an untrained user without recourse to separately printed instructions.

Considerations

Some products have special needs to turn them into a salable or usable product. You might consider that the product must be protected such that only paid-up customers can access it.

Ask questions of your marketing department to discover unstated assumptions that have been made about the specified environment and the customers’ expectations of how long installation will take and how much it will cost.

Most commercial products have needs in this area.

13e. Release Requirements

Content

Specification of the intended release cycle for the product and the form that the release shall take.

Motivation

To make everyone aware of how often you intend to produce new releases of the product.

Examples

Description: The maintenance releases will be offered to end users once a year.

Description: Each release shall not cause previous features to fail.

Fit Criterion

Description of the type of maintenance plus the amount of effort budgeted for it.

Considerations

Do you have any existing contractual commitments or maintenance agreements that might be affected by the new product?

13f. Backward Compatibility Requirements

Content

Specification of what the product must do to accommodate legacy versions of the product you are working on, or other legacy products.

Motivation

To ensure that there are no nasty surprises when the product is released. This type of requirement acknowledges that you are not always operating in a greenfield environment.

Example

Description: The product shall be able to process data from both the legacy customer database and the new CRM database.

Considerations

Check the work context model for any legacy adjacent systems or for indications that legacy systems are included in the work scope.

14. Maintainability and Support Requirements

14a. Maintenance Requirements

Content

A quantification of the time necessary to make specified changes to the product.

Motivation

To make everyone aware of the maintenance needs of the product.

Examples

Description: New business intelligence reports must be available within one working week of the date when the requirements are agreed upon.

Description: A new weather station must be able to be added to the system overnight.

Considerations

There may be special requirements for maintainability, such as that the product must be able to be maintained by its end users, or by developers who are not the original developers. These requirements influence the way that the product is developed. In addition, there may be requirements for documentation or training.

14b. Supportability Requirements

Content

This specifies the level of support that the product requires. Support is often provided via a help desk. If people will provide support for the product, then that service is considered part of the product: Are there any requirements for that support? You might also build support into the product itself, in which case this section is the place to write those requirements.

Motivation

To ensure that the support aspect of the product is adequately specified.

Considerations

Consider the anticipated level of support, and what forms it might take and who might need that support. For example, a constraint might state that there is to be no manual. Alternatively, the product might need to be entirely self-supporting.

14c. Adaptability Requirements

Content

Description of other platforms or environments to which the product must be ported.

Motivation

To publicize the client’s and users’ expectations about the platforms and environments on and in which the product will be able to run.

Examples

Description: The product is expected to run under the last two releases of major mobile operating systems.

Description: The product might eventually be sold in the Japanese market.

Description: The product is designed to run in offices, but we intend to have a version running in restaurant kitchens.

Fit Criterion

Specification of system software on which the product must operate. Specification of future environments in which the product is expected to operate. Time allowed to make the transition.

Considerations

Question your marketing department to discover unstated assumptions that have been made about the portability of the product.

15. Security Requirements

15a. Access Requirements

Content

Specification of who is authorized to access the product (both functionality and data), under what circumstances that access is granted, and to which parts of the product access is allowed.

Motivation

To understand the expectations for confidentiality aspects of the system.

Examples

Description: Only direct managers can see the personnel records of their staff.

Description: Only holders of a current security clearance can enter the building.

Fit Criterion

System function name or system data name. User roles and/or names of people who have clearance to access specified data. User roles and/or names of people who have clearance to add, change, or delete specified data.

Considerations

Is there any data that management considers to be sensitive? Is there any data that low-level users do not want management to have access to? Are there any processes that might cause damage or might be used for personal gain? Are there any people who should not have access to the system?

Consider asking for help. Computer security is a highly specialized field, and one where improperly qualified people have no business. If your product has a need for more than average security, we advise you to talk to your own security department or make use of a security consultant.

15b. Integrity Requirements

Content

Specification of the required integrity of databases and other files, and of the product itself.

Motivation

To understand the expectations for the integrity of the product’s data. To specify what the product will do to ensure its integrity in the case of an unwanted happening such as an attack from the outside or unintentional misuse by an authorized user.

Examples

Description: The product shall prevent incorrect data from being introduced.

Description: The product shall protect itself from intentional abuse.

Considerations

Organizations rely on their stored data. If this data should become corrupt or incorrect—or disappear—then it could be a fatal blow to the organization. For example, almost half of small businesses go bankrupt after a fire destroys their computer systems. Integrity requirements are aimed at preventing complete loss as well as corruption of data and processes.

15c. Privacy Requirements

Content

Specification of what the product must do to ensure the privacy of individuals about whom it stores information. The product must also ensure that all laws related to privacy of an individual’s data are observed.

Motivation

To ensure that the product complies with the law, and to protect the individual privacy of your customers. Compliance with the General Data Protection Regulation (GDPR) is mandatory for European countries and many US states. Few people today look kindly on organizations that do not observe their privacy.

Examples

Description: The product shall make its users aware of its information practices before collecting data from them.

Description: The product shall notify customers of changes to its information policy.

Description: The product shall reveal private information only in compliance with the organization’s information policy.

Description: The product shall protect private information in accordance with GDPR and the organization’s information policy.

Considerations

Privacy issues may well have legal implications, and you are advised to consult with your organization’s legal department about the requirements to be written in this section.

Consider what notices you must issue to your customers before collecting their personal information. Also, do you have to do anything to keep customers aware that you hold their personal information?

Customers must always be able to give or withhold consent when their private data is collected or stored. Similarly, customers should be able to view any private data and, where appropriate, correct or ask for correction of the data.

Also consider the integrity and security of private data—for example, when you are storing credit card information.

GDPR requirements are covered in section 17.

15d. Audit Requirements

Content

Specification of what the product must do (usually retain records) to permit the required audit checks.

Motivation

To build a system that complies with the appropriate audit rules.

Considerations

This section may have legal implications. You are advised to seek the approval of your organization’s auditors regarding what you write here.

You should also consider whether the product should retain information on who has used it. The intention is to provide security such that a user may not later deny having used the product or participated in some form of transaction using the product.

15e. Immunity Requirements

Content

The requirements for what the product must do to protect itself from infection by unauthorized or undesirable malware, such as viruses, worms, spyware, or any other undesirable interference.

Motivation

To build a product that is as secure as possible from malicious interference.

Considerations

Each day brings more malevolence from the unknown, outside world. People buying software, or any other kind of product, expect that it can protect itself from outside interference.

16. Cultural Requirements

16a. Cultural Market Requirements

Content

This section contains requirements that are specific to the sociological factors that affect the acceptability of the product. If you are developing a product for foreign markets, or for a specific demographic such as teenagers or seniors, then these requirements are particularly relevant.

Motivation

To bring out in the open requirements that are difficult to discover because they are outside the cultural experience of the developers.

Examples

Description: The product shall not be offensive to religious or ethnic groups.

Description: The product shall be able to distinguish between French, Italian, and British road-numbering systems.

Description: The product shall keep a record of public holidays for all states in the United States and countries in the European Union.

Considerations

Question whether the product is intended for a culture other than the one with which you are familiar. Ask whether people in other countries or in other types of organizations will use the product. Do these people have different habits, holidays, superstitions, or cultural norms that do not apply to your own culture? Are there colors, icons, measurement units, or words that have different meanings in another cultural environment? If your reaction to a requirement is “That’s rather odd,” then it’s likely you have discovered a cultural requirement.

16b. Cultural Diversity and Inclusion Requirements

Content

This section contains requirements that are specific to the factors that affect the acceptability of the product in different groups in society. In today’s world, there are many requirements for products that fit with personal choices, preferences, and feelings. Bear in mind that some of these cultural diversity and inclusion requirements might also be legal requirements.

Motivation

To recognize requirements that are outside the sociological experience of the developers and to make products that fit effectively into different people’s daily lives without causing offense.

Examples

Description: The product shall allow the user to choose the preferred courtesy title or honorific.

Description: The product shall recognize all genders as recognized by current LGBTQ+ conventions.

Description: The product shall recognize all marital statuses as defined by the current law of the land.

Description: The product shall not request or store courtesy title, gender, or marital status unless there is an agreed need for that information.

Considerations

Consider whether the product could cause offense by ignoring or contravening any personal sociological preferences or choices. There have been many additional cultural diversity requirements recognized in the last few years, so you might need the help of cultural experts to discover the requirements that are related to your work.

17. Compliance Requirements

17a. Legal Compliance Requirements

Content

A statement specifying the legal requirements for this system.

Motivation

To comply with the law to avoid later delays, lawsuits, and legal fees.

Example

Description: Personal information shall be implemented in compliance with GDPR.

Fit Criterion

Lawyers’ opinion that the product does not break any laws.

Considerations

Consider consulting lawyers to help identify the legal requirements.

Any solution holding personal data needs to comply with the GDPR. This was a European Union initiative, but it has since come to be adopted by almost all democratic countries. It is a significant piece of legislation, and penalties for noncompliance can be harsh.

Are there any copyrights or other intellectual property that must be protected? Conversely, do any competitors have copyrights that you might be in danger of infringing?

Is it a requirement that developers have not seen competitors’ code or even have worked for competitors?

The Sarbanes-Oxley Act (SOX), the Health Insurance Portability and Accountability Act (HIPAA), and the Gramm-Leach-Bliley Act may have implications for you. Check with your company lawyer. Following are some additional questions to ask.

● Might any pending legislation affect the development of this system?

● Are there any aspects of criminal law you should consider?

● Are there banking or insurance laws that apply to your product?

● Have you considered the tax laws that affect your product?

● Are there any labor laws relevant to your product?

17b. Standards Compliance Requirements

Content

A statement specifying applicable standards and referencing detailed standards descriptions. This does not refer to the law of the land—think of it as an internal law imposed by your company or by your industry.

Motivation

To comply with standards and avoid later delays.

Examples

Description: The product shall comply with milspec standards.

Description: The product shall comply with insurance industry standards.

Description: The product shall comply with ISO [whichever standards are applicable].

Fit Criterion

The appropriate standards keeper certifies that the standard has been adhered to.

Considerations

It is not always apparent that there are applicable standards, because their existence is often taken for granted. Consider the following:

● Do any industry bodies have applicable standards?

● Does the industry have a code of practice, watchdog, or ombudsman?

● Are there any special development steps for this type of product?

Project Issues

Sections 18 through 27 contain issues that must be faced if the requirements are to be met and the product is to become a reality. These sections also connect the requirements with the project activities that discover and progress the requirements. If you are using a consistent language for communicating requirements, then project managers can use the requirements as input to steering the project. The Volere Requirements Knowledge Model (Appendix C) provides the basis for a requirements common language by identifying classes of requirements knowledge and the relationships between them. Each class of knowledge is cross-referenced to sections in this requirements template.

18. Open Issues

This section looks at issues that have been raised and do not yet have a conclusion.

Content

A statement of factors that are uncertain and might make significant difference to the product.

Motivation

To bring uncertainty out into the open and provide objective input to risk analysis.

Examples

Our investigation into whether the new version of the processor will be suitable for our application is not yet complete.

The government is planning to change the law about who is responsible for salting the Interstates, but we do not know what those changes might be.

The feasibility study to determine whether to use the Regional Weather Center’s online database is not yet complete. This issue affects how we should handle the weather data.

Planned changes to working hours for drivers may affect the way that trucks are scheduled and the length of the routes that drivers are permitted to travel. The changes are still in the proposal stage; details will be available by the end of the year.

Considerations

When you are probing around your customer’s business, questions often come to the surface that cannot immediately be answered. Similarly, as you are gathering the requirements for a future product, it may well be that your stakeholders are unsure of how the work should be done in the future. Are there any issues that have come up from the requirements gathering that have not yet been resolved? Have you heard of any changes that might occur in the other organizations or systems on your context diagram? Are there any legislative changes that might affect your system? Are there any rumors about your hardware or software suppliers that might have an impact?

Form

A list of open issues containing the following:

● Issue number

● Cross-reference to affected requirements, business events, BUCs, PUCs, atomic requirements, dictionary definitions, and so on

● Summary of the issue

● Stakeholders involved

● Action to be taken (where applicable)

19. Ready-Made Solutions

This section looks at available solutions (off the shelf, open source, legacy, etc.) and summarizes their applicability to the requirements. This discussion is not intended to be a full feasibility study of the alternatives, but it should tell your client that you have considered some alternatives and determined how closely they match the requirements for the product.

19a. Ready-Made Products

Content

List of existing products that could be investigated as potential solutions. Reference any surveys that have been carried out for these products.

Motivation

To consider whether a solution can be acquired by means other than building it.

Considerations

Could you buy something that already exists or is about to become available? It may not be possible at this stage to make this determination with a lot of confidence, but any likely products should be listed here.

Also consider whether some ready-mades must not be used.

19b. Reusable Components

Content

Description of the candidate components, either bought from outside or built by your company, that could be used by this project. List libraries that could be a source of components.

Motivation

Reuse rather than reinvention.

19c. Products That Can Be Copied

Content

List of other similar products or parts of products that you can legally copy or easily modify.

Motivation

Reuse rather than reinvention.

Examples

Another electricity company has built a customer service system. Its hardware is different from ours, but we could buy its requirements specification and cut our analysis effort by approximately 60%.

Considerations

While a ready-made solution may not exist, perhaps something, in its essence, is similar enough that you could copy and possibly modify to better effect than starting from scratch. This approach must be done carefully, as it relies on the base system being of good quality.

This question should always be answered. The act of answering it will force you to look at other existing solutions to similar problems.

Form

For each of sections 19a, 19b, and 19c, set out the alternatives that you think are suitable. If your findings are preliminary, then say so. It is useful to add approximate costs, availability, time to implement, and other factors that may have a bearing on the decision.

20. New Problems

20a. Effects on the Current Environment

Content

A description of how the new product will affect the current implementation environment. This section should also cover things that the new product should not do.

Motivation

Discover early any potential conflicts that might otherwise not be realized until implementation time.

Examples

Any change to the scheduling system will affect the work of the engineers in the divisions and the work of the truck drivers.

Considerations

Is it possible that the new system might damage some existing system? Can people be displaced or otherwise affected by the new system?

Form

These issues require a study of the current environment. A model highlighting the effects of the change is a good way to make this information widely understandable.

20b. Effects on the Installed Systems

Content

Specification of the interfaces between new and existing systems.

Motivation

Very rarely is a new development intended to stand completely alone. Usually, the new system must coexist with some older system. This question forces you to look carefully at the existing system, examining it for potential conflicts with the new development.

Form

A model identifying the interfaces between the new and existing systems supported by data dictionary definitions of the interfaces. The interfaces might also be supported by prototypes or sketches of format.

20c. Potential User Problems

Content

Details of any adverse reaction that might be suffered by existing users.

Motivation

Sometimes existing users are using a product in such a way that they will suffer ill effects from the new system or feature. Identify any likely adverse user reactions and determine whether/why we care about those reactions and what precautions we will take.

20d. Limitations in the Anticipated Implementation Environment That Might Inhibit the New Product

Content

Statement of any potential problems with the new automated technology or new ways of structuring the organization.

Motivation

The intention is to make early discovery of any potential conflicts that might otherwise not be realized until implementation time.

Examples

The planned new server is not powerful enough to cope with our projected growth pattern.

The size and weight of the new product do not fit into the physical environment.

The power capabilities will not satisfy the new product’s projected consumption.

Considerations

This requires a study of the intended implementation environment.

20e. Follow-Up Problems

Content

Identification of situations that we might not be able to cope with.

Motivation

To guard against situations where the product might fail.

Considerations

Will we create a demand for our product that we are not able to service? Will the new system cause us to run afoul of laws that do not currently apply? Will the existing hardware cope?

There are potentially hundreds of unwanted effects. It pays to answer these questions very carefully.

21. Tasks

What steps must be taken to deliver the product? This section highlights the effort required to build the product, the steps needed to buy a solution, the amount of effort to modify and install a ready-made solution, and so on.

21a. Project Planning

Content

Details of the life cycle and approach that will be used to deliver the product.

Motivation

To specify the approach that will be taken to deliver the product so that everyone has the same expectations.

Considerations

Depending on the maturity level of your process, the new product will be developed using your standard approach. However, some circumstances are unique to a particular product and will necessitate changes to your life cycle. While these considerations are not product requirements, they are needed if the product is to be successfully developed.

If possible, attach an estimate of the time and resources needed for each task based on the requirements that you have specified. Attach your estimates to the events, use cases, stories, and/or functional requirements that you specified in sections 6, 8 and 9.

Do not forget issues related to data conversion, user training, and cutover. These needs are usually ignored when projects set implementation dates.

Form

A high-level process diagram or a task list showing the tasks and the interfaces between them is a good way to communicate this information. Here you can also identify the strategy that you intend to use to maximize your potential for agility.

21b. Planning of the Development Phases

Content

Specification of each phase of development and the components in the operating environment.

Motivation

To identify the phases necessary to implement the operating environment for the new system so that the implementation can be managed.

Considerations

Identify which hardware and other devices are necessary for each phase of the new system. This list may not be known at the time of the requirements process, as these devices may be decided at design time.

Form

This is usually a mixture of diagrams and text. Specify the following for each phase of the project:

● Name of the phase

● Value/benefit of delivery to user

● Required operational date

● Operating environment components included

● Functional requirements included

● Non-functional requirements included

22. Migration to the New Product

When you install a new product, some things always must be done before it can work successfully. For example, databases often need to be converted. There is usually new data to be collected, procedures to be converted, and many other steps to be taken to ensure the successful transition to the new product.

Often there are periods where the organization will run both the old product and the new product in parallel until the new one has proven that it is functioning correctly.

This section of the specification is where you identify the tasks necessary for the period of transition to the new product. This section is input to the project planning process.

22a. Requirements for Migration to the New Product

Content

A list of the conversion activities. A timetable for implementation.

Motivation

To identify conversion tasks as input to the project planning process, and to provide the basis for a timetable for the migration.

Considerations

Will you use a phased implementation to install the new system? If so, describe which requirements will be implemented by each major phase.

What kind of data conversion is necessary? Must special programs be written to transport data from an existing system to the new one? If so, describe the requirements for these programs here.

Is any manual backup needed while the new system is being installed?

When is each major component to be put in place? When are the phases of the implementation to be released?

Is there a need to run the new product in parallel with the existing product?

Will we need additional or different staff?

Is any special effort needed to decommission the old product?

Form

A cross-reference between the development tasks, your project phases, and the PUCs and atomic requirements.

22b. Data That Has to Be Modified or Translated for the New Product

Content

List of data translation tasks.

Motivation

To discover missing tasks that will affect the size and boundaries of the project.

Considerations

Every time you make an addition to your dictionary (see section 7), ask this question: Where is this data currently held, and will the new system affect that implementation?

Form

Description of the current technology that holds the data. Description of the new technology that will hold the data. Description of the data translation tasks. Foreseeable problems.

23. Risks

All projects involve risk—namely, the risk that something will go wrong. Risk is not necessarily a bad thing, as no progress is made without taking some risk. Risk is only a bad thing if the risks are ignored and they become problems. Risk management entails assessing which risks are most likely to apply to the project, deciding on a course of action if they become problems, and monitoring projects to give early warnings of risks becoming problems.

Content

This section of the specification contains a list of the most likely and most serious risks for your project. For each risk, include the probability of it becoming a problem, and any contingency plans.

Motivation

To discover and manage the risks.

Considerations

Risks will undoubtedly change during the lifetime of a project. The better you understand the requirements, the better you can identify which risks are most serious for your project. The project manager determines how to manage the risks, but the requirements specialists and developers provide input on new risks and which risks are turning into problems.

Use your knowledge of the requirements as input to discover which risks are most relevant to your project. Use the Volere Requirements Knowledge Model (Appendix C) as a trigger for identifying relevant risks.

It is also useful input to project management if you include the impact on the schedule and/or the cost if the risk does become a problem.

As an alternative, you may prefer to identify any “showstopper” risks. If any of these risks become a problem, then the project will definitely fail. Project efforts are then concentrated on not letting these risks manifest themselves as a problem.

This section is not intended to be a thorough treatise on risk management. Nor is this section meant to be a substitute for proper risk management. The intention here is to assign risks to requirements and show clearly that requirements are not free—they carry a cost that can be expressed as an amount of money or time, and as a risk. Later, you can use this information if you need to make choices about which requirements should be given a higher priority.

Form

A risk list or log. For each risk, include the probability of that risk becoming a problem. Capers Jones, a software statistician, cites the following risks as being the most serious:

● Inaccurate metrics

● Inadequate measurement

● Excessive schedule pressure

● Management malpractice

● Inaccurate cost estimating

● Silver bullet syndrome

● Creeping user requirements

● Low quality

● Low productivity

● Canceled projects

24. Costs

The other cost of requirements is the amount of money or effort that you must spend building them into a product. Once the requirements specification is complete, you can use one of the estimating methods to assess the cost, expressing the result as a monetary amount or time to build.

There is no best method to use when estimating. The important thing is to create your estimates using metrics directly related to the requirements. If you have specified the requirements in the way we have described, you will have some or all of the following metrics:

● Number of input and output flows on the work context

● Number of business events

● Number of BUCs

● Number of business stories

● Number of PUCs

● Number of functional requirements

● Number of non-functional requirements

● Number of requirements constraints

● Number of function points

The more detailed the work you do on your requirements, the more accurate your estimates will be. Your cost estimate is the amount of resources you estimate each type of deliverable will take to produce within your environment. You can create some very early cost estimates based on the work context. At that stage, your knowledge of the work will be general, and you should reflect this vagueness by making the cost estimate a range rather than a single figure. You can use these metrics as the basis for estimating the time, effort, and cost of building the product. First, you need to determine what each metric means within the environment in which you are building the product. For example, do you know how much effort it will take you to do all the work necessary to implement a PUC? If you do not, then you can take one of the use cases and benchmark it.

As you increase your knowledge of the requirements, we suggest you try using function point counting—not because it is an inherently superior method, but because it is so widely accepted. So much is known about function point counting that it is possible to make easy comparisons with other products and other installations’ productivity.

You can also use planning poker, story points, and several other methods.

It is important that your client be told at this stage what the product is likely to cost, or how much effort is needed. You usually express this amount as the total cost to complete the product, but you may also find it advantageous to point out the cost of the requirements effort or the costs of individual requirements.

Whatever you do, do not leave the costs in the lap of hysterical optimism. Make sure that this section includes meaningful numbers based on tangible deliverables.

25. User Documentation and Training

This section specifies the user documentation that will be produced as part of the product-building effort. This is not the documentation itself, but a description of what must be produced. The reason for including this description is to establish your client’s expectations, and to give your usability people and your users the chance to assess whether the proposed documentation will be sufficient.

25a. User Documentation Requirements

Content

List of the user documentation to be supplied as part of the product. Be careful not to waste time defining anything that has already been defined. Bear in mind that the requirements, especially the PUCs, atomic requirements, and definitions of data provide the input for the user documentation.

Motivation

To set expectations for the user manuals and to identify who will be responsible for creating them.

Examples

Technical specifications to accompany the product. User manuals. Service manuals (if not covered by the technical specification). Emergency procedure manuals (e.g., the card found in airplanes). Installation manuals.

Considerations

Which documents do you need to deliver, and to whom? Bear in mind that the answer to this question depends on your organizational procedures and roles.

For each document, consider these issues:

● The purpose of the document

● The people who will use the document

● Maintenance of the document

What level of documentation is expected? Will the users be involved in the production of the documentation? Who will be responsible for keeping the documentation up to date? What form will the documentation take?

Use the requirements that you have already specified as input to writing the user documentation. For example, if you have defined all the terms used in the requirements, then take advantage of this and use the same definitions and dictionary in the user documentation. Use the PUC scenarios as the core of describing how a user can do a particular task. If someone else is writing the user documentation, then show them how they can use a lot of the work that has already been done as the basis for user manuals.

25b. Training Requirements

Content

A description of the training needed by users of the product. Be careful not to waste time defining anything that has already been defined. Bear in mind that the requirements, especially the PUCs, atomic requirements, and definitions of data provide the input for the user training.

Motivation

To set expectations for the training. To identify who is responsible for creating and providing that training.

Considerations

What training will be necessary? Who will design the training? Who will provide the training? What are the plans for holding the training sessions?

Use the requirements that you have already specified as input to designing the training. For example, you have specified what a PUC must do. Use that PUC scenario or model as the basis for building training for the users who will be carrying out that task. You have defined all the terms used in the requirements, so take advantage of this and use the same definitions and dictionary in the user training.

26. Waiting Room

The waiting room holds requirements that will not, for one reason or another, be part of the upcoming release of the product. If you are competent at gathering requirements, your users may often be inspired to think of more requirements than you can fit within the constraints of the project. While you may not want to include all these requirements in the initial version of the product, neither do you want to lose them.

If you are doing iterative development, then the waiting room is your story backlog.

Content

Any type of business event, requirement, or story at any level of detail.

Motivation

To allow requirements to be captured, even though they will not be part of the current development. To ensure that good ideas are not lost. To manage a backlog.

Considerations

The requirements discovery process often throws up requirements that are beyond the sophistication of, or time allowed for, the upcoming release of the product. This section holds these requirements in waiting. The intention is to avoid stifling the creativity of your users and clients, by using a repository to retain future requirements. You are also managing expectations by making it clear that you take these requirements seriously, although they will not be part of the agreed-upon product.

Many people use the waiting room as a way to plan future versions of the product. Each requirement in the waiting room is tagged with its intended version number. As a requirement progresses closer to implementation, you can spend more time on it and add details such as the cost and benefit attached to that requirement.

You might also prioritize the contents of your waiting room. Low-hanging fruit—requirements that provide a high benefit at a low cost of implementation—are the highest-ranking candidates for the next release. You would also give a high waiting room rank to requirements for which there is a pent-up demand. You can think of the waiting room as a way of managing your backlog.

The waiting room means your users and client know the requirements are not forgotten, but merely parked until it is time to review them and make decisions about whether they will be incorporated in the product.

27. Ideas for Solutions

Ideas for solutions are obviously not requirements, but it is impossible when gathering requirements not to get ideas for how they might be implemented. Rather than discarding the ideas or—even worse—writing them as if they are requirements, a practical idea is to simply set aside a section of your specification for these ideas. Record each one in this area, and then hand them over, along with the requirements, to your designer.

Content

Any idea for a solution that you think is worth keeping for future consideration. This can take the form of rough notes, sketches, pointers to other documents, pointers to people, pointers to existing products, prototypes, and so on. The aim is to capture, with the least amount of effort, an idea that you can return to later.

Motivation

To make sure that good ideas are not lost. To help you separate requirements from solutions.

Considerations

While you are gathering requirements, you will inevitably have solution ideas; this section offers a way to capture them. Bear in mind that this section will not necessarily be included in every document that you publish.

Form

The ideas for solutions are an ideal subject for a blog. This is, after all, the place for ideas, and blogs are a great place for creativity and building on one another’s ideas.

B

Stakeholder Management Templates

This appendix contains templates that are designed to help you manage your stakeholders. Its aim is threefold:

To help you discover the relevant stakeholders for your project

To help you identify gaps that are without stakeholder representation

To help you agree on your decision-making structure

Stakeholder Map

Figure B.1 is a generic stakeholder map showing the potential classes of stakeholders. Use it as an aid for discovering your stakeholders. Refer to Part II, Project Blastoff, for a discussion of stakeholder classes.

Figure B.1

This generic stakeholder map shows the various classes of stakeholders. Use it as an aid to identifying your stakeholders.

Figure B.2

The stakeholder template showing stakeholder roles and classes of needed knowledge

Stakeholder Template

The following template is a sample checklist you can use to identify and analyze your stakeholders. Note that the template’s stakeholder classes correspond to those on the stakeholder map (Figure B.1). For each stakeholder class, we have suggested common roles that represent the class. Of course, you will want to modify this list to include role names that are appropriate for your organization. It will probably be more convenient for you to do so using a spreadsheet. An extract of the spreadsheet is shown in Figure B.2. The complete version of the stakeholder template in the form of an Excel spreadsheet can be found at https://www.volere.org/templates/stakeholder-analysis-download.

C

Volere Requirements Knowledge Model

The Volere Requirements Knowledge Model is a language for communicating and keeping track of the knowledge that you discover during requirements-related activities. Your model specifies which requirements knowledge you plan to discover and trace. Your own process must define who gathers which knowledge, to what degree of detail, and how it will be packaged and reviewed.

Using the Model

As with any language, communication is most effective when everyone has the same understanding of the words that you use. If your team agree on how they are going to communicate, it will make for a more effective team. We recommend that you start with one of the example knowledge models in this appendix and use it as the basis for planning and monitoring your project. If you find a term that has different meanings for different team members, then it’s an indication that you need to determine the consensus meaning and change the model so that you remove the potential communication block.

Interpreting the Model

A requirements knowledge model identifies the classes of requirements knowledge and the relationships between them. An extract is shown in Figure C.1.

Figure C.1

Two knowledge classes and their relationship

In this example, the Work Scope and the Business Event are both classes of knowledge. The relationship between the two classes is that they identify the Business Boundary. There is one (1) Work Scope related to many (*) Business Events. Reading in the other direction, you see that each Business Event is related to (1) Work Scope.

The precise meaning of every class and relationship is defined later in this appendix.

Example Requirements Knowledge Model

You can use the example knowledge model as a starting point for your own knowledge model (see Figure C.2). If you need to, you can make changes by adding or renaming the classes and/or relationships, but remember that any change you make should be reflected in the dictionary of definitions that supports your model; see the sample dictionary in the next section.

Figure C.2

The requirements knowledge model showing the classes of knowledge used for requirements discovery

The following knowledge classes are suited to projects in which you specify individual atomic requirements:

● Business Events

● Business Use Cases

● Product Use Cases

● Atomic Requirements

OR

The following knowledge classes suit projects that use Stories and are especially suited to agile development teams:

● Business Events

● Business Event Stories

● Functional Stories

● Detailed Tasks

Dictionary for Requirements Knowledge Model

It is preferable if you have common agreement on what the names of the classes mean. This requires a dictionary to support the names you use. The following is a definition of the classes of knowledge and the relationships between them. The classes are listed in alphabetical order, followed by the relationships in alphabetical order.

Knowledge Classes

Knowledge class: Atomic Requirement

Purpose:

An atomic requirement specifies a business need or want. It has a number of attributes.

Attributes:

Requirement Number

Requirement Description

Requirement Rationale

Requirement Type

Requirement Fit Criterion

Requirement Source

Customer Satisfaction

Customer Dissatisfaction

Conflicting Requirements

Dependent Requirements

Supporting Material

Version Number

Considerations:

Also see the requirement subtypes; namely, Constraint Requirement, Functional Requirement, Non-functional Requirement, and Technological Requirement.

Suggested Implementation:

Sections 9 through 17 of the Volere Requirements Specification Template. Various automated tools are available that allow team access to the requirements.

Knowledge class: Business Event

Purpose:

A Business Event is a happening outside the work scope that is a demand for some service provided by the work. Examples of business events: Motorist passes an electronic tollbooth; Customer orders a book; Doctor needs a scan of a patient; Pilot lowers the landing gear.

Business events can also happen because of the passage of time. For example, if a customer’s bill is not paid in 30 days, then it is time for the work to send a reminder. Or if it is two months before an insurance policy is due to expire, it is time to send a renewal notice.

Attributes:

Business Event Name

Business Event Adjacent Systems/Actors/Users

Business Event Summary

Considerations:

It is important to recognize the business event. Its nature, the circumstances that exist at the time of the event, and the activity of the adjacent system at the time of the event are all important indicators of the appropriate response.

Suggested Implementation:

Section 6 of the Volere Requirements Specification Template. A list of the business events and their associated input and output flows will suffice. It is practical to give each business event a unique identifier.

Knowledge class: Business Event Story

Purpose:

A Business Event Story describes what activity is needed when a business event takes place. A business event story is the equivalent of a business use case, but it usually does not go into as much detail. If you are working in an agile environment, then it is likely that you are using business event stories.

Attributes:

Role of Stakeholder

Name of Stakeholder

Stakeholder Functionality

Reason for needing this functionality

Suggested Implementation:

As a [Name of Stakeholder, name of customer segment, adjacent system name, or Role name]

I can [Something the stakeholder needs the work to do]

So that [The business reason for fulfilling this need]

Knowledge class: Business Use Case

Purpose:

A Business Use Case (BUC) is the processing done in response to a business event. For example, A policyholder decides to make a claim is a business event. The triggering data flow in this case is that a Claim Request informs the BUC that the event has taken place. The business use case contains all the processing done by the work to approve or deny the claim. Also see Business Event Story and Product Use Case.

Attributes:

Business Use Case Name

Business Use Case Description

Business Use Case Trigger (this is the data flow that triggers the BUC)

Business Use Case Outputs

Business Use Case Rationale

Business Use Case Priority

Normal Case Scenario

Exception Case Scenarios

Preconditions

Post or Exit Conditions

Considerations:

Business use cases are self-contained portions of the work and can be studied independently. For this reason, they are an important unit that project leaders use to structure the analytical work.

Suggested Implementation:

Section 6 of the Volere Requirements Specification Template. An automated tool that allows sharing of the business use case attributes is advisable. BUCs can be represented using any combination of business process models, sequence diagrams, activity diagrams, scenarios, or any other representation that is acceptable to the people involved, providing the Business Event Story is within the boundaries declared for the Business Event.

Knowledge class: Constraint Requirement

Purpose:

A constraint is a type of requirement. It is a constraint on the design of the solution or a constraint on the project itself, such as budget or time restrictions.

Considerations:

Constraints are a type of requirement. They are imposed because of organizational policy or technological needs. Highlight them, as it is important that you and your management are aware that they are constraints and not customer-generated requirements.

Suggested Implementation:

Section 3 of the Volere Requirements Specification Template. Design constraints should be recorded in the same way as the other requirements. See the Knowledge class Atomic Requirement for the attributes.

Knowledge class: Detailed Task

Purpose:

The Detailed Tasks are chunks of functionality. You can think of them as the things that have to be done to complete the work of the Functional Story.

Suggested Implementation:

A sentence stating a cohesive unit of functionality: Get Airport Information, Find Matching Address, Store Customer Details ….

Knowledge class: Fact/Assumption

Purpose:

An Assumption states an expectation on which decisions about the project are based. For example, it might be an assumption that another project will be finished before this one is, or that a particular law will not be changed, or that a particular supplier will reach a specified level of performance. If an assumption turns out not to be true, then it indicates that there might be unknown effects on the project.

A Fact is some knowledge that is relevant to the project and affects its requirements and design. A Fact can also state some specific exclusion from the solution and the reason for that exclusion.

Fact/Assumption is a global class and could have a Relationship with any of the other classes in your knowledge model.

Attributes:

Description of the Assumption/Fact

Reference to people and documents for more details

Considerations:

Assumptions indicate a risk. For this reason, they should be highlighted, and all affected parties made aware of the assumption. You could consider installing a mechanism to resolve all assumptions before implementation starts.

Suggested Implementation:

Section 5 of the Volere Requirements Specification Template. These can be written in free text. They should be regularly circulated to management and the project team to help everyone have the same understanding.

Knowledge class: Functional Requirement

Purpose:

A Functional Requirement is something that the product must do; for example, calculate the fare, analyze the chemical composition, record the name change, or find the new route. Functional requirements are concerned with creating, updating, referencing, and deleting the essential subject matter within the context of the study.

Attributes:

This is a subtype of Atomic Requirement and inherits its attributes.

Suggested Implementation:

Section 9 of the Volere Requirements Specification Template. See the Knowledge class Atomic Requirement for the attributes.

Knowledge class: Functional Story

Purpose:

A Functional Story represents one of the pieces of functionality that is necessary to implement a business event story.

Functional stories are concerned with creating, updating, referencing, and deleting the essential subject data within the scope of the solution.

Attributes:

A simple verb-object statement.

Suggested Implementation:

If the functionality is simple enough for one development cycle, then you can indicate the required functionality using a verb-object statement like Make Reservation, Pay Invoice, Find Suitable Flights ….

For more complex stories, you can use the common story format:

As a [Name of Stakeholder or Role name]

I can [The functionality of the story]

So that [The business reason/rationale behind the need]

Knowledge class: Implementation Unit

Purpose:

The unit for packaging your implementation.

Attributes:

Implementation Unit Name

Considerations:

This could be what your customers refer to as a “feature,” or if your product is a consumer item then it is possibly called a “function.” The choice of Implementation Unit is driven by a combination of your implementation technology and your implementation process. When you tailor this part of the knowledge model you might find that you replace the implementation unit with several classes. The important point is that you can unambiguously trace your implementation unit back to the relevant requirements.

Knowledge class: Naming Conventions and Data Dictionary

Purpose:

A Data Dictionary that defines the meaning of terms used within the requirements. This dictionary will be added to throughout the project to include terms that are related to the implementation. This is a global class and could have a Relationship with any of the other classes in your knowledge model. Consistent use of the same terminology, as defined in the dictionary, helps minimize misunderstandings.

Attributes:

Name of the Term

Definition of the Term

Suggested Implementation:

Section 4 of the Volere Requirements Specification Template; this should be in the form of a glossary. Along with the work context and the product context, this provides an introduction for new team members. In section 7 of the Template, there is a formal dictionary that defines the data in the inputs, outputs, and attributes within the scope of the work and the scope of the product. The dictionary provides a mechanism for connecting business terminology and implementation terminology.

Knowledge class: Non-functional Requirement

Purpose:

A non-functional Requirement is a quality that the product must have. For example, it must be fast, attractive, secure, customizable, maintainable, portable, and so on. Non-functional requirement types are Look and Feel, Usability, Performance and Safety, Operational Environment, Maintainability and Portability, Security, Cultural and Political, and Legal. For more about non-functional requirements, refer to the Volere Requirements Specification Template in Appendix A.

Attributes:

This is a subtype of Atomic Requirement and inherits its attributes.

Considerations:

Providing the functional requirements are correct, the non-functional properties are what make the customer accept the product.

Suggested Implementation:

Sections 10 through 17 of the Volere Requirements Specification Template. It is vital that you give all non-functional requirements the correct fit criterion.

Knowledge class: Product Use Case

Purpose:

A Product Use Case (PUC) is a functional grouping of requirements that will be implemented by the product. It is the part of the business use case that you decide to build as a product. If you are working with an agile development team, you will likely use Functional Stories instead of Product Use Cases.

Attributes:

Product Use Case Name

Product Use Case Identifier

Product Use Case Description

Product Use Case Users

Product Use Case Inputs

Product Use Case Outputs

Product Use Case Stories

Product Use Case Scenarios

Product Use Case Fit Criterion

Product Use Case Owner

Product Use Case Benefit

Product Use Case Priority

Suggested Implementation:

Section 8 of the Volere Requirements Specification Template. The product use cases are a good mechanism for communication within the extended project team. PUCs might take the form of models, user stories, scenarios, or anything else that suits the people involved. Whatever the type of representation, the details of the PUC should be within the boundaries declared by the PUC inputs and outputs.

Knowledge class: Project Goal

Purpose:

To understand why the company is making an investment in doing this project.

Attributes:

Project Goal Description

Business Advantage

Measure of Success

Note that there might be several project goals.

Suggested Implementation:

Section 1 of the Volere Requirements Specification Template. This is the basis for making decisions about scope, relevance, and priority. It is the guiding light for the project. Ideally, this should be defined as part of the project initiation. The project goals should be unambiguously defined and agreed on before putting effort into discovering detailed requirements.

Knowledge class: Solution Scope

Purpose:

The solution scope identifies the boundaries of the solution that will be built. The solution scope is a summary of the boundaries of all the product use cases OR all the functional stories.

Attributes:

User Names

User Roles

Other Adjacent Systems

Interface descriptions

Suggested Implementation:

Section 8 of the Volere Requirements Specification Template. This should preferably be a diagram: either a use case diagram or a solution context diagram. Some interface descriptions might be supported by prototypes or simulations.

Knowledge class: Stakeholder

Purpose:

Identifies all the people, roles, and organizations that have an interest in the project. This covers the project team, direct users of the product, other indirect beneficiaries of the product, specialists with technical skills needed to build the product, external organizations with rules or laws pertaining to the product, external organizations with specialist knowledge about the product’s domain, opponents of the product, and producers of competitive products.

Attributes:

Stakeholder Role

Stakeholder Name

Types of Knowledge

Necessary Participation

Appropriate Trawling Techniques

Contact information (e.g., email address)

Suggested Implementation:

Section 2 of the Volere Requirements Specification Template. Use the stakeholder map and stakeholder analysis template in Appendix B to define the attributes for each stakeholder.

Knowledge class: Systems Architecture Component

Purpose:

A piece of technology, software, hardware, or abstract container that influences, facilitates, and/or places constraints on the design.

Knowledge class: Technological Requirement

Purpose:

A technological requirement exists because of the technology chosen for the implementation. These requirements are there to serve the purposes of the technology and are not originated by the business.

Attributes:

This is a subtype of Atomic Requirement and inherits its attributes.

Considerations:

The Technological Requirements should only be considered when you know the technological environment. They can be recorded alongside the business requirements, but it must be clear which is which.

Knowledge class: Work Scope

Purpose:

Defines the boundary of the business investigation necessary to discover, invent, understand, and identify the requirements for the product.

Attributes:

Adjacent Systems

Input Data flows

Output Data flows

Work Scope Description

Considerations:

This should be recorded publicly, as our experience is that it helps the team share a common understanding of the business they are investigating. A context diagram is an effective communication tool for defining the work scope.

Suggested Implementation:

Section 7 of the Volere Requirements Specification Template. This is best illustrated with a context diagram.

Relationships

These relationships (associations, if you prefer) are shown in Figure C.2.

Relationship: Automating

Purpose:

To identify which parts of the business problem will have an automated solution.

Multiplicity:

For each Business Use Case there are many Product Use Cases.

OR

For each Business Event Story there are many Functional Stories.

Relationship: Business Boundary

Purpose:

To relate the work scope with the business events the work is responding to.

Multiplicity:

For each Business Event there is one Work Scope.

For each Work Scope there are potentially many Business Events.

Relationship: Business Relevancy

Purpose:

To ensure that there are relevant business connections between the scope of the investigation, the project purpose, and the stakeholders.

Multiplicity:

The trinary Relationship is as follows:

For each instance of

one Work Scope and

one Stakeholder there are one or more Project Goals.

For each instance of

one Project Goal and

one Stakeholder there is one Work Scope.

For each instance of

one Project Goal and

one Work Scope there are potentially many Stakeholders.

Relationship: Business Responding

Purpose:

To connect the chunk of functionality that responds to a business event.

Multiplicity:

For each Business Event there is one Business Use Case.

OR

For each Business Event there is one Business Event Story.

Relationship: Business Tracing

Purpose:

To keep track of which requirements are generated by which business use cases or Functional Stories.

Multiplicity:

For each Business Use Case there are potentially many Atomic Requirements.

OR

For each Functional Story there are potentially many Detailed Tasks.

Relationship: Design Guiding

Purpose:

To keep track of which Systems Architecture Components affect the Solution Scope.

Multiplicity:

The Solution Scope is potentially connected to many Systems Architecture Components.

Relationship: Implementing

Purpose:

To keep track of which Implementation Units implement which Atomic Requirements

OR

Detailed Tasks.

Multiplicity:

For each Implementation Unit there are potentially many Atomic Requirements

OR

Detailed Tasks.

Relationship: Owning

Purpose:

To establish ownership of the requirements. The idea of “ownership” is to identify a person who takes the responsibility for or is the most knowledgeable about the requirement.

Multiplicity:

Each Business Use Case

OR

Business Event Story is owned by one Stakeholder.

Relationship: Product Boundary

Purpose:

All the product use cases together form the complete Solution Scope.

OR

All the Functional Stories together form the complete Solution Scope.

Multiplicity:

For the Solution Scope there are potentially many Product Use Cases

OR

Many Functional Stories.

Relationship: Product Inclusion

Purpose:

To establish which requirements are contained in which product use cases

OR

Which detailed tasks are contained in which functional stories, for the purpose of traceability and dealing with change.

Multiplicity:

For each Atomic Requirement there is one Product Use Case.

OR

For each Detailed Task there is one Functional Story.

Relationship: Supporting

Purpose:

To keep track of which systems architecture components support which implementation units for the purpose of tracking tests and assessing the impact of change.

Multiplicity:

For each Systems Architecture Component there are potentially many Implementation Units.

For each Implementation Unit there are potentially many Systems Architecture Components.

Knowledge Model Annotated with Template Section Numbers

The Volere Requirements Knowledge Model is a formal structure for identifying and relating classes of requirements knowledge. The Volere Requirements Specification Template contains many examples and guidance for content and form for ways you can present the requirements knowledge. You will find the complete Volere Requirements Specification Template in Appendix A.

Figure C.3 shows the knowledge model again, this time annotated with the relevant sections of the requirements template.

Figure C.3

The numbers on the classes point to the relevant sections of the Volere Requirements Specification Template.

Glossary

actor The person or automated system that interacts with a product use case. Actors are also known as users and end users.

adjacent system A system (customer segment, person, organization, computer system) that provides information to or receives information from the work that you are studying.

agile development A way of developing software using iterative development. A variety of agile techniques exist, including Scrum, eXtreme Programming, and Crystal. We use the term “iterative” to mean any agile or iterative technique.

Agile Manifesto A set of principles that focus on the delivery of working software to the customer, collaborative working practices, and the ability to respond rapidly to change.

artificial intelligence (AI) The name given to intelligent machines or bots (software, really) that mimic human thinking capabilities.

atomic requirement A requirement that is testable and does not need further decomposition. See also functional requirement, non-functional requirement, constraint, snow card.

attribute A data element that describes (and has been attributed to) a class. Also used to mean the components of an atomic requirement.

blastoff A technique for building the foundation for the requirements activity by establishing the scope-stakeholders-goals trinity and verifying the viability of the project.

Brown Cow model A technique for discussing and modeling the work by using different system viewpoints. The viewpoints are permutations of now, future, how, and what.

business analyst The role responsible for discovering and communicating requirements among the project’s stakeholders. Can be referred to as requirements analyst, requirements engineer, and systems analyst.

business data model A model of the essential classes of business data and associations between them necessary to support the functional requirements within the scope of the work.

business event Something that happens to the business (usually called “the work”) that makes it respond. Examples: Customer pays an invoice, Truck reports all roads have been treated, Time to read electricity meters, and Customer wants to search website.

business process model A model of the processes within a business; often used to understand the current processes so that they can be improved. A variety of notations are used for such models.

business use case (BUC) The work’s response to a business event. It includes the processes and the stored data needed to satisfy the request implicit in the business event. See also product use case.

buyer See customer.

class A physical or abstract entity within a context of study that has one or more attributes of stored data.

class model A model showing classes of data and the associations between them. This is also known as a business data model.

client The person who is commissioning and paying for the development effort. The client can be internal, and is sometimes known as the sponsor. For example, the manager of the audit department would commission you to build an audit application. An external client would commission your organization to build a solution for him. In this case, you would be a development organization.

constraint A requirement, either organizational or technological, that restricts the way you produce the product. It may be a management edict on the way the product must be designed—“It must work on a 5G mobile phone”—or a budget that limits the extent of the product or a characteristic of the current technology that constrains the possible solutions.

context The subject matter, people, and organizations that affect the requirements for the product. The context of study, or the work context, identifies the business to be studied and the adjacent systems that interact with this work. The product context identifies the scope of the product and its interactions with users and other actors.

context diagram A graphical model of the work scope showing how the work to be investigated connects to the outside world.

customer A person who buys something from your client, or buys your solution. “Customer” and “client” are often used interchangeably.

customer segment A group of customers or end users who have a unique set of requirements that separates them from other customer segments. Typically you develop a solution for each customer segment.

data dictionary Specification (to the elemental level) of the terms used in the requirements specification.

data element A piece of data that has a defined range or set of values within a context of study. Also called an attribute.

data flow Data that moves from one process to another, or from an adjacent system to the work. Usually represented by a named arrow.

data model A model showing classes of data and the associations between them. This is also known as a class model. See also business data model.

design The act of crafting a technological solution to fit the requirements within the constraints.

developer Someone who is part of the technological development or building of the product, sometimes called a programmer.

domain analysis The activity of investigating, capturing, and specifying generic knowledge about a subject-matter area.

end user The person who operates your solution to do her work. Also called a customer.

essential viewpoint A viewpoint that focuses on the processes and data independently of any technological implementation. Also referred to as “thinking above the line.”

external event A business event triggered by a happening in an adjacent system outside the work context. See also time-triggered event.

$$$$$$$

fit criterion A quantification or measurement of the requirement such that you are able to determine whether the delivered product satisfies (fits) the requirement. This is much the same as an acceptance criterion.

function point A measure of the functionality of the work or of a piece of software. Function points were first proposed by Allan Albrecht; today the method for counting function points is specified by the International Function Point User Group.

functional requirement A requirement for the solution to carry out some functional activity.

innovation Fresh thinking about the problem to find a new and better way to do the work.

iterative development Strategies that facilitate repetitive and continuous delivery of software solutions with current business value.

lessons learned An examination of the project to date with the intention of improving the requirements discovery process. Also known as retrospective.

naming conventions The terminology (including abbreviations and acronyms) that the stakeholders use when talking about the work. This terminology is usually captured in a glossary such as the one you are reading.

non-functional requirement A property or quality that the product must have, such as an appearance, speed, security, accuracy, usability ….

off-the-shelf (OTS) Software products developed by external organizations. These can be commercial (COTS) or open source products. See also ready-made.

owner See client.

persona A virtual person, archetypical of your users, invented to help you discover the requirements.

problem space The scope of the study that is necessary in order to understand the problem to be tackled by a project. This is also called the work.

product The thing for which you are writing your requirements. In this book, “product” usually means a software product, but the requirements can be for hardware, consumer goods, a service, or anything else you need to specify. See also solution.

product owner The person responsible for the delivery of the product. The product owner is responsible for prioritizing the product backlog and deciding on the sequence in which parts of the product are developed.

product use case (PUC) The part of the business use case you decide to automate. You write the requirements for each product use case. See also business use case.

project blastoff See blastoff.

project goal The reasons for doing the project. The goal must include a quantification of the expected benefit.

prototype A simulation of potential solutions using software prototyping tools, low-fidelity whiteboards, or paper mockups. Also referred to as a sketch. In this book, prototypes are used to explore the problem space.

quality gateway A set of tests (relevance, ambiguity, viability, fit, etc.) to assure the quality of individual requirements before the requirements become part of the requirements specification.

rationale The justification for a requirement. Used to help understand a requirement, and to discover the underlying reason for the requirement.

ready-made A solution or a component that you do not build yourself. This can be an off-the-shelf (OTS) solution, an open-source solution or component, a legacy solution, or anything else you don’t build. It can be installed in-house, or it can be a cloud service or software as a service (SaaS).

requirement Something that the solution must do, or a property that the product must have, that is needed or wanted by the stakeholders.

requirements analyst The person who has responsibility for producing the requirements specification. Depending on how roles are defined in an organization, this individual might be referred to as a business analyst, systems analyst, or requirements engineer.

requirements creep The uncontrolled addition of new requirements to the product after the requirements are considered complete.

requirements knowledge model A conceptual filing system—usually expressed as a data model—that establishes a common language for communicating requirements. (An example appears in Appendix C.)

requirements repository A place for the project team to store requirements knowledge. The repository can be one or a combination of a specification, a story map, a backlog, a collection of artifacts, a database of requirements, or any other form that records the requirements.

requirements specification A complete collection of requirements knowledge for a specific project. The specification defines the product and may be used as a contract to build the product.

requirements specification template A guide for gathering and organizing requirements knowledge. (An example appears in Appendix A.)

requirements tool A software tool capable of maintaining all or part of the requirements specification.

scenario A breakdown of a business use case or product use case into a series of stakeholder-recognizable steps.

sketch A quickly built model or prototype of a piece of work or a candidate solution. Sketches are used to explore the problem space.

snow card A card—paper or digital—showing the attributes of an atomic requirement.

solution A way of implementing the requirements. Also called the product.

sponsor See client.

stakeholder Any person who has an interest in the product and who therefore has requirements for it, such as the client, a user, or someone with specialized knowledge who builds the product. Some stakeholders are outside the organization, such as an auditor, a safety inspector, or a lawyer.

story A technique for discovering requirements by using the guide: “As a [ … ] I can [ … ] so that [ … ].” Sometimes called a user story or a story card.

system In the context of this book, a business or work system, and not just a computer or software system.

systemic thinking Or Systems thinking. The technique of understanding how components of a business solution affect one another and affect the whole system.

systems analysis The craft of modeling the system’s functions and data. Systems analysis can be done in several ways: data flow modeling, as defined by DeMarco; event response modeling, as per McMenamin and Palmer; use cases, as per Jacobson; or any of the many object-oriented methods, most of which use the Unified Modeling Language (UML) notation or the Business Process Model and Notation (BPMN).

technological requirement A requirement that is necessary only because of the chosen technology; it is not there to satisfy a business need.

thinking above the line Deriving and discussing the essence of the work. The “thinking” refers to an exploration of the possibilities without being constrained (for the moment) by technological realities. The “line” is the horizontal line on the Brown Cow model that separates the physical reality (how) from the essential policy (what).

time-triggered event An event triggered by some time-related policy. Examples: “Time to produce sales report,” “Time to remind driver to renew license.” See also external event.

trawling techniques Techniques for discovering, eliciting, determining, and innovating requirements.

use case A chunk of functionality describing the interaction between a user/actor and an automated system. In this book we use business use case and product use case.

user The person or system that uses the product to do work. Also known as an actor or end user.

user story A way of specifying functionality to be developed. The form “As a [ … ] I can [ … ] so that [ … ].” is used. See also story.

Volere A set of principles, processes, templates, tools, and techniques developed to improve the discovery, communication, and management of requirements. (Volere is the Italian verb for “to wish” or “to want.”)

work A business area of the organization that your product is meant to improve. The business analyst studies the work before making decisions on the optimal product to do some or all of the work. Work is also known as the problem space.

work scope The extent of the business area under investigation. It is usually shown using a context diagram.

Bibliography

Ackoff, Russell, and Herbert Addison. 2010. Systems Thinking for Curious Managers: With 40 New Management f-Laws. Dorset, UK: Triarchy Press.

Adolph, Steve, Shane Hastie, and Ryland Layton. 2023. The Rock Crusher: A Model for Flow-Based Backlog Management. Ontario: International Institute of Business Analysis.

Alexander, Ian, and Ljerka Beus-Dukic. 2009. Discovering Requirements: How to Specify Products and Services. Hoboken, NJ: Wiley.

Alexander, Ian, and Neil Maiden. 2004. Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle. Hoboken, NJ: Wiley.

Alexander, Ian, and Richard Stevens. 2002. Writing Better Requirements. Boston: Addison-Wesley.

Allen, David. 2015. Getting Things Done: The Art of Stress-Free Productivity. London: Piatkus Books.

Allweyer, Thomas. 2010. BPMN 2.0. Norderstedt, Germany: Books on Demand.

Anderson, David, and Andy Carmichael. 2016. Essential Kanban Condensed. Seattle: Lean-Kanban University.

Beyer, Hugh, and Karen Holtzblatt. 1998. Contextual Design: Defining Customer-Centered Systems. San Francisco: Morgan Kaufmann.

Blaise, Steven. 2012. Business Analysis: Best Practices for Success. Hoboken, NJ: Wiley.

Boehm, Barry, and Richard Turner. 2004. Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison-Wesley.

Booch, Grady, James Rumbaugh, and Ivar Jacobson. 2005. Unified Modeling Language User Guide, Second Edition. Boston: Addison-Wesley.

Brennan, Kevin, with Sallie Godwin and Filip Hendrickx. 2022. Digital Product Management. London: BCS, The Chartered Institute for IT.

Brooks, Frederick P. 2010. The Design of Design. Boston: Pearson Education.

Brooks, Frederick P. 1995. The Mythical Man-Month. Reading, MA: Addison-Wesley.

Buzan, Tony. 2018. Mind Map Mastery: The Complete Guide to Learning and Using the Most Powerful Thinking Tool in the Universe. London: Watkins Publishing.

Cadle, James, Debra Paul, Jonathan Hunsley, Adrian Reed, David Beckham, and Paul Turner. 2021. Business Analysis Techniques: 123 Essential Tools for Success, 3rd Edition. Swindon, UK: BCS Learning and Development Ltd.

Capron, John. 2020. Sometimes the Most Important Requirement for a Project Is Courage: A Cautionary Tale of Project Management. Independently published.

Checkland, Peter. 1993. Systems Thinking, Systems Practice. Hoboken, NJ: Wiley.

Chemuturi, Murali. 2010. Mastering Software Quality Assurance: Best Practices, Tools, and Techniques for Software Developers. Plantation, FL: J. Ross Publishing.

Christensen, Clayton. 2011. The Innovator’s Dilemma: The Revolutionary Book That Will Change the Way You Do Business. New York: Harper Business Books.

Cockburn, Alastair. 2006. Agile Software Development: The Cooperative Game. Boston: Addison-Wesley.

Cohn, Mike. 2005. Agile Estimating and Planning. Upper Saddle River, NJ: Pearson.

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston: Addison-Wesley.

Cooper, Alan. 2004. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis: Sams Publishing.

Cooper, Alan, Robert Reimann, and David Cronin. 2007. About Face 3: The Essentials of Interaction Design, Third Edition. Hoboken, NJ: Wiley.

Cooper, Alan, Robert Reimann, David Cronin, and Christopher Noessel. 2007. About Face: The Essentials of Interaction Design, 4th Edition. Hoboken, NJ: Wiley.

Davis, Alan. 2005. Just Enough Requirements Management. New York: Dorset House.

de Voil, Nick. 2019. User Experience Foundations. London: BCS, The Chartered Institute for IT.

DeMarco, Tom, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson, and Suzanne Robertson. 2009. Adrenaline Junkies and Template Zombies: Patterns of Project Behaviour. New York: Dorset House.

DeMarco, Tom, and Tim Lister. 2003. Waltzing with Bears: Managing Risk on Software Projects. New York: Dorset House.

DeMarco, Tom, and Tim Lister. 1999. Peopleware: Productive Projects and Teams, Second Edition. New York: Dorset House.

Fenton, Norman, and Shari Lawrence Pfleeger. 1997. Software Metrics: A Rigorous and Practical Approach. Boston: International Thomson Computer Press.

Flyvbjerg, Bent, and Dan Gardner. 2023. How Big Things Get Done. New York: Macmillan.

Fowler, Martin. 2003. UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition. Boston: Addison-Wesley.

Gause, Donald, and Gerald Weinberg. 1989. Exploring Requirements: Quality Before Design. New York: Dorset House.

Gelperin, David. 2017. Understanding Requirements. Minneapolis: ClearSpecs Press.

Gilb, Tom. 2005. Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Oxford, UK: Butterworth-Heinemann.

Girvan, Lynda, and Debra Paul. 2024. Agile and Business Analysis: Practical Guidance for IT Professionals, Second Edition. London: BCS, The Chartered Institute for IT.

Goldenberg, Herbert, and Irene Goldenberg. 2012. Family Therapy: An Overview, Eighth Edition. Independence KY: Cengage Learning.

Gottesdiener, Ellen. 2002. Requirements by Collaboration: Workshops for Defining Needs. Boston: Addison-Wesley.

Gottesdiener, Ellen, and Mary Gorman. 2012. Discover to Deliver. Acton, MA: EBG Consulting.

Griffiths, Chris, with Melina Costi and Caragh Medlicott. 2022. The Creative Thinking Handbook. Penarth, UK: Open Genius Ltd.

Hargadon, Andrew. 2003. How Breakthroughs Happen. Cambridge, MA: Harvard Business Review Press.

Highsmith, James. 2000. Adaptive Software Development. New York: Dorset House.

Hoberman, Steve. 2009. Data Modeling Made Simple: A Practical Guide for Business and IT Professionals. Sedona, AZ: Technics Publications.

Holtzblatt, Karen, Jessamyn Burns Wendell, and Shelley Wood. 2004. Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design. Burlington, MA: Morgan Kaufmann.

Hull, Elizabeth, Ken Jackson, and Jeremy Dick. 2005. Requirements Engineering, Second Edition. New York: Springer.

International Function Point Users Group. 2010. Function Point Counting Practices Manual. Westerville, OH: IFPUG.

International Institute of Business Analysis. 2021. The Business Analysis Body of Knowledge (BABOK Guide). Ontario: International Institute of Business Analysis.

Jacobson, Ivar. 1992. Object-Oriented Software Engineering: A Use Case Driven Approach. Boston: Addison-Wesley.

Kelley, Tom, and David Kelley. 2013. Creative Confidence: Unleashing the Creative Potential Within Us All. New York: Crown Currency.

Kelley, Tom, with Jonathan Littman. 2001. The Art of Innovation. New York: Doubleday.

Lauesen, Soren. 2005. User Interface Design. Boston: Addison-Wesley.

Lauesen, Soren. 2002. Software Requirements: Styles & Techniques. Boston: Addison-Wesley.

Lawrence-Pfleeger, Shari. 2009. Software Engineering: Theory and Practice, Fourth Edition. Upper Saddle River, NJ: Prentice Hall.

Leffingwell, Dean. 2011. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston: Addison-Wesley.

Leybourn, Evan, and Shane Hastie. 2023. #noprojects: A Culture of Continuous Value. Morrisville, NC: Lulu Press.

Lidwell, William, Kritina Holden, and Jill Butler. 2003. Universal Principles of Design. Beverly, MA: Rockport Publishers.

Maeda, John. 2006. The Laws of Simplicity. Cambridge, MA: MIT Press.

Maiden, Neil, and Suzanne Robertson. 2005. Integrating Creativity into Requirements Processes: Experiences with an Air Traffic Management System. International Conference on Software Engineering, May 2005.

McConnell, Steve. 2006. Software Estimation: Demystifying the Black. Redmond, WA: Microsoft Press.

McElroy, Kathryn. 2017. Prototyping for Designers: Developing the Best Digital and Physical Products. Sebastopol, CA: O’Reilly.

McGreal, Don, and Ralph Jocham. 2018. The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Boston: Addison-Wesley.

McMenamin, Steve, and John Palmer. 1984. Essential Systems Analysis. New York: Yourdon Press.

McMenamin, Steve, and Tom DeMarco, Peter Hruschka, Tim Lister, James Robertson, and Suzanne Robertson. Happy to Work Here. 2021. Camden, ME: Systems Guild.

Meadows, Donella. 2008. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green Publishing.

Merkow, Mark. 2011. Secure and Resilient Software: Requirements, Test Cases, and Testing Methods. Boca Raton, FL: Auerbach Publications.

Meyer, Bertrand. 2022. Handbook of Requirements and Business Analysis. New York: Springer.

Meyer, Bertrand. 2014. Agile: The Good, the Hype and the Ugly. New York: Springer.

Michalko, Michael. 2006. Thinkertoys: A Handbook of Creative-Thinking Techniques. Emeryville, CA: Ten Speed Press. Associated website: https://www.mycoted.com.

Miller, Roxanne. 2009. The Quest for Software Requirements. Montgomery, IL: MavenMark Books.

Murray-Webster, Ruth, and Penny Pullan. 2022. Making Risk Management Work: Engaging People to Identify, Own and Manage Risk. New York: Routledge.

Nixon, Natalie (Ed.). 2016. Strategic Design Thinking. New York: Bloomsbury.

Norman, Donald. 2002. The Design of Everyday Things. New York: Basic Books.

Osterwalder, Alex, Yves Pigneur, Greg Bernarda, and Alan Smith. 2014. Value Proposition Design: How to Create Products and Services Customers Want. Hoboken, NJ: Wiley.

Osterwalder, Alexander, and Yves Pigneur. 2010. Business Model Generation. Hoboken, NJ: Wiley.

Pardee, William J. 1996. To Satisfy and Delight Your Customer. New York: Dorset House.

Patton, Jeff. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol, CA: O’Reilly.

Patton, Jeff, with Peter Economy. 2014. User Story Mapping. Sebastopol, CA: O’Reilly.

Paul, Debra, and Christina Lovelock. 2019. Delivering Business Analysis: The BA Service Handbook. London: BCS, The Chartered Institute for IT.

Paul, Debra, and James Cadle. 2020. Business Analysis, 4th Edition. London: BCS, The Chartered Institute for IT.

Paul, Debra, Donald Yeates, and James Cadle. 2014. Business Analysis. London: BCS, The Chartered Institute for IT.

Pilone, Dan, and Neil Pitman. 2005. UML 2.0 in a Nutshell. Sebastopol, CA: O’Reilly.

Podeswa, Howard. 2021. The Agile Guide to Business Analysis and Planning. Boston: Addison-Wesley.

Pohl, Klaus. 2010. Requirements Engineering: Fundamentals, Principles, and Techniques. New York: Springer.

Project Management Institute. Business Analysis for Practitioners: A Practice Guide. Project Management Institute, 2015.

Pullan, Penny. 2021. Making Workshops Work: Creative Collaboration for Our Time. Northwich, UK: Practical Inspiration Publishing.

Pullan, Penny, and James Archer (Eds.). 2013. Business Analysis and Leadership: Influencing Change. London: Kogan Page.

Reed, Adrian. 2018. Business Analyst: Careers in Business Analysis. London: BCS, The Chartered Institute for IT.

Reed, Adrian. 2018. Business Analyst: Careers in Business Analysis. Swindon, UK: British Computer Society.

Reed, Adrian. 2016. Be a Great Problem Solver—Now! Upper Saddle River, NJ: Pearson.

Richards, Ian, and Filip Hendrickx. 2021. Brainy Glue: Making Change Stick. BrainyGlue.com: Brainy Glue.

Roam, Dan. 2013. The Back of the Napkin: Solving Problems and Selling Ideas with Pictures. New York: Portfolio.

Robertson, James, and Suzanne Robertson. 1994. Complete Systems Analysis: The Workbook, the Textbook, the Answers. New York: Dorset House.

Robertson, Suzanne, and James Robertson. 2018. Business Analysis Agility: Solve the Real Problem, Deliver Real Value. Boston: Addison-Wesley.

Robertson, Suzanne, and James Robertson. 2013. Mastering the Requirements Process, Third Edition. Boston: Addison-Wesley.

Robertson, Suzanne, and James Robertson. 2005. Requirements-Led Project Management: Discovering David’s Slingshot. Boston: Addison-Wesley.

Roderich, Oliver. 2021. 5 Whys: The Effective Root Cause Analysis. Self-published.

Rothman, Johanna. 2015. Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. Leanpub.com: Practical Ink.

Rumbaugh, James, Ivar Jacobson, and Grady Booch. 2004. Unified Modeling Language Reference Manual, Second Edition. Boston: Addison-Wesley.

Russell, Mike. 2015. Wrong Until Right: How to Succeed Despite Relentless Change. WrongUntil Right.com.

Senge, Peter. 2006. The Fifth Discipline: The Art and Practice of the Learning Organization, Revised Edition. New York: Crown Business.

Sharp, Helen, Yvonne Rogers, and Jenny Preece. 2011. Interaction Design: Beyond Human-Computer Interaction, 3rd Edition. Hoboken, NJ: Wiley.

Shlaer, Sally, and Stephen Mellor. 1992. Object Lifecycles: Modeling the World in States. New York: Yourdon Press.

Shlaer, Sally, and Stephen Mellor. 1988. Object-Oriented Systems Analysis, Modeling the World in Data. Upper Saddle River, NJ: Prentice Hall.

Silverstein, David, Philip Samuel, and Neil DeCarlo. 2012. The Innovator’s Toolkit: 50+ Techniques for Predictable and Sustainable Organic Growth. Hoboken, NJ: Wiley.

Simsion, Graeme, and Graham Witt. 2004. Data Modeling Essentials. San Francisco: Morgan Kaufmann.

Sinek, Simon. Start With Why. 2011. New York: Penguin.

Snyder, Carolyn. 2003. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. San Francisco: Morgan Kaufmann.

Sommerville, Ian, and Pete Sawyer. 1998. Requirements Engineering: A Good Practice Guide. Hoboken, NJ: Wiley.

Spolsky, Joel. 2004. Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity. New York: Apress.

Sullivan, Wendy, and Judy Rees. 2008. Clean Language: Revealing Metaphors and Opening Minds. Rocky Hill, CT: Crown House Publishing.

Tockey, Steve. 2004. Return on Software: Maximizing the Return on Your Software Investment. Boston: Addison-Wesley.

Trompenaars, Fons, and Charles Hampden-Turner. 2015. Riding the Waves of Culture, Understanding Diversity in Global Business, 3rd Edition. London: Brealey Publishing.

Tufte, Edward. 2010. The Visual Display of Quantitative Information, Second Edition. Cheshire, CT: Graphics Press.

Van Der Pijl, Patrick, Justin Lokitz, Lisa Kay Solomon, and Erik Van Der Pluijm. Design a Better Business: New Tools, Skills, and Mindset for Strategy and Innovation. Hoboken, NJ: Wiley.

van Lamsweerde, Axel. 2009. Requirements Engineering: From System Goals to UML Models to Software Specifications. Hoboken, NJ: Wiley.

Von Oech, Roger. 2008. A Whack on the Side of the Head: How You Can be More Creative. New York: Grand Central Publishing.

Weske, Mathias. 2024. Business Process Management: Concepts, Languages, Architectures, Fourth Edition. New York: Springer.

Wiegers, Karl. 2021. The Thoughtless Design of Everyday Things. Plantation, FL: J. Ross Publishing.

Wiegers, Karl. 2007. Practical Project Initiation: A Handbook with Tools. Redmond, WA: Microsoft Press.

Wiegers, Karl, and Candase Hokanson. 2023. Software Requirements Essentials: Core Practices for Successful Business Analysis. Boston: Addison-Wesley.

Wiegers, Karl, and Joy Beatty. 2013. Software Requirements, Third Edition. Redmond, WA: Microsoft Press.

Wiley, Bill. 1999. Essential System Requirements: A Practical Guide to Event-Driven Methods. Reading, MA: Addison-Wesley.

Winter, Helen. 2023. The Business Analysis Handbook: Techniques and Questions to Deliver Better Business Outcomes. London: Kogan Page.

Zaki Warfel, Todd. 2009. Prototyping: A Practitioner’s Guide. New York: Rosenfeld Media.

Index

A

abstraction, 177, 178, 243, 255, 359, 373

acceptance criteria

authors of, 352

as clear and binary, 349

GWT (Given/When/Then), 349–352

timing of writing, 352

viability via fulfilling, 421

access, 302–303, 553

accessibility, 540–541

achievable goals, 45

action learning, 260–261

activity diagrams, 233, 237, 365

adaptation of ready-made solutions, 388

adjacent systems

and business events, 76, 78, 91, 222

customer segments as, 224

data flow to/from, 63

defined, 54

influence of, 48, 55

Adobe Lightroom, 295

advantages

in goal statements, 28–30, 43–44, 502

purpose-advantage-measurement, 43–44, 154

and value, 34

agile development

business analysis and, 1

personas for, 71

prevalence of, xxxi

and Project Blastoff, 107–108

Scrum, 11, 17, 61

and the Volere method, 11–12, 17, 451–452

AI (artificial intelligence), 2, 16, 475–480

Alexander, Christopher, 318

Alexander, Ian, 58, 218

alignment models, 387

alternatives, 215–216, 429

Amazon, 11, 51, 98, 142, 149, 294

ambiguity, 282–283, 419

appearance, intentional, 291–293

apprenticing, 254–255

approval voting, 93

architecture, 370–371, 589

archiving, 304

assumptions, 103, 485, 516–519, 584

Atlantic Systems Guild, 97

atomic requirements, 272, 396, 402–403, 417, 492, 532, 581, 585

attributes, data, 244, 245

auditing, 302, 305, 555

automation, 365–372, 441

availability, 302, 544

B

Babbage, Charles, 4

BABOK (Business Analysis Body of Knowledge) Guide, xxix

background, project, 500

backlogs, product, 61, 399

backups, 304

Bain & Company, 38

benchmarks, 318, 337, 349

beneficiaries, 62, 402

benefits, 4, 402, 461, 483

Bezos, Jeff, 98

blame, 489

Blastoff. See Project Blastoff

blue zone, 491

de Bono, Edward, 148

boundary, product, 528–529, 593

brainstorming, 486, 487, 490

Brennan, Kevin, xxx

Brown Cow model, 195–200, 258, 267, 359

budget, 23, 514

business analysis/analysts

acceptance criteria written by, 352

agile and serial, xxxi–xxxii, 1, 451–452

AI use in, 477, 479

Brown Cow model for, 360

and business case development, 101–106

common language for, 452–453

and customer prioritization, 73

in early days planning, 461

essence as understood via, 373

innovation by, 141, 485

need identification via, 6

planning/priorities for, 93–94

prototyping by, 113, 121

requirements discovery by, 3

responsibilities of, 61

role of, 4

solution identification via, 2

systems thinking by, 467, 472

tips for successful, 453–457

trawling as/by, 174

and UX design, 374–376

business case development, 107

business ecosystem, 48–50, 54, 76

business events

completeness checks for, 430–431, 435

conditional, 81, 187

in context diagram, 138–139

and data conservation, 81–82

and data modeling, 248–250

defined, 75, 77–78, 189–190, 581–582

estimating effort for, 89–91

external, 80, 187

finding, 82–84

GWT (Given/When/Then) for, 350

importance of, 82

as independent, 345

list of, 75, 521–523

mission-critical, 387

prioritization of, 87–93, 190, 403–405

and process modeling, 236–238

ready-made solutions for, 84–85, 135

requirements discovery via, 75

requirements specification and, 396–397

responses to, 77–80, 187, 190–191, 392

and scope of ready-mades, 383–386

stories of, 221–230, 339–341, 349–351, 399–401

time-triggered, 80–81, 187, 188

users and, 376

business process, 365, 369

Business Process Model and Notation (BPMN), 232

business rules, 258–259, 478, 516–519

business use cases (BUCs)

business rules and, 259

case development, 101–106

defined, 79, 167, 583

desired future of, 192–193

effort for, 89–90

and non-functional requirements, 309–311

and process modeling, 236–238

prototyping and, 193

as response to event, 187, 272, 521

specifying, 523–534

systems thinking about, 133–135

time-triggered, 211–212

trawling for, 190–192

workshops on, 201–203

Butterfly Effect, 471–472

C

calls to action, 206

Capron, John, 481

cardboard box prototyping, 128

cardinality, 246

change

anticipating, 452

charter to change zone, 50–52

inviting, 209

managing, 443–446

as an opportunity, 25

problems resulting from, 25

and product review, 368

of requirements, 482

choice, intentional, 215–216

clarity, 5–6

classes of data, 432, 580–593

clients, 312–313, 503

collaboration, 510

combinations, novel, 150

commercial off-the-shelf (COTS) solutions, 85

commercial projects, 14–16

community participation, 142

community value, 39

completeness checks, 417–418, 429–436

complexity, 57

compliance requirements, 287, 288, 289, 308–309, 332–333, 337, 386, 407, 558–559

computers, 373, 475

conditional requirements, 282

confidentiality, 302

configuration of solutions, 134, 137, 139, 272, 379, 385, 387, 538

connectedness, 48, 144–145, 467–474

conservation, data, 81–82

constraints

constraint requirement, 583–584

defined, 174, 499

on design, 370

fit criteria for solutions, 336–337

removing, 148–149

and requirement viability, 421

types of, 508–515

consultants, 62

context diagrams

to assess ready-mades, 137, 381

of the business ecosystem, 49

of business events, 76–77, 83, 222

and data modeling, 249

for project scope, 45, 46, 53–57, 414

scope of work in, 76–77, 392

systems thinking for, 470, 471

convenience, 142–144, 541

“coolness,” 324–325, 424

Cooper, Alan, 69

corrections, 26

cost

budgets, 23, 514

of building requirements, 421

and early days planning, 459–462

estimate inputs, 104–105

and project launch, 100

and scope creep, 425

in Volere template, 569–570

creating data, 250–251, 434–435

creativity, 141–151, 261–262, 451, 485, 486

criteria

acceptance criteria, 349–353

fit criteria and rationale, 317–338

CRUD (Create Read Update Delete) check, 250–251, 434–435

cultural requirements, 101, 287, 288, 306–308, 332, 386, 556–557

culture

of blame, 481, 489

cultural viability, 101

culture drivers, 463

innovative, 485, 488, 490

of teams, 464

customers

analyzing experience of, 264–266

and business events, 77–80

changing attitudes of, 7

connectedness of, 144

identifying values of, 5, 33–39

influencing behavior of, 50–51

participation by, 142

personas of, 68–71, 405–406

prioritization of, 67, 71–73

prototyping for/with, 123, 158

as purchasers, 39, 60, 65

satisfied/dissatisfied, 3–4, 423

segments of, 65–73, 76, 224, 341–342

solutions proposed by, 261

as sponsors, 60

as stakeholders, 58–60, 503

trawling by/with, 191

as users, 38, 60, 65

customized solutions, 134, 137, 139, 379, 385, 387

D

damage risk, 298

data

data conservation, 81–82

data flow diagrams, 234–236

data mining, 478

data models, 243–248, 524–526

defining, 335, 431–433

to find missing connections, 472

fit criteria and, 334–335

information gathering, 145–146

processing of, 373

in solution space, 375

triggering data flows, 79, 82–84, 190, 211–212

as ubiquitous, 243

data dictionaries, 335, 420, 524–528, 586

data in-process-data out principle, 54

decision-making, 145–146, 374

deletions, 250–251, 434–435

Deming, W. Edwards, 457

democracy, 489–490

description of requirements

fit criteria and, 337–338, 419

for functional requirements, 281, 285

on snow card, 278

Design the Business Solution

for agile projects, 12

and architecture, 371

automation boundaries in, 365–372

business solutions, 359–364

for commercial projects, 15, 16

in goal statements, 357

for information/functionality, 373–377

innovation in, 487

physicality in, 373

prototyping and, 170

requirements implemented via, 357

and scope of problem, 364

tips for successful, 455–456

for “useful, usable, used,” 371–372

for user experience, 374–376

using ready-made components, 379–390

in the Volere process, 10, 355–357

detailed tasks, 402–403

Develop a Solution

for commercial projects, 16

prototyping and, 170

tips for successful, 456–457

differentiation, 387–388

disguised problems, 182–183

diversity and inclusion requirements, 557

document archaeology, 262–264

documentation, 455, 570–571

double-loop learning, 161–162, 164

E

early days, xxxii, 459–462

ease of use requirements, 537–538

easy-to-use products, 294

economic feasibility, 161–164

ecosystem, business

adjacent systems in, 48, 54, 63

assessing prototypes in, 159–160

principles of, 48–50

work done within, 76–77

Edison, Thomas, 150, 261, 488

effectiveness, 482

Einstein, Albert, 164, 178

elastic users, 69

elevator pitches, 127

employees, solutions for, 38

enterprise architecture, 370, 371

environmental benefits, 39

environmental requirements, 287, 288, 299–300, 330–331, 512, 547–551

errors

data conservation errors, 82

reducing, 47

essence of the problem, 177–185, 199, 212, 214, 359, 365, 373

estimable stories, 346

ethnography, 253

evolutionary design, 367–368

evolutionary prototypes, 171–172

excellence, 464

exceptions, 216–217, 429

experience, user, 374–376

exploring candidates, 157–164

external influences, 470–471

F

facilitation of workshops, 204

facts/assumptions, 584

failure, 261, 326, 459–462

family therapy, 253

fault-tolerance requirements, 545

feasibility, 154, 161–164

feedback

between developers/analysts, 16

during interviews, 256

in Volere method, 10

feel-good solutions, 146–147

feel/look requirements, 287, 288, 289, 291–293, 327–328, 535

fit criteria

description vs., 337

finding the, 322–323

for functional requirements, 280, 333–336

as measurable benchmarks, 318–320

for non-functional requirements, 290, 324–333

for project purpose, 336

and rationale, 320–322

scale of measurement, 323

for solution constraints, 336–337

for stories, 333

See also measurements

flexibility, 16, 253, 451

Flyvbjerg, Bent, 11, 461

fork mode, 237

Franklin, Benjamin, 469

free solutions, 38

functionality

from abstract to physical, 373

of candidate solutions, 156–157, 225

deciding on a solution’s, 273–275

designing, 373–377

of functional requirements, 173, 271

functional stories, 401–403

as “I can” story, 342

of non-functional requirements, 173–174

of ready-made solutions, 379

trawling for appropriate, 173–174

in user experience, 374–376

functional requirements

avoiding ambiguity for, 282–283

in completeness checks, 429

conditional, 282

and customer values, 35–36

defined, 499, 585

finding, 272–273

fit criteria for, 333–336

functionality decisions, 273–275

granularity of, 281

grouping, 284

for ready-made products, 284

snow card for, 278–280

technology of/for, 281

test cases for, 336

trawling for, 173

in the Volere template, 532–534

writing of, 275–277

Future-How model, 198, 267

future planning, 147–148, 197–198

Future-What model, 197–198, 212, 237, 267

G

GDPR (General Data Protection Regulation), 26

goals

achievable, 45

examining, 42

goals-scope-stakeholders trinity, 41–64

of the project, 501–502, 588

and project launch, 98

purpose-advantage-measuring of, 43–44, 154, 502

statements, elements of, 28–30

types of, 502

zones of influence in, 50–52

goals-scope-stakeholders trinity, 41–64, 97

von Goethe, Johann Wolfgang, 117

gold plating, 423–424

granularity, 209, 276, 277, 281, 352

graphical pictures, 260–261

guard conditions, 238

guardians, repository, 426

GWT (Given/When/Then), 349–352

H

hi-fi prototypes, 129

high-level requirements, 396

high-level stories, 221

hiring, 463–464

hostile stakeholders, 63

How-Now model, 195–197, 210, 212, 213, 237, 240, 258, 267

human activity/work, 365–367

human behavior, 463–466

humanity requirements, 287, 288, 293–297, 328, 536–542

I

ideas, 116, 117, 490, 572–573

IDEO process, 486

immunity, security and, 304, 556

implementation, 510

implementation units, 440, 586

improvement, 483

incomplete ideas, 490

independent events, 345

influence, zones of, 50–52, 78

information

computer vs. human processing of, 373

gathering, 145–146

learning as you go, 481–484

in Requirements Knowledge Model, 439

RFI (request for information), 380

in story maps, 405

in user experience, 374–376

inherited requirements, 407

initiatives. See projects

innovation, 141–151, 361, 477, 485–493

integrity, 302, 304, 554

intentional appearance, 291–293

interconnectedness, 48, 144–145, 467–474

internalization requirements, 538

interviewing, 255–258

INVEST (independent, negotiable, valuable, estimable, small, testable), 345–346

iPhones, 116, 485, 488, 491

iterative design

and development, 367–368, 457

iteration planning, 346

of requirements specification, 398

of story maps, 408

IT systems, 49

ITT (invitation to tender), 380

J

Jobs, Steve, 116, 355

job shadowing, 254

join mode, 238

journey maps, 264–266

K

Kaiser, Henry J., 25

Kanban boards, 441–443

knowledge, value of, 464–465, 481

knowledge classes, Volere, 580–593

L

language, common, 420, 452–453

lateral thinking, 148

launching projects, 97–110

laws, 258–259, 308–309

lawyers, 63

learning, 481–484, 539

less is more, 143

likability, 324–325

Lincoln, Abraham, 25, 178

linear/serial projects, 12–13, 17, 451–452

listening, 253, 258

longevity, 547

look and feel requirements, 287, 288, 289, 291–293, 327–328, 535

Lorenz, Edward Norton, 471

low-fidelity prototypes, 119–122

low-level requirements, 396

M

machine learning (ML), 477

maintainability, 287, 300–302, 331, 455, 508, 551–553

managers/managing

of changes, 445

of people, 451

of products/programs, 62

of requirements, 437–447

of stakeholders, 575–577

manual activities, 365

maps, 61, 124–125

market impact, 92

marketing/sales, 63

Mastering the Requirements Process, xxix, xxx, xxxii

McDonald, Kent, 387

McMenamin, Steve, 119, 133

measurements

fit criteria as, 317–338

in goal statements, 28–30, 43–44

for precise requirements, 317–318

purpose-advantage-measurement, 43–44, 154

of real rationale, 321

scale of, 323

of solutions, 28

of success, 43

of values, 42

See also fit criteria

mental models, 374, 375

migration to new products, 566–568

milspec specification, 12–14

mind maps, 124–125

Mini Blastoffs, 108, 388

minimum viable product (MVP), 91, 408, 444

mining data, 478

missing connections, 472

misuse scenarios, 218

models of process, 125–126, 163, 524–526

modification of solutions, 272

motivation, 501

multiple ideas, 115–118, 164

multiplicity, 246

MuSCoW prioritization, 92, 408, 423

N

naming conventions, 420, 452–453, 515–516, 586

natural language processing (NLP), 477

needs, customer

and customer segmentation, 66

identifying, 6

satisfying, 3–4

stories about, 230

trawling to discover, 173–174, 454–455

negative impact, 133

negative scenarios, 218

negotiable business events, 346

neobanks, 142, 168

Nightingale, Florence, 24, 25

non-functional requirements

acceptance/rejection via, 406

architecture and, 371

in completeness checks, 429

and customer values, 36

defined, 499, 586–587

finding, 309–313

fit criteria for, 324–333

as inherited, 407

overview of, 535–559

produce use cases and, 289–290

requirements vs. solutions, 313–314

and scoring of ready-mades, 386

in story maps, 406–408

trawling for, 173–174

types of, 287–289, 290–309

O

observation, 254, 486

obstacles, 66

off-the-shelf (OTS) solutions

constraints of, 511

defined, 85

designing, 379–390

See also ready-made solutions

onion diagrams, 58

open issues, 560–561

open-source solutions, 38, 85, 379

operational requirements, 287, 288, 299–300, 330–331, 547–551

operations manual, 274

opportunities

problems as, 25

window of opportunity, 106

options, project, 104, 106

organizations

building, 38

customer experience of, 264–266

enterprise constraints, 514

internal laws of, 258–259

learning of, 444

lessons learned by, 483

maturity of, 421

modifying, 101

reorganizing, 388–389

staff of, 463–466

outcomes

business solutions for, 360–363

designing for appropriate, 359

desired, 80, 98, 157–158, 361

in scenarios, 215

scoring of ready-mades for, 386–387

workshops focused on, 201–202

outputs, 202–203

P

pain points, 66, 182

participation, 142

partnerships, 510

Patton, Jeff, 399

Pauling, Linus, 115

Peña, William, 278

people, 463–466

performance requirements, 297–299, 319, 329–330, 542–547

personalization, 538

personas, customer, 68–71, 506–507

Pfleeger, Charles, 305

Pfleeger, Shari Lawrence, 302

physical devices, 196

planning

in the early days, 460

of projects, 565–566

via “think slow, act fast,” 11

politeness, 540

precision/accuracy requirements, 544

presumptions

about the problem/situation, 27

about solutions, 19–20, 25, 47, 52

prioritization

of business events, 87–93, 190, 403–405

of customers, 67, 71–73

of detailed tasks, 403

of story maps, 408–410

privacy, 26, 289, 302, 303–304, 554

probing candidates/prototypes, 153–157

problems

and business case development, 102

change as source of, 25

and customer values, 33–39

defined, 3, 25

disguised, 182–183

essence of, 177–185, 212

exploration of, 12, 115

goal statements and, 28–30

new, 563–565

in Project Blastoff, 20

prototypes to explore, 123

referred pain from, 182

requirements specification and, 396–397

root causes of, 27

scope of, 45, 46, 364, 380

solutions to real, 9, 25–26, 30, 33

solving the right, 156, 161, 177–179, 359

systemic, 27

understanding, 9, 23–31, 33–39, 50, 52

problem space

assessing the, 26

Brown Cow model of, 195–196

complexity of, 57

context diagram of, 46, 49, 53–57

defined, 45

ecosystem surrounding, 48

examining entire, 371

goals-scope-stakeholders and, 41

graphical pictures of, 260–261

prototyping to explore, 12, 111–113, 153

scope of, 45, 47, 50, 383–384

trawling through, 173

work done in, 75–77

process

with AI, 475, 478–480

business process, 365, 369

common language for, 452–453

context diagram of, 54

data and, 243

IDEO process, 486

serial or agile, 451

of the Volere method, 453–457

process models

accommodating ready-mades, 390

of business use cases, 193

and double-loop learning, 163

functional requirements on, 277

interviews using, 256

notation for, 231, 232, 234

prototyping with, 125–126

requirements discovery via, 232

when to use, 238–240

during work, 254

product development

appropriate, 19

backlog of stories for, 61

and client expectations, 312–313

design decisions and, 357

early days planning, 459–462

instructions for, 269–270

iterative/evolutionary, 361, 367, 444

planning of, 566

rationale for, 322

requirements for ready-made, 284

and scope creep, 424–426

specifications for, 272

time of, 92

tips for successful, 456–457

writing requirements for, 271–285

products

backlog of, 399

migration to new, 566–568

owners of, 61

product boundaries, 273, 528–529, 593

scope of, 528–532

Project Blastoff

for agile projects, 11

and business events, 75–86

for commercial projects, 14, 15

customer segmentation for, 65–73

customer value identification, 33–39

determining usefulness in, 372

goals-scope-stakeholders trinity in, 41–64

Mini Blastoffs, 108, 388

prioritizing business events, 87–95

problem identification in, 23–31

purpose of, 20, 21

scope of work in, 356

for specification-led projects, 13

tips for successful, 453–454

in Volere method, 10

when to launch, 97–110

without preconceptions, 19–20

projects

acceptance criteria timing in, 352

agile, 11–12

big, 460–461

dead fish projects, 97

drivers of, 499

early days of, xxxii, 459–462, 481

effect of scope creep on, 424–426

establishing trajectories of, 21

failure of, 459–462

goals-scope-stakeholders trinity for, 41

issues with, 560–561

lessons learned on, 481

planning of, 565

project issues, 499

purpose of, 336, 500–502

scope of, 14

specification-led, 12–14

sponsors of, 60

timing of, 97–110, 459, 465

prompt engineering, 479–480

proofs-of-concepts, 444

Prototype for Requirements

for agile projects, 12

atomic requirements, 492

for commercial projects, 15

creative innovation via, 141–151, 485

exploring problems via, 111–113

functionality determined by, 271

probing/exploring candidates, 152–165

process models with, 239–240

prototypes as specifications, 167–172

with ready-made solutions, 131–140

sacrificial prototypes, 112–113, 115–118, 356

tips for successful, 454

trawling and, 174

types of prototypes, 119–130

in Volere method, 10, 112

prototypes

for automation boundaries, 368–370

building multiple, 43

and business use cases, 193

change avoided via, 444

and non-functional requirements, 311–312

options for using/losing, 170

personas for, 71

rapid, xxxi, 2, 11, 486, 487

sacrificial, 112–113, 115–118, 153, 171, 356

testing, 12

types of, 119–130

psychological values, 36–37

PUC (product use case), 274, 275, 284, 289, 529–532, 587

purpose

early days establishment of, 460

fit criteria for project purpose, 336

in goal statements, 28–30, 43–44

purpose-advantage-measurement, 43–44, 154, 502

in Volere template, 500–502

Q

qualitative values, 42

quality checks, 413–427

quality standards, 441

quality thinking, 417

quantitative values, 42, 318

R

rationale for requirements

defined, 295, 320, 322

finding the real, 320–322

fit criteria and, 317–338

project scope and, 415

on the snow card, 278–280

as “so that,” 319

and value of knowledge, 465

reading data, 250–251, 434–435

ready-made solutions

adaptation of, 388

and business events, 84–85, 138–139

choosing the best, 383–390

for commercial projects, 15

constraints of, 511

designing, 136–138, 356, 379–390

impact of, 133–135

prevalence of, xxxi, 2

and project launch, 101

prototyping with, 131–140

requests for proposal (RFPs) of, 379–383

requirements for, 284, 561–562

scenarios with, 208–209

trawling for, 454

recipients of value, 37–39, 62

recovery, 304

referred pain, 182

refining ideas, 486, 487

regulators, 63

relationships

data, 243, 244, 433, 579–594

as a knowledge class, 590–593

relevancy, 415–417

relevant facts, 516–517

reliability, 544

repository, requirements. See requirements repository

request for proposal (RFP), 379–383, 454

requirements

attributes of, 278

clear communication of, 269–270

conditional, 282

designing to fulfill, 361–362

fit criteria and rationale for, 317–338, 419

functional, 173, 271–285

goals as, 63

implementing, 357

innovative, 485–493

Knowledge Model for, 579–594

lessons learned from, 482–483

managing, 437–447

“and no more,” 305

non-functional, 36, 173–174, 287–315

ready-made solutions for, 385

recording of, 5

solutions vs., 313–314, 422

specifications, 395–398, 417

stakeholders as source of, 57–58, 63

testing. See testing requirements

tools, 393–394

traceable, 437–441

tracking of, 441–443

types of, 173–174, 499

values of, 423

waiting room for, 572

writing the, 271–285

requirements discovery

with AI, 475–478

via business events, 75

changes in, xxxi

classes of knowledge in, 580

creativity in, 492

and customer persona, 69–70

and customer values, 33, 39

defined, 3

focus on, 227

of functional solutions, 272

fundamental principles of, 3–7

IDEO process and, 487

necessity for, 1

organization learned via, 444

with process models, 232

via prototyping, 111–113

requirements repository and, 392

and solution development, 456–457

to solve the right problem, 177–179

via stories, 229

via trawling, 173–174

via “why?,” 180–181

without “users,” 221

Requirements Knowledge Model, 223, 274, 392, 393, 439, 498, 579–594

requirements repository

and completeness checks, 429–436

as dynamic storage, 391

guardians of, 426

physical incarnation of, 393

purpose of, 391, 455

and quality thinking, 413–427

of requirements specification, 395–398

story maps as, 399–412

in the Volere process, 11, 356

Requirements Specification Template, 14, 495–573

responsiveness, 77–80, 145

revenue, 73, 91

reverse engineering, 199

review, 368

RFI (request for information), 380

rich pictures, 260–261

ripple effects, 469–470

risk, 92, 98–100, 103, 298, 459, 465, 488, 568–569

ROI (return on investment), 105

S

Saarinen, Eero, 371

sacrificial prototypes, 112–113, 115–118, 153, 164, 171–172, 356

safe-to-fail probes, 153, 162

safety

blame vs., 489

innovation and, 488

safety-critical requirements, 543

and security, 287, 288, 302–306, 386

standards of, 441

scalability, 546

scenarios

alternatives in, 215–216

for business use cases, 207

completeness checks of, 429–430

essence of the business, 212–215

exceptions to, 216–217

how to craft, 207–212

interviews using, 256

negative, 218

prototypes via, 126–127

in workshops, 202–203

writing requirements via, 275–277

scheduling, 513

scope

and the business ecosystem, 48–50

of business event stories, 223

context diagrams for, 45–46, 53–57

and early days planning, 460

goals-scope-stakeholders trinity, 41–64

of problems, 25–27, 45, 107, 383–384

of the product, 14, 528–532

scope creep, 414, 424–426, 482

of solutions, 357, 588

testing requirements within, 413–415

well-defined, 454

of work, 76–77, 356, 519–524, 590

zones of influence, 50–52

scoring techniques, 386–387

Scrum, 11, 17, 61

security, 287, 288, 302–306, 386, 553–556

segmentation, customer, 65–73, 76, 224, 341–342

self-confidence, 464, 481

self-referential users, 69

serial projects, 12–13, 17, 451–452

service technicians, 508

sketched prototypes, xxxi, 2, 11, 119–122, 406

skunkworks, 489–490

slogans, 127

small stories, 346

snow cards, 278–280, 417–418, 500, 501

Snowden, Dave, 153

soft sciences, 253

software development

and design, 355

purpose of, 5

requirements for, 270, 271, 359

and risk of damage, 298

vs. solutions, 16, 23, 42

and support, 145

and Volere method, xxx

solution architecture, 370, 371

solutions

adding automation to, 365–372

AI use in, 16, 478–479

architecture of, 371

business solutions, 359–364

constraints for, 336–337, 509–510

as customer benefits, 4

and customer segmentation, 65, 67

and customer values, 33–39

data storage in, 375

defined, 3

designing. See Design the Business Solution

desired, 374, 387, 426

free, 38

functionality of, 271, 273–275

as the goal, 28–30, 42

ideas for, 572–573

identifying appropriate, 2, 3–4, 365

impact of, 28, 133–135

incremental, 171, 172

innovative, 141–151, 486

inviting proposals of, 379–383

maintaining, 455

orderly development of, 6, 9

as physical realities, 359, 365, 373

presumptions about, 19–20, 24, 25, 27, 47, 52, 199, 228, 320, 339, 461

prototypes as proposed, 111, 115–118, 138

providing the best, 11, 23, 177–179

ready-made. See ready-made solutions

requirements specification and, 396–397

requirements vs., 313–314, 422

to the right problem, 156, 212

scope of, 45–46, 357, 588

software development for, 5, 414

sponsors of, 60

stories about, 222

user ignorance of, 261

“so that”/rationale, 341, 343–345

See also rationale for requirements

specifications

complete, 12–13

functional requirements describing, 272

grouping requirements in, 284

prototypes as, 167–172

repository of, 395

specification-led projects, 12–14

structure of, 396–398

Volere Requirements Specification Template, 495–573, 594

speed and latency, 147, 542

Spolsky, Joel, 357

sponsoring organizations, 38, 60

stakeholders

approval voting by, 93

customers as, 58–60

examples of, 58–63

goals-scope-stakeholders trinity, 41–64

interviewing, 255

as a knowledge class, 589

lessons learned from, 482

map of, 58, 59, 575

prototyping with, 113, 121

requirements as driven by, 57–58

scenario work with, 211

templates for managing, 575–577

types of, 503–508

at workshops, 203

standards, 309, 327, 441, 559

status of requirements, 441–443

storage

of data, 81–82, 243–252, 432

of requirements, 5, 11, 391

See also requirements repository

stories

acceptance criteria and, 349–352

AI for preliminary, 477

backlog of, 61

of business events, 221–230, 349–351, 399–401, 582

fit criteria for, 333

format of, 223–230

functional, 401–402, 585

INVEST test for, 345–346

for non-functional requirements, 346–347

properties of good, 341–345

“so that”/rationale in, 319

story maps, 61, 399–412

trawling via, 221–230

without presumed solutions, 228, 229

writing good, 339–348

writing requirements and, 3, 270

storyboards, 122–123, 155

style requirements, 536

success

acceptance criteria for, 349

via appropriate solutions, 363

assessing likelihood of, 98–101

via failure, 261

measuring, 43

recording your, 483

via the Volere method, 453–457

for workshops, 203–206

suitable solutions, 132–133

support, 287, 300–302, 331, 551–553

swimlanes, 237

systemic problems, 27

systems thinking, 133, 134, 253, 467–474

T

tasks, detailed, 402–403, 584

teamwork, 451, 464

technical viability, 101

technology

reverse engineering from, 180

technical skills needed, 421

technological fossils, 181

technological requirements, 281, 589

terminology, consistent, 420, 452–453, 515–516, 586

testing requirements

before building, 413

for completeness, 417–418

for consistent terminology, 420

to ensure fit, 7, 419–420

via fit criterion, 499

quality thinking for, 413

rationale and, 322

for relevancy, 415–417

within scope, 413–415

subjective tests, 326–327

testable requirements, 270, 346, 351

test cases for, 336

and traceability, 438

for value, 423

for viability, 421–422

thought

organizing, 124–125

quality thinking, 413–427

systems thinking, 133, 134, 253, 467–474

time, value of, 465–466

timing, 459, 465–466, 513

traceability, 437–441

tracking requirements, 437, 441–443

transparency, 437

Trawl for Requirements

for agile projects, 12

alternate tools for, 253–268

with Brown Cow model, 195–200, 267

and business use cases, 187–194

for commercial projects, 15

flexibility during, 253

functionality determined by, 271

process models to, 231–241

prototyping and, 111–112, 170, 174

with scenarios, 207–219

for specification-led projects, 13, 14

and stored data, 243–252

via stories, 221–230

tips for successful, 454–455

in Volere method, 10

via workshops, 201–206

triggering data flow, 79, 190, 211–212

tripwires, 100

U

understandability, 540

Unified Modeling Language (UML), 232, 233, 243

updating data, 250–251, 434–435

usability requirements, 287, 288, 293–297, 328, 386, 536–542

“useful, usable, used,” 371–372

user manuals, 263

users

abilities of, 293

analyzing experience of, 264–266

apprenticing with, 254

customers as, 38, 60

documentation of, 570–571

experience of, 374–376

mental models of, 374, 375

personas of, 68–71, 506–507

prototyping for, 158

self-referential, 69

as stakeholders, 505–508

in story maps, 405

training, 571

viability determined by, 421

V

validating/verifying

of requirements, 427, 438

of specifications, 13, 14

value propositions, 103

value(s)

as advantages, 34

assessing prototypes for, 160–161

of customer segments, 72

functional, 35–36

goals as demonstrating, 42

identifying customer, 5, 33–39

innovation and, 485

to the organization, 72, 91, 103

people as assets, 463–464

as prioritization criterion, 408

psychological, 36–37

recipients of, 37–39

of requirements, 423

in stories, 346

of time, 465–466

value statements, 35

viability, 101, 421–422

video walk-throughs, 128

visibility, 92

visual aids, 205

Volere method

arena of activities, 9–10

blastoffs in, 10, 21

class diagram of, 393

defined, 7

designing in, 10, 355–357

evolution of, xxxii

flexibility of, 16–17

innovation in, 487

as a process, 6–7, 356, 453–457

prototyping in, 10, 169–171

purpose of, xxx

requirements specification in, 396–397

trawling in, 10, 174

Volere Requirements Knowledge Model, 223, 274, 392, 393, 439, 498, 579–594

Volere Requirements Specification Template, 14, 495–573, 594

voting, approval, 93

W

waiting room, 572

Wake, Bill, 345

waterfall projects, 12–13, 17

websites, 469

What-Now model, 197, 212, 237, 258, 267

“why?” asking, 180–181, 253

wireframes, 119–122, 406

work

apprenticing during, 254

via business events, 75, 77–80, 82–84

defined, 76

improved via lessons learned, 481–484

scope of, 14, 76–77, 392, 519–524, 590

workshops, 201–206, 261–262

writing requirements, 271–285

Z

zones of influence, 50–52, 78