How to keep a requirements gathering discussion focused on business needs and not technical details?

Question

I'm certain that acquiring the business requirements from the clients and providing the work items for the developer teams are always a headache for experienced business analysts as well.

A few days ago, it was my first time to talk my clients, who ask us to develop an ordering application for the Windows platform. After that I was recommended to carry on the necessary research and summarize the business needs.

I am a fresh graduate of Information Engineering and I don't know much about software development processes, and I have less experience in discussing business proposals with clients about reducing operational costs and process improvements. Nevertheless, I had to draft a wireframe for our application along with all the possible use cases and architectural specifications.

At the moment it is hard for me to distinguish between the business analyst role and the programmer role, which I also have in our 3 men team, but I have to figure this out in order to be able to communicate with our clients.

So, what is the best way to collect business requirements?

Is there a good way to translate business requirements to software development requirements?

How can I gather business requirements without getting into deep technical discussions?

Answer 1

The easiest way is to organise a series of interviews with your clients. During the first session, you talk about the product, create some sketches either on paper or on the whiteboard about how the product should work (it may be a good idea to record the session with the permission of the clients). After that, you go back to the team, and together you create some pretotypes based on the gathered data and you play with them.

The pretotypes should give you ideas on the work you are facing, and most probably you'll also have a lot of questions. You call for the second session, where you give the pretotypes to your clients and ask your questions. The session should end with a set of use cases in a prioritised order. These uses cases will be your requirements. If you focus on the use cases, you can avoid talking about technical details.

Answer 2

As Zsolt mentioned, there's no other way to gathering requirements than getting in touch with the business.

As you mentioned that you're a fresh graduated, you may still consider confuse the differences between Tech and Functional Specs. If that's the case, you can take a look at this article from Joel: Painless Functional Specifications - Part 1: Why Bother?

At some point, he clearly states the difference between Functional and Technical specs (that might be the most obvious for everyone, but I haven't heard until reading this article):

• Functional Specs defines WHAT the application is going to do;
• Technical Specs defines HOW things are going to built.

Hope you have already seen this definition somewhere else. If not, hope it helps you now.

Answer 3

"So, what is the best way to collect business requirements?"

As others have said, working directly with business, managers and staff (SMEs), is the best way. Given that, you can't just ask what they want; that is an open-ended question. Creating a prototype is a good way to give feedback on the requirements, but it is much better if you have a grasp of the requirements first, or you may end up in an endless loop of prototyping.

So, ask the business what they need to do, and what information they need to do it; this post, Requirements Attack tells it pretty well.

Answer 4

Translating Requirements with User Stories

Rather than attempt to answer the whole question, I'm going to answer just the part about translating requirements because I think it's often the most misunderstood. You asked:

Is there a good way to translate business requirements to software development requirements?

There are many ways to do this, but one of the most useful agile techniques is the user story. A user story contains perspective ("As a ..."), a deliverable ("I want ..."), and some context ("so that ...") that provides a solid framework for defining the scope and technical tasks that meet the business requirement.

Of course, as an agile technique, user stories are inherently iterative. Mike Cohn points out that:

[A] user story...is incomplete until the discussions about that story occur.

In other words, while user stories are a great starting point for delivering value, they don't replace the need for ongoing interaction and routine feedback between the development team and the end users (or their proxies, such as the Product Owner).

No matter how far down the rabbit hole you go, you still need a feedback loop. For example, converting user stories to acceptance tests with Cucumber often builds an initial agreement (ideally using domain-specific language appropriate to the business) on what the specification really means. However, it's still extremely common to uncover additional use cases or hidden requirements only after a requirement is met, which then requires refinement or refactoring.

Here's a concrete example. I had a client that specified that they wanted all records from a database table to be available on a single UI screen---no paging, no Ajax or remote procedure calls, just local access to all records delivered in a single batch to the client. The feature was delivered, having met all the acceptance criteria originally specified...and was then redesigned because it didn't meet the performance expectations of the end users.

Sometimes this happens because the end result is unexpected or unanticipated, and sometimes it happens because the organization accepts business risk, betting that a shortcut will pay off. Whatever the reason, though, it's common enough that continuous refinement and re-evaluation are baked into agile development frameworks.

Requirements Should Be Living Documents

Most of the problems with project management come from treating the requirements document (whether a formal specification or a set of user stories) as an historical artifact. User stories make treating requirements as living documents more intuitive, and encourage informed discussions about scope, risk, and usability.

If end users and developers don't remain routinely engaged with one another in a tight feedback loop, it pretty much ensures that:

1. The business will ask for the wrong things.
2. The development team will deliver unusable things.

Requirement documents are, from one point of view, a proxy for end-user expectations. If you build a good feedback loop into your project and revisit the requirements throughout your project life-cycle, you will be in a better position to manage those expectations successfully.