Software Engineering Lecture 10: System Engineering

Today’s Topics l System Engineering Concepts l Business Process Engineering l Product Engineering l Requirements Elicitation, Analysis & Specification l System Modeling

System Engineering l Precedes software engineering l “Put software into context” Work flow & other human activities Business model l Business Process Engineering Focus on a business enterprise l Product Engineering Focus on a product to be built

What is a “System”? l Types of systems: political, educational, avionics, banking, manufacturing, … l Computer-based system: “A set of elements that are organized to accomplish some predefined goal by processing information” l Goals: Support a business function, develop a product, etc.

System Elements l Software l Hardware l People l Database l Documentation l Procedures These elements combine in a variety of ways to transform information

System Hierarchy l Each computer-based system can be part of a larger system l System Engineering Hierarchy Organize the systems into a set of layered views (Figure 10.1) Define the elements for a specific computer-based system in the context of the overall hierarchy of systems

System Engineering Hierarchy Software Engineering Information Strategy Planning Business Area Analysis [From SEPA 5/e]

System Modeling l System engineering is a modeling process l For each view: Define processes Represent process behavior List process assumptions Define external and internal inputs Model linkages (control, data, I/O)

System Modeling [2] l Assumptions range of allowable data l Simplifications partition data into categories l Limitations bounds on functionality l Constraints guide the implementation l Preferences indicate preferred architecture (data, functions, technology) Much of this information is derived from customer requirements

Business Process Engineering l Data Architecture Framework for the data objects used by the business (+ relationships) l Applications Architecture Elements which transform data objects for a business purpose l Technology Infrastructure Foundation for data & applications architectures

BPE Hierarchy [From SEPA 5/e]

Information Strategy Planning l Focus: World View (entire business) l Goals: Isolate domains of the business (engineering, marketing, sales, …) Define data objects visible at the enterprise level (+ relationships & data flow)

Business Area Analysis l Focus: Domain View (selected business area) l Goals: Isolate functions and procedures that allow the area to meet its goals Define data objects visible at the business area level (+ relationships & data flow) Identify information support systems

Business System Design l Focus: Element View (specific information system in a business area) l Goals: Model the requirements Design: Data Architecture Applications Architecture Technology Infrastructure

Construction & Integration l Focus: Detailed View (implementation of an element) l Goals: Implement the architectures and infrastructure Insert the completed system into the business area (training, logistics, …)

Product Engineering Hierarchy [From SEPA 5/e]

Requirements Engineering l Elicitation l Analysis & Negotiation l Specification l Modeling l Validation l Management How can we specify a system that meets the customer’s needs and expectations?

Requirements Elicitation l Challenges Scope: Defining the system boundary Lack of clarity on overall objectives Understanding: Customer not skilled Doesn’t state the obvious Requirements ambiguous, conflicting, … Volatility: Requirements change over time

Elicitation [2] l Assess feasibility l Identify people & their role(s) l Define technical environment l Identify domain constraints l Select elicitation method(s) l Solicit participation from several perspectives l Identify ambiguous requirements l Create usage scenarios

Analysis & Negotiation l Is each requirement: Consistent with overall objective? Sufficiently abstract? Essential to overall objective? Bounded and unambiguous? Attributed to a source? (person) Conflicting with other requirements? Achievable in technical environment? Testable, once implemented?

Requirements Specification l Elements of a Specification: Written documents Graphical models Formal mathematical models l Final work product: System Specification

System Modeling l Evaluate the system’s components in relation to one another l Link requirements to system components l Validate assumptions about data flow, work flow, input / output,...

Requirements Validation l Is each requirement: Stated clearly? Verified by an identified source? Bounded in a quantitative way? Associated with other requirements? Consistent with domain constraints? Testable, with specified tests? Traceable to the system model? Traceable to overall objectives?

Requirements Management l Identify, control, and track: New requirements Changes to requirements l Active throughout the life-cycle l Traceability Table Relates requirements to features, source, dependency, subsystem, interface, etc.

Generic Traceability Table [From SEPA 5/e]

System Modeling Techniques l System Model Template (Hatley & Pirbhai, 1987) Allocate system elements to 5 processing regions: user interface input system function and control output maintenance & self-test

System Model Template [From SEPA 5/e]

Modeling Techniques [2] l System Context Diagram (SCD) Establish the information boundary between the system & the operating environment External producers & consumers of information Entities that communicate through the interface / testing capability

System Context Diagram [From SEPA 5/e]

Modeling Techniques [2] l System Flow Diagram Identify major subsystems Identify data & control flow Each subsystem can also be decomposed into an SFD Final product: a hierarchy of SFDs

System Flow Diagram [From SEPA 5/e]

SFD Hierarchy [From SEPA 5/e]

Questions?

Software Engineering for Information Technology Lecture 10: System Engineering

Today’s Topics l System Engineering Concepts l Business Process Engineering l Product Engineering l Requirements Elicitation, Analysis & Specification l System Modeling

System Engineering l Precedes software engineering l “Put software into context” Work flow & other human activities Business model l Business Process Engineering Focus on a business enterprise l Product Engineering Focus on a product to be built

What is a “System”? l Types of systems: political, educational, avionics, banking, manufacturing, … l Computer-based system: “A set of elements that are organized to accomplish some predefined goal by processing information” l Goals: Support a business function, develop a product, etc.

System Elements l Software l Hardware l People l Database l Documentation l Procedures These elements combine in a variety of ways to transform information

System Hierarchy l Each computer-based system can be part of a larger system l System Engineering Hierarchy Organize the systems into a set of layered views (Figure 10.1) Define the elements for a specific computer-based system in the context of the overall hierarchy of systems

System Engineering Hierarchy Software Engineering Information Strategy Planning Business Area Analysis [From SEPA 5/e]

System Modeling l System engineering is a modeling process l For each view: Define processes Represent process behavior List process assumptions Define external and internal inputs Model linkages (control, data, I/O)

System Modeling [2] l Assumptions range of allowable data l Simplifications partition data into categories l Limitations bounds on functionality l Constraints guide the implementation l Preferences indicate preferred architecture (data, functions, technology) Much of this information is derived from customer requirements

Business Process Engineering l Data Architecture Framework for the data objects used by the business (+ relationships) l Applications Architecture Elements which transform data objects for a business purpose l Technology Infrastructure Foundation for data & applications architectures

BPE Hierarchy [From SEPA 5/e]

Information Strategy Planning l Focus: World View (entire business) l Goals: Isolate domains of the business (engineering, marketing, sales, …) Define data objects visible at the enterprise level (+ relationships & data flow)

Business Area Analysis l Focus: Domain View (selected business area) l Goals: Isolate functions and procedures that allow the area to meet its goals Define data objects visible at the business area level (+ relationships & data flow) Identify information support systems

Business System Design l Focus: Element View (specific information system in a business area) l Goals: Model the requirements Design: Data Architecture Applications Architecture Technology Infrastructure

Construction & Integration l Focus: Detailed View (implementation of an element) l Goals: Implement the architectures and infrastructure Insert the completed system into the business area (training, logistics, …)

Product Engineering Hierarchy [From SEPA 5/e]

Requirements Engineering l Elicitation l Analysis & Negotiation l Specification l Modeling l Validation l Management How can we specify a system that meets the customer’s needs and expectations?

Requirements Elicitation l Challenges Scope: Defining the system boundary Lack of clarity on overall objectives Understanding: Customer not skilled Doesn’t state the obvious Requirements ambiguous, conflicting, … Volatility: Requirements change over time

Elicitation [2] l Assess feasibility l Identify people & their role(s) l Define technical environment l Identify domain constraints l Select elicitation method(s) l Solicit participation from several perspectives l Identify ambiguous requirements l Create usage scenarios

Analysis & Negotiation l Is each requirement: Consistent with overall objective? Sufficiently abstract? Essential to overall objective? Bounded and unambiguous? Attributed to a source? (person) Conflicting with other requirements? Achievable in technical environment? Testable, once implemented?

Requirements Specification l Elements of a Specification: Written documents Graphical models Formal mathematical models l Final work product: System Specification

System Modeling l Evaluate the system’s components in relation to one another l Link requirements to system components l Validate assumptions about data flow, work flow, input / output,...

Requirements Validation l Is each requirement: Stated clearly? Verified by an identified source? Bounded in a quantitative way? Associated with other requirements? Consistent with domain constraints? Testable, with specified tests? Traceable to the system model? Traceable to overall objectives?

Requirements Management l Identify, control, and track: New requirements Changes to requirements l Active throughout the life-cycle l Traceability Table Relates requirements to features, source, dependency, subsystem, interface, etc.

Generic Traceability Table [From SEPA 5/e]

System Modeling Techniques l System Model Template (Hatley & Pirbhai, 1987) Allocate system elements to 5 processing regions: user interface input system function and control output maintenance & self-test

System Model Template [From SEPA 5/e]

Modeling Techniques [2] l System Context Diagram (SCD) Establish the information boundary between the system & the operating environment External producers & consumers of information Entities that communicate through the interface / testing capability

System Context Diagram [From SEPA 5/e]

Modeling Techniques [2] l System Flow Diagram Identify major subsystems Identify data & control flow Each subsystem can also be decomposed into an SFD Final product: a hierarchy of SFDs

System Flow Diagram [From SEPA 5/e]

SFD Hierarchy [From SEPA 5/e]

Questions?

Software Engineering for Information Technology Lecture 10: System Engineering

Today’s Topics l System Engineering Concepts l Business Process Engineering l Product Engineering l Requirements Elicitation, Analysis & Specification l System Modeling

System Engineering l Precedes software engineering l “Put software into context” Work flow & other human activities Business model l Business Process Engineering Focus on a business enterprise l Product Engineering Focus on a product to be built

What is a “System”? l Types of systems: political, educational, avionics, banking, manufacturing, … l Computer-based system: “A set of elements that are organized to accomplish some predefined goal by processing information” l Goals: Support a business function, develop a product, etc.

System Elements l Software l Hardware l People l Database l Documentation l Procedures These elements combine in a variety of ways to transform information

System Hierarchy l Each computer-based system can be part of a larger system l System Engineering Hierarchy Organize the systems into a set of layered views (Figure 10.1) Define the elements for a specific computer-based system in the context of the overall hierarchy of systems

System Engineering Hierarchy Software Engineering Information Strategy Planning Business Area Analysis [From SEPA 5/e]

System Modeling l System engineering is a modeling process l For each view: Define processes Represent process behavior List process assumptions Define external and internal inputs Model linkages (control, data, I/O)

System Modeling [2] l Assumptions range of allowable data l Simplifications partition data into categories l Limitations bounds on functionality l Constraints guide the implementation l Preferences indicate preferred architecture (data, functions, technology) Much of this information is derived from customer requirements

Business Process Engineering l Data Architecture Framework for the data objects used by the business (+ relationships) l Applications Architecture Elements which transform data objects for a business purpose l Technology Infrastructure Foundation for data & applications architectures

BPE Hierarchy [From SEPA 5/e]

Information Strategy Planning l Focus: World View (entire business) l Goals: Isolate domains of the business (engineering, marketing, sales, …) Define data objects visible at the enterprise level (+ relationships & data flow)

Business Area Analysis l Focus: Domain View (selected business area) l Goals: Isolate functions and procedures that allow the area to meet its goals Define data objects visible at the business area level (+ relationships & data flow) Identify information support systems

Business System Design l Focus: Element View (specific information system in a business area) l Goals: Model the requirements Design: Data Architecture Applications Architecture Technology Infrastructure

Construction & Integration l Focus: Detailed View (implementation of an element) l Goals: Implement the architectures and infrastructure Insert the completed system into the business area (training, logistics, …)

Product Engineering Hierarchy [From SEPA 5/e]

Requirements Engineering l Elicitation l Analysis & Negotiation l Specification l Modeling l Validation l Management How can we specify a system that meets the customer’s needs and expectations?

Requirements Elicitation l Challenges Scope: Defining the system boundary Lack of clarity on overall objectives Understanding: Customer not skilled Doesn’t state the obvious Requirements ambiguous, conflicting, … Volatility: Requirements change over time

Elicitation [2] l Assess feasibility l Identify people & their role(s) l Define technical environment l Identify domain constraints l Select elicitation method(s) l Solicit participation from several perspectives l Identify ambiguous requirements l Create usage scenarios

Analysis & Negotiation l Is each requirement: Consistent with overall objective? Sufficiently abstract? Essential to overall objective? Bounded and unambiguous? Attributed to a source? (person) Conflicting with other requirements? Achievable in technical environment? Testable, once implemented?

Requirements Specification l Elements of a Specification: Written documents Graphical models Formal mathematical models l Final work product: System Specification

System Modeling l Evaluate the system’s components in relation to one another l Link requirements to system components l Validate assumptions about data flow, work flow, input / output,...

Requirements Validation l Is each requirement: Stated clearly? Verified by an identified source? Bounded in a quantitative way? Associated with other requirements? Consistent with domain constraints? Testable, with specified tests? Traceable to the system model? Traceable to overall objectives?

Requirements Management l Identify, control, and track: New requirements Changes to requirements l Active throughout the life-cycle l Traceability Table Relates requirements to features, source, dependency, subsystem, interface, etc.

Generic Traceability Table [From SEPA 5/e]

System Modeling Techniques l System Model Template (Hatley & Pirbhai, 1987) Allocate system elements to 5 processing regions: user interface input system function and control output maintenance & self-test

System Model Template [From SEPA 5/e]

Modeling Techniques [2] l System Context Diagram (SCD) Establish the information boundary between the system & the operating environment External producers & consumers of information Entities that communicate through the interface / testing capability

System Context Diagram [From SEPA 5/e]

Modeling Techniques [2] l System Flow Diagram Identify major subsystems Identify data & control flow Each subsystem can also be decomposed into an SFD Final product: a hierarchy of SFDs

System Flow Diagram [From SEPA 5/e]

SFD Hierarchy [From SEPA 5/e]

Questions?