When you are trying to define product requirements, you have to use a top-down approach. You don't have to focus on features, but on value. After all, this is what we need to deliver to our Customers! We don't have to be a "feature factory", we don't need to flood the Customer with things they will barely use. We need to delight them with things they need, and that will relief their pains. The definition of requirements is essential to accomplish this, but how can we do that? I'll describe - as an example - the development of an office suite. This is our vision: build an office suite that will enable us to do our job better.

Themes (topics)

First of all, we need to define the themes. Themes are high level descriptions of the major areas that should be covered by the project. In our office suite example, the themes may be:

• app to send chat messages
• email client
• app for taking notes

Epics

Each theme is further refined into epics. The definition of what an epic is "per-se" is quite hard, since usually epics are simply represented by a functionally-related group of user stories. In our example, if we look only at the chat app, epics could be:

• send a text message
• send an audio message
• send an image

User Stories

Epics are then granulized to the level of detail of user stories, which are characterized by the acronym INVEST: independent, negotiable, valuable, estimable, small, testable. They are called "user stories" because they are the description, from a user's perspective, of a specific functionally independent requirement. What's more, each of them represent an added value for the customer, and it includes clear functions that can pass quality assurance and User Acceptance Test. If we look at the epic of sending a text message, user stories may be:

• write text in a message box
• use rich text formatting
• see the button for sending the message
• see if the message is received One conventional way of writing user stories is "As a (type of user) I want to (do something) so that I can (accomplish something)", but this is not mandatory.

  Tasks

  Tasks are the technical level of user stories. Each functionality requires a lot of technical activities. The tasks for the user story "write text in a message box" may be:

• design user interface
• develop the front-end part
• establish the back-end

Take-aways

The benefit of working with an Agile methodology, is that all requirements don't have to be specified in detail at the beginning of a project. A team may start working with a single epic and just a few user stories clearly defined. All other information and requirements will be specified during the sprint, as more knowledge becomes available, and feedback from the stakeholders may be incorporated.