Home > Ask the Software Quality Experts > Software Requirements Questions & Answers > How to communicate with the client for effective requirements engineering
Ask The Software Quality Expert: Questions & Answers
EMAIL THIS

How to communicate with the client for effective requirements engineering

Rob Apmann EXPERT RESPONSE FROM: Rob Apmann

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: 05 December 2007
We are having problems with the client and communicating the product features. Some look good in prototype but may not work. How do I communicate these to the client without angering the client? Also how do we keep from adding on too many things?

>
EXPERT RESPONSE

My initial reaction to the question leads me to believe that an exchange between yourself and the client does not happen on a regular basis.

Make it part of your "process" to involve the client at every step of the way. Finding out something cannot be done late in the delivery cycle is more painful than finding out shortly after seeing the initial prototype. If you can work with your client in a more agile fashion, you can make many small changes and tradeoffs more often, fine tuning the implementation as you go along. Before either of you know it the feature will be done, and there will not be any shock that it does not meet expectations.

Another way to help with this problem might be to focus more on the value that your client wants to achieve from some particular feature, rather than the implementation (prototype). Consider capturing the requirements in the form of user stories or use cases, each with a clear goal or expected end result. Make sure your client agrees with those expected results. This helps to direct the focus of requirements validation away from the specific implementation details and onto the end result. The downside to a prototype is that if the end product does not look just like the prototype the client may see that as a failure, or view it as incomplete, even if the desired goal is achieved. A mix of both prototypes and stories or use cases is probably necessary; just don't expect to capture all of the requirements in a prototype.

Software requirements gathering:
Software requirements analysis: Five use case traps to avoid

Software requirements gathering techniques

Ambiguous software requirements lead to confusion, extra work

Being agile is not to say that you do not need to understand the big picture early on, it is not an excuse for ignoring things such as performance or architecture requirements that must typically be built in from the very beginning. However, for either you or the client to understand and document "all" of the requirements up front is not realistic. Have regular conversations, make decisions and tradeoffs on a regular basis, and hopefully you can avoid delivering a sudden surprise to your client, when it does not turn out just like the recipe said it would.


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


RELATED CONTENT
Software Requirements
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
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

Software requirements techniques (Prototyping, Storyboards, Modeling, State transitions)
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
Approaches to defining requirements within Agile teams
How to elicit performance requirements
Software requirements sign-off essential for solid QA

Use cases and misuse cases
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
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