1

System EngineeringSystem Engineering

based onbased on Chapter 6 - Chapter 6 - Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s

Approach, 6/eApproach, 6/e

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

2

Waterfall model 1 Waterfall model 1 [aka Royce1970][aka Royce1970]

Systems Engineering

Software Req. Analysis

Project Planning

Design

Implementation

Testing/Verification

Release

Operation/Maintenance

3

System EngineeringSystem Engineering

Elements of a computer-based Elements of a computer-based systemsystem SoftwareSoftware HardwareHardware PeoplePeople DatabaseDatabase DocumentationDocumentation ProceduresProcedures

SystemsSystems A hierarchy of macro-elementsA hierarchy of macro-elements

4

Business Process Business Process (Re-)Engineering(Re-)Engineering to identify how to identify how information systemsinformation systems can best meet can best meet

the the strategic goalsstrategic goals of an of an enterpriseenterprise, , using an integrated set of using an integrated set of procedures, methods, and tools, given a set of business rules and constraints.procedures, methods, and tools, given a set of business rules and constraints.

focuses first on the focuses first on the enterpriseenterprise and then on the and then on the businessbusiness area area

creates creates enterpriseenterprise models, models, datadata models and models and processprocess modelsmodels

(processes/services and interrelationships of processes and data)(processes/services and interrelationships of processes and data)

creates a framework for better information creates a framework for better information management, distribution, and controlmanagement, distribution, and control

5

System ArchitecturesSystem Architectures

Three different architectures must be analyzed and designed within Three different architectures must be analyzed and designed within the context of business objectives and goals:the context of business objectives and goals:

data architecturedata architecture provides a framework for the information needs of a provides a framework for the information needs of a business or business function (e.g., incident location, patient status, business or business function (e.g., incident location, patient status, ambulance location, drivers’ lunch hours and break, hospital locations, ambulance location, drivers’ lunch hours and break, hospital locations, etc.)etc.)

application architectureapplication architecture encompasses those elements of a system that encompasses those elements of a system that transform objects within the data architecture for some business purposetransform objects within the data architecture for some business purpose(e.g., determine ambulance availability, determine hospital availability, (e.g., determine ambulance availability, determine hospital availability, etc.)etc.)

technology infrastructuretechnology infrastructure provides the foundation for the data and provides the foundation for the data and application architectures (e.g., communication lines, computer platforms, application architectures (e.g., communication lines, computer platforms, etc.)etc.)

6

System Modeling with UMLSystem Modeling with UML

Deployment diagramsDeployment diagrams Each 3-D box depicts a hardware element that is part of Each 3-D box depicts a hardware element that is part of

the physical architecture of the systemthe physical architecture of the system Activity diagramsActivity diagrams

Represent procedural aspects of a system elementRepresent procedural aspects of a system element Class diagramsClass diagrams

Represent system level elements in terms of the data that Represent system level elements in terms of the data that describe the element and the operations that manipulate describe the element and the operations that manipulate the datathe data

7

Skip – Self ReadingSkip – Self ReadingPossibly One Lecture on UMLPossibly One Lecture on UML

8

Conveyor Line Sorting System Conveyor Line Sorting System (CLSS)(CLSS)

CLSS must be developed such that boxes moving along a conveyor CLSS must be developed such that boxes moving along a conveyor line will be identified and sorted into one of six bins at the end of line will be identified and sorted into one of six bins at the end of the line. The boxes will pass by a sorting station where they will be the line. The boxes will pass by a sorting station where they will be identified. Based on an identification number printed on the side of identified. Based on an identification number printed on the side of the box and a bar code, the boxes will be shunted into the the box and a bar code, the boxes will be shunted into the appropriate bins. Boxes pass in random order and are evenly appropriate bins. Boxes pass in random order and are evenly spaced. The line is moving slowly.spaced. The line is moving slowly.

A desk-top computer located at the sorting station executes all CLSS A desk-top computer located at the sorting station executes all CLSS software, interacts with the bar-code reader to read part numbers software, interacts with the bar-code reader to read part numbers on each box, interacts with the conveyor line monitoring equipment on each box, interacts with the conveyor line monitoring equipment to acquire conveyor line speed, stores all part numbers sorted, to acquire conveyor line speed, stores all part numbers sorted, interacts with a sorting station operator to produce a variety of interacts with a sorting station operator to produce a variety of reports and diagnostics, sends control signals to the shunting reports and diagnostics, sends control signals to the shunting hardware to sort the boxes, and communicates with a central hardware to sort the boxes, and communicates with a central factory automation system.factory automation system.

9

Deployment DiagramDeployment Diagram

CLSS processor

Sorting subsystem

Sensor dataacquisition subsystem

Operator display

