1. CS 4850: Senior Project – Spring 2009 CS 4850: Senior Project Spring 2009 Overview of Software Requirements and OO Analysis

2. CS 4850: Senior Project – Spring 2009 Introduction to Software Requirements Analysis

3. CS 4850: Senior Project – Spring 2009 What is Software Requirements Analysis? (1) Software requirements analysis is process of understanding customer requirements of the software system to be built, and building analysis model to help assess the quality of the system to be built. This process requires active participation of the customer, and it is crucial step in the development process. The developer (analyst) may play different roles - interrogator, advisor, problem solver, and negotiator.

4. CS 4850: Senior Project – Spring 2009 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 customer needs. 2. Quality Assurance Plan - set of activities that the project team can follow to ensure software quality throughout the product life cycle (portability, reliability, efficiency, V&V criteria, cost, acceptance criteria, etc…) Only the SRS part is required for our class projects.

5. CS 4850: Senior Project – Spring 2009 Overview of Object-Oriented Analysis

6. CS 4850: Senior Project – Spring 2009 The Big Picture - 1 Domain Level System Level Domain Engineering OO Engineering OO Analysis OO Design Implementation OO Testing Deployment

7. CS 4850: Senior Project – Spring 2009 The Big Picture - 2 OO Analysis OO Design Implementation OO Testing Deployment Object Relationship Modeling Class Modeling Object Behavior Modeling

8. CS 4850: Senior Project – Spring 2009 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 See OOA Handout (Chapter 21 of Pressman’s SE Book, 5 th Ed.)

9. CS 4850: Senior Project – Spring 2009 The UML Approach UML is a modeling language that can be used with any modeling method/process. UML components: Syntax ===> the look of each symbol. Semantic ===> the meaning of each symbol. Pragmatic Rules ===> the intention/purpose of grouped symbols. UML 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. CS 4850: Senior Project – Spring 2009 Use-Cases (1) Use-cases are scenarios of system usage by different actors (classes of users and devices). e.g., student, faculty, and registrar are actors for a student registration system. Uses-cases are used to: - obtain requirements from the customer - effectively express requirements to the customer Annotated diagrams are common way to construct use-cases. In UML, use-cases are represented by use-case diagrams (see handout page 582 or check you CSIS 3600 textbook)

11. CS 4850: Senior Project – Spring 2009 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-case 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. CS 4850: Senior Project – Spring 2009 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. CS 4850: Senior Project – Spring 2009 OOA Process 1.Define use cases 2.Extract/Select candidate classes 3.Identify attributes for each class 4.Specify methods that service the attributes 5.Establish basic class relationships 6.Define a class hierarchy 7.Build a behavioral model Repeat these steps for lower-level (other) use-cases. Steps 2 through 5 may be done using CRC modeling.

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

15. CS 4850: Senior Project – Spring 2009 Selecting Classes Selection criteria for potential objects (classes), page 583: 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. CS 4850: Senior Project – Spring 2009 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). See handout, page 584, for helpful guideline for allocating class responsibilities.

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

18. CS 4850: Senior Project – Spring 2009 Reviewing the CRC Model (1) Reviewing CRC model index card can be done in different ways. The following approach is described in the handout, page 588. 1. All participants in the review process 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 corresponding class index card.

19. CS 4850: Senior Project – Spring 2009 Reviewing the CRC Model (2) 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.

20. CS 4850: Senior Project – Spring 2009 Here is what you need to do for your class project…

21. CS 4850: Senior Project – Spring 2009 Understand Customer Requirements (1) Step 1: Get good understanding of customer requirements - Write down what the customer need from the system (functionality)  Often the customer has a vague idea of needed system  Note the difference between customer wants and needs!  Differentiate between requirements and design issues  Pay attention to doability (applicability) of needs/wants

22. CS 4850: Senior Project – Spring 2009 Understand Customer Requirements (2) - Don’t rely on memorizing gathered information. Document gathered information (requirements).  Clearly express customer 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

23. CS 4850: Senior Project – Spring 2009 Develop Use-Cases (1) Step 2: Develop reasonably 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 CSIS 3600 textbook handout)  Develop UML diagram for each use-case

24. CS 4850: Senior Project – Spring 2009 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. - Review your 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.

