Free Usage*

Software requirement specifications the culprit - yet ignored
Everyone who has a long stint of experience in building software would be quick to point to ‘inaccurate’ or ‘changing software requirement specifications’ as the most common reason for software project failure or delays. Despite decades of improved tools, methodologies, reports, and education, it continues to doggedly remain as the key reason for project delays and failures. A number of factors like lack of user interaction, lack of business understanding, gaps in communication, lack of good tools, short time frames, users giving inputs late and so on seem to be the key reasons. Most of these can be solved through leveraging trained personnel, providing adequate time and budgets to do a good job and by using good methodologies.

However, there are deeper reasons which are more difficult to solve, and that is why inaccurate specifications continue to doggedly remain a problem over decades.

Specifications change as businesses change

Software projects take long to deliver, and typically between the time when specifications are conveyed and when the software is used, business processes change. Responsibilities change, external influences require process changes, competitive actions demand operational changes and many more. Such changes demand the software to change, and business would not take no as an answer to the change. When such changes occur, the impact on the software product is usually vastly underestimated. Business deems it as a software project failure while software teams blame the changing specifications. Both are right, but the root reason is business process change and the under estimation of its impact.

The long communication chain points to failure

Ever played the game where many people repeat a phrase in a sequence without the others hearing it? The last person then tells what he or she has heard, and invariably that is completely different from what the first person says. Similarly business users convey their needs in one form, business analysts add their value and often distort it, designers and architects interpret it differently, software developers and testers deliver it differently. Teams that get the communication chain right use need to use extreme quality focused methods to ensure that specification gaps do not occur. Only mature organizations with good platforms do this well, and most delivery organizations still are not mature enough to get this perfect despite following standards and obtaining quality certifications

End users are not geared to convey their true needs

Most users are not experienced in software development and often do not tell accurately what they truly need. Good requirements elicitation by experienced business analysts can bring out true needs to a good extent but is still never complete. However, this gap can be effectively brought down if they see wireframes or report outputs of what they will use or get. Most projects do not iterate to obtain user feedback after prototyping or wire-framing and hence many of users true needs are missed out.

Cultural transition to change

An enterprise software automation project often leads to a tsunami of process changes once implemented. Process users need to accept these changes after validating its applicability, internalizing it and examining its benefits. Such steps are by passed often and in the end user resistance leads to forced changes. Inputs for true needs are hence given late and that often causes loop backs.

Force fitting due to decisions by senior management

Senior management take macro decisions which are road blocks to on the ground execution. Force fitting a product that does not fit the process, or using software that cannot be adapted to users true and critical needs are a different form or requirements gap that can often have serious consequences. This article from a popular blog by Joel Spolsky - 'Painless Specifications - Why bother?' effectively reinforces the view that specifications are rarely completed and remains inaccurate for many reasons.

At we believe that a combination of good tools, and an iterative approach till accurate specifications are obtained can solve the problem. Good specification tools are integrated covering requirements, process modeling, iterative wire-framing and detailed logic specifications. In addition they are meant for business users themselves to specify without getting too technical. Avoiding the specifications gap trap is critical for your project and can help in overcoming the trap.

Software Specifications, Requirement Specifications, software projects, enterprise software, process modeling, wireframing, prototype, SpecMyApp, Kallos Solutions, SRS, Software tools

Project Setup & User Configuration | Requirements | Process Modeling | Wireframing |Collaborate |
Reports & Notification Modeling | Detailed Specifications and Rules |Extract for Project Execution
Accounts Control Panel


Our Story
Contact Us


For whom and for what purpose
Why SpecMyApp
Pricing & Signup
Quick Start Guide
Free Trial


Useful Links


+ 91 (0)44-42615064