Eliciting and managing requirements continues to be a problem for development organizations, according to results...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
from a recent SearchSoftwareQuality.com reader survey. Practices are evolving, though, with the adoption of principles of agile and lean, interest in visualization and social media technology and emphasis on ease of use.
For the past two years, respondents have reported that requirements gathering is the area that organizations have the most difficulty with, followed by process improvement and software testing and quality assurance.
However, the percent choosing requirements gathering as the most difficult, did decrease this year from 30 percent to 22 percent, while the percent of respondents choosing process improvement rose from 12 percent to 14 percent; software testing and QA also increased from 12 to 14 percent.
In addition, those asked which aspects of application performance management they find most difficult, gathering performance requirements topped the lists this year as well as last.
Mary Gerush, an analyst at Forrester Research Inc., said more organizations have become more conscious of the affliction poor requirements can cause over the past few years. "Organizations have spent a lot of time putting good practices in place for other phases of the lifecycle, like development, project management, testing," she said. Now there's increased interest in the requirements area, she said. "There's more professionalization of the role of business analyst and what it means to be a strong business analyst."
Gerush prefers the term "elicitation" over "gathering" when it comes to requirements. "'Gather' implies passive, receiving information and passing it on. Elicitiation is suggests seeking the right questions and pulling information out of the stakeholders, to get requirements right up front. We're seeing more emphasis on requirements definition practices and tools and techniques than in the past."
In terms of requirements gathering techniques, user interviews followed by use cases topped the list for the second year running. The percentage of respondents citing user interviews dropped this year, from 67 percent in 2008 to 54 percent in 2009, while use cases increased from 50 percent to 53 percent.
Other requirements gathering techniques are user requirement models (37 percent) and focus groups/workshops (35 percent). Respondents to this year's survey also reported an increase in the use of user stories, from 26 percent in 2008 to 34 percent in 2009.
These results "jibe with what see most commonly," Gerush said. "Interviews and focus groups are very common and continue to be used. Use cases/workflows/swim lane diagrams we're seeing more focus on as visual artifacts; prototyping is growing. In a survey we did, 57 percent are using prototypes. We've seen an increase in inquiries related to visualization, prototypes and how that fits with requirements practices."
Another trend Forrester is seeing, she said, is the use of social media for identifying and elaborating on requirements. She said this trend is not necessarily in the IT shops, but rather in the vendor community. Software vendors, she said, "are starting to look at social media for understanding the requirements of people buying their products, so Twitter, blogs, etc."
Survey respondent and freelance IT professional Rick Pingry said he relies on user stories the most. "I then take the user story and drive out more detail in the alternate flows and call it more of a use case, based on the interactions with the system. I have used user interviews in previous projects, and they are critical to getting things started when you don't know what you need."
Joel Cranford, a survey respondent and business analyst at Nashville-based Healthstream, a provider of learning and research solutions for the healthcare industry, said his organization also relies on user stories. "We're moving away from waterfall to agile, and user stories have enabled us to move with more agility and focus. We begin with validated stories to establish the business rationale, then compose business rules, functional requirements and use cases for each."
Respondents were also asked which tools they consider essential to successful development. Requirements management tools topped the list of choices at 64 percent, a negligible increase from 63 percent last year. However, in 2008 project management/tracking tools was the top choice of 65 percent of respondents, but this year fell to fifth on the list of essential tools, dropping to 51 percent.
The second and third most important tools for respondents this year were bug tracking (62 percent) and functional testing (58 percent).
Results were similar when respondents were asked which tools are essential to agile development. Bug tracking topped the list (73 percent), followed by requirements management (60 percent, an increase from 56 percent in 2008), project management (58 percent) and functional testing (53 percent).
For Pingry, requirements management is not a big concern, he said. "I have the benefit of working right along with the people that are providing the requirements, and I am usually working alone or on a small team working on a pretty small project of limited scope, so to be honest, all requirements management tools seem like overkill to me. I write out early design documents in Word."
He added, "Bug tracking is pretty useful, and I certainly use it on small teams, but I am not much of a tools guy. I can keep a text file or Excel spreadsheet most of the time. I do like FogBugz [a project and issue tracking tool]."
Survey respondent Matt Griscom agrees with the tools cited as essential, but added that "it's better if they're not all separate tools. For example, requirements management and bug tracking tools can instead be one tool; for example, Microsoft Product Studio."
Forrester's Gerush said traditional requirements management tools are evolving. "The things we hear commonly about some of the requirements management tools out there for while is they're heavy, too complex, and often have more features than needed." Organizations that are still working on understanding requirements practices and getting them right, but that have already invested in requirements management tools, are finding that those tools are becoming shelfware, she said.
In a recent Forrester survey, Gerush said ease of requirements input and usability and ease of learning are features respondents said are important for requirements definition and requirements management tools. "Traditional requirements management tools are still evolving and vendors are hearing this message. And new tools are coming out with a strong focus on ease of use, particularly ease of getting requirements into the system because the business analysts are used to Word and Excel."
Barry Young, who oversees the requirements process at HealthStream, said his organization uses "a number of tools to capture requirements and are currently exploring different approaches to manage these requirements in a central place. One approach we are exploring is leveraging a tool used by the development team: [Microsoft] Team Foundation Server [TFS]. The product backlog is captured in the user story format as well as the acceptance criteria directly in TFS. If there are visuals or other supporting artifacts or documents that further flesh out the acceptance criteria, they are uploaded, or linked to, directly in TFS. This approach allows us to capture requirements with different tools but keep all of those assets centrally located."
HealthStream's Cranford added that the business analysts have had success with the iRise prototyping tool. "Its features for requirements management are less robust than some other tools, which ironically has been a good thing so far," he said. "It forces the BAs to be focused and precise in the narrative and encourages team collaboration and discussion on a daily basis."
However, Cranford said, "'People over process' is one of the tenants of the Agile Manifesto, so we have been spending more attention to delivering what is needed versus how to make a particular software tool work for us."
Young added, "One of our mantras is, 'Use whatever tool makes the most sense to provide what is needed.' For example, a requirement might be best explained or represented by a workflow diagram created in Visio or Excel might be the right tool to represent a dataset for a report.
Gerush said requirements look very different for organizations adopting agile methodology. "The processes are different and more iterative, faster and lighter weight, so the artifacts produced are more visual, lighter weight, just in time and and produced collaboratively with developers and testers."
She said the principles of lean are also having an influence on the requirements process as organizations attempt to get rid of waste and redundancy. But whether an organization adopts agile or lean should not preclude it from applying some of those principles to requirements, she said. "Organizations are looking at principles of agile and lean and trying to make requirements practices more agile and lean. You do not necessarily have to adopt agile methodology in order to use a user story. Why not use a user story in a waterfall project? So organizations are looking at what they can pull from agile and lean principles and apply them to the overall software development processes."