How to understand what the customer wants?
Do you have any questions? Contact us!
I agree the Terms of Service
published November 20, 2019
Commercial projects' customers often do not know what they want to get from the developed project. Of course, the customer has an idea of what he wants to get as output: process optimization, analytics tool, user-friendly interface, etc.; however, as a rule, the very idea of achieving a result is very, very abstract.
Commercial projects' customers often do not know what they want to get from the developed project. Of course, the customer has an idea of what he wants to get as output: process optimization, analytics tool, user-friendly interface, etc.; however, as a rule, the very idea of achieving a result is very, very abstract.
Defining requirements is one of the most critical stages of product development, whether it is a desktop, web, or mobile application. Before you start collecting requirements, it is necessary to identify all interested parties - people who will use the system are also called stakeholders. The more accurately this list can be formed, the more complete the requirements will be. Stakeholders can be managers, department heads, directors, any organization employees who will at least somehow interact with a ready-made solution and whose requirements, wishes, ideas, needs, problems are essential to consider when developing. It's good practice if the stakeholders are represented by one person who collects these requirements and reports to the development team; as a rule, they are the product owner.
Each project developed by the Attractor Software team is precisely tuned to the customer company's processes. As our motto says: We use technology to extend boundaries and connect people, businesses, and ideas for the better.
Most often, the collection of functional requirements occurs through interviews (personal meetings with the customer or using a call). Typically, such meetings are attended by the customer, project manager, and business analyst. The task of the development team representatives is to find out during the conversation:
Most often, the collection of functional requirements occurs through interviews (personal meetings with the customer or using a call). Typically, such meetings are attended by the customer, project manager, and business analyst. The task of the development team representatives is to find out during the conversation:
✦List of Terms and Definitions
✦Description of Business Roles
✦Business requirements
✦General system scenarios
✦System Use Scenarios and Verification Algorithms
✦System and non-functional requirements
✦Integration requirements
✦User interface requirements
This method may seem relatively easy to many, but it is not. A good interview is hard enough. It is necessary to ask as many open questions as possible, respond flexibly to the interviewee's answers, and, if appropriate, change the order of the questions prepared or their wording and help customers formulate the desired idea.
✦Description of Business Roles
✦Business requirements
✦General system scenarios
✦System Use Scenarios and Verification Algorithms
✦System and non-functional requirements
✦Integration requirements
✦User interface requirements
This method may seem relatively easy to many, but it is not. A good interview is hard enough. It is necessary to ask as many open questions as possible, respond flexibly to the interviewee's answers, and, if appropriate, change the order of the questions prepared or their wording and help customers formulate the desired idea.
Everything discussed at the meeting is fixed in the list of functional requirements submitted to the customer for approval.
Next, from the list of functional requirements, we select many tasks that must be implemented for a certain period - a sprint, the duration of which is discussed between the development team and the customer. For example, during the designated time, the team performs tasks and implements the planned functionality for two weeks. At the end of the sprint, the feature is demonstrated to the customer. The customer has the opportunity to test the developed application, click on buttons, fill out forms, and much more, to understand whether this corresponds to his ideas about the product, to make sure that the implemented functions are convenient to use.
Next, from the list of functional requirements, we select many tasks that must be implemented for a certain period - a sprint, the duration of which is discussed between the development team and the customer. For example, during the designated time, the team performs tasks and implements the planned functionality for two weeks. At the end of the sprint, the feature is demonstrated to the customer. The customer has the opportunity to test the developed application, click on buttons, fill out forms, and much more, to understand whether this corresponds to his ideas about the product, to make sure that the implemented functions are convenient to use.
In turn, the customer gives feedback for the already created functionality and wishes for the new features , which will be implemented in the following sprints. At the end of each sprint, the customer receives an updated product.
So, for the next sprint, a new task list is selected that matches the functional requirements of this project. At the end of each sprint, the customer has a completed version of the product - part of the ready-made functional that can be transferred for real users use. And so the process goes on continuously until all the requirements are realized. Our approach to work helps to understand whether the customer is moving in the right direction, whether the market needs it, whether it is spent correctly. In our approach to development, we try to satisfy all customer requirements, which can change during work without significantly stretching the project's budget and timelines, providing our client with high-quality software.
So, for the next sprint, a new task list is selected that matches the functional requirements of this project. At the end of each sprint, the customer has a completed version of the product - part of the ready-made functional that can be transferred for real users use. And so the process goes on continuously until all the requirements are realized. Our approach to work helps to understand whether the customer is moving in the right direction, whether the market needs it, whether it is spent correctly. In our approach to development, we try to satisfy all customer requirements, which can change during work without significantly stretching the project's budget and timelines, providing our client with high-quality software.
We understand that the best way to build our future is to help you make yours and are always happy with new unique ideas. Let's discuss your project!
Did you like this article?
Share article on social networks
Worked on the article:
Maria Ilchenko
PR and Event Manager
Oksana Budnikova
Senior Software Project Manager
