A Requirements Gathering Journey
From a Mother Daughter Adventure to Software Development
Every year, my elderly mother and I meet in person to bond in a place we've never been before, a cherished annual getaway where we connect without distractions.
However, this eccentric, articulate, well-traveled, and comical woman is quite a handful. Her numerous travel requirements make planning a detailed and somewhat laborious process, filled with challenges, changes, upgrades, downgrades, and everything in between. Regardless, watching her make new friends and share stories she's saved all year to tell is an absolute delight and well worth the effort.
The good news is that she has a Systems Analyst with over 15 years of experience by her side, adept at the myriad skills encompassed by this role: the ability to fuse problem-solving, analysis, design, and technical acumen to understand and enhance the intricate systems and processes within organizations. Moreover, well-equipped to handle complex travel requirements.
It must be asked. How is it possible to equate planning an unforgettable holiday to System Analysis on a software project? It’s the same reason a solid System Analyst can be effective on a complex supply chain implementation one day, a financial system upgrade the next, and rearrange a group cooking tour at the Topkapı Palace the day after.
It’s all in how the requirements are collected.
Planning- Where are we going?
Inarguably, the first step in any software development project is Planning and Analysis. It lays the foundation upon which the project is built and how it’s ultimately managed. It’s well documented to be the most crucial step in the SDLC. At the crux of Planning and Analysis is gathering requirements. According to the Project Management Institute (PMI), organizations that have effective requirements management processes in place experience a higher project success rate compared to those without such processes. Additionally, studies have shown that projects with well-defined and validated requirements are more likely to result in higher user satisfaction.
The Business Analyst Body of Knowledge (BABOK) defines requirement gathering as “a set of activities that involve identifying stakeholder needs, eliciting requirements, analyzing and validating requirements, and documenting them in a formal manner.” While this statement is generally agreed upon, for this discussion, it will be scaled down to a more rudimentary interpretation:
Gathering requirements is the process of collecting and organizing relevant information.
And the first question we need to ask? Where are we going?
Who are we traveling with? A Stakeholder Assessment
System Analysts gather requirements from a range of sources using a variety of methods. Stakeholder Assessment is most often the first step in the planning phase and arguably the most important. Stakeholders take on many roles and positions within and around an organization. An open mind goes a long way in identifying who may have valuable input into a project's success beyond the usual suspects. They are engineers, product owners, designers, scrum masters, quality assurance, and end users. Understanding the lens through which they view their world, and ours will yield priceless contributions to the requirements-gathering process. Our stakeholders are our allies, our extended team members, and the best traveling companions we have.
Do the research- What will we do when we get there?
Systems Analysis, specifically gathering requirements, is always a group adventure and Stakeholders are our guides. Roles and technical expertise are important in understanding the immediate and extended team, but let’s take that a step further. Getting to know stakeholders involves more than initiating contact, organizing gathering sessions, and being effective at standard elicitation techniques. What do we know about the team we spend so much time with? What are their personality traits and how do those intersect with the dynamics of the overall team?
An empathetic and sincere interest in these details creates a roadmap to navigate a host of situations when we are aware of a stakeholder’s motivations, needs, and of the utmost importance, body language. Picking up on micro-expressions and subtle shifts in demeanor can lend context and clues to how a conversation is going and allow us to adapt and pivot quickly. While this is difficult in an ever-growing remote world, the use of consistent video calls goes a long way to achieve this. Listening for tonal inflections is another skill to hone in the remote world where video calls may not be possible. Subtle clues can tell us when the team is growing indifferent, uncomfortable, excited, or energized and allow us to steer a gathering session or refinement discussion in a direction that better benefits overall product success.
Will we need an interpreter? Speak their language
There is no repeatable prescriptive method for gathering requirements that will work every time.
Simply put, people convey and interpret information differently. To maximize effectiveness, a skilled System Analyst will seamlessly tailor his/her communication style to best fit the style of the client and/or given team member.
So how does the given stakeholder best convey information? Ask. The answer could be surprising. Some people are visual, some are ‘talkers’, and some are short and concise. Others are scenario-driven, rely on past experiences, or may require prompting to get a visual idea. Keep in mind, how people give information may not be the way they want to receive information. For example, the same user who responds excitedly to large brainstorming sessions when eliciting requirements may be more visual and respond best to flows, diagrams, and mind maps when absorbing requirements.
No matter where the journey takes you…. Have fun
Requirements gathering is the cornerstone of every successful project. A System Analyst never stops looking for opportunities to gather requirements, listening with both eyes and ears. Combining standard analytical methods to elicit information with a compassionate and sincere interest in the personalities and styles of individual stakeholders ensures that the most comprehensive and detailed set of requirements are mined.
Keep in mind your project is a journey. Your stakeholders are your traveling companions and not all stops required were on your original itinerary. That doesn’t mean they weren’t worth visiting. With the right attitude (and a flair for versatility), there’s no reason you won’t have a successful and memorable trip….. I mean, project.
