1. SYSTEM ENGINEERING
1
Name :
SYED KEYAN ALI TAHIR (124)
USMAN BIN SAAD (118)
SHAHID IQBAL (160)
M.RAMZAN (074)
M.BILAL
SUBMITTED TO:
Mehreen Akhter
2. What is system engineering:-
•It is an approach to design, Implement
and evaluate successful development of
complex system.
2
3. Jobs for system engineers:-
• System engineer
• Mission operation planner
• Safety engineer
• Airworthiness and certification engineer
• Missile defiance national team chef engineer
• Signal intelligence analyst
• System integration engineer
• Ground test planning engineer
• Space craft system engineer
4. Duties of software engineer:-
• Engineer have to ensure must that all things are working properly
• They have to create new and latest ideas for their companies
• Technical work also required in field
• Coordination , leadership and organisation important aspects of
job
• They are ready to cooperate with other in daily life
5. System Engineering
•Elements of a computer-based
system
• Software
• Hardware
• People
• Database
• Documentation
• Procedures
5
6. Systems
A hierarchy of macro-elements
6
Worldview
Businessor
Product Domain
Domainof interest
Domainview
Systemelement
Element view
Detailedview
7. System Modeling
• define the processes that serve the needs of the view under
consideration.
• represent the behavior of the processes and the assumptions
on which the behavior is based.
• explicitly define both exogenous and endogenous input to the
model.
• exogenous inputs link one constituent of a given view with other
constituents at the same level of other levels; endogenous input
links individual components of a constituent at a particular view.
• represent all linkages (including output) that will enable the
engineer to better understand the view.
7
8. Business Process Engineering
8
uses an integrated set of procedures,uses an integrated set of procedures,
methods, and tools to identify howmethods, and tools to identify how
information systems can best meet theinformation systems can best meet the
strategic goals of an enterprisestrategic goals of an enterprise
focuses first on the enterprise and then on thefocuses first on the enterprise and then on the
business areabusiness area
creates enterprise models, data models andcreates enterprise models, data models and
process modelsprocess models
creates a framework for better informationcreates a framework for better information
management distribution, and controlmanagement distribution, and control
9. System Architectures
• Three different architectures must be analyzed and designed
within the context of business objectives and goals:
• data architecture
• applications architecture
• technology infrastructure
• data architecture provides a framework for the information
needs of a business or business function
• application architecture encompasses those elements of a
system that transform objects within the data architecture for
some business purpose
• technology infrastructure provides the foundation for the
data and application architectures
9
10. The BPE Hierarchy
•Information strategy planning (ISP)
ostrategic goals defined
osuccess factors/business rules identified
oenterprise model created
•Business area analysis (BAA)
oprocesses/services modeled
ointerrelationships of processes and data
•Application Engineering
oa.k.a ... software engineering
omodeling applications/procedures that
address (BAA) and constraints of ISP
•Construction and delivery
using CASE and 4GTs, testing
10
11. Information Strategy Planning
• Management issues
o define strategic business goals/objectives
o isolate critical success factors
o conduct analysis of technology impact
o perform analysis of strategic systems
• Technical issues
o create a top-level data model
o cluster by business/organizational area
o refine model and clustering
11
12. Defining Objectives and Goals
•Objective—general statement of
direction
•Goal—defines measurable objective:
“reduce manufactured cost of our
product”
o Subgoals:
decrease reject rate by 20% in first 6 months
gain 10% price concessions from suppliers
re-engineer 30% of components for ease of
manufacture during first year
•Objectives tend to be strategic while
goals tend to be tactical
12
13. Business Area Analysis
•define “naturally cohesive groupings of
business functions and data” (Martin)
•perform many of the same activities as ISP,
but narrow scope to individual business
area
•identify existing (old) information systems /
determine compatibility with new ISP
model
define systems that are problematic
defining systems that are incompatible with
new information model
begin to establish re-engineering priorities
13
15. Product Engineering
15
System analysis
(World view)
The complete
product
capabilities
Component
engineering
(Domain view)
Processing requirement
Analysis & Design
Modeling
(Element view)
Construction
&
Integration
(Detailed view)
software
function
Software
Engineering
program
component
hardware
data behavior
16. Product Architecture Template
16
user interface processing
input
processing
output
processing
maintenance and self-test
process and control
functions
17. Architecture Flow Diagram
17
bar code
reader
subsystem
bar code
decoding
subsystem
data base
access
subsystem
shunt
control
subsystem
report
formating
subsystem
diagnostics
subsystem
operator
interface
subsystem
shunt
controller
mainframe
communications
driver
operator requests CLSS queries, reports, displays
shunt control status
bar code acquisition request
bar code
pulse tach input
line
speed
bar code
reader status
sensor status
raw bar
code data
part
number
report
requests
bin
location
key
sort records
formated
reporting data
sorting reports
shunt commands
CLSS reports
BCR status
shunt status
communications status
timing/location data
operator
interface
data acquisition
interface diagnostic interface output interface
CLSS processing & control
sensor data
acquisition
subsystem
18. System Modeling with UML
•Deployment diagrams
• Each 3-D box depicts a hardware element that is
part of the physical architecture of the system
•Activity diagrams
• Represent procedural aspects of a system
element
•Class diagrams
• Represent system level elements in terms of the
data that describe the element and the
operations that manipulate the data
18
20. Activity Diagram
20
get c onv ey or speed
send shunt
c ont rol dat a
get shunt st at us read bar c ode
st art c onv ey or line
det er m ine bin loc at ion
valid bar code
set f or rejec t bin
conveyor in m otion
read bar c ode
get c onv ey or st at us
produc e report ent ry
conveyor stopped
invalid bar code
21. Class Diagram
21
Box
barcode
forwardSpeed
conveyorLocat ion
height
widt h
dept h
weight
cont ent s
readBarcode()
updat eSpeed ()
readSpeed()
updat eLocat ion()
readLocat ion()
get Dimensions()
get Weight()
checkCont ent s()
class name
at t ribut es
not e use of capit al
let t er f or mult i-word
at t ribut e names
operat ions
(parent heses at end
of name indicat e t he
list of at t ribut es t hat t he
operat ion requires)
22. Requirements Engineering
• Inception—Establish a basic understanding of the problem
and the nature of the solution.
• Elicitation—Draw out the requirements from stakeholders.
• Elaboration—Create an analysis model that represents
information, functional, and behavioral aspects of the
requirements.
• Negotiation—Agree on a deliverable system that is realistic
for developers and customers.
• Specification—Describe the requirements formally or
informally.
• Validation—Review the requirement specification for errors,
ambiguities, omissions, and conflicts.
• Requirements management—Manage changing
requirements.
22
23. Inception
•Ask “context-free” questions
• Who is behind the request for this work?
• Who will use the solution (product/system)?
• What will be the economic benefits?
• How would you characterize “good” output from the
system?
• What problems does this solution address?
• What environment will the product be used in?
• Are you the right person to answer these questions?
• Are these question relevant?
• Can anyone else provide additional information?
• Should I be asking you anything else?
23
24. Getting Requirements Right
• “The hardest single part of building a software system is
deciding what to build. No part of the work so cripples the
resulting system if done wrong. No other part is more difficult to
rectify later.”
—Fred Brooks
• “The seeds of major software disasters are usually sown within
the first three months of commencing the software project.”
—Capers Jones
• “We spend a lot of time—the majority of project effort—not
implementing or testing, but trying to decide what to build.”
—Brian Lawrence
24
25. Eliciting Requirements
• Why is it so difficult to clearly understand what the customer wants ?
• Scope
• The boundary of the system is ill-defined.
• Customers/users specify unnecessary technical detail that may confuse rather
than clarify objectives.
• Understanding
• Customers are not completely sure of what is needed.
• Customers have a poor understanding of the capabilities and limitations of the
computing environment.
• Customers don’t have a full understanding of their problem domain.
• Customers have trouble communicating needs to the system engineer.
• Customers omit detail that is believed to be obvious.
• Customers specify requirements that conflict with other requirements.
• Customers specify requirements that are ambiguous or untestable.
• Volatility
• Requirements change over time.
25
26. Collaborative Requirements
Gathering
• Meetings are attended by all interested stakeholders.
• Rules established for preparation and participation.
• Agenda should be formal enough to cover all important points,
but informal enough to encourage the free flow of ideas.
• A facilitator controls the meeting.
• A definition mechanism (blackboard, flip charts, etc.) is used.
• During the meeting:
• The problem is identified.
• Elements of the solution are proposed.
• Different approaches are negotiated.
• A preliminary set of solution requirements are obtained.
• The atmosphere is collaborative and non-threatening.
26
27. Quality Function Deployment
• Function deployment determines the “value” (to the
customer) of each function required of the system.
• Information deployment identifies data objects and
events.
• Task deployment examines the behavior of the system.
• Value analysis determines the priority of requirements.
27
28. Elicitation Work Products
• Statement of need and feasibility.
• Statement of scope.
• List of participants in requirements elicitation.
• Description of the system’s technical
environment.
• List of requirements and associated domain
constraints.
• List of usage scenarios.
• Any prototypes developed to refine
requirements.
28
29. Use-Cases
• A use-case scenario is a story about how someone or
something external to the software (known as an actor)
interacts with the system.
• Each scenario answers the following questions:
• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or
change?
• Will the actor have to inform the system about changes in the
external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
29
31. Elements of the Analysis Model
• Scenario-based elements
• Use-case—How external actors interact with the system
(use-case diagrams; detailed templates)
• Functional—How software functions are processed in
the system (flow charts; activity diagrams)
• Class-based elements
• The various system objects (obtained from scenarios)
including their attributes and functions (class diagram)
• Behavioral elements
• How the system behaves in response to different events
(state diagram)
• Flow-oriented elements
• How information is transformed as if flows through the
system (data flow diagram)
31
35. Negotiating Requirements
•Identify the key stakeholders
• These are the people who will be involved in the
negotiation
•Determine each of the stakeholders “win
conditions”
• Win conditions are not always obvious
•Negotiate
• Work toward a set of requirements that lead to
“win-win”
35
