Agile requirements - setting the context

Still in the series of posts about requirements related artifacts - previous post. When I say requirements related, I mean something that assists us in understanding the system under development. As in past posts, the user story, scenarios & tests are all part of the requirements package. What else is there? What other kinds of things can we produce that add value & enhance understanding. As a coach many times when working with a new team, I'm listening to the conversation and I get lost. There are too many applications, acronyms, systems for me to understand what's going on. When I'm lost I almost always ask the team to allow me to draw a system context diagram.


A system context diagram is not a technical diagram. It's a simple view of the system under development in the context of other systems and users.

This is understandable by anyone in the organization. It's something the members of the business side can understand and explain. There are no enterprise service buses on the diagram, there are no database icons, no routers, no racks, no techno-speak at all. Just a simple picture of the interfaces (both systems and user) with the key systems that are part of the work effort.

Key things to remember when creating a system context diagram:

• It's not a technical diagram
• Should be in terms the business understands
• Can show evolution of the system release by release. This can be done like the example above. Or you may have multiple versions of the diagram, one for each release. You can color code the diagram to show release 1 versus 2, etc.
• Although there may be many other systems in the ecosystem, only those that are part of the work effort are included. If there are other systems that aren't changing you may not need to add them to the diagram. 
• Collaborate to create the diagram
• It's simple to draw - no crazy notation to worry about

So why is this a requirements related artifact. The diagram identifies a high level view of what is included. Interfaces are identified leading to requirements for interface work, both system-to-system and user interfaces. It can also show what's included in each release identifying overall scope of the project. And it allows you to identify the teams required to participate in the effort. This becomes part of Roadmap for the project/team/product.

I use this diagram with almost every team I work with.  You should try it out.

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