Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  But I got more than what I asked for, what now?
Previous Previous
 
Next Next
New Post 8/31/2014 5:27 PM
Unresolved
User is offline Ronel Ellis
4 posts
No Ranking


But I got more than what I asked for, what now? 

Recently I have been challenged with questions about basing my requirements on business process (solution agnostic) even when we already know which solution we will implement .  When we do requirements based on the business process  and we implement a purchased solution, it inevitably happens that the solution delivers more than what is strictly necessary to meet the business's need.  The testers build their test cases based on my requirements, but suddenly there are features, functions and even modules in the solution which are not traceable to any of my requirements.  There is an expectation that I amend my requirement document to include requirements for those additional parts delivered.  Off course this is not done, but it opens a question on how to deal with these perceived gaps.  My normal advice to the testers are to do basic logical testing on parts unspecified.  This has been received with mixed feelings so far.

I would welcome thoughts on this matter.  What are people doing to cover these cases?  What would best practice be?

 
New Post 9/4/2014 6:43 AM
Online now... Adrian M.
741 posts
3rd Level Poster




Re: But I got more than what I asked for, what now? 

Hi Ronel,

You have an interesting, but not uncommon, challenge.

The testers have a good point: even though what the customer needs is documented as a requirement, the requirements in such cases should define what is NOT a requirement and how the system is supposed to behave.

I'll get to that in a second, but first let me make my point with a silly illustration.  Let's say that you're in the market for a sports car and you have requirements such as: must have 2 seats, needs to be low to the ground, needs to have tires wider than x inches, it should be red, etc.... You may even say it should be a Lamborghini.  When you go to pick up the car, it has everything you asked for but it also has a 18-wheeler truck permanently attached to the back of the brand new car.  I'm sure it wouldn't go well with you if the salesman simply said "You didn't tell me you don't want an 18-wheeler stuck to the back of the sports car."

The users (not testers) of your system will feel the same way when they begin using your system in the production environment and encounter "features" they did not expect.  These could be more than just "noise" and could cause serious technical, operational, and security issues.

For example:

  • What if your parts tracking system also has an accounting module which the users did not ask for.  The users could begin creating invoices in this module instead of the in the company's centralized accounting system.
  • What if your system has  feature (not asked for) which allows customer data to be emailed to the email address you type in.  Given the corporate standards, this could be a significant breach of agreement to safeguard customer data.
  • What if this new system has ability to export data to MS Excel?  If needed and used properly, this could be  a great feature but if it gives a salesman the ability to export all the leads from the system before they quit their job (and go to the competitor) that feature is not a flaw.  This feature could also put a high load on the system and decrease performance since data export processes could be resource intensive.

So, your testers have valid concerns even though they may not have articulated them from the end user's perspective or from the organizational perspective.

Here are some thoughts on how to deal with this:

  • Create an inventory of all the features which were not requested.
  • Identify those which of these feature could cause issues of various types: operational, performance, security, risk, etc.
  • Find out if the system has the ability to disable undesired features via configuration, entitlements, or security settings.
  • If such features do not exist, request that they be added by clearly outlining the risks to the organization of not doing so.
  • Work with the end users, operations group, or trainers to document (by policy) what the users should do when they encounter a feature not needed.  These could become assumptions in your requirements doc that the testers can use. Example: "It is assumed and confirmed by the business that feature <x> will not be used."

You get the idea!  Hope this helps!

Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  But I got more than what I asked for, what now?

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
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...

 






 

Copyright 2006-2021 by Modern Analyst Media LLC