Robert Morris College https://members.tripod.com/~ci620

CI-620 System Analysis and Design

Your Course Project

 Instructor: Ed Quigley 724.774.2088
Your project provides an opportunity to:

Your project involves applying the SA-D techniques from the course to an information system (IS), either existing or proposed. When an IS is developed by a single individual, the rigorous approach to SA-D may not always be followed. When a team of technical experts (programmers, trainers, writers, marketers) develop an IS, there must be a single unifying plan that they all follow.

The plan does not have to contain n-th degree details for each professional, and in fact the plan should leave such details to people with expertise. The result of the SA-D process is a overall blueprint that technical teams can follow when building their part of the info system.

You don't have to write any code. You do have to define the entities involved, the data flows, and design a system that others will build. You are conducting the symphony, not playing every instrument.

It is also important to communicate your work effectively. We are in the realm of technical change, which is painful and resisted. Too often, worthy technical proposals are lost to political and human reactions that were, in hindsight, predictable and actionable.

Your Requirements Document is the final result of your work in this course. It is equivalent to the report you would present to a panel of corporate V-P's.

Outline of a Requirements Document

Table of Contents

The following are the sections that you should probably have in your requirements document. There are no requirements for the structure of such documents, but following a standard outline, possibly adding sections, will make it easier to be sure that all necessary information is present, and it will make it easier to evaluate the document. If your organizations has a standard format, stick with it, but review this outline for beneficial suggestions.

The #'s next to section titles should be replaced by numbers (e.g., 2.3 ...). You should not leave out any sections, but explain why a section is not applicable, instead.

#. Introduction

#.# Purpose of this Document

Provide an abstract for the document.

#.# Intended Audience

Discuss the intended audience(s) of this document (users, analysts, designers, ...), and what parts each audience should pay close attention to. Make sure that you present a document that would answer all the questions a customer would have, and be useful to a system designer.

#.# Suggestions for Using this Document

Discuss what each audience should expect to get out of the document, and how they should get it.

#.# Prerequisite Knowledge for Using this Document

Discuss what a reader needs to know, possibly broken down by sections (e.g., to understand this section, you must know ...). Alternatively, this section may be one of the first subsections or paragraphs of subsequent sections.

#. Project Summary

Provide information about the customer and team working on the project.
Project Name
Project Manager
Responsible User
Responsible Analyst
Project Purpose and Scope
Project Start and Completion Dates
Completion Date for System Requirements Specification
Project Budget Summary

#. System Summary

#.# Introduction

#.# System Purpose and Scope

Write a summary that answers questions about who, what, where, why, ... Define the scope by indicating what the system will be responsible for and what the system will not be responsible for (drawn from responsibilities that might conceivably be within the scope of the system).

#.# Improvements/Advantages from Proposed System

New Capabilities
Upgraded Existing Capabilities
Elimination of Existing Deficiencies
Improved Performance
Elimination or Reduction of Capabilities No Longer Needed
Increases in Revenue
Reduction in Costs
Competitive Advantages

#.# Impacts from Proposed System

Equipment Impacts
What new equipment, upgrades, or reconfiguration will be needed?
Software Impacts
What new software or upgrades will be needed?
Organizational Impacts
What new people will be (no longer) needed?
Operational Impacts
What new procedures will need to be in place?

#. System Environmental Model

The Environmental Model describes how the system interacts with the external world.

#.# Statement of Purpose

#.# The Event List

This section includes a list of the external events to which the system must respond. The events are phrased in terms of the user's point of view. The preliminary environmental model will contain a process for each event (with some exceptions) with names phrased in terms of the system's response.

#.# The Context Diagram

The context diagram shows the external entities that provide/use in/out flows of information to the system. The interaction of each external entity with the system should be described. This will include some E/R-D's (usually Level0) that depict the interaction with the external world.

#. System Behavioral Model

The behavioral model shows how the system works internally.

#.# Level 0 Dataflow Diagrams

Level-0 DFD depict the preliminary behavioral model, combining meaningful aggregates and creating super-processes for them, or by finding overly complex processes (e.g., too many inputs/outputs) and breaking them into more manageable sub-processes.

#.# Data Dictionary

The data dictionary defines all the data elements and relations in the system. The data dictionary should be alphabetized for easy reference.

Major system stores should also be described with well-organized text in the entity-relationship diagrams. Key elements of objects should be clearly identified in the data dictionary.

#.# Process Specifications

Process specifications describe in detail how lowest-level processes will produce their outputs from their inputs. Each process specification should include:

Like program code,each process specification should include comments to make the specifications more clear.

#.# Entity-Relationship Diagrams / Data Structure Diagrams

Entity-relationship diagrams describe the objects and important relations among objects in the system. Data structure diagrams may be used in conjunction with the data dictionary if a diagrammatic form better conveys meaning.

Each major store in the dataflow diagrams should be described with well-organized text.

#. User Implementation Model

#.# Automation Boundary

#.# User Interface

The user interface is probably best described by (snapshots of) a prototype.

#.# Operational Constraints

#.# System Performance Requirements

#. Appendices

The following appendices are commonly seen in systems requirements documents, but some may not be applicable to a specific system.

#.# Summary of Assumptions

#.# Project Cost Estimates and Schedule

#.# Detailed Schedule and Budget for Design

#.# Detailed Schedule and Budget for Planning Acceptance Tests

#.# Cost/Benefit Comparisons of Alternatives

#.# How to Read the System Model

A key to the notation used in diagrams will make the document readable by more people.

Format Requirements

Title Page with:
Executive Summary. Written after the main body, presenting a rhetorically compelling summary.
Table of Contents with:
Main Body of Report:
General Considerations:

Implications Checklist

Have you considered:
1.15.98 Robert Morris College