CIS 375 SOFTWARE ENGINEERING

UNIVERSITY OF MICHIGAN-DEARBORN

DR. BRUCE MAXIM, INSTRUCTOR

Date: 10/6/97

Week 5

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.

1. Architecture context diagram.

1. Architecture flow diagram:
   • Much greater detail.
   • specific inputs/outputs/parameters are needed.
2. Architecture diagram specification:
   • System module narrative for each subsystem (purpose, processing interface).
   • Architectural dictionary.
   • Architectural interconnect diagram (directed graph, the nodes are AFD's).

SYSTEM SPECIFICATIONS:

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

REQUIREMENTS ANALYSIS:

• Requirement- features of system or system function used to fulfill system purpose.
• Focus on customer's needs and problem; not solutions:
  1. Requirements definition document (written for customer).
  2. Requirements specification document (written for programmer; technical).

TYPES OF REQUIREMENTS:

1. Functional requirements:
   • Input/output processing.
   • Error handling.
2. 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?
   • Externally - all desired properties are present.
   • Internally - no undefined references.
4. Each requirement describes something actually needed by the customer.
5. Requirements are verifiable (testable)?
6. 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.

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:

INFORMATION DEPLOYMENT:

TASK DEPLOYMENT:

VALUE ANALYSIS:

MAKES USE OF:

• Customer interviews.
• Observations.
• Surveys.
• Historical data.

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).

Date: 10/8/97

Week 5

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.
8. Appropriate for application.

ERPP:

RISKS USING ERPP:

1. Premature delivery.
2. Premature design selection.
3. Features in prototype can get lost in final product.
4. There is a tendency to choose efficiency over modifiability
   • Focus on what will take least amount of program time rather than maintainability.
   • Rapid prototyping - don't write code until ready, with spiral model may want to write code, but code may be thrown out after risk assessment.

REQUIREMENTS ANALYSIS FOR ERPP:

DESIGN:

IMPLEMENTATION & TESTING:

1. Code.
2. Test.
3. Debug.
4. Goto 1 (repeat).

FINAL SPIN CYCLE:

REQUIREMENTS SPECIFICATION METHODS:

1. HIPO Chart:

(Hierarchy Input - Output Chart)

Strengths Weaknesses

- Shows function - No mechanism for

relationship. Non-functional requirements.

- No checking mechanism.

1. Hierarchical Data Structures:

How is it different from object hierarchy:

• Looks at data, not methods.
• No inputs/outputs.
• Only shows declaration of records, could work for database model, but not for implementation.

1. Data Flow Diagrams:

{square} = producer or consumer of information.

{circle} = software client capable of transforming information.

{arrow} = data item.

{thing} = database.

Key: this is data flow.

1. CFD:

Control flow diagram.

CSPEC - control specification.

1. General Data Model: (Focus on data)

Data object tables are determined.

Object = record.

Attribute = fields.

NORMALIZATION RULES:

1. Given instance of an object has one value for an attribute.
2. Attributes represent elementary items.
3. When more than one attribute is used to identify an object, make sure they describe the same "key".
4. All non-ID attributes represent the same characteristics of instance named by key.

E-R DIAGRAM:

(Entity relationship)

{squares} = data object.

{diamonds} = relationship between objects.

1. Decision Table:

1. Finite state machines:
   • Set of machine states.
   • S_o , start state.
   • F , final state.
   • Input symbols - .
   • Transition functions - : * .

1. Event table:

(Like decision table)

• Vertical axis that deals with system nodes or states.
• Horizontal axis - events (clicks on mouse).
• Table entries - action (displaying menu).

O = no action / no state change.

X = no action defined.

1. Petri Net:
   1. Sequential processes.

f(state A, event) -> state S.

f(state A, event1, event2, event3) -> state S.

f(state A, event1, event2, event3) -> (state S₁, state S₂).