CHAPTER 5
Putting It All Together

Now that you have learned how to begin eliciting business requirements, let’s take a look at the forum in which you can use these steps: the requirements session. The same steps can also be used in one-on-one requirements interviews.

What Is a Requirements Session?

A requirements session is an interactive forum led by a facilitator and attended by key business representatives such as subject matter experts, stakeholders, and project team members.

Requirements sessions allow business users to articulate business requirements in order to establish a project charter, develop a business case, and identify issues that might become showstoppers later in the project.

Sessions like this tend to fast-track the requirements analysis process. They also encourage consensus and buy-in from business users and stakeholders. It is not unusual to make surprising discoveries during these sessions; attendees often have “aha” moments, in which they learn something new or gain new understanding. Sometimes problems that could cause the project to be delayed or even cancelled are unearthed.

IT professionals have always believed that it is best to discover problems and unknowns in the earliest possible stage of the systems-development life cycle. It is much more costly to fix these issues if they are discovered later in the process than if they are discovered during the requirements phase. Barry Boehm and Victor R. Basili write, “Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design stage.”¹

Preparing for a Requirements Session

1. Identify and understand client expectations. What does the business want to get out of the requirements session? Do users need an analysis of the current process or system? Do they expect a process engineering exercise? Process mapping? Reverse engineering? Do they want an analysis of the to-be?

   The client’s expectations will dictate what you, the requirements analyst, will eventually deliver, but the steps that you take should be the same regardless.

2. Identify session participants. Who should attend the requirements session? In almost all the sessions I have facilitated, the following individuals have participated:

   • Project sponsor

   • Subject matter experts

   • Internal and external stakeholders

   • Project team members.

   The session should be led by a facilitator.

3. Scope the project. Scoping the project before holding the requirements session will allow you to identify the business events that must be analyzed and documented. This may also be done during the first few minutes of the requirements session itself.

4. Schedule the session. Group or categorize the business events according to the line of business that must respond to them. Schedule discussion of each business event according to the availability of the subject matter experts.

5. Arrange room logistics and equipment. An ideal room for a requirements session is one with lots of usable wall space on all four sides and no obstructing columns that could impair attendees’ ability to see the work area. The facilitator will stand at the front of the room to conduct the session. The completed data flow diagrams will be put on one wall; the object definitions will go up on another wall; and the EERD will be built on a third wall.

   No equipment is required, other than static-cling white board sheets and dry erase markers. You may need an overhead projector if someone is slated to do a presentation at the beginning or end of the session.

6. Issue invitations to participants.

7. Evaluate responses to invitations. It may be necessary to reschedule the session if too many invitees cannot attend.

Scoping a Project

What does scoping a project allow you to do? Why even do it? Scoping a project allows you to understand the size and complexity of the project.

• The size of the project is determined by the number of business events that are in scope.

• The complexity of the project is determined by the complexity of each of the business events, as well as the number of people who will be involved in the discussion. The more people there are, the longer it takes to come to decisions and consensus.

Scoping a project involves identifying as many events as you possibly can, even if your users are not sure if an event is in scope or not. The time to query the relevance of a business event is when you are about to analyze it. When in doubt, include the event in the scoping list. Do not be discouraged if you can find only one event. You will eventually discover others along the way.

Where to Begin?

Start with the business objective. What are the users trying to do? What problem are they trying to solve? The answer to this question may very well be the first business event. For example, if a user’s main concern is trying to locate a product he or she has ordered from a supplier,² you can start with an event called It is time to find a product ordered from a supplier. Then look for the possible results of this event, which are Ordered product is not found and Ordered product is found. These are two separate events which may or may not require independent processes. Looking further for other events, you might want to ask whether the ordering process itself is within the scope of the project. If it is, you have another event: Ordering the product from a supplier. If you can order a product from a supplier, can you un-order—cancel—a product? If that too is within scope, there will be another event called An order is cancelled.

You can see that even if you begin this process with only one event, you will find others by asking the appropriate questions. Don’t be afraid to ask “dumb” questions. It is by asking questions that you tend to find scope creep.

Of course, you should always ask your users what events they think should be included in your list. They are there, after all, to provide you with their subject matter expertise.

Scoping Document

The scoping document should address the following:

• Business or project objectives

• Business events and their relative complexity and priority

• Roles or business areas expected to participate in each event

• Typical (or current) process flow (detailed in Chapter 9)

• Risks

• Issues

• Requirements estimate

• Schedule of participation

• Recommendation for next steps.

The scoping document may end up being the project charter. The scoping document is used as a guide during the requirements-gathering session to ensure that the appropriate parties are invited to the requirements sessions, the in-scope events are analyzed and documented, the analysis is done within the timeframe established, the expected deliverables are completed, and whenever possible, the risks are mitigated, and the issues are resolved.

