One of the key aspects of an analyst's work is proper communication with the client. You can spend a lot of time trying to guess what the business needs if you don't ask the right questions.
The Standish Group study showed that incomplete requirements and specifications, as well as changing requirements, are among the TOP-3 causes of IT project failures. Conversely, clear statement of requirements is named the third most important reason for the success of IT projects.
In the previous article we explained what requirements are and how they are gathered. Here you will learn several lifehacks that will help you avoid typical mistakes and improve the quality of a business analyst's work.
"I Meant Something Different"
When communicating with stakeholders, start simple: understand what specific problems your project solves and ask for examples from real life. Recording requirements on paper alone is not enough. Fortunately, modern tools allow creating visualizations and even working prototypes without developer labor.
To avoid misunderstandings and complaints during the presentation of the finished product, software consultant Karl Wiegers advises business analysts to obtain the client's signature at the requirements validation stage. This is not always possible, but a good practice is to conduct written approval of key points. This will help avoid disagreements at the final stages of the project and speed up the implementation process.
Lack of Information
Companies often lack full documentation: no formal business processes, no preservation of necessary data. In such cases, the first step is to identify key stakeholders and experts who possess the information. Second, solving the information shortage problem is helped by visualization of key processes and reverse engineering — which will allow you to restore missing links and better understand existing processes.
This is especially important for identifying bottlenecks and inefficiencies that can be eliminated during optimization. Reverse engineering also helps systematize data, turning it into a foundation for further documentation and analysis.
If sufficient time is available, the "fieldwork" technique can be applied. In this case, the business analyst goes directly to the company and documents processes "from the inside." During observation, clarifying questions can be asked and paths for optimizing business processes can be identified. An alternative option is to embed a client representative into the development team. This allows for timely evaluation of development progress and implementation correctness. However, this method is also quite labor-intensive and requires time for employee adaptation.
Missed requirements — which often include functional ones relating to system quality and architecture — are very expensive to add after the development process has begun. The only way to avoid a situation where a system has thousands of users and a critical update needs to be released is to be proactive.
Donald Firesmith from the Software Engineering Institute advises planning in advance for "rainy day" scenarios (when something goes off plan) and, in addition to use case diagrams (what people and systems do), creating for each scenario business process diagrams (how they do it) and even sequence diagrams (which specify technical details and functions).
"It Looked Different in the Picture"
Often stakeholders and end users have a clear idea of what the new solution should look like, but don't understand what it should do. The user interface is an important aspect of any system, but it should not define or limit its functionality.
Business consultant Julia Kornienko (Breadcrumb Digital) advises ensuring that documentation has a clear separation between design and functional requirements. To focus on functional aspects, it is better to use more abstract tools, such as diagrams, user stories, and low-level prototypes, rather than design mockups.
Several diagrams can replace a hundred pages from a huge requirements document. At a minimum, this will help quickly present concepts and make it easier for specialists to understand your presented ideas.
How to Avoid Ambiguities: Several Proven Techniques
-
Event Storming: A team of diverse specialists (developers, domain experts, etc.) visualizes business processes using a board and colored sticky notes. During the brainstorming process, the team can not only obtain a draft model for developers, but also exchange knowledge and improve collaboration.
-
Never forget the human factor. Alan Cooper, author of "The Inmates Are Running the Asylum," advises being meticulous when gathering requirements:
"Clients often talked about some new things they would like to see, but did not mention features that already existed in their existing software or browsers that they took for granted. Since they didn't mention these features, they were never added to the technical specification and were never implemented."
-
Personal meetings are best suited for reaching consensus and prioritizing requirements. If you prepare in advance using the MoSCoW technique, you can validate all priorities right at the meeting.
-
Make sure your document is understandable not only to the client but also to the development team, testers, and managers. Record and number collected requirements and indicate their sources. This will be very helpful later when questions arise about the implementation of a feature during development.
-
Justify collected requirements — developers need a rational and reasoned reason for making changes.
"The process of architecture design, development, implementation, and testing becomes more complex, expensive, and time-consuming" — Donald Firesmith, Software Engineering Institute
He advises using a user-friendly tool to record the requirements themselves, the date of their receipt, changes, and their sources. This process should occur at all stages of the project.
The Kazakhstani ERP platform Darlean allows recording and prioritizing requirements in the project module. In addition, the system has many tools necessary for running your own business, including employee training functionality, document management, and process management.
