Defining Requirements
Requirements are much more than just a "to-do list" with a hierarchical
number scheme, although many projects rely on exactly that, in a spreadsheet
or a word processing document, which may or may not be kept up-to-date and
version-controlled.
-
Requirements must be classified. (How do they fit into a dependence
hierarchy?)
-
Requirements must be validated. (Do they pertain to fulfilling the need?)
-
Requirements must be consistent. (Are there any contradictions?)
-
Requirements must be complete. (Are we going to have scope creep?)
-
Requirements must be version controlled, and changes must be revalidated.
-
Requirements must have traceability. (Who originated this requirement? Who changed it?)
-
Requirements must be partitionable according to a number of different
criteria such as:
-
Priority: What group can comprise parts of an incremental delivery?
-
Modularity: What group can be assigned to a single team?
-
Access control: What group can be read, modified, deleted by which
individuals?
-
Requirements must directly relate to other CASE documents such as
Use Case diagrams.
-
Requirements must be testable, and must be able to be associated
with the applicable tests.
This tool will implement all of these facets of Requirements. Additionally,
it will:
-
Enable viewing of requirements from different perspectives
-
Allow graphic display of requirements or subsets wherever it make sense
to do so.
-
Plug into Eclipse, or other Open Source IDEs (if there are any).
-
Store requirements in a communicable form to use other Open Source
CASE tools.
