Business Analysts Handbook

Integrating Business Analysis Artifacts for Information System Requirements

David Wright

In the domain of Business Analysis, the ‘hard skill’ is writing (or modeling), documenting the Requirements so that they are recorded, communicated, and agreed to; and it is this skill and related techniques that is the least well known of all skills/techniques employed in Information Systems development. This article will be how to document Information System Requirements; other aspects of Business Analysis (gathering, analyzing) will be the subject of another article.

What is an Information System Requirement?

A standard definition of an Information System Requirement does not yet exist. My favourite over time is:

A requirement is a property that is essential for an IT system to perform its functions. Requirements vary (italics added) in intent and in the kinds of properties they represent. They can be functions, constraints, or other properties that must be provided, met, or satisfied so the needs are filled for the system’s intended users (Roger Abbott 1986).

What this definition reminds us is that Information Systems are asked to do many different things; perform calculations, edit and store data, produce reports, support business process, enforce rules, etc. How do you capture business requirements that reflect such potential diversity?

Documenting Information System Requirements

To support their communication and understanding, information system requirements must be documented; this has usually meant they are written down in some way. Given that straight prose writing was always going to be too ambiguous for common understanding, many different structured written formats and diagrams have been used over the decades in best attempts to capture the elusive Information System Requirement. Much energy has been spent over those years by ‘authorities’ and ‘experts’ trying to impress various audiences that their specific format/diagram was the one true way to document requirements; heated arguments often between competing camps as to why ‘my way’ is better than ‘your way’.

This history, combined with the above definition of Information Systems Requirements, supports my thinking that no one format or diagram is sufficient to represent all Information System Requirements. Since information systems can do so many things, it is necessary to recognize that the means of representing the requirements need to vary as well.

Using multiple formats (or ‘artifacts’) to support different types of requirements can lead to overlap and potential redundancy, so it is vital that the multiple artifacts be integrated in such a way that, as a whole, they present one overall view of the Requirements. This integration also provides traceability across the Requirements which can support impact analysis of requirements changes.

So, what should you consider using? In fact, many well-known types that have previously been used independently are good candidates; the set I currently use the most are:

• Declarative Requirement Statements • Use Cases • Data Models • Process Models • Business Rules

Declarative Requirement Statements

An occurrence of this artifact is a direct assertion of a “ that is essential for an IT system to perform its functions.” ; they are ‘declarative’ in that they do not imply any order or flow upon the information system..

The common structure is: “…the System must <specific statement>.”

Variations on this structure include:

• Referring to the ‘Solution’ instead of ‘System’, as an information or other type of ‘System’ is not always what is needed to meet the Requirements of the business. Business Analysis can identify the need for procedure or process change, for instance. • Variations on the verb ‘must’, such as ‘shall’ or ‘will’; a ‘must’ statement is often interpreted as a mandatory requirement, while statements using other verbs mean the requirement is optional or ‘nice-to-have’. If multiple verbs are used in a set of Requirement Statements, the specific meaning of the use of each verb should be clearly defined.

For example:

“The System must provide security that a Manager can view salary data only for their own reporting staff.”

“The System must calculate the monthly payment for a loan application, given the Interest Rate, the Amount Borrowed, and the Number of Payments & Payment Frequency”

Such statements are usually part of a group of Requirement Statements, and can be documented at various levels --- from High-Level Requirements, documented first in a project to assist in scope definition and planning, to detailed statements used as input to Design and as the source of Test Cases.

Gathering these Statements can begin with a simple question to the business asking what they want the expected Information System to do. Their declarative nature focuses the business on ‘what’, steering clear of early assumptions about ‘how’ the system should meet those requirements. If a Business Analyst can document 10 to 25 Statements at the start of a project, the overall Requirements for the system will begin to take shape.

However, one should also expect that the number of Statements will grow as analysis continues, large enough to require some means of organizing them to improve their communication. The most common classification I have seen is functional versus non-functional, with the latter further sub-divided by types such as performance, security, legal, and more. These do tend towards how a system will operate or perform, which is fine, but that will still leave a Business Analyst with many Functional Requirements of what a system must do that need to be organized; can another artifact help?

Use Cases

Let us consider Use Cases, probably the currently best known and widest-used artifact in Information Systems development, both for Analysis/Requirements and Design.

I am a relative new-comer to Use Cases, after working in analysis and requirements through Structured Analysis and Design in the eighties, and Information Engineering in the nineties. I found one author’s description of them almost aesthetically appealing, that each one is a case (or example) of the use of a system.

After that, I have seen many variations and permutations and various ‘uses’ of use cases; either that is a testament to their flexibility, or a condemnation of their vagueness. If you are new to Use Cases, be aware that different flavors of use cases are out there, being promoted and being used. When I am feeling the need for some rigor or consistency, I always go back to Alistair Cockburn (pronounced ‘coburn’) at

Overall, I have seen and used two basic types of use cases:

1. A multiple-step interaction between Actor and System, which relates to user interface design, and capturing the required functionality the system must provide to support the interaction. I saw this a lot when working with co-workers who were OO designers and programmers.

