RTM’d today: Visual Models for Software Requirements
We are delighted to announce that Visual Models for Software Requirements, by Joy Beatty and Anthony Chen, has shipped to the printer! Hard copies should begin being shipped from our distributor to customers in the next couple weeks.
If you’re a business analyst or product manager who is looking for an effective way to help executives, technical teams, and other stakeholders understand proposed solutions, you’re going to want this book. It describes a simple but comprehensive language of visual models for software requirements called Requirements Modeling Language, or RML, that helps organizations improve the way they elicit, model, and understand what their solutions can and cannot deliver.
You can order the book here or here.
In today’s post, please enjoy the book’s Contents at a Glance and an excerpt from the Introduction.
PART I AN INTRODUCTION TO MODELS
CHAPTER 1 Introduction to RML
CHAPTER 2 Model Categorization
PART II OBJECTIVES MODELS
CHAPTER 3 Business Objectives Model
CHAPTER 4 Objective Chain
CHAPTER 5 Key Performance Indicator Model
CHAPTER 6 Feature Tree
CHAPTER 7 Requirements Mapping Matrix
PART III PEOPLE MODELS
CHAPTER 8 Org Chart
CHAPTER 9 Process Flow
CHAPTER 10 Use Case
CHAPTER 11 Roles and Permissions Matrix
PART IV SYSTEMS MODELS
CHAPTER 12 Ecosystem Map
CHAPTER 13 System Flow
CHAPTER 14 User Interface Flow
CHAPTER 15 Display-Action-Response
CHAPTER 16 Decision Table
CHAPTER 17 Decision Tree
CHAPTER 18 System Interface Table
PART V DATA MODELS
CHAPTER 19 Business Data Diagram
CHAPTER 20 Data Flow Diagram
CHAPTER 21 Data Dictionary
CHAPTER 22 State Table
CHAPTER 23 State Diagram
CHAPTER 24 Report Table
PART VI MODELS IN THE BIG PICTURE
CHAPTER 25 Selecting Models for a Project
CHAPTER 26 Using Models Together
Introduction (excerpt)
Visual requirements models are one of the most effective ways to identify software requirements. They help the analyst to ensure that all stakeholders—including subject matter experts, business stakeholders, executives, and technical teams—understand the proposed solution. Visualization keeps stakeholders interested and engaged, which is key to finding gaps in the requirements. Most importantly, visualization creates a picture of the solution that helps stakeholders understand what the solution will and will not deliver. Despite this fact, many business analysts and product managers continue to create nonvisual requirements using spreadsheets or documents listing thousands of line items. These unwieldy documents are overwhelming, boring to review, and extremely difficult to analyze for missing requirements. Such practices are a symptom of the state of current requirements training, which is often focused on how to write a good requirement rather than how to analyze an entire solution.
This book will help business analysts, product managers, and others in their organizations use visual models to elicit, model, and understand requirements. It describes a simple but comprehensive language of visual models for software requirements called RML (Requirements Modeling Language) that is a collection of best-practice models that have commonly been used in industry in an ad-hoc fashion.
Who Should Read This Book
Although this book is geared primarily toward business analysts and product managers, we think that project managers, developers, architects, and testers will get a tremendous amount of value out of the book because it can help them understand the standard of information that they should be receiving to make their jobs easier. Throughout the book, we commonly refer to the person doing the work as “the analyst,“ because this role has many different titles across organizations. When we refer to “you,“ we are also referring to “the analyst.”
We want to be up front and mention that our experience has primarily been with projects that are geared toward building software that operates within an existing infrastructure, such as internally facing information technology (IT) systems, large-scale consumer-facing software as a service (SaaS) systems, and cloud systems. Although we have used RML on stand-alone (“packaged“) software and embedded systems, those types of projects have not been our primary focus. However, based on our limited experience with these systems, we still think that readers working with those systems will find incredible value in RML, and we look forward to receiving feedback from those readers to improve it.
Assumptions
This book does not cover basic information on requirements; therefore, it assumes that you have existing foundational knowledge about how to write software requirements. It expects that you have a basic understanding of software development processes such as iterative, waterfall, and agile methods, and how requirements fit into those approaches.
Who Should Not Read This Book
If you are just starting out as a business analyst, you should probably read Software Requirements by Karl Wiegers (Microsoft Press, 2003) before reading this book, for an overview of requirements practices. If you are developing shrink-wrapped consumer software, some of the concepts will be useful, but you might find the business orientation distracting. If you are a product manager who focuses on the strategy or marketing aspect of software products rather than on software construction, then this book might not be a good fit, because it heavily emphasizes how to design features for high enduser adoption and satisfaction.
Organization of This Book
We have organized this book so that you can use it as a reference guide. Part I, “An Introduction to Models,” introduces models in general and then goes on to discuss RML and the four classifi cations of models: objectives models, people models, systems models, and data models (OPSD).
Each chapter in Parts II through V covers one RML model and has a consistent layout, including:
■ A story that relates the model to the real world.
■ A definition of the model.
■ The model template.
■ A suggestion of which tools to use to create the model.
■ A fictional example.
■ Explanations of how to create and use the model.
■ An exercise so that you can practice using the model.
The exercise in each chapter is in the context of one sample project that is used throughout all chapters.
Part VI, “Models in the Big Picture,” explains how to select the models and how to use models together to derive requirements.
Appendix A contains two quick lookup models grids as references for how to select models. Appendix B suggests general guidelines for creating models, including metadata for all models and template tips. Appendix C contains the answers to all of the exercises in the book. There is also a Glossary defining the terms that are used throughout the book.
Finding Your Best Starting Point in This Book
You can read the book straight through, but for some people, reading Part VI first might help create context before you delve into the details of each model. The following table provides more guidance.
Models Quick Start
This book contains a tremendous amount of information to absorb about models. The prospect can be overwhelming, so we have developed a way for you to get started with models that uses as few models as possible but still creates significant value for projects. This quick-start method fits most IT-based projects. The following Process Flow provides an overview of this approach.
As shown in the diagram, you start by creating the Process Flows. Next, you create a Requirements Mapping Matrix (RMM) based on the Process Flow steps. Then you create Display-Action-Response (DAR) models for screens and map them against business processes. Finally, you create Data Dictionaries to ensure that all fields are covered and that the validation rules are known.
This leaves out a lot of the value of the other models, but it is a series of steps that can be adopted without major upheaval. The result is that your requirements will be organized by process steps and your screens will also be mapped to process steps to ensure that the key processes are satisfied by the user interface.