1. Object-Oriented System Analysis and Design Chapter III- Requirement Elicitation Collecting and organizing users requirement- WHAT- User needs

2. Requirement Elicitation using CRC 6/5/2016 2 Using Class Responsibility Collaboration (CRC cards) are a brainstorming tool used in the design of object-oriented software. are typically used when first determining which classes are needed and how they will interact. CRC are an index card on which one records the responsibilities and collaborators of classes, thus the name, which stands for Class-Responsibility-Collaboration.

3. Important tasks - CRC 6/5/2016 3 Finding Classes Recall definitions of a class and an object A Class represents a collection of similar objects. Objects are things of interest in the system being modelled. They can be a person, place, thing, or any other concept important to the system at hand. An object/class has responsibility to perform a task such as storing information or executing some process For example student class store information about student The Class name appears across the top of the CRC card.

4. cont… 6/5/2016 4 There are many ways to identify classes. One of the easiest to start with is noun extraction. Noun extraction identifies all of the Nouns in a problem statement and/or use-case scenario. The nouns extracted make excellent candidate classes

5. Cont… 6/5/2016 5 Other ways to identify classes are to look for items that interact with the system, or things that are part of the system. Ask if there is a customer of the system, and identify what the customer interacts with. Screens and reports represent interface classes, but for the sake of a CRC session, a single GUI class can represent these. If a class can’t be named with less than three words, then it’s probably not a class but a responsibility of another class.

6. Cont… 6/5/2016 6 Accordingly there are three types of classes at this stage Actor class Who interact with the system e.g. student Business class Are classes on which major business functionalities revolve around- represent the vocabulary of the system e.g. course, schedule, grade, etc Major UI classes Are reports and form used e.g grade reports, etc Remark: a class could be both an actor and a business class

7. Check list in finding classes 6/5/2016 7 Actors are potential classes Identify customers Follow the money How it is earned and what it is spent on Concepts and events used most frequently by the system Recurring nouns in the use case modeling Identify Major UI elements Additional Remarks identifying three to five main classes right away

8. Cont… Finding Responsibility A Responsibility is anything that the class knows or does. These responsibilities are things that the class has knowledge about itself, or things the class can do with the knowledge it has. For example, a person class might have knowledge (and responsibility) for its name, address, and phone number. In another example an automobile class might have knowledge of its size, its number of doors, or it might be able to do things like stop and go. The Responsibilities of a class appear along the left side of the CRC card. 6/5/2016 8

9. Cont… 9 How? Through verb extraction Verb extraction identifies all of the verbs in a problem statement and/or use-case scenario. These are usually good indicators of actions that must be performed by the classes of the system. Other techniques included asking what the class knows, and what information must be stored about the class to make it unique. Ask what the class does, and then flesh out how the class might do it.

10. Cont… 6/5/2016 10 Finding Collaborator A Collaborator is another class that is used to get information for, or perform actions for the class at hand. It often works with a particular class to complete a step (or steps) in a scenario. The Collaborators of a class appear along the right side of the CRC card. Class Name Responsibility Collaborators

11. Cont… 6/5/2016 11 Collaboration occurs when a class needs information that it doesn’t have. Classes know specific things about themselves. Very often to perform a task a class needs information that it doesn't have. Often it's necessary to get this information from another class, in the form of collaboration.

12. Cont… 6/5/2016 12 Collaboration can also occur if a class needs to modify information that it doesn’t have. One property of information that a class knows about itself is the ability to update the information. Often a class will want to update information that it doesn't have. When this happens, the class will often ask another class, in the form of a collaboration, to update the information for it.

13. Cont.. 6/5/2016 13 Generally for a collaboration to occur, one class is the initiator. In other words, there has to be a starting point for collaboration. Often times the initiating class is doing very little work beyond initialing the collaboration itself. However, be careful that a class doesn't just 'pass the buck', just to have it passed again. For example, if class A collaborates with class B, just to have class B passes the work to class C, consider eliminating the collaboration with class B.

14. Thus finally …. 6/5/2016 14 Item ItemID ItemName UnitPrice Quantity AddItem CheckReorder SalesClerk Invoice (UI) Sales Clerk > SellItem GenerateReport CheckAvailability Item Invoice (UI) Invoice > *see prototype*Item Sales Clerk Eg: CRC for User Interface Class Eg: CRC for Actor Class Eg: CRC for Business Class

15. Read and take notes about advantages of CRC modeling 6/5/2016 15 Reading assignment

16. Cont… 6/5/2016 16 Using Essential UI prototype User Interface is portion of software with which user directly interacts with the system. An essential UI prototype is a low fidelity model, or prototype of the UI for the actual system. It represents the general ideas behind the UI and not the exact detail. Represents the initial stage of the UI requirement in a technology independent manner, just like essential use case model.

