SRS document Helps to Protect IT Projects From Failure

Software Requirements Specification Document (SRS) gives business owners a clear vision of how much does it cost to develop their custom software product (web, mobile or desktop one). Who should write a software requirement specification? A business analyst. Belitsoft as a business analysis services company can help you with writing an SRS. Get a free quote or check out how to start custom software development without creating an SRS!

Contents

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 dedicated development 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.

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 specification

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.

Typical Mistakes

• 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

There is no one optimal complete example of software requirement specification for all types of software projects. Besides, these documents are confidential (check out our Privacy Policy). 

However, we prepared a general example of what kind of information the software requirement specification should contain to prevent software projects from failure.