Tuesday, 02 August 2011 08:16

Capturing Implicit Requirements

Written by
Rate this item
(8 votes)

Introduction

A typical SDLC project starts with a requirements-gathering exercise followed by an analysis phase. During the requirements analysis phase, a detailed study is done in order to identify the different pain areas that would be addressed by the software that would be delivered. Often we come across situations, or more appropriately, business scenarios, wherein the requirements are not clearly documented.  They are vague and do not provide any clarity as to what exactly is expected. This leads to ambiguity, and finally, a software that delivers everything except what the client asked for! Unfortunately, this discovery happens during the user acceptance phase. Defects are identified that inadvertently point to requirements that have not been clearly captured/documented. A standard reaction of the business users would be, ‘We thought that this was going to be delivered…it is an Implicit requirement!’ Once we hear this statement, a typical ‘passing the buck’ game starts between the IT department and the Business Users.

This situation could have been easily avoided if the Business Analyst had taken the efforts to identify the implicit requirements. A key responsibility of a Business Analyst is to define the Scope of the system that is going to be built, and in this process, ensure that the Explicit as well as Implicit requirements are clearly documented.

Understanding Implicit Requirements

Let us begin with understanding the difference between an Explicit and an Implicit requirement. Usually, the requirements that are stated by the business users in the different meetings and interviews are categorized as Explicit requirements. These requirements are the easiest to capture. They are usually supported by loads of Documentation, or for that matter, even a legacy system screenshot!

Implicit requirements are the hidden or ‘assumed’ requirements. Business users expect these to be delivered and hence may not feel the need to explicitly mention them in the business meetings. It could be challenging to actually define the scope as there is no clear-cut documentation or boundary available. The keyword here is ‘scope’. Let us try to understand this with a very simple example:

User requirement: 

Screen to capture the following employee details:

  1. Employee number
  2. Employee name
  3. Department

Implicit requirement: 

  1. Capture Designation as well

Since it is an Employee data capture screen, the business users would assume that there is a field to capture Designation as well. This would definitely be an Implicit requirement. But is it right to assume that this is the ONLY implicit requirement?

For instance, I can add a couple of other implicit requirements, such as:

  1. Duplication check required on the ‘Employee number’ field
  2. Should have the facility to Search for an existing Employee

Here is where the dilemma starts. Some Business Analysts would totally agree with my listing of implicit requirements, but I am sure there would be many others in the Business Analyst world who probably disagree. For instance, Search facility could be provided as a separate screen, and hence that would be a separate requirement altogether.

The key point here is to recognize that capturing the implicit requirement is more of a need than a luxury.

Another example would be in a data processing centre where the performance of a data entry operator is measured by the number of entries that have been done in the system. For example, consider a typical airlines scenario wherein millions of passengers travel daily. A data entry operator in such a scene would have to enter hundreds of passenger coupons in the system and his KRA or performance is measured on the basis of the number of coupons he enters in the system. In such a scene, the Business would need a system that would capture data quickly and in a highly efficient manner. Here, the implicit need is that the data capture form has to be designed in such a manner whereby the maximum data/information on the form can be entered using the keyboard rather than using the mouse. In other words, maximum information must be enterable using keystrokes rather than using the mouse.

If this implicit requirement is missed out, then we end up in situation where the data entry operator would never meet his KRA, and looking at the bigger picture, the airline would miss its SLA. This could lead to tarnishing the airline’s image and would ultimately impact its business.

Scope Control

If documented well, Implicit requirements can be used as an excellent tool to control the scope, which in turn will lead to lesser defects and finally a Satisfied Customer! But at the same time if the boundaries for the requirements are not clearly documented, it can be misused and will lead to Scope Creeps, huge defects and a Dissatisfied customer.

Capture

This leads us to the conclusion that the Business Analyst community would have to use certain proven methods to define and bound the scope. A cost-benefit analysis will be the ideal way to deal in this situation. There may be a scenario wherein an endless list of implicit requirements inadvertently increases the cost with no visible benefits. On the other hand, it is quite possible that by deciding to incorporate minimal implicit requirements, the client would reap huge benefits.

In a nutshell, in order to ensure that the implicit requirements are never missed out, we would need to take a step back and always try to understand what exactly the Business user is looking for and if we have really understood this need. To conclude, we Business Analysts do play a role of ‘the Truth Seeker’ and thus need to unravel what lies beneath, in our quest of understanding Business requirements!

Don't forget to leave your comments below.


Aruna Parameswaran : A technical person with 12+ years of experience who moved into a Fucntional role by choice. Working as a Business Consultant with an IT organization and have led the Requirements phase of multiple implementation projects across geographies,primarily Asia-Pac and UK with some exposure to the US geography. Have spent the last 6 years specializing in the Life Insurance domain in the UK and Asia-Pac regions

Read 24750 times

Latest from Aruna Parameswaran