17. Cont… 6/5/2016 17 is an iterative development technique in which users are actively involved in the mocking-up of the UI for a system. Essential UI prototype focus on the users and their usage of the system, not system features. It is represented by various rectangles enclosed in a bigger one. Grouping of smaller rectangles can be done by larger ones.

18. Cont… 6/5/2016 18 The various rectangles are used to represent the following components of the UI: Attributes/Data values Input Filed Display Only List Requestor Help Requestor Search Requestor Detail Requestor

19. Example student information UI-HTML 6/5/2016 19

20. Basic tasks 6/5/2016 20 Explore system usage Like what a “student transcript should look like” Model Major UI Large grained items potentially a screen, HTML page, report or a form Example: “class enrollment request” Model minor UI elements Example: input fields, menu items, lists, labels Examine the usability of your user interface in view of functionalities

21. Tools to be used 6/5/2016 21 For all essential modeling's the tool to be used is simple: Paper, whiteboard, sticky papers…. The purpose is to focus on the major issues (the actual task) rather than technology or implementation details.

22. Example of Invoice User Interface Prototyping 6/5/2016 22

23. Example UI- Using whiteboard 6/5/2016 23

24. Read and take notes on UI flow diagramming 6/5/2016 24 Reading assignment

25. Supplementary Specification We may not be in a position to capture all the requirements of the organization or the system Such uncaptured requirements need to be included and explained in the requirement document. The terminology used to entertain such exceptions is called supplementary specifications. Requirements not captured through use case, UI prototype and CRC Supplementary specification includes: Business Rules Non-Functional Requirements and Constraints Change case

26. Cont… Business Rules Any organization has its own internal policies and principles on how to run its business E.g.: if a student wants to add a new course and if it is the case that the student has reached the maximum semester load then the student will be required to drop some courses he already registered for. Thus the use case “Add Course” can extend to another use case called “Drop Course” based on evaluation of a business rule that declares the maximum credit hours the student is allowed to take in a semester. i.e.: If Current Load of student plus Credit hour of course to be added is greater than the Maximum semester Load (say 21) then include use case Drop Course

27. Cont.. Common ways of documenting business rule ID: BR002 Name: Allowed Maximum Semester Load Description: A regular/day student is not allowed to take more than 21 credit hours per semester. If the student is an extension/evening student, he/she can not take more than 12 credit hours per semester

28. Cont… Non-Functional Requirements Sometimes referred to as technical requirements of the system. The technical issues to be addressed here are more on Usability, Maintainability, Reliability, Modifiability, Efficiency, Portability (across operating systems) Testability, Understandability, User Interface and Human Factors, Documentation, Hardware Considerations, Performance Characteristics, Error Handling and Extreme Conditions, Quality Issues, Resources and Management Issues, etc E.g.: the system should work for 8 hours a day on all working days by dedicating a server for this purpose. UI of the system should be user friendly in terms of color combination and language usage.

29. Cont… Common ways of documenting Technical requirements Same as Business Rule

30. Cont… Constraints Constraints are other specifications that need to be documents for any systems development. This category includes the various restrictive conditions that exist in providing/delivering the system. The constraints might be economical, political, schedule, technical, or any that hinders the development team and the organization from meeting the objective of the systems development project. Some how similar with pseudo requirements

31. Cont… Change Cases No system lasts long without change. Internal need or external forces and a change in the real world and business customers demand force a system to change the way it behaves or the data it captures and processes. Such changes need to be anticipated before the development of a system. These anticipated changes need to be well documented and a mitigation scheme should be prepared. The development team and the users should work on this together and capture as many cases as possible. Lack in capturing probable changes would result in rejection of the system when the change happens.

32. Cont… Change cases would be documented as: Change Case: name or description of the anticipated change Likelihood: analysis and explanation when it might occur Impact: the impact the case would have on the overall system if not applied. See examples on reference materials like; Scott Ambler (2000)

33. Validating, organizing and documenting requirements 6/5/2016 33 Ensuring that your requirements are Correct, complete and consistent Trying to avoid unnecessary requirements- Gold plating The golden rule is: “Test early and often” How to validate? Through use case scenario testing, UI walkthrough and requirement review by all stakeholders Finally you are required to organize and document your requirements collected through traditional methods, Essential use case, CRC, UI prototype and supplementary specification in one document which will serve as an agreement document b/n the developers and users

34. Review questions 1. What is the difference between functional and non functional requirements 2. What are the techniques you use to identify system requirements? 3. What is user interface? Why do you develop UI prototype early in system development 4. What are the three elements of CRC 5. What are elements of use case diagram 6. How do you identify class, attribute, relationship and methods from the analysis document 6/5/2016 34

35. Example Company A has more than 1000 employees. Managing the personnel records become very difficult. They want a system that stores personal data. In addition, they want the system to retrieve single employee records. When employee leave the organization, they want to delete that employee record. They also hire new employee and want to be add that record to the system. 1. Develop the use case diagram 2. Develop sequence diagram, class diagram 3. Design also the user interface. 4. Try also to design the database 6/5/2016 35