Did we get the requirements right?

It’s just another day at the office. You just finished gathering requirements for a project after hours of discussion with the customer. What next? Do you just go ahead with writing the Software Requirement Specification (SRS) based on these requirements?

There was probably a time when you wondered: Are these requirements complete? Are they consistent with what we have already gathered? Is there still some ambiguity on the end product that is required?

If someone else were to gather requirements, would they have got an exactly similar set of requirements or would they end up with something more than this or less than this. Would their solution pertaining to their requirements be different? Over time, all those questions go out the window because we have work to do and timelines to meet.

Unfortunately, there is no measure for completeness of requirements and the generally accepted truth is that requirements are never complete. Fortunately, there can be a set of guidelines developed to ensure that the requirements are as close to being complete as possible.

  1. Coverage – The collected requirements should explain the required behavior/functionality in full. Are there any gaps? Are there any more ‘why’s that need to be answered?
  2. Clarity – Are there still some points which are ambiguous and where clarity is required?
  3. Atomic – Requirements should be so detailed that each requirement should be at an atomic level. Is it possible to interpret any of these requirements in two different ways?
  4. Role – Each task/activity should be associated to a role. It could be system doing certain things automatically or an assistant moving documents from one tray to another. It’s better to capture them all. Are there any activities that do not have a role defined and could lead to conflict at a later point of time?
  5. Consistency – On day 1, the General Manager might say that once the available quantity of a part falls below the reorder level, a purchase order should be created automatically by the system. On day 17, the procurement manager might say that once the available quantity of a part falls below the reorder level, system should alert the buyer who will then decide whether to procure or not based on allocated budget for that week. Are there any requirements that contradict earlier stated ones?

The requirements can never be complete and neither can the guidelines. But, if the answer to any of the above questions is ‘Yes’ or even a ‘Maybe’, then you have work to do before moving on to the next step.

Let us consider a simple example here to drive home the point. Customer says that he/she should be able to see the purchase lead time, repair lead time, purchase cost and repair cost for each part with respect to a vendor/repair agency.

Coverage - Assuming that we are already capturing purchase and repair lead times somewhere in the application, does the customer want to view this information which is already captured or does the customer want to view the actual lead times based on when the order is sent and when the part is received.

Clarity – Should the lead time be the one pertaining to the latest purchase/repair or should it be a moving average. If it is a moving average, what is the period for which it should be calculated and where do we capture that period?

Atomic – What should the lead time units be? In what currency should the costs be displayed of they are in different currencies?

Role – Who is going to use this information? It’s probably the buyer and the manager for taking some critical decisions. So, will it be better to have this information provided in some existing screen(which buyer uses) in the ERP product that the customer is using or to have this as a standalone screen for the benefit of all those who want to view this information.

Consistency – Let’s say the buyer calculates lead time as the time between order sent date and part received date. Procurement Manager might want to consider lead time as time between acknowledgement date from supplier to airway bill date for some analysis. So, which lead time are we going to show? Or is it both?

One often ignored aspect while gathering requirements and while proposing a solution is the impact of the architecture on the solution. We hear the term Non-functional requirements more often these days and they are as important as the functional requirements.

  1. What is the use of having a software product that automatically analyzes buying patterns and uses system data to suggest the vendor from whom the part should be procured based on quantity and need date but it takes 3 days to give you the result?
  2. What if a product is built on a particular technology that became obsolete in a year and we neither have infrastructure nor skilled manpower who can work when some issue arises?
  3. The product is great and it delivers the results perfectly. But no one knows how to use it because it requires a complex sequence of steps to be followed.
  4. Is there a way for the customer to test and certify that the solution delivered works as requested? Is the end user knowledgeable enough of what must be done by him to get the work done?
  5. When the company expands and adds new entities at new locations, can the product be enhanced to deliver results for all entities?
  6. Can the customer be confident enough that the data entered in the system is not being accessed by a third party?

These points refer to performance, maintainability, usability, testability, scalability and security in that order.

When any functional requirement is being noted, the business analyst would do well to think of the non-functional requirements associated to the functional requirements.

For example, before it is decided that something will be done by a scheduler, the time taken and the growth in data being used by the scheduler over a period of time should be given due consideration.

Before suggesting a user to do something in the system, we should give a thought as to whether the system is easy to understand and use for a person with the given skill/knowledge level. It is always good practice to enquire the short term and long terms plans of the customer and analyze the impact of them on the requirements/proposed solution.

Conducting workshops for business analysts and educating them about these aspects is a proven and successful approach followed by most organizations. In fact, I have benefited greatly from the Requirements Gathering and Customer Handling workshops that I attended as part of employee training programs conducted by Ramco Systems. Also in order to have a tighter control on the solution provided by the analysts/consultants, in Ramco, we maintain a repository of scenarios and solutions in the form of RSPRINT. Using RSPRINT, a consultant can check for the solution given earlier for a similar scenario and can either reuse or enhance the solution and update the database so that it will benefit other consultants and improves consistency in the solution given. Eventually we will have a set of solutions that are based on best practices which will help customers to re-engineer their business processes if need be.

Okay, so it’s time to go back and finish the SRS. But before doing that, spare a thought to check if the requirements are complete and consistent and if any non-functional requirements could be derived out of them.

See all topics