I've heard a lot about requirement gathering and use cases in theory, but in practice often happens that we ask ourselves "should we include this? should this be a use case? in which language should we write this particular requirement" and so on. These questions are mainly because of lack of practice, and since we cannot go picking projects to "learn in practice" it's a little bit hard to get used to the kind of thinking we need in the process of gathering requirements for a new app.

In that case, is there some place where can I find real life examples of requirements gathering and application of use cases? I've found some books, but they are mainly focused on teams and I work alone, so it becomes a little confusing.

closed as off-topic by Bart van Ingen Schenau, gnat, Kilian Foth, user53019, Doc Brown Nov 14 '13 at 12:54

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Bart van Ingen Schenau, gnat, Kilian Foth, Community, Doc Brown
If this question can be reworded to fit the rules in the help center, please edit the question.


A simple example. You assist a user who tests your e-commerce product. At some point, the user wants to get every product matching given tags within a price range. Currently, this is impossible, because the product allows to filter products by tags or to filter products by price, but not both at the same time.

The users' need would be:

I want to filter products by tags and prices. How do I do it?

Transformed into a user story, it would become:

As a user, I should be able to filter the list of products using both tags and prices criteria.

From that point, you may study the implications of the new change and start to write tests and implement the new feature.


In practice Requirement gathering should occur first and then followed by use cases (and you could have a feedback loop to verify the requirements). The case that you describe of "should we include this" , "should this be a use case" comes up mostly in product development environments. Making this choice is tricky based on your appetite for risk and your team.

If however you are trying to develop a solution for a client the question really is "Does the client need this" and nothing more. You may encounter situations where the client really does not know what he needs, in that case I would recommend you to go even deeper and understand the business problem that needs to be solved. Once that is clear the technical solution can follow. In such scenarios I would usually recommend short iterations and an incremental solution with active client participation.

In which language should we write this particular requirement

Are you implying a programming language ? In that case that is definitely the wrong question to ask during requirement gathering. The technical implementation is usually decided much after the requirement gathering phase.
First there should be a technical solution like say a web-app, mobile-app, middleware, integration , db solution etc.
You could have hints thereabout ofcourse if say your client has a .net shop or java shop or deals with a particular vendor or even worse is vendor locked-in. Even then the first thing should be the technical solution and based on time/budget/resources/misc conditions the technical implementation will evolve.

Unfortunately books can only hint at various scenarios, and the best learning is in practise.

  • +1 for "and you could have a feedback loop to verify the requirements" that snippet of a sentence alone. In order to get a solid set of upfront requirements it is almost essential to iterate between the use-cases and requirements document. – Dunk Nov 14 '13 at 15:53
  • Thanks for your answer @Sunny, you clarified a lot of things. About the language, I wasn't talking about programming language, I was talking about the way to write things: in a formal and technical way, or simply as the customer told us. I know that programming comes much after the requirements gathering. – user1620696 Nov 19 '13 at 16:35

You get use-cases from your users or clients.

Essentially, they drive the acceptance criteria.

Without talking to users or clients we can think of many possible use (patterns) for our software, but it's the users or clients who should be telling us which ones are the keys.

On the other hand, users will often come up with ways of using our software that we had never considered, and in the process find bugs. This is how successful software evolves and generates new requirements.

Think of use cases as user cases.

  • Not that I want to be nitpicky, but considering the OP seems to not have any experience in the use-case/requirements area, I think saying that use-cases come from the users or clients is misleading. While there may be some users/clients who have the background to give these to the developers, almost all users/clients will simply tell you what they want to accomplish (at a high level) and it never covers everything they need. It is then up to the developers to define the use-cases and identify the missing functionality necessary to have a working system. – Dunk Nov 14 '13 at 15:58

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