BPM-EAI

Yes, you guessed it correctly. It is about “Requirement Specification”. A lot of time, when the requirements are not articulated clearly, the result would have a correct solution to a wrong problem.

We are in the business of IT Services, where we adhere to what is called as “Software Development Life Cycle” process for providing IT Solutions to business problems of our customers. In SDLC, we start with our first step to understand the “Requirement” of our client, which then is “Analyzed” to come up with a feasible “Design” of a solution for the “Requirement”. Till this stage, the actual nuts and bolts of the software are not assembled, but the solution is still at drawing board level.

Later, based on the “Design”, the solution is “Built” wherein all the components discussed at the drawing board are assembled to form the IT Solution. ‘Taste of the pudding is in eating it’, so that “Built” solution is then tested to see, if there are any leaks or malfunction or if it is in adherence to the “design”.

Finally, the solution is presented to the customer, who would then “test” the solution to “accept” the solution. Once the solution is “accepted” it is “deployed” into the daily use for the customer.

In the entire life cycle of the software, from the solution “idea” germination to “deployment” into daily use, as the time line moves, the cost of fixing any mismatch between the requirement and the solution grows exponentially. Barry Boehm, in this magnum opus book, “Software Engineering Economics” [ISBN 0076092033097] mentions that ‘the cost of removing a software defect grows exponentially for each downstream phase of the development lifecycle in which it remains undiscovered’.

All along we have been discussing about a popular SLDC model called “Waterfall” model, which is a unidirectional model. Another popular model “Agile” used for software development is an iterative model, where all the stages are met in a short span of time. Here too the risk of “Skewed Requirements” plays the Demosthenes sword. As each of the iteration builds upon the previous iteration, if somewhere in earlier iterations, the requirement is wrongly met, the whole solution that is build and deployed in the final iteration might be different from the expected.

So, how do we come over this problem of omitting a requirement or misunderstanding of a requirement, before things go on to different phases of SDLC?

A quick answer would be - by following good requirement gathering practices, better listening skills (if provided with a workshop), better reading comprehensions (if provided with documents), like good data eliciting techniques (if on a consulting mode) or prototyping models (to showcase our understanding) etc.

There is always a risk of human error in the above mentioned techniques. We at Infosys too understood the limitation and identified a technique to overcome this limitation. Setlabs our research and development unit has come up with a tool called InFlux, which can help the development team for gathering requirements in a way that nothing is either misunderstood or missed out altogether.

In an ESB implementation engagement for one of our Energy Utilities client in USA, InFlux was used to gather the requirements and a solution was provided. Later, for another subsidiary company of the same customer, the requirements were gathered again using InFlux, the tool showed that near to 60% of the requirements are similar to the earlier requirements, suggesting the team to “reuse” most of the already built solution. The customer made a saving of 50% on the development cost.

For more information about InFlux, please visit link