Agile Requirements - System Sequence Diagram (SSD)

In the Previous Post I talked about the System Context Diagram. It provides a high level view of a system and it's interfaces that make up the overall ecosystem for the product under development. The system context diagram is a static model, meaning it doesn't show interactions/changes over time. From a context diagram, we can create another model, the System Sequence Diagram (SSD) that will show interactions over time.

At the system level the interactions are between interface points, either systems or users. You'll notice that there are no decision points. This diagram illustrates a single scenario or flow. In the diagram below the sequence is for successfully paying outstanding fines through the library website.

The Patron initiates the sequence by interacting with the website to get their account info. Next the Patron chooses to pay the fines which requires interaction with the Library Management System (LMS), which then hits the payment gateway to process the electronic payment. In this example the payment is successful.

Why would we use this diagram? Well, it's great to use when defining interface points between systems and thus between teams and/or products. In this case it allows the teams to, early on, clearly define interactions and interface points. You can even take it to the point of establishing operation contracts for the interfaces, allowing teams to code to the contract and establish stubs or mocks as needed to foster early & continuous integration.

Key things to remember about SSD's:

• Pairs well with a system context diagram
• Illustrates a single flow or scenario
• There are no decision points
• Since these are "system" sequence diagrams they focus on interactions between systems and external users
• SSD's are useful when dealing with integration projects
• SSD's show project scope - work that must be done to complete system development (interface and integration points)
• Can include operations contracts for the interfaces - allowing teams to establish interface definitions early so system to system integration can begin right away
• System Sequence diagrams are used for high level interactions (not detailed design level); 
• Know that developers also use sequence diagrams (note I left off the word system) for software design - that's describing the "How" not the what and thus not what we're looking for when creating SSD's

Don't overuse the system sequence diagram. Don't get carried away by exhaustively documenting every scenario you can think of. In my experience, it works best to have a few diagrams that illustrate key mechanisms. That's usually sufficient.

The next model: Activity Diagram.

Modeling notation can be found at: www.uml.org