1. 1 Lecture 3 Requirement Analysis System Analysis Concepts Modeling Techniques

2. 2 Disclaimer and Copyright Notice This work is subject to copyright. All rights are reserved. This course material is developed in conjunction with the courseware of Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001. The material provided is for reference only. It should not be redistributed with prior written consent. Proceeding beyond this notice implies willingness to comply with the terms.

3. 3 The Hierarchy

4. 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. 5 The BPE Hierarchy  Information strategy planning – strategic goals defined – success factors/business rules identified – enterprise model created  Business area analysis – processes/services modeled – interrelationships of processes and data  Business system design – modeling information systems/procedures that address BAA and constraints of ISP – Translate requirement into data architecture, applications architecture and technology infrastructure  Construction and delivery – using CASE and 4GTs, testing

6. 6 Product Engineering

7. 7 Requirement Engineering

8. 8 Elicitation  Determining what the customer requires  Problems of scope, understanding and volatility Assess project feasibility Assess project feasibility Identify key person(s) Identify key person(s) Get user commitment Get user commitment Identify environment Identify environment Define elicitation methods Define elicitation methods Identify ambiguous requirements Identify ambiguous requirements Create usage scenarios Create usage scenarios  Statement of need and feasibility  Statement of scope  List of participants  Description of technical environment  List of requirements and constraints  Set of usage scenarios

9. 9 Analysis & negotiation  understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result  Consistent  Right level of detail  Necessary  Bounded and clear  Traceable to the source  Conflicts  Achievable  Testable

10. 10 Other Steps  Requirements specification — building a tangible model of requirements, the basis for product development for all parties involved  System Modeling — building a representation of requirements that can be assessed for correctness, completeness, and consistency  Validation — reviewing the model  Management — identify, control and track requirements and the changes that will be made to them – Traceability tables: features, source, dependency, subsystem and system interface

11. 11 Product Architecture Template

12. 12 Architecture Flow Diagram

13. 13 Systems Analysis Concepts

14. 14 Requirements Gathering Facilitated Application Specification Techniques SoftwareEngineeringGroup CustomerGroup

15. 15 FAST Guidelines  participants must attend entire meeting  all participants are equal  preparation is as important as meeting  all pre-meeting documents are to be viewed as “proposed”  off-site meeting location is preferred  set an agenda and maintain it  don’t get mired in technical detail J. Wood & D. Silver