shunt controller

Conveyor Pulse tach

Bar code reader Shunt actuator

10

Activity DiagramActivity Diagram

get conveyor speed

send shunt

control data

get shunt status read bar code

start conveyor line

determine bin location

valid bar code

set for reject bin

conveyor in motion

read bar code

get conveyor status

produce report entry

conveyor stopped

invalid bar code

11

Class DiagramClass Diagram

Box

barcode forwardSpeed conveyorLocation height width depth weight contents

readBarcode() updateSpeed() readSpeed() updateLocation() readLocation() getDimensions() getWeight() checkContents()

class name

attributes note use of capital letter for multi-word attribute names

operations (parentheses at endof name indicate the list of attributes that theoperation requires)

12

Requirements EngineeringRequirements Engineering

based on based on Chapter 7 - Chapter 7 - Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s

Approach, 6/eApproach, 6/e copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

13

Requirements Engineering Process:Requirements Engineering Process:A Basic Framework A Basic Framework [Loucopolos][Loucopolos]

Many variations and extensionsMany variations and extensions

3 fundamental activities: 3 fundamental activities: understand, (formally) describe, attain an agreement on, the understand, (formally) describe, attain an agreement on, the problemproblem

User

ProblemDomain

Elicitation Specification Validation

Elicitation: determine what’s really needed, why needed, whom to talk toElicitation: determine what’s really needed, why needed, whom to talk to Specification: produce a (formal) RS model: translate "vague" into "concrete", etc. make Specification: produce a (formal) RS model: translate "vague" into "concrete", etc. make

various decisions on what & howvarious decisions on what & how Validation: assure that the RS model satisfies the users’ needsValidation: assure that the RS model satisfies the users’ needs

Domain knowledge Domain knowledge

User reqsUser feedback

Req. models

Val. result

knowledge

For more knowledge

(domain experts, laws, standards, policies, documents, etc.)

14

Requirements EngineeringRequirements Engineering Elicitation - InceptionElicitation - Inception—ask a set of questions that establish …—ask a set of questions that establish …

(basic) understanding of the problem(basic) understanding of the problem the people who want a solutionthe people who want a solution the nature of the solution that is desired, and the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration the effectiveness of preliminary communication and collaboration

between the customer and the developerbetween the customer and the developer

Specification Specification — can be any one (or more) of the following:— can be any one (or more) of the following: A written documentA written document A set of models - A formal mathematical?A set of models - A formal mathematical? A collection of user scenarios (use-cases)A collection of user scenarios (use-cases) A prototypeA prototype

Validation Validation — a review mechanism that looks for— a review mechanism that looks for errors in content or interpretationerrors in content or interpretation areas where clarification may be requiredareas where clarification may be required missing informationmissing information inconsistencies (a major problem when large products or systems are inconsistencies (a major problem when large products or systems are

engineered)engineered) conflicting or unrealistic (unachievable) requirements. conflicting or unrealistic (unachievable) requirements.

15

Eliciting Requirements - Eliciting Requirements - InceptionInception

Identify (key) Identify (key) stakeholdersstakeholders These are the people who will be involved in the negotiationThese are the people who will be involved in the negotiation ““who else do you think I should talk to?”who else do you think I should talk to?”

Recognize multiple points of Recognize multiple points of viewview Work toward Work toward collaborationcollaboration

The first The first questionsquestions Who is behind the request for this work?Who is behind the request for this work? Who will use the solution?Who will use the solution? What will be the (economic) benefit of a successful solutionWhat will be the (economic) benefit of a successful solution Is there another source for the solution that you need?Is there another source for the solution that you need?

16

Eliciting RequirementsEliciting Requirements meetingsmeetings are conducted and attended by both software engineers and are conducted and attended by both software engineers and

customerscustomers rules for preparation and participation are establishedrules for preparation and participation are established an an agendaagenda is suggested is suggested a "a "facilitatorfacilitator" (can be a customer, a developer, or an outsider) controls the " (can be a customer, a developer, or an outsider) controls the

meetingmeeting a "a "definition mechanismdefinition mechanism" (can be work sheets, flip charts, or wall stickers or " (can be work sheets, flip charts, or wall stickers or

an electronic bulletin board, chat room or virtual forum) is usedan electronic bulletin board, chat room or virtual forum) is used

the goal is the goal is to identify the problemto identify the problem propose elements of the solutionpropose elements of the solution negotiate different approaches, andnegotiate different approaches, and specify a preliminary set of solution requirementsspecify a preliminary set of solution requirements

17

Elicitation Work ProductsElicitation Work Products a statement of a statement of need, scopeneed, scope, and , and feasibilityfeasibility.. a list of customers, users, and other a list of customers, users, and other stakeholdersstakeholders who who

