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:


Sound Off! -   Be the first to post a message to Sound Off!


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


RELATED CONTENT
Software Requirements
Requirements engineering in an uncooperative environment
Scrum and requirements gathering
Requirements reporting beyond use cases
Requirements gathering with storyboards
How to elicit performance requirements
Developing use cases that support business goals
Requirements discipline throughout the SDLC
The difference between gap analysis and requirements analysis
Software requirements elicitation and documentation
Requirements gathering for payroll application

Software requirements techniques (Prototyping, Storyboards, Modeling, State transitions)
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
Approaches to defining requirements within Agile teams
How to elicit performance requirements
Software requirements sign-off essential for solid QA
Requirements Management Using IBM Rational RequisitePro: Chapter 1, Requirements Management

Use cases and misuse cases
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
How to communicate with the client for effective requirements engineering
From use case diagrams to context diagrams
UML made Jacobson's use cases state of the art. What's next?

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