Q
Problem solve Get help with specific problems with your technologies, process and projects.

Clarifying software requirements

Software requirements engineering is impeded by unclear, indeterminate requirements. Expert Karl E. Wiegers explains how analysts can clarify requirements with users.

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.

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:
This was last published in April 2007

Dig Deeper on Software Requirements Gathering Techniques

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close