Home > Ask the Software Quality Experts > Software Requirements Questions & Answers > Clarifying software requirements
Ask The Software Quality Expert: Questions & Answers
EMAIL THIS

Clarifying software requirements

Karl E. Wiegers EXPERT RESPONSE FROM: Karl E. Wiegers

Pose a Question
Other Software Quality Categories
Meet all Software Quality Experts
Become an Expert for this site


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


>
QUESTION POSED ON: 09 April 2007
I'm often faced with incomplete or confusing requirements. The client does not specify a clear requirement, but simply says "I need a product that can do such and such work." Hence, creating test requirements becomes a difficult task. Please give me some insight on how to handle projects when the requirements are not clear.

>
EXPERT RESPONSE

Unfortunately, we can't expect customers always to provide nicely structured, clearly written, unambiguous, and complete requirements. And no matter how good the written requirements are, they are never going to replace human dialogue. This is particularly a problem when software development is being outsourced and there are limited opportunities for interactions between customers, developers and testers to clarify and flesh out requirements.

It's important to recognize that requirements development is an iterative and exploratory process. The requirements analyst typically begins with some initial ideas and thoughts from the customer (or client, or end user). Sometimes the customer provides a description of needs, sometimes he proposes a specific solution he has in mind, and sometimes the customer just provides bits and pieces of information in an apparently random sequence. Through discussion, skillful questioning, use of prototypes and other techniques the analyst and the customer attempt to reach an understanding of exactly what the customer's needs really are and exactly what kind of software solution might meet those needs.

In this situation it sounds as though the role of a requirements analyst might be lacking, which results in the delivered requirements being inadequate for your needs to develop tests. The best solution is to have a skilled analyst work with the client to develop requirements focused on user goals, such as use cases. The analyst can then determine what functionality must be implemented in the software to satisfy those use cases. Use cases also provide an excellent starting point for developing tests.

Alternatively, you might ask the client to develop some acceptance criteria. That is, how would they determine whether the product was doing what they needed it to do in a manner they found acceptable? Those acceptance criteria can serve as a starting point for developing more formal tests, as well as clarifying the requirements and the customer expectations.

More information:


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


RELATED CONTENT
Software Requirements
Use cases and SRS for requirements gathering
How to choose the right requirements tool
Why you should test requirements definitions
How to estimate change requests in requirements
Use cases: Who writes them, what data do you include?
How use cases facilitate the SDLC
Requirements engineering in an uncooperative environment
Scrum and requirements gathering
Requirements reporting beyond use cases
Requirements gathering with storyboards

Software requirements techniques (Prototyping, Storyboards, Modeling, State transitions)
Requirements tools that empower business analysts
Why you should test requirements definitions
How to estimate change requests in requirements
Requirements gathering resources, practices lacking at Fortune 500 companies
Teams turn to use cases, user stories to ease requirements gathering challenges
Requirements engineering in an uncooperative environment
Scrum and requirements gathering
Requirements gathering with storyboards
How to capture performance requirements -- Expert Webcast
Book Review: Just Enough Requirements Management

Use cases and misuse cases
Use cases and SRS for requirements gathering
Use cases: Who writes them, what data do you include?
How use cases facilitate the SDLC
Requirements reporting beyond use cases
Test cases from requirements specifications and use cases
Approaches to defining requirements within Agile teams
Getting started with Web application misuse cases
Developing use cases that support business goals
Requirements gathering, SRS and use cases
How to effectively elicit user interface requirements

RELATED GLOSSARY TERMS
Terms from Whatis.com − the technology online dictionary
requirements analysis  (SearchSoftwareQuality.com)

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary



Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and answer pairs from more than 250 TechTarget industry experts.
Browse our Expert Advice

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