RISK MANAGEMENT 
Risk Aversion
Java   
  Given our lack of use with Java, guidance will be sought from various sources such as 
  Motorola or our team technical advisor.  This will only occur if we encounter a problem beyond 
  our scope.
Schedule
  The schedule will be followed as closely as possible but we anticipate problems.  These
  problems will be discussed with the project leader and the customer.  We will  explain the
  problems and a new revised schedule.
Independence, Generic, Hierarchy
  These programming concepts are major requirements for the project. Our lack of knowledge
  and experience with these concepts must be dealt with before coding begins.  Therefore, a
  design will be planned and given to Motorola for acceptance before programming starts.
Integration
  Integration should be minimized with top-down incremental design. 
Platform
  The platform is not anticipated to become a problem given the nature of Java.  However, in the
  event of one platform running while another will not, the group will meet with Motorola and
  discuss what platforms will be used.
Translator
  The translator is expected to convert any Java file in the old format to the newly constructed 
  format.  Coordination with Motorola and our team advisor is necessary for this part of the 
  project to be a success.
Missed Requirements
  Using the incremental process will allow for incorporation of newly identified requirement, or initiate newly
  requested requirements. 
Time constraints
  Have a long term schedule of the project to give team members advanced time to work it in their personal
  schedule.  Make other members aware of our personal schedule.
Team cohesion
  Strive to focus on how this is a group project.  Emphasize the individuals contributin to the project.  Resolve
  conflicts before they are to big.  If this fails then it will be resolved with Ken Collier.
Technology changes
  Maintain flexible design with well documented code for future maintenance.
 
Future Risks
  Future Risk areas are anticipated and can be identified through the periodic process of 
  current risk evaluation.  Those risk areas encountered but not initially recognized as one of 
  the outlined risk areas are then evaluated for severity and depth of risk and then methods for 
  minimizing the risk are then formulated.  This then leads to a modified risk plan with the new 
  area incorporated.


REQUIREMENTS COVERAGE
Capturing Primary Requirements

Acquire information through:
1. Teleconferencing 
2. Conference Meetings
3. Email
Write Requirements Document that will capture all the details and specifications of the project.
Requirements Document will be revised until both parties agree to the document.

Showing Derived Requirements
Derived requirements are those requirements that are implied by the explicitly stated 
  requirements, but may not have been originally stated.  These requirements will be molded
  into our current version of the Requirements Document after they are communicated and
  approved by  our client.  Changes will be made to the corresponding diagrams created with 
  Software through Pictures using OMT.


Tracking Requirements to Architecture
By using Software through Pictures with the Object Modeling Technique, we will create 
  diagrams to show all our objects and their properties.  Visually, we will be able to see if we will
  need to add or remove objects when necessary.  We also will be less likely to omit an object 
  (i.e. lose an object) due to this visual structure.

Tracking Requirements to Design
Much like tracking requirements to architecture, tracking requirements to design will be 
  based on Software through Pictures to assure accuracy in the development of our design. 
  The visual structure will allow us to see what exactly needs to be put into each object and 
  class.  

Tracking Requirements to Implementation Code
The Software through Pictures approach will allow us to see what attributes that our
  objects and classes will contain.  These pictures will aid in the implementation of our code 
  and minimize the amount of time we will spend on it.  This technique will disallow any 
  duplication in code.

Testing for Requirements Coverage
Use regression tests for all reusable classes in class library
Check-list for expected GUI components
The software will be tested for completeness from the requirements document 





Page 3



Document Index



Page 5