Transitioning business requirements to an IT solution


Angie Perris, Vice President, B2T Training


One of the ongoing challenges for a project team is the transition of business requirements to solution design. This transition is difficult because business requirements, such as business processes or business use cases, are described in business language for business stakeholders. Business language is a language in which IT developers may not be fluent. Also, business requirements do not describe how software should work; they describe what work must be accomplished by the business. This information does not give enough direction to software developers. To help set realistic stakeholder expectations for what will be delivered, using a structured technique for transitioning business requirements to an IT solution will create success.

This paper presents an outstanding technique for managing the transition of business requirements defined by business stakeholders to a software (IT) solution. The Design Area Scope Table is both a technique and a documentation tool. This is a valuable tool for the project manager to facilitate stakeholder conversations about business and technical priorities and costs. It is also an excellent tool to document stakeholder agreements. This table is simple to build and use, and results in more satisfied stakeholders, from both the business and IT areas. This is a technique that should be used early in the software design/architecture planning stage.

One of the important steps to understanding business requirements is the identification and detailed description of business processes. Understanding business processes is the link to defining an effective, usable software solution.

Design Area Scope

The Design Area Scope Table is a seven-column table that can easily be built in Microsoft Word or Excel. The complexity comes with the analysis required to populate the cells in the table. The project manager should bring together the business analyst, business stakeholders and key IT stakeholders to reach consensus on these design decisions.

This paper will present a step-by-step approach and explanation of each column in the table. After reading this paper you should be able to begin using this table on many of your projects.

Design area scope table

Exhibit 1 – Design area scope table

Before any software design is discussed, there must be a clear understanding of the business requirements in terms of the business model.

The Business Model

To ensure that business stakeholder needs are met, first make sure that the business requirements of the project are understood. Most software development methodologies expect that a business model is available for use during software design. The business model is a description of the business area, and may include diagrams, models, and textual descriptions (International Institute of Business Analysis, 2006). These documents or artifacts describe the core business needs independent from technology. In other words, they describe what needs to be done, not how it is accomplished. There are many analysis tools and techniques for developing and presenting a business model: functional decomposition, business use case model, organization chart, conceptual data model, conceptual class model, or a list of business objectives or goals. Any of these analysis techniques can be used to transition business requirements to a software design. This paper will use two of them in this discussion: business use case model and functional decomposition.

The Business Use Case Model

The business use case model includes use case diagram(s) and a set of use case descriptions. These business use cases typically start at a very high level of abstraction and represent high-level business functions. They describe an end-to-end business transaction where the customer initiates the process and the business satisfies the need of the customer (example: order product). They are externally focused and must fulfill a basic goal of a customer. They are named from the perspective of the customer.

Once these high level or conceptual business use cases are agreed upon, they are broken down into lower-level, more concrete use cases, also known as business scenarios. These lower-level activities can then be easily transitioned to software components.

High-level business use case: Order product
Low-level business use cases/scenarios: Search items for purchase
  Select item for purchase
  Create customer profile
  Look at delivery options
  Supply delivery address
  Pay for order

Functional Decomposition

Another approach to developing a business model is to use functional decomposition. High-level functions are first identified and then broken down into lower-level functions and processes. They are internally focused and must describe an essential activity of the business. They are named from the perspective of the business. The lowest-level processes are referred to as elementary processes, sequential processes, or leaf-level processes.

High-level function: Order processing
Low-level business process: Receive order
  Validate order items
  Check inventory
  Validate payment method
  Fulfill order
  Ship order

Business Process

Regardless of the approach or terminology used, there is consensus throughout the business analysis profession that a process (or a use case) is an activity that transforms some input(s) into some output(s). They describe the work of the business. The term business process will be used to refer to this work of the business for the remainder of this paper.

Business processes are named and described using business terminology because it is important for the analyst to demonstrate to business stakeholders that they truly understand what the process is and why the process is being performed (McMenamin, 1984). A business process may be performed in many different ways; however, the goal of the business remains the same. For example, an order may be received from a customer over the telephone, from a fax, from an e-mail, from the internet, or through the postal service. Regardless of how the order is received, the business process is fundamentally the same. The company wants to record the order, get paid, and send the requested products to the customer. It is critically important that the business analyst, project manager, and solution team understand these business processes, because they are the fundamental goals of the business. The solution team (IT) must understand these processes before they attempt to improve them with software.