The Roles of the Requirements Session Participants

Let’s take a look at a typical list of participants in a requirements session and what value they bring to the session:

• Subject matter experts (SME) have in-depth knowledge about the business events. They may not necessarily be the people doing the actual work; they may have done it before or have a vision of what the process should be.

• Stakeholders are responsible for the success or failure of the project. They are normally the people who will be affected by the performance of the project and can influence the development of it, but who are not directly involved with doing the work. Typically they provide guidance as to policies and principles to follow in the development of the project. They are also usually the people whose reputation is at stake should the project fail. They may be SMEs themselves.

• A sponsor finances the project. He or she may be a stakeholder, too.

• The facilitator manages the requirements session. He or she:

  • • Controls the flow of discussion

  • Controls the involvement of the participants

  • Elicits the requirements

  • Analyzes the requirements.

  The facilitator should not take the role of a SME when conducting a session. Facilitators must be objective when eliciting the business requirements.

• A documentation specialist is responsible for documenting the business requirements, generating the business requirements document (BRD), and managing changes to the BRD. It is ideal to have both a facilitator and a documentation specialist at a requirements session, but if this is not possible due to lack of resources, the facilitator can do the documentation.

  A documentation specialist must understand what business requirements are. He or she must know what information should and should not be documented and must work with the facilitator at the end of each day of the requirements session to make sure nothing has been missed.

• Development professionals (programmers) are not required to be present at the requirements session, but they may be asked to attend as technical resources. Because business requirements are all about business, when programmers attend sessions, they do so not necessarily to contribute their business knowledge, but to share their knowledge about the system capabilities.

Conducting the Requirements Session

The first day of the session should be devoted to explaining the project and the requirements-gathering process to the participants. It is important that all the interested parties attend the first day of the session. Usually, the sponsor opens the meeting by talking about what the project is supposed to do, which business areas will be affected, the benefits of the project, timelines, expected outcomes, and constraints, if any.

When the sponsor finishes his presentation, he or she should introduce the facilitator, who will explain the process of eliciting the business requirements.

To explain the process, the facilitator should use an example that is completely different from the target project. If possible, use an example everyone can relate to, such as A customer makes a bank deposit or It is time to make a reservation.

When explaining the process, explain the event process model symbols for object, process, actor, and data flow, and then develop an event process model for the selected event. Show the steps one at a time, beginning with identifying the trigger. This explanation should take about 15 minutes.

Then, if you have previously scoped the project, show the list of business events to the participants. (You should already have determined which events will be discussed each day.) If you have not scoped the project, now is the time to identify as many events as you can.

Ask the participants to select an event from the list—the most logical one to start with, the easiest to understand, or the hardest (to get it over with). You should be able to start your analysis at any point in the list because you are treating each business event as an independent, stand-alone entity.

Always make sure that while you are drawing an event process model in front of the meeting attendees, it is visible to everyone so that they can tell you if what you’ve heard and modeled is correct. Number each event in your original list and each event process model. Once you have completed each model, summarize it aloud and get confirmation from the attendees before moving on to another event.

To keep track of your progress, check the event that you have just completed off the original list of events. If you discover a new business event while in the process of modeling another, add the new event to your list. Do not get distracted or go off on a tangent by discussing the newly identified event before completing the event at hand.

As you complete an event and find new ones, always ask whether the new event is in or out of scope. When in doubt, consider it in scope. You might find that your list of events is longer than when you started. Do not let this overwhelm you. Just keep analyzing one event at a time. You might find events that share a process you already have documented, so you do not need to spend any more time analyzing those events.

When conducting a requirements session, it’s ideal to have a documentation specialist who will document the requirements as the facilitator is asking questions, modeling the processes, identifying more events, and analyzing data and processes. The documentation specialist should produce draft documentation at the end of each day to show the attendees what has been discussed, the results of the discussion, and a summary of decisions made.

If this is not possible (it is not in most organizations today), the facilitator should produce the documentation at the end of the day. This makes for a long day for the facilitator. In this case, I would suggest that the session be conducted for half the day; the rest of the day can be spent on documentation.

When producing a requirements document, make sure that it is written in business terms, because it should be confirmed by the business users. At the same time, you should ensure that it can easily be translated into specifications that can be understood and accepted by the development group.

Always keep a list of issues that surface during the discussion. At the end of each day, assign unresolved issues to specific staff members. If there are events that depend on the resolution of certain issues, make sure that you have indicated a date by which resolution is necessary.

Eliciting the Requirements

When eliciting business requirements:

1. Identify the business events.

2. Develop an event process model (EPM) for each event.

3. Build the event entity relationship diagram (EERD) for each event, including object definitions and data attribution.

