Engine and Bells & Whistles of Software

Requirements of modern systems have come to be so complex in the last few years that the word 'requirement' itself probably needs to be replaced with something else. At the very minimum, the requirements need to be differentiated between the core and the cover, atleast. For lack of better terminology I still use the word(s) Engine and Bells & Whistles. By using these words I do not want to portray that the latter are more annoying or less valuable than the former. But I certainly want to differentiate between them based on the criticality. Let's take an example of an application that is used to record the clock-in and and clock-out times of a workers and their other shift activities. Some of the desired pieces of functionality may be:
  • Log shift activities
  • Log in and out times
  • Generate XYZ Report
  • Export Data to Excel
  • View Data in a Range

The above pieces represent the nature of a few types of functionality that are often found on projects. One of the practices I that I follow and recommend to others is of course to determine the business value of each of the features desired. For different businesses the value of each of the above features will be different. The other practice is to seperate the features into engine and bells & whistles after you have determined their business value. So, in the above example Export Data to Excel or View Data in a Range can be a bells & whistles feature if it has very little business value. It is a feature that most likely got added because all the other applications in the industry may have those.

This often gets skipped, but is very helpful for many reasons. Some of them are:

  • More experienced people can be handed the responsibility of the engine components.
  • Bells & Whistles can always be used as filler features when engine feature(s) planned for an iteration of development are over.
  • These are often good pieces that can be used to get new team members upto speed on code. Let's not forget that bells & whistles can be very complicated features to implement sometimes.

There, probably, aren't any rules of thumb by which a feature can be classified as bells & whistle. However, there are certain hints that can be used to figure it out. If the business value is very little compared to some of the other features and/or if the feature being asked for has its inspiration from a lot of commercially available applications, there are high chances that it may qualify as bells & whistles.

Process Study and Client Interviews

Have you ever asked a BA about what (s)he does and the biggest challenge they have had? I have asked many and the majority of them told me that gathering requirements by interviewing clients is one of the primary tasks. The challenge that most of them face is either information overload or not getting enough information. I have been in both situations and have come to realize that eliciting and distilling information is very complex because the level of granularity is not consistent across the interviewee base. A solution to distilling information is to enforce a consistent level of granularity while talking to users and clients. This doesn't mean that the granularity has to be the same across the different roles; it just has to be the same across different users/interviewees withing the same role for it to be the most effective. In order to guide the consistency, it is very important to have a list of questions ready and compiled before hand so that as an interviewer you can get a feel of them. A quick review of questions is all it takes to make a decision if you need to go one level up or a level down in granularity with questions. There's three (3) different styles of interviews that you can follow - structured, semi-structured, and unstructured. What do I mean by that and what are their merits and demerits.
  • Structured - These are generally yes/no, fill in the blanks and data collection kind of questions. The nature of these questions make the interview process seem like an interrogation rather than a knowledge sharing session. Problem almost never come out using this format.
  • SemiStructured - Problem come out, which don't in a structured interviews. It is a very efficient two way communication process.
  • Unstructured - Without guideposts the chances of straying are very high. Also, it is very important for the interviewee or the respondent to be able to sense the direction you are going in to frame their answers correctly. Unstructured interviews don't have that benefit.
In my experience a semi-structured interview is the best fit for the kind of information that a Business Analyst is generally interested in. This is almost a free form discussion that is primarily time-boxed and secondarily scope-boxed. By that I mean that in a certain time period of interaction you plan to touch a set number of topics armed with a few questions upfront and then asking questions as an when the information is revealed by the interviewee. And, if you don't get to ask all the questions you try to interview again. Choose one of these styles based on the following:
  • Availability of users/interviewees.
  • Subject Matter Expertise.
  • What do you aim to understand - process or problem
Answer the following question before you go for an interview. Do you want to understand the problem or do you want to understand the process? The distinction between the problem and the process is more important than what's obvious. The study of a problem needs an entirely different source than what is required to study the process. Understanding the process requires interaction with the people who actually carry out the tasks, but it's the managers that usually contribute the most to understanding and solving the problems. The reason is simple, people who actually carry out the task are the ones who the know the most about it but at the same time usually don't see any problems with the current processes. They know so much about the proess that they justify each and every step of it and, hence, nothing ever seems to be a problem.What's the kind of information you are looking for; primary or secondary? Information is classified as Primary if you communicate with the person who carries out the tasks. It is secondary if the person you communicate with is not the one that carries out the tasks but has either been the consumer of information in the past or has just been an observer or a supervisor. Answering the above two questions and preparing for it is useful since the objective is very clear at each and every step of the study and interview process and focus is maintained. There are two symptoms of incorrect focus and it is very important to identify those. These are:
  • Incomplete understanding of the process/problem, and/or
  • Indecisiveness
There's, typically, two kinds of statements that should prompt you to seek different people to talk to. These are:
  1. I don't know, or I am not sure.
  2. I can't make that decision.
Next comes the part of documenting the process study and client interviews. With the processes in the industry out there being as sophisticated as they are, there's no one prescribed format to record the findings. Most of the business problems are unique and require a fair bit of tweaking of either the existing templates or creating new ones. The objective of creating this artifact is to take down notes for each of the process steps and make a note of where this information came from, just in case if this has to be verified later on. The idea is to have enough information that can serve as a reminder and a, without having to ask the basics again and again. The idea is not to make this artifact a training document for someone in the team. Overall, the document should be lightweight and just in enough detail to be able to make educated estimates from.