Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  Req. gathering/testing for an out-of-the-box solution
Previous Previous
Next Next
New Post 10/4/2011 5:20 AM
User is offline Tim G.
4 posts
No Ranking

Req. gathering/testing for an out-of-the-box solution 

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)?

New Post 10/4/2011 11:40 AM
User is offline David Wright
141 posts
7th Level Poster

Re: Req. gathering/testing for an out-of-the-box solution 

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?



David Wright
New Post 10/5/2011 10:30 AM
User is offline Deepdive
3 posts
No Ranking

Re: Req. gathering/testing for an out-of-the-box solution 

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.

New Post 10/6/2011 7:51 AM
User is offline Tony Markos
493 posts
5th Level Poster

Re: Req. gathering/testing for an out-of-the-box solution 


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.


Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Req. gathering/testing for an out-of-the-box solution

Community Blog - Latest Posts

The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...
Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified. 1. Not understanding underlying business need Organization’s business environment keeps changing with respect to Customer...



Copyright 2006-2021 by Modern Analyst Media LLC