Swedish web site
TDDC32 Design and implementation of a software module in Java
Requirements specification
What should the requirements specification contain?
Suggestions on what your requirements specification document should contain.
- On the first page you should have the project name as the main
headline. Then you should have a heading that identifies the document
as a "Requirements Specification" and further the version number of
the document, the names and emails of the project members, date of
the last modification. First page ends here.
- A summary that presents the purpose of the document, the context
of the project, and the main parts of the document. Should be around
2 paragraphs in length.
- Table of contents.
- Introduction. Should be more comprehensive than the previous summary.
- Document conventions. What the different symbols, text formats,
or reserved words in your document mean.
- System description, that gives an overview description of the
entire system and how it should be used.
- User interface. A description of how the user(s) of the system
interact and communicate with the system. E.g. commands, GUI,
etc.
- System Functions. Describe the tasks that the system should
perform and the problems it must solve. It is recommended to split the
functional requirements in mandatory requirements that have to be fulfilled,
and optional requirements that will be fulfilled if time permits.
- Non functional requirements. Describe any non
functional requirements on your system, such as performance,
security, presentation, etc.
- Storage of permanent data. If the system stores data (e.g. in
files) describe the structure of your database.
- Describe the limitations of your system, the cases it does not
address and other exceptions.
- Included in your requirements specification document you should
have the use case description of your system. You don't have to (but
you can) have a graphical version of the use case diagrams. (See lab 3 for suggestions on UML tools.) Give the
use case name, the actor(s), the relationship to other use cases (if
exists), and a description paragraph.
- Complete. All functionality should be described
- Clear and concise. It should have one interpretation only.
- All requirements should be testable. That is, a correct test
result can be specified for every case.
- Consistent. Requirements should be correct and not conflicting
with each other.
- Readable and well structured.
- In principle the requirements specification should not discuss
implementation issues. Concentrate on what the system does
not on how it should do it.
Page responsible: Tommy Färnqvist
Last updated: 2013-01-22
