Analyse IT

When (to use it)?

Like the Hierarchy diagram, I use a Context diagram at the beginning of the project, along side the top level (and only the top level) Hierarchy diagram.

To Achieve?

A simple and instant view of the Processes, their Actors and Interaction of the processes (depending which type you pick)- Context diagrams are a great way of viewing your scope as a whole - but only the birdseye view, at a high level.

What is it?

Context Diagram is: A static view of the Processes and actors at the "high level". You can see what you need to address during your project by looking at the context, it is "in scope" view. Anything (at a high level) outside that, is not within your scope. You can see the actors that interact with those processes, too. This is a scope of my stakeholders. At the beginning of my project, I srtrive to model this first off. I get agreement from the sponsor and steering committees if this is correctly understood. On a technical side, if you do not adhere to Use Cases too strictly, Context diagram is a good depiction of the process interactions too (where Hierarchy diagram does not show).

Context Diagram is not:

• It does not show all the "detail" processes in your scope.
• It isn't a picture of stakeholders' relationships.

Notation

...aahh well this is tricky

Context diagrams were commonly used in SSADM. Where high level Processes, Information and Actors (including systems) where defined in one go. You would then break down each process further to show another level of the context, each process broken down in more detail. UML ignored Context in its early days but soon caught up. Now (officially) you have Use Case Contexts too. Becuase it is te heasier type I am tackling that one first. Following is a notation for Use Case Context Diagrams.

Example

Following shows a very simple use of Context diagram used in SSADM - it shows that the European Direct Debit process consists of: Mandate Management, Payment Authorisation, Payment Capture and Clearing and Settlement processes. And it shows that Creditor, Debtor as well as Creditor Bank, Debtor Bank and Clearing Agents (Clearing Houses) can act on these processes. Any combination of Actor/Priocess can be taken over and fleshed out as a Use Case in its own right. e.g. you know as an anlyst you need to look at Creditor Bank Managing Mandate separate from Creditor Managaing Mandate. This guides your analysis - if ultimately you find out that the Use Case in both cases are identical you may then combine them - but the analysis process must be independent or you'll compromise understanding delicate rules and in (from my opint of view) disrespect the importance of these actors cotribution to the process.