To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.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.
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.
|
