Lecture 6- System Engineering

1. Lecture 6- System Engineering Computer-Based Systems The System Engineering Hierarchy Business Process Engineering Product Engineering Requirements Engineering System Modeling;

2. Overview Before software can be engineered, the system it is part of must be understood. The overall objective of the system must be determined, the role of the system elements (hardware, software, people, data, etc.) must be identified, and the operational requirements must be created. A representation (i.e. prototype, specification, symbolic model) of the system is produced as the result of the system engineering process. It is important that system engineering work products be managed using the quality assurance techniques.

3. Systems • Don't take a "software-centric" view of the system; consider all system elements before focusing on software. • Good system engineering begins with a clear understanding of the "world view" and progressively narrows until technical detail is understood. • Complex systems are actually a hierarchy of macro-elements that are themselves systems.

4. Computer-Based System Elements • Software • Hardware • People • Database • Documentation • Procedures

5. System Engineering Hierarchy • World view • Domain view • Element view • Detailed view

6. System Modeling • Define the processes that serve the needs of the view under consideration • Represent the process behavior and the assumptions on which the behavior is modeled • Explicitly define the exogenous (links between constituents) and endogenous (links between constituent components) input to the model • Represent all linkages (including outputs) required to understand the view

7. System Model Restraining Factors • Assumptions • Simplifications • Limitations • Constraints • Preferences

8. System Simulation • If simulation capability is not available for a reactive system, project risk increases. • Consider using an iterative process model that will allow the delivery and testing of incrementally more complete products.

9. Business Process Engineering Hierarchy • Information Strategy Planning (world view) • Business Area Analysis (domain view) • Business System Design (element view - software engineers) • Construction and Integration (detailed view - software engineers)

10. Business Process Engineering Architectures • Data architecture - provides framework for information needs of a business or business function • Applications architecture - those system elements that transform objects within the data architecture for some business purpose • Technology infrastructure - provides foundation for the data and application architectures

11. Product Engineering Hierarchy • Requirements engineering (world view) • Component engineering (domain view) • Analysis and Design modeling (element view - software engineers) • Construction and Integration (detailed view - software engineers)

12. Requirements Engineering • Requirements elicitation (find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis) • Requirements analysis and negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs)

13. Requirements specification (work product produced describing the function, performance, and development constraints for a computer-based system) • System modeling (system representation that shows relationships among the system components) • Requirements validation (examines the specification to ensure requirement quality and that work products conform to agreed upon standards) • Requirements management (set of activities that help project team to identify, control, and track requirements and changes as project proceeds)

14. Traceability Tables • Features traceability table • Source traceability table • Dependency traceability table • Subsystem traceability table • Interface traceability table

15. System Model Template • User interface • Input • Process and control functions • Output • Maintenance and self test

16. Systems Modeling Process • 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 (precursor to Data Flow Diagram discussed in Chapter 12)

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

18. Summary • Home work problem and points to ponder No. 10.2 No. 10.4