Abstract— There are many publications of the reasons and benefits of using software requirement specifications (SRS). A good SRS will provide us a clear goal in the software implementation phase. It provides us an established basis for agreement between the customers and the suppliers on what the implemented software product is to do. The requirements are transferable, reduce the development effort, provide a rough basis for estimating costs and schedules and provide a baseline for validation and verification. Furthermore, there are large amounts of definitions, guidelines, and standards available for writing SRS in terms of what it means, what it should contain, how the elicitation should be done for the requirements trawling. Unfortunately, SRS is seen as a major burden and as an artifact that has to be dealt with as soon as possible. This always leads to ambiguous, omitted, erroneous, and inconsistent software requirements that can and will ultimately lead to a software failure.
Index Terms— SRS, software requirement specification, software lifecycle, design documentation, architecture document, requirement document, design document, elicitation, software engineering, requirements trawling, project plan, user manuals, technical documentation.
I. INTRODUCTION
| This post tries to go through the good characteristics of Software Requirements Specification (SRS) by investigating what it is, where it is used, how it was used in different cases and where the emphasis should be when compiling it, an what are the overall benefits of using SRS which consequently all lead to the reasons in elicitation, compilation, and using the documentation. |
SRS is a written documentation for a software system or systems in general that explicitly states about the different users and stakeholders and what they wish to obtain or do with the software (functional and nonfunctional) and how the software system should behave under different use cases (validation and verification). It is an explicit statement of what the customers want and what the software suppliers provide [1].
The usage of SRS is not mandatory in software projects is not mandatory and the quality and features of SRS is usually regulated by the ordering customer and the company that develops the software. SRS and the generally known templates and standards only provide guidelines and good software development and design practices. There are multiple governmental regulations on safety, legal, and ethical issues for having some sort of documentation for later auditing and reviewing, but regulations vary from one country to another, but there are many reasons to compile a complete documentation.
As a main source of information, the design and use of SRS is considered as a good practice by many different professional organizations and there are various ways how it can be compiled. Furthermore, there is a wide variety of different published SRS standards and guidelines for different types of systems to make sure that the final system meets the users’ needs. SRS works like an established agreement and contract that contains unambiguous and complete formal and informal information about what the customers want and what the suppliers of the software have to implement and provide for the customer [1] [2] [3] [4].
A complete description of the software functions are given in the SRS document to assist the possible users/buyers of the software if it meets their needs and how the software or the specifications have to be changed. Adequate and original source of information for understanding on how to compile an SRS document is by taking look the IEEE publications (The Institute of Electrical and Electronics Engineering association), which is the leading consensus building organization.
There are several of other reasons for the compilation of the SRS document and the reasoning’s are the following. Our today’s software systems are complex, large, and highly integrated. Future software systems will become more integrated, large, and highly complex than the present day systems. As the size and the comprehensibility of the software architectures have become more complex and harder to grasp, new problems have arisen. The need for more heavy weight requirements elicitation and analysis arose since there is no longer room for ignoring the proper requirements documentation, due to modern software projects being evidently harder to be comprehended by just relying on informal communication with the software engineer. It is necessary to be able to do an extensive iteration between the client and business analyst for the software requirement specification and the system definition before any implementation occurs [1].
Since SRS is compilation of trawled customer and stakeholder needs; it does not specify the design and implementation details and this means that the document is transferable from the specialized business analyst company to the implementing software developer company without any need for future collaboration although this option is still a possibility [3] [10].
Furthermore, SRS can be developed in agile projects where the requirements elicitation is being done in short iterative stages where the customer is part of the development team and communicates through meetings, internet (email, chat, and conference), or phone. Projects that use agile paradigm in the development phase have more freedom in the software design and development where refinement of both the SRS and software is possible. Furthermore, it is a characterized as a shift from traditional (heavier process structure, principles, methods, and documentation) to a more modern, transparent, and lighter method driven by industry practitioners. The difference between the agile and waterfall methodologies are that the SRS in waterfall software development projects always take place before any design and implementation (even though changes to SRS is still acceptable at this point) while in agile methodologies the implementation can be started by using just the use case stories and filling out the SRS in iterative manner throughout the development process [15] [17].
In this research paper we seek to investigate and state the benefits of using software requirements documentation in the software development projects by trawling through various literal and online sources related to the found benefits in different case studies. The hypothesis and statement is that the quality of the software requirement documentation contributes to the success of the development project, as a consequence of having detailed documentation about the required software product.
II. METHOD
The method of understanding, how the usage of SRS can be beneficial, is through research by conducting a survey or a case study in already finished software projects where the project members and workers are still available by using qualitative and quantitative methods. Since this phase has been already done for us by various researchers, we will only use various case studies and previously conducted surveys to find out the benefits of SRS by looking at the relationship between successful and failed IS/IT projects and the used development methodologies.
The process of finding the right information was by using various keywords related to SRS in general and then by going through the perceived benefits of SRS in different white papers by first doing an initial pass, over the data and then reviewing them in more detail if the categorization and topic met this papers goal.
In addition, SRS in itself engages the developers in various ways and there are readily available and standardized templates that have relevant questions for the developers to go through to be able to develop their final product or prototype so the first method is to go through the SRS document and what it provides and then move to few existing case studies and how SRS might have been beneficial.
The hypothesis is that any errors in the documentation like omission of important information, incorrect facts, and inconsistent information leads to incorrect system functionality and thus highlight the benefits of using SRS so the beneficial aspects would be found by looking at the problems arising when it is not used [1].
To begin with, the software requirements specification for a particular software product or program is a basic description of what functionalities the wanted product should have and how this software should behave i.e. it describes what the customers want and what the suppliers have to produce and answer to the questions like why, what, where, and when. This in itself will help the developers to have a good understanding of what needs to be done and also it provides a shallow level prioritization of the requirements and usually no work is executed without having the documentation independent of the used software development methodology [21].
The SRS elicitation therefore is a customer initiated software project phase where the SRS is compiled before any work is started so that the development team knows what to produce as an final shippable product [1] [2] [4].
The de-facto process of how the SRS is compiled is by sending or having a business analyst onsite to work with the customer and stakeholders by first identifying them in their own premises and trawl through the customer needs by investigating, interviewing, and observing different stakeholders. For example, in situations and cases where there is a manual process that has to be completely automated as a requirement; the business analyst will come to the location where this manual process is conducted and the analyst will investigate and understand the process by observing the current practices similar to what ethnographic researchers [1] do. The requirements elicitation is done by interviewing different stakeholders for use cases, functional and nonfunctional requirements [1] [3] [5].
SRS contains at least the following factors: purpose, scope, definitions of the used terms / acronyms / abbreviations in the document, overview, product perspective, product functions, user characteristics, general constraints, assumptions and dependencies, functional and nonfunctional requirements, performance requirements, design constraints, attributes, external interface requirements, other requirements and so on. It should not contain anything that is not related to the software requirements, for example, the implementation details like the used programming language, database design, etc. [21].
Characteristics of a complete SRS are the following factors. SRS should be unambiguous, complete (heavy and all the SRS viewpoints trawled through), verifiable, consistent, modifiable, and traceable [21].
Also, there are other types of complementary software specification tools that can be added to a more known and standardized SRS documentation. One of the types is called formal specifications or formal methods (FM). They are system specifications (and design) techniques that use rigorous amounts of mathematical models to design and specify the stakeholder requirement functionality without any implementation details. These kinds of specifications will reduce the amount of erroneous behavior of the software and are heavily used in safety-critical systems. The reasons for using FM are the following [10]:
- The specialist / user / stakeholder might have a certain constraint and functionality related requirement that they need the implemented software to execute.
- The system should behave in an exact way in different cases (medical devices, rockets, astronomy / physics related systems).
By using one or various standards and guidelines; the process of requirements elicitation is usually straightforward and the process itself has no reported drawbacks since it is scalable depending on the project size and complexity, but still there have been numerous problems regarding erroneous elicitation.
III. RESULTS OF THE RESEARCH
The assumed benefits of using SRS are numerous on different phases, levels, and dimensions for a software development that contribute to the reasons of using it.
The usage of SRS can eliminate and prevent errors in the design phase since any contradicting requirements and functions that need validation can be fixed at this point and stakeholders can be contacted for reevaluation. This way, no requirement errors can creep into our code and there is no need for countless of hours, energy, and resources to be spent on the code testing, modification, and debugging [1] [11] [21].
SRS can provide the managers of any particular enterprise and organization a rough estimate so that they can plan and estimate their own schedule, effort, and resources for the project and the project has lesser risk to fail [2] [8] [9].
There are numerous examples and cases about the consequences of negative software requirement specifications or missing one. One of the most common consequences is that the project will fail one way or another i.e. the software budget exceeds two-three times of the originally planned, the software does not meet the customer and stakeholder needs, the software is buggy and is abandoned. The most common problems or factors in the software failures have been ranked as follows [14] [18] [22]:
- Lack of top management support or commitment to the project
- Functional, performance, and reliability requirements and scope are not documented
- Project stakeholders have not been interviewed for project requirements
- Undefined project success criteria
- Project team members have weak commitment to the project scope and schedule
Common denominators in the failures were unrealistic and unverifiable goals, estimation of the workload, poor communication between stakeholders and developers.
There are other factors involved also, but one third of the problems were related to poorly written SRS, but this factor is not always taken into consideration when allocating the budget for the software project. For example, the typical antagonist view of the SRS is that it might take too much time to compile a requirement and that having a detailed SRS is not the main obstacle. Furthermore, SRS needs to be refined and prototyped and you need a specialized (expensive) person to do the conceptual and detailed technical requirement work. Also, the main argument is that the SRS might be outdated by the time the documentation is finished, making it useless for the customer. Then again, if the sought and resulting system is implemented with wrong behavior, it will be difficult to rework the software later after the implementation, but in many projects, this is a common problem for both the ordinary developers and specialists [11].
Software specialists typically use about 50 percent of their time in avoidable rework because of the missing or incomplete requirements in projects that were not considered as “complete failures” i.e. they were implemented and kept (not abandoned) afterwards despite over exceeding the budget and late delivery time. There have also been cases where the specialist or developer uses a considerable time in reworking the code while the project is ongoing until the last moment before the product is deployed as stakeholders constantly keep adding more requirement requests. The question remains that, what is the reason for the companies continuously keeping their documentation plain and simple despite the problems and the comparison of SRS with the architects building blueprints? One of the reported reasons were that the compilation of a complete documentation before any work is conducted might be too costly and time consuming and the SRS might be outdated by then [18] [8] [12].
On the other hand there is the possibility of having too much information in the SRS if too much effort was put on compiling it, which can affect negatively on the project development even despite the SRS being complete and good and all good characteristics are in place [18] [8] [25] [26].
The term used for the information overload In the case of usable information system artifact is called “Information Paradox” and it means that when it happens, it affects in reverse of the expected value addition, but this is usually in cases where the information overload was because of unnecessary amounts of documented data in the SRS where the issue of the existing heavy documentation was partly dismissed. This other side of the extreme is rare since the heavy SRS documentation is usually compiled (or should be) for a multi-billion, large, and complex software system or for a safety-critical software and hardware where the stakeholder elicitations usually need verification and validation. Nonetheless, these types of cases are rare and information paradox was the result of wrong type of elicitation for a particular system where the heavy and complete documentation in itself does not contribute negatively i.e. the developers with the business analyst should not take into consideration the fear of compiling too large and heavy SRS since the benefits outweigh the disadvantages on many levels and dimensions [18] [8] [25] [26].
To minimize the problems in the process of writing and compiling the final version of SRS; there has been multiple publications on how the documentation process can be made more lighter without losing any customer requirements or other notable factors that make the documentation useful. The one proposed idea was to have multiple of analysts to trawl for the same requirements and then modify the end result in the unification or developing the software in iterative stages. This will cut down the required time for the release of the document since the customers must be part of the requirement phase intensively so that a complete and detailed SRS is finished, before a single line of code is implemented. This characteristics is important since the typical modern software projects have large sizes and they are complex not to mention that the development teams can be multinational working in different separate locations where the well compiled SRS will provide the clear goals and tasks for work segmentation and delegation especially when the SRS is compiled in iterative stages [10] [18] [22] [25] [26].
The other suggested way in conducting the SRS elicitation and compilation a more feasible way is by implementing formal methods (lessens informal text). It is based on validation and verification of the requirements by relying on mathematical representation where the problem domain is well understood [27].
The results thus are very clear and consistent. Without SRS there cannot be any kind of work and the quality of work is dependent on the documentation. Compilation of SRS can be used with any type of development methodologies more or less and studies have shown that it is imperative to have an elicitation phase to have a project start as conceptualized in the below picture because otherwise no software design can happen whether or not the software development methodology was using agile[2] (implementing the system in iterative stages where SRS is ready before any implementation phase) or waterfall[3] approaches [23]:
Figure 1: Software development lifecycle
The first case is the Obamacare’s website which was and still is widely known as one of the largest failed IT projects of this generation in terms of the quality of code, budget, functionality, and time used to develop it. The project suffered major problems from the beginning of the development when the developers did not know the clear picture of the application functionalities or what was required of the different functionalities in detail. The SRS was said to be incomplete and it contained erroneous information not to mention that the standard procedure of building a software application in terms of design and development process was not used or followed properly [25] [8].
IV. DISCUSSION
The level of SRS usage, varied substantially between different software projects. According to the research and investigation behind the IS/IT project failures, the project cases that had a poor project management and documentation had persisting and reoccurring problems. Furthermore, the problems were occurring from one project to another, which let the companies and researchers to investigate the core reasons behind these failures by decomposing the development process and let them come to a conclusion that the followed process practices, management, and documentation were the main issues is the problems i.e. the factors related to poorly written documentation or in another words SRS, highlighted the beneficial aspects of a properly compiled software requirements specification.
On the contrary some companies reported successful projects after the failures without any clear definitions for the success, but the assumption is that since the failures were mostly related to project management and documentation the successes later must have been caused by multiple factors that were related to improved processes. In general, it does not seem to matter whether the software requirements were compiled for a government specific purpose or for individual organizations in terms of project failure and success factors since the procedures in software development projects are almost the same whether it is by an governmental or non-governmental organization [8] [12] [24].
The results are clear-cut. The low-level usage or erroneous stakeholder requirements elicitation has always lead to project failures, unmanageable project expenses, and late delivery time. The reasons have always been insufficient and concrete low and higher level goal descriptions, constraint descriptions, and estimation descriptions.
In nearly all the cases the SRS was confusing, missing, and had wrong information in it. Reasons for poorly written or missing SRS ranges from internal workplace politics to poor project handling, but those factors are out of the scope of this research paper. Fortunately, for us the failed software projects highlighted the beneficial aspects and reasons of using SRS in the software development life cycle.
Without having a complete and unambiguous SRS documentation the software project has failed before it started. The whole usage of the document is based on mutual understanding between the developers, customers, and users based on natural language and naturally, any unambiguous, inconsistent, and incomplete requirement can be implemented erroneously by the developer. If the SRS does not state accurately what the customers wish to obtain and what the developers have to deliver then the whole meaning of using the document becomes obsolete [16].
Only a few percent of the problems throughout the software life cycle can be attributed to technical challenges. Rests of them are related to the SRS on some levels and the problems of not having it for the project management.
A good SRS characteristic can be similar to a real world architects construction designs and blueprints even though software architecture is considered as a design and not part of the SRS. Nonetheless, even if SRS does not have any design details, it has enough details to construct the design, models, and system architecture and this is why, it has been omitted several times even in the enterprises where the previous software failure was related to same kind of mistake because of the small perceived importance of the documentation [28].
In conclusion the SRS benefits can be categorized in two parts. One was software requirement specification documents of quality attributes since correctness is the premise of accuracy and the second one was the perceived value additions by the developers or teams that were part of the development project like better management decision making process in the development life-cycle. The general benefits of the SRS quality attributes were [28]:
- Accessibility (requirements available for the whole team and there is no information hiding on any level)
- Accuracy (exact information can be found that is precise in nature to convey the needed information and descriptions)
- Author-related (every requirement and document change can be traced to certain authors for missing information clarification)
- Completeness (SRS is complete in terms of supporting the development team to know what needs to be done for different functionalities, non-functionalities, and modules)
- Consistency (no conflicting information is supposed to be present in SRS to help the developers build a program that has integrity)
- Correctness (information should be right, factual, and non-misleading i.e. there are no barriers for working),
- Information organization format (provides a segmented, categorized, sorted, and organized document that is easy to read and the structure is logical)
- Readability (clarity)
- Similarity
- Traceability
- Trustworthiness
- Up-to-date-ness
- Other
The perceived benefits in the software requirements specification documentation were development aid, management decision aid, maintenance aid, architecture and design comprehension, code comprehension, perceived importance of the project, reduction in the development effort that showed in the reduced time, final product usability and success, and other like reduced development and maintenance costs.
V. LIMITATIONS ON THE RESEARCH DESGN AND MATERIAL
The limitations of the used method for writing this research paper was that it only contained already existing surveys, questionnaires and various published papers and online books. This kind of research methodology will not provide accurate and up-to-date information to back up the topic statement. Instead, the reliance is on other research papers and the supervising authors work ethics i.e. the quantitative and qualitative data might not answer the research statement at hand and the previous research might not be hundred percent right.
Therefore the research would have been more feasible if it was designed to find the beneficial or useful characteristics of SRS by conducting a web based survey for different companies and their employees on different levels and dimensions and then investigate the data by categorizing and sorting the survey data by using the qualitative and quantitative approach, to find out the relationship between the beneficial characteristics of SRS in general and shallow level, but because of the time limitation, this particular approach was not be implemented since the length of the research in itself was estimated to be between 9 – 13 months if all research phases was taken into consideration.
Furthermore, the research question itself was too general and limited the focus of the paper as the initial plan was just to create a research plan and several sources had to be omitted because of the general characteristics of the topic, research methods, tools, and metrics.
References
[1] P. Jalote, An Integrated Approach to Software Engineering, Kanpur:
Springer, 2005, pp. 79 – 152.
[2] Agarwal, B. B., & Tayal, P. S. (2009). Software Engineering. New
Delhi: FIREWAL MEDIA.
[3] Al-Khanjari, Z. A. (2014). Proposing a Systematic Approach to Verify
Software Requirements.
[4] Bass, L & Bergey, J. & Clements, P. & Merson, P. & Ozkaya, I. &
Sangwan, R. (2006). A Comparison of Requirements Specification
Methods from a Software Architecture Perspective. Carnegie Mellon
Software Engineering Institute.
[5] Bomarius, F., Oivo, M., Jaring, P., & Abrahamsson, P. (2009).
Product-Focused Software Process Improvement. 10th International
Conference, PROFES (pp. 28 – 42). Oulu: Springer.
[6] Collins, M. (1989, April 1). Formal Methods: Dependable Embedded
Systems. Retrieved 2015, from Carnegie Mellon University:
http://users.ece.cmu.edu/~koopman/des_s99/formal_methods/
[7] Dingsoyr, T., Dybå, T., & Moe, B. N. (2010). Agile Software Development: Current Research and Future Directions. New York: Springer.
[8] J. Ditmore, “Why Do Big IT Projects Fail So Often?,” 28 10 2013.
[Online]. Available: http://www.informationweek.com/strategic-
cio/executive-insights-and-innovation/why-do-big-it-projects-fail-so-
often/d/d-id/1112087?.
[9] Ellis-Braithwaite, R. (n.d.). Analyzing the Assumed Benefits of
Software Requirements. London: Loughborough University.
[10] Farsimadan, K. (2014). Vaatimusmääritys ALV-raportin
automatisointisovellukselle. Helsinki: Haaga-Helia University of Applied
Sciences.
[11] Frederick, P. B. (1987). No Silver Bullet – Essence and Accident in
Software Engineering. IEEE, 0-19.
[12] Gulla, J. (2012, March 1). Seven Reasons IT Projects Fail: Avoiding
these pitfalls will help ensure success. Retrieved from IBMSystems
Magazine:
http://www.ibmsystemsmag.com/mainframe/tipstechniques/applicationdev
elopment/project_pitfalls/?page=2
[13] IEEE. (1998). IEEE Recommended Practice for Software
Requirements Specification. New York: The Institute of Electrical and
Electronics Engineers.
[14] Kappelman, L. A., McKeeman, R., & Zhang, L. (2006). Early warning
Signs of IT project failure: The dominant dozen. Infortmation Systems
Management.
[15] Muscat, Oman: Journal of Software Engineering and Applications.
[16] Palomares, C. (n.d.). Definition and Use of Software Requirement
Patterns in Requirements Engineering Activities. Catalonia: Universitat
Politecnica de Catalunya (UPC).
[17] Ramesh, B.;Cao, L.;& Baskerville, R. (2010). Agile requirements
Engineering practices and challenges: an empirical study. Atlanta:
Computer Information Systems Department, Georgia State University.
[18] Robert, N. C. (2005). Why Software Fails: We waste billions of
dollars each year on entirely preventable mistakes. IEEE Spectrum.
[19] Stanley, R., & Uden, L. (2013). Why Projects Fail, from the
Perspective of Service Science. 7th International Conference on
Knowledge Management Organizations: Service and Cloud Computing
(pp. 421-429). Springer.
[20] Wiegers, K., & Joy, B. (2013). Software Requirements. Washington:
Microsoft Press.
[21] IEEE. (1984). IEEE Guide to Software Requirements Specification (Std 830-1984). New York: IEEE.
[22] R. R. Nelson, “IT Project Management: Infamous Failures,Classic Mistakes, and Best Practices,” MIS Quarterly Executive, vol. 6, no. 2, pp. 67 – 78, 2007.
[23] S. S. Al-Fedaghi, “Conceptualizing Software Life Cycle,” in Information Systems: Modeling, Development, and Integration, Sydney, 2009.
[24] R. Kaur and J. Sengupta, “Software Process Models and Analysis on Failure of Software Development Projects,” International Journal of Scientific & Engineering Research, vol. 2, no. 2, pp. 1-4, 2011.
[25] A. U. Khan, J. R. Qurashi and I. A. Khan, “A Comprehensive Study of Commonly Practiced Heavy and Light Weight Software Methodologies,” International Journal of Computer Science, vol. 8, no. 4, pp. 441 – 449, 2001.
[26] M. Ullah, “Comparison and problems between Traditional and Agile software develoment methpds,” Lapeenranta University of Technology, Lappeenranta, 2014.
[27] J. Rushby, Formal Methods and the Certification of Critical Systems, Menlo Park: SRI, 1993, pp. 7 – 21.
[28] J. Zhi, V. Garousi-Yusifoglu, B. Sun, G. Garousi, S. Shahnewaz and G. Ruhe, “Cost, benefits and quality of software development documentation: A systematic mapping,” The Journal of Systems and Software, pp. 1 – 24, 2012.
Kurosh Farsimadan 