Some words sound old-school.
That’s the case for sequence diagrams—a word usually associated with a previous mainframe era, and being out of date with new practices such as microservices.
Even if the technology landscape is constantly changing, there are fundamental things that don’t: specifying what a process must do.
Sequence diagrams act as a point of reference between actors that need to perform shorter iteration cycles with an increasing complexity of organizations and technology.
This article shares how Quality Engineering Sequence Diagrams can be leveraged to constrain the software lifecycle to Quality and Speed.
Follow the QE Unit for more Quality Engineering from the community.
What is a Quality Engineering Sequence Diagram?
A sequence diagram is a specific type of interaction diagram focusing on the description of flows between actors and systems.
Sequence diagrams are the most required model for software of the 3 types of interaction diagrams (sequence, communication, and timing).
By focusing on the “What”, they enable to clarify:
- Which actors are involved in the process?
- What are the initiators and reactions to events?
- Who is calling whom? What is happening? In which order?
They can be used to describe processes within and between software, and also for mapping out organizational processes.
With more maturity, sequence diagrams can support methodologies such as Value-Stream, Capabilities Mapping, Event-Driven Architecture, Model-Based Development & Test.
Standard notations exist such as UML and BPMN. The problem is that they usually end-up complex to maintain at scale, and most importantly, not understood transversally.
That’s where Quality Engineering Sequence Diagrams enter in the game.
People with an engineering background tend to over-complicate things when simplicity is needed (including myself, recognizing when I read articles again).
Quality Engineering Sequence Diagrams are simple schemas that:
- Represent flows between actors and systems
- Identify the ordered initiators, reaction and messages
- Highlight the most important information to consider.
Quality Engineering Sequence Diagrams describe interactions across two dimensions of flows and time (ordering only, no duration) with:
- Actor that is part of the interaction
- Lifeline per actor (vertical)
- Activation events
- Flows between actors
- Notes for relevant contextual information.
While we could add more elements to specify if flows are synchronous or asynchronous, manual or automated; it’s better to keep them simple and use notes in context.
The purpose is to specify with minimal efforts a process to improve the Quality and Speed of functionality implementation or a change of processes.
Why using Sequence Diagrams in Quality Engineering?
Organizations have the challenge to reinvent themselves with software to remain competitive in an accelerating digital ecosystem.
Their capability to deliver Quality at Speed software directly impacts how they can generate new revenues streams, and most importantly, survive.
Once priorities are defined, teams have the challenge to specify software increments at the high-standard (Quality) with velocity and scalability (Speed).
How does Sequence Diagram contribute to Quality?
One challenge of software teams composed of different expertises is to collaborate with a common language on deliverables.
Teams can spend hours writing hundreds of specification pages trying to align different perspectives, but that does not mean that they will be clear or actionable.
Straight after the definition of a Quality Engineering User Story, sequence diagrams can be made for each case identified, acting as a lightweight pivot in the cross-functional team.
Quality Engineering Sequence Diagrams contributes to Quality being:
- Result-oriented on a focused deliverable to produce per scenarios
- Systematic applicable to all user stories and processes definition
- Scalable across teams, processes and easily maintainable over time.
How does Sequence Diagram contribute to Speed?
Another reason writing a hundred pages is not an option is the lack of time for organizations requiring to transform themselves.
Speed in Quality Engineering is like running a continuous marathon of sprints: short-term increments must be delivered fast while maintaining a continuous velocity.
The focus on a common deliverable to produce for each software increment enables the team to create a rhythm of iteration they are able to keep and expand across the organization.
Quality Engineering Sequence Diagrams contributes to Speed with:
- Focus on common diagrams that emphases the key elements required
- Rhythm creating a shared ritual for specifying main software flows
- Asynchronicity with a shared format favoring asynchronous collaboration
- Visibility in providing a visual representation of the flows of processes.
How to start using Quality Engineering Sequence Diagrams?
The implementation of diagrams can be done gradually in multiple teams according to the team maturity.
A set of principles are important to foster Quality at Speed:
- Share the why for teams to adapt its usage
- Define a template format for replicability and sharing
- Make it systematic by leveraging the DoR and DoD.
Each Quality Engineering Sequence Diagram can be created by:
- Set the objectives
- Identify the scope
- Map step-by-step interactions
- Add emphasis on information
- Step back to improve the process.
Set the objectives
This step could be named “Start with Why”, aiming at validating the need for such a diagram in the first place.
Answering that question will also clarify the key questions and complexity at hands, helping you to focus on what matters in the following steps.
The diagram objective can simply be written at the top of your diagram.
Identify the scope
The scope of your diagram consists in identifying processes and actors that will be part of the horizontal and vertical axis.
Processes are clear sentences that can come from your user story or example mapping. It is important to stick with one diagram per process only to avoid mixing information.
Actors are humans or systems that are individually represented in a box with a vertical lifeline to map the flows. Try to order them based on the information you have.
Map step-by-step interactions
You are now ready to identify the flows composing the process, starting by the identification of initiating triggers to then add interactions.
The initiating triggers are the events that will initiate a particular flow. It can be a human action, a system event, or a fixed trigger like a specific hour.
Each trigger is then the starting point of mapping out interactions that must be represented as individual flow from one actor to another to effectively decompose the flow.
Merge or omit flows can result in an missed assumption for the software teams, that could miss an important point, feature and would involve costly reworks afterwards.
Add emphasis on information
It is now time to capture additional value from your diagram by highlighting relevant information for what you are trying to achieve.
The objectives and intent clarified in the first step can be used to add notes for:
- Information about an actor
- Initiating trigger conditions
- Flow execution (e.g. nature, time, data)
- Internal process performed in between
- Nominal and error flows (e.g. using color code).
As an example, if the diagram’s objective is to clarify complex interactions between front and back-office systems, you better map nominal, error cases, and flow synchronicity.
To the contrary, ensuring data shared are using master systems, you would add notes on the master data managed per system and data flow content.
Step back to improve the process
You can even increase the power of your diagrams by stepping back on what you have done to critically assess the content.
The analysis can be done in a variety of ways:
- Questions like “What if?” to identify scenarios and paths
- Gap analysis to identify deviation from expected states
- Verification by performing reality checks on the process
- Conformance checking versus defined standards.
The techniques to use come down to the context of what you are trying to solve and specify—reinforcing the need to always keep in mind the big picture.
Quality Engineering Sequence Diagrams Within MAMOS
The deployment of Quality Engineering Sequence Diagrams is a pivotal practice to deploy as part of your portfolio of software methodologies.
The shared format will foster an end-to-end collaboration between team members to iterate with more Quality and Speed on a continuous basis.
Its power can be extended when combined with the other methods of the Quality Engineering Framework, MAMOS, like Quality Engineering User Story, DoR, DoD.
We used to say that a scheme is worth a thousand words, and that an example is worth a million. And Quality Engineering Sequence Diagrams combine both.
What will be the value of yours?
References
Martin Fowler, Kendall Scott (1999), Get UML Distilled: A Brief Guide to the Standard Object Modeling Language, Second Edition. O’Reilly.
Sanford Friedenthal, Alan Moore, Rick, Steiner, A Practical Guide to SysML (Third Edition).
The Systems Modeling Language, The MK/OMG Press.
Lambert M. Surhone, Miriam T. Timpledon, Susan F. Marseken (2010), Sequence Diagram, VDM Publishing.