Completeness and Consistency of the System Requirement Specification

Jarosław Kuchta

DOI: http://dx.doi.org/10.15439/2016F468

Citation: Position Papers of the 2016 Federated Conference on Computer Science and Information Systems, M. Ganzha, L. Maciaszek, M. Paprzycki (eds). ACSIS, Vol. 9, pages 265–269 (2016)

Full text

Abstract. Although the System Requirement Specification, as a first formal and detailed document, is the base for the software project in classic software methodologies, there is a noticeable problem of assuring the completeness of this document. The lack of its completeness causes uncertainty of the project foundations. This was one of motivations for agile methodologies -- if the SRS cannot be easily validated, if it can change in late project phases, then get rid of the SRS. Replace formal requirements with user stories. However user stories are also requirements - mostly functional requirements. As agile methodologies focus on functional requirements, it is easy to forget quality requirements.

References

1. “Ieee guide for software requirements specifications,” IEEE Std 830-1984, pp. 1–26, Feb 1984. http://dx.doi.org/10.1109/IEEESTD.1984.119205
2. A. Davis, S. Overmyer, K. Jordan, J. Caruso, F. Dandashi, A. Dinh, G. Kincaid, G. Ledeboer, P. Reynolds, P. Sitaram, A. Ta, and M. Theofanos, “Identifying and measuring quality in a software requirements specification,” in Software Metrics Symposium, 1993. Proceedings., First International, May 1993. http://dx.doi.org/10.1109/METRIC.1993.263792 pp. 141–152.
3. T. Shell, “System function implementation and behavioral modeling: A systems theoretic approach,” Systems Engineering, vol. 4, no. 1, pp. 58–75, 2001. http://dx.doi.org/10.1002/1520-6858(2001)4:1<58::AID-SYS6>3.0.CO;2-Z.
4. R. S. Carson and T. Shell, “Requirements completeness: Absolute or relative? comments on "system function implementation and behavioral modeling"[syst eng 4 (2001), 58-75],” Systems Engineering, vol. 4, no. 3, pp. 230–231, 2001. http://dx.doi.org/10.1002/sys.1019. [Online]. Available: http://dx.doi.org/10.1002/sys.1019
5. S. H. Kan, Metrics and Models in Software Quality Engineering, 2nd ed. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002. ISBN 0201729156
6. E. Knauss and C. E. Boustani, “Assessing the quality of software requirements specifications,” in 2008 16th IEEE International Requirements Engineering Conference, Sept 2008. http://dx.doi.org/10.1109/RE.2008.29. ISSN 1090-705X pp. 341–342.
7. R. Pressman, Software Engineering: A Practitioner’s Approach, 6th ed. New York, NY, USA: McGraw-Hill, Inc., 2005. ISBN 0077227808, 9780077227807
8. S. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. New York, NY, USA: John Wiley & Sons, Inc., 2002. ISBN 047127190X
9. “Ieee recommended practice for software requirements specifications,” IEEE Std 830-1998, pp. 1–40, Oct 1998. http://dx.doi.org/10.1109/IEEESTD.1998.88286
10. D. Zowghi and V. Gervasi, “On the interplay between consistency, completeness, and correctness in requirements evolution,” the Journal of Information and Software Technology, Volume 45, Issue, vol. 14, p. 2003, 2003.
11. T. T. Moores and R. E. M. Champion, “Software quality through the traceability of requirements specifications,” in Software Testing, Reliability and Quality Assurance, 1994. Conference Proceedings., First International Conference on, Dec 1994. http://dx.doi.org/10.1109/STRQA.1994.526392 pp. 100–104.
12. G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques, 1st ed. Wiley Publishing, 1998. ISBN 0471972088, 9780471972082
13. W. M. Wilson, L. H. Rosenberg, and L. E. Hyatt, “Automated analysis of requirement specifications,” in Proceedings of the 19th International Conference on Software Engineering, ser. ICSE ’97. New York, NY, USA: ACM, 1997. http://dx.doi.org/10.1145/253228.253258. ISBN 0-89791-914-9 pp. 161–171. [Online]. Available: http://doi.acm.org/10.1145/253228.253258