CS 4850/01: CS Senior Project Fall 2014 Overview of Software Requirements and OO Analysis

1. CS 4850/01: CS Senior Project Fall2014 Overview of Software Requirements and OO Analysis

2. Introduction to Software Requirements Analysis

3. What is Software Requirements Analysis? (1) Software requirements analysis is the process of understandingcustomer requirements of the software system to be built, and buildinganalysis model to help assess the quality of the system. This process requires active participation from the customer, and it is a crucial step in the development process. The developer (analyst) may play different roles - interrogator, advisor, problem solver, and negotiator.

4. What is Software Requirements Analysis? (2) The outcome of the process: 1. A Software Requirements Specifications (SRS). The SRS should be clear, complete, and consistent with the customer needs. 2. Quality Assurance Plan - set of activities that the project team can follow to ensure software quality throughout the product lifecycle (portability, reliability, efficiency, V&V criteria, cost, acceptance criteria, etc…). Only the SRS part is required for our class projects.

5. Overview of Object-Oriented Analysis

6. Domain Level Domain Engineering OO Engineering System Level OO Analysis OO Design Implementation OO Testing Deployment The Big Picture - 1

7. OO Analysis OO Design Implementation OO Testing Deployment Object Relationship Modeling Class Modeling Object Behavior Modeling The Big Picture - 2

8. OOA Methods OOA methods vary in their process steps, diagrams, notations, terminologies, but they all produce similar results. Examples: • Booch method • Rumbaugh method • Jacobson method • Coad/Yourdon method • Wirfs/Brock method

9. The UML Approach UML is a modeling language that can be used with any modeling process. UML components: Syntax ===> the look of each symbol. Semantic ===> the meaning of each symbol. Pragmatic Rules ===> the intention/purpose of grouped symbols. UML General Views: User model view (user view) Structural model view (data and functionality view) Behavioral model view (object interactions view) Implementation model view (the software static and dynamic aspects) Environment model view (the environment static and dynamic aspects)

10. Use-Cases (1) Use-cases are scenarios of system usage by different actors (categories of end-users and devices). e.g., a student, faculty, and registrar are actors for a student registration system. Uses-cases are used to: - obtain requirements from the customer - effectively express requirements back to the customer Annotated diagrams are common way to construct use-cases. In UML, use-cases are represented by use-case diagrams.

11. Use-Cases (2) Some of the questions a use-case should answer: - What are the main functions performed by the actor (people or devices)? - What information will the actor acquire, produce or change? - What information does the actor desire of the system? - others… Note that an actor can play different roles for a given scenario. High-level use-cases may be elaborated by lower-level use-cases. Please read the report “Structuring Use Cases with Goals” at: http://alistair.cockburn.us/Structuring+use+cases+with+goals

12. Components of OOA Static components: classes class attributes class operations class relationships (inheritance structure) Dynamic components: interactions among objects (events) control events that cause state transitions

13. OOA Process • Define use-cases • Extract/Select candidate classes • Identify attributes for each class • Specify methods that service the attributes • Establish basic class relationships • Define a class hierarchy • Build a behavioral model Repeat these steps for lower-level (other) use-cases. Steps 2 through 5 can be done using CRC modeling.

14. class name: class type: (e.g., device, property, role, event, person ...) class characteristics: (e.g., tangible, atomic, concurrent, ...) responsibilities: collaborators: CRC Modeling CRC modeling involves selecting classes, defining their responsibilities, and identifying collaborations among classes.

15. Selecting Classes Suggested class selection criteria for potential objects: • Retained information: Does the system need to know about the object? • Needed services: Does the object provide needed operations? • Multiple attributes: Does the object have multiple attributes? • Common attributes: Do attributes apply to all instances of the object? • Common operations: Do operations apply to all instances of the object? • Essential requirements: Does the object represent essential entity of the system? An object that satisfies all or most of these criteria is a potential class candidate.

16. Allocating Responsibilities Class responsibility implies attributes and operations (i.e., needed content such that the class performs its intended function as per the scope statement or system narrative). Attributes: class variables. Operations: class methods needed to manipulate its variables.

17. Identifying Collaborations Collaboration is required when a class cannot fulfill all of its responsibilities on its own (i.e., the class doesn’t have the method(s) to manipulate its attributes). Common relationships: part-of: Subclass relationship (part of aggregate). has-knowledge-of: Relationship to a non-subclass. For a potential class, the names of its collaborating classes and their relationships are recorded on the class index card.

18. Reviewing the CRC Model (1) Reviewing CRC model index card can be done in different ways. One approach is the following: 1. All participants are given a subset of the index cards. 2. All use-case scenarios and corresponding use-case diagrams should be organized into categories. 3. The review leader reads the use-case deliberately. As the leader comes to a named object, he/she passes the token to the person holding the class index card for that object. 4. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. 5. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards.

19. Here is what you need to do for your class project…

