JReality
JavaTM Virtual Reality Applications and
Related Technologies
"Freedom" Service-Oriented Methodology
Requirements Process
Principles -- Requirements
- Quality First (Q1) Principle:
Needs for quality supersede needs for expeditious development
Build software to be functional, reliable, usable, administrable,
maintainable and efficient even though this is difficult.
80% of the cost of software accrues after development.
Working harder and longer to improve quality during
development benefits the customer in the long run.
- Customer Involvement (CI) Principle:
The customer or his knowledgeable representative must directly assist in
requirements specification
Only the customer knows what he wants, even if he can't articulate it.
Embedding customer expertise directly into the development team is the
surest, and often only, way of discovering the correct requirements.
- Reuse Principle:
Don't build when you can reuse
Check the reuse library for needed requirements modules before
specifying new requirements modules. Reusing, when possible, is
usually more cost-effective than building.
- No Prose Principle:
"Prose is the sign of an error"**
Avoid natural language prose in requirements. Prose leads to
ambiguous, incomplete, inconsistent, unverifiable specifications.
** Quote from David Parnas, former head of the Software
Cost Reduction project team that codified information-hiding.
Prioritize Quality Requirements
Quality requirements reflect the customer's priorities for
quality in the software to be developed. The default quality
requirement priorities may need to be changed to reflect the
customer's actual quality priorities for the given project.
The customer-ranked quality requirements are used as engineering
trade off decision criteria when selecting among competing technical
approaches or options when developing the capability requirements,
design, implementation, tests, documentation, and other technical
work products for the project.
Identify & Organize Stimuli
The external
stimuli
detectable by the application program are identified by considering
all program inputs from three possible sources -- human user
interfaces such as GUIs, external system interfaces such as networks
and files, and physical environment interfaces such as clocks and
sensors. To make a large number of stimuli manageable by
the people who will develop, use and maintain the software, the
stimuli are organized by grouping them into
stimulus sets
The stimulus sets are organized into a tree structure called a
functionality tree that shows which stimulus sets activate which
other stimulus sets. In so doing, the functionality tree records the
external interface architecture (i.e., the requirements architecture)
of the system. A functionality tree is the primary output of the stimulus
identification and organization task.
Sketch Human User Interface
Because most developers and customer representatives are familiar with
human user interfaces, stimulus identification is often aided by sketching
functionality screens. Functionality screens depict in rough form,
such as on the backs of used envelopes or obsolete business cards, a
proposed look and feel for the human user interface. The stimulus sets
thus recorded such as menus, lists, tabbed panes, data entry fields and
the like, are then transfered to the functionality tree. Later, the
functionality screens will serve as the basis for creation of the user
interface
mockup prototype.
Identify Requirements Commonalities
Often, one or more stimulus sets of a functionality tree, or even entire
branches of the tree, will be replicated at different locations within
the tree, or will be potentially useful in entirely different functionality
trees. The commonality of these stimulus sets marks them, and the code
that will implement them, as reusable requirements components. This
task ensures that such repeating stimulus sets are flagged for implementation
as reusable requirements components, and also inspects the reuse library
for reusable requirements components that may be applicable to creation
of this functionality tree.
Specify Responses
Once the program stimuli have been identified, the responses to the
stimuli are specified with the assistance of a knowledgeable customer
representative. Only the externally-detectable parts of the
responses are considered, consistent with the
definition of requirements.
The responses to all stimuli of one stimulus set are recorded in a
behavior table.
A behavior table contains one row for each stimulus
of the stimulus set, and one column for each component of the external
response -- "normal," "exception," and "new stimulus set activation"
responses. A final column records response performance, accuracy, and
precision (PAP) requirements. Table cells contain the actual response
specifications in Program Design Language
(PDL) format.
PDL consists of structured natural language readable by customer
personnel, and structured logic syntax which is unambiguous
for programmers. The Specify Requirements task produces one behavior
table for each stimulus set of the functionality tree.
Prioritize Requirements
If desired by the customer, the requirements
(stimulus
sets and associated
behavior tables) may be prioritized into
release groups
based on their importance or immediacy of need.
The remaining tasks of the Freedom process, from
Object Design through
Evolution, are then performed repetitively
for each release group, starting with the highest priority.
Requirements prioritization allows Freedom to be easily
adapted to incremental and frequent release management methodologies.
The chart semantics of the
Freedom process permits finer-grained adaptation to spiral, prototyping,
or other risk management methodologies that the customer may wish to
utilize.
Develop User Interface Prototype
While the participation of a knowledgeable customer representative
is essential to performing all Requirements tasks, feedback from the
larger customer organization is also necessary. A
user interface mockup is developed to obtain such feedback.
The mockup consists of production quality code implementing the stimulus
detection mechanisms and look and feel for the human user
stimulus sets of one or more
release groups,
but no response behavior except for
new stimulus set responses.
Develop External System Interface Protocols
External system interfaces consist of the protocols used to communicate
with external software or hardware systems via networks, files, data
bases or other programmatic mechanisms. This task determines the low
level details of these communication protocols, either by selecting
predefined standard protocols or by developing the syntax and semantics
of new custom protocols. For protocols that require custom code development,
the
functionality tree and
behavior tables
are updated to reflect the stimuli and responses of the (usually
custom) protocols. As with other tasks, the
quality requirements
guide selection among technical alternatives when choosing or
defining protocols.
Develop Environment Interface Protocols
Environment interfaces consist of the protocols used to communicate
with sensors, actuators, clocks, and other devices that interact
with the physical environment. This task determines the low
level details of these device communication protocols, either by selecting
predefined standard protocols or by developing the syntax and semantics
of new custom protocols. For protocols that require custom code development,
the
functionality tree and
behavior tables
are updated to reflect the stimuli and responses of the (usually
custom) protocols. As with other tasks, the
quality requirements
guide selection among technical alternatives when choosing or
defining protocols.
Get Customer Feedback
The
user interface mockup
is released to the customer organization,
and the users who will evaluate it are instructed in its purpose
and use. The primary purpose of the customer organization
evaluation is to verify that all necessary functionality
(stimuli) are present. Secondarily, usability concerns
of the customer organization users are also identified.
At the same time, a
heuristic evaluation or other form of
usability inspection (see
how to) may be carried out by the
developer test team or a
specialized usability contractor
hired by the
customer. The primary purpose of the heuristic evaluation or other
usability inspection is to improve the usability of the human user interface.
Secondarily, additional functionality (stimuli) needed to
improve usability also may be identified.
The feedback from the users and heuristic evaluation are collected
and evaluated with the assistance of customer management or the
customer's representative. The results of the evaluations are
used to modify or correct the
functionality tree,
functionality screens,
behavior tables,
and the user interface mockup itself.
This task also includes customer organization review of standard
external system and environment protocol selection and/or
custom protocol details.
Again, the feedback is evaluated with the assistance of customer
management or their representative, and the results used to modify or
correct the functionality tree, behavior tables, and protocol details.
home
about
downloads
gallery
goal
plan
products
e-commerce
future
science & engin
you & me
Copyright (C) 2000-2003 LDJ Trust
