Logo for Android

I am really enjoying having Logo on my phone. Making that little turtle run around takes me back to first learning about variables and sub-routines on an Apple ][e. Good times.

 

This is almost definitely my geekiest post ever.

---

This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. You should immediately delete the message if you are not the intended recipient. If you have received this email by mistake please delete it from your system; you should not copy the message or disclose its content to anyone.

This electronic communication may contain general financial product advice but should not be relied upon or construed as a recommendation of any financial product. The information has been prepared without taking into account your objectives, financial situation or needs. You should consider the Product Disclosure Statement relating to the financial product and consult your financial adviser before making a decision about whether to acquire, hold or dispose of a financial product.

For further details on the financial product please go to http://www.bt.com.au/general/rse.asp

Past performance is not a reliable indicator of future performance.

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.

Building Living Specifications

Producing new functional requirements for each project is evil and should be illegal, and punishable by death or working as a tester [1]. It is a basic cause of incoherent system, lack of holistic system thinking, and a lack of coherent documentation to support testing.

We've all had the experience of trying to understand the behaviour of a system and wading through reams of the original specification, change requests, and series of follow-on project specs, so why do we willing perpetrate this mess?

Probably a few main reasons:

1) The model of monolithic documents being prepared, signed-off, and developed against encourage this beahviour.
2) In the short-term it's the fastest way to get your individual project over the line
3) It's how we've been taught to do it
4) When we do decide to do something about it, we don't get angry that we're documenting badly, we get angry that we're documenting _at all_, and we implement some messy mix of agile and waterfall.
5) Wanting to have "all the information in one place" for decision makers (Which is a really valid point)

So what can be done about it? I'd generally propose a few changes that don't involve a massive change to current practices.

1) For new projects try to split out the project ephemera from the functional design that will be re-used.
2) Instead of having a singel plave for all project documentation, have a seperate place for storing project documetnation, system documentation, and process documentation. This reinforces that they should be treated seperately.
3) Gently ease into some business architechture questions, because if you're not using projects as the basic unit of information, you're going to need soemthing to replace it, and a system centric-organisation is a pretty poor substitiute.
4) Get some soom document/knowledge management systems. Shared directories will not work if you're moving towards lots of smaller documents. Consider Sharepoint as your first stop, and moving towards a Wiki and a Modelling tool in the long tem.

All of these mitigate against most of the objections I raised earlier, but they still don't give you the "single view" of the changes you're making for the project. Unfortunately there's no magic-bullet here. The more solution centric you make your documents, the less project centric they become.

Ideally you could mix-and-match content together into dynamic documents. But there's just no good tools for that, confluence is closest but really isn't there yet. There's a good summary of why up at http://confluence.atlassian.com/display/DISC/Using+Confluence+for+professional+documentation.

[1] Nothing against testers. It's just that most BAs hate working as testers.

Business vs Functional Requirements: I don't care.

Either I’m getting very lazy or I’ve reached a new point of sophistication in my BA practice because I really don’t care that much about the difference between business and functional requirements anymore. Maybe I’m just sick of the fact that it’s almost a point of pride for people to have their own definition.

Not to mention that fact that half of the time the “business” requirements aren’t from the business they’re from customers or regulators, and that “functional requirement” documents include non-functional things like service-levels and look and feel.

Half the time I don't even consciously differentiate between business and functional requirements. I just elicit a bunch of requirements, get the business to sign off to confirm that it looks like we have a shared understanding, and then specify a solution separately.

For me that's the big separation between classes of documents that BA produce

* Elicited Requirements: Documents conversations and consensus with stakeholders, embodies a shared understanding of situation, with the BA's role being mainly a drawing out from stakeholders.

Elicited requirements could be business, functional, stakeholder, objectives, KPIs, NFRs, show tunes, user stories, wire-frames, or just whatever works best for all stakeholders to communicate.

This is a big mess of "business" and "functional" requirements.

* Specified Solution: Documents a single concrete solution that addresses the situation embodied in the elicitation stage, with the BA's role being to design a solution based on the elicited requirements.

In this model I end up collecting mostly "functional" requirements.

I grant this represents my background working as a system integrator. In a fixed-price environment you really want to manage scope by keeping all that vague text in the elicited requirements separate from the model.

This has always worked well for me, with the following provisos:

* Traceability between elicited reqs and the eventual solution is key. You need to show where you took into account all the things your stakeholders said.

* You still need to understand the difference between business and functional requirements on some level so you know where you can implement something differently from the user request (And note it is such in your traceability)

* I’d never talk like this to someone just starting out as a BA. I think when you’re starting out you need to be much pretty dogmatic about the difference between stakeholders expressed needs, and their underlying objectives to avoid becoming an over-paid stenographer.

Customer Needs, not Functionallity

My Lamy ink pot is so well designed that every time I refill my cheapy $30 fountain pen I get a real sense of satisfaction, because everything just works.

I can feel that they've actually though about:

how a customer will use their product,

the acions they'll take immediatly before and afterwards, and

what place the product has in the customers life.

An inkpot is a fairly simple thing at it's heart. You just need ink in a well sealed container, lamy obvioulsy have great ink, and athe container closes tightly but it's a few little additions that make me willing to pay the %20 price premium over their competitors.



Lamy's have added two main feautres:

An integrated dispenser for plastic backed tissue paper around the base of the ink pot

A little reservoir in the bottom of the pot so that it's easy to get your pen or bladder all the way into the ink, even when you're down to the last of the ink.

So; from a BA point of view what have Lamy done that is so applicable to software design?

Firstly - they didn't think about themselves as providing a function (Ink, Email, holding customer records) instead they saw themselves as supporting an activity (Refilling a pen, communication, communicating with customers). By looking at a wider business-process context they were able to better integrate multiple functional components into something useful to the end user.

From a BA POV they took a wide process, and collapsed distincy activities together by providing a single interface that matches what the customer wanted to acheive. This is putting the customer's needs first, and the functionallity later.

Secondly - they looked at the whole lifecycle of usage. They introduced features that covered the whole product lifecycle, giving the customer unexpected bonuses towards the end of their product use; which usefully for a retail product is just when they're about to re-order.

But what's really great is that there's a synergy between the two, that little reservoir on the bottom is what paper dispenser clips to. There's also ongoing revenue from selling paper refills.

The only thing it's really missing is a way to easily open it when the ink has dried the list shut, maybe if base coudl be made square'ish you could get a grip more easily?