participated in requirements elicitation participated in requirements elicitation a description of the system’s technical a description of the system’s technical environment (cf. environment (cf.

enterprise model in system engineering)enterprise model in system engineering).. a list of a list of requirementsrequirements (preferably organized by (preferably organized by

function) and the function) and the domain constraintsdomain constraints that apply to that apply to each.each.

a set of a set of usage scenariosusage scenarios that provide insight into the that provide insight into the use of the system or product under different operating use of the system or product under different operating conditions.conditions.

any any prototypesprototypes developed to better define developed to better define requirementsrequirements.

18

Building the Analysis ModelBuilding the Analysis Model

Elements of the analysis modelElements of the analysis model Scenario-based elementsScenario-based elements

Functional—processing narratives for software Functional—processing narratives for software functionsfunctions

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

Class-based elementsClass-based elements Implied by scenariosImplied by scenarios

Behavioral elementsBehavioral elements State diagramState diagram

Flow-oriented elementsFlow-oriented elements Data flow diagramData flow diagram

19

Skip – Self ReadingSkip – Self ReadingPossibly One Lecture on UMLPossibly One Lecture on UML

20

Use-CasesUse-Cases A collection of A collection of user scenariosuser scenarios that describe the thread of usage of a that describe the thread of usage of a

systemsystem Each scenario is described from the point-of-view of an “Each scenario is described from the point-of-view of an “actoractor”—a ”—a

person or device that interacts with the software in some wayperson or device that interacts with the software in some way

Each scenario answers the following questions:Each scenario answers the following questions: Who is the primary actor, the secondary actor (s)?Who is the primary actor, the secondary actor (s)? What are the actor’s goals?What are the actor’s goals? What preconditions should exist before the story begins?What preconditions should exist before the story begins? What main tasks or What main tasks or functions functions are performed by the actor?are performed by the actor? What extensions might be considered as the story is described?What extensions might be considered as the story is described? What variations in the actor’s interaction are possible?What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change?What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external Will the actor have to inform the system about changes in the external

environment?environment? What information does the actor desire from the system?What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?Does the actor wish to be informed about unexpected changes?

21

Use-Case DiagramUse-Case Diagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

22

Class DiagramClass Diagram

Sensor

name/id type location area characteristics

identify() enable() disable() reconfigure()

From the From the SafeHomeSafeHome system … system …

23

State DiagramState Diagram

Figure 7.6 Preliminary UML state diagram for a photocopier

Initialization

system status=“not ready” display msg = “please wait” display status = blinking

entry/ switch machine on do: run diagnostics do: initiate all subsystems

turn copier “on“

subsystems ready system status=“Ready”

display msg = “enter cmd” display status = steady

entry/ subsystems ready do: poll user input panel do: read user input do: interpret user input

Readingcommands

system status=“Copying” display msg= “copy count =” display message=#copies display status= steady

entry/ start copies do: manage copying do: monitor paper tray do: monitor paper flow

Making copies

start copies

system status=“Jammed” display msg= “paper jam” display message=location display status= blinking

entry/ paper jammed do: determine location do: provide corrective msg. do: interrupt making copies

problem diagnosis

paper jammed

system status=“load paper” display msg= “load paper” display status= blinking

entry/ paper empty do: lower paper tray do: monitor fill switch do: raise paper tray

load paper

paper tray empty

not jammed

paper full

turn copier “off”

not jammed

copies complete

24

Validating RequirementsValidating Requirements Is each requirement Is each requirement consistentconsistent with the overall objective for the with the overall objective for the

system/product?system/product? Have Have allall requirements been specified at the requirements been specified at the proper levelproper level of abstraction? of abstraction?

That is, do some requirements provide a level of technical detail that is That is, do some requirements provide a level of technical detail that is inappropriate at this stage?inappropriate at this stage?

Is the requirement Is the requirement really necessaryreally necessary or does it represent an add-on or does it represent an add-on feature that may not be essential to the objective of the system?feature that may not be essential to the objective of the system?

Is each requirement bounded and Is each requirement bounded and unambiguousunambiguous?? Does each requirement have attribution? That is, is a Does each requirement have attribution? That is, is a sourcesource (generally, a (generally, a

specific individual) noted for each requirement? specific individual) noted for each requirement? Do any requirements Do any requirements conflictconflict with other requirements? with other requirements? Is each requirement Is each requirement achievableachievable in the technical environment that in the technical environment that

will house the system or product?will house the system or product? Is each requirement Is each requirement testabletestable, once implemented?, once implemented? Does the requirements model Does the requirements model properly reflectproperly reflect the information, the information,

function and behavior of the system to be built.function and behavior of the system to be built.