Business Analyst Community & Resources | Modern Analyst

Can business analysis help finding the “missing” requirements?

23607 Views

4 Comments

21 Likes

Introduction:

As Business Analysts, we are involved in requirements development and management day in and day out with most of the time spent on eliciting, analyzing and specifying business and software requirements for multiple projects. We follow or adopt multiple frameworks, approaches and tools that help us to successfully gather and analyze requirements. Can business analysis help finding the “missing” requirements? Having done all these things to ensure the success of the projects, we still end up in a few projects wherein we have “missed” few requirements. Missing requirements are requirements that are “missed” to be even elicited during the lifecycle of the project. Missing requirements are usually not part of the long list of requirements that we have elicited and then prioritized with stakeholders. The irony is no stakeholder (including business analysts) identified these missing requirements during the project lifecycle - it just appeared out of the blue moon one day after the go live and no amount of process governance adopted during business analysis could ensure that such requirement was considered earlier.

Few examples of missing requirements:

You have helped create a far complete/up-to-date invoice document or say any key output document out of the system whenever a product is sold to the customer at the point of sale, but missed to include requirement for a “bar code” into the document so that the disparate point of sale details added automatically through scanning when the physical document arrives in the head office!
You did an IT project to improve or make the process lean for an online application of your/client product/service but missed the requirement to add tracking of the application so that the customer is aware where his application currently is!
You have helped document requirements for an insurance retention process but missed to capture a requirement to email the retention details (lapse of premium payment or time trigger when retention is to be initiated) to the sales/account managers as an automatic alert!
You analyzed the solution for a regulatory project but till the end of the project you missed including needs of a key stakeholder or intermediary in the requirements who should have access to the data!
You missed creating an audit requirement for a CRM application implementation!
You did an analysis for a consumer loan application but missed the requirements to generate an output that calculates the possible tax returns for the customer for the full lifecycle years of the loan!

Can usual business analysis techniques prevents “missing” requirements?

Few techniques that are widely used to prevent missing requirements include:

Process modeling based analysis of requirements - modeling the successful flow, alternate flow, etc. can help preventing any functional requirements to be missed
Quality assurance techniques - like requirements tracing (lower level requirements to business requirements or to other dependent requirements or use-cases), stakeholder completeness analysis, root cause analysis, requirements completeness checklist etc that can actually help to “not to miss” both functional as well as non- functional requirements!

In my experience, I have seen that these techniques actually lead towards detailing requirements to death - creating hundreds of pages or requirements documentation/use-cases with all success/alternate flow, business rules associated, pre conditions, post conditions etc. It is good to have such detailed documentation taking into consideration both the perspective of the system to be built and other interacting systems in the IT landscape of the project involved. These techniques are reactive in nature and are more organized around solving the “pain points” of the stakeholder or an existing system rather than brining a fresh view on what is best as a solution with a forward thinking that can avoid missing any requirements.

Some of the reasons we as business analysts overlook “missing” requirements can be:

We are so much involved in discussing risks, issues, assumptions and dependencies (RAID) of the system level implementation - we actually forget that there are best practices outside our system purview.
The project team is so much motivated towards ‘delivery excellence’ but not on ‘user (customer, business, partners, etc.) satisfaction excellence’.
Constraints on time and budget.
Business requirements and software requirements are elicited from stakeholders who know only their particular system or domain but not the best practices that are available within their industry or outside their industry.

So, are there any practical insights to solve this mystery?

Finding “missing” requirements

These are few techniques that I have used to be successful in identifying missing requirements:

Sound-boarding:

Use few stakeholders outside the project team at regular intervals of the project lifecycle for sound-boarding – throwing at them the current requirements and getting back their feedback. These stakeholders can be your fellow business analyst in another team, a business stakeholder who is not involved in the project, a colleague of you who has experience on different industries, an architect who is not in your project or an analyst from some IT research organizations. Guide them through the session and allow them to point out what is that missing in the requirements and try to list them as possible inclusions. Later, discuss with the project team to see if there is really need for such requirements and if it is feasible to include them within the budget and time constraints!
Cross Industry References:

