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

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC