Briefing Study: Requirements Analysis and Specification (slide 10)
About using the techniques
The techniques described in this Briefing Study are cross validating, coherent and complementary.
Before you get on with looking at a list of the techniques, bear in mind that they are a means to an end, akin, say, to a sculptor's tools. The subject, its lighting and environment, and the medium being sculpted dictates overall approach and the extent to which the sculptor uses each type of tool.
Project profile influence
It's the same with the techniques here. The size and complexity of the project will hugely influence the extent and depth to which the techniques are used. For smaller, more straightforward projects involving a business change of narrow scope and tightly focused impact, you'd expect the barest minimum of technique use, perhaps developed as just one single document with embedded diagrams and tables of user requirements.
At the other extreme, you have projects that are complex, with processes that are highly regulated and with sophisticated business rules; perhaps industry-wide agreements dictate many requirements (as applies in financial services and utilities). Other attributes that make for complex projects are wide scope; wide-ranging impacts on many of the standard impact areas (Customer, Product, Process, Organisation, Location, Data, Application and Technology); success of the project is a critical success factor in achieving specific board-level strategies.
Whatever the size and complexity, the techniques are more than adequate for the job - they have the provenance of appearing in most structured methods. So they are a standard set of tools in the professional business analyst's tool belt.
One size doesn't fit all
They are not a panacea by themselves, though. They have to be used judiciously by an experienced practitioner. However, if you are someone with a shorter, informal background in analysis, then being armed with a working knowledge of these techniques and by working alongside a skilled practitioner, you'll quickly gain the required experience. And at the same time, prove to be a boon. It might even get you assigned to a project that otherwise you wouldn't be considered for.
By the way...
You have probably come across the term "use case".
You did know it's pronounced like "juice", yes? A use case is one particular case/example of the use of a set of processes in a particular way to respond to an event.
I just thought I'd mention it because I hear it mis-pronounced quite often.
Oh, and in this briefing study (because of its roots in SSADM) use cases are called "business functions".
Just for completeness, I'll mention it here. If your business analysis duties cause you to stray into the realm of the systems analyst, then you'd be doing "business function design with your users. This entails stringing together the lowest level processes in different ways, one for each event the system is to cater for.
And that's pretty much exactly what a use case is.
Transition from business to systems analysis
NB In this briefing study, we've said we'll only go up to the point where our requirement specification gets handed over to a supplier. This is at the stage of logical solution design and that's where the supplier will have systems analysts.
This division makes sense because solution providers will have their own internal tools, techniques and methods, perhaps using Agile and use case design, perhaps other methods.
By handing over at the logical solution design stage, it means their systems analysts can take the requirements to the next level of detail and produce their outputs in the form required by the design and development method they use in-house.
Of course, as a BA, you'll be keeping a weather eye on the systems analysts as they drive out the detailed requirements. You'll be making sure they clearly understand the business requirements from which they're working and you'll be part of the review team on the documents they produce.