1 / 86

Computing and SE II Chapter 5: Requirements Analysis

Computing and SE II Chapter 5: Requirements Analysis. Er-Yu Ding Software Institute, NJU. Main Contents. Models of Requirement Analysis Structural Analysis: Entity-Relationship Diagram Structural Analysis: Data Flow Diagram Structural Analysis: State Transition Diagram

genera
Download Presentation

Computing and SE II Chapter 5: Requirements Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computing and SE II Chapter 5: Requirements Analysis Er-Yu Ding Software Institute, NJU

  2. Main Contents Models of Requirement Analysis Structural Analysis: Entity-Relationship Diagram Structural Analysis: Data Flow Diagram Structural Analysis: State Transition Diagram Object-Oriented Analysis: Use Case Diagram Object-Oriented Analysis: Class Diagram Object-Oriented Analysis: Behavioral Diagram Object-Oriented Analysis: CRC Card Writing the Software Specification

  3. 1. Models of Requirement Analysis——Requirements analysis Outcome of Analysis 现实世界 计算世界 用户模型 分析模型 计算模型 Analysis

  4. 1. Models of Requirement Analysis——The Analysis Model Describe what the customer wants built Establish the foundation for the software design Provide a set of validation requirements System Description Design Model Analysis Model The analysis model consists of a wide variety of diagrammatic forms used to bridge an important gap. • System information • System function • System behaviors Purpose:

  5. 1. Models of Requirement Analysis—— Model What is a model? a model is a simplification of reality Why do we model? we build models so that we can better understand the system we are developing we build models of complex systems because we cannot comprehend such a system in its entirety four aims to achieve help us to visualize a system permit us to specify the structure/behavior of a system give us a template that guides us in constructing systems document the decisions we have made

  6. 1. Models of Requirement Analysis—— Software Model A model is an abstract representation of a system that enables us to answer questions about the system. When we represent it with real world language, it’s user model When we represent it with computing world language, it’s design model When we represent it with codes, it’s program model When we represent it with a neutral, formal language, it’s analysis model …

  7. 1. Models of Requirement Analysis—— How to represent software model? Describes necessary and complete knowledge Stakeholders can get what they want Decision makers Users ,clients… Developers Analyst Designer Programmer Integrator Developers can develop software according to software model Data, behavior, business rules…

  8. 1. Models of Requirement Analysis—— Model and View Model, views, viewpoints, and stakeholders A model is a simplification of reality, created in order to better understand the system being created; a semantically closed abstraction of a system A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or viewpoints relative to, a system A content type is an kind of information needed for software development

  9. 1. Models of Requirement Analysis—— Viewpoints, perspectives and views Viewpoint is defined as a standing position used by an individual when examining a universe of discourse (Stakeholders Roles) A perspective is defined as a set of facts observed and modelled according to a particular aspect of reality (Certain type content observed from some viewpoint) A view is defined as an integration of related perspectives, usually using two kinds of methods According to viewpoint (all perspectives observed by some stakeholders role on different content types) According to content type (all perspectives observed by different stakeholders on some content types)

  10. 1. Models of Requirement Analysis—— Describing Perspectives A perspective language is used to represent the observed information of the perspectives Text, Diagram (semi-formal language), Formal Language… The language defines the set of units and their associations that can be used to describe perspectives Languages N:Mperspectives There is no semi-formal or formal language can describe all kinds of perspectives

  11. 1. Models of Requirement Analysis—— Common Perspectives Languages UML Object diagram Classification model Behavioral diagram OCL Use case diagram Entity-Relationship Diagram Composition( semantic data) model Process Model (DFD) Data processing model State Machine Model Stimulus/response model • Fact Model • Entity-event model • Object Role Model • Organization model • Petri Nets • ……

  12. 1. Models of Requirement Analysis——Analysis Model– Structural Process specification (PSPEC) Function Data Object description ERD DFD Data dictionary Data STD Behavior Control Specification (CSPEC)

  13. 1. Models of Requirement Analysis—— OO Analysis Model - UML Function Class diagram Object diagram Use case diagram Activity diagram Object Data Behavior State-chart diagram Interaction diagram

  14. 2. Structural Analysis: Entity-Relationship Diagram——Data Modeling Automobile Person • Examines data objects independently of processing • Focuses attention on the datadomain • Creates a model at the customer’s level of abstraction • Indicates how data objects relate to one another Make Model Body type Price Color Birthday Height Weight Expertise

  15. 2. Structural Analysis: Entity-Relationship Diagram—— What is a Data Object? Object —something that is described by a set of attributes (data items) and that will be manipulated within the software (system) each instance of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) each plays a necessary role in the system i.e., the system could not function without access to instances of the object each is described by attributes that are themselves data items

  16. 2. Structural Analysis: Entity-Relationship Diagram——Typical Objects Automobile Person external entities (printer, user, sensor) things (e.g, reports, displays, signals) occurrences or events (e.g., interrupt, alarm) roles (e.g., manager, engineer, salesperson) (e.g., division, team) organizational units places (e.g., manufacturing floor) structures (e.g., employee record)

  17. 2. Structural Analysis: Entity-Relationship Diagram—— Data Objects and Attributes Automobile Person A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object Make Model Body type Price Color Birthday Height Weight Expertise

  18. 2. Structural Analysis: Entity-Relationship Diagram——Relationship • Connectedness • A fact that must be remembered by the system and cannot or is not computed or derived • Several instance of a relationship can exist • Entity can be related in many ways own

  19. 2. Structural Analysis: Entity-Relationship Diagram——Cardinality and Multiplicity own Automobile Person own Make Model Body type Price Color Birthday Height Weight Expertise

  20. 2. Structural Analysis: Entity-Relationship Diagram—— ERD Notation One common form: (0, m) object object relationship 1 2 (1, 1) attribute Another common form: relationship object object 1 2 (1, 1) (0, m) attribute

  21. 2. Structural Analysis: Entity-Relationship Diagram——The ERD: An Example request for service Customer places (1,1) (1,m) (1,1) standard task table (1,n) work order generates (1,1) (1,1) (1,1) (1,w) work tasks selected from consists of (1,w) (1,i) materials lists

  22. 2. Structural Analysis: Entity-Relationship Diagram——Building an ERD Level 1—model all data objects (entities) and their “connections” to one another Level 2—model all entities and relationships Level 3—model all entities, relationships, and the attributes that provide further depth

  23. 2. Structural Analysis: Entity-Relationship Diagram——ERD- Let’s try it 为选课系统建立ERD描述

  24. 3. Structural Analysis: Data Flow Diagram——Flow Oriented Model Represents how data objects are transformed at they move through the system A data flow diagram (DFD) is the diagrammatic form that is used Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to provide a view of the system that is unique—it should be used to supplement other analysis model elements

  25. 3. Structural Analysis: Data Flow Diagram—— The Flow Model Every computer-based system is an information transform .... computer based system input output

  26. 3. Structural Analysis: Data Flow Diagram—— Flow Modeling Notation external entity process data flow data store

  27. 3. Structural Analysis: Data Flow Diagram—— External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something

  28. 3. Structural Analysis: Data Flow Diagram—— Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function

  29. 3. Structural Analysis: Data Flow Diagram—— Data Flow Data flows through a system, beginning as input and be transformed into output. base compute triangle area area height

  30. 3. Structural Analysis: Data Flow Diagram——Data Stores Datais often stored for later use. sensor # sensor #, type, location, age look-up sensor data report required type, location, age sensor number sensor data

  31. all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic 3. Structural Analysis: Data Flow Diagram—— Data Flow Diagramming

  32. 3. Structural Analysis: Data Flow Diagram——Level 0 (Context Diagram) processing request user requested video signal digital video processor monitor video source NTSC video signal

  33. 3. Structural Analysis: Data Flow Diagram——Constructing a DFD—I review the descriptions and use a grammatical parse to determine “operations” determine external entities (producers and consumers of data) create a level 0 DFD

  34. write a narrative describing the transform parse to determine next level transforms “balance” the flow to maintain data flow continuity develop a level 1 DFD 3. Structural Analysis: Data Flow Diagram——Constructing a DFD—Refine Process

  35. 3. Structural Analysis: Data Flow Diagram——Level 1 c p2 a f p1 b p4 d 5 g p3 e level 1 a b P x y level 0

  36. Each bubble is refined until it does just one thing The expansion ratio decreases as the number of levels increase Most systems require between 3 and 7 levels for an adequate flow model 3. Structural Analysis: Data Flow Diagram——Flow Modeling Notes

  37. 3. Structural Analysis: Data Flow Diagram——Using PSPEC Process Specification (PSPEC) can be used to specify the processing details implied by a process within a DFD bubble PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts

  38. 3. Structural Analysis: Data Flow Diagram——Using PSPEC Check & convert pressure PSPEC If absolute tank pressure > max pressure then set above pressure to “true”; else set above pressure to “false”; begin conversion algorithm x-01a; compute converted pressure; end end if

  39. 3. Structural Analysis: Data Flow Diagram——Mapping to design model analysis model Maps into design model

  40. 3. Structural Analysis: Data Flow Diagram—— DFD- Let’s try it 用DFD描述ATM机的功能

  41. 4. Structural Analysis: State Transition Diagram——Behavioral modeling The behavioral model indicates how software will respond to external events or stimuli. events behavior Outside world Application How do I model the software's reaction to some external event?

  42. State: a set of observable circum-stances that characterizes the behavior of a system at a given time State transition: the movement from one state to another Event: an occurrence that causes the system to exhibit some predictable form of behavior Action: process that occurs as a consequence of making a transition 4. Structural Analysis: State Transition Diagram—— Basic concept

  43. Make a list of the different states of a system (How does the system behave?) Indicate how the system makes a transition from one state to another (How does the system change state?) indicate event indicate action Draw a state transition diagram 4. Structural Analysis: State Transition Diagram——State Modeling

  44. 4. Structural Analysis: State Transition Diagram——Notation and Example Increment Hours button2Pressed button1&2Pressed Blink Hours button1Pressed Increment Minutes button2Pressed button1&2Pressed Blink Minutes button1Pressed Increment Seconds button2Pressed Blink Stop Seconds Blinking State Event Initial state Transition button1&2Pressed Final state

  45. 4. Structural Analysis: State Transition Diagram—— State Diagram - Lets Try It! North You are designing a traffic light system for this intersection. Draw a state diagram showing the different states and how they transition. West East South

  46. 5. Object-Oriented Analysis: Use Case Diagram—— Use-Cases A scenario that describes a thread of usage for achieving a functional requirement Actors represent roles people, devices, or external systems play System internals are ignored “[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).” –Ivar Jacobson Key Points: Example: See Pressman Chapter 8, Section 8.5.1

  47. 5. Object-Oriented Analysis: Use Case Diagram—— The Key Elements of a Use-Case A descriptive name for the scenario e.g., “Customer Checkout”, “Browse Products” The primary actor in the scenario Who is interacting with the system? The primary actor’s goal What is the actor trying to accomplish? Scenario pre-conditions What assumptions are being made? Scenario trigger How was the scenario initiated? The “sunny day” scenario In the best case, how does the user interact with the system? Exceptions What might go wrong? Remember why we’re interested in use-cases!

  48. 5. Object-Oriented Analysis: Use Case Diagram—— Developing a Use-Case (1) What should we write about? (2) How much should we write about it? (3) How detailed should we make our description? (4) How should we organize the description? What are the main tasks or functions that are performed by the actor? What system information will the actor acquire, produce or change? Will the actor have to inform the system about changes in the external environment? Does the actor wish to be informed about unexpected changes? …

  49. 5. Object-Oriented Analysis: Use Case Diagram——Use Case Diagram - Let’s Try It The Online Bookstore The Online Bookstore System (OBS) will be a web-based application that allows customers to browse and purchase online product offerings. The application will support the notion of an online shopping cart, similar to other online retailers such as Amazon.com. The checkout features of the system will be integrated with our credit card transaction processor, as well as our internal billing system. The system will also provide an administrator-view that will allow authorized employees to view and administer products, customers, and orders. • Based on this description, what are the key use-cases? • Select one key use-case, describes it.

More Related