Even if there are some standard ways of finding and defining requirements the methods must always be adjusted to the actual situation. It is also important that all participants in a project actually realize that they finding requirement. It is almost impossible for a or some persons to perform findings since a whole range of business and technical areas my crossed and affected by a coming change. Normally the workflow of finding requirements can be managed by one person, a Business Analyst. Business Analyst also manage the flow of change requests and secure that the requirement process works smoothly.


Different methods to gather requirements must often be combined at the same time. Most important is that requirement are gathered into one source, are understandable, and aligned.

It is also a fact the choice of method is effecting the end-result, and therefore it is very important to make a good choice. The choice of method is made on a variety of aspects. And it is also a fact that no matter of what method that is used, there is not one single method that covers all variants and depth of the requirements. The methods have to be combined.



Interviews is a common way of finding information. The interviews can be done in several ways. It can be by meeting stakeholders and go through prepared questions and ongoing issues. It can also be planned to give a brief of new demands or of identified need of change. The interviews also gives a knowledge transfer how the business works and can be useful for the team when communication to other stakeholders or suppliers.


A Business Analysts can setup and facilitate workshops to be able to gather a lot of information during a short period of time. A workshop brings the requirements specification phase into a joint effort among the stakeholders. The different stakeholders can together find new ways of thinking and needed changes in common. Workshops can be performed in many ways and with different focus areas to address wanted areas.

Use case or User stories

The team based on speculation and common sense can write requirements. Of course, the requirements needs to be detail studied by stakeholders before going further. Anyhow, the joined result must be stated into one source of requirements. It can be in different documents or in an appropriate requirement system. Findings can be formatted in a) lists of requirements, b) use case descriptions, c) user stories, d) etc. Most requirements also need its context descriptions as flow charts and high-level descriptions. This also joins different requirements and must secures that they can co-exist.


To be able to communicate with some stakeholders, prototyping is an important way of describing requirements. A prototype can be created for a specific reason, to maybe prove the concept of solution or state parts of user interactions. A prototype can never describe all requirements that is needed, but for stakeholders its must easier to locate fails or new needed finding.


If stakeholders are physically distributed over the globe, different surveys are a good way of collect information or gather feedback on unique requirements. It can also be used if information is supposed to be gathered from many stakeholders or many people within a targeted user group.


If needed, targeted user groups can be observed in their daily work or when interacting with the function that is supposed to change. The observations can also be done if users are invited for an observation session when user interaction with pointed functios. The team can then find issues or fails with currents, or future, solution.