2. A single step or occurrence format, where an Actor initiates the use case, which is provided some input and/or pre-conditions, and it executes a set of actions (calculate something, retrieve or store something else) that produces a result of interest to the Actor. (There may be multiple Actors, too.) The set of actions that are first defined are those that will normally execute, if no exceptions or other variations occur. I call this the ‘happy path’.

However, if it is known that one or more exceptions/variations from the ‘happy path’ could occur (due to certain input values or combinations of pre-conditions), these are documented as alternative paths. Creators of these types of use cases don’t like to see path selection in their use cases, no “IF-THEN-ELSE” statements; use your alternatives instead.

Finally, both of the above types differentiate between the use case itself as the definition or template of the ‘use of the system’, and Scenarios, which are specific instances of the use case given one set of possible input values or pre-conditions; changing the input values produces another scenario, so a large number of scenarios could be defined for one use case, all of which will help the Testers of the information system developed based on the use case(s).

As you might expect by now, I mainly use the second type of use case as part of documenting Information Systems Requirements. They are extremely valuable as a widely-accepted artifact for documenting the results of Analysis; anything that effectively assists in communicating Business Requirements to one or more audiences is something that should be used(!).

Now, they are not perfect, and they are not the ultimate artifact for documenting Requirements… they are only one artifact of many (five at my last count). One issue I had with use cases early on was identifying them in the first place: what was the scope of each use case? How many use cases do you need? There will definitely be more than one. What I can say now is that one way use cases can be identified is by there relationship with Process Models, which I describe later in this article.

However, once you do have a set of use cases defined that cover the scope of the business you are analyzing, you can also use them to organize the Declarative Requirements Statements. As I described earlier, I often start an Analysis effort by creating a list of High-Level Requirement Statements based on initial discussions with the business subject matter experts; if the these people want a new or enhanced system, they will tell you what they want from that system, which you can capture as Declarative Requirement Statements.

Once I have moved ahead to capture the necessarily detailed description of the business in use cases, I allocate those Declarative Requirement Statements to the use cases that will actually support the Requirements (if you end up with Requirements that don’t match up to any of your use cases, you might be missing some use cases.) Detailed analysis will also support the definition of more Requirement Statements, again associated with particular use cases.

It might be argued that the detail provided in a use case supersedes the need for Requirement Statements, but I believe they still play an important role in communicating the essence of the use case; the Requirement Statements are often preferred by Testers as documentation of what they must test, and the Statements provide trace-ability from the Analysis through Design/Development to Testing.

So to this point, we have covered Declarative Requirement Statements and Use Cases, including how the two can be associated with each other… what about the data that is used in a Use Case, especially across many Use Cases for a domain?

Using Data Models for Requirements

Data Models are used to define the data needed for an Information system to use and/or control, and often form the basis for the definition and creation of databases. The most common format used to capture data requirements is the Entity-Relationship Diagram, which was most popularized by James Martin’s and Clive Finkelstein’s Information Engineering Methodology.

A web search on Entity-Relationship Diagrams or on Data Models will return thousands of hits, as I think that Data Models as a requirements artifact rival Use Cases in popularity. Here are two interesting links I found:

1) Data Modeling: Finding the Perfect Fit An Introduction to Data Modeling by Tim McLellan Copyright 1995. All Rights Reserved.

2) Applied Information Science (Data) Modeling Methodologies

In my use of data models for Requirements, the main component is the Data Entity, a subject of interest to the Business, associated by the business relationships between them. Each entity contains data items/attributes that relate to or describe the Entity. Each attribute belongs only to one Entity, so duplication of Requirements is reduced.

Entity-Relationship data models are also commonly classified as ‘Conceptual’ or ‘Logical’, in that they are intended to communicate the data requirements of the Business. Such models can then be transformed into a ‘Physical’ Data Model that is used to design a database.

If a Data Model is used in conjunction with Use Cases, the latter’s data items can be defined by a cross-reference to the Data Model. As a result, a data item used in multiple use cases will be defined only once, eliminating duplication and inconsistency.

Given integrated Use Cases and Data Models, what other requirement artifacts should be considered?

Process Models: Are they an Information Systems Requirement artifact?

The origin of Process Models as we see them today would likely make for an interesting academic paper --- systems and procedures and time & motion studies pre-dated information systems. In any case, the profile of Process Models was certainly raised by Business Process Re-engineering; you had to define your Business Process before improving/re-engineering it.

However, as a format for documenting Information System Requirements, process models can have a negative impact on the resulting system. The process as it exists at the time of requirements documentation has often been ‘hard-coded’ into delivered information systems; when the process needs to change, the system cannot support a different process, and the business starts to adapt or create work-arounds to get the work done despite the constraints of the system.

This situation occurs frequently because it is not recognized that some aspects of the business are less stable than others. It has been shown that the process of a business, especially the order of separate steps, is the least stable aspect of a business; at the other end of the scale, the data items and their definitions as used by a business are the most stable aspect of that business. In between the two ends of the scale fall things like specific procedures (units of work) and business rules.

