What's the best way to gather requirements for the business when they hear of a product on the market and believe (without/before the proper requirements gathering phase) that this product will satisfy their needs?
Eample - the requirement states the solution should provide reporting functionality for data. The business learns of a product on the market that can provide reporting functionality and thinks it will satisfy their needs. Do you document the product's capabilities, present to business, and have them agree and sign-off that it satisfies their needs? OR, do you somehow force the business to forget about the product and focus on gathering requirements based on the requirement statement alone, then revisit the product after the process is complete? Also - if you do choose the product, how much testing do you perform? Since it is out-of-the-box you would believe you shouldn't have to perform large amount of testing. Do you trust the product and perform minimal testing, or do you complete standard testing (acceptance, load, functional, integration, etc)?
This isn't really a requirements issue, it is about the process (if any) of acquiring solutions. If the business can just buy it, they probably will. If they have to cost-justify it, they at least have to define benefits that will be realized, and that is always the responsibility of the business. If they have to show that they considered more than one alternative solution, then requirements have to be discovered in order to evaluate the alternatives against the requirements. If they can't buy something without someone else's agreement, like IT, then the process is out of their hands (although business peple don't like this usually, especially if it is their budget used for a purchase) and you could indeed force them to provide requirements first.
If they can just buy it, requirements are moot. You then have an implementation effort for the product. At that point you may (will?) dicoverthat the product doesn't do some of the things the business wants. If so, you have a subsequent enhancement effort, and you will need requirements for that. This isn't necessarily a bad way to go, could save time, but it is riskier, as a product could turn out to have been not anything like was wanted. When that happens, somebody usually takes the fall (fairly or not), and then the process changes to prevent that next time.
So, does your company have any process around acquiring solutions/products?
I've gone through this and will be again. I would recommend that you gather requirements from the business without the "magic new tool I found online" in the picture. Another name for this might be a "Request For Proposal" or a "Vendor Scorecard". The idea is that you use the same baseline of requirements to eccentially score each vendor against. Other than the functionality, you need to gather more of the non-functionals, too. Cost, scalability, security and the vendors future vision are things to consider. Doing these things at a minimum should position them to make the best decision.
For your second question, test it against your requirements like you would any other project, meaning do the complete standard testing. The software is tested at "XYZ Tech", but their environment will be different from yours. They didn't test it using your data, servers, users or load. You're paying for it. You better make sure they deliver on the goods.
Hi:
What you need to know is essentially, what, from an end-use perspective, the product does and ,essentially, what do your end-users do. If you had essential data flow diagrams of both of these things, then you could simply compare one vs the other, and then report your findings to the decision makers.
Problems: You are not going to be given such diagrams from the software vendors - just disjointed fluff; and you probably will not be given the time to diagram your company specific essential functions/tasks and their interrelationships.
But, at least now you know what the ideal is. Keep this ideal in for forefront of your mind to negotiate the best approach you can with your management.
Tony
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: