In present we have a lot of problems dealing with requirements. We have only internal customers, and we don't have a "standard" for gathering and managing requirements. Usually we don't get only general requirements from our customers, and of course they change them several times during development or even testing.
As a (partial) solution I've proposed to use Use Cases for Functional Requirements and to put in a place a Requirements Management procedure as part of (future) Change Management procedure. As a tool for handling requirements we want to use RequisitePro from Rational.
Do you think it will work ? If not, why ?
Sounds like an excellent start. A few things to be careful of:
1 - most people don't know how to write a good requirement; and the same is true for use cases. Just be sure that whoever is working with the customers to get requirements down is trained well on what things belong.
2 - make sure that if Use Cases are the main thrust of your requirements, you're able to extrapolate testable requirements out of them.
3 - there were recently two threads on this subject (similar anyway) where Elfriede mentions the chapters in her book "Quality Web Systems" that address using Use Cases as a main thrust of testing an application. In addition, one of the recent cyber seminars at Mecury's virtual users conference (click the banner at side to get there) was on Requirements Management Processes. The presentor uses and discusses Test Director near the end, but the overall process flows he defines are very good.
Thank you for your opinions. I will look for more details on Mercury's site, but about the Book that Jules had recommended, will be more difficult to obtain it...
Now, we have to 'convince' our users and some Project Managers to agree to some basics of Requirements Management and than to USE them. In the same time we want to put in place some procedures to colect some metrics related to these issues (like no. of req. added/changed/modified versus total no. of req. during the project life cycle). We thought that having some data to compare some projects, it will be easier to make them aware a Requirement Management Process is useful. Another reason could be that ,having the metrics in place, will make them more responsible.