How to Write an SRS (software Requirements Specification)

1. Consider using one of the SRS templates attached. Template #1 is less formal than Template #2.
2. Meet with the subject matter experts/clients to gather the requirements.
3. Define the functions of the software.
4. Create use cases for the major sub-processes. For example, if you're designing an order entry system, use cases would consist of creating a new order, modifying an existing order and a customer order search.
5. Define the user interface.
6. Define any other interfaces such as hardware interfaces or other software system interfaces.
7. Define the process flow.
8. Determine any specific business rules.
9. Define the performance specification.
10. Create any diagrams needed to illustrate the process flow or elaborate on key requirements.
11. Compile the SRS document and have all necessary parties review or sign it.

 Tips:

• Create a standard document template.
• Include a traceability matrix.
• Include a linkage between requirements and the source of those requirements.
• Clearly list defined business operation rules.
• Ensure the rules and processes are defined with precise, unambiguous language.
• The SRS only contains functional requirements. No software design or implementation details should be included

Questions during a meeting to discuss a project spec:  (courtesy of Tom Dietsche)

1. Request filled-in copies of ALL their current paper-based or automated forms,
with good examples of typical data and especially of any uncommon/unusual data.
This is the single most useful thing to get. Empty forms are much less useful.

2. Talk thru how a field person's normal day goes, and what variations can occur.
- what actions do they perform each day?
- what is the normal process from the end-user POV?
- what unusual actions can happen?
- (etc.)
These are the "use cases".

3. Discuss the major problems they have with their current methodology.
This will provide insights into the things we need to most focus on to be successful.

4. Find out what they want to do that they cannot do now. How can we help with this?

5. Get schema and data examples for the tables in their current back-end DB that we will be using.


Note 1:
It is useless to try to figure out absolutely everything at the start.
Better to get most of the big items figured out and then just jump in and start swimming,
then you will figure out what else needs to be done.
Nobody is smart enough to come up with a 100% spec in advance.

Note 2:
We should NOT start by modifying the UI, this should be the LAST thing we change, based
on more fundamental core requirements. But users like to focus on UI, not on core stuff.