System Engineering

LECTURE 9 By Umm-e-Laila
1

Topics to be covered
System Engineering -System Engineering Hierarchy -Business Process Engineering -Requirement Engineering -System Engineering

Computer-based System
Software engineering occurs as a consequence of system engineering System engineering may take on two different forms depending on the application domain
Business process engineering conducted when the context of the work focuses on a business enterprise Product engineering conducted when the context of the work focuses on a product that is to be built

Both forms bring order to the development of computer-based systems Both forms work to allocate a role for computer software and to establish the links that tie software to other elements of a computer-based system

System
System (Webster)
A set or arrangement of things so related as to form a unity or organic whole A set of facts, principles, rules. etc., to show a logical plan linking the various parts A method or plan of classification or arrangement An established way of doing something such as a method or procedure

Computer-based System
Defined: A set or arrangement of elements that are organized to accomplish some predefined goal by processing information The goal may be to support some business function or to develop a product that can be sold to generate business revenue A computer-based system makes use of system elements Elements constituting one system may represent one macro element of a still larger system Example
A factory automation system may consist of a numerical control machine, robots, and data entry devices; each can be its own system At the next lower hierarchical level, a manufacturing cell is its own computer-based system that may integrate other macro elements

The role of the system engineer is to define the elements of a specific computer-based system in the context of the overall hierarchy of systems

Computer-based System (continued)

A computer-based system makes use of the following four system elements that combine in a variety of ways to transform information
Software: computer programs, data structures, and related work products that serve to effect the logical method, procedure, or control that is required Hardware: electronic devices that provide computing capability, interconnectivity devices that enable flow of data, and electromechanical devices that provide external functions People: Users and operators of hardware and software Database: A large, organized collection of information that is accessed via software and persists over time

The uses of these elements are described in the following:

Documentation: Descriptive information that portrays the use and operation of the system Procedures: The steps that define the specific use of each system element or the procedural context in which the system resides

System Engineering Process

The system engineering process begins with a world view; the business or product domain is examined to ensure that the proper business or technology context can be established The world view is refined to focus on a specific domain of interest Within a specific domain, the need for targeted system elements is analyzed Finally, the analysis, design, and construction of a targeted system element are initiated At the world view level, a very broad context is established At the bottom level, detailed technical activities are conducted by the relevant engineering discipline (e.g., software engineering)

"Always design a thing by considering it in its next larger context a chair in a room, a room in a house, a house in an environment, and environment in a city plan"
7

System Engineering Hierarchy

World View

Domain View

Element View Component View

8

System Modeling (at each view level)

Defines the processes (e.g., domain classes in OO terminology) that serve the needs of the view under consideration Represents the behavior of the processes and the assumptions on which the behavior is based Explicitly defines intra-level and inter-level input that form links between entities in the model Represents all linkages (including output) that will enable the engineer to better understand the view May result in models that call for one of the following
Completely automated solution A semi-automated solution A non-automated (i.e., manual) approach

Factors to Consider when Constructing a Model

Assumptions
These reduce the number of possible variations, thus enabling a model to reflect the problem in a reasonable manner

Simplifications
These enable the model to be created in a timely manner

Limitations
These help to bound the maximum and minimum values of the system

Constraints
These guide the manner in which the model is created and the approach taken when the model is implemented

Preferences
These indicate the preferred solution for all data, functions, and behavior They are driven by customer requirements

Optimization of some of these factors may be mutually exclusive

10

System Modeling with UML

The Uniform Modeling Language (UML) provides diagrams for analysis and design at both the system and software levels Examples
Use case diagrams Activity diagrams Class diagrams State diagrams

11

Business Process Engineering

uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise focuses first on the enterprise and then on the business area
creates enterprise models, data models and process models creates a framework for better information management distribution, and control

12

Business Process Engineering

Business process engineering defines architectures that will enable a business to use information effectively It involves the specification of the appropriate computing architecture and the development of the software architecture for the organization's computing resources Three different architectures must be analyzed and designed within the context of business objectives and goals
The data architecture provides a framework for the information needs of a business (e.g., ERD) The application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose The technology infrastructure provides the foundation for the data and application architectures
It includes the hardware and software that are used to support the applications and data

13

Business Engineering Hierarchy

The Enterprise
Information Strategy Planning (World View)

A Business Area

Business Area Analysis (Domain View) Business System Design (element view)

Information System

Construction & integration (Detailed View)

