A few weeks ago I was looking for a new set of lockable office drawers for my home office. Not far from me, there’s an excellent second-hand shop that sells all sorts of assorted furniture, so I thought I’d pay them a visit.
I arrived at the shop, and there was every type of furniture item that you could imagine – plus a few items you wouldn’t expect! There were tables, chairs, dolls houses, even shovels and forks. The shop was utterly jam packed with all sorts of interesting and intriguing items. In fact, it was so rammed-full of furniture, I couldn’t even get inside. I didn’t even know where to start looking, so I gingerly peeked around the door. After about five minutes, I managed to attract the shop owner’s attention. He clambered over the furniture to reach me, and I explained what I was looking for. He immediately knew where I could find the exact thing I wanted, and pointed me in the precise direction of a practically new set of lockable office drawers. I bought them and took them home. They were an absolute bargain too!
On the journey home, I was reflecting on this rather unusual experience. The fact was that the shop was so jam-packed with furniture of every imaginable type that it was virtually impenetrable to the average customer. The only way you’d be able to find what you were looking for would be to ask the owner. I started to think about how in some cases we might be tempted to treat our requirements like this.
What this means for requirements
On some projects, particularly those that require a high level of formality, we might create a large number of requirement artefacts. We might create deliverables and artefacts including a context diagram, use cases, non-functional requirements, a logical data model, a glossary and so on. We create artefacts that are jam packed with precise and concise information. As the author, we’ll instinctively know where to find everything in our requirement set – but what about the recipients? How do they know which artefact they need to look at to find what they are interested in? How can we stop our requirements becoming an unregulated “junk shop” where everything exists, but stakeholders can’t find what they need?
This is where the art of requirements organisation and packaging comes into play.
Some tips that can help
Firstly, when it comes to requirements reviews, it’s vital that each stakeholder or reviewer knows:
- What they are being asked to review
- Where in the requirement set they can find it
It’s extremely valuable to explicitly point this out when sending requirements packages prior to review. Rather than sending a blanket e-mail, it can be valuable to provide a tailored reading and review list for each stakeholder.
It’s also essential that the overall requirements package has a logical structure. This might be within some kind of repository, a dedicated requirements management tool, or even in a spreadsheet or word processing package. If you’re using a word processing package, you might choose to separate the requirements out into separate modules or packages so they are easier to digest – perhaps with one document acting as a ‘wrapper’ and setting the context for the others. It’s even possible to ‘hyperlink’ documents together (although beware the hazard of out-of-date links!).
The best requirements structure will vary by project, and there’s no single ‘one-size-fits-all’ approach. I’m a fan of using some kind of context diagram or high level functional model to set the scene and act as a ‘table of contents’ for the requirement set. For example, a use case diagram acts as a great ‘table of contents’ for the functional requirements – the detailed underlying use case descriptions and scenarios can then be cross referenced with the data requirements, business rules, etc. There will almost certainly be cross-functional requirements too; many non-functional requirements apply to the whole system.
The key is to have a logical structure that works for the project team and the wider stakeholder community. It’s important to avoid creating an uncontrolled ‘junk shop’ set of requirements where everything is present, but nobody can find it. Version control and maintaining some form of central repository is also important. It’s key to consider these things early on so that the requirements can be built and structured in the right way.
In summary: Well-structured requirements packages are easier for our stakeholders to digest. It’s worth thinking about structure early, so we create the right artefacts and communicate them in the right way. This will help us avoid the “junk shop” effect!
I hope you’ve found this article interesting. How do you package, structure or store your requirements? I’d love to hear from you – please add a comment below.
About the author:
Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.
To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com
