Case in Point

I once was assigned to redesign a customer management system. The existing software was almost 20 years old and had been patched and updated thousands of times. In initial discussions with the business stakeholders, the IT manager became concerned that the project team would end up simply rewriting the existing system. Most of the organization had been using the old software for so long that everyone used its terminology and accepted its limitations as if they were business rules. The IT manager instructed the analysis and design teams not to look at the old software. She instructed us to elicit the true business requirements independent of the current how and design a brand new system that would support the business and allow for future flexibility. This was a challenging task because it felt natural to learn the business by learning the old system. It was also difficult because, as the IT manager predicted, all of the business workers understood the business through their use of the old software. We asked a lot of questions and worked to pull out the core or essential business needs (see next section) and designed a brand new software application. It expanded the capabilities of the entire company because we had ignored the limitations of the old system.

What is a business process?

Many organizations use the phrase “business requirements” to mean high-level goals of the business. Excellent business analysis requires that business requirements, and in particular business processes, be analyzed at a much more detailed level. Analysts should work to understand as much detail as possible about each business process. These detailed business requirements should be documented in a business model that can be reused for future projects. This will be discussed further in Chapter 6.

To understand a business, you must understand the work that is performed. This work can be defined as a business process. There are as many different definitions for the word process as there are BAs and consultants! Most agree that a process is an activity— a verb—something that an organization performs. Since the word process and others close to it (activity, function, task, and even business use case) are used so inconsistently, the BA must be able to hear these words used inconsistently and interpret their meaning from the context within which they are used. The terms used to describe business activities and processes have subtle differences that are often lost when people don’t understand what the original author/methodologist intended. Table 4.1 gives the proper usage and examples of terms commonly used to describe business processes.

Ideally, the BA will help an organization come to a common agreement on how the word process is used. Even in an organization with only 5 to 10 people, there will be inconsistent uses, so it is best to get comfortable with the inconsistency as opposed to trying to fight it. The way to deal with inconsistency is by listening carefully, asking clarifying questions, and always speaking precisely. These are things that BAs do very well anyway!

Tabled 4.1: Business Process Terms
Term	General Usage	Examples
Function	Generally considered higher level than a process. Functions are ongoing activities of the business. Names are usually nouns.	Human resource management, marketing, finance
Process	This can mean anything from a very high-level activity in the organization (e.g., sell product) to a low-level, de-tailed activity (e.g., record order). Some people use process to describe how work is done, and others use it to describe the goal of the work. Some use it to describe how software is developed (Rational Unified Process® ). In business process management, it may be a high-level business transaction being managed across the organization. Names are usually verb-noun phrases. Processes should be named from the perspective of the business.	Receive order Validate order
Subprocess	A portion of a major process.
Activity	Used interchangeably with process, task, or procedure.
Task	Generally considered a lower level subprocess. A task is usually defined as an individual unit of work that can be accomplished by one business worker in a short period of time. Names are verb-noun phrases.	Add new account
Procedure	Step-by-step activities that define how work should be done. Often, procedures are considered manual tasks (not entirely supported by software).	New employee procedure, hiring procedure, file a claim procedure
Use case	Defined as a goal of the business. The term use case is used inconsistently—some analysts define very high-level use cases, some (more technology-oriented analysts) define them as very detailed, and others create multiple levels. They are named from the perspective of the actor (person for whom the goal is desired). See Chapter 6 for more information.	Place order
Event	Something that happens—and causes the business to react. There are several types of events, primarily external and temporal. These requirements components are used in a technique called event partitioning. This will be discussed further in Chapter 6.	Customer requests product

When learning about a business area, choose the terms that you will use from

Table 4.1 and use them consistently. Make sure that other analysts on your project use the terms in the same way. If your organization has not used these terms in the past, include them in the project glossary.