14

The BPE Hierarchy

Information strategy planning (ISP) (world view)
strategic goals defined success factors/business rules identified enterprise model created processes/services modeled interrelationships of processes and data

Business area analysis (BAA) (domain view) Business system design - Application Engineering (element view)

Construction and delivery (detailed view) using CASE and 4GTs, testing
15

Software engineering modeling applications/procedures that address (BAA) and constraints of ISP

 Product engineering translates the customer's desire for a set of defined capabilities into a working product It achieves this goal by establishing a product architecture and a support infrastructure
Product architecture components consist of people, hardware, software, and data Support infrastructure includes the technology required to tie the components together and the information to support the components

Product Engineering

Requirements engineering elicits the requirements from the customer and allocates function and behavior to each of the four components System component engineering happens next as a set of concurrent activities that address each of the components separately
Each component takes a domain-specific view but maintains communication with the other domains The actual activities of the engineering discipline takes on an element view

Analysis modeling allocates requirements into function, data, and behavior Design modeling maps the analysis model into data/class, architectural, interface, and component design

16

Product Engineering Hierarchy

Product Requirements Engineering Human Engineering Hardware Engineering Software Engineering
Data and Classes

Database Engineering

System Component Engineering Analysis Modeling Design Modeling

Function

Behavior

Data/Class Design

Architectural Interface Design Design

Component Design

Construction
17

Requirements Engineering
Challenge facing system and software engineers
How can we ensure that we have specified a system that: Properly meets the customers needs Satisfies the customers expectations

Requirements engineering provides mechanisms for:

Understanding what the customer wants analyzing need assessing feasibility negotiating a reasonable solution specifying the solution validating the specification managing the transformation of the requirements into an operational system

18

Requirements Engineering
The requirements engineering process can be described in six steps:
Inception Elicitation Elaboration Negotiation Specification Validation Requirements management
19

Inception Task
During inception, the requirements engineer asks a set of questions to establish A basic understanding of the problem The people who want a solution The nature of the solution that is desired The effectiveness of preliminary communication and collaboration between the customer and the developer Through these questions, the requirements engineer needs to Identify the stakeholders Recognize multiple viewpoints Work toward collaboration Break the ice and initiate the communication
20

Requirements Elicitation
It might seem that this should be simple:
Ask the customer, users, and others:
What the objectives for the system are What is to be accomplished How the system fits the into the needs of the business How the system will be used on a day-to-day basis

In fact it is hard!
Problems of scope Problems of understanding Problems of volatility
21

Problems of Scope
The boundary of the system may be ill-defined
Who is going to interact with the system? What other systems are involved? Exactly what functionality is the responsibility of the system
e.g. should a rostering system produce a telephone directory?

The customer/user may specify unnecessary technical detail that may confuse overall system objectives

e.g. specifying OS, language, hardware, etc. for no particularly good reason
22

Problems of Understanding
Customers/users may:
Not be completely sure of what is needed, e.g.:
See what you can do to help us (Marketing director of textile business) Try to improve the project (Director of British Aircraft Corporation, with reference to the Concorde project)

Have a poor understanding of the capabilities and limitations of their computing equipment Not have a full understanding of the problem domain Have trouble communicating needs to system engineer Omit information believed to be obvious Specify requirements that conflict with needs of others Specify requirements that are ambiguous or untestable

23

Problems of Volatility
Requirements change over time Change is inevitable in most systems, due to factors such as:
Changes in customer organization, e.g. Changes in scale, e.g. External changes
new divisions, new products Number of transactions per day Number of users Increased connection bandwidth Changes in law (e.g. taxation) Changes in international standards (e.g. MPEG)

Customers get new ideas as they become aware of system possibilities

24

Elicitation Work Products

The work products will vary depending on the system, but should include one or more of the following items A statement of need and feasibility A bounded statement of scope for the system or product A list of customers, users, and other stakeholders who participated in requirements elicitation A description of the system's technical environment A list of requirements (organized by function) and the domain constraints that apply to each A set of preliminary usage scenarios (in the form of use cases) that provide insight into the use of the system or product under different operating conditions Any prototypes developed to better define requirements

25

Elaboration Task
During elaboration, the software engineer takes the information obtained during inception and elicitation and begins to expand and refine it Elaboration focuses on developing a refined technical model of software functions, features, and constraints It is an analysis modeling task
Use cases are developed Domain classes are identified along with their attributes and relationships State machine diagrams are used to capture the life on an object

