Skip to main content
Mediacurrent logo

Blog Post

Expressing Processes: A Higher and Lower Level View

by Bill Shaouy
June 21, 2021

For a web project to be successful, someone must ensure that the right solution is being delivered, one that is in line with organizational goals and stakeholders’ priorities. That’s where a Business Analyst comes in. When eliciting and analyzing project stakeholder requirements, the Business Analyst conveys what the desired solution will do both at a high level and at a detailed level, so all stakeholders have a clear, common understanding of how their business processes are organized and how these processes relate to one another. Two work products can be created to serve this purpose, the Functional Decomposition Diagram and the Process Detail Document.

To create these work products, we first need to understand the boundaries of the proposed solution, the people and systems interacting with it, and the data that flows in and out of the solution. The Context Data Flow Diagram (DFD) does this. See my previous blog post about it for details, but as a quick review, let’s use this example solution proposal and DFD to base the new work products off of:

Example Solution Proposal:

The organization Acme Seminars has scheduled a new virtual seminar and has advertised it in the SMS (Student Management System), which reaches out to prospective attendees via the web. Behind the scenes, there’s a multi-step process from registration and payment to receiving a certification of completion. 

  1. A new attendee registers for the seminar through the SMS web interface. 
  2. Part of the registration process is entering credit card information. The SMS sends the credit card information to the credit card company’s Approvals server, and gets a message back that the credit card was approved. 
  3. The SMS notifies Acme’s Seminar Administrator by email of the new registration. 
  4. The Seminar Administrator logs in to the SMS to view the application, and confirms the registration in the SMS, which then sends a confirmation email to the attendee. 
  5. A day before the seminar, the SMS sends the Seminar Instructor a roster of the attendees. 
  6. The Seminar Instructor takes attendance at the seminar. 
  7. After the seminar is complete, the Seminar Instructor goes into the SMS and marks each attendee’s record as complete, if they were in attendance. 
  8. The SMS sends an automatic email to each of those attendees with a certificate of completion. 
  9. The Seminar Instructor also notifies her manager by email that she has completed teaching the seminar. 

Context DFD:

A graphic explaining Context DFD - An SMS project includes an Attendee, a Credit Card Approval Server, a Seminar Instructor, and a Seminar Administrator. All requests and approvals go between the project and the four outer parts.

The Functional Decomposition Diagram

Now that we have a Context DFD, we can build a Functional Decomposition Diagram based on it. A Functional Decomposition Diagram is a work product that is used to depict how essential business processes are organized and how they relate to one another. Like the Context DFD, it is created during requirements elicitation and analysis. It further serves as a launching point for more detailed work products later during requirements analysis. 

The Functional Decomposition Diagram is a great analysis tool because it is an easy diagram for reviewers to understand. It identifies and documents core business processes or capabilities, independent of how they are accomplished. Further, it gives structure to eliciting detailed requirements and allows the requirements to be gathered in a top-down fashion. Without it, a mutually-agreed-upon high-level view of the business requirements will have to be expressed in another, possibly less effective, way, and a core business process may be missed during analysis. 

The Functional Decomposition Diagram is really the innards of the solution proposed in the Context DFD, i.e. the innard of the circle in the middle. To create one, start with the high-level process identified during scope definition.

A graphic showing the scope definition as a tree structure with Seminar Management at the top and the rest of the  spreading out along branching paths of the business process and capabilities.

From there, break it down into more detailed pieces. In our example, Seminar Management is broken down into the following:

  • Promote Seminar
  • Register Student
  • Manage Roster
  • Certify Student

Break those processes down into even simpler processes until each lowest-level process performs a single logical user or system task. We now have a parent/child relationship between processes. Each level must completely describe the level above it. From there, each process can be more explicitly detailed.

Process Detail Description

Each subprocess in the Functional Decomposition Diagram can be detailed in a Process Detail Description. This description captures the following process elements:

  • A unique Process ID and name
  • A description
  • The agents involved
  • What causes the process to occur
  • What happens after the process is complete
  • The business rules associated with the process
  • … and more

Using our example, the following is the process detail for credit card approval:

A table showing an example of the process detail for credit card approval.

Business rules are expressed in a table format that includes the data being passed, what its “CRUD” action is, which stands for “Create, Read, Update, Delete”, and the source of the data. For example, the System is the source of the card number and is the reader of the response from the card service. 

After the listing of who performs the process and how, we include a metrics table that includes a key metric, its current state measurement, and desired future state measurement. For example, the process execution frequency is currently two times per day, but the desired future frequency is five times per day. 

The table concludes with some key details. The efficiency rating is useful when prioritizing which processes to update; low-efficiency processes often are a higher priority to address. What future changes are planned will depend on whether the process can be streamlined, fully automated, or even eliminated. Finally, the future state primary actor is captured; sometimes it will be different than that of the current state. In our example the process will be automated enough such that the prospective student will be the primary actor rather than the admissions administrator, freeing up the latter to do other work. 

What Deliverables Follow?

With a combination of a Functional Decomposition Diagram and its associated Process Detail Descriptions, we are now equipped to go deeper into requirements definition. Both are excellent inputs into business rule descriptions, use case models, and more. 

If you’d like to learn more about these and other requirements management tools for your organization, please contact us. At Mediacurrent, we've invested in Data and Business Analytics personnel and processes to make digital transformation a reality for our clients. We’re happy to chat with you!

Meet team member, Bill Shaouy

Bill is a senior technical professional who has been working with Drupal for over ten years. He has innovated client-centered, Drupal-based solutions for non-profit and for-profit organizations, placing a premium on fostering lasting relationships with clients and teammates in equal measure.

Bill was first introduced to Drupal in 2007, when he served as I/T Architect and Development Lead for the DC Comics Zuda web content management system. Since then, Bill has led Drupal projects in both the profit and nonprofit space, for such organizations as the State of Georgia, Jane Addams Hull House, the Mohonk Nature Preserve, the New York Hall of Science, Mentorplace, the World Bank, and most recently, the Atlanta Falcons. He also served as one of the original board members of the Atlanta Drupal User’s Group, giving multiple presentations there and contributing to the running of the early Atlanta Drupalcamps, and was also the founder and long time chairman of the IBM Drupal User's Group. Bill has also conducted many technology roadmap consulting engagements over the past several years, many from the nonprofit space. These engagements helped clients form a long term technology strategy based on current and projected requirements. 

When he’s not working, Bill is an active musician and songwriter, with two albums of his own and several more with him accompanying on piano.

Learn more about Bill >