- 1 -

INSIGHTS FOR SUCCESS

Six Simple Steps for Accelerating and Perfecting Requirements: A Framework, a New Model, and VisualizationBy Barbara von Halle and Larry Goldberg

(This article assumes knowledge of the Decision Model. If you are not already familiar with the theory of the Decision Model, you

can download a brief primer from www.TheDecisionModel.com.)

Portions of this article are drawn from the book, The Decision Model: A Business Logic Framework Linking Business and

Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis, LLC. This article consists, in part, of

abstracts from the book; directly quoted passages, diagrams, and tables are cited, and are copyright © 2009 Auerbach

Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.

Software engineering is a much younger discipline than are other branches of engineering. We see this in the continuing evolution

of attitudes and approaches to requirements. In early days, there were no requirements. In later days, there were volumes of

approved textual statements. Eventually, there were formal models. Today, sometimes models and statements are merely interim

deliverables because code becomes the requirements.

n the spirit of this evolution, we present a requirements framework and methodology that may be different from what you are

doing. Its three prominent characteristics are a framework, a new model, and visualization. The framework ensures completeness

of all requirements.

The new model is the Decision Model, transforming important business thinking into a tangible and manageable business

requirement. The visualization simulates user scenarios, alleviating the need for abstract specifications or models.

Based on experience, this approach accelerates the productivity and success of a software engineering project. It begins with a

framework.

- 2 -

Six Simple Steps for Accelerating and Perfecting Requirements: A Framework, a New Model, and Visualization

The FrameworkOur approach adopts the Zachman Framework for Enterprise Architecture , which is the foundation for all modern Enterprise

Architecture theory. Thus, it will likely fit into most – if not all – architectures. The Zachman Framework proposes a decomposition

of complex systems, processes, or organizations. As a quick review, it consists of six columns representing the dimensions

which are the interrogatories (What, How, Where, Who, When, Why). It consists of six rows representing the views of target

audiences (Planner, Owner (the “business”), Designer, Builder, Sub-contractor, and Functioning Enterprise). Therefore, there are

36 cells. Each contains content unique to the cell, which ought not to appear in any other cell. So, it is a normalized schema of

decomposition artifacts because it disallows

Using this framework for requirements ensures completeness. Mostly, each cell represents an appropriate model. Each model

corresponds to a particular audience view. Each model connects to other models, along with appropriate metadata.

To keep it simple, we explain the framework and methodology in six simple steps.

Step 1: Validate the completeness of the Project Charter.

Step 2: Confirm the appropriate requirements deliverables within the framework.

Step 3: Become familiar with the kinds of models.

Step 4: Include the new Decision Model.

Step 5: Complete the visualization of the target scope.

Step 6: Repackage and Present a Holistic Requirements Deliverable.

Step 1: Validate the Completeness of the Project Charter Many people overlook this step, but it is the most vital.

To get started, begin in Row 1 in Figure 1, the perspective of the “Planner” of the system, which consists simply of six lists. Using

the project charter as your scope, create the lists referenced in row 1:

List of things (information)

List of business processes

List of locations

List of organizations

List of events/cycles

List of business goals or strategies, and business decisions (more on this later).

If the project charter is unclear about any of these lists, request sponsors to fill in the gaps before proceeding.

- 3 -

Six Simple Steps for Accelerating and Perfecting Requirements: A Framework, a New Model, and Visualization

Step 2: Confirm the Appropriate Requirements Deliverables within the FrameworkUse the framework to identify the kinds of requirements deliverables appropriate for the project. This means moving onto Row

2 because it represents the business audience. For each cell, describe the corresponding deliverable to the level of detail as

prescribed by Zachman. (It is a principle of the framework that there is no difference between the detail in the cells from top to

bottom, but rather a difference of perspective only. In other words it is as important for business requirements to be as detailed

as the technical design is, but for different audiences.)

Many deliverables should be models, each one aimed at a different dimension of the Framework. Figure1 contains a list of useful

deliverables for business requirements.

Figure 1: Useful Deliverables for Business Requirements

Step 3: Become Familiar with the Kinds of Models. When possible, favor models to represent business requirements over textual statements of functional requirements. Accompany

each model with descriptive text.

“Models provide graphical and semantic representations of their target aspects in ways that are easier to view and understand

than are textual statements or narratives. Because each model captures just one aspect of the system, several models, each

orthogonal to the other, provide a sufficiently complete view of the proposed system2 . Therefore, models provide shared

understanding and for assistance in developing related textual requirement statements. In some approaches, a model serves as

input for the automatic generation of the system. This is called Model Driven Architecture (MDA).

There are at least three reasons for modeling each dimension with its own model. First, each model reduces complexity. Second,

each model enables independent change of its dimension from other dimensions. Third, it turns out that a model specifically

tailored to the characteristics of the modeled dimension best represents each dimension. For example, data is best modeled in

diagrams that show the relationship of each data entity to another, where icons represent the data entities and lines represent

