Software Requirements Specification Helps to Protect IT Projects From Failure
Working without a software requirements specification document. Source: projectcartoon.com
THE COMMON CAUSE OF SOFTWARE PROJECT FAILURE: ABSENCE OF WELL-DEFINED REQUIREMENTS
Unfortunately, up to 70 percent of IT projects without well-defined requirements fail. Poor management of requirements is the second most commonly-cited reason projects fail. Organizations are wasting up to 10 times more money on projects and programs due to poor management of requirements.
Case study: Libra IT system for magistrates’ courts. The cost of the Libra project to provide a national system for 385 magistrates courts in Great Britain soared from £146m to £390m, and the main supplier Fujitsu twice threatened to withdraw unless it was paid more money. Review in February 2002 revealed that Fujitsu had made "too many mistakes in the early life of the project" including a poor analysis of requirements.
Professor Leon Kappelman who consults for the White House and United Nations puts in his research article ‘Early warning signs of it project failure: the dominant dozen’: «If functional, performance, and reliability requirements are not documented, then each project team member and stakeholder inevitably will have different expectations and assumptions about the project, because each participant is working from a different mental blueprint. Asking for sign-offs on requirements documentation forces differences in expectations and assumptions to the surface where they can be resolved».
List of failed and overbudget custom software projects.
Image source: spectrum.ieee.org/computing/software/why-software-fails
BENEFITS OF SOFTWARE REQUIREMENTS SPECIFICATION
According to International Standard ISO/IEC/IEEE 29148:2011 (Systems and software engineering — Life cycle processes — Requirements engineering), the benefits of documenting the software requirements include:
- It provides a realistic basis for estimating product costs, risks and schedules.
- It provides an informed basis for deploying a product to new users or new operational environments.
- It provides a basis for product enhancement.
- It forces a rigorous assessment of requirements before design can begin and minimizes later redesign.
- It establishes the basis for agreement between the acquirers or suppliers on what the product is to do (in market driven projects, the user input may be provided by marketing).
- Organizations can use the specifications to develop validation and verification plans.
Figure. What should be considered before Software Requirement document is done.
THE RIGHT PEOPLE SHOULD WRITE THE SOFTWARE REQUIREMENTS SPESIFICATION
The software requirements specification may be written by one or more representatives of the supplier, one or more representatives of the acquirer, or by both.
The main rule here is that only professionals should write it. Otherwise, software requirements specification should be reworked to detect defects in it, further fix them and thus avoid problems in future.
Defects in software requirements specification can lead to wrong or incomplete product. The outcome of the development process will not satisfy the customers’ needs. The more progress is achieved in the software development life cycle, the more defects will emerge. Consequently, the earlier the detection of requirements defects, the more money and time of rework that can be saved.
Here, the most typical mistakes in the software requirement specification (SRS) are gathered. Examples are taken from real documents in real commercial software projects.
- SRS has no glossaries. «UUID is set incrementally to make sure there are no two users with the same account number». It would be great to know what “UUID” stands for. What is the difference between UUID and account number? Is it "unique user ID" or maybe "unified user identity descriptor"?
- SRS has questions, opinions and so on. «I believe that multiple versions of the API must be supported. What options do we have? I'd suggest we go with versioned URLs. Feel free to post your thoughts here». SRS should contain exactly what needs to be done without discussions.
- SRS has un-measurable quality requirements. «The app should launch in less than 2 seconds». On what equipment? What does "launch" mean? Such a requirement is difficult to implement or test.
- SRS describes functions without defined user. «PDF report should be generated when required. It is possible to download a report or save it in the account». It's not clear who is doing all this. It may be a system, a RESTful API client, a database, registered user, admin etc.
- SRS contains no requirements. «Our primary concern is performance and an attractive user interface». This is an example of useless information for the developer.
EXAMPLE OF SOFTWARE REQUIREMENTS SPECIFICATION
However, we prepared a general example of what kind of information the software requirement specification should contain to prevent software projects from failure.