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.
Computer-Based System Elements
- Software
- Hardware
- People
- Database
- Documentation
- Procedures
System Engineering Hierarchy
- World view
- Domain view
- Element view
- Detailed view
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
System Model Restraining Factors
- Assumptions
- Simplifications
- Limitations
- Constraints
- Preferences
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.
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)
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
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)
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)
- 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)
Traceability Tables
- Features traceability table
- Source traceability table
- Dependency traceability table
- Subsystem traceability table
- Interface traceability table
System Model Template
- User interface
- Input
- Process and control functions
- Output
- Maintenance and self test
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)
- 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