Professional Documents
Culture Documents
Writing SRS
Writing SRS
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.4 Any reference correctly included in Section 1.4 should be written as follows:
For papers/articles:
[number] NameOfAuthor(s), TtitleOfWork, JournalName, VolumeNumber,
IssueNumber, PageNumbers (pp. first-last), Year (or Month and Year)
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.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.
- 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.
- 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 ***