Advanced

Revisiting Software Requirements Specifications - What could we learn

Johansson, Björn LU and Rolandsson, Tanja (2010) 2010 International Conference on Accounting and Information Technology In [Host publication title missing] p.168-168
Abstract
A software requirements specification (SRS) is an important document that reports the result from the system requirements determination (SRD) which forms a basis for subsequent activities in the systems development process. In order to increase the knowledge base of SRS and how they could be structured nine SRSs are analyzed. The analysis aims at demonstrate similarities and differences in SRS composition and requirements organization. The reason for doing this is to be able to give some advice on how a SRS could be improved and thereby supporting development of information systems better. The result from the analysis shows that SRSs are structured either by following the IEEE (Institute of Electrical and Electronics Engineers) standard... (More)
A software requirements specification (SRS) is an important document that reports the result from the system requirements determination (SRD) which forms a basis for subsequent activities in the systems development process. In order to increase the knowledge base of SRS and how they could be structured nine SRSs are analyzed. The analysis aims at demonstrate similarities and differences in SRS composition and requirements organization. The reason for doing this is to be able to give some advice on how a SRS could be improved and thereby supporting development of information systems better. The result from the analysis shows that SRSs are structured either by following 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). In what specific way specific requirements in SRSs are structured differ from SRS to SRS. The most frequent type of requirements is functional requirements, which is not a big surprise. However, more unpredictably is that non-functional requirements are getting so low attention. One finding 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. But, standards high focus on functional requirement could be an influential factor explaining SRSs high focus on functional requirement. 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 for information systems in the future. (Less)
Please use this url to cite or link to this publication:
author
organization
publishing date
type
Chapter in Book/Report/Conference proceeding
publication status
published
subject
in
[Host publication title missing]
pages
168 - 168
publisher
Department of Accounting and Information Technology, National Chung Cheng University
conference name
2010 International Conference on Accounting and Information Technology
language
English
LU publication?
yes
id
349f2220-d242-48d0-b317-0c1df32f69d0 (old id 1653489)
date added to LUP
2010-08-18 09:07:39
date last changed
2016-10-07 15:32:32
@misc{349f2220-d242-48d0-b317-0c1df32f69d0,
  abstract     = {A software requirements specification (SRS) is an important document that reports the result from the system requirements determination (SRD) which forms a basis for subsequent activities in the systems development process. In order to increase the knowledge base of SRS and how they could be structured nine SRSs are analyzed. The analysis aims at demonstrate similarities and differences in SRS composition and requirements organization. The reason for doing this is to be able to give some advice on how a SRS could be improved and thereby supporting development of information systems better. The result from the analysis shows that SRSs are structured either by following 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). In what specific way specific requirements in SRSs are structured differ from SRS to SRS. The most frequent type of requirements is functional requirements, which is not a big surprise. However, more unpredictably is that non-functional requirements are getting so low attention. One finding 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. But, standards high focus on functional requirement could be an influential factor explaining SRSs high focus on functional requirement. 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 for information systems in the future.},
  author       = {Johansson, Björn and Rolandsson, Tanja},
  language     = {eng},
  pages        = {168--168},
  publisher    = {ARRAY(0x922b728)},
  series       = {[Host publication title missing]},
  title        = {Revisiting Software Requirements Specifications - What could we learn},
  year         = {2010},
}