Mastering Requirements Analysis in Software Engineering

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