The end result is an analysis model that defines the functional, informational, and behavioral domains of the problem

26

Developing Use Cases

Step One Define the set of actors that will be involved in the story
Actors are people, devices, or other systems that use the system or product within the context of the function and behavior that is to be described Actors are anything that communicate with the system or product and that are external to the system itself

Step Two Develop use cases, where each one answers a set of questions

(More on next slide)

27

Negotiation Task
During negotiation, the software engineer reconciles the conflicts between what the customer wants and what can be achieved given limited business resources Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders Risks associated with each requirement are identified and analyzed Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction

28

Specification Task
A specification is the final work product produced by the requirements engineer It is normally in the form of a software requirements specification It serves as the foundation for subsequent software engineering activities It describes the function and performance of a computer-based system and the constraints that will govern its development It formalizes the informational, functional, and behavioral requirements of the proposed software in both a graphical and textual format

29

Validation Task
During validation, the work products produced as a result of requirements engineering are assessed for quality The specification is examined to ensure that
all software requirements have been stated unambiguously inconsistencies, omissions, and errors have been detected and corrected the work products conform to the standards established for the process, the project, and the product

The formal technical review serves as the primary requirements validation mechanism
Members include software engineers, customers, users, and other stakeholders

30

Requirements Management
We have noted that changes in requirements:
are essentially unavoidable will persist throughout the lifetime of the system

Requirements management helps the project team to identify, track and control requirements and changes to them
This is closely related to configuration management

Traceability tables are developed for requirements

31

A Generic Traceability Table

A01
R01

A02

A03

Aii

R02
R03 Rnn
32

Traceability Tables
Features traceability table
Source traceability table
Show how requirements relate to customerobservable system features
Identify the source of each requirement

Dependency traceability table Subsystem traceability table Interface traceability table

Show relationships between requirements

Categorise requirements according to subsystems they govern

Shows how requirements relate to internal and external system interfaces

33

System Modeling Process

Hartley-Pirbhai Modeling System Context Diagram (SCD)
top level node in system hierarchy used to establish the boundary between the system being implemented (system model template serves as its basis)

System Flow Diagram (SFD)

refinement of the process and control functions from SCD, derived by identifying the major subsystems and lines of information flow.

Initial SFD is becomes the top level node of a hierarchy of more successively more detailed SFD's System Specification
developed by writing narrative description for each subsystem and definitions for all data that flow between subsystems
34

System Modeling
Any computer-based system can be modeled as a box with input > processing(in the box) > output. Hatley and Pirbhai extend this with
user interface processing maintenance and self testing features. Hatley and Pirbhai have developed a template that helps modelers describe the system
35

System Model Template

36

Conveyor Line Sorting System (CLSS)

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 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 code, the boxes will be shunted into the appropriate bins. Boxes pass in random order and are evenly spaced. The line is moving slowly. A desk-top computer located at the sorting station executes all CLSS software, interacts with the bar-code reader to read part numbers on each box, interacts with the conveyor line monitoring equipment to acquire conveyor line speed, stores all part numbers sorted, interacts with a sorting station operator to produce a variety of reports and diagnostics, sends control signals to the shunting hardware to sort the boxes, and communicates with a central factory automation system.
37

Architecture Flow Diagram

38

Architecture Flow Diagram

39

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
These and other UML models will be discussed later

40

Deployment Diagram
CLSS processor

Sort ing subsyst em

Operat or display

Sensor dat a acquisit ion subsyst em

shunt cont roller

Conveyor Pulse t ach

Bar code reader

Shunt act uat or

41

Activity Diagram
st a rt c o n v e y o r l i n e re a d b a r c o d e g e t c o n v e y o r sp e e d

v alid bar c ode

inv alid bar c ode

det er m ine bin loc at ion

se t f o r re j e c t b i n

se n d sh u n t c o n t ro l d a t a

g e t sh u n t st a t u s

re a d b a r c o d e

g e t c o n v e y o r st a t u s

p ro d u c e re p o rt e n t ry

c onv ey or s t opped

c onv ey or in m ot ion

42

Class Diagram
class name 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( ) 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)

43

Use-Case Diagram
Arms/ disarms syst em

Accesses syst em via Int ernet homeow ner

sensors

Responds t o alarm event

Encount ers an error condit ion

syst em administ rat or

Reconf igures sensors and relat ed syst em f eat ures

44