Try to get arranged for a cross industry analysis session with a focused group of colleagues, consultants, analysts or even multi country team members. This can be a one of session in the course of the requirements project to do a focus group discussion on what can be possibly a cross industry reference that can be used as requirement for your project. For example: for a life insurance policy portal after looking into other industry online websites like Amazon, we included a requirement to “suggest” to customers an alternative policy or related policy to what the customer is currently browsing online for possible purchase.

Bring in the user or customer early

If it is possible to bring in users or customers of the system at an early stage for an idea generation session, it would help you to not to miss any requirements during the usual requirements elicitation sessions. Keep this session as a high level discussion on what are the possible ideas that are floating in the user or customer’s mind on requirements. Beware to ask users or customers to actually spend time on the scope and do some homework well in advance to come up with ideas – otherwise what you get is so generic that you or any common man will already know!

Define a mechanism for time boxing:

This is more of a governance mechanism to allow certain defined time line so as to identify “missing” requirements during the course of the project. This way you allow yourselves and the project team to actually do a search within a limited time (say a week) to find out what is missing. Otherwise there is no end to the search for missing requirements and by introducing a time limit you are actually avoiding the concept of missed requirements – rather you are bringing in the concept of timed out requirements which has to find its way to build in the next release! This may sound a bit funny but this is how you can face the reality so as to avoid chasing a moving target of missing requirements!

Author: Umbreen Sherwani

Umbreen Sherwani is a Business Analyst with SecondFloor, Netherlands. Umbreen has multiple years of experience in business analysis in Insurance domain consulting. SecondFloor (www.secondfloor.nl) is a specialized IT solution partner for insurance companies with successful solutions for Solvency II and other regulatory requirements. The author can be reached at [email protected]

Posted in: Requirements Analysis (BABOK KA), Elicitation (BABOK KA), General Business Analysis

21 members liked this article

23607 Views

4 Comments

21 Likes

Preparing for CPRE Certification? Here are some tips!

Crafting Valuable Requirements Using Business Architecture and Artificial Intelligence

Requirements vs. User Stories: Which Are Better?

Visualize, Organize, Realize: The Magic of Mind Mapping

COMMENTS

Leslie posted on Wednesday, July 10, 2013 6:01 PM

The low rating, is because the title got my interest 'analysis' and 'missing requirements', and after reading the complete article, i discovered lots of ideas about locating missing requirements, but almost nothing on 'analysis'.

All of the examples cited describe requirements that were missed by not getting enough information from the st5akeholders. These can likely be found by modeling the business process thoroughly, as described in the above techniques.

What analysis allows me to do, is to discover those requirements that you are not going to discover through interviews with the above stakeholders, because the stakeholders are not aware of these requirements.

Typically these are alternate paths of use cases, that a user is not going to think of, or they arise because of the introduction of new technology into the process (i.e restrictions by interfacing systems, regulatory bodies or database technologies,, for example). These types of requirements are found by modeling the systems that will be used to implement the requirements.

Some might argue that systems modeling is out of scope for a typical business analyst, and I won't disagree. But my point is that that the techniques described above are not 'analysis' techniques, whereas modeling is.

Mick Wren posted on Thursday, July 11, 2013 6:26 AM

I agree with Baldrick's comments. Thorough modelling will reveal the vast majority of hidden requirements, and there are thousands of them.

I would recommend acquiring solid logical relational data modelling skills as well as those mentioned. Data modelling can very quickly reveal gaps in understanding of the business domain (both by the analyst and the stakeholder). Also, the majority (all?) of business processes involve handling data. I would argue that you can't fully understand and model a process if you don't understand the data being processed.

In the 25+ years that I've been doing this I have never (to my knowledge) gone back to the stakeholders with a list of requirements to be checked. Requirements are inputs to the analysis process. I always go back with queries and issues that have arisen as a result of me converting requirements into models. Ultimately it is the models that become the statement of requirements.

If I were to extract every 'requirement' implicit in my models the project deadline would have passed before the requirements doc had finished printing.

