Briefing Study: Requirements Analysis and Specification (slide 18)
Using the Dialogue Identification technique
The identification of dialogues is part of the wider technique of dialogue design (pretty much akin to use-cases) - obviously you have to identify them before you can design them.
However, with a supplier involved, they'll be responsible for the design aspects, eliciting required interaction from the users and doing design either in prototyping workshops or by using an Agile approach to the solution development.
You won't be looking to identify every single dialogue needed, just the critical ones. What makes one "critical" in the users' eyes can be down to many criteria. Characteristics to look out for are most used functions, function subject to seasonal peaks, shared between many user roles, large amounts of data, access many entities.
One of the matrices developed and built on during the project is the user role matrix. As function definition progresses, you will be able to build a user role / function matrix. Users representing each role will confirm the access to the functions they need, possibly identifying ones they don't need after all.
Each intersection identifies where a dialogue is needed, so you should have a starting point for identifying the critical ones. The I/O descriptions and volumetrics in the DFM should by now be in the Function Definitions and will help inform the selection of critical functions.
It's now over to the supplier to continue into dialogue design.
Good Practice tip
Keeping the project manager sweet
It is so important to have a good relationship with your project manager. A project manager and a business analyst are complementary roles:
- The PM makes sure the BA gets access to the resources s/he needs
- In return, the BA scopes out the work and provides the estimates of when their workstream's deliverables will be available for sign-off.
Your first estimate
You're doing a Terms of Reference, yes? If not, you'll still need to investigate and create the sorts of things that would go into it. Your estimate will be in the region of 1 to 2 weeks for the first draft, depending on the number of business areas in scope.
Your second estimate
You can only do this when you've completed the ToR to first draft. You'll be estimating the date when you'll have the Currrent Services Description (the as-is) ready for sign-off. Amongst other sections the Current Services Description is going to contain:
- A dataflow model of the As-is with dataflow diagrams for each business area in scope
- A logical data model featuring the business-level data entities involved and their inter-relationships
You use what's in the ToR to estimate how much effort to create the DFM and LDM and then sketch out when the work can be fitted in, to give an elapsed time estimate / timeline plan.
Say your DFD in the ToR contains 7 high-level processes. With the knowledge you have already gained about them, to investigate them, you might allow 1 day for some 2 for others and maybe 3 for the rest? Say, 1 at 1 day, 4 at 2 days and 2 at 3 days. 15 days effort spread over maybe five and a half weeks?
There, you have your estimate for when the Current Service Description will be ready for sign-off. Add that timeline plan into your ToR and that should complete the ToR. It can now be distributed to keep everyone in the loop and for sign-off
The key to adequate estimating is having a good understanding of the number of things to be done and an appreciation of how long each will take - perhaps with a fiddle factor to account for complexity.
With the business analysis techniques I advocate in this briefing study, the work you need to do to create the products and deliverables will, as a matter of course, provide you with everything needed for confident estimating.