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?

  • I'm afraid the question might be too broad for this site ( how to gather busines requirememts and translate them into a development spec). Can you narrow it down to a particular challenge? Nov 15, 2012 at 6:49
  • To gather business requirememts
    – Larry Lo
    Nov 15, 2012 at 6:51
  • Hi Lo Wai Lun. You might try editing your post to focus on describing what you don't understand about the requirements gathering process. What part of it has you stuck? Definitely, narrowing the scope of the question would be really helpful. :)
    – jmort253
    Nov 15, 2012 at 7:04
  • already updated
    – Larry Lo
    Nov 15, 2012 at 8:06
  • Hi @LoWaiLun, I believe that J's question is to understand where specifically you got stucked on. What have you done so far? If you don't know where to start from (and at least for me it seems to be the case as the question stands now), then your question is indeed too broad, as Mark stated. In this case, take a look at the [requirements] tag here in PMSE (pm.stackexchange.com/questions/tagged/requirements), progress on your requirements and when you have punctual questions, update this question with further details.
    – Tiago Cardoso
    Nov 15, 2012 at 14:54

4 Answers 4


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.

  • I have already made the pretotype but when it comes to discussion , almost all of them are re-discussed again because of not meeting the standards and requirements
    – Larry Lo
    Nov 16, 2012 at 2:48
  • then I'm afraid you have to do it over and over again, because it is worse if you develop something the customer doesn't want (most probably won't pay for it either)
    – Zsolt
    Nov 16, 2012 at 12:00

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.


"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.

  • 1
    Although prototyping may be a good asset, one should be careful using it. Some clients focus on what a prototype is is not (yet) doing, instead of what are you trying to demonstrate. So it may be hard just to say, "here there will be a login screen". They don't understand why you skip it in a proto and go ahead. Nov 19, 2012 at 17:59

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.