25. CS 4850: Senior Project – Spring 2009 Develop Specific Requirements Step 3: Analyze gathered requirements an develop specific requirement specifications (See Handout) - Specific requirements 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 - For this course, we’ll use table format for this course as shown in the SRS Components document (posted)

26. CS 4850: Senior Project – Spring 2009 Specific Requirements for OO System Table of Contents 1. Introduction 2. Overall description 3. Specific requirements (OO format) 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communication interfaces 3.1.6 Memory constraints 3.2 Classes/Objects 3.2.1 Class/Object 1 3.2.1.1 Attributes 3.2.1.1.1 Attribute 1... 3.2.1.2 Methods 3.2.1.2.1 Method 1... 3.2.2 Class/Object 2... 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements <<See posted SRS Components Handout for table format. We’ll use table format for this course>>> 4. Supporting information IEEE Standard 830-1999 SRS.

27. CS 4850: Senior Project – Spring 2009 Organizing Requirements for OO systems For OO systems, specific requirements can be organized by - use-cases > based on operational sequence > desired approach by the Unified Software Development process - classes (We’ll follow this approach for our class projects) > known as OO style > promotes traceability (correspondence between requirements and their design and implementation > promotes reuse of classes that correspond to “real-world” concepts > identifies classes early on

28. CS 4850: Senior Project – Spring 2009 Recommended Steps Using OO Style (1) The following steps are summary of the handout. 1. List classes you mentioned in the use-cases. Here, create a sequence diagram for each use-case to compile your list of classes. 2. Apply the “Class Selection Criteria” discussed in the handout, page 583, to revise the initial list and identify potential classes. Notice that we are actually applying the CRC method. 3. For each class, determine its responsibilities (attributes/variables and methods). Consider using index cards (sheets of paper) for individual classes.

29. CS 4850: Senior Project – Spring 2009 Recommended Steps Using OO Style (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 sheet of paper). 5. Review the index cards (or sheet of papers). 6. Draw Class Diagram(s) showing relationships between classes. (similar to figures 21.4 through 21.7). This is your Class Modeling. 7. In addition to class relationships (which are eventually relationships among objects of related classes), identify other potential relationships among objects of the system. Draw object relationship diagram(s) (similar to figure 21.8). Remember, this step results in your Object Relationship Modeling.

30. CS 4850: Senior Project – Spring 2009 Recommended Steps Using OO Style (3) 8. List all events that objects of a class must respond to (behavior modeling for individual objects). Draw object state diagrams (similar to figure 21.9). 9. From your object relationship modeling, list potential events among objects of the system (behavior modeling for all objects). Draw event trace diagrams (similar to figure 21.10). 10. Develop event flow diagram for the system by aggregating events on the event trace diagrams (similar to figure 21.11). Materials developed under the last three steps above represent your Behavior Modeling of your system.

31. CS 4850: Senior Project – Spring 2009 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 project.

32. CS 4850: Senior Project – Spring 2009 SRS Content Organization (1) As you prepare your SRS, please take a close look at the SRS Components document posted on the website, and make a note of the following: 1.In section 3.2 of the SRS document, use table format to present each class as shown in the posted SRS Components document. This way you can reuse this document to generate your Software Design document. 2. Add the Sequence Diagrams, Object Collaboration Diagram(s), and Object Relationship (collaboration) Diagram(s) to section 3.0 of the SRS, under appropriate titles as shown in the SRS Components document.

33. CS 4850: Senior Project – Spring 2009 SRS Content Organization (2) 3.Add your CRC cards info as support martial in section 4.0 4.The blue italic text in the tables (in file SRS Components) is for directions. When you add your text to the templates and tables, use non-italic, black color, regular size font. 5. Be consistent throughout the document with regard to style and appearance (type, style, size, color, etc…)

34. CS 4850: Senior Project – Spring 2009 Milestone #2 SRS Document Due: Wednesday 2/18/09 in class The document includes UML use-case modeling diagrams. Each team will submit a professionally prepared printout of the document along with a cover page. Check the course website for a revised SRS template and other handouts.

35. CS 4850: Senior Project – Spring 2009 Project Final Report Your project final report will consist of all the deliverables you product throughout the semester (milestones), including software development plan (scope statement, project plan), requirement specifications, design document, 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!