data relationships. On the other hand, process flow is best modeled in diagrams that represent flow of process tasks, where

icons represent the process tasks and lines represent process sequence.” (von Halle and Goldberg, 2010)

- 4 -

Six Simple Steps for Accelerating and Perfecting Requirements: A Framework, a New Model, and Visualization

Step 4: Include the New Decision ModelThere are at least two compelling reasons to include the Decision Model as a new requirements deliverable. The first one relates

to how business rules are the forgotten dimension in most requirements. Ken Orr states in the preface to our book, “Indeed,

business rules are perhaps the most important, unresolved problem facing business and IT. A great many organizations are

not so much the masters of their business rules but prisoners of them.” That is because the business rules in those systems

represent is the one dimension we have omitted from requirements, but that we now recognize as something we need to

manage much better. We are unable to do so because we have not had a separate deliverable for them.

The good news is that the Decision Model fills this gap as a stand-alone model just for organizing business rules similar to how

the Relational Model is for data. In a Decision Model, business rules are in their atomic form, governed by 16 principles, including

three forms of normalization.

The inherent structure of business logic in the Decision Model is similar to the inherent structure that Dr. Codd detected in data

almost 40 years ago. This is a very exciting development for requirements practitioners. Further, the Decision Model shares

metadata with, and has connection points to, the other models commonly used in requirements today.

A second, even more compelling reason to include the Decision Model is its potential impact on the business itself. Practice

proves that when business leaders can view their business logic in a tangible, rigorous Decision Model structure, it becomes

a magnet for better business decision-making. This has a profound effect not only on requirements, but also on organizational

maturity and business performance.

It should come as no surprise that most systems, processes, and organizations are driven by decisions defined by logic. Until

now, we did not know how to find them. In our requirements approach, we start looking for them in Step 1 above, creating a list

of them. We deliver models for them in Step 4. Figure 2 depicts the connections of Decision Models to other deliverables.

Figure 2: The Decision Model and Connections to Other Deliverables

- 5 -

Six Simple Steps for Accelerating and Perfecting Requirements: A Framework, a New Model, and Visualization

Step 5: Complete the Visualization of the Target ScopeVisualization is the simulation of important user scenarios of the system. It enables exhaustive examination of business

requirements. Consider completing the visualization before finishing models because it reveals requirements arising from these

interactions. Visualization takes place in three distinct phases, as illustrated in Figure 3. A product for this is Irise.

Figure 3: High Level Phases of Visualization

The first phase is Scenario Ideation. Divide the requirements into a set of scenarios generally grouped around a set of logical

functions. Explore each set of scenarios through steps all scenarios are complete. In some cases, users may decide that there is

no value to creating a high-fidelity simulation, and that an analysis level simulation is sufficient.

During the Scenario Ideation and the Analysis-Level Simulation, participants identify a large number of requirements. A wider

group of participants discovers more when given access to the simulations. This leads to more exhaustive discovery of

requirements that may not have been identified using conventional methods. It also leads to higher levels of adoption of the

product.

The High-Fidelity Simulation delivers a refined deliverable.

- 6 -

Six Simple Steps for Accelerating and Perfecting Requirements: A Framework, a New Model, and Visualization

Step 6: Repackage and Present a Holistic Requirements Deliverable.Upon completion of the visualization and models, organize the requirements document according to the framework, packaged

with the high-fidelity visualization. Deliver a presentation of the requirements, highlighting the key features of the system.

Summary

There is a need to improve the quality of requirements gathered in projects developing software systems for business because a

large proportion of projects fall short or fail due to inaccurate or missing requirements.

The requirements approach in this article combines common practices with visualization and the Decision Model. The most

important parts of this approach are:

Select a requirements framework that represents complex systems or organizations as discrete dimensions.

Use the framework to identify the requirements deliverables for your business audience.

Deliver models for each dimension of your project.

Include the Decision Model for important business thinking behind business decisions.

Adopt a visualization methodology to elicit requirements before completing models

Organize the requirements document according to the framework, packaged with the High-Fidelity Visualization.

- 7 -

Barbara von Halle is co-inventor of the Decision Model and co-author of The

Decision Model: A Business Logic Framework Linking Business and Technology

published by Auerbach Publications/Taylor and Francis LLC 2009.

Larry Goldberg has over thirty years of experience in building technology

based companies on three continents, and in which the focus was rules-based

technologies and applications. Commercial applications in which he played a

primary architectural role include such diverse domains as healthcare, supply chain,

and property & casualty insurance.

Published in: www.modernanalyst.com, May 04, 2010

Contact usFor more information please visit us:

www.sapiensdecision.com

info@sapiensdecision.com

+ 1-800-858-9473 (US)

+ 44 1895 464 000 (UK)

© 2014 Copyright Sapiens International. All Rights Reserved. Dec. 2014

Six Simple Steps for Accelerating and Perfecting Requirements: A Framework, a New Model, and Visualization