Revisiting Software Requirements Specifications-What Could We Learn

10.6131/MISR.201203_17(2).0002

Bjorn Johansson；Tanja Rolandsson

Software Requirements Specification ； Requirements Engineering ； FunctionalRequirements ； Non-functional Requirements ； IEEE 830

MIS REVIEW：An International Journal

17卷2期（2012 / 03 / 01）

31 - 57

英文

Software requirements specifications (SRSs) are important documentations that reports results of system requirements determination (SRD) when developing software. It forms a base for subsequent activities in a system development process. In order to increase the knowledge of SRS and how such documentation could be structured we present an analysis of nine SRSs. From the analysis of similarities and differences in composition and requirements organization in the SRSs we aim at giving some advice on how a SRS could be improved and thereby supporting development of information systems better. The analysis shows that the overall structure of the SRSs either follows the IEEE (Institute of Electrical and Electronics Engineers) standard 830 with three main sections (introduction - overview - list of requirements), or another structure (introduction - references - list of requirements). However, how specific requirements then are structured and presented differ from SRS to SRS. The most frequent type of requirements is functional requirements, which is not a big surprise. However, more unpredictable is that non-functional requirements are getting less attention. One conclusion is that even though using standards might not be the only way to formulate SRSs, they are being used and serve their purposes, at least to some extent. However, it can also be concluded that the high focus on functional requirements in standards could be seen as an influential factor explaining why SRSs have such a high focus on functional requirements. The main conclusion is that future SRSs should spend more focus on non-functional requirements since these are both more difficult to describe and will probably play an even more important role when developing information systems in the future.

1. Adisa, F.,Schubert, P.,Sudzina, F.,Johansson, B.(2010).Living requirements space: an open access tool for enterprise resource planning systems requirements gathering.Online Information Review,34(4),540-564.
2. Aurum, A.(Ed.),Wohlin, C. (Ed.)(2005).Engineering and Managing Software Requirements.Berlin, Germany:Springer.
3. Avison, D.,Fitzgerald, G.(2006).Information Systems Development: Methodologies, Techniques & Tools.Berkshire, UK:McGraw-Hill.
4. Cysneiros, L.M.,do Prado Leite, J.C.S.(2001).Nonfunctional requirements: from elicitation to conceptual models.IEEE Transactions on Software Engineering,30(5),328-350.
5. Dahlstrand, M.,Fredborg, H.,Leandersson, S.(2009).Västra Götaland, Sweden,University of Boras.
6. Daniels, J.,Bahill, T.(2004).The hybrid process that combines traditional requirements and use cases.Systems Engineering,7(4),303-319.
7. De Carvalho, R.A.,Johansson, B.,Parthasarathy, S.(2010).Software tools for requirements management in an ERP system context.Journal of Software Engineering and Technology,2(2),101-106.
8. Droschl, G.(2000).Technical report, Institute for Software TechnologyTechnical report, Institute for Software Technology,Graz, Austria:Technical University of Graz.
9. Duggan, E.W.,Thachenkary, C.S.(2003).Higher quality requirements: supporting joint application development with the nominal group technique.Information Technology and Management,4(4),391-408.
10. Eriksson, U.(2007).Kravhantering för IT-System.Malmö, Sweden:Studentlitteratur.
11. Franko, S.,Hansson, M.(2006).Scania, Sweden,Lund University.
12. Grady, R.B.(1992).Practical Software Metrics for Project Management and Process Improvement.Upper Saddle River, NJ:Prentice Hall.
13. Halvorsen, K.(1992).Samhällsvetenskaplig Metod.Lund, Sweden:Studentlitteratur.
14. Hull, E.,Jackson, K.,Dick, J.(2005).Requirements Engineering.London, UK:Springer.
15. Jackson, M.(1995).Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices.London, UK:ACM Press.
16. Maxwell, J.A.(2005).Qualitative Research Design: An Interactive Approach.Thousand Oaks, CA:Sage.
17. McIlroy, R.C.,Stanton, N.A.(2011).Specifying the requirements for requirements specification: the case for work domain and worker competencies analyses.Theoretical Issues in Ergonomics Science
18. Nicolás, J.,Toval, A.(2009).On the generation of requirements specifications from software engineering models: a systematic literature review.Information and Software Technology,51(9),1291-1307.
19. Power, N.M.(2002).Dublin, Ireland,Dublin City University.
20. Smith, S.,Lai, L.,Khedri, R.(2007).Requirements analysis for engineering computation: a systematic approach for improving reliability.Reliable Computing,13(1),83-107.
21. Svenning, C.(2003).Metodboken.Eslöv, Sweden:Lorentz Forlag.
22. The Institute of Electrical and Electronics Engineers(1998).,New York, NY:IEEE.
23. The Institute of Electrical and Electronics Engineers(1998).,New York, NY:IEEE.
24. Véras, P.C.,Villani, E.,Ambrósio, A.M.,Pontes, R.P.,Vieira, M.,Madeira, H.(2010).Benchmarking software requirements documentation for space application.Computer Safety, Reliability, and Security,Berlin, Germany:
25. Wiegers, K.E.(1999).Software Requirements.Redmond, WA:Microsoft Press.
26. Wieringa, R.J.(1996).Requirements Engineering: Frameworks for Understanding.Chichester, UK:John Wiley & Sons.
27. Wiktorin, L.(2003).Systemutveckling på 2000-Talet.Lund, Sweden:Studentlitteratur.