1 / 106

Requirements Analysis-1

Requirements Analysis-1. Last Update: Monday September 1, 2003. Contents. Requirements Analysis: “What” and “How” ?. Unified Process. OO Analysis and Design. Basics UML Actors, Use cases. Requirements Analysis [1]. What is it?.

curran-marquez
Télécharger la présentation

Requirements Analysis-1

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. Requirements Analysis-1 Last Update: Monday September 1, 2003 BITS C461/IS C341 Software Engineering

  2. Contents • Requirements Analysis: “What” and “How” ? • Unified Process • OO Analysis and Design • Basics • UML • Actors, Use cases BITS C461/IS C341 Software Engineering

  3. Requirements Analysis [1] • What is it? • The process by which customer needs are understood and documented. • Expresses “what” is to be built and NOT “how” it is to be built. • Example 1: • The system shall allow users to withdraw cash. [What?] • Example 2: • A sale item’s name and other attributes will be stored in a hash table and updated each time any attribute changes. [How?] BITS C461/IS C341 Software Engineering

  4. Requirements Analysis [2] • C- and D-Requirements • C-: Customer wants and needs; expressed in language understood by the customer. • D-: For the developers; may be more formal. BITS C461/IS C341 Software Engineering

  5. Requirements Analysis [3] Why document requirements? • Serves as a contract between the customer and the developer. • Serves as a source of test plans. • Serves to specify project goals and plan development cycles and increments. BITS C461/IS C341 Software Engineering

  6. Requirements Analysis [4] • Roadmap: • Identify the customer. • Interview customer representatives. • Write C-requirements, review with customer, and update when necessary. • Write D-requirements; check to make sure that there is no inconsistency between the C- and the D-requirements. BITS C461/IS C341 Software Engineering

  7. Requirements Analysis [5] • C-requirements: • Use cases expressed individually and with a use case diagram. A use case specifies a collection of scenarios. • Sample use case: Process sale. • Data flow diagram: • Explains the flow of data items across various functions. Useful for explaining system functions. [Example on the next slide.] • State transition diagram: • Explains the change of system state in response to one or more operations. [Example two slides later.] • User interface: Generally not a part of requirements analysis though may be included. BITS C461/IS C341 Software Engineering

  8. Employee Record Overtime rate Deduct taxes Get employee file Pay rate Company records Overtime pay * Pay * ID Issue paycheck * Regular hours Overtime hours Weekly pay Total pay Worker Net pay Tax rates Check Data Flow Diagram BITS C461/IS C341 Software Engineering

  9. EBP(e,f) EBOFF (e,f) EBON (e,f) EBP(e,f) State Transition Diagram (STD) Elevator example (partial): EBOFF (e,f): Elevator e button OFF at floor f. EBON (e,f): Elevator e button ON at floor f. EBP(e,f): Elevator e button f is pressed. BITS C461/IS C341 Software Engineering

  10. Requirements Analysis [6] • D-requirements: • Organize the D-requirements. • Create sequence diagrams for use cases: • Obtain D-requirements from C-requirements and customer. • Outline test plans • Inspect • Validate with customer. • Release: BITS C461/IS C341 Software Engineering

  11. Requirements Analysis [7] Organize the D-requirements: Functional requirements The blood pressure monitor will measure the blood pressure and display it on the in-built screen. Non-functional requirements Performance The blood pressure monitor will complete a reading within 10 seconds. Reliability The blood pressure monitor must have a failure probability of less than 0.01 during the first 500 readings. BITS C461/IS C341 Software Engineering

  12. Requirements Analysis [8] Interface requirements: interaction with the users and other applications The blood pressure monitor will have a display screen and push buttons. The display screen will…. Constraints: timing, accuracy The blood pressure monitor will take readings with an error less than 2%. BITS C461/IS C341 Software Engineering

  13. Requirements Analysis [9] Properties of D-requirements: • Traceability: Functional requirements D-requirement  inspection report  design segment  code segment  code inspection report  test plan  test report • Traceability: Non-Functional requirements • Isolate each non-functional requirement. • Document each class/function with the related non-functional requirement. BITS C461/IS C341 Software Engineering

  14. Requirements Analysis [10] • Testability It must be possible to test each requirement. Example ? • Categorization and prioritization..next slide BITS C461/IS C341 Software Engineering

  15. Prioritizing (Ranking) Use Cases • Strategy : • pick the use cases that significantly influence the core architecture • pick the use cases that are critical to the success of the business. • a useful rule of thumb - pick the use cases that are the highest risk!!! BITS C461/IS C341 Software Engineering

  16. Requirements Analysis [11] • Completeness Self contained, no omissions. • Error conditions State what happens in case of an error. How should the implementation react in case of an error condition? BITS C461/IS C341 Software Engineering

  17. Consistency of Requirements • Different requirements must be consistent. Example: R1.2: The speed of the vehicle will never exceed 250 mph. R5.4: When the vehicle is cruising at a speed greater than 300 mph, a special “watchdog” safety mechanism will be automatically activated. BITS C461/IS C341 Software Engineering

  18. OO Analysis and Design: Objectives • Compare and Contrast analysis and design • Define object-oriented analysis and design • Relate, by analogy, OO analysis and design to business organization. BITS C461/IS C341 Software Engineering

  19. What is Analysis and Design? • Analysis - investigation of the problem (what); • What does the system do? • Investigation of the problem. • Design - conceptual solution to fulfill the requirements (how); how will the system do what it is intended to do. • What (conceptual) solution will full the requirements BITS C461/IS C341 Software Engineering

  20. What is OO analysis and design? • Essence of OO analysis - consider a problem domain from the perspective of objects (real world things, concepts) • Essence of OO design - define the solution as a collection of software objects (allocating responsibilities to objects) BITS C461/IS C341 Software Engineering

  21. Examples • OO Analysis - in the case of library information systems, one would find concepts like book, library, patron • OO Design - emphasis on defining the software objects; ultimately these objects are implemented in some programming language; Book may have a method named print. BITS C461/IS C341 Software Engineering

  22. Representation in analysis of concepts Domain concept Book ______ title print() publicclass Book { publicvoidprint(); private stringtitle; } Representation in OO programming language Example - contd. BITS C461/IS C341 Software Engineering

  23. Digression: OO Concepts-Objects • http://java.sun.com/docs/books/tutorial/java/concepts/ • Objects: Anything that has a state and exhibits behavior. • Real world objects: Bicycle, student, course, dog, university,…. • Software objects: Model real-world or abstract objects (e.g. a list). • Methods: Procedures through which objects communicate amongst themselves. Example: Bicycle: brake, park. Dog: bark, eat. Student: register, study. • Attributes: Variables that hold state information. Bicycle: speed, color, owner. Dog:name, breed. Student: name, ID. BITS C461/IS C341 Software Engineering

  24. Digression: OO Concepts-Class • Class:Prototype for all objects of a certain kind. Student, animal, university, shape, etc. • Objects: Created from a class. For example: s1, s2 are objects from class Student. BITS and Purdue are objects from class University. myCircle and mySquare are objects from class Shape. • Inheritence: A class inherits attributes and methods from its super class. This allows hierarchical organization of classes. • Interface: A contract between a class and its users. A class implements an interface (methods and attributes). BITS C461/IS C341 Software Engineering

  25. What are business processes? • First step - consider what the business must do; in the case of a library - lending books, keeping track of due dates, buying new books. • In OO terms - requirements analysis; represent the business processes in textual narration (Use Cases). BITS C461/IS C341 Software Engineering

  26. Roles in the organization • Identify the roles of people who will be involved in the business processes. • In OO terms - this is known as domain analysis • Examples - customer, library assistant, programmer, navigator, sensor, etc. Examples from class projects? BITS C461/IS C341 Software Engineering

  27. Who does what? Collaboration • Business processes and people identified; time to determine how to fulfill the processes and who executes these processes. • In OO terms - object oriented design; assigning responsibilities to the various software objects. • Often expressed in class diagrams. BITS C461/IS C341 Software Engineering

  28. In Summary... BITS C461/IS C341 Software Engineering

  29. Simple example to see big picture • Define use cases • Define conceptual model • Define collaboration diagrams • Define design class diagrams Example: Dice game a player rolls two die. If the total is 7 they win; otherwise they lose BITS C461/IS C341 Software Engineering

  30. Define use cases • Use cases - narrative descriptions of domain processes in a structured prose format Use case: Play a game Actors: Player Description: This use case begins when the player picks up and rolls the die…. BITS C461/IS C341 Software Engineering

  31. Define domain model • OO Analysis concerns • specification of the problem domain • identification of concepts (objects) • Decomposition of the problem domain includes • identification of objects, attributes, associations • Outcome of analysis expressed as a domain model. BITS C461/IS C341 Software Engineering

  32. 1 2 Rolls 1 2 Plays Includes 1 1 Domain model - game of dice Player _____ name Die ____ facevalue DiceGame Conceptual model is not a description of the software components; it represents concepts in the real world problem domain BITS C461/IS C341 Software Engineering

  33. Collaboration diagram • OO Design is concerned with • defining logical software specification that fulfills the requirements • Essential step - allocating responsibility to objects and illustrating how they interact with other objects. • Expressed as Collaboration diagrams Collaboration diagrams express the flow of messages between Objects. BITS C461/IS C341 Software Engineering

  34. 1: r1:=roll() :Player d1:Die 2: r2:= roll() d2:Die Example - collaboration diagram BITS C461/IS C341 Software Engineering

  35. Defining class diagrams • Key questions to ask • How do objects connect to other objects? • What are the behaviors (methods) of these objects? • Collaboration diagrams suggests connections; to support these connections methods are needed • Expressed as class diagrams BITS C461/IS C341 Software Engineering

  36. Player Die Rolls name faceValue 1 1 2 2 play() roll() 1 1 2 2 includes Plays DiceGame 1 1 1 initialize() Example - Class diagram A line with an arrow at the end may suggest an attribute. For example, DiceGame has an attribute that points to an instance of a Player BITS C461/IS C341 Software Engineering

  37. Defining Models and Artifacts • Objectives • analysis and design models • familiarize UML notations and diagrams • Real world software systems are inherently complex • Models provide a mechanism for decomposition and expressing specifications BITS C461/IS C341 Software Engineering

  38. Analysis and Design models • Analysis model - models related to an investigation of the domain and problem space (Use case model qualifies as an example) • Design model - models related to the solution (class diagrams qualifies as an example) BITS C461/IS C341 Software Engineering

  39. What UML is not • UML is NOT a methodology • UML is NOT a process • UML is NOT proprietary (Now under the OMG) UML is strictlyNotations BITS C461/IS C341 Software Engineering

  40. Parts of UML • Views - shows different aspects of the system that are modeled, links the modeling language to the method/process chosen for development • Diagrams - graphs that describe the contents in a view • Model elements - concepts used in a diagram BITS C461/IS C341 Software Engineering

  41. Use Case View • Use-case view : A view showing the functionality of the system as perceived by the external actors Views in UML BITS C461/IS C341 Software Engineering

  42. Logical View Use Case View • Logical view: A view showing how the functionality is designed inside the system, in terms of the static structure and dynamic behavior. Views in UML BITS C461/IS C341 Software Engineering

  43. Logical View Component View Use Case View • Component view: A view showing the organization of the code components Views in UML BITS C461/IS C341 Software Engineering

  44. Logical View Component View Use Case View Concurrency View • Concurrency view: A view showing the concurrency of the system Views in UML BITS C461/IS C341 Software Engineering

  45. Logical View Component View Use Case View Concurrency View Deployment View • Deployment view: A view showing the deployment of the system in terms of the physical architecture Views in UML BITS C461/IS C341 Software Engineering

  46. Introduction to UML[4] • Model elements • Class • Object • State • Use case • Interface • Association • Link • Package …. BITS C461/IS C341 Software Engineering

  47. UML diagrams • Use Case diagram: External interaction with actors • Class/Object Diagram : captures static structural aspects, objects and relationships. • State Diagram: Dynamic state behavior • Sequence diagram: models object interaction over time • Collaboration diagram: models component interaction and structural dependencies BITS C461/IS C341 Software Engineering

  48. More UML diagrams • Activity diagram : models object activities • Deployment diagram : models physical architecture • Component diagram : models software architecture BITS C461/IS C341 Software Engineering

  49. Case study - Point of Sale Terminal • POS terminal should support the following • record sales • handle payments • Several architectural layers • presentation • application logic (problem domain, service support) • persistence • Emphasis - problem domain application objects BITS C461/IS C341 Software Engineering

  50. Analysis • Objectives • Identification of Use Cases • Draw use case diagrams • Ranking Use cases BITS C461/IS C341 Software Engineering

More Related