his.sePublications
Change search
CiteExportLink to record
Permanent link

Direct link
Cite
Citation style
  • apa
  • harvard1
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf
Revisiting Software Requirements Specifications-What Could We Learn
Lunds Universitet.
The Swedish Armed Forces.ORCID iD: 0000-0001-5685-4046
2012 (English)In: MIS Review, ISSN 1018-1393, Vol. 17, no 2, 31-57 p.Article in journal (Refereed) Published
Abstract [en]

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.

Place, publisher, year, edition, pages
Department of Management Information Systems , 2012. Vol. 17, no 2, 31-57 p.
Keyword [en]
Software Requirements Specification, Requirements Engineering, Functional Requirements, Non-functional Requirements, IEEE 830
National Category
Information Systems
Research subject
Humanities and Social sciences
Identifiers
URN: urn:nbn:se:his:diva-9941OAI: oai:DiVA.org:his-9941DiVA: diva2:745707
Available from: 2014-09-11 Created: 2014-09-11 Last updated: 2014-11-07Bibliographically approved

Open Access in DiVA

fulltext(1709 kB)337 downloads
File information
File name FULLTEXT01.pdfFile size 1709 kBChecksum SHA-512
5087738dde1c1468b5805e765a142d89089c10abe597d79628901f046e067b17934282dfbcc8d233f9ea05f52dee5ee0476d48a21cd4545f5efe63097ce14609
Type fulltextMimetype application/pdf

Other links

http://gebrc.nccu.edu.tw/misr/pdf/volume/1702/1702-02-fullpaper.pdf

Search in DiVA

By author/editor
Rolandsson, Tanja
In the same journal
MIS Review
Information Systems

Search outside of DiVA

GoogleGoogle Scholar
Total: 337 downloads
The number of downloads is the sum of all downloads of full texts. It may include eg previous versions that are now no longer available

Total: 718 hits
CiteExportLink to record
Permanent link

Direct link
Cite
Citation style
  • apa
  • harvard1
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf