Business Analyst Community & Resources | Modern Analyst

Career Forums

Modern Analyst Forums Business and Sy... Requirements Requirements for a Vendor Application Upgrade .. Help

11/3/2011 1:47 PM

	gostovp
1 posts

Requirements for a Vendor Application Upgrade .. Help

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.....

1/12/2012 7:06 PM

	Engle
30 posts

Re: Requirements for a Vendor Application Upgrade .. Help

What needs to happen is some planning and project leading, perhaps from your PM.

The overall requirement is that whatever the old software did, the new one should be able to do as well. And then some.

To ensure this happens, you will need testing support - specifically ' parallel ' testing.

Identify and execute business functions using old software, do the same for new software and compare results. There should be no differences.

1/13/2012 7:14 AM

	Deepdive
3 posts

Re: Requirements for a Vendor Application Upgrade .. Help

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.

1/13/2012 7:58 PM

	Kimbo
456 posts

Re: Requirements for a Vendor Application Upgrade .. Help

Hi,

I think its really important to understand your business requirements for a project like this before diving into the detail. (Rob N - couldn't disagree more with you on this one). Lots of companies don't take the time to consider their business requirements when doing something like an upgrade.

The BRD will probably be quite short but that is often the case in infrastructure projects. Also consider non-functionals at the same time e.g. response times.

Looking at your scenario above I can see some requirements already:

1. The system shall fit within our current desktop architecture

2. the system shall fit within our current server architecture

3. the system shall be supported by the vendor (can get much more detail here on when support required, response times, how its supported e.g. phone, on site, etc)

4. The system shall provide like for like functionality (you'll need to define what the functionality is at some point)

5. The system shall support existing business processes (can go into more detail based on the processes you have defined.)

etc.

Have a go, you'll be surprised at what this exercise will throw up. Particularly when you speak to the business and get their opinion, you may find that some of the assumptions that everyone is making are not actually true. e.g. a like for like conversion. Bet the business has identified some functionality they need that no one has bothered to ask them about.

Kimbo