4. Repeat steps 1-3 until all the events have been analyzed.

Follow these steps, and you cannot go wrong.

The Business Requirements Document

The primary deliverable of the requirements-gathering exercise is the business requirements document (BRD). It is usually not necessary to produce a business requirements document at the end of each day, but it is always good to show the participants what you have produced at the end of the first day to alleviate their typical concern: that their requirements have not been documented. Every BRD should have the following components.

A. Analysis of business events. Each business event must have an associated:

1. Event process model. The EPM answers the following questions:

   • When does the event happen? What triggers it?

   • What is the objective of the related process or activity?

   • What do we need to do with the information (e.g., data attributes, business rules, processes) we have?

   • What business rules do we have to follow?

   • Who should be doing this process or activity?

   • Where should the process or activity be performed?

   • Should anything happen before the event (pre-condition)?

   • What should happen after the event (post-condition)?

     An EPM is composed of:

   • A data flow diagram (DFD), which visually represents the answers to the questions above. A DFD is a very powerful tool for the facilitator of a business requirements elicitation session. It allows the facilitator to show the SMEs what he or she has heard from them. The SME can then confirm or alter the information that was given.

   • A process description, which describes in business terms the process illustrated by the DFD. It details in sequence the tasks and activities that must be performed. These include established business rules and those still being defined.

2. Event entity relationship diagram. This visual representation shows the relationships of the objects required by the business event.

B. Data dictionary. This details each object and data element involved in the system. For each object, the following information appears:

• Definition of the object in business terms

• List of data attributes (pieces of information belonging to an object)

• Description of object relationships in business terms. These will help us ask questions that will uncover rules applicable to the business and, later, discover gaps or scope creep.

C. List of acronyms and glossary of terms used in the document.

D. List of issues affecting the project.

E. Design considerations. These are features users might want to incorporate into system operations to allow ease of use, increase productivity, or cater to users’ special needs. It’s not mandatory to include design considerations in the BRD, but if they are discussed during a requirements session, they should be documented so that they are not lost or ignored. For example, a user may express a need for a graphical user interface (GUI) with huge characters that can be read up to three feet from the screen. This may be a design consideration for a specific business event, or for all events requiring a user interface.

F. Nonfunctional requirements. These requirements are related to the quality of, rather than the behaviors of, a system. Examples are performance, scalability, reliability, and availability. You’ll find a more comprehensive list in Chapter 8.

What Should the Requirements Document Look Like?

The requirements document itself should be easy to read. It should be well organized, making it easy for the audience to find the information it is looking for. Here’s how I suggest you organize your requirements document.

1. History of the requirements documentation, including approval page

2. Executive summary

3. Business objectives

4. List of project team members

5. Global nonfunctional requirements

6. Assumptions

7. Issues

8. Outstanding questions

9. List of acronyms used throughout the document

10. Context diagram

11. Recommended next steps

12. Functional requirements

    • 12.1. Business event 1

      • 12.1.1. Data flow diagram

      • 12.1.2. Process description

      • 12.1.3. Specific nonfunctional requirements

      • 12.1.4. Event entity relationship diagram

      • 12.1.5. Objects participating in the event

        • 12.1.5.1. Object 1
                        Object definition
                        Data attributes

        • 12.1.5.2. Object 2
                        Object definition
                        Data attributes

        • 12.1.5. n. Object n
                        Object definition
                        Data attributes

    • 12.2. Business event 2

      • 12.2.1. Data flow diagram

      • 12.2.2. Process description

      • 12.2.3. Specific nonfunctional requirements

      • 12.2.4. Event entity relationship diagram

      • 12.2.5. Objects participating in the event

        • 12.2.5.1. Object 1
                        Object definition
                        Data attributes

    • 12.n. Business event n

      • 12.n.1. Data flow diagram

      • 12.n.2. Process description

      • 12.n.3. Specific nonfunctional requirements

      • 12.n.4. Event entity relationship diagram

      • 12.n.5. Objects participating in the event

        • 12.n.5.1. Object 1
                        Object definition
                        Data attributes

Because an object will participate in more than one business event, there is no point in repeating the definition of this object under every event. You can consolidate all of the object definitions and data attributes in the data dictionary. The data dictionary might appear as part 13 of the requirements document and look like this:

13. Data dictionary

• 13.1. Name of object 1

  • 13.1.1. Object definition

  • 13.1.2. Object data attributes

    • 13.1.2.1. Data attribute 1

    • 13.1.2.2. Data attribute 2

    • 13.1.2.3. Data attribute

    • 3 13.1.2.n. Data attribute n

