As a kid, playing the game ‘Telephone’ was a lot of fun! You start with a logical message and end up with something hilarious! While this is great as a game for leisure, the same is not true when gathering business needs from different stakeholders and translating them into technical specifications. Can you imagine what that would look like?
Adopting technology by an end-user in any business can involve quite a bit of a learning curve. Our previous blog examined how businesses have had to chart a course to succeed and thrive in the ‘new normal.’ However, some users may not be comfortable adopting new technologies, some may resort to using the paper-pen method, while some have spent a lot of time using obsolete systems, and they become resistant to change. “How do I use this application? What’s the process flow like? What data should I put where? What’s the logic behind what I see on the screen? How are the calculations done?” And the list can be endless. Fret not! Involving users early in the process while building the application, can help ease some of these difficulties. Working closely with BSAs to share their needs can assist with the gathering of business requirements, the first step towards elicitation of technical specifications.
Critical thinking is a crucial step before and during the documentation process. Raising questions with different teams from both business and tech, and then carrying out a thorough analysis of the use cases is imperative to understanding the main goal of the requirements. One needs to look at the bigger picture, think long-term and comprehensively determine all the necessary functionalities that would come into play. So, don’t forget to critique! More the critique better the outcome, and better the ability to respond to stakeholder questions down the road. Being assertive yet flexible and knowing when to be either of them is tricky.
Throwing in a lot of details can be time-consuming and exhaustive. However, diving deeper into multiple scenarios including edge cases aids in building a robust application. Including system validations are key to keeping a system from run-time errors and ensuring the integrity of data. Persistency of data is another factor that needs to be considered for accuracy.
Monotony can often mark the tone of a lengthy requirement, hence the need to break it down. Workflows, diagrams, and graphics add color and life to a narrative that’s pure verbose. But hang on, even though a picture speaks a thousand words, consistency is key here, as the text should accurately explain the pictorial representation and vice versa. Proofreading and reviews can lead to refinement while facilitating feedback and fresh opinions.
A good strategy to follow is keeping the language simple. Be clear, concise, and non-repetitive. Good documentation is one, that can be read and understood by both technical and non-technical people alike. Try wearing different hats like that of an end-user, a developer, a quality analyst, to have different perspectives on how each team member would read and interpret the content.
We at Auvenir follow these policies. The role of a BSA in Auvenir is one of a problem solver and team player involving perseverance, curiosity, and technical aptitude. We have a passion for analyzing, writing, and solutioning. This is also reflected in how we choose new candidates for the role. Like all our colleagues, our work ethic echoes the Auvenir core values of the team before self, forgiving mistakes, and to be bold and learn fast. Encouragement for work done well and shout-outs for the small and big things keeps the team motivated. As Arti Marwaha, HR Generalist, mentioned in her blog, just as we at Auvenir value our customers, we value our team just as much. Our knowledge sharing sessions create an atmosphere of constant learning and development, thereby leading to both personal and professional growth. So, happy writing and, remember to have fun along the way!