The key to the successful project completion is to have clear understanding of the requirements and the clear picture of the points to be agreed from the developer and the client end.
Common myth about Software Requirement Specifications
The common myth is writing requirements and preparing the requirement documents is the extra work, therefore start the work as the requirements are reached. The common problem with this scenario is, you will be able to start the project up to one or two modules. As the development progresses the new modules, will be added and there are very much chances that the exiting one will continue to change.
The lake of proper SRS (Software Requirement Specification document) results ambiguity for the development process, which is most likely to be delayed but has the serious worst impact on the budget of the project. Most probably, either the project results to failure or the relationships with the client get worst. Client, most of the time is usually unaware of the SRS (Software Requirement Specification document) document, and all the responsibility of development including the documentation of the project relies on the software house. As the situation becomes worst, client remains always on the safe side.
Survey conducted for the project failures shows that the major reasons are incomplete or ambiguous SRS(Software Requirement Specification document) or no SRS existence, Lack of skilled resources, unrealistic expectations, no or lack of managerial support and consistent changing requirements. Incomplete and inappropriate Project requirements are the major cause of the failures. Proper requirement engineering process can reduce the project failure risk to 25% as described above.
The key points for writing successful and meaningful SRS – Software Requirement Specification
The SRS document (Software Requirement Specification document) is the mutual agreement between the company and the client on the technical details. The appropriate and reasonable time spend on creating the well engineered SRS (Software Requirement Specification document) will not only reduce the development cost but will lead to successful completion of the project. Generally, the requirements are defined into two categories as behavioral requirements and the non-behavioral requirements.
Behavioral Requirements for SRS (Software Requirement Specification document)
The behavioral requirements address how the software performs operations. Behavioral requirements define the input an output for the system, as well how the inputs and outputs for the system interrelate.
Non-Behavioral Requirements for SRS (Software Requirement Specification document)
Non-Behavioral requirements in SRS (Software Requirement Specification document) address the different attributes related to the reliability, Efficiency, security, maintainability, portability, visibility, capacity and standards.
SRS (Software Requirement Specification document) document is communicated to the various in-house departments and the client. Therefore, SRS (Software Requirement Specification document) should not include the design details, implementation details and other constraints on the system. All these attributes are discussed in other documents related to the specific personals and departments.
The key quality attributes for the SRS (Software Requirement Specification document)
1. Correctness of SRS (Software Requirement Specification document)
The correctness of the SRS is to list only those requirements that the software should meet.
2. Unambiguous SRS- Software Requirement Specification document
Different personals and departments do have the concern with this; they may be from the non-technical end. To satisfy the different needs of each one, the SRS must be in language that when interpreted results to the one meaning. All the natural languages invite ambiguity, therefore always avoid using the natural languages like English and prefer to use the Z-Language or Col etc for SRS.
3. Verifiability of the SRS - Software Requirement Specification document
There should not be any requirement that is not verifiable by either the human being or the testing software. If there is any such requirement then this will not be possible to meet the requirements at any stage of the development cycle.
4. Consistency of the SRS - Software Requirement Specification document
The SRS must contain the consistent set of requirements. No requirement in the SRS should negate any other.
5. Understandable by Customers
The primary user of the application may not be the expert in the computer science and very positive chances are that he will not be able to succeed in complete understanding , if the SRS is written in technical details. Therefore, always keep the SRS very general and avoid the technical details including design and implementation details.
6. Conciseness of the SRS
SRS should be short as much as possible. Never goes into long description and brief, the primary requirements of the module.
7. Modifiability of SRS - Software Requirement Specification document
The structure and design of the SRS should be flexible enough that the changes to the requirements can be made easily and constantly.
Read more about SRS – Software Requirements Specification Document
Above are the guidelines for creating a successful SRS document. Following the above mentions points will lead to the understandable Software Requirement Specification document in the short time. Very neat and concise SRS document is the key to successful project completion. Related information may be read by visiting the URLs below.