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

Angular is a powerful open-source web application framework developed and maintained by Google. It is designed to simplify and streamline the process of building dynamic and interactive web applications.  Angular was first introduced in 2010 as "AngularJS" by Misko Hevery and Adam Abrons during their work on a project called "...
Introduction In today's data-driven world, businesses are constantly looking for ways to gain valuable insights and make informed decisions. Power BI, a powerful business intelligence and data visualization tool developed by Microsoft, has emerged as a game-changer for organizations across various industries. In this article, we will explore...
As a business analyst, your resume is a crucial marketing tool for showcasing your skills, experience, and accomplishments to potential employers. You have the opportunity to make the best impact and secure an interview when you compose your resume. Yet, competition for jobs is fierce, so it is vital to be aware that your resume stands out from the...



Copyright 2006-2023 by Modern Analyst Media LLC