It is best not to begin to design software until the core or essential business processes have been identified and described. Each business process must be clearly understood with respect to what work is accomplished, what information it uses (data), and what policies constrain the process (business rules). An example of a detailed process description template is shown in Exhibit 2. Once there is a thorough understanding of a business process, the team can imagine options for software support or enhancement of the business activity.

Example of a detailed description of a business process

Exhibit 2: Example of a detailed description of a business process

Once all of the business processes within the scope of the project are understood, the design area should be discussed. There are five steps necessary to complete the Design Area Scope Table.

Step 1: Which Processes Will Be Supported by Software?

The first decision that must be made by the team for each business process is: Will it be automated? This is the second column in the Design Area Scope Table (after the process name):

Will the process be automated?

Exhibit 3 – Will the process be automated?

Not all business processes should be supported by software. It is important to understand which processes are “candidates” for automation. As the project manager works to keep the project on schedule – balancing time, resources, and scope – he or she must help stakeholders prioritize the most important processes with the highest payback for the organization. If the process is currently supported by software, assume that automation is desired. In these cases, ask the business stakeholders if they are satisfied with the current software solution or if it needs improvement.

IT people sometimes don’t understand why business stakeholders would decide not to automate a process. Often there is an aspect of a process for which the business people prefer a human or manual component. This may involve a complex business decision. For example, final approval of a new loan must be reviewed by a supervisor. There may be processes that are too expensive to automate. For example, “We only send out about five refund letters per month, so it is cheaper to create the letters manually.”

Also, before deciding on automation, determine if the current process is efficient. Inefficient processes will not be improved simply by automating. Each process should be optimized before it is automated. Business processes that are not selected for automation are candidates for business process improvement, reengineering or organizational changes. Those discussions are topics for another paper.

Step 2: How should the process be automated?

For each process that is to be automated, make an initial determination of how the process should be automated. During this early stage of transition, the team needs to have a discussion about the solution options for each process. Most business stakeholders have experience using software and will probably already have some preferences regarding process automation. The project manager may call upon the business analyst to conduct these brainstorming sessions. Then the team can select the best solution.

Examples of automation options include an online or Web screen, a report, or an automatic software interface. This is the third column in the Design Area Scope Table.

Desired functional design

Exhibit 4– Desired functional design

Step 3: What is the business priority?

Next, ask the business stakeholders to prioritize each business process. A simple scheme is usually adequate, such as high, medium, or low. By asking the business stakeholders to rate each process, you are helping them understand that some tasks on the project plan are more important than others. This is the business stakeholders’ opportunity to tell the IT team which work is most important for the success of the business.

This is the fourth column in the Design Area Scope Table.

What is the business priority?

Exhibit 5 – What is the business priority?

To help the business stakeholders quantify the importance of a process, a discussion of business impact and risk assessment will be helpful. A good question to ask is, “If the money for this project were to be suddenly cut in half, which processes should be automated first?”

Step 4: How Would Automation of These Processes Affect IT?

One of the difficult realities for business stakeholders is that even if a particular process is their highest priority, there are other considerations from a technical perspective. For example, even though being able to answer customer questions about the status of their order is the highest business priority, we can’t build an inquiry screen into order data unless we have first built an order database and a data entry system through which data is entered. Another word to describe this difficulty is dependency (something with which project managers are very familiar!). IT professionals will also assess the technical risk of the software components as input to the technical priority (Hands On Technology Transfer, Inc, 2005). These challenges drive the fifth and sixth columns of the Design Area Scope Table. What is the technical priority and how expensive will it be to automate? The IT team members need to understand what is desired by the business, to enable them to think about how they would build a software architecture to support the business. As in any construction project, the foundation must be built before the upper floors, so the IT team may prioritize the work differently than the business stakeholders.

