Scenario:  We have a 3rd party application that is need of an upgrade to a newer version.  The current version in our production environment is out of date and is out of support.  Thus the business need to upgrade to a supportable version that fits within our current desktop and server architecture.  We are in the process of negotiating w/ the vendor that supplied us w/ our current version of the software to purchase the upgraded version.  Along w/ the software purchase will be consulting hours from the vendor to help with the upgrade (software installation and configuration and data conversion)  I have been assigned as the BA on the project.  The project manager says we need to document the 'requirements' for this project.  The scope has been defined as a 'like for like' replacement, meaning that at the end of the day, the business processes supported by the old software have the be supported by the new software and the exploring the implementation of functionality with the tool is out of scope if it extends the timeline or does not suppor the existing business processes.

Problem: I'm confused on how to approach this...how do I go about documenting requirements for an upgrade of existing out of support software to new software from the same vendor?  What types of requirements need to be elicited?  Do I get a feature function list and try to align to the existing business processes?  We have business processes documented for the use of the existing tool.  These types of projects confuse me because we've already picked a tool and we have vendor support for the upgrade...how much does it make sense to document a list user requirements when we are constrained at the outset by the feature/functionality of the new tool.....

It's not requirements that you should be gathering at this point.  Instead, you should focus your efforts on Use Cases or Test Cases.  Your existing business process are your business rules and can be used as the basis for the cases.  The best approach is to document the functionality that you expect to work in the new version using a step by step approach for the 'happy path' as well as the exception cases.  Screenshots with notations are always helpful.  New functionality should also be documented in the same way.  Once complete, you, your clients and the QA/Testing team can use these to give the thumbs up (or down) on the success of the implementation. 

If your company put the vendor through an RFP process, you may also be able to use this information to feed into your cases and testing as well. 

Don't forget to document your contraints, dependancies and assumptions. 

Gostovp,

I have exactly the same situation as u mentioned above. I am also in huge dilemma what should be my approach or what should I do as a BA. 

Please help me with your suggestion and approach style or documentation style .

I would really appreciate if you help me with this.

Thank You so much