So, automation of the current business process should not be an Information System Requirement. In fact, more generic process and workflow software have been developed over the years to specifically support rapid change in process, adding or changing or re-ordering process steps as needed. These tools are enjoying a new high-profile a Business Process Management (BPM) products, as companies look for ways to integrate disparate systems, and vendors look for a front-end to SOA approaches.

Where Process Models can play a role in documenting Information System Requirements is to provide a context for Use Cases. Most steps in a process map will state that some work is done in that step, before the process flow continues; often this work involves use of an Information System, which can be documented as a Use Case. As stated in earlier posts, the Use Case then provides context for Declarative Requirement Statements, as well as a cross-reference to data items and their definitions in a Data Model. In the end, knowing the overall process of the business or its subsets solves the issue common with Use Cases: how many do you need, and how do you know when you have enough… process context provides the answer.

Just a few years ago, this would have been the last ‘artifact’ that I would have discussed. However, a new emphasis on methods and formats for documenting Business Rules has recently emerged…

Business Rules

As a concept, Business Rules are not new, to the Business or IT; what is new is the focus on separating them from other forms of documentation so they can better defined and managed.

Business Rules are similar to Process Models/Maps in that they are subject to more frequent change than other aspects of the business, frequently enough that if rules are hard-coded in an Information System, the effort and elapsed time to change the system can be too large to be tolerated by the business over time. So, just as generic Process ‘systems’ are emerging to support rapid process change, so are Business Rule Systems and Vendors that support Business Rule Management and change independent of the information systems that use them.

What is a Business Rule?

"A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern (an Information Systems) project are atomic – that is, they cannot be broken down further." ... from “Defining Business Rules ~ What Are They Really?”, Copyright ©2001, the Business Rules Group.

I would add the word ‘declarative’ to the definition, as in “a business rule is a declarative statement that defines…” emphasizing that Business Rules do not imply a process, procedure, flow or other ‘system’ structure. If Business Rules are separately defined and managed, they can then be used as needed by any process/procedure/flow that needs a rule’s guidance or constraint.

Some examples of business rules include:

- The insurance coverage for a 10 year Term Life Insurance Policy must be $50,000- or higher.

- Premiums paid by direct debit must have a monthly payment frequency.

- A person may be the life insured on multiple policies, but only if the total coverage of all the policies does not exceed $1,000,000-.

To ensure that Business Rules are meaningful and clear, they are always based on a defined set of ‘Terms and Facts’, which are used as the language of the Rules. Terms from the above examples include insurance coverage, premium, policy, and person. An example of a fact would be "a person may be the life insured on multiple policies ": it’s when you add the constraint "but only if the total coverage of all the policies does not exceed $1,000,000-" that you have a rule, using that fact and the relevant terms.

Defining terms and facts can also be seen as a role of an Entity-Relationship Data Model, such that the Entities/Attributes and Relationships of such a Data Model can readily be used as the Terms and Facts for defining Business Rules. The two types of models are different in many ways, but they are similar enough that if you have one, you can easily use it to drive the creation of the other.

To recap we have covered all the Requirements formats that I commonly use:

• Declarative Requirement Statements • Use Cases • Data Models • Process Models • Business Rules

I have touched on some aspects of how these formats can be inter-related and integrated. Let’s review all these formats and add some more aspects of integration.

Integrating Requirements Artifacts:

In summary:

- Process Maps identify all steps of a process, and a Process Step can indicate when a Use Case is used in the Business. One Use Case may be used by multiple steps.

- Use Cases can include one or more Declarative Requirements for the Information System/Solution. Each Requirement Statement is allocated to one and only one Use Case.

- A Data Model will document all data items used within the scope of a set of Use Cases, and is cross-referenced in the Use Case for the data items used by the latter. So, a data item is defined once but can be used in multiple Use Cases.

- Business Rules can also be documented across the scope of the Business being analyzed, including both the set of Use Cases and the overall Process Map; a Business Rule may be invoked at different points and times within Business Operations. Use to date has shown they can then best cross-referenced in:

- the Use Cases whose execution is impacted by one or more Business Rules

- Process Maps at Decision Points, as Business Rules may play a role in deciding which path within a Map should be followed in any one execution of the Process

The integration described above can be illustrated in the following diagram:

Integrated Requirements

It is at this point where the cross-requirements traceability of this level of integration can be seen to support Impact Analysis of potential Requirement changes; for example, when a change to a Business Rule is being considered, the measure of its potential impact can be gauged by tracing to all the Use Cases and Process Decisions that the rule currently constrains.

Used together as an integrated set, I find these Requirements artifacts present a comprehensive set of Information System Requirements. However, Requirement Artifact formats and artifacts come and go, so in the long run, it is not as important to use the ‘best’ Artifacts, as it is that you will need multiple types of Artifacts, and they should be integrated to reduce duplication, and present multiple views of the same Business domain.