16. 16 Quality Function Deployment  Function deployment determines the “value” (as perceived by 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 relative priority of requirements

17. 17 Use-cases  A collection of scenarios that describe the thread of usage of a system  Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way  Each scenario answers the following questions: – What are the main tasks of functions performed by the actor? – What system information will the actor acquire, produce or change? – Will the actor inform the system about environmental changes? – What information does the actor require of the system? – Does the actor wish to be informed about unexpected changes – What are the main tasks of functions performed by the actor? – What system information will the actor acquire, produce or change? – Will the actor inform the system about environmental changes? – What information does the actor require of the system? – Does the actor wish to be informed about unexpected changes

18. 18 The Analysis Process the problem requirementselicitation build a prototype createanalysismodels develop Specification Review

19. 19 Analysis Principle I Model the Data Domain  define data objects  describe data attributes  establish data relationships  define data objects  describe data attributes  establish data relationships  content and relationship  flow  structure

20. 20 Analysis Principle II Model Function  identify functions that transform data objects  indicate how data flow through the system  represent producers and consumers of data  an iterative process  identify functions that transform data objects  indicate how data flow through the system  represent producers and consumers of data  an iterative process

21. 21 Analysis Principle III Model Behavior  indicate different states of the system  specify events that cause the system to change state  indicate different states of the system  specify events that cause the system to change state

22. 22 Analysis Principle IV Partition the Models  refine each model to represent lower levels of abstraction  refine data objects  create a functional hierarchy  represent behavior at different levels of detail  refine each model to represent lower levels of abstraction  refine data objects  create a functional hierarchy  represent behavior at different levels of detail

23. 23 Analysis Principle V Essence  begin by focusing on the essence of the problem without regard to implementation details

24. 24 Davis’ Principles  Understand the problem before you begin to create the analysis model.  Develop prototypes that enable a user to understand how human-machine interaction will occur.  Record the origin of and the reason for every requirement.  Use multiple views of requirements.  Prioritize requirements.  Work to eliminate ambiguity.

25. 25 The Analysis Model Data Model Behavioral Model Functional Model

26. 26 Analysis Modeling

27. 27 Where to Begin?  A statement of scope can be acquired from: – the FAST working document – A set of use-cases  the statement of scope must be “parsed” to extract data, function and behavioral domain information

28. 28 Statement of Scope  a relatively brief description of the system to be built – indicates data that are input and output and basic functionality – indicates conditional processing (at a high level) – implies certain constraints and limitations

29. 29 Identifying Objects and Operations  define “objects” - nouns in the written statement of scope producers/consumers of data places where data are stored “composite” data items  define “operations” - by active verbs processes relevant to the application data transformations  consider other “services” that will be required by the objects

30. 30 Elements of an Analysis Model Data Dictionary Entity Relationship Diagram Data Flow Diagram State-transition Diagram Data Object Description Process Specification (PSPEC) Control Specification (CSPEC)

31. 31 Data Modeling and Entity Relationship Diagramming

32. 32 Why Data Modeling?  examines data objects independently of processing  focuses attention on the data domain  creates a model at the customer’s level of abstraction  indicates how data objects relate to one another

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

34. 34 Typical Objects  external entities (printer, user, sensor)  things (e.g., reports, displays, signals)  occurrences or events (e.g., interrupt, alarm)  roles (e.g., manager, engineer, salesperson)  organizational units (e.g., division, team)  places (e.g., manufacturing floor)  structures (e.g, employee record)

35. 35 Data Objects and Attributes A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object object: automobile attributes: make make model model body type body type price price options code options code object: automobile attributes: make make model model body type body type price price options code options code

36. 36 What Is a Relationship?  several instances of a relationship can exist  objects can be related in many different ways  several instances of a relationship can exist  objects can be related in many different ways relationship – indicates “connectedness”’; a “fact” that must be “remembered” by the system and cannot or is not computed or derived mechanically

37. 37 ERD Notation object 1 object 2 (0, m) (1, 1) object 1 relationship One common form: (0, m) (1, 1) relationship Another common form: attributes

38. 38 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  Other ERD – data object type hierarchy, associated data object  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  Other ERD – data object type hierarchy, associated data object

39. 39 The ERD: An Example (1,1) (1,m) places Customer request for service generates (1,n) (1,1) workorder worktasks materials Consistsof lists (1,1) (1,w) (1,1) (1,i) selectedfrom standard task table (1,w) (1,1)

40. 40 Creating a Flow Model

41. 41 The Flow Model Every computer-based system is an information transform.... computerbasedsystem input output

42. 42 Flow Modeling Notation external entity process data flow data store

43. 43 External Entity A producer or consumer of data Examples: a person, a device, a sensor or computer-based system Data must always originate somewhere and must always be sent to something

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

45. 45 Data Flow Data flows through a system, beginning as input and be transformed into output. computetriangleareabaseheight area

46. 46 Data Stores Data is often stored for later use. look-upsensordata sensor # report required sensor #, type, location, age sensor data sensor number type, location, age

47. 47 DFD Guidelines  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

48. 48 Constructing a DFD—I  review ERD to isolate data objects and grammatical parse to determine “operations”  determine external entities (producers and consumers of data)  create a level 0 DFD (fundamental system model, context model)

49. 49 Level 0 DFD Example userprocessingrequestvideosource NTSC video signal digitalvideoprocessor requestedvideosignal monitor

50. 50 Constructing a DFD—II  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  use a 1:5 (approx.) expansion ratio

51. 51 The Data Flow Hierarchy P a b xy p1 p2 p3 p4 5 a b c d e f g level 0 level 1

52. 52 Flow Modeling Notes  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  a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)

53. 53 DFDs: A Look Ahead Maps into analysis model design model