Friday, March 22, 2002

 
Posted by Mike Tarrani 4:28 PM
Tarrani-Zarate Model: Business Requirements. In my 21 March entry I introduced the model, how it evolved and discussed the importance of business imperatives. These are the impetus or driving force behind everything also the flows through the model, with an ultimate purpose of delivering tools to the business that are characterized by reliability, availability and support from IT.

Refer to the illustration and you'll see that before the model's foundation there is one additional layer: business requirements. These requirements are dictated by business imperatives. The requirements flow in two directions:

1. Up, which determines service level objectives, which are performance targets that IT uses to measure how well the business is supported.
2. To application delivery processes, which is either a project to develop a system needed to support business imperatives (or to modify existing systems), or the acquisition of the system/application. Application delivery also encompasses the procurement of third-party services, such as application service providers (ASPs), managed service providers (MSPs) and outsourced services and functions, including IT as a whole.

Doing the right things. Getting requirements right is probably one of the most important activities in IT. This is a two-part process: elicitation and documentation. Within this process is the normal due diligence of peer reviews, review and approval of the documented requirements by not only the source of those requirements (from whom they were elicited), but from the business process owner(s) who are the final authority for whether or not the requirement conforms to business needs, governing policy (see my series on processes in Notes from the Field), and business processes (both "as is" and "to be").

Technical and Business Value. The technical value of requirements is that they are the basis for committing resources (people and money) to develop or acquire the systems and services that support the fulfillment of business imperatives. Poorly defined requirements will at worst result in project cancellation, and at best, tools that do not completely satisfy needs generated by business imperatives.

The business value of requirements is straightforward as well: poorly defined requirements will result in either the delay of the systems and services that comprise tools with which the business employs to satisfy business imperatives, or tools that do not fully address business imperatives.

In both cases there is much at risk, all of which goes back to competitive advantage and shareholder value. These are significant factors that determine whether or not a business will survive (or you have a job). The cost of poor requirements is clearly illustrated in costs of defects, which shows that as the development of a system progresses throughout its life cycle the cost of catching problems in the requirements phase is nominal, yet it increases dramatically in later phases. One of the biggest causes of problems is poor requirements. It's ironic that requirements elicitation and management is too often deemed least important when a project is initiated. To be sure there is much lip service given, but in many organizations the focus is on the development stage. This is why IT often delivers results that are [to put it charitably] less than adequate.

Business Rules. This approach to requirements has been repeatedly mentioned here and in Notes from the Field. The value of using a business rules approach is discussed in detail in my 10 March entry, so I am not going to rehash it in this entry. I do want to recommend two books, both of which I've recently reviewed on Amazon, and encourage you to carefully investigate this proven approach to requirements:

1. Business Rules and Information Systems: Aligning IT with Business Goals
   Best introductory text on the subject

   This book introduces the concept and mechanics of business rules, and is essential reading for anyone involved in eliciting and writing requirements, or developing specifications. I want to disclose that I am a staunch advocate of business rules, so take this into consideration as you read this review.

   This is one of two books on the subject. The other book, Business Rules Applied by Barbara von Halle, is more suitable for an experienced practitioner or someone responsible for implementing business rules as an enterprise methodology. This book, however, focuses on the basics and addresses topics, such as object orientation and development, that are not found in von Halle's book. Both books are valuable, but to different audiences.

   What I like most about this book is that it painstakingly describes how to define business rules, and how to clearly and unambiguously describe them. Moreover, the approach given in this book employs the object constraint language, which is a part of the unified modeling language (UML) version 1.1. As such it shows how to integrate business rules into use cases, and to develop artifacts that align to organizations that are using UML or the Rational Unified Process, as well as object-oriented frameworks in general.

   My favorite chapters were 3, which is about defining business rules (getting them right) and 5, which covers controlling business rule quality. To me these are the keys to understanding and using business rules, and both chapters were clear and filled with examples. I also liked the appendix, which covered logic - another essential knowledge factor for analysts who are involved in requirements and specifications.

   If you're new to business rules or are exploring them, start here. Even though the von Halle book is better suited to experienced practitioners, I would still recommend this book to members of that audience who are working in object-oriented environments or are using UML. If you are also using UML, do consider also reading Alistair Cockburn's excellent book titled Writing Effective Use Cases because that book is completely consistent with the material in this one.

2. Business Rules Applied
   For experienced practitioners and business rules implementors

   This is one of two books currently in print about business rules, and each book addresses the subject from a different perspective. The other book, Business Rules and Information Systems by Tony Morgan, is a better introduction because it assumes less technical knowledge. This book, however, has unique strengths that the other book doesn't, including:

   1. A comprehensive approach to preparing for and implementing business rules as an enterprise-wide discipline. It accomplishes this by providing a life cycle approach to business rules development through ongoing management.
   2. The implementation approach is provided as a work breakdown structure, which significantly reduces your planning for an enterprise-wide initiative (or a pilot initiative based on a single project).
   3. There is an accompanying web site that provides additional papers, case studies and other materials that enhance the value of the book.

   The introduction to business rules and concepts is perhaps too verbose, but is thorough. What this part of the book lacks in sparkling prose it more than compensates in detail. I particularly liked the chapter devoted to business rules methodology, which takes the concepts and applies them in a structured way. Another strong point is that the book provides many examples to reinforce points under discussion, and summarizes key information in easy-to-read tables. The illustrations that are sprinkled throughout the book also add clarity.

   If you're new to business rules the best book, in my opinion, is Morgan's Business Rules and Information Systems. However, after reading that book you'll also want this one if you are serious about implementing business rules because of the way Ms. von Halle has structured the flow and content. Also, the author is one of the pioneers in the business rules community, which adds considerable authority and credibility to her approach.

Next Up. In my next entry I'm going to discuss the impact of business requirements on service level objectives.