Requirements gathering, SRS and use cases

Requirements gathering, SRS and use cases

If we are provided with only SRS documents, how do we design use cases out of it? I'm a beginner, please help.

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

I have seen software requirements specification (SRS) documents which contain both functional and nonfunctional requirements as well as diagrams, but I assume you have a document that is entirely textual and describes sentence-by-sentence, paragraph-by-paragraph what the application should do. There are a few things you might be able to do, but I would probably not spend a lot of time trying to convert the SRS into use cases.

The issue here is how to convince the team that there are better ways to gather requirements than writing an SRS. Writing use cases, building prototypes or simulations, etc.

There is no direct route from SRS to use cases, they are each a different way of capturing similar information. If you have a detailed SRS that someone spent a lot of time writing, I would suggest you use it for this project and try to keep track of the areas where the requirements are ambiguous, or parts of the document that generate a lot of conversation. A lot of conversation probably means that the requirements are not well understood.

Software requirements resources:
How to structure a software requirements document

Software requirements gathering techniques

How to effectively elicit requirements
Try using a different technique during your project to clarify those areas where confusion reigns. Try writing a use case, or capturing some scenarios and see if those methods make the requirements more clear. If those techniques work, then push to have them incorporated in the next project from the beginning, before the SRS is written. Perhaps you can slowly improve the process and methodology of the team by introducing new techniques that will aid in understanding and possibly replace the SRS.

This was first published in January 2008