SRS FORMAT IEEE STD 830

How to write the SRS documentation, following IEEE Std. 830.

ISM 4331, J.Zalewski, September 2003

1. General

1.1 All documents should have a title page (to include information such as:  title of the project, course name and number, team members, place, date, and other relevant information).

1.2 Table of Contents normally makes a lot of sense, so should be included as well

1.3 Number all sections in the document.

1.4 Any reference correctly included in Section 1.4 should be written as follows:

For books, reports, theses, standards, manuals, etc.:

[number] NameOfAuthor(s), TtitleOfWork, Publisher, Place, Date

(if authors’ or editors’ names are not available, it can start with a title of the

name of the Publisher)

For papers/articles:

[number] NameOfAuthor(s), TtitleOfWork, JournalName, VolumeNumber,

IssueNumber, PageNumbers (pp. first-last), Year (or Month and Year)

For papers in Conference Proceedings:

[number] NameOfAuthor(s), TtitleOfWork, Phrase “Proceedings of the” Conference

Name, Place, Date[, Publisher, Place Date]

For websites:

[number] AuthorNames(s), TitleOfWork, Company’s Name, Place, Date, URL

Note. For names of authors never use full first names, only initials!

1.5 All references from Section 1.4 have to be referred to in the text (using [number]

notation)

1.6 Do not end section titles with colons.

1.7 Every figure/diagram should have a caption (number and titile).  Place it underneath

the figure/diagram.

1.8 Every table should have a number and title, placed above the table.

1.9 “Shall/Must” phraseology should not be used in unless it is requirement.  This means

that normally it is not used in sections 1 or 2.

2. Writing “Introduction”

- In Section 1.1 “Purpose”, describe the purpose of this document, not the purpose of

the software being developed.

- In Section 1.2 “Scope”, describe the scope of this document, not the scope of the

software being developed.

- In Section 1.5 “Overview”, provide an overview of this document, not the overview of

the software being developed.

- Definitions, in Section 1.4, should be write using the following template:

word_defined.  <in lower case, ended with a dot “.”> Followed by a definition.

For example:

user.  The person, or persons, who operate or interact directly with the product.

3. Writing “Overall Description”

- a Context Diagram is mandatory.

- other important characteristics are: Product Perspective, product Functions, User Characteristics, Constraints, Assumptions and Dependencies.

4. Writing “Specific Requirements”

- Never specify the Operating System or Language in the SRS, unless the customer

demands doing so.  These are strictly implementation issues, and well designed software

can be implemented in any specific programming language to run under any specific

operating system on any specific hardware platform.

- Specific Requirements Section should be split into:

* “External Interfaces” derived from the Context Diagram

* “Functional Requirements” that should be further split into “Input Requirements”

(related to user inputs, commands, etc.), “Output Requirements” (mostly related to the

GUI), “Input/Output Requirements” (if they cannot be separated), and “Processing

Requirements”

* “Non-Functional Requirements”, such as performance, reliability, safety, security, etc.

* “Design Constraints”, normally related to software and hardware limitations (OS,

platform, stand-alone or networked, network protocols, standards, etc.);

* “Database Requirements” – can be combined with “Design Constraints”.

- Use Case Diagrams have to be included in most sections, specifically in the “Functional Requirements” section.  Several Use Case Diagrams have to be presented, including

specific scenarios, how the system will respond to certain user/operator requests or

commands, or network behavior.

5. Other

- End your SRS document by the following line (centered across the page):

*** End of the SRS ***