SE chapters 6-7
Upcoming SlideShare
Loading in...5

SE chapters 6-7






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

SE chapters 6-7 SE chapters 6-7 Presentation Transcript

  • Chapter 6 System Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman
  • System Engineering
    • Elements of a computer-based system
      • Software
      • Hardware
      • People
      • Database
      • Documentation
      • Procedures
    • Systems
      • A hierarchy of macro-elements
  • The Hierarchy
  • 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.
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • The BAA Process sales acct manufacturing QC eng’ring distribution admin. Data Model Process Decomposition Diagram Matrices e.g., entity/process matrix Process Flow Models
  • Product Engineering
  • Product Architecture Template
  • Architecture Flow Diagram
  • 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
  • Deployment Diagram
  • Activity Diagram
  • Class Diagram
  • 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
  • Chapter 7 Requirements Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman
  • Requirements Engineering
    • Inception —Establish a basic understanding of the problem and the nature of the solution.
    • Elicitation —Draw out the requirements from stakeholders.
    • Elaboration —Create an analysis model that represents information, functional, and behavioral aspects of the requirements.
    • 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.
  • 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?
  • 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
  • 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.
  • 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.
  • 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.
  • 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 and associated domain constraints .
    • List of usage scenarios .
    • Any prototypes developed to refine requirements .
  • 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 might be considered as the story is described?
      • What variations in the actor’s 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?
  • 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)
  • Use-Case Diagram
  • Activity Diagram for RE
  • Class Diagram
  • State Diagram
  • 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.
  • 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”
  • 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 system’s technical environment ?
    • Is each requirement testable , once implemented?
    • Does the model reflect the system’s information, function and behavior ?
    • Has the model been appropriately “partitioned” ?
    • Have appropriate requirements patterns been used?
  • 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.
  • 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.
  • 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, …
  • 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.