I’ve seen many approaches to requirements & design over the years. Here is one that I’ve seen play out more than once:

1. Design out the business processes.
2. Generate a list of user stories.
3. Hand them off the to the development team.
4. Pat self on the back and walk away with a feeling of accomplishment.

“But wait a minute!” you’re thinking. “Is that all I have to do as a BA?”

The short answer is: No.

The long answer is a lot more useful. Bear with me here.

What Do The Developers See?

I always urge analysts to look at things from the developer’s point of view. When a developer receives something like this, they often see it as a list of unrelated items on a wishlist with very little thought put into the solution.

There is very little “systems thinking” in the requirements. Developers can’t build anything meaningful with this level of detail, and so they’re left to fend for themselves. They begin the painful process of poking and prodding the BA and the SME to tease out the details that they need.

“Its like pulling teeth” I’ve heard one developer say.

And when they’re not able to get the details they need, they resort to some pretty drastic measures to “be on time” with their deliverables. They start taking uneducated guesses of what the solution is supposed to be, and in doing so, they introduce a huge amount of risk into the project.

This increases project costs (the price of re-work); and in the worst of cases, it has the potential to bring down the entire project.

User Stories Are Just The Starting Point

I hold myself and my BA team members accountable for hitting 5 key points during requirements & design. User stories make up a small part of this framework:

1. How does the business function?
2. At what point in this process do users interact with the system?
3. What are the business rules that the system has to enforce?
4. What is the structure of the business data (business entities)?
5. Are we clear about the life-cycle of the key business entities (how are they born? how do they live? when do they die?)

User stories fit into point #2.

If you’ve produced a list of user stories, chances are that you’ve answered point #1 in order to get the list. And if you’ve left your requirements off at just the list of user stories, then you’ve covered about 5% of point #2.

Your business stakeholders are happy because you’ve made their part of the solution relatively clear.

Your technical stakeholders? Well, let’s just say that they aren’t as enthusiastic about your work; and they have good reason to be concerned.

You Need To Provide More Detail

I sometimes get push-back from analysts when I insist that BAs are as responsible for the solution as they are for the requirements. BAs need to start thinking about the solution from the onset of the project. 

Not all the answers are going to be clear right up front, but “systems thinking” and solution thinking needs to be there as soon as the project is being conceived.

So What About Points #3, 4, and 5?

I’m going to talk about these in much more detail in future posts. The training program I’m building will also help BAs learn how to apply this entire framework to their requirements & design.

The Takeaways

1. Recognize that your output as a BA has huge downstream impacts.
2. Understand that meeting the needs of your downstream stakeholders (the dev team) are as important as meeting the needs of your upstream stakeholders (the business side).
3. Learn what it takes to make sure your downstream stakeholders have what they need to build a solid solution.  A little bit of “systems thinking” will take you a long way to help meet the developer’s needs.