Requirements: Are we there yet?
There is a tendency to want to plow through the requirements phase of an application development project, as in the sooner requirements are set, the sooner the coding, and then testing, can get underway. But the requirements process doesn’t proceed in a linear fashion, and nor should it, says business analyst Laura Brandenburg, founder of Clear Spring Business Analysis. “It’s a funny task. You go through the cycle quite a few times. You get closer and closer, but you’re not really done until you have a baseline spec.”
Instant Download: Your guide to introducing and maintaining continuous testing
The pace of application development has been increasing rapidly. Continuous testing is the only way to avoid bottlenecks. Download this PDF to introduce continuous testing in your organization.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.
What makes the process nonlinear is that you are not actually “gathering” requirements—you are eliciting information that helps define an app’s features and functionality, says Brandenburg. Although the term “requirements gathering” still gets a lot of play, it isn’t really accurate, because “gathering” implies that requirements are sitting around fully formed just waiting for someone to pick them up. Elicitation, on the other hand, is a complex process of getting information from stakeholders, interviews, surveys and other sources, then analyzing and validating the information, says Brandenburg.
A good business analyst asks questions of stakeholders, listens actively, clarifies what she hears and works to get alignment among group members. When Brandenburg leads a group, she says things like: “I heard what you said. We have an idea on what we want. Now let’s see if we tear this apart.” This back and forth takes place before you actually write down a single requirement, she says. “When you are ready to write down the requirements, you are working from a shared understanding.”
Her requirements projects typically include business stakeholders and a project manager. As ideas begin to crystallize, Brandenburg brings a developer into the mix as well. Developers are most effective when they are willing to listen and understand the real problem we are trying to solve,” says Brandenburg. “You want to involve them in the creative part of the process. They are engaged, they offer options, helping me and the business understand that more things are possible.”
Start the conversation
0 comments