SRS Plan of Attack

How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables – what would you do?

The Lay of the Land

Your IT director knows she needs something to give to her development and test teams. She’s looking to you to tell her what it is you need to deliver. Oh – and while it isn’t explicitly a constraint, her expectation is that you’re looking at something less than a couple of months of effort. To increase the pressure a little, she also tells you that her program will likely have a steady, ongoing need for requirements development – for now, she needs a “single capability” defined.

Her approach is really pretty rational. She’s rolling out a brand new initiative for the company. The initiative will drive tens of millions in profits for the company. There is a huge user base, there are stakeholders all over the globe, it is a “high pressure” environment – very visible internally, high external pressures, and there’s a palpable sense that continued employment is dependent on the success of the initiative.

There is an ocean of work involved in this particular initiative. Your director’s initiative needs to demonstrate momentum, so instead of boiling the ocean, she’s releasing new business capabilities incrementally. She’s working with the business stakeholders and customers to define “what first”, and then she’s working with internal teams to enable those capabilities one at a time. Each business capability is being treated as a distinct program – distinct funding, staffing, and timing. Sort of an “enterprise agile” – certainly an incremental approach.

The capability that she needs next (she has already prioritized it as “next” for the initiative) is also needed by other directors, for other initiatives. The enterprise IT folks intend to leverage the capability across many different programs and areas of the business. Each program has common and distinct needs, and different timing objectives. There are many moving parts involved in defining this capability across a multi-billion dollar enterprise.

Your mission is to figure out how best to validate your customer’s approach, identify what she needs, and estimate what it will take to make it happen – given the above environment. Do you try and boil the ocean, defining the requirements for the business capability across all the initiatives? If not, how do you define and manage deliverables for this one program?

One At A Time

There’s an interesting dynamic that comes into play when working with teams across and within an enterprise architecture. You have to think about the big picture (the ocean) in order to really understand things. At the same time, if you try to accomplish all of the needs of the disparate teams (boiling the ocean) at the same time, you will fail. Each group has its own dynamics, politics, deliverables, hangups, issues, and pet “favorite features.” If you try and tackle all of them at once, you will get mired in the bog of analysis paralysis and never make forward progress.

The best way to knock down all the dominoes in this case is to knock them down one at a time. Think of it as sequential product releases, each one targeted at a different market segment. Because that’s really what it is. As you build out a business capability (like “provide hosted service X”, or “sell products online”) for each program you are identifying a different set of internal stakeholders, end users, and often, delivery and test teams. They are independent projects that happen to share a lot of goals.

Dominoes make for a great analogy, because although you start out by knocking down the first one, you knock it towards the second one, with the intent of knocking them all down eventually. The more you understand about the other dominoes, the better a job you will do in knocking down the first one. But you have to focus on the first one first. The other knowledge provides context, and hopefully understanding that leads to insights.

Knock down the first one first.

How Much to Do?

You can approach this top-down (as we normally do with structured requirements), or bottoms-up. Either way, you end up with the same answer. We’ll work backwards in this article – since we’re identifying the deliverables, not creating them.

• Software Requirements Specification (SRS). We already know we need this – because the development and test teams at the company expect to work against an SRS. If your company uses something else to communicate requirements to development and test, substitute that artifact here.
• Fact Model and Glossary of terms.  Explicit agreement about language and terms is critical to avoiding confusion and ambiguity.
• Use Cases. The requirements in the SRS are defined to support use cases and goals. So we need use cases. The team you are working with, and the complexity of the business needs / processes will influence the format that works best.
• Actor Hierarchy and Personas. You have to identify the actors by role, and the personas that describe them.
• Business Requirements Document (BRD). Describes the goals of the business stakeholders.
• Vision & Scope Document. Describe the vision for your program, and its scope. Especially valuable in avoiding ratholes in this environment – be articulate about what you are not doing. Set expectations that the second domino is second – only the first domino is first.

You can reverse this list to create a top-down set of deliverables: Vision & Scope Doc, BRD, Actor & Persona definitions, Use Cases and SRS.

And Estimating…

The devil is always in the details when it comes to estimating. How long will use cases take? How many interviews will you have to do, and do you need to travel to do them? And a hundred more questions.
We aren’t trying to tackle the estimation details here – too many project specific variables, and as I just read somewhere, “estimating is more of an art than a science.” Although you can apply some science to expose and mitigate the risks around your estimates by using PERT analysis.

But now you know what you should deliver, and what you now have to go estimate.