Oosad 02


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Oosad 02

  1. 1. Gathering User Requirements Chapter 2 1
  2. 2. Outline• Introduction• How to interview and brainstorm• Indentify essential use cases• Define and prototype your system• Domain modeling using CRC cards• Supplementary spec• Modeling Room Organization 2
  3. 3. Introduction• The first Step – not easy – People don’t want to spend time here • SME don’t want to invest time • Developers want to get into the “real work” of coding • Senior Management want to see progress – Communicate with everyone• Use Models – Use Case Modeling – b/r and functional tasks – Domain Modeling – business domain concepts – User Interface Prototyping – screen, pages, reports … 3
  4. 4. Interviewing• To broaden your understanding of the application• To determine who to invite to requirements modeling sessions• To identify new or existing requirements directly for your application 4
  5. 5. Pointers for interviewing• Send ahead agenda• Verify the Schedule• Thank the person• Let the person know his input is important• Summarize issues• Ask critical questions ASAP• Ask for missing information• Don’t Shut down users – “ I have already heard this before• End by summarizing• Thank the person again• Listen than talking• Identify “needs” vs “wants” 5
  6. 6. Brainstorming• Technique where group of people discuss a topic and say anything that comes into their minds about it. – Rules • All ideas are good; not judged by the group • All ideas are owned by the group, not the individual • All ideas immediately become public property, anybody is allowed to expand upon them• Make sure everyone follows the rules 6
  7. 7. Potential Issues to discuss in Brainstorming• Who is this system for?• What will they do with the system?• Why do we do this?• Why do we do this the way we do?• What business needs does this system support?• What do/will our customers want/demand from us?• How is the business changing• What is our competition doing? Why? And how can we do it better?• Do we need to do this?• Will the system pay for itself?• Is the work being performed where it makes most sense?• How will peoples jobs be affected?• How can we do this BFC?• Etc… 7
  8. 8. Essential Use Case Modeling• To model behavioral requirements• It is one of the two basic flavors – Essential Use Case – Business/Abstract Use Case – System Use Case – Concrete/Detailed Use Case• Intended to capture the essence of problems through technology free, idealized and abstract descriptions• Flexible• A picture says 1,000 words 8
  9. 9. Use Case Diagram for a Simple University Input Marks Grade Administrator Enroll in Semester DistributeStudent Transcripts Registrar 9
  10. 10. Drawing Use Case Diagrams• Collection of use cases, actors, their associations, a system boundary box (Optional), and packages (Optional)• Horizontal Ellipse – Use Cases• Stick Figures – Actors – role players• Line – Association and Relationship• Arrow – Initial invocation (optional)• Rectangle around use case – Scope of the system• File Folders – Packages (organized model elements into groups) 10
  11. 11. Identifying Actors• Anything or anyone that interfaces with your system• Including people, external systems, and other organizations• Never part of the system• Questions help to find actors – Customer? – Who obtains information? – Who provides information? – Who installs the system? – Who operates the system? – Who shuts down the system? – What other system interacts with our system? – Does anything happen automatically at preset time? – Who will supply, use or remove information? – Where does the system get information? 11
  12. 12. Things to consider• Actors should model roles and not the physical, real world people.• Actors don’t model positions• Describe an actor by actually reflecting its role 12
  13. 13. Document Use Cases• Sections – Name – purpose of the use case – Description – summary of a use case – Actors (optional) – associated with the use case – Status (optional) – work in progress etc… – Precondition – conditions that must be met – Post condition – effect of a use case action – Extension Points (optional) – covered later – Included Use Cases (optional) – covered later – Basic Course of Action – logic followed – Alternate Course of Action – Infrequently used path – Change History (optional) – when, who, why modified use cases 13
  14. 14. Identifying Use Cases• Answer the following questions – What are users trying to accomplish – To fulfill this role, what do users need to be able to do? – What are the main tasks of users in this role? – What information do users in this role need to examine, create or change? – What do users in this role need to be informed of by the system and inform the system about?• Use Case Scenario – description of a potential business situation that may be faced by the users of a system 14
  15. 15. Essential Use Case Description ExampleName: Enroll in SemesterDescription: Enroll an existing student in a seminar for which she is eligiblePreconditions: The Student is registered at the universityPost conditions: The Student will be enrolled in the course she wants if she is eligible and room is availableBasic course of Action:1. A Students wants to enroll in a seminar2. The Student submits his name and student number to the registrar3. The registrar verifies the student is eligible to enroll in semesters at the university according to rule no BR 1274. The student indicates, from the list of available seminars, the seminar in which he wants to enroll5. The registrar validates the student is eligible to enroll in the semester according to the business rule6. The registrar validates the semester fits into the existing schedule of the student7. The registrar calculates the fees for the seminar,8. The registrar informs the student of the fees9. The registrar verifies the student still wants to enroll in the seminar10. The student indicates he wants to enroll in the seminar11. The registrar enrolls the student in the seminar12. The registrar adds the appropriate fees to the students bill13. The registrar provides the student with a confirmation that he is enrolled14. The use case ends 15
  16. 16. 10 Things to know about Use Cases• These are just preliminary use cases• No time ordering is indicated between use cases• Customer actors are usually involved in may use cases• Use Cases are not functions• No arrowheads are on the associations• The diagram is too big (7 +/- 2 bubbles)• Should be functionally cohesive• Should be temporally cohesive• Every actor is involved with one use case and vice versa• I chose not to include a system boundary box 16
  17. 17. UML packages• Represents collection of use cases• By introducing packages, the use case diagram become simpler and easier to understand• Each package, in turn, would be documented by another use case diagram. 17
  18. 18. Manage Loan and Manage Seminar Instruct Seminars Manage Fees Grants and Registration Enroll in Seminar Drop Seminar Attend Seminar Finish Seminar Notify students of schedule changes 18
  19. 19. Alternate Course of Action• Infrequently used path of logic in a use case• Exception or error condition that must be handled• Style issues 1. Includes the descriptions of actions that must be met to invoke the alternate course 2. Identification and numbering scheme is used 3. Each step starts with the letter of the alternate course, followed by the number of the step in the basic course of the use case it replaces 4. The last step in each alternate course of should indicate either that the use case ends or goes to the last step of the Basic Course of Action 19
  20. 20. Example of Courses of ActionsAlternate course A: The student is Not Eligible to Enroll in SeminarsA.3. The registrar determines that student is not Eligible to Enroll in SeminarA.4 The registrar informs the student she is not eligible to enrollA.5 The use case endsAlternate Course B: The Student Does Not Have the PrerequisitesB.5 The registrar determines the student is not eligible to enroll in theseminar she choseB.6 The registrar informs the student she does not have the prerequisiteB7. The registrar informs the student of the prerequisites she needsB8. The use case continues at Step 4 in basic course of actionAlternate Course C: The student decides not to enroll in an available seminarC4. The student views the list of seminars and does not see one in which shewants to enrollC5. The use case ends 20
  21. 21. Exercise 1.• Name the Actors for your system• Identify use cases• Draw use cases• Describe the use cases 21
  22. 22. Essential User Interface Prototyping• Place where user directly interacts with systems• Low fidelity model, or prototype of the UI for your system• It represents the general ideas behind the UI, but not the exact details• Represents user interface requirements in a technology-independent manner• Beginning point of the user interface prototype for your system 22
  23. 23. Differentiating facts about essential UI prototyping• Focus on your users and their usage of the system, not system features• Simple tools including whiteboards, flip chart paper and sticky notes• Don’t focus on the design 23
  24. 24. Tasks in Essential UI P• Explore system usage – Use white boards to discuss initial drawings – Work iteratively• Model major UI elements – flip chart paper – Potential screens and reports• Model minor UI elements (input fields, lists and containers) – sticky notes• Explore the usability of your UI – Learnable, increase user productivity, easy to remember, supportable• Explore the relationship between UI elements – User interface flow diagramming 24
  25. 25. Example for essential UIStudent Information Enroll Students in Seminar Student Help Help Number Requester Requester Student Name Display Course Details Requester Course Course Seminar Seminar Seminar Seminar Number Number Location Location Availability Availability Course Course Enrollment Enrollment Course Searcher Name Name Requester Requester Course Number Course Course Description Description Course Name Search Details Details Professor Professor Requester Requester Requester 25
  26. 26. Prototype for a Student Transcript Student Information Student Number Student Number Student Phone Number Student Phone Number Student Address Student Address Student Full Name Student Full Name Student Email Student Email Period Period Student Status Student Status Payment Status Payment Status Amount Owed Amount Owed Seminars the student ha taken during period of the transcript Informational Message Footer Information 26
  27. 27. Ensuring System Usability• Five factors affect usability – Access : A system should be usable with out help from a person – Efficacy: System not interfere with or impede use by a skilled worker – Progression: facilitating advancement in knowledge, skill and facility – Support: easy, simple, fast and fun – Context : Real condition and actual environment• Usability is important because – By focusing on use and usability your system can be simpler, smaller and less expensive – Best systems give pleasure and satisfaction – Unusable systems lead to request for change – User are less patient with poorly developed applications 27
  28. 28. User Interface Flow Diagramming• Helpful to see the bigger picture• High level interaction between the UI elements of you application• Also called windows navigation diagrams and context navigation maps• Use notations that is a combination of the notation for UML activity diagram and UML collaboration diagram• Used for one of the two purposes – Model the interactions that users have with your software, as defined in a single use case. – Gain a high level overview of the UI of your application. • Derived from your use cases• Gain an understanding of how the system is expected to work 28
  29. 29. Example : :Main Menu Main Menu Use enrollment Use Transcript requester Requester :Enroll in :Enroll in :Obtain :Obtain Use Transcript :Transcript :Transcript Seminar Seminar Transcript Transcript Requester Use Professor Use Prerequisite Information Details Requester Requester Use :Professor :Professor Seminar :Seminar :SeminarInformation Information Information Information Information Requester 29
  30. 30. Domain Modeling with Class Responsibility Collaborator (CRC) Cards• Task of discovering the classes that represent the things and concepts pertinent to your problem space• Nouns and noun phrases from USE CASES are good sources for domain modeling• A CRC model is a collection of standard index cards that have been divided into three sections – CLASS – collection of similar objects – RESPONSIBILITY – something that a class knows or does – COLLABORATOR - another class that a class interacts with to fulfill its responsibilities 30
  31. 31. Layout of a CRC card CLASS NAMEResponsibilities CollaboratorsResponsibilities Collaborators 31
  32. 32. Domain Modeling with CRC• CRC models are well suited for domain modeling during requirement gathering• Fundamental techniques employed for design in the eXtreme programming (XP) software process• UML class diagrams are better choice for domain modeling 32
  33. 33. CLASS• Represents a collection of similar objects• Person, Place, Thing, Event or Concept• Eg. University System – Students, professors, seminars• Singular noun or singular noun phrase• Class names should also be simple 33
  34. 34. Responsibility• Anything a class knows or does• Eg. – Students have names, addresses and phone numbers. (KNOWS)• Students also enroll in seminars, drop seminars and request transcripts (DOES)• Classes update their own attributes and nobody else’s• A class may not have enough information to do its responsibilities, need information from other classes 34
  35. 35. Collaboration• Takes one of two forms – A request for information or – A request to do something.• EG. – The card “Student” requests an indication from the card “Seminar” – A request for information – A request to do something 35
  36. 36. STUDENTStudent NumberNameAddressPhone Number SEMINAREnroll in SeminarDrop a seminarRequest transcripts 36
  37. 37. Steps in Domain Modeling by CRC cards1. Prepare to CRC Model – Put together a modeling group of SMEs – Brainstorm – Explain the CRC modeling techniqueIteratively Model CRC – Find classes – Find responsibilities – Define collaborators – Define use cases – Move the cards around – Prototype 37
  38. 38. Finding Classes• Actors are potential classes• Identify the customer• Follow the money• Concepts and Events are potential classes• Major UI elements are potential classes• Look for three to five main classes right away• When you think you have identified a class, create a new card for it immediately• You are interested in several types of classes 38
  39. 39. The three types of classes1. Actor Classes – actors that appear in your use case • People or organization2. Business Classes – places, things, concepts, and events that describe what the business is all about • Concept – Course • Event – Registration • Place – Room3. UI Classes – screens, menus, and reports • The Major UI elements • Eg. Student editing screen, registration page, student transcript 39
  40. 40. Finding Responsibilities• Ask yourself what a class does – Actor Class – Identify the way in which the actor interacts with your system – UI Class – accept input from users, retrieve business objects, enable users to manipulate the business objects, support creation, update, deletion, and saving of business objects into the system – Business Class – derived from UI classes or other business classes (remember the context of your domain)• Ask yourself what information you need to record about a class – Actor Class – don’t need to identify information they know about themselves because they are represented by their corresponding Business Class – UI Class – prototype describes all 40
  41. 41. Defining Collaborators• Collaboration must occur – when a class needs information it doesn’t have – When a class needs to modify information it doesn’t have because any given classes can update only the information it knows• Things to consider – There will always be at least one initiator of any given collaboration – Sometimes the collaborator does the bulk of the work – Don’t pass the buck – New responsibilities may be created to fulfill the collaboration 41
  42. 42. Student <<actor>> Student <<actor>> Enroll in course <<UI>> Enroll in course <<UI>> Student Student Name Name Address AddressThe student registers The student registers Enroll in Enroll in Phone number Phone numberfor a a course for course Email address Email address Enrollment EnrollmentAdds a a course Adds course Course Course **See the prototype** **See the prototype** Student Student Student numberChanges its name Changes its name Student number Record Record <<UI>> <<UI>> Average Mark Average Mark Validate Info Validate Info Provide list of course Provide list of course 42
  43. 43. Advantages and Disadvantages of CRC Modeling• User participation in system devt is • Threatening to systems developers increased• • Difficult to get your SMEs together CRC modeling improves communications between users and developers • Limited• CRC cards are simple and inexpensive • You still need to do class modeling• CRC modeling is nonthreatening to users • You need management support• CRC cards are quick and portable• CRC modeling goes hand in hand with essential use case modeling and essential UI prototyping• Gives you good overview of a system Name Name• Leads directly into class modeling Respon Collabo Attribute• Enables you to deal with system complexity one class at a time sibilitie rators Method• Promotes a common project vocabulary s 43
  44. 44. Exercise 3• Create CRC Cards for the classes in your system 44
  45. 45. Example for the simple university 45
  46. 46. Requirement Tips and Techniques• Prominently display definitions• Expect to gather requirements throughout the entire software process• Explain the techniques• Allow observers• User several techniques simultaneously• Use the terminology of your users• Keep it low tech• Keep it fun• Obtain management support• Send an agenda ahead a few days before a modeling session• Don’t be afraid to iterate• Take a breadth first approach• Technical support people are good sources of user requirements• Existing documents are a good source of requirements 46
  47. 47. Business Rules• Business rules often pertain to – access control issues • Professors are allowed to input and modify the marks of the students taking the seminars they instruct – business calculations or operating policies and • Converting a percentage mark that a student receives in a course to a letter grade – principle of your organization • Expel any student who falls more than two courses in the same semester• 47
  48. 48. More on business rules• Each business rule has an identifier• Use format of BR# – Enables to refer easily to business rules in other development artifices (class models or use cases)• A good business rule is cohesive: it describes one and only one concept – Increase their reusability 48
  49. 49. Examples• BR123 Tenured professors may administer student gradesgrades tudent e have beenminister sauthority by a tenured• BR124 Teaching business rul assistants who rs may ad granted n ted sso Af professor may administerrofe ully docume Te nu red p student grades t y… he abilit ms (INSY granted te are grades tand se Sysgradesed in that BR177 BR123• Name Table to convert between ssors numeric r of Da aba letter s enroll re profe u to t n 32) Identifie r Only ten Bekele, instruc rks of all stude iology(3 tion l a n to B Descrip D r. Rahe minister the m “Introductio e ay ad rolled in s Exampl 432)m e en not thos d Procedure but course ies an i ty Polic Univers 701 , 2000 Sou rce Do c ID: U1 ate: August 14 nd P ublicatio fying to teach nt Grad es uali tude s BR12 Q difying Final S r. X Rela ted rule BR 200 Mo h 2, 2001 by M r. Y efined Marc , 20 01 by M n His tory D d Oc tober 10 Revisio Update 49
  50. 50. Got Questions? The End 50
  51. 51. Exercise 4State the business rules and describe them- Choose the ones that are going to be applied in your use cases 51