How do you know when the requirements are done?

In my earlier article, I talked about the 5 key points I hit during the requirements & design process. But even within that framework, it can be hard to know what level of detail to go into for each of the five requirements areas.

The short answer is: There is no one-size-fits-all.

The longer answer, as always, is a lot more useful.

You’ve Got to Find the Sweet Spot

Getting the right level of detail in your requirements & specifications is more art than science. Don’t panic just yet though, you don’t have to be Vincent van Gogh to figure it out. There are some guidelines you can follow.
Ask 3 basic questions of yourself:

1. How are my relationships with my developers?
2. How are my BA / BSA skills?
3. What constraints is my project up against?

How Are My Relationships With My Developers?

Don’t look at me like that, I’m serious. How are your relationships? Are you looping your dev team into conversations early on in the project, or do they find out about the work when you finally throw a printed copy of your 285-page spec over the cubical wall to them? If it’s the latter, then I know why your spec is 285 pages long. It’s because you don’t talk to your developers enough.

How you interact with your dev team has a huge impact on how much detail you have to put in your Req’s & Spec’s. Your requirements can be done much faster if you’ve built open communication and mutual trust.

Keeping Them Engaged Helps You Find the Sweet Spot.

When I’m asked to produce requirements & specs, one of the first things I do is to run things by the dev team. As soon as I have some idea of what the solution looks like, I find out who is going to be leading the development on it, and I tell them that I need 30 minutes of their time. 

Sometimes they’re too busy and don’t wanna hear it, but most of the time they’re happy to get filled in because they know it’ll make their lives easier down the line.

In the meeting, I walk them through what I think the solution is going to look like (at a high level) and encourage them to speak up if they have any objections. The Sr. developers in your company understand technical constraints better than anyone else. If they say something is not going to work, then I know that I need to go back to the drawing board to re-think parts of the proposed solution.

Throughout the requirements process, I keep asking them for their opinion on the things that I think may cause problems down the line. These conversations help me “feel-out” where the dev team needs the most details, and which parts of the solution they can put together on their own. By keeping the dev team engaged, I know exactly where to put most of my effort and where I can afford to skimp if I need to.

This is also how I judge whether my requirements and specs are done or not; I feel out the situation to see when the dev team is satisfied with the level of detail, then I move onto the next part of the scope.
Like is said; more art than science.

An Ounce of Prevention = A Pound of Cure

By the time I release the specs to the dev team, they already have a pretty good idea of what needs to be done. And my requirements are way more implementable than if I had just gone off on my own and drafted a gigantic document with no development input.

What’s even more beneficial is the fact that the developers have already vetted the requirements & specs themselves. This means that there will be far fewer questions for me when the dev team starts the build. An ounce of prevention just saved me a pound of cure.

Not All Developers Are Made the Same

Of course, not all bad relationships are your fault. You’ll always run into difficult people who don’t “work well with others”. In a future post, I’ll talk about the different “types” of developers you’ll run into, and things you can do to work well with them.

The Takeaway

1. Working closely with the development team will give you the best indication of when your Requirements & Specs are “done”. Building good relationships with them will help you be more effective as a BA and will also make your life easier.
2. Relationships are a two-way street and not all bad relationships are entirely your fault, but you should be doing everything in your power to cultivate good professional relationships with your development team. You’d be surprised at how much unnecessary documentation you can cut out of your deliverables when you talk with, and have trust in your developers. Same goes for QA.