• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Finally, you can manage your Google Docs, uploads, and email attachments (plus Dropbox and Slack files) in one convenient place. Claim a free account, and in less than 2 minutes, Dokkio (from the makers of PBworks) can automatically organize your content for you.


Topic - Software Specifications

Page history last edited by Dr. Ron Eaglin 5 years, 6 months ago

Software Specifications


A key skill of a professional working in systems integration is the ability to read and write software specifications. Software specifications (or often called Software Requirement Specifications - SRS). In integrating systems you will either need to build or purchase software. In both cases you must produce technical documentation of exactly what the software needs to do, and how it must function - and this is known as an SRS.


There are many methods to put together an SRS and these can differ markedly. The process of developing an SRS can take a tremendous amount of time and often involves being able to determine the needs of end users and translating them into a technical document that an engineering or software team can turn into a product.


Because software engineering is an engineering field and is treated as such - there are guidelines established by the engineering technical society IEEE. The most common of these is IEEE STD 830-1998, however there are other guidelines and different guidelines are appropriate for different types of projects. The guidelines are available for purchase from IEEE at https://standards.ieee.org/findstds/standard/830-1993.html. We are not going to require that in this course, but you should be aware of this and other standards for the development of software requirements specifications.




An excellent guide to writing an SRS by Robert Japenga is here - http://www.microtoolsinc.com/Howsrs.php 


Outline for SRS


Though we are not going to go into complete depth of using the IEEE standard for SRS - you should be aware of the basic outline which is included here


1.   Introduction
1.1   Purpose of the requirements document
1.2   Scope of the product
1.3   Definitions, acronyms and abbreviations
1.4   References
1.5   Overview of the remainder of the document

2.   General description
2.1   Product perspective
2.2   Product functions
2.3   User characteristics
2.4   General constraints
2.5   Assumptions and dependencies

3.Specific requirements, covering functional, non-functional and interface requirements. This is obviously the most substantial part of the document but because of the wide variability in organisational practice, it is not appropriate to define a standard structure for this section. The requirements may document external interfaces, describe system functionality and performance, and specify logical database requirements, design constraints, emergent system properties and quality characteristics.






An example of a SRS produced by the author of this site is at - http://ucf-sage.pbworks.com/w/page/9655640/SAGE%20Methodology 


Previous Topic - Topic -What is Systems Integration


Next Topic - Topic - Business Process Analysis



Comments (0)

You don't have permission to comment on this page.