Home > Software Quality News > Requirements gathering resources, practices lacking at Fortune 500 companies
Software Quality News:
EMAIL THIS

Requirements gathering resources, practices lacking at Fortune 500 companies

By Jennette Mullaney, Associate Editor
20 Aug 2008 | SearchSoftwareQuality.com

Software quality news and advice
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google

Proper requirements analysis is a major contributor to software project success, but a recent study of business analysts at Fortune 500 companies revealed that resources and best practices are often lacking when it comes to this crucial phase of the software development life cycle.

The role of the business analyst is increasingly important for aligning IT organizations with businesses.
Theresa Lanowitz
Founder, Voke Inc.

The study, "The Role of the Business Analyst" from Web analyst firm Voke Inc., found that the average Fortune 500 software project costs $3.2 million and takes 1,290 months to complete. Yet only 37% of respondents answered "yes" when asked if their projects met users' needs.

While those numbers indicate a high amount of waste, Theresa Lanowitz, founder of Voke and co-author of the study, said they may serve as a wake-up call to those in upper management.

"Those at the C-level are seeing that software really does drive the business," she said. "The role of the business analyst is increasingly important for aligning IT organizations with businesses."

Inadequate tools
Business analysts, whose roles are central to requirements definition, don't have the proper tools to complete their work, Lanowitz said. Microsoft Word was the most popular tool among respondents for requirements gathering. "Even a small project might generate a big thick Word document of 15 pages of requirements," she said.

Considering that over three quarters of business analysts responded that they manually write test cases from requirements, a less static tool would be far more appropriate, Lanowitz said.

"The business analyst is looking for a tool that is very dynamic -- versus static -- and once they get those dynamic tools that are coming onto the market, we'll see a big, big boost in productivity," she said.

Multiple responsibilities and fractured communication
Business analysts usually find their attention split between requirements definition and another major duty in the SDLC, the study found. Most BAs also participate in project management, testing, design, or some combination of those roles. Multiple roles mean that "most business analysts have a lot of responsibility and not a lot of authority," Lanowitz said.

Voke's study characterized communication between business analysts and IT architecture and operations as "chaotic or reactive." Additionally, as the IT market expands across the globe, scattered stakeholders create another barrier to communication.

Requirements gathering techniques and tools
Software requirements gathering techniques

What requirements gathering technique should you use?

Teams turn to use cases, user stories to ease requirements gathering challenges

How to choose a requirements gathering tool

Ideally, Lanowitz said, business analysts would report to a separate "center of excellence" or centralized team. A centralized group, Lanowitz explained, would "continue to push that alignment between enterprise IT and business more closely."

More time for requirements needed
Too much of the SDLC is spent in rework, Lanowitz said. The development and testing phases dominate the lifecycle in less mature organizations, she said. These phases are in inverse proportion to the requirements gathering and design phases, which make up larger chunks of the SDLC in optimized organizations.

"When the design is laid out, there is so much more you can do in testing; you're so much more efficient in coding," said Lanowitz. "There's less room for error and interpretation."

For business analysts who find themselves mired in rework, Lanowitz is confident that attitudes are changing in upper management and organizations are realizing how important requirements definition and business analysts are. Organizations "should treat their business analysts as paid consultants," she said.

Until then, Lanowitz recommends BAs "survey their own organizations." They should enlist support, lobby for enhanced communication, and advocate automation to eliminate waste, she advised.



Tags: Software requirements techniques (Prototyping, Storyboards, Modeling, State transitions)Software requirements toolsVIEW ALL TAGS

Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google




Software Development Methods - Extreme Programming, Agile Programming, Scrum
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of technology-specific Web sites, events and magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Reprints  |  Site Map




All Rights Reserved, Copyright 2006 - 2008, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts