Here are some thoughts on gathering requirements that I hope will
be useful.
The bioinformatics team has a pretty good set of requirements on-line.
Feel free to check it out. There may be others as well by now.
Suggested requirements document contents
-
BRIEF system description -- what does the system do? (2-6 sentences only)
-
Functional requirements -- logically arranged by FUNCTION (and,
possibly, by subfunction) Categories might include user interface,
communications, interfaces with other systems, security, data
manipulation, storage, user customization, etc. etc. ) It is this
functional breakdown that will primarily organize your requirements
document.
-
Individual requirements should be included in the appropriate section.
Individual requirements should be discrete (not embedded in a paragraph,
for example) and should stand on their own as much as possible. (This
will help in checking to see whether the system meets its requirements.)
-
Issues can be included at end of each section -- be sure to delineate
in some way! (italics and bold, for example. Or how about
using the border capability of MS Word?)
You should also separate constraints (e.g. cost, schedule, etc.) from
requirements
-
People often separate guidelines from constraints. Constraints are
more negatives whilst guidelines are generally more proactive.
-
An example of constraint: The minimum system requirements must be
implemented and fully tested by June 1, 1988.
-
An example of guideline: The team will use the PICTIVE system of
participatory design during the design phase of the project.
-
A glossary or list of appropriate definitions is often a very useful
addition to the document.
-
Sometimes a list of references is useful.
Miscellaneous Guidelines
-
It's better to have a section with the letters TBD (to be determined)
than a missing section.
-
The document is first and foremost, a communication vehicle -- between
customer, team, and the faculty advisor. Therefore you can use graphics,
tables, etc. IF that is what it takes to get the point across.
-
It's supposed to be
- CLEAR
- complete
- non-ambiguous
- testable
- consistent
-
The requirements document is NOT supposed to have design in it
but it
does need to have lots of information. E.g. If you know that a certain
algorithm is to be used then say it! (You shouldn't say how
you'll be
implementing it, however.) The document needs to be so clear and
specific
that no matter who designed and implemented it, it would have the same
functionality in either case.
|
