Chapter 6 System Engineering

Software Engineering: A Practitioner’s Approach, 6th edition

by Roger S. Pressman

1

 

System Engineering

Elements of a computer-based system       Software Hardware People Database Documentation Procedures Systems  A hierarchy of macro-elements 2

The Hierarchy

3

System Modeling

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

explicitly define both exogenous and endogenous input to the model.

 exogenous inputs link one constituent of a given view with other constituents at the same level of other levels; endogenous input links individual components of a constituent at a particular view.

represent all linkages (including output) that will enable the engineer to better understand the view.

4

Business Process Engineering

 uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise  focuses first on the enterprise and then on the business area  creates enterprise models, data models and process models  creates a framework for better information management distribution, and control 5

System Architectures

    Three different architectures must be analyzed and designed within the context of business objectives and goals:  data architecture  applications architecture  technology infrastructure

data architecture

provides a framework for the information needs of a business or business function

application architecture

system that transform objects within the data architecture for some business purpose encompasses those elements of a

technology infrastructure

provides the foundation for the data and application architectures 6

The BPE Hierarchy

    Information strategy planning (ISP)  strategic goals defined  success factors/business rules identified  enterprise model created Business area analysis (BAA)  processes/services modeled  interrelationships of processes and data Application Engineering  a.k.a ... software engineering  modeling applications/procedures that address (BAA) and constraints of ISP Construction and delivery  using CASE and 4GTs, testing 7

Information Strategy Planning

 

Management issues

 define strategic business goals/objectives  isolate critical success factors  conduct analysis of technology impact  perform analysis of strategic systems

Technical issues

 create a top-level data model  cluster by business/organizational area  refine model and clustering 8

  

Defining Objectives and Goals

Objective — general statement of direction Goal — defines measurable objective: “ reduce manufactured cost of our product ” 

Subgoals :

 decrease reject rate by 20% in first 6 months  gain 10% price concessions from suppliers  re-engineer 30% of components for ease of manufacture during first year Objectives tend to be strategic while goals tend to be tactical 9

  

Business Area Analysis

define “ naturally cohesive groupings of business functions and data ” (Martin) perform many of the same activities as ISP, but narrow scope to individual business area identify existing (old) information systems / determine compatibility with new ISP model  define systems that are problematic  defining systems that are incompatible with new information model  begin to establish re-engineering priorities 10

The BAA Process

admin.

manufacturing

sales QC acct distribution eng’ring Process Flow Models Data Model Process Decomposition Diagram Matrices e.g., entity/process matrix 11

Product Engineering

12

Product Architecture Template

13

Architecture Flow Diagram

14

System Modeling with UML

 Deployment diagrams  Each 3-D box depicts a hardware element that is part of the physical architecture of the system  Activity diagrams  Represent procedural aspects of a system element  Class diagrams  Represent system level elements in terms of the data that describe the element and the operations that manipulate the data

These and other UML models will be discussed later

15

Deployment Diagram

CLSS processor Sort ing subsyst em Operat or display Sensor dat a acquisit ion subsyst em shunt cont roller Conveyor Pulse t ach Bar code reader Shunt act uat or 16

Activity Diagram

st a rt c o n v e y o r l i n e g e t c o n v e y o r sp e e d re a d b a r c o d e v alid bar c ode inv alid bar c ode d e t e r m i n e b i n l o c a t i o n se t f o r re j e c t b i n se n d sh u n t c o n t ro l d a t a g e t sh u n t st a t u s re a d b a r c o d e g e t c o n v e y o r st a t u s p ro d u c e re p o rt e n t ry c onv ey or s t opped c onv ey or in m ot ion 17

Class Diagram

class name Box barcode forwardSpeed conveyorLocat ion height widt h dept h weight cont ent s readBarcode( ) updat eSpeed ( ) readSpeed( ) updat eLocat ion( ) readLocat ion( ) get Dimensions( ) get Weight( ) checkCont ent s( ) at t ribut es not e use of capit al let t er f or mult i-word at t ribut e names operat ions ( parent heses at end of name indicat e t he list of at t ribut es t hat t he operat ion requires) 18

 

System Engineering

A system view of a product encompasses more than just the software.

    Elements of a computer-based system:    Software Hardware People Database Documentation Procedures Other computer-based systems 19

Chapter 7 Requirements Engineering

Software Engineering: A Practitioner’s Approach, 6th edition

by Roger S. Pressman

20

Requirements Engineering

       Inception — Establish a basic understanding of the problem and the nature of the solution. Elicitation — Draw out the requirements from stakeholders.

Elaboration — requirements.

Create an analysis model that represents information, functional, and behavioral aspects of the Negotiation — Agree on a deliverable system that is realistic for developers and customers.

Specification — Describe the requirements formally or informally.

Validation — Review the requirement specification for errors, ambiguities, omissions, and conflicts. Requirements management — Manage changing requirements.

21

Inception

 Ask “ context-free ”    questions Who is behind the request for this work?

Who will use the solution (product/system)?

What will be the economic benefits?

   How would you characterize “ good ” system?

output from the What problems does this solution address?

What environment will the product be used in?

    Are you the right person to answer these questions?

Are these question relevant?

Can anyone else provide additional information?

Should I be asking you anything else?

22

Getting Requirements Right

 “ The hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

” — Fred Brooks  “ The seeds of major software disasters are usually sown within the first three months of commencing the software project.

” — Capers Jones  “ We spend a lot of time — the majority of project effort — not implementing or testing, but trying to decide what to build.

” — Brian Lawrence 23

Eliciting Requirements

 Why is it so difficult to clearly understand what the customer wants?

 Scope   The boundary of the system is ill-defined.

