Elicitation can be a tricky activity. Often when needing to understand the requirements for a particular project, the temptation is to jump straight into facilitating a requirements workshop or holding stakeholder interviews. The challenge, of course, is getting enough stakeholder time, and knowing which questions to ask with the limited time available. Understandably, business stakeholders are often too busy running the business to attend meetings, workshops or interviews.
It’s important to come prepared with as much information as possible, and the technique of document analysis can be extremely useful. It’s possible to use document analysis to gather information about the business domain and/or the problem being solved without taking up too much stakeholder time.
So what does document analysis mean? Well, in essence, it just means “finding out what relevant documentation the enterprise has, and reading/referring to it”. This is something that you almost certainly do intuitively, but by consciously planning it you can expand the scope of documents you consider. Here are some document types to look out for:
Forms: If you are examining a process that involves paper forms, ask to see a copy of the form. This will tell you a lot about the process! It will help you to understand the data that’s collected, and it might even hint at the business rules that apply (e.g. you might find that the form states, “All applications over $3,000 must use a form XYZ2”. You’d then know that something different happens in these circumstances).
Business Architecture diagrams: These will often show who does what, where and which business services are in-source/out-sourced etc. They can give you a macro-level view of your domain.
Process or procedure diagrams: Often operational areas keep documented copies of their processes. But beware: They might not be up-to-date, and people on the ground may well be doing something subtly different (so it’s always worth following up with interviews/observation).
User guides/help screens: If you’re working with an existing system, user guides and help screens can help you to understand the “as is” screen-flows. They might even hint at underlying process logic and business rules.
Previous requirements documents: Sometimes, you might strike gold and find that a previous BA has produced a full set of requirements for the system or process that you’re aiming to change. If so, this will be an excellent reference point, but remember that not all requirements get implemented, so it’s worth checking whether anything was de-scoped.
Customer complaints: Sounds strange doesn’t it? But customer complaints can often give you great insight into where processes have broken down. If you’re working to fix or improve a process or system, it’s well worth finding out whether there are any related customer complaints.
Defect logs: Sometimes, business users will keep logs of “pain points” and perceived defects on systems that they work on. Sometimes these will be on a central defect management system, but sometimes they’ll be kept informally on Excel logs or in paper files. Ask for a copy. It’s very useful to understand which parts of the process or system are causing pain.
Product/service promotional material: Often the marketing material for a product or service will give you an insight into how it works. For example, if you are working on a project that involves making change to an Investment product, then the existing prospectus/brochure provide a whole range of useful information about the “as is” product.
Document analysis is a great way to quickly gain enough information to ensure you’re asking the right questions. It can help you quickly get up to speed, and ensures that you’re using stakeholders’ time effectively. A quick initial 5 minute phone call to ask, “Do you have any of these documents, and if so could you send them to me?” can really pay dividends.