Systems Engineering: A practitioner's perspective

It is a methodology that supports the containment of the life cycle cost of a system. In other words, systems engineering is a logical way of thinking. Systems engineering is the art and science of developing an operable system capable of meeting requirements within often opposed constraints.

1. 1
System EngineeringSystem Engineering
based onbased on
Chapter 6 - Chapter 6 - Software Engineering: A Practitioner’s Approach, 6/eSoftware Engineering: A Practitioner’s Approach, 6/e
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only
May 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. 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. 3
System EngineeringSystem Engineering

Elements of a computer-based systemElements of a computer-based system

SoftwareSoftware

HardwareHardware

PeoplePeople

DatabaseDatabase

DocumentationDocumentation

ProceduresProcedures

SystemsSystems

A hierarchy of macro-elementsA hierarchy of macro-elements

4. 4
Business Process (Re-)EngineeringBusiness Process (Re-)Engineering
to identify how to identify how information systemsinformation systems can best meet the can best meet the strategic strategic
goalsgoals of an of an enterpriseenterprise, , using an integrated set of procedures, methods, and using an integrated set of procedures, methods, and
tools, given a set of business rules and constraints.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 models models
(processes/services and interrelationships of processes and data)(processes/services and interrelationships of processes and data)
creates a framework for better information management, creates a framework for better information management,
distribution, and controldistribution, and control

5. 5
System ArchitecturesSystem Architectures

Three different architectures must be analyzed and designed within the Three different architectures must be analyzed and designed within the
context of business objectives and goals: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, etc.)ambulance location, drivers’ lunch hours and break, hospital locations, 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, etc.)(e.g., determine ambulance availability, determine hospital availability, etc.)

technology infrastructuretechnology infrastructure provides the foundation for the data and application provides the foundation for the data and application
architectures (e.g., communication lines, computer platforms, etc.)architectures (e.g., communication lines, computer platforms, etc.)

6. 6
System Modeling with UMLSystem Modeling with UML

Deployment diagramsDeployment diagrams

Each 3-D box depicts a hardware element that is part of the Each 3-D box depicts a hardware element that is part of the
physical architecture of the systemphysical 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 describe Represent system level elements in terms of the data that describe
the element and the operations that manipulate the datathe element and the operations that manipulate the data

7. 7
Skip – Self ReadingSkip – Self Reading
Possibly One Lecture on UMLPossibly One Lecture on UML

8. 8
Conveyor Line Sorting System (CLSS)Conveyor Line Sorting System (CLSS)
CLSS must be developed such that boxes moving along a conveyor line will 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 the line. The 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 identified. Based boxes will pass by a sorting station where they will be identified. Based
on an identification number printed on the side of the box and a bar on an identification number printed on the side of the box and a bar
code, the boxes will be shunted into the appropriate bins. Boxes pass in code, the boxes will be shunted into the appropriate bins. Boxes pass in
random order and are evenly spaced. The line is moving slowly.random order and are evenly 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 on software, interacts with the bar-code reader to read part numbers on
each box, interacts with the conveyor line monitoring equipment to each box, interacts with the conveyor line monitoring equipment to
acquire conveyor line speed, stores all part numbers sorted, interacts acquire conveyor line speed, stores all part numbers sorted, interacts
with a sorting station operator to produce a variety of reports and with a sorting station operator to produce a variety of reports and
diagnostics, sends control signals to the shunting hardware to sort the diagnostics, sends control signals to the shunting hardware to sort the
boxes, and communicates with a central factory automation system.boxes, and communicates with a central factory automation system.

9. 9
Deployment DiagramDeployment Diagram
CLSS processor
Sorting subsystem
Sensor data
acquisition subsystem
Operator display
shunt controller
Conveyor
Pulse tach
Bar code reader Shunt actuator

10. 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. 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 end
of name indicate the
list of attributes that the
operation requires)

12. 12
Requirements EngineeringRequirements Engineering
based on based on
Chapter 7 - Chapter 7 - Software Engineering: A Practitioner’s Approach, 6/eSoftware Engineering: A Practitioner’s Approach, 6/e
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only
May 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. 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 problemunderstand, (formally) describe, attain an agreement on, the problem
User
Problem
Domain
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 various decisions on what Specification: produce a (formal) RS model: translate "vague" into "concrete", etc. make various decisions on what
& how& 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 reqs
User feedback
Req. models
Val. result
knowledge
For more knowledge
(domain experts, laws, standards, policies, documents, etc.)

14. 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 between the effectiveness of preliminary communication and collaboration between
the customer and the developerthe 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 engineered)inconsistencies (a major problem when large products or systems are engineered)

conflicting or unrealistic (unachievable) requirements. conflicting or unrealistic (unachievable) requirements.

15. 15
Eliciting Requirements - InceptionEliciting Requirements - Inception

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. 16
Eliciting RequirementsEliciting Requirements

meetingsmeetings are conducted and attended by both software engineers and customers are conducted and attended by both software engineers and customers

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 meeting" (can be a customer, a developer, or an outsider) controls the meeting

a "a "definition mechanismdefinition mechanism" (can be work sheets, flip charts, or wall stickers or an " (can be work sheets, flip charts, or wall stickers or an
electronic bulletin board, chat room or virtual forum) is usedelectronic 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. 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 function) (preferably organized by function)
and the and the domain constraintsdomain constraints that apply to each. that apply to each.

a set of a set of usage scenariosusage scenarios that provide insight into the use of that provide insight into the use of
the system or product under different operating the system or product under different operating
conditions.conditions.

any any prototypesprototypes developed to better define requirementsdeveloped to better define requirements.

18. 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 functionsFunctional—processing narratives for software functions

Use-case—descriptions of the interaction between an Use-case—descriptions of the interaction between an
“actor” and the system“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. 19
Skip – Self ReadingSkip – Self Reading
Possibly One Lecture on UMLPossibly One Lecture on UML

20. 20
Use-CasesUse-Cases

A collection of A collection of user scenariosuser scenarios that describe the thread of usage of a system that describe the thread of usage of a system

Each scenario is described from the point-of-view of an “Each scenario is described from the point-of-view of an “actoractor”—a person or ”—a person or
device that interacts with the software in some waydevice 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. 21
Use-Case DiagramUse-Case Diagram
homeowner
Arms/disarms
system
Accesses system
via Internet
Reconfigures sensors
and related
system features
Responds to
alarm event
Encounters an
error condition
system
administrator
sensors

22. 22
Class DiagramClass Diagram
Sensor
name/id
type
location
area
characteristics
identify()
enable()
disable()
reconfigure()
From the From the SafeHomeSafeHome system … system …

23. 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
Reading
commands
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. 24
Validating RequirementsValidating Requirements

Is each requirement Is each requirement consistentconsistent with the overall objective for the system/product? with the overall objective for the system/product?

Have Have allall requirements been specified at the requirements been specified at the proper levelproper level of abstraction? That is, do of abstraction? That is, do
some requirements provide a level of technical detail that is inappropriate at this some requirements provide a level of technical detail that is inappropriate at this
stage?stage?

Is the requirement Is the requirement really necessaryreally necessary or does it represent an add-on feature that may or does it represent an add-on feature that may
not be essential to the objective of the system?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 specific (generally, a specific
individual) noted for each requirement? 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 will house in the technical environment that will house
the system or product?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, function and the information, function and
behavior of the system to be built.behavior of the system to be built.