Skip to main content

System Status: 

Development Guidelines: 2 - Analysis Phase

Learn about the second phase, Analysis, of a systems development methodology

2.0 Analysis Phase:

During the analysis phase, gather your department's business requirements and environmental considerations. At the end of the phase, decide whether you will build or buy your proposed system.

2.1 Capture and analyze your requirements and identify critical issues, including the following:

  • Business functions to be developed
  • All data required for these business functions
  • Business rules determining data behavior, constraints, limits, relationships, and life-cycle
  • Business function flow
  • Related business systems on and off campus
  • Interfaces with other external and internal business systems
  • Existing data that may have to be converted
  • Opportunities for re-engineering
  • Preliminary transition plan
  • Security requirments
  • Campus and departmental technical environment and standards (includes security, network, hardware, database, desktop tools, middleware, and application software delivery issues)
  • Technical architectures that maximize opportunities for appropriate sharing of information across the campus community
  • Critical success factors (up-time, business response time, etc.)
  • Architectural issues such as network and systems capacity planning
  • Campus policy affected
  • Contingency planning

2.2 Decide whether to build or buy a business system, based on the following factors:

  • Do surveys of the marketplace and indicate availability of products that would address the majority of your business problems.
  • Determine product compatibility with the campus technical environment and standards (includes security, network, database, desktop tools, middleware, and application software delivery issues).
  • Analyze the full life-cycle cost of a buy versus build decision, including customization cost.
  • Determine the availability of internal resources to build a system.
  • Identify the contract resources available to augment staff to build a system.
  • Analyze the time-frame involved in buying versus building a system.

2.3 Initiate operations planning. Start to address the following operational issues, and plan to refine this plan throughout the project:

  • Determine how the application will be deployed.
  • Determine how technical and functional upgrades will be accomplished.
  • Determine desktop and server hardware and need to upgrade or change end-user desktop computers.
  • Determine timing and strategy for backing up data.
  • Initiate disaster planning.
  • Determine resources to support ongoing operations addressing application and hardware maintenance.
  • Develop a communication plan.

2.4 Produce an analysis summary of high-level conclusions. The analysis summary may include an assessment of the following:

  • Acceptable approaches
  • Acceptable technologies and general architectures
  • Opportunities for re-engineering
  • Refinement of resource needs (people, money, environment)
  • Unacceptable approaches
  • Unacceptable technologies and general architectures
  • Risks

UC San Diego Guidelines

  1. Planning
  2. Analysis
  3. Prototyping
  4. Design
  5. Development
  6. Training
  7. Implementation