Project Comments, 3/28
- Introduction. Enterprise overview and a statement of the
problem you will address. Describe the need for the system and how it fits
with business objectives. This could include the results of a (hypothetical?)
feasibility study conducted prior to beginning the project.
- Systems Models (showing system components and their relationships)
To help explain requirements.
Most important: what are the external interfaces and who uses it for what.
Your context diagrams are still trying to reveal design. Include the system
you plan to build only as a black box and show how it interfaces with the
rest of the world.
Discussions of who uses it sometimes sound too technical A viewpoint hierarchy
is great, but you might call it Figure X.
Data flow diagrams are fine if they describe requirements,
but often the don't.
- Requirements.
Functional: the services to be provided.
Non-Functional Requirements: constraints on the system and the development
process.
Put in one chapter
Are you going to organize requirements by user category or by function?
General preference: by function.
A reason to look at user categories is to try to identify the functions.
Cover each each service and each category of constraint
in its own subsection.
3.1 External Interfaces
3.1.1 An interface
3.1.2 An interface
3.2 A service or category of services
3.3 Another service
3.x Sections for nonfunctional requirements
or
3.1 External Interfaces
3.2 A user category
3.2.1 A service
3.2.2 A service
3.3 Another user
...
3.x Sections for nonfunctional requirements
Are ther requirements complete? E.g. could someone build the system you want from Chapter 3?
Are the requirements testable. Example "If the system fails, an error message will be displayed" versus a
list of failure conditions and corresponding messages.
Possible appendices:
- Glossary
- Detailed system models (use case descriptions, etc.)
- Tables of error conditions and corresponding messages