Clarifying software requirements
Software requirements engineering is impeded by unclear, indeterminate requirements. Expert Karl E. Wiegers explains how analysts can clarify requirements with users.
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:- Ambiguous software requirements lead to confusion, extra work
- Software requirements analysis: Five use case traps to avoid
- Software requirements: Using models to understand users' needs
