Chapter 6 System Engineering

1
Chapter 6System Engineering
Software Engineering A Practitioners Approach,
6th edition by Roger S. Pressman
2
System Engineering

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

3
The Hierarchy
4
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.

5
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

6
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 encompasses those
  elements of a system that transform objects
  within the data architecture for some business
  purpose
• technology infrastructure provides the foundation
  for the data and application architectures

7
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

8
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

9
Defining Objectives and Goals

• Objectivegeneral statement of direction
• Goaldefines 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

10
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

11
The BAA Process
admin.
manufacturing
QC
distribution
sales
acct
engring
Process Decomposition Diagram
Matrices e.g., entity/process matrix
Process Flow Models
Data Model
12
Product Engineering
13
Product Architecture Template
14
Architecture Flow Diagram
15
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

16
Deployment Diagram
17
Activity Diagram
18
Class Diagram
19
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

20
Chapter 7Requirements Engineering
Software Engineering A Practitioners Approach,
6th edition by Roger S. Pressman
21
Requirements Engineering

• InceptionEstablish a basic understanding of the
  problem and the nature of the solution.
• ElicitationDraw out the requirements from
  stakeholders.
• ElaborationCreate an analysis model that
  represents information, functional, and
  behavioral aspects of the requirements.
• NegotiationAgree on a deliverable system that is
  realistic for developers and customers.
• SpecificationDescribe the requirements formally
  or informally.
• ValidationReview the requirement specification
  for errors, ambiguities, omissions, and
  conflicts.
• Requirements managementManage changing
  requirements.

22
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 output from the
  system?
• 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?

23
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 timethe majority of project
  effortnot implementing or testing, but trying to
  decide what to build.
• Brian Lawrence

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

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

26
Quality Function Deployment

• Function deployment determines the value (to
  the customer) of each function required of the
  system.
• Information deployment identifies data objects
  and events.
• Task deployment examines the behavior of the
  system.
• Value analysis determines the priority of
  requirements.

27
Elicitation Work Products

• Statement of need and feasibility.
• Statement of scope.
• List of participants in requirements elicitation.
• Description of the systems technical
  environment.
• List of requirements and associated domain
  constraints.
• List of usage scenarios.
• Any prototypes developed to refine requirements.

28
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 actors goals?
• What preconditions should exist before the story
  begins?
• What main tasks or functions are performed by the
  actor?
• What exceptions might be considered as the story
  is described?
• What variations in the actors interaction are
  possible?
• What system information will the actor acquire,
  produce, or change?
• Will the actor have to inform the system about
  changes in the external environment?
• What information does the actor desire from the
  system?
• Does the actor wish to be informed about
  unexpected changes?

29
Elements of the Analysis Model

• Scenario-based elements
• Use-caseHow external actors interact with the
  system (use-case diagrams detailed templates)
• FunctionalHow 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)

30
Use-Case Diagram
31
Activity Diagram for RE
32
Class Diagram
33
State Diagram
34
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
• they are commonly used with the named pattern
• they are structurally similar to the named
  pattern
• they are a variation of the named pattern.

35
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

36
Validating Requirements

• Is each requirement consistent with the objective
  of the system?
• 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 systems
  technical environment?
• Is each requirement testable, once implemented?
• Does the model reflect the systems information,
  function and behavior?
• Has the model been appropriately partitioned?
• Have appropriate requirements patterns been used?

37
Example CRG Meeting

• First CRG meeting of the SafeHome project.
• After QA 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.

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

39
Example CRG Meeting

• Objects control panel, smoke detectors, window
  and door sensors, motion detectors, an alarm, an
  event (sensor has been activated), a display, a
  PC, telephone numbers, a telephone call,
• 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 Sensor event should be
  recognized within one second, an event priority
  scheme should be implemented,

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