20. Understand Customer Requirements (1) Step 1: Get good understanding of customer requirements - Write down what the customer needs from the system (functionality) • Often the customer has a vague idea of needed system • Note the difference between the customer's wants and needs! • Differentiate between requirements and design issues • Pay attention to doability (applicability) of needs/wants

21. Understand Customer Requirements (2) - Don’t rely on memorizing gathered information. Document gathered information (requirements). • Clearly express the customer's wants and needs • Clearly identify and document all potential users (actors) and their roles • Develop high-level use-cases to clarify the customer’s view of system functions and potential system interactions

22. Develop Use-Cases (1) Step 2: Develop detailed use-cases - For each potential user of the system, develop high-level use-case scenario (plain-English description) • State the use-case name, and the user's role(s) (student, faculty, staff, etc..) • List the user’s main interactions with the system (minimize branching and avoid specific names and values) • Briefly elaborate on each interaction (system functions) to indicate if lower-level use-cases are needed • Document the use-case (See posted revised SRS Template) • Develop UML diagram for each use-case

23. Develop Use-Cases (2) - Develop needed lower-level use-cases in a similar manner. In our case, please use your judgment to determine reasonable level of details for each use case your team defines. Please read the report “Structuring Use Cases with Goals” at: http://alistair.cockburn.us/Structuring+use+cases+with+goals - Review the use-cases for each actor and each role, and save all resulted data (text and diagrams). Note 1: In addition to specifying requirements, use-cases are useful for developing the system design and test cases. Note 2: Since most requirements documentation standards predate use-cases, use-cases are often amended to the SRS.

24. Develop Specific Requirements Step 3: Analyze gathered requirements to develop analysis classes. - Specific requirements (presented as analysis classes) are detailed requirements intended for the development team. But also reviewed by the customer! - They consist of detailed and well expressed listing of properties and functions of the system. - They are written from the customer requirements (use-cases). - For this course, we’ll use table format as shown in the revised SRS Template (posted).

25. Summary of OOA Approach (1) The following steps are summary of the OOA approach (See CS 3610 textbook). 1. List the names of potential analysis classes you derived from the use-cases using grammatical parsing. 2. Apply the “Class Selection Criteria” discussed earlier to revise the initial list of analysis classes and identify potential classes. Notice that we are actually applying CRC modeling. 3. For each class, determine its responsibilities (attributes/variables and methods). Consider using index cards (or paper notepad) for individual classes.

26. Summary of OOA Approach (2) 4. For each class, determine its collaborators and the sort of relations between them (is-a, uses, etc..). Write this info on the class index card (or sheets of paper). 5. Review the index cards (or sheets of paper). 6. Draw Class Diagram(s) showing relationships between classes. This is your Class Modeling (see OOA slides). 7. In addition to class relationships (which are eventually relationships among objects of related classes), identify other potential relationships among objects of the application. Draw object relationship diagram(s). Remember, this step results in your Object Relationship Modeling(see OOA slides).

27. Summary of OOA Approach (3) 8. List all events that objects of a class must respond to (behavior modeling for individual objects). Draw object state transition (or state chart) diagrams. 9. From your object relationship modeling, list potential events among objects of the application (behavior modeling for all objects). Draw a state transition (or state chart) diagrams for the entire system. Materials developed under the last two steps above represent Behavior Modeling of the system (see OOA slides).

28. Other Requirements In addition to Class/Object requirements, you need to think about and document the following: - Interface requirements. Note: GUI design is part of the design phase. However, you may consider drafting screen designs for GUI interfaces. - Performance requirements. Are there processing speed, response time, efficiency, throughput, resource allocation requirements? - Other requirements specific to your application and the client's business model.

29. SRS Content Organization (1) Use the revised SRS Template document posted on the website, and make a note of the following: • In section 3.2 of the posted revised SRS template, use table format to present each class. This way you can reuse this document to generate your Software Design document later. 2. Add the Sequence Diagrams, Object Collaboration Diagram(s), and Object Behavior Diagram(s) to section 3.0 of the SRS, under appropriate sections as indicated in the posted revised SRS template. 3. Add your CRC cards info as support materials in section 6.0

30. SRS Content Organization (2) • The blue and red italic text in all posted documents is for guidance purpose only. When you add your text to the templates and tables, use non-italic, black color, regular size font. Remove all guidance text. 5. Be consistent throughout the document with regard to style and appearance (font type, text styles, font size, font color, bullets, numbering, indentation, figure captions, etc…).

31. Milestone #2 SRS Document Due date: Wednesday 2/5/2014 in class Each team will submit a professionally prepared printout of the document along with a cover page. Please email the instructor an electronic version (Word file). Check the course website for a revised SRS template and these OOA slides.

32. Project Final Binder Your project final report (binder) will consist of all the deliverables you product throughout the semester (milestones), including software development plan (scope statement, project plan), requirement specifications, design document, presentations, weekly reports, and implementation result. In the final report, an “Updates” section will added to include updates to each of those deliverables, and potential future functions and enhancements for the system. Save copies of all deliverables!