Student Originated Software 1997-1998
Winter Quarter

A Software Engineering Course at
The Evergreen State College

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

  1. BRIEF system description -- what does the system do? (2-6 sentences only)

  2. 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.

  3. 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.)

  4. 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

  5. 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.

  6. A glossary or list of appropriate definitions is often a very useful addition to the document.

  7. 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.

For more information contact
[ Evergreen Home Page | Academic Programs ]

Created by: SoSwEbGrOuP