• 13.2. Name of object 2

  • 13.2.1. Object definition

  • 13.2.2. Object data attributes

    • 13.2.2.1. Data attribute 1

    • 13.2.2.2. Data attribute 2

    • 13.2.2.3. Data attribute

    • 3 13.2.2.n. Data attribute n

• 13.n. Name of object n

  • 13. n.1. Object definition

  • 13. n.2. Object data attributes

    • 13. n.2.1. Data attribute 1

    • 13. n.2.2. Data attribute 2

    • 13. n.2.3. Data attribute 3

    • 13. n.2.n. Data attribute n

Levels of Detail in Requirements Documentation

Why are there different levels of detail in requirements documentation? Some analysts produce high-level requirements documents that may be too broad to be useful. Others deliver requirements documents that are so detailed that the development group feels robbed of the opportunity to be creative with the design.

The level of detail found in requirements documents varies for two reasons:

1. The requirements document’s intended use. If you plan to use the requirements to issue a request for proposals (RFP), a request for quote (RFQ), or a request for information (RFI) for evaluation of packaged software from external vendors, a high-level business requirements document will usually suffice. A high-level requirements document usually identifies the capabilities expected of a software program without necessarily describing the data requirements, process definitions, and business rules. At its highest level, the document should allow analysts to short-list vendors that can and cannot fulfill the project’s requirements. A high-level document may simply consist of capability statements such as:

   • The system must be capable of accepting reservations by phone, email, fax, or over the counter.

   • The system must be capable of accepting payments by credit card, debit card, cash, credit memo, or promotional coupon.

   If, however, your plan is to use the requirements document as the source for developing the design and eventually the full construction of the system, it should be more detailed. This will help minimize back-and-forth contact between the requirements analyst, users, and development group. Detailed requirements documents are especially useful when development is outsourced to developers outside the country, or when the development will be done inhouse but the developers did not talk with the users about their needs.

2. The eye of the beholder. We may all agree that requirements explain what a system should do, but analysts still struggle to define what requirements are supposed to be or do. As Alan M. Davis notes in Software Requirements: Objects, Functions, and States, “One person’s what is another person’s how, or one person’s floor is another person’s ceiling.” So no matter how detailed a requirements document might be, someone will invariably claim that it is either not detailed enough or too detailed.³

Managing Your Requirements Document

In business, change is constant. Processes change, business drivers change, people change, requirements change. Any of these changes can affect your requirements document.

Requirements document management is all about ensuring that the documentation is an accurate and true representation of the current business requirements for the target application. It also includes making sure that changes made to the requirements document are traceable.

Many organizations have tried to “freeze” business requirements, hoping that they can control the change requests submitted while the system is under construction. But freezing requirements is not necessarily a practical approach. We all recognize that change occurs. We need to prioritize these changes and assess the risks and benefits of including them in the system under development. Unstable and evolving requirements are an ongoing problem in the systems development field. Allowing changes to requirements to get out of hand can halt progress on the project or cause the project budget to balloon. With that in mind, remember that changes should be incorporated if not doing so could potentially cause more serious problems than including them would.

Lehman’s law⁴ of continuing change states that systems that are used must change, or they automatically become less useful. Yet the law of increasing complexity holds that through changes, the structure of a system becomes ever more complex and more resources are needed to simplify it.

What can be done to manage your requirements document after it has been signed off? Mandating a version-control process can help. When a change is made, the following information must be documented:

• Explanation of the change request

• Who made the change

• Date the change request was made

• Date the change was approved

• The phase of system implementation in which the change is to be included

• What other pages were changed as a result

• Effect of the change on the overall project

• Risk introduced by the change request.

This list implies that an approval process is followed for any requirements change. Figure 5-1 illustrates a change management flow in which signoffs are required. Your organization might not rigidly follow a defined approval process. Regardless, traceability of the change itself is essential. Chapter 11 details traceability techniques and types of traceability.

In Brief

Understanding the XCellR8™ approach and applying it to a real requirements session will give you a full appreciation for its simultaneous simplicity and complexity—simplicity because the approach is broken into simple steps and complexity because individual analysts must analyze and compartmentalize gathered information and follow up with probing questions when necessary.

NOTES

1. Barry Boehm and Victor R. Basili, “Software Defect Reduction Top 10 List,” Computer 34, no. 1 (January 2001): 135-137.

2. I once had a client who constantly asked, “Where’s my stuff?” I almost named his project WMS, but his company already had a warehouse management system with the same acronym.

3. People tend to complain about the level of detail only when they think that time is being wasted by talking about the level of detail or when they feel like they don’t know enough about the details. So it’s important that all interested parties understand why the requirements are general or detailed.

4. M.M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution,” Proceedings of the IEEE (September 1980): 1060-76.

FIGURE 5-1: Example Requirements and Change Management Flow