Author: Arvind Subramaniam

“The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labor to perform the same task.”

– Tom Clancy (The Sum of All Fears)

In 1986 Alfred Spector then President of Transcorp and currently CTO at Two Sigma, Co-authored a paper which compared bridge building to software development. In the paper, he explains

“Bridges are normally built on time, on budget. Software never comes in on time or on budget. When a bridge falls down (or has technical and business difficulties) it is investigated, and a report is written on the cause of the failure. The resulting information is used to produce or refine the decision or decisions in an attempt to prevent recurrence of similar failures. This report becomes part of an architecture that is used to guide future decisions for successful bridge construction.However, in the computer industry failures are covered up, ignored, and or rationalized, which may be due to the absence of procedures for analyzing failures.

Subsequently, due to the lack of a rational explicit process, the same mistakes continue to occur and negatively impact the success of software development projects. Because of human failings, critical information is lost, decision making becomes difficult, and mistakes are repeated. It is the repetition of mistakes and the occurrence of new ones, because of improper decision making, that results in canceled projects, cost overruns, time overruns, and failure to provide expected features.”

A 2014 study by Standish Group claims that almost 48% of software projects are in a “Challenged” phase and 16% software projects “Fail”. While the study has its share of contestants, chances are if you are a software developer, project manager or a SME owner you would have come across software and IT development projects that failed for one reason or the other or projects that refuse to die, which are kept alive because of the critical need for the system or difficulties associated with admitting failure in large corporations although the initiative has lost momentum or gone out of control.

Apart from Alfred Spectors accusation that Software development failures are covered up or rationalized a huge problem today facing software development projects is frozen design and requirements are not always feasible because it does not accommodate changes in the business practices. Therefore, development teams, as well as project stakeholders, work on a flexible model. This leads to various issues and miscommunication and the end result is that the project ends up in the dumps. But in the case of building bridges this is rarely the case. No one wants to change the starting and ending points of bridges once the project has started, nor does the client expect a bridge designed for vehicular traffic to support trains. The design is frozen and the crew has little or no leeway in changing the specifications.

However, bridge building is not always foolproof as it seems. Over the course of human history bridges have overshot budgets, exceeded timeframes and some even collapsed. But today we have learned through failures and bridges are foolproof because of the extreme detail of the design.

The Sanginotobel Bridge is a world renowned structure and International Historic Civil Engineering Landmark built by Robert Maillart .

So what are the learnings we can draw from this analogy and use it to build better software? The Standish Group study lists down top three reasons for successful projects.

1. Stakeholder involvement,
2. Support from executive management
3. And a clear statement of requirements.

The key aspect that I believe determines success of the project is the statement of requirements or what we call a “Software Requirement Specification” (SRS) document. The SRS document should act as the gospel for all stakeholders not only during the entire duration and project from initiation to delivery but also beyond in testing and support phases. Whether you are a software development firm, an organization that has outsourced its Software requirement or working with an internal team, the SRS document is the first step in successful project completion.

Why is a Software Requirement Specification document necessary?

• Customers are good in understanding their problems, but in understanding how it can be solved
• Developers are good in solving problems but face difficulties in understanding customer needs.

A go to document that lays down all expectation and solutions in a tangible form will make it easier for every one sitting across the table.

The widely circulated comic on social media. Its a jest on how software development is viewed by each of the stake holders

What makes a good Requirement document?

• It describes a feasible project clearly and in detail
• It reflects the needs and use cases of the customers
• It gives a very picture of how the software will look, feel and work.
• It gives a mutually agreed upon time line, cost and expected deliverables without ambiguity.

The Anatomy of a Software Requirement specification document

While there is no one right format or template to capture SRS, a widely accepted and used template can be downloaded for free from here. Different organizations and different professionals follow formats that suits them or they may be used to a particular format. But in general a good SRS document will have the following points:

Introduction

• A brief outline and scope of the project
• References

Project Description

• Software functions
• Types of users and characteristics
• Environment
• Assumptions and dependencies
• Constraints

Interface Requirements

• User Interface
• Hardware interface
• Software interface
• Communication Interface

System Features

• Functional Features
• Performance Features
• Security Features

Glossary of Terms

• A review and explanation of all technical and scientific terms specific to the project covered in the document.

In certain instances, SRS documents do not live up to the expectation for the following reasons.

• Missing or incomplete requirement gathering
• Constraints not mapped thoroughly
• Insufficient or poor quality of data and requirement analysis.

It is very critical that we follow established and strict process for requirement gathering and arrive at an iron clad SRS document. Understanding and drafting SRS documents is not a skill that cannot be mastered. With adequate time, training and intent every body can become adept at SRS and ultimately contribute towards a highly successful software project implementation.

We have come a long way from the time of Roman bridges.  We may argue that building bridges and building software is not the same but never the less, just as construction crews and engineers over time have perfected the art of stringent design adherence towards bridge construction, software developers and the industry should perfect the art of building effective software with documented requirements and specifications.