I am about to start the process of gathering requirements for a project. This project is going to involve taking a stand-alone Access-based application and re-developing it as a client-server based application using .Net (C#) and SQL Server. The basic functionality and features will remain. We will basically be re-designing the application to be a mirror version, functionally, but in .Net with the data access additions.
My question is, how would you go about gathering and tracing requirements for this project? I have thought about taking the "All functionality will remain the same as the existing application, with the exception of the following" approach and then detail all requirements relating to the changes between the two apps.
I would rather not have to re-write all requirements, even for the existing features, however, for traceability reasons, this might be the only way to verify that all features and functionality are included in the new version.
My Test Plan and Test Cases will be scoped to cover the entire application, so I am leaning towards writing testing requirements, based on the existing application, newly gathered requirements and our interface prototype. Does this sound sufficient?
I have done quite a few searches on this forum and other sources, but the majority of topics are more related to ADDING onto or modifying an existing project, instead re-developing on a different platform.
Any suggestions would be appreciated...
Re: Existing Project
I think your approach of writing testing requirements for the existing, new, and interface prototype makes a lot of sense. It gives you everything you need without overkill. Consultants run into this all the time; we need to completely regression test something that has never been documented (for example) as part of a new project or platform. We also have limited time to produce test assets. We would follow the approach you've suggested.