CIS 375 SOFTWARE ENGINEERING

University Of Michigan-Dearborn

Dr. Bruce Maxim, Instructor

System Analysis Objectives:

  1. Identify customer’s needs.
  2. Evaluate system for feasibility.
  3. Perform economic and technical analysis.
  4. Allocate functions to system elements.
  5. Establish schedule and constraints.
  6. Create system definitions.

Management Questions:

  1. How much effort put towards analysis?
  2. Who does the analysis?
  3. Why is it so difficult? (Bottom line - who pays for it?)

Feasibility Study:

  1. Economic feasibility. (cost/benefit analysis)
  2. Technical feasibility. (hw/sw/people, etc.)
  3. Legal feasibility.
  4. Alternatives.

Modeling System Architecture:

  1. Architecture template.

User Interface Processing

Input Processes

Process & Control Functions

Output Processes

Maintenance &

Self-Test

  1. Architecture context diagram.
  1. Architecture flow diagram:
  1. Architecture diagram specification:

System Specifications:

  1. Introduction.
  2. Functional data description.
  3. Subsystem description.
  4. System modeling and simulation results.
  5. Projects.
  6. Appendices.

Requirements Analysis:
    1. Requirements definition document (written for customer).
    2. Requirements specification document (written for programmer; technical).

Types Of Requirements:
    1. Functional requirements:
    1. Non-functional requirements:
    1. Physical environment (equipment locations, multiple sites, etc.).
    2. Interfaces (data medium etc.).
    3. User & human factors (who are the users, their skill level etc.).
    4. Functionality (how well is system functioning).
    5. Documentation.
    6. Data (qualitative stuff).
    7. Resources (finding, physical space).
    8. Security (backup, firewall).
    9. Quality assurance (max. down time, MTBF, etc.).

Validation Of Requirements (how to check to see what’s there):
    1. Correct?
    2. Consistent?
    3. Complete?
    1. Each requirement describes something actually needed by the customer.
    2. Requirements are verifiable (testable)?
    3. Requirements are traceable.

Requirements Definition Document:

  1. General purpose of document.
  2. System background and objectives.
  3. Description of approach.
  4. Detailed characteristics of proposed system (data & functionality).
  5. Description of operating environment.

(These should be technically correct documents, pretend customer’s not there)

F.A.S.T. - Facilitated Application Specification Technique (you & customer get together early to get everything "hammered" out. Focus on problem definition):
    1. Meeting between customers and developers at a neutral site (no home advantage).
    2. Rules for participation and preparation established ahead of time.
    3. Agenda suggested (brain storming).
    4. Facilitator appointed.
    5. Definition mechanism (sheets, flipcharts, wallboards, stickers, etc.).
    6. Goal - identify the problem, propose elements of solution, negotiate different approaches, specify preliminary set of requirements.

QFP - Quality Function Deployment (customer’s needs -> technical requirements):
    1. Normal requirements (minimal functional & performance).
    2. Expected requirements (important implicit requirements, i.e. ease of use).
    3. Exciting requirements (will become normal req. next time, highly prized & valued).

Function Deployment:

Determines value of required function.

Information Deployment:

Focuses on data objects and events produced or consumed by the system.

Task Deployment:

product behavior -> operating environment.

Value Analysis:

Makes Use Of:

to create a Customer Voice Table (extract expected requirements, derive exciting req.)

Analysis Principles:

  1. Information domain of problem must be presented & understood.
  2. Models depicting system information, functions, and behavior should be developed.
  3. Models and problems must be partitioned in a manner that uncovers detail in layers.
  4. Analysis proceeds from essential information toward implementation detail (must be traceable).

Specification Principles:

  1. Separate functionality from implementation.
  2. A processor - oriented specification language is needed.
  3. Specification must encompass the system containing the software component.
  4. Specification must encompass the environment.
  5. System specification = cognitive model.
  6. Specification must be operational (talk about how it works).
  7. Must be tolerant of incompleteness and easy to add to.
  8. Specification must be localized and loosely coupled (pieces of things are independent of each other).

Requirements Review:

  1. Goals & objectives review.
  2. Compare requirements to goals & objectives.
  3. Consider system operating environment.
  4. Assess and document all risks in system developmental operation.
  5. Discuss testing procedure.

Evaluating Specification Techniques:
    1. Requirements are understandable to naïve user.
    2. Requirements form basis for design and testing.
    3. Automated requirements checking?
    4. Requirements form external view of system.
    5. Technique aid in organizing and structuring requirements.
    6. Technique for prototyping.
    7. Automatic test case generation from requirements.

Appropriate for application.