In Praise of Context Diagrams

The context diagram is probably the most neglected part of a BA’s bag of tricks. Nothing gives you the ability to collaborate with people so easily on a solution. A single slide with a good context diagram neatly summarises exactly what some functional component does, and who it serves. Whether it’s for a whole company, a system, or a software component, the context diagram applies just as well.

There’s lots of fancier ways of doing the same thing that give you a lot more information on context, aims, implementation, and scope – but none of them are so useful as tools to collaborate.

The beauty is that all you have to do is sit people down in a room, draw a circle in the centre of a white board and ask people who uses it. You then draw the users around in an arc in the top half of the board. Then ask what systems we rely on, draw those in an arc in the bottom half. Now ask what each user/system does with the solution and draw these requests and responses in as the arrows between external participants and the system.

It’s not fancy, there’s no certification course, but it can be the most useful meeting you have the whole project if you get it right.

Also, if you’re an external provider you can make these diagrams look very slick as you’re not restricted by a particular notation or layout. These give you a great way to advertise your competence, while displaying that you’ve understood the context.

Now – tricks!

• If you’re scope doesn’t cover the whole diagram you can use highlighted areas of the diagram to show in/out of scope, or multiple stages.
•  The MS Visio shapes for work flow diagrams and departments are a great source of icons for actors
• Minimise the number of systems you show, it should be mainly about users, systems are only their if they’re really significant.
• Maximum of four lines between any one user and the solution
• The “solution” in the centre of the diagram doesn’t have to be a system; it can be an organisational function, group, process, physical object, or anything really.
• If it helps – think of it as a top-level data-flow-diagram. But I don’t even know if they teach structured design in IT courses any more so that may not help you.
• Each arrow from users/systems to the solution could end up as one or more use cases or as a story grouping.
• Arrows going between users/systems to the solution can be verbs to capture actions, or nouns to capture data transfer. If you can stay consistent that’s nice, but it’s not %100 necessary.

P.S. In fact now I come to think of it most of what I learn in Structured System Design is generally under-used by the larger community. Perhaps because there’s no industry consortiums or consulting houses to push the method like there is for UML, BPMN, RUP, Agile, and all the other usual suspects?

Traceability and Business Rules in Word

A really good LinkedIn question from Adriana Beal on LinkedIn prompted me to write-up a neat little MS Word trick that can be useful for managing requirements traceability or business rules in MS Word.

It lets you create create consolidate of text scattered throughout your word document in a grouped list at the end using the same mechanisms as Tables of Contents, Indexes, and Tables of Figures.

This lets you do things like:

Reference business rules throughout your document and then include them all in

one appendix

Show a list of all Use Cases in your documents

Show a list of which Users, Screens, Systems, or Data Entities are involved in each Use Case

These are the basic steps:

• Create a custom paragraph style in world name it something like "Business Rule"
  
• Every time you reference business rule in your document put it on it's own line and apply this style (In our project we had a special section in each use case for the business rules)
  
• At the end of the document create a custom table of contents that lists all of the Business Rules in your document (Right click table, click edit field code, select field options, and you can then select which word styles show up in your table of contents). The resulting field code looks something like {TOC \f \n \h \z \t "Business Rule,2,Use Case,1"}
  

If you want a sample document that shows how to apply this style I've shared one from drop box: Sample File Download. The major downsides are:

• It's restricted to a single document
  
• You have to be a bit of a word nerd
  

Honestly it's a realy pain, and if you have an options you should use a wiki or a real requirements management tool. This is just a last ditch option to make requirements in word a little more practical.

Guirella Centre of Excellence

It's "reccomended best practice" these days to have a BA Centre of Excellence for any decent sized organisation, and most pieces of improving the performance of the BA function in an organisation being with getting senior management buy-in for starting one. This is fair enough.

But what if you can't?

I knocked togather a few powerpoint slides on low cost, cheap, fast ways to improve performance of the BA function in your organisation if you can't do anything formal. Essentially it boils down to:

• Encourage social contact amongst BAs
• Do information sharing at informal brown-bag lunches
• Have a good bookshelf on-hand
• Have conversations about basic theories, i.e. "What is a requreiment?"
• Use BABOK and IIBA to enhance the "professionalism" of being a BA

This all comes down to encouraging self-directed learning, and a team pride in the BA role.

Guerrilla BA CoE

View more presentations from harrislloydlevy.