Customers/users specify unnecessary technical detail that may confuse rather than clarify objectives.

 Understanding  Customers are not completely sure of what is needed.

 Customers have a poor understanding of the capabilities and limitations of the computing environment.

Customers don ’ t have a full understanding of their problem domain.

     Customers have trouble communicating needs to the system engineer.

Customers omit detail that is believed to be obvious.

Customers specify requirements that conflict with other requirements.

Customers specify requirements that are ambiguous or untestable.

 Volatility  Requirements change over time.

24

Collaborative Requirements Gathering

      Meetings are attended by all interested stakeholders.

Rules established for preparation and participation.

Agenda should be formal enough to cover all important points, but informal enough to encourage the free flow of ideas.

A facilitator controls the meeting.

A definition mechanism (blackboard, flip charts, etc.) is used.

During the meeting:  The problem is identified.

    Elements of the solution are proposed.

Different approaches are negotiated.

A preliminary set of solution requirements are obtained.

The atmosphere is collaborative and non-threatening. 25

Quality Function Deployment

    Function deployment determines the “ value ” (to the customer) of each function required of the system.

Information deployment objects and events.

identifies data Task deployment the system.

examines the behavior of Value analysis requirements.

determines the priority of 26

      

Elicitation Work Products

Statement of need and feasibility .

Statement of scope .

List of participants in requirements elicitation.

Description of the system ’ s technical environment .

List of requirements constraints .

and associated domain List of usage scenarios .

Any prototypes requirements

.

developed to refine 27

  

Use-Cases

A use-case scenario is a story about how someone or something external to the software (known as an actor ) interacts with the system.

Each scenario answers the following questions: Who is the primary actor , the secondary actor(s)?

      What are the actor ’ s goals ?

What preconditions should exist before the story begins?

What main tasks or functions are performed by the actor?

What exceptions What variations might be considered as the story is described?

in the actor ’ s interaction are possible?

What system information change? will the actor acquire, produce, or  Will the actor have to inform the system external environment?

about changes in the   What information does the actor desire from the system ?

Does the actor wish to be informed about unexpected changes?

28

Elements of the Analysis Model

 Scenario-based  elements Use-case — How external actors interact with the system (use-case diagrams; detailed templates)  Functional — How software functions are processed in the system (flow charts; activity diagrams)  Class-based  elements The various system objects (obtained from scenarios) including their attributes and functions (class diagram)  Behavioral  elements How the system behaves in response to different events (state diagram)  Flow-oriented  elements How information is transformed as if flows through the system (data flow diagram) 29

Use-Case Diagram

30

Activity Diagram for RE

31

Class Diagram

32

State Diagram

33

Analysis Patterns

Pattern name: Captures the essence of the pattern. Intent: What the pattern accomplishes or represents. Motivation: A scenario that illustrates how the pattern solves a problem.

Forces and context: External issues (forces) that affect how the pattern is used, and external issues resolved when the pattern is applied. Solution: How the pattern is applied to solve the problem; emphasizes structural and behavioral issues.

Consequences : What happens when the pattern is applied; what trade-offs exist during its application.

Design : How the pattern can be achieved via known design patterns.

Known uses : Examples of uses within actual systems.

Related patterns : Patterns related to the named pattern because (1) (2) (3) they are commonly used with the named pattern; they are structurally similar to the named pattern; they are a variation of the named pattern.

34

Negotiating Requirements

   Identify the key stakeholders  These are the people who will be involved in the negotiation Determine each of the stakeholders “ win conditions ”  Win conditions are not always obvious Negotiate  Work toward a set of requirements that lead to “ win-win ” 35

Validating Requirements

          Is each requirement consistent with the objective system?

of the Have all requirements been specified at the proper level of abstraction ? Is the requirement really necessary ?

Is each requirement bounded and unambiguous ?

Does each requirement have attribution ? Do any requirements conflict with other requirements ?

Is each requirement achievable in the system ’ s technical environment ?

Is each requirement testable , once implemented?

Does the model reflect the system ’ s information, function and behavior ?

36 Has the model been appropriately “ partitioned ” ?

Example CRG Meeting

 First CRG meeting of the

SafeHome

 project.

After Q&A session (inception meeting), stakeholders write a two page product request , which is delivered to those attending the first CRG meeting.

 Attendees are asked to make a rough list of objects , services , constraints , and performance criteria for the product.

   At the meeting, a combined list is created in each topic.

Subgroups write mini-specifications for each list item.

Relevant features in mini-specifications are added to the list.

37

 

Example CRG Meeting

Our research indicates that the market for home management systems is growing at a rate of 40 percent per year. The first

SafeHome

function we bring to market should be the home security function . Most people are familiar with “ alarm systems ” so this would be an easy sell.

The home security function would protect against and/or recognize a variety of undesirable “ situations ” such as illegal entry , fire , flooding , carbon monoxide levels , and others . It ’ ll use our wireless sensors to detect each situation, can be programmed by the homeowner , and will automatically telephone a monitoring agency when a situation is detected.

38

   

Example CRG Meeting

Objects sensors, motion detectors, an alarm, an event (sensor has been activated), a display, a PC, telephone numbers, a telephone call, … – control panel, smoke detectors, window and door Services – configuring the system, setting the alarm, monitoring the sensors, dialing the phone, programming the control panel, reading the display, … Constraints – System must recognize when sensors are not operating, must be user friendly, must interface directly to a standard phone line, … Performance criteria implemented, … – Sensor event should be recognized within one second, an event priority scheme should be 39

Example CRG Meeting

 Mini-specification for Control Panel  The Control Panel is a wall-mounted unit that is approximately 9 x 5 inches in size. The control panel has wireless connectivity to sensors and a PC. User interaction occurs through a keypad containing 12 keys. A 2 x 2 inch LCD display provides user feedback. Software provides interactive prompts, echo, and similar functions.

40