Ultimately though there is always the risk that someone assumes that you know what they want when you don't. The only way to mitigate that risk is to feedback as often and in as many ways as possible. The sooner the better. I would suggest however that a requirements catalogue is not the most effective way of doing that.

Putcha posted on Saturday, July 13, 2013 1:05 PM

AA: Very good article & comment by baldrick and Mick.wren. Yes, it is very difficult to know what is missed which is the reason why they are missed in the first place.

BB: I have some suggestions drawn from TQM and recent publications on Real Requirements + my experiments. I see they are covered to some extent by AA

BB1: Application of 5Ws & 1H; Ask Why 5 Times, Role Play, Ethnographic Study & Analysis, Field Trials with early prototypes (covered by the author and reviewers),

BB2: Catalog of Needs and Means (which one may build within some domains of applications and review of products and designs). I do not find it much in use in engineering in general and software engineering in particular---exception "Design Patterns" and "Repository of Reusable Artifacts" (but they are not applied to BA and RE)

BB3: Discovery of REAL NEEDS---see publications and blogs of Robin Goldsmith and Roger Cauvin (you can search with these words). I am impressed with Cauvin's test of pure need. Examine the statement of need and see if it contains any hint of how the need may be met. Examples: (1) I need something to write with---real need is "to make visible marks on a surface" or something even more abstract, (2) I need a car---real need is perhaps: I need to move from location A to location B or I need to interact with X or Y at a different location (reachable by road) or I need the sensation of driving and experiencing the environment of certain geographical locations.... This comes out of analysis and reflection, not by asking.

BB4: I have experimented with "offer of answering questions about what I need without naming any standard object or means". The BA or RE is expected to ask questions and arrive at a description of some object that meets all my needs (which I have predefined. I am not trying to change or add to "what I need"). I found that many BAs and REs do not even know how to start questioning.

When they ask "what do you want?" I say "I cant name it, I do not know if there is a *THING* which does what all I want". Yet many fail to start eliciting. I found 5Ws&1H is excellent to break out of it with out asking "WHAT is it that you want". One can still ask WHAT will you do with it, WHERE, WHEN, WHY, WHO are all involved, HOW will you use it etc,

Those who are interested can test their methods of eliciting by asking me questions on the *THING* I need.

[email protected]
13JUL13

Robin Goldsmith posted on Sunday, July 14, 2013 7:08 AM

Thank you for the cite, Putcha. In my experience, while missed use case paths are certainly an issue, the more important source of missed requirements is inadequate REAL business requirements. Perfection is not the issue. Humans being the fallible creatures they are, all REAL requirements are to some extent defined inadequately; but the approaches and techniques described in my book Discovering REAL Business Requirements for Software Project Success, articles, and seminars can do much better.

The most effective and efficient way to reveal missed REAL business requirements is to improve their discovery in the first place. Business analysis done well can help finding the missing requirements. Business analysis as commonly done is unlikely to do much better than it already does because of its fundamental flaws. For an example, we need look no further than the author’s recommendation to ‘Bring in the user or customer early.’ This makes me wonder where the supposed requirements are coming from currently. No wonder things are missed, and not just ‘a few’ either.

The next most effective and efficient way to reveal missed REAL business requirements is to apply the more than 21 ways my book and Proactive Testing™ methodology describe for evaluating requirements adequacy. Most organizations and projects either use one or two weaker-than-realized techniques or don’t evaluate requirements at all, which is typical of command-and-control organizations where requirements dictated by a boss often are not questioned and Agile development where the Product Owner/Customer Representative’s declarations are unlikely to be evaluated critically.

The most commonly-known and generally only-used requirements review techniques focus on format issues, such as clarity and testability. Such methods are relatively unlikely to detect wrong and missed requirements. In contrast, the 21+ Proactive Testing™ techniques include a number of more effective methods specifically focused on detecting missed and wrong requirements. Not only must one understand and develop proficiency using these special techniques, but their application depends also on increased business domain knowledge that many analysts and developers simply don’t have or appreciate the need to acquire.