Requirements Analysis and Specification

Lifecycle and Techniques for a Data Processing Environment
- with a supplier designing and delivering the required system

To follow this briefing study guide you'll likely be a good fit to some of:

• a student following business studies or a computing-related course
• a project manager looking to understand BA work better
• an agent in one of the freelance agencies, looking to be able to communicate better with a potential client by improving your knowledge of Business Analysis and its techniques.
• a junior do-it-all-using-notes-and-ad-hoc-diagrams business or systems analyst
• a systems analyst who wants to move into business analysis
• an in-house BA in an organisation that's a bit chaotic, looking for something to bring a quantum change in quality to the work for the minimum impact, pereto style (if you do nothing but DFDs, you'll see a sea change).
• freshly out of university and working for one of the big consultancies

If you're in the last category, you have some great qualities: energy, enthusiasm to learn, inquisitiveness and so on. You know how to take relevant notes quickly, you know how to learn, you know about deadlines… all really relevant... and you know how to celebrate project achievements, too!

But the ones I bump into in projects I get involved in, often don't seem to have a set of structured tools in their toolkit - and don't know how to interpret the resulting models when people do use them.

Some of the big consultancies don't seem to support their analysts too much in this respect, expecting and getting a hodge-podge of analysis results documentation (spreadsheets, meeting notes, flip-chart sketches, powerpoint slides), with only tenuous connections between the products that get developed. Everything all seems kind of ad-hoc. And this doesn't lead to systems that users expect to get, ones that meet their requirements and whose design supports the way they want to work. Business representatives need to sign up to a comprehensive model that expresses their requirements in business terms, diagramatically and with rigour.

The purpose of this Briefing Study guide is to define an optimal set of techniques that delivers a Business Requirement Specification to an external supplier. From the specification and the access to the business users for design decisions, the supplier will be able to prepare a fixed price quote for the system covering logical design, physical design, code, build and internal test.

The cut-over point, where the supplier responsibilities start, is carefully chosen so that they are not constrained in proposing a solution but still have a detailed enough requirement specification so that in meeting it, the business gets a system fit for purpose.

Your Briefing Study practitioner is Mark Ridley, Senior Consultant with Crocus Information Ltd. He has been a Business Analyst involved in requirements capture and specification since 1990. He has worked with a number of structured methods, majoring in the pragmatic, appropriate and tailored use of SSADM (Structured Systems Analysis and Design Method) in data processing environments for public and private sectors.