In this series that starts with Part I (State Diagrams), I show how different visual models can help you create better requirements. If you don’t want to miss the next installments, make sure to follow me on LinkedIn or subscribe to our infrequent updates entering your email to the right.
# # #
As a business analyst working on software projects, you’re probably asked to draw a lot of diagrams. Sometimes it may be hard to understand why, when textual requirements is what’s traditionally required to get “sign off” from stakeholders for what needs to be built. But as we started to see in Part I: State Diagrams, visual representations can help you understand what questions to ask to uncover potentially hidden requirements, reconcile differing viewpoints about what the system is meant to do, and communicate the big picture of a solution being built incrementally, among other benefits.
In this article of the series, we’re going to take a look at relationship maps. While state diagrams focus on a single business object and how it transitions states in response to conditions and events, and process maps depicts the sequence of steps that transform inputs into outputs, a relationship map highlights the inputs received from external parties (customers, providers, partners) and the outputs provided to them, as well as the functional areas involved in handling those inputs and outputs and the handoffs (inputs and outputs) within the organization.
Imagine that you’re starting to work on a system to automate invoice processing for a hardware repair company. A relationship map for the project could look like this:
Because the diagram focuses on the affected business functions and their inputs and outputs, it’s easy to determine the cross-functional relationships between these functions (engineering, account management, finance) and the external actors (customers and providers). After building this map, a BA could identify a potential process improvement opportunity in the handoff of invoices to the customers (highlighted in orange above).
The analyst could ask relevant questions to stakeholders, such as, “Given that the finance department is responsible for generating the repair invoice the customer gets and receiving the payment, does it still make sense to have the handoff of the repair invoice from finance to account management before it reaches the customer?” The proposed change would be captured in a relationship diagram like this:
But now, comparing it with the previous version, it’s easy for the BA to see that the account management is left “out of the loop” regarding the completion of a repair order, previously signaled to them via the customer invoice forwarded by the finance team. We can then modify the diagram again, to make sure the notification still happens (see added green arrow):
Note how in this version the customer still has to submit a repair request to the account management team, responsible for validating the terms, such as the service level agreement the request has to adhere to. But account management no longer needs to be involved in the customer invoicing process: the finance team can invoice the customer directly. However, since in the “as-is” process the invoice received from finance served as the notification to the account management team that the service had been provided, we now need to extend the “repair complete” notification issued by the engineering team to the finance department (for invoicing purposes) so it also reaches the account management (new green arrow).
Showing the first and last diagrams (as-is and to-be ) above to business stakeholders makes it much easier for them to understand the recommendation for the process change compared to writing a textual description of the proposed changes and directly asking for sign off for the final requirements. Once the process change has been well-understood and approved, a textual requirement can be created to communicate to the development team what needs to be built and tested:
When the engineering team marks a repair service as complete, a “repair complete” notification will be forwarded to:
a) the finance system (existing behavior, which already triggers the invoicing process); and
b) the account management system (new functionality that will update the order status in the account management system so that account managers can have the information readily available when interacting with customers over the phone).
# # #
Visual representations of business functions involved in a business process, like the one provided by relationship maps, can be extremely useful for identifying areas of improvement and communicating proposed changes in existing processes. Relationship maps offer an excellent view of the key business entities and the inputs and outputs that flow between them. They can also serve as input for the creation of other useful diagrams such as a process map, with the functional areas becoming lanes in the diagram. By not focusing exclusively in one type of visual representation of the business model, BAs can dramatically reduce the risk of overlooked requirements or missed opportunities to improve business processes.
# # #
Looking to take your textual requirements and visual models to the next level? Registration for Crafting Better Requirements is only open for a few more days for analysts interested in taking the program, with immediate start date or scheduling for the first quarter of 2018.