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
User is offline Adrian M.
764 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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC