1.12k likes | 1.79k Views
Software Engineering. Lecture 10: System Engineering. Today’s Topics. System Engineering Concepts Business Process Engineering Product Engineering Requirements Elicitation, Analysis & Specification System Modeling. System Engineering. Precedes software engineering
E N D
Software Engineering Lecture 10: System Engineering
Today’s Topics • System Engineering Concepts • Business Process Engineering • Product Engineering • Requirements Elicitation, Analysis & Specification • System Modeling
System Engineering • Precedes software engineering • “Put software into context” • Work flow & other human activities • Business model • Business Process Engineering • Focus on a business enterprise • Product Engineering • Focus on a product to be built
What is a “System”? • Types of systems: • political, educational, avionics, banking, manufacturing, … • Computer-based system:“A set of elements that are organized to accomplish some predefined goal by processing information” • Goals: Support a business function, develop a product, etc.
Software Hardware People Database Documentation Procedures System Elements These elements combine in a varietyof ways to transform information
System Hierarchy • Each computer-based system can be part of a larger system • 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
InformationStrategy Planning System Engineering Hierarchy Business AreaAnalysis SoftwareEngineering [From SEPA 5/e]
System Modeling • System engineering is a modeling process • For each view: • Define processes • Represent process behavior • List process assumptions • Define external and internal inputs • Model linkages (control, data, I/O)
Assumptions range of allowable data Simplifications partition data into categories Limitations bounds on functionality Constraints guide the implementation Preferences indicate preferred architecture (data, functions, technology) System Modeling [2] Much of this information is derived from customer requirements
Business Process Engineering • Data Architecture • Framework for the data objects used by the business (+ relationships) • Applications Architecture • Elements which transform data objects for a business purpose • Technology Infrastructure • Foundation for data & applications architectures
BPEHierarchy [From SEPA 5/e]
Information Strategy Planning • Focus: World View (entire business) • Goals: • Isolate domains of the business(engineering, marketing, sales, …) • Define data objects visible at the enterprise level (+ relationships & data flow)
Business Area Analysis • Focus: Domain View (selected business area) • 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 • Focus: Element View(specific information system in a business area) • Goals: • Model the requirements • Design: • Data Architecture • Applications Architecture • Technology Infrastructure
Construction & Integration • Focus: Detailed View(implementation of an element) • Goals: • Implement the architectures and infrastructure • Insert the completed system into the business area (training, logistics, …)
ProductEngineeringHierarchy [From SEPA 5/e]
Elicitation Analysis & Negotiation Specification Modeling Validation Management Requirements Engineering How can we specify a system that meets the customer’s needs and expectations?
Requirements Elicitation • 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
Assess feasibility Identify people & their role(s) Define technical environment Identify domain constraints Select elicitation method(s) Solicit participation from several perspectives Identify ambiguous requirements Create usage scenarios Elicitation [2]
Analysis & Negotiation • 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 • Elements of a Specification: • Written documents • Graphical models • Formal mathematical models • Final work product:System Specification
System Modeling • Evaluate the system’s components in relation to one another • Link requirements to system components • Validate assumptions about data flow, work flow, input / output, ...
Requirements Validation • 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 • Identify, control, and track: • New requirements • Changes to requirements • Active throughout the life-cycle • Traceability Table • Relates requirements to features, source, dependency, subsystem, interface, etc.
Generic Traceability Table [From SEPA 5/e]
System Modeling Techniques • 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] • 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
SystemContextDiagram [From SEPA 5/e]
Modeling Techniques [2] • 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
SystemFlowDiagram [From SEPA 5/e]
SFDHierarchy [From SEPA 5/e]
Software Engineeringfor Information Technology Lecture 10: System Engineering
Today’s Topics • System Engineering Concepts • Business Process Engineering • Product Engineering • Requirements Elicitation, Analysis & Specification • System Modeling
System Engineering • Precedes software engineering • “Put software into context” • Work flow & other human activities • Business model • Business Process Engineering • Focus on a business enterprise • Product Engineering • Focus on a product to be built
What is a “System”? • Types of systems: • political, educational, avionics, banking, manufacturing, … • Computer-based system:“A set of elements that are organized to accomplish some predefined goal by processing information” • Goals: Support a business function, develop a product, etc.
Software Hardware People Database Documentation Procedures System Elements These elements combine in a varietyof ways to transform information
System Hierarchy • Each computer-based system can be part of a larger system • 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
InformationStrategy Planning System Engineering Hierarchy Business AreaAnalysis SoftwareEngineering [From SEPA 5/e]
System Modeling • System engineering is a modeling process • For each view: • Define processes • Represent process behavior • List process assumptions • Define external and internal inputs • Model linkages (control, data, I/O)
Assumptions range of allowable data Simplifications partition data into categories Limitations bounds on functionality Constraints guide the implementation Preferences indicate preferred architecture (data, functions, technology) System Modeling [2] Much of this information is derived from customer requirements
Business Process Engineering • Data Architecture • Framework for the data objects used by the business (+ relationships) • Applications Architecture • Elements which transform data objects for a business purpose • Technology Infrastructure • Foundation for data & applications architectures
BPEHierarchy [From SEPA 5/e]
Information Strategy Planning • Focus: World View (entire business) • Goals: • Isolate domains of the business(engineering, marketing, sales, …) • Define data objects visible at the enterprise level (+ relationships & data flow)
Business Area Analysis • Focus: Domain View (selected business area) • 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 • Focus: Element View(specific information system in a business area) • Goals: • Model the requirements • Design: • Data Architecture • Applications Architecture • Technology Infrastructure
Construction & Integration • Focus: Detailed View(implementation of an element) • Goals: • Implement the architectures and infrastructure • Insert the completed system into the business area (training, logistics, …)
ProductEngineeringHierarchy [From SEPA 5/e]
Elicitation Analysis & Negotiation Specification Modeling Validation Management Requirements Engineering How can we specify a system that meets the customer’s needs and expectations?