Comments  

0 # Marie Salcioglu 2011-08-02 04:37
Thanks for the article! Not to split hairs, but I disagree with the example given about the employee designation! Since some requirements at that level of granularity were captured, (e.g. Department) I think that it would be difficult for the business users to argue that the need to capture Designation was implied. Certainly the fact that some requirements are implied, does not mean that they are less important! How do you know you've captured all requirements, whether explicit or implied? Working prototypes can help, and checklists for the BA to ensure that he/she has considered requirements from the non-functional (performance, scaleability, maintainability ,...)side of things are a great tool as well.
Reply | Reply with quote | Quote
+1 # Seo Keo 2011-08-02 16:26
The better way is not just step back but put yourself in the user's shoes and play with a screen. Be honest about your user experience so it will help capture all (explicit and implicit) requirements. Cheers, SK
Reply | Reply with quote | Quote
+3 # Shivraj Khorate 2011-08-02 16:30
I beg to differ on the views expressed on implicit requirement. If we go by the approach in the article, we may end up providing irrelevant features, or features which the client haven’t asked for. This will leave client more frustrated, not to mention the time and rework to remove the implicit requirement, and if there are couple of integration points surrounding it – more time spend I believe there is nothing as "implicit requirement" per se. The business analyst, if finds that inclusion of certain field, like “Designation” field in the example, will add value, than it is wise for him/her to communicate the same to the client, and get their buy-in. This will culminate implicit to explicit, thereby curtailing ambiguity in the whole requirement gathering process.
Reply | Reply with quote | Quote
0 # Aruna Parameswaran 2011-08-02 22:21
Firstly, thanks for all yor comments! Gives a good feeling that people are reading my article & correcting me :) @Marie: The example cited was to highlight the fact that sometimes we forget to ask relevant questions and hence may land up in a situation wherein we miss out on some requirements. Do agree that working prototypes are a great way to capture the implicit requirements. @Seo Keo: Agree with your views @Shivra j: Don't really agree with your views but appreciate your opinion. In my experience with users, they have accepted, if not totally agreed to the implicit requirements that were discovered. It gives them a great sense of trust as they see a sense of empathy.
Reply | Reply with quote | Quote
+1 # Ginny 2011-08-03 06:55
I think the point here is that the Business Analyst needs to understand what the business is trying to accomplish and what the context is. In the employee-captur e screen example, there might also be security requirements based on what other data is being captured and what the information is going to be used for. In the data processing center example, a BA should work with the users in the actual environment: learn what the user has to do and what other environmental impacts there are. This is especially important when the environment is not an office. To me, these are part of _eliciting_ the requirements so they can be defined explicitly.
Reply | Reply with quote | Quote
0 # Colin 2011-08-03 08:17
A good article that covers a really important aspect of requirements analysis. My personal approach is to gather an initial set of requirements from the stakeholders and document as a draft version. Then, as Ginny suggests, I attempt to identify as many missing / implicit requirements as possible (talking to users, using my experience, knowledge of the business area and understanding what they are trying to achieve). I simply add these new requirements to the draft requirements document and assign them to the appropriate stakeholder. W hen I issue the draft document for review I make it clear that I have added some suggested requirements and ask the reviewers to confirm or reject them. If confirmed they become standard requirements, if rejected I update the 'Out of Scope' section to clearly document that they have been considered and rejected. This approach seems to work for me.
Reply | Reply with quote | Quote
0 # Aruna Parameswaran 2011-08-03 14:53
@Ginny: Thanks for your comments! Absol utely agree about the security requirement in the Employee Capture screen. But , sometimes, the security requirement may be tagged as a non-functional requirement and gets passed to a separate Analyst team. The key then here is to ensure that the Inter-dependenc ies are also taken care of. For the data processing example, do agree with the approach that you have suggested. However, my practical experience is that the Business users get so much involved in the functionality bit that they sometimes do miss out on the basic stuff. In that sense, it would become implicit. @Col in: Thanks for your comment! This is very similar to the approach that I follow but with some minor variations.I pass on the suggested requirements as queries and then as you have mentioned , after subsequent discussions with the users, I either add them in or move them out.
Reply | Reply with quote | Quote
0 # David Wright 2011-08-04 08:45
All requirements have to be 'explicit'; I prefer to say they have to be 'stated'. The key thing is that the business people have to be involved directly in stating the requirements, so that in the end they take ownership of them as 'their requirements", not IT's requirements. Otherwise, the problems you describe are very likely to happen.
Reply | Reply with quote | Quote
0 # Charu 2011-08-07 08:21
I do think Aruna has raised a good topic for Business Analysts who are in the earlier years of their career. While I agree with comments that requirements should never be made up by a BA or IT team, the point, I guess, Aruna is trying to reiterate is, the caution and thinking that needs to be deployed while eliciting requirements. E very BA needs to think of the possible scenarios that may arise and ask questions when eliciting the requirements. Adding on designation in Aruna's example may not be the most appropriate while the point she is trying to make is, may be, ask about the reporting requirements in which may come out that the user actually needs the designation there. What defines the unique key, checking for duplicates / avoiding them, secuirty, usability, etc are some of the associated non-functional requirements that naturally follow the functional requirements once the list of functional requirements is completed. Inst ead of drilling into the specific example provided by Aruna, let us use the opportunity to discuss the possible implicit requirements or the right questions to be asked while eliciting requirements... ....that type of a discussion will be useful to the Junior BAs or new BAs entering the field.
Reply | Reply with quote | Quote
0 # Aruna Parameswaran 2011-08-07 15:29
@David: Thanks for your comment. It is true that the business has to own it but the point that I am trying to make is that how we can be excellent facilitators and help business to express/state all the requirements @Charu:Thanks for reading! I think you have got it right. As I mentioned, my examples were used to just prove a point. As you have rightly pointed out , would like the BA community to discuss on the subject matter rather than the specific examples.
Reply | Reply with quote | Quote
+1 # steve blais 2011-09-06 18:12
It would appear that you would leave a requirement "implicit" and just include it in the product. Would this be an example of IT arrogance by assuming we know what they should have said but didn't? I suggest, as Dave Wright above suggests, that "implicit" requirements be vetted with the product stakeholders so that we can be sure we are not assuming anything untoward. Now, here is the critical factor: once you have them vetted, or approved, they are then "explicit". In other words there can be no "implicit" requirements that we know about. The only "implicit" requirements are those we don't know about. The same holds true of assumptions. Instead of making an assumption we should turn it into a question and ask someone in the business about it. Once you get the answer, it is no longer an assumption. The only thing I agree with is that truly implicit requirements (those that the product stakeholders assume that we already know so don't tell us) can come back to haunt us, or even worse.
Reply | Reply with quote | Quote
0 # steve blais 2011-09-06 21:29
It would appear that you would leave a requirement "implicit" and just include it in the product. Would this be an example of IT arrogance by assuming we know what they should have said but didn't? I suggest, as Dave Wright above suggests, that "implicit" requirements be vetted with the product stakeholders so that we can be sure we are not assuming anything untoward. Now, here is the critical factor: once you have them vetted, or approved, they are then "explicit". In other words there can be no "implicit" requirements that we know about. The only "implicit" requirements are those we don't know about. The same holds true of assumptions. Instead of making an assumption we should turn it into a question and ask someone in the business about it. Once you get the answer, it is no longer an assumption. The only thing I agree with is that truly implicit requirements (those that the product stakeholders assume that we already know so don't tell us) can come back to haunt us, or even worse.
Reply | Reply with quote | Quote
0 # Sridhar K Gowda 2012-06-26 04:04
We need to put ourself in the user's shoes and play with the screens, capture our experience so it will help capture all (explicit and implicit) requirements.
Reply | Reply with quote | Quote
0 # Siddharth Sharma 2013-04-02 05:29
I agree with article and also with the comments. As a business analyst, one should have to think about the implicit requirements which are really necessarily and also have to draft them into the Document and should have to discuss the same with the client. after his approval should move further into the execution.
Reply | Reply with quote | Quote
0 # Ram Mohan Allam, 2013-09-14 10:55
Informative article & narrated with good example...thank s
Reply | Reply with quote | Quote
0 # Megha 2013-09-17 05:20
"take a step back and always try to understand what exactly the Business user is looking for"
Very true statement. If business analysts keep this in mind, creating something that really solves business problems will be easy.
Reply | Reply with quote | Quote
0 # Ravi Chandra Jain 2015-03-08 05:43
I agree with the article on we should capture the granularity of product, whether it could be data entry or a basic employee screen. we should capture these information, get the consent of the stake holder and make is as an explicit requirement. The Signoff process is the key in any documents or requirement to be approved.
Reply | Reply with quote | Quote
0 # Sourabh Bhurat 2015-08-19 23:44
It is very good article on said subject and trigger the thinking of RA/ BA. There could be 100's of things to do but we should never forget to capture the basic needs and never compromise on customers needs.
Reply | Reply with quote | Quote
0 # Arvind Iyer 2016-06-17 00:40
Firstly thank you for sharing your knowledge by way of this article. I completely agree that one need to take care in articulating the implicit requirements. But what if such requirements doesn't carry much of sense to the actual users. Like Steve Blais rightly mentioned such needs to be freezed with the users so that it becomes the explicit requirements and no disputes comes at a later date. Again this will require time and efforts by both parties to come to a conclusion thus raising the chances of scope creep.

Its just an opinion there's nothing right or wrong but sincerely trying to figure out convincing solutions for such scenarios.
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

search Articles

© BA Times.com 2016

DBC canada 250