This is a big part of requirements engineering. Talking to your
customer and people that are going to be involved in the development
of the software. The SRS document is supposed to be written in
a way that supports this work process.
You start out by writing down a brief project description, version of
the document and so on. In all major parts of the SRS you can use the
dl,dt and dd tags to add extra information.
The nonfunctionl requirements vary a lot that's why we let you
add them to the arbitrary data of the dd tag. For instance you may have
want to set some requirements on the design, hardware, environment and so on.
Everything that is not a functional requirement should be listed here.
Functional requirements and use cases
We choose to gather and describe functional requirements through
use cases. Talking to a customer you should try to figure out
how They want to work. Your job is to introduce better ways of doing
things if possible and to reflect on the pros and cons of doing things
a certain way, remember that changing the ways people work is probably the most
difficult thing to do so be careful when you propose fancy features and solutions.
Discussing a use case scenario like this will help
you see any problems that may arrise in the future of your solution.
If you look at the DTD for the SRS, you see that we start of by
gathering information about the actors that will use the software. Later
on you will reference these actors to use cases where needed.