Maintenance Requirements Analysis

"Everyone likes to focus on new development because it's exciting, yet more time and effort is spent on maintaining it after it is in production.  Finally, someone has helped our company save major dollars by showing us a better way to do our maintenance activities. Bravo!"

Are you facing these maintenance issues?

  • You may have a methodology for new system development, but what method are you using for your maintenance & enhancements?

  • Industry studies show that some organizations are spending upwards of 75% of their budget maintaining existing systems – would you like to reduce that percentage?

  • You spend more time trying to find the problem than is actually required to make the change?


How do you know that your maintenance efforts have:

  • Covered all the bases and identified the change(s) correctly?

  • Not introduced other errors ("ripple effect") while executing the change(s)?

  • Documented each separate Change Request, enhancement by enhancement, to (re)build your system documentation?

  • Produced "non-redundant" documentation & spec's?

  • Documentation that your designers can trust? 


Practical two-day workshop:

This course is a mix of presentation, demonstration and exercises. The same case study is carried throughout the session, from the initial change request being received from the client to the production of the "change package".

We'll show you -- and you'll have an opportunity to practice the techniques used in a practical, straight-forward, step-by-step method to:

  • Determine the size of the change(s)

  • Organize the change(s) 

  • Determine and document the change(s)

  • Validate the change(s) being made

  • Producing a change package that is understandable and useable

Prerequisite: Specifying Client Requirements (SCR) & Defining Software Requirements


What's our difference?

It's how to do it – an identified, repeatable and manageable process that produces results.

It will work directly with your current methodology tools and key practices.

We teach it and we do it – seminar leaders are consultants with real project experience.

Brings together proven, modern analysis and design principles.


Best Business Requirements Practices:

Uses familiar, proven methods – a unique approach –compiled from the experts in systems analysis & design, and supports industry standards from CMM & IEEE.

Defines a clear and easy process – finally there is a set of simple models, tools and techniques compiled in an easy to use process – that takes you easily through receiving a request for change to "spec-ing out" the change into a highly cohesive "change package"

Demonstrates a proven, applied approach – that works on today's projects. 

Produces a high quality, industry standard change spec – a unique balance between rigorousness and simplicity, within a framework defined by CMM and IEEE

Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Maintainable, Traceable


"This was a very organized way to go from a nebulous user change request to a complete change package, quickly and easily"


MRA COURSE CONTENT

Confirming & Validating The Business Requirements

Functional Validation Checklist §  Data Validation Checklist § Data usage 
matrix § Actor Descriptions § Scenarios § Role Matrix § Work 
Session Matrix § Work Session Use Case Model § Sources § Leveling 
the playing field 

Organizing & Defining the Data 

Data Specifications § Characteristics § Behavior rules § Presentation 
roles § Data normalization guidelines § Data Item Matrix § Data 
Presentation Matrix § New data requirements (objects, data items)

Describing the Workflow

Identify actors and role matrix § Develop work sessions § Validate with 
scenarios § Illustrate with use cases § Develop precise component 
specifications supported by: External interface specifications, Report specs, 
User interface specs § Questions requiring clarification

Defining the Modification Specification

Activity Dependency Matrix § Process Flow Diagram § Activity 
Dependency Model § Scenarios § Components § Component 
Reusability Matrix § Scope of Automation Matrix § Requirements 
Tracking Matrix § Other Matrices such as: Release-Version Planning Release Matrix, Gap Analysis Matrix, Weighting - Ranking Matrix § New functional requirements (activities, operations)

Documenting the Modifications

Presentation § Format §  Standards § What needs to be included § Tips

 


CONTACT US

1-800-209-3616

Copyright © 1999 The Information Architecture Group
and The Information Architecture Group, Inc. All Rights Reserved