Benefits of a Continuous Requirements Gathering Approach In Software Development
Don’t worry if the phrase “continuous requirements gathering” is new to you, odds are you employ the concept at some level in your current waterfall style workflows, or even in your everyday routines. Anywhere from inquiring whether a client’s needs are satisfied by an upcoming, in-development feature set, or making sure you have enough funds in your bank account to cover a tank of gas before driving to the station on fumes and possibly becoming stranded. The end goal may be clear and the path set -- deliver a working product suitable for the target audience, or getting groceries with which to make a dinner for five, respectively -- but in truth, every step of the way requires awareness and evaluation of the current circumstances in order to adapt and keep a process moving forward. This meshes well by design with the short and frequent cycles of an agile development approach, though the methods and stages should still be familiar to veterans of traditional software development, both when working with clients and internal processes.
Most projects are conceived of a well defined need or opportunity, perhaps for a client of another industry in need of expertise, or of and for a development house itself looking to expand their offerings. Typically, some details need to be solidified before proceeding. What exactly is the target audience, or in other words, who are the end users? As such, is the product’s concept appropriate for them in terms of learning curve and usefulness? From there, what is the intended feature set they are to be presented with? What is it supposed to do for them? Can it integrate well with existing technologies or is it intended as an all-in-one platform of sorts? Appropriately open-ended questions are essential here in discovering real requirements, which are not simply budget or campaign-rooted deadlines and price ceilings handed down from upper management. They are hard-earned from careful analysis of the answers received.
Several avenues should be used to get the most out of your questions. One-on-one interviews with the client’s staff and/or potential end users can yield personal perspectives on specific usage and expectations. Shadowing the role of a user may give answers they wouldn’t have thought to tell you to questions you wouldn’t have thought to ask. Having them teach you about their tasks will allow you to understand their role and needs better. Though more generic surveys and market analysis are useful tools and should certainly be used, this directness and openness is essentially the inverse approach and should prove much more insightful. Group interactions can also be very helpful, as brainstorming sessions or workshops involving people both in and outside the project or company.
At this point, user stories become essential for taking what was learned, exploring various scenarios and explaining them to the rest of the team, and helping to refine the real purpose of the product and desired experience when using it. If you’re not yet familiar, you may want to check out this article on user stories.
For example: “Mr Smith needs to to access X and do Y with it while on a particular device or at a certain location [we’ll say mobile]. He discovers through Z means [targeted campaign, etc.] that our software will do this, decides to give it a go, and installs it with no hassle [e.g. online store]. A central dashboard intuitively guides him to feature XY, with which he’s able to accomplish the task from his phone, saving him time.” The above would be considered an “epic” and can be more comprehensive than is useful. Although we do need to consider exposure, installation method, and so on, a simple one-liner would suffice. “As a broker, Mr. Smith can keep track of his investments on the road.” The number and diversity of such cases is key to further planning.
So now we have an idea of what we want, but it would be wise to put the brakes on for a minute and check the feasibility from engineering and resource standpoints before committing to any estimates. Already the process is starting to loop back on itself in sort of a continuous way, even in waterfall development, and that’s not a bad thing. Is the concept actually possible given the technologies out there? Are there team members available that are well versed in those technologies, or are new hires or outsources necessary for certain aspects like low-level programming or custom hardware engineering? Is there enough funding and workpower? What is the time window to get the product to market? What level of maintainability and expandability is desired? What additional research is needed to fill in the remaining gaps? Provided a proof of concept is successful, now we can get on to more entertaining stages of development where things actually start to get rolling. User interface and interaction design, wireframing, prototyping, and continual testing throughout the first iterations, no matter how big or small your development cycle is.
Everything so far should seem quite familiar no matter your style, but this is where waterfall and agile methodologies really start to diverge. Traditionally, the product’s feature set is locked in to avoid complications, the team works toward the conclusion of that version, one last internal loop is made through quality assurance and back through development if any problems are found, and the product is shipped. Any feedback from the client or end users, positive or negative, will drive the beginning of the next development cycle, where it will be analyzed using the same steps, almost as if it’s a completely new and different product.
There are many problems with this, most of which stem from longer cycles. If anything at all changes throughout the development push, concerning time, funding, client needs or expectations, market shifts, or anything else that would undermine the product’s success, either the team will be forced to clumsily shift gears, likely burning up valuable time with replanning and engineering, or they will have to ignore it completely for the time being with the promise that it will be addressed in the next cycle, dissatisfying the client and users, and vicariously the team. It’s also possible that by the time it’s ready to deliver, it’s not what’s expected or wanted anymore, and the effort is for nought. The solution is to integrate continuous telemetry back into the development process, drawing from all of the same sources we started the project with.
This is the essence of continuous requirements gathering. The use of real time information gleaned from feedback and outreach on all fronts to steer a project in smaller degrees rather than sharp, stalling turns. Whether driving a monolithic semi-trailer or nimble SUV, if a map is available on a road trip, better to consult it regularly than blast along the highway for hours before coming to a closure or realizing all you needed to do was take an off ramp two states back. A huge element to using this successfully is openness, internally and externally. Do not hesitate to communicate with clients and the team. No secret planning meetings or sly feature decisions. If something isn’t working out either big or small, whether it be a particular line of code, feature, design, a budget restriction, or the client relationship on the whole, it should be addressed, and those concerned should not be afraid to do so through the proper channels. Nobody likes a bad relationship or impossible hurdle, and doing nothing about it benefits no one, especially if one could have looked out the window and made adjustments.
Such continuous shifting does invite complications and confusion, so as requirements change, and they will, thorough documentation is vital to ensuring the team stays on the same page and is able to maintain the same vision. In more linear development with larger cycles there may not be as much room for adjustment, but all involved should be apprised of changes as they arise, and as a result will be more able to address them along the way. Frequent meetings are the norm in agile environments and may seem trivial and a bore at times, but requirement updates are no less important there because changes can happen so quickly from week to week that misfires may result. A room of confused developers asking what they’re supposed to be working or not working toward is never a good thing.
No matter your particular environment, with a little self-testing it should be possible to integrate continuous assessment techniques into your model and experience both flexibility and productivity gains, as well as improved working relationships between team members and clients alike. For extended reading on continuous requirements gathering as it relates to agile software development, you may wish to peruse the guide Gathering and Managing Software Project Requirements and the many subsections and references therein. Or, for an extremely in depth look, there is the book Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World, of which a section specific to requirements gathering begins on page 55. Also available online is an overview of dos and don’ts at a more general level, Requirements Gathering Blunders and Best Practices.
