SE 616 – Introduction to Software Engineering

Lecture 3

System Engineering (Chapter 6)

Definition of System:
    Webster's Dictionary :
        1.  a set or arrangement of things so related as to form a unity or organic whole.
        2.  a set of facts, principles, rules, etc., classified and arranged in an orderly form so as to show a    logical plan linking the various parts.
        3.  a method or plan of classification or arrangement.
        4. an established way of doing something; method; procedure.

Definition of Computer-based System:
    A set or arrangement of elements that are organized to accomplish some predefined goal by processing information.

Components of a Computer-based System:

System Engineer:
Defines the elements for a specific computer-based system in the context of the overall hierarchy of systems (macro elements).

System Engineering Hierarchy:
Description: ch10fg1

System Modeling

System engineering is a modeling process. It

System Modeling Restraints

System Simulation

Business Process Engineering (BPE)

Description: ch10fg2

Business Process Engineering Modeling

Hierarchical Activity Structure - information strategy planning (ISP)

 Description: ch10fg3

Information Strategy Planning

Management issues

Technical issues


Defining Objectives and Goals

§  decrease reject rate by 20% in first 6 months


Steps in Business Process Engineering (BPE)

1. Business Area Analysis (BAA)

2. Business System Design (BSD)

3. Application Engineering


4. Construction and Integration


Product Engineering


Process: Requirements Engineering


 Description: ch10fg4

Product Architecture Template

Description: newfig1

Architecture Flow Diagram

Description: newfig2


System Modeling with UML

Deployment diagrams

Description: newfig3


Activity diagrams

Description: newfig4


Class diagrams

Description: newfig5


Requirements Engineering (Chapter 7)


·  Ensure that a system that properly meets the customer's needs and satisfies the customer's expectations has been specified


Inception—ask a set of questions that establish …

o   the people who want a solution

Elicitation—elicit requirements from all stakeholders

Elaboration—create an analysis model that identifies data, function and behavioral requirements

Negotiation—agree on a deliverable system that is realistic for developers and customers

Specification—can be any one (or more) of the following:

Validation—a review mechanism that looks for

Requirements management




Identify stakeholders

Recognize multiple points of view

Work toward collaboration

The first questions


Requirements Elicitation


·         A collection of user scenarios that describe the thread of usage of a system

·         Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way

·         Each scenario answers the following questions:

o   Who is the primary actor, the secondary actor (s)?

o   What are the actor’s goals?

o   What preconditions should exist before the story begins?

o   What main tasks or functions are performed by the actor?

o   What extensions might be considered as the story is described?

o   What variations in the actor’s interaction are possible?

o   What system information will the actor acquire, produce, or change?

o   Will the actor have to inform the system about changes in the external environment?

o   What information does the actor desire from the system?

o   Does the actor wish to be informed about unexpected changes?


Use-Case Diagram

Description: newfig7


Building the Analysis Model

Elements of the analysis model

·         Scenario-based elements

o   Functional—processing narratives for software functions

o   Use-case—descriptions of the interaction between an “actor” and the system

·         Class-based elements

o   Implied by scenarios

·         Behavioral elements

o   State diagram

·         Flow-oriented elements

o   Data flow diagram


Class Diagram

Description: newfig8

State Diagram

Description: newfig9

Analysis Patterns

Pattern name:  A descriptor that captures the essence of the pattern.

Intent: Describes what the pattern accomplishes or represents

Motivation:  A scenario that illustrates how the pattern can be used to address the problem.

Forces and context:  A description of external issues (forces) that can affect how the pattern is used and also the external issues that will be resolved when the pattern is applied.

Solution:  A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues.

Consequences:  Addresses what happens when the pattern is applied and what trade-offs exist during its application.

Design:  Discusses how the analysis pattern can be achieved through the use of known design patterns.

Known uses:  Examples of uses within actual systems.

Related patterns: 

One or more analysis patterns that are related to the named pattern because


Requirements Analysis and Negotiation

Do some requirements provide a level of technical detail that is inappropriate at this stage?

Is a source (generally, a specific individual) noted for each requirement?

Requirements Specification

System Modeling

Requirements Validation

Requirements Management

e.g. <requirement type><requirement #>


<requirement type> takes on values such as
F = functional requirement
D = data requirement
B = behavioral requirement
I = interface requirement
P = output requirement

Hence, a requirement identified as F09 indicates a functional requirement assigned requirement number 9.

Description: ch10fg5a