Current loctn: about > methods > software > analysis

Analysis

"If you want to do a good job washing a table, you must first know whether it is to be used for surgery or for lunch." - W. E. Deming

Analysis stage focuses on development of a complete understanding of tasks to be supported by the system, from the user's perspective. The functions to be suported are detailed and organized in fashions that facilitate planning of software structures. The information used is gained from interactions with client staff who are invovled in actually performing the processes to be supported. Supporting information is sometimes derived from documents provided by the client.

Formal studies of software development have repeatedly documented that a focus on clear documentation of requirements is an effective method for reducing overall software development expenses and reducing violations of predicted project timelines. Error detection and correction is most cost-effective at requirement stage - many studies document 10 to 20 fold increases in error-correction expenses at later development stages.

To take advantage of this possible efficiency, we typically ask for a high level of client engagement in this stage. In effect, frequent client review and comment during this stage integrates informal inspections into requirements development. Inspections have been repeatedly demonstrated to be among the most cost-effective methods of ensuring software quality - especially when applied at this stage of a development project.   Additional advantages result from client staff's resulting familiarity with the new system, and with the decisions made during project development.

Products

• Business Rules Description - rules that will be applied to data regardless of what implementation approaches are selected (for example, what features define a delinquent payment, what is the standard duration of a membership, etc.) (business rules example)
• Candidate Use Case List - summary type list of tasks that the system should support. Frequently provdided in spreadsheet form together with scoring system designed to indicate tasks with highest potential impaact. (candidate use cases example)
• Code Conversion Maps - listing showing how field values in the legacy system are converted to values used in the destination system. Typically provided in spreadsheet form. This description is often used to indicate spelling corrections, merging of different legacy values to a single value in the destination system, elimination of obsolete codes, etc. (code conversion map example)
• Detailed data model - outlines the data required to meet client needs.  This model also outlines the important logical relationships between different data subjects. (detailed data model example)
• Function/Attribute Matrix - table indicating exactly which attributes from the data model diagram are used by each use case to be supported by the system. (Similar to "function/entity matrix", but with a higher level of detail displayed.)
• Function/Entity Matrix - table indicating which entities on the data model diagram are used by each use case to be supported by the system.
• Process Diagrams - a variety of flowchart style diagrams may be used to represent business processes that will be supported by the new system. If these processes are to be modified as part of the new development, additional diagrams may be developed to represent the proposed new process in a similar fashion ebase "add contact" logic flow example, ebase "add contact" script flow example)
• Revised Work Plan - outlines each major task in the project and the resources required to complete that task. This document often provides the basis of further discussions to ensure that project goals are appropriate to the available budget. Updated to reflect current state of project and current understanding of project. (work plan example)
• Use Case Descriptions - detail description of the interactions of users with the system during supported tasks. Each task supported by the new system is represented by a single "use case description". (use case desc example 1 use case desc example 2)
• Variable Domain Descriptions - A representation of values that will be allowed in important "coded" fields. (code set definition example)
• Variable Loading Map - outlines where data in the new system will be obtained from within the existing data management system. This includes an outline of any needed data transformations. This is sometimes documented in a custom FileMaker application we have created specifically for this purpose.

Work Process

A great deal of time is spent discussing processes, information needs, and current systems with users during this stage. If the client has system documentation or other prepared materials that provide important information, the analysis team will attempt to make the best use of these materials. However, it often happens that few written materials are avaialble for review. In fact, it often happens that the data contents of current systems have been completely undocumented - the development process for the new system is sometimes the first time a written description is developed. Information gathering therefore is typically a process of interacting with appropriately chosen client staff members, and documenting the information gained from this process.

Work on these products typically overlaps, but the majority of the work usually proceeds in this sequence:

1. User Requirements Interviews

   As information from interviews is accumulated, the following products are updated to include that information:

   • Candidate Use Case List
   • Business Rule Descripton
   • Detailed Data Model

2. Variable Domain Descriptions/Code Conversion Maps
3. Use Case Descriptions
4. Process Diagrams
5. Function/Entity Matrix
6. Function/Attribute Matrix
7. Variable Loading Map
8. Revised Work Plan

Last modified: 13:22:15 27-Feb-2018