Is There a Better Way to Document Salesforce? Introducing ”Decomposition”

This article explores a practical methodology for structuring business information in a way that is easily digestible.

We’ll leverage the Business Process Management concept, “decomposition” to create a connected and contextualized scaffolding for documentation artifacts that help guide readers through a coherent story of the business.  

By the end of the article you should be able to:

• Define “functional decomposition” and understand its utility for business analysis.
• Use “how?” and “why?” questions to ensure audiences have enough context and specificity to understand a business process. 
• Understand how decomposed processes can be captured in a way that helps stakeholders quickly understand the business context.

What Is “Functional Decomposition”?

Decomposition is the process of distilling complex processes into digestible and analyzable components. Functional decomposition refers to the decomposition of functional, business-orientated processes or requirements. 

You can think of functional decomposition as a methodology to help you break down the business in a way that makes it easier to understand. 

The key tenet of functionally decomposed processes and requirements is starting at the lowest level of complexity and drilling down into higher levels of complexity until no further granularity is required to complete the job at hand. 

If you’re familiar with Universal Process Notation (UPN), this idea may be familiar. UPN enables business analysts to decompose complex processes by leveraging drill down elements to capture and showcase greater detail, only when it’s needed. UPN is one practical application of functional decomposition methodology. 

Why Use Functional Decomposition Methodology?

Decomposition is a useful methodology to manage complexity and help readers develop a robust understanding of the business more easily. By documenting functional processes and requirements in such a way, business analysts can enable:

• Clients to validate that the project team’s understanding of the business is correct. 
• Architects and developers to more accurately solution design and build fit-for-purpose systems.
• Other project team stakeholders to effectively understand the business context.

A full functional decomposition serves as a blueprint for the business that functional and technical team members can reference as a source of truth for how the business works. 

How to “Drill Down”

Decomposition is all about drilling down. From big-picture to small-picture, your decomposed concepts, processes, or requirements should first give general context, and then allow readers to selectively dig deeper where they need to. 

Consider the following high-level process:

On reviewing this process, an architect responsible for solution design might ask questions like:

• How is the project opportunity identified?
• How is the contract signing process managed? 
• How is the project implemented over time?
• What conditions must be met for the project to be closed?

In this scenario, a technical team member needed to drill down into higher levels of complexity by asking “how?” and “what?”. But what if a process has been drafted that is too specific to give the necessary context?

Consider the following lower-level process:

In this case, the architect may ask:

• Why is the contract document generated in Word?
• Why do we need approval from the Project Manager?
• Why is the document stored in SharePoint? 

As seen in the example above, more detail is elicited by asking “how” to drill down into higher levels of complexity, whereas asking “why” can help fold up into more conceptual layers. Having both contextual and detail layers ensures that the audience understands both the how and the why behind business requirements. 

There is no set standard for the number of layers of complexity or when exactly to drill down. However, a simple guideline to follow is to question if an element offers sufficient detail for a technical audience member to design against. 

Take the process flow in the second example. An architect may ask “why” questions to contextualize the process, but may still need to ask deeper “how” questions to unpack the process further, for example:

• How does the Project Manager approve the contract?
• How does the Partner sign the contract?

Put Decomposition Into Practice

With the theory in mind, let’s put functional decomposition into practice. How might one leverage this methodology to organize a large corpus of functional requirements?

Create a Functional Decomposition Document

Creating a functional decomposition document can help you succinctly articulate the business and scaffold your functional requirements. The functional decomposition document breaks down large functions in the business into smaller, more manageable components and assigns a code to each (i.e. Function 1; Subfunction 1.1; Process 1.1.1; Sub-Process 1.1.1.1). 

The Functional decomposition document helps to solve the following pain points:

• Difficulty understanding the main functions and processes in a business, and how they fit together.
• Reliance on numerous disparate artifacts, such as user stories and process flows, to understand the requirements that underpin a build.

LucidChart offers an out-of-the-box Functional Decomposition Template, structured as follows:

Imagine you are onboarding onto a new, enterprise-level project as a technical consultant. Your team has asked you to familiarize yourself with the requirements and share a Jira link with 200 user stories and a Lucid folder with 20+ business diagrams and process flows. Where do you start?

Scaffolding Your Documentation

Starting with the Functional Decomposition document allows you a bird’s-eye view of the business, understanding at a glance the key functional areas and how they decompose into more discrete business processes serviced by the system. 

To increase the utility of the functional decomposition document, implement a coding structure that is tagged to your requirements documentation to make finding relevant artifacts easier. 

Let’s take the Functional Decomposition offered by Lucid, for example:

Using this code structure, it becomes possible to organize lower-level requirements. Let’s take user stories, for example. By adding a Code attribute to your user stories, readers can quickly query for the stories that support a particular sub-process:

Your process flows can also be tagged which helps readers locate visual overviews of the processes outlined in the functional decomposition, and allows readers to tether together user stories with visual artifacts. 

This methodology supports business analysts in quickly understanding how low-level business requirements (i.e. user stories) support the big picture and could help developers debug technical issues against the business requirements well after the build has been implemented.

Tip: Remember that business, and thus business requirements change over time. Your functional decomposition should be a living document that is consistently maintained to reflect the current state and needs of the business.

Summary

Leveraging this methodology should prove useful for a variety of project team stakeholders. In summary, a coherent decomposed corpus of requirements should help:

• Clients validate that project teams have correctly understood and articulated the business requirements.
• Business analysts quickly understand the scope of the business, key functions, and low-level processes.
• Solutions architects in understanding the dependencies between processes and requirements, and designing fit-for-purpose technical solutions that add business value.
• Developers in building and debugging solutions that support business requirements.