Tips for Writing Good SRS

From Requirements Management School

If you're not very familiar with to compiling documentation or writing, then being tasked with a Software Requirements Specification (SRS) for the first time can seem challenging. But you need not worry!

Writing SRS should be approached in the same way as any other writing task. Best practice when writing means that you need to go through the following stages:

  • Prewriting – gather all the data that you have; analyze it; plan out where everything fits into the SRS framework.
  • Writing – the first draft, plot out all of your content into paragraphs and manageable sentences.
  • Edit – the second draft, come back to your document with a fresh pair of eyes. Re-read it critically and make any necessary changes.
  • Proofread – the third draft, go through the document for spelling and grammatical issues. Check for inconsistencies and correct them.
  • Publish – issue the completed document.

Writing a good SRS document is something that comes with experience. It will take a few iterations of the process before you become fully comfortable with the conventions of an SRS. Using a predefined template is a good start because it ensures that you have a framework to follow. You are less likely miss any vital components this way.

Specific Guidelines

Here are a few helpful guidelines that will help improve the quality of the document that you produce:

  • Make sure your document is well organized:
    • Include a table of contents.
    • Make sure diagrams and tables are labeled and indexed.
    • Additionally provide an index if possible.
    • Make sure the document is well sign posted even within sections.
    • Clearly define all jargon and acronyms in a glossary.
  • Make sure that your document is well laid out:
    • Paragraphs must flow transitioning from one to another.
    • Make sure that there is plenty of white space for readability as well as note taking.
    • Make sure that you consistently highlight key points.
    • Headings must be consistent and act as sign posts.
    • Break up the text by using appropriate tables and diagrams.
  • Make sure that your document is written in a style that all stakeholders will understand:
    • Use short sentences and paragraphs.
    • Do not use the passive voice.
    • The language must be precise.
    • Use strong nouns and verbs.
    • Include use cases and use models
    • Fully address all stakeholder requirements
    • Define each requirement ensuring that each one is actionable; measurable; testable; relates directly to business processes/goals.
    • Use precise language so that the requirements are not open to interpretation. They must at all cost be unambiguous.
    • Make sure each requirement is unique and uniquely identified. Where a requirement is in multiple uses it should only be identified once and then cross referenced using its unique identifier.
  • All information contained in the document must be accurate and complete:
    • If you are not certain about something, clarify the position.