What is the technical priority and cost?

Exhibit 6 – What is the technical priority and cost?

Project managers are very experienced working with team members to estimate time and costs. Costs may include resource effort time, hardware, software, maintenance fees, infrastructure, and so forth (Project Management Institute, 2004). For this discussion it is usually enough for the project manager to use a simple scheme (high, medium, or low) for the entries in these columns. Try to initially identify the conflicts and issues. For example, is the highest priority business process considered a low priority to the technical team? Helping the business and IT stakeholders understand their divergent perspectives improves teamwork.

Developing the Design Area Scope Table generates valuable discussions, which is one of the most important benefits of using this technique. Ideally, the project manager schedules a working session with business and IT stakeholders to discuss these issues. When a business analyst is available, he or she can facilitate the discussion. When the project manager asks the team to look at the business processes and begin to fill in this grid, fascinating questions arise. Often there are discrepancies between the priorities of business stakeholders and the IT stakeholders. Just getting them to discuss their rationale will bring the team into better alignment. And you may be surprised to find that the business stakeholders don’t all agree on their priorities. One business area employee may see his job as the most important while another disagrees. Again, these discussions are extremely valuable and must be resolved before any software development can begin. Failing to identify unclear priorities and costs will guarantee that your project will fall behind schedule as soon as the developers start coding!

Step 5: Identify Phase or Iteration

The last column in the Design Area Scope Table is used to indicate the agreement of the group on the phases or iterations of the software development. On a small project, all of the automation may be built and deployed at the same time. On larger projects the work is often divided into smaller chunks so that some of the business functionality is delivered sooner rather than waiting until the complete system is done. With the increased use of agile development approaches, smaller and smaller iterations are popular. This approach works best when there is an overall plan that each small iteration supports. Remember to revisit priorities after each iteration is complete.

In which phase or iteration will the process be included?

Exhibit 7 – In which phase or iteration will the process be included?


Software development is an expensive and time-consuming activity. You will be more successful when you bring all of the stakeholders together early in the project to gain agreement on the development priorities. You will face challenges balancing the business priorities with IT priorities and cost, but these challenges are best met openly and honestly with the team. Having a simple, straightforward tool like this Design Area Scope Table is one proven technique to increase your likelihood of success.

B2T Training, LLC. (2007). Requirements package template. Retrieved from

Hands On Technology Transfer, Inc. (2005). Object oriented analysis and design: Methodology and the UML training.

International Institute of Business Analysis. (2006). Business analysis body of knowledge (IIBA BABOK™) V1.6. Retieved from

McMenamin, S. M., & Palmer, J. F. (1984). Essential systems analysis. Upper Saddle River, NJ: Yourdon Press.

Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK® Guide) – Third Edition. Newtown Square PA: Project Management Institute.

© 2007, Barbara Carkenord and Angie Perris
Originally published as a part of 2007 PMI Global Congress Proceedings – Atlanta, GA



Related Content

  • PM Network

    Agile Assurance member content open

    By Parsi, Novid Some project teams believe agile means skimping on requirements management. They're dead wrong. When they disregard this crucial component, they put project success on the line: For 35 percent of…

  • Greatness, a Place beyond Stakeholders' Expectations member content open

    By Deguire, Manon Managing stakeholder engagement calls upon something quite different from process groups and domains of knowledge, it calls upon the ability to create emotional responses such as enthusiasm, trust,…

  • PM Network

    Allied forces member content open

    By Merrick, Amy Seventy percent of organizations report that collaboration between project managers and business analysts is essential for project success, but only 46 percent believe the two groups collaborate…

  • Uncover gaps in your requirements using requirements risk management techniques member content open

    By Lee, Cheryl | Schibi, Ori According to a 2014 Project Management Institute Pulse of the Profession® report, inaccurate requirements gathering is the second most common reason for project failure, second only to changing…

  • Collaborating with stakeholders member content open

    By Haney, Victoria B. According to a variety of studies, 60 percent of software defects are linked directly to incorrect or incomplete requirements, with most project teams spending less than 8 percent of their time on…