1 Chapter 10 System Engineering

2 Computer-Based System  A computer-based system is a set or arrangement of elements that are organized to accomplish some predefined goal by processing information. SoftwareSoftware HardwareHardware PeoplePeople DatabaseDatabase DocumentationDocumentation ProceduresProcedures

3 System Engineering System engineering is the activity of specifying, designing, implementing, validating, deploying and maintaining system as a whole to achieve some objective. System engineering is the activity of specifying, designing, implementing, validating, deploying and maintaining system as a whole to achieve some objective.

4 System Engineering Hierarchy MV = {D 1, D 2, …, D n }; D i = {E 1, E 2, …, E m }; E j = {C 1, C 2, …, C k }

5 Example

6 System Modeling  Model Define the processes that serve the needs of the view under consideration.Define the processes that serve the needs of the view under consideration. Represent the behavior of the processes and the assumptions on which the behavior is based.Represent the behavior of the processes and the assumptions on which the behavior is based. Explicitly define both exogenous and endogenous input to the model.Explicitly define both exogenous and endogenous input to the model. Represent all linkages (including output) that will enable the engineer to better understand the view.Represent all linkages (including output) that will enable the engineer to better understand the view.  Restraining factors AssumptionsAssumptions SimplificationsSimplifications LimitationsLimitations ConstraintsConstraints PreferencesPreferences

7

8 Business Process Engineering (BPE)  The goal of business process engineering (BPE) is to define architectures that will enable a business to use information effectively.  Architectures Data architectureData architecture Applications architectureApplications architecture Technology infrastructureTechnology infrastructure

9 The BPE Hierarchy

10 Information Strategy Planning (ISP)  Define strategic business goals  Isolate critical success factors  Conduct analysis of technology impact  Establish the business-level modeling

11  Define strategic business goals Decrease reject rate by 20 % within 9 monthsDecrease reject rate by 20 % within 9 months Gain 10% price concessions from suppliersGain 10% price concessions from suppliers Reengineer keypad to reduce assembly cost by 30%Reengineer keypad to reduce assembly cost by 30% Automate manual assembly of componentsAutomate manual assembly of components Implement a real-time production control systemImplement a real-time production control system

12  Isolate critical success factors (CSFs) Total quality management strategy for the manufacturing organizationTotal quality management strategy for the manufacturing organization Worker training and motivationWorker training and motivation Higher-reliability machinesHigher-reliability machines Higher-quality partsHigher-quality parts A “sales plan” to convince suppliers to reduce pricesA “sales plan” to convince suppliers to reduce prices Availability of engineering staffAvailability of engineering staff

13  Conduct analysis of technology impact How critical is the technology to the achievement of a business objective?How critical is the technology to the achievement of a business objective? Is the technology available today?Is the technology available today? How will the technology change the way business is conducted?How will the technology change the way business is conducted? What are the direct and indirect costs?What are the direct and indirect costs?

14  Establish the business-level modeling Business OrganizationBusiness Organization Business functionsBusiness functions Data objectsData objects

15 Organization & Functions

16 Relationship among business-level data objects

17

18 Business Area Analysis (BAA)  Data models  Process flow models  Process decomposition diagrams  A variety of cross reference matrices

19

20

21 Product Engineering  Goal – to translate the customer’s desire for a set of defined capabilities into a working product.  Components SoftwareSoftware HardwareHardware DataData PeoplePeople

22

23 Requirements Engineering  Objectives Understanding what the customer wantsUnderstanding what the customer wants Analyzing needAnalyzing need Assessing feasibilityAssessing feasibility Negotiating a reasonable solutionNegotiating a reasonable solution Specifying the solution unambiguouslySpecifying the solution unambiguously Validating the specificationValidating the specification Managing the requirements as they are transformed into an operational systemManaging the requirements as they are transformed into an operational system

24 Requirements Engineering  Process Elicitation — determining what the customer requiresElicitation — determining what the customer requires Analysis & negotiation — understanding the relationships among various customer requirements and shaping those relationships to achieve a successful resultAnalysis & negotiation — understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result Requirements specification — building a tangible model of requirementsRequirements specification — building a tangible model of requirements

25 System Modeling — building a representation of requirements that can be assessed for correctness, completeness, and consistencySystem Modeling — building a representation of requirements that can be assessed for correctness, completeness, and consistency Validation — reviewing the specificationValidation — reviewing the specification Management — identify, control and track requirements and the changes to requirementsManagement — identify, control and track requirements and the changes to requirements

26 Requirements Elicitation  Why requirements elicitation is difficult? Problems of scopeProblems of scope Problems of understandingProblems of understanding Problems of volatilityProblems of volatility

27  Requirements elicitation guidelines Assess the business and technical feasibility.Assess the business and technical feasibility. Identify the people who will help specify requirements and understand their organizational bias.Identify the people who will help specify requirements and understand their organizational bias. Define the technical environment into which the system or product will be placed.Define the technical environment into which the system or product will be placed. Identify “domain constraints”.Identify “domain constraints”. Define requirements elicitation methods.Define requirements elicitation methods. Solicit participation from many people.Solicit participation from many people. Identify ambiguous requirements as candidates for prototyping.Identify ambiguous requirements as candidates for prototyping. Create usage scenarios to help customers/users better identify key requirements.Create usage scenarios to help customers/users better identify key requirements.

28  This work products A statement of need and feasibilityA statement of need and feasibility A bounded statement of scope for the system or productA bounded statement of scope for the system or product A list of customers, users, and other stakeholders who participated in the requirements elicitation activity.A list of customers, users, and other stakeholders who participated in the requirements elicitation activity. A description of the system’s technical environment.A description of the system’s technical environment. A list of requirements and the domain constraints that apply to each.A list of requirements and the domain constraints that apply to each. A set of usage scenarios that provide insight into the use of the system or product.A set of usage scenarios that provide insight into the use of the system or product. Any prototypes developed to better define requirements.Any prototypes developed to better define requirements.

29 Requirements Analysis and Negotiation  Categorize and organize requirements into related subsets  Explore each requirement in relationship to others  Examines requirement for consistency, omissions, and ambiguity  Rank requirements based on the needs of customers/users

30 Requirements Analysis and Negotiation  Is each requirement consistent with the overall objective for the system/product?  Have all requirements been specified at the proper level of abstraction?  Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?  Is each requirement bounded and unambiguous?  Does each requirement have attribution?  Do any requirements conflict with other requirements?  Is each requirement achievable in the technical environment that will house the system or product?  Is each requirement testable, once implemented?

31 System Modeling  Building a representation of requirements that can be assessed for correctness, completeness, and consistency.

32 Requirements Validation  Examine the specification  Discover the requirements errors

33 Requirements Management  Traceability Table Features traceability tableFeatures traceability table Source traceability tableSource traceability table Subsystem traceability tableSubsystem traceability table Interface traceability tableInterface traceability table

34 System Specification

35 System Modeling Product Architecture Template

36 System Context Diagram for CLSS

37 Architecture Flow Diagram for CLSS

38 System Flow Diagram (SFD)