1. Software Engineering Lecture 10: System Engineering

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

3. 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

4. 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.

5. 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

6. 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

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

8. 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)

9. 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

10. 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

11. BPE Hierarchy [From SEPA 5/e]

12. 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)

13. 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

14. 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

15. 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, …)

16. Product Engineering Hierarchy [From SEPA 5/e]

17. 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?

18. 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

19. 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

20. 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?

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

22. 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,...

23. 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?

24. 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.

25. Generic Traceability Table [From SEPA 5/e]

26. 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

27. System Model Template [From SEPA 5/e]

28. 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

29. System Context Diagram [From SEPA 5/e]

30. 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

31. System Flow Diagram [From SEPA 5/e]

32. SFD Hierarchy [From SEPA 5/e]

33. Questions?

34. Software Engineering for Information Technology Lecture 10: System Engineering

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

36. 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

37. 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.

38. 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

39. 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

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

41. 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)

42. 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

43. 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

44. BPE Hierarchy [From SEPA 5/e]

45. 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)

46. 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

47. 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

48. 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, …)

49. Product Engineering Hierarchy [From SEPA 5/e]

50. 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?

51. 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

52. 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

53. 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?

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

55. 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,...

56. 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?

57. 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.

58. Generic Traceability Table [From SEPA 5/e]

59. 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

60. System Model Template [From SEPA 5/e]

61. 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

62. System Context Diagram [From SEPA 5/e]

63. 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

64. System Flow Diagram [From SEPA 5/e]

65. SFD Hierarchy [From SEPA 5/e]

66. Questions?

67. Software Engineering for Information Technology Lecture 10: System Engineering

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

69. 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

70. 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.

71. 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

72. 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

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

74. 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)

75. 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

76. 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

77. BPE Hierarchy [From SEPA 5/e]

78. 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)

79. 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

80. 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

81. 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, …)

82. Product Engineering Hierarchy [From SEPA 5/e]

83. 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?

84. 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

85. 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

86. 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?

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

88. 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,...

89. 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?

90. 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.

91. Generic Traceability Table [From SEPA 5/e]

92. 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

93. System Model Template [From SEPA 5/e]

94. 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

95. System Context Diagram [From SEPA 5/e]

96. 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

97. System Flow Diagram [From SEPA 5/e]

98. SFD Hierarchy [From SEPA 5/e]

99. Questions?