CS615 – Software Engineering I

Lecture 4

Analysis Modeling (Chapter 8)

Requirements Analysis



Software Requirements Analysis Phases

Software Requirements Elicitation

Process Initiation

Facilitated Action Specification Techniques (FAST)

Quality Function Deployment (QFD)

Analysis Principles

Operational principles:

Guiding principles:

Information Domain


Information Flow

How data and control change as each moves through a system




Software Requirements Views

Software Prototyping




Prototyping Methods and Tools

Specification Principles

Specification Representation

Specification Review


Analysis Model

Structured Analysis (DeMarco)

Analysis Model Objectives



Analysis Model Elements

Analysis Modeling: Where to Begin?

Data Modeling (ERD)





Cardinality and Modality (ERD)



Entity/Relationship Diagrams

A simple ERD and data object table (Note: In this ERD the relationship builds is indicated by a diamond)

Expanded ERD


ERD representation of data object type hierarchies


Associative data object - represents the associativity between objects


Creating Entity Relationship Diagrams


Scenario-Based Modeling


Use-Case Diagram


Activity Diagram

Supplements the use-case by providing a diagrammatic representation of procedural flow



Swimlane Diagrams

Allows the modeler to:


Flow-Oriented Modeling

Functional Modeling and Information Flow (DFD)

Data Flow Diagrams (DFDs)







The relationship between data and control models




Class-Based Modeling


Analysis Classes


Selecting Classes—Criteria


Class Diagram


CRC Modeling


CRC Cards


Class Types

controller classes can be designed to manage


Class Responsibilities

·        System intelligence should be distributed across classes to best address the needs of the problem

·        Each responsibility should be stated as generally as possible

·        Information and the behavior related to it should reside within the same class

·        Information about one thing should be localized with a single class, not distributed across multiple classes.

·        Responsibilities should be shared among related classes, when appropriate.


Class Colaborations


Composite Aggregate Class


Reviewing the CRC Model


Associations and Dependencies






Analysis Packages



Behavioral Modeling

·        The behavioral model indicates how software will respond to external events or stimuli.

·        Evaluate all use-cases to fully understand the sequence of interaction within the system.

·        Identify events that drive the interaction sequence and understand how these events relate to specific objects.

·        Create a sequence for each use-case.

·        Build a state diagram for the system.

·        Review the behavioral model to verify accuracy and consistency.


State Representations 



State Diagram for the ControlPanel Class



Sequence Diagram




Level 1 CFD for photocopier software


State transition diagram for photocopier software



Data Dictionary Contents

Data dictionary is an organized listing of all data elements that are pertinent to the system, with precise, rigorous definitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores and [even] intermediate calculations


Data Construct




is composed of





[ | ]




n repetitions of


( ) 

optional data


* ... * 

delimits comments

Notation enables representation of composite data in one of the three fundamental ways that it can be constructed:

  1. As a sequence of data items.
  2. As a selection from among a set of data items.
  3. As a repeated grouping of data items. Each data item entry that is represented as part of a sequence, selection, or repetition may itself be another composite data item that needs further refinement within the dictionary.



Design Engineering (Chapter 9)

Translating the analysis model into a software design


Design Specification Models

The Design Process

1.    A design should exhibit an architectural structure that it:

(1) has been created using recognizable design patterns
(2) is composed of components that exhibit good design characteristics
(3) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing.

2.    A design should be modular; that is, the software should be logically partitioned into elements that perform specific functions and subfunctions.

3.    A design should contain distinct representations of data, architecture, interfaces, and components (modules).

4.    A design should lead to data structures that are appropriate for the objects to be implemented and are drawn from recognizable data patterns.

5.    A design should lead to components that exhibit independent functional characteristics.

6.    A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment.

7.    A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

Design Principles

Software Design Concepts

Modularity and software cost

Typical Hierarchical Control Structure


Effective Modular Design

Functional Independence


coincidental cohesion 

module that performs tasks that are related logically


temporal cohesion 

module contains tasks that are related by the fact that all must be executed with the same spanof time


procedural cohesion 

processing elements of a module are related and must be executed in a specific order


communicational cohesion 

all processingelements concentrate on one area of a data structure



module that performs one distinctprocedural task. 


data coupling

simple data are passed- a one-to-one correspondence of items exists


stamp coupling

a portion of a datastructure (rather than simple arguments) is passed via a module interface


control coupling 

where a "control flag" is passed between modules


external coupling 

modules are tied toan environment external to software


common coupling

when a number of modulesreference a global data area


content coupling

when one modulemakes use of data or control information maintained within the boundaryof another module

Design Heuristics for effective Modularity

Program structure can be manipulated according to the following set of heuristics:

  1. Evaluate the "first iteration" of the program structure to reduce coupling and improve cohesion
  2. Attempt to minimize structures with high fan-out; strive for fan-in as depth increases
  3. Keep the scope of effect of a module within the scope of control of that module
  4. Evaluate module interfaces to reduce complexity and redundancy and improve consistency
  5. Define modules whose function is predictable, but avoid modules that are overly restrictive
  6. Strive for "controlled entry" modules by avoiding "pathological connections."


Design Documentation

Software Design Specification from: