CS615 – Software Engineering I

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:

System Modeling

System engineering is a modeling process. It

System Modeling Restraints

System Simulation

Business Process Engineering (BPE)

Business Process Engineering Modeling

Hierarchical Activity Structure - information strategy planning (ISP)


 

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

Goal:

Process: Requirements Engineering

Execution:


 
 

Product Architecture Template

Architecture Flow Diagram

 

System Modeling with UML

Deployment diagrams

 

Activity diagrams

 

Class diagrams

 

Requirements Engineering (Chapter 7)

Goal

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

Process:

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

 

 

Inception

Identify stakeholders

Recognize multiple points of view

Work toward collaboration

The first questions

 

Requirements Elicitation

Use-Cases

·        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

 

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

State Diagram

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 #>

where

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