2. 310414 REQUIREMENTS CAPTURE 1/67 SYSTEM REQUIREMENTS CAPTURE 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

3. 310414 REQUIREMENTS CAPTURE 2/67 SYSTEM REQUIREMENTS CAPTURE OUTLINE System Requirements Capture — Unified Process Overview –Importance & Difficulty –Capturing & Documenting Requirements –Life Cycle Role  System Requirements Capture — Unified Process Activities –Domain Modeling –Use-Case Modeling –User-interface Specification & Prototyping –System Requirements Validation 4

4. 310414 REQUIREMENTS CAPTURE 3/67 SYSTEM REQUIREMENTS CAPTURE requirement a feature that the system must have or a constraint that it must satisfy to be accepted by the customer requirements capture (gathering, elicitation,...) learning about the problem that needs a solution specifying (in detail) the required features/constraints of the system in a way that the customer/user understands and can approve CHALLENGE:How to bridge this gap? CHALLENGE: How to bridge this gap?  requires the collaboration of several groups of participants with different backgrounds KnowledgeGAPKnowledgeGAP 4

5. 310414 REQUIREMENTS CAPTURE 4/67 Reasons for failure of/problems with software development: incomplete requirements13.1% lack of user involvement12.4% lack of resources10.6% unrealistic expectations9.9% lack of executive support9.3% changing requirements and specifications8.7% lack of planning8.1% system no longer needed7.5% Reasons for failure of/problems with software development: incomplete requirements13.1% lack of user involvement12.4% lack of resources10.6% unrealistic expectations9.9% lack of executive support9.3% changing requirements and specifications8.7% lack of planning8.1% system no longer needed7.5% IMPORTANCE OF REQUIREMENTS CAPTURE — 1  Requirements capture is involved in a majority of cases > 50% 4.1

6. 310414 REQUIREMENTS CAPTURE 5/67 IMPORTANCE OF REQUIREMENTS CAPTURE — 2 cost to find and fix a defect log scale 1 10 100 Reqmts 0.75 Design 1.00 Code 1.50 Test 3.00 System test 10.00 Field use 60-100  BUT, requirements capture is VERY DIFFICULT!

7. 310414 REQUIREMENTS CAPTURE 6/67 WHY REQUIREMENTS CAPTURE IS DIFFICULT Our aim is to build the right system  a system that meets the users ’ needs but, users often do not know what they need! –many types of users (only know their own work and needs) –may not see the “ big ” picture (do not know entire flow of work) –may not know which aspects of their work can be computerized  for the software engineer, requirements capture is often a “ discovery and learning ” process need to get users to understand what we have captured and to approve that it meets their needs  users need to be able to understand our specifications but, user is usually not a computer specialist! Major challenges

8. 310414 REQUIREMENTS CAPTURE 7/67 REQUIREMENTS CAPTURE PROCESS — OVERVIEW Identify and understand user needs –define the goals of the system – compile list of system constraints –compile list of candidate requirements – define development effort scope Determine feasibility –economic feasibility – operational feasibility –technical feasibility – organizational impact Understand, capture and document system requirements –static (persistent data) – dynamic (processing + constraints) (domain model + specifications)(use-case model + specifications) Validate the system requirements –criteria for user acceptance of the completed system (acceptance tests) every software project is unique – > need to adapt our process

9. 310414 REQUIREMENTS CAPTURE 8/67 USER NEEDS — IDENTIFICATION collect data on application domain (may include existing system) investigation ® existing documentation observation ® work practices interviews ® questionnaires, personal prototyping ® interface, functions –challenge customer ’ s/user ’ s model of reality –elicit problems, not solutions –distinguish needs from wants; rate importance of needs refine system goals, list of requirements, list of constraints, system scope, etc. propose scope of project (what is included, what is excluded) document requirements  system requirements specification  serves as a contract between the customer and developer! 4.5.1

10. 310414 REQUIREMENTS CAPTURE 9/67 USER NEEDS — DATA COLLECTION challenge customer ’ s/users ’ model of the world people: a) filter out, b) distort, and/or c) generalize information  e.g., challenge statements containing universal quantifiers such as, all, everyone, always, never, nobody, none! elicit problems, not solutions Not this: “ We need to put in a teleconferencing network among our offices. ” But this: “ Our offices are not communicating in a timely manner. ” distinguish needs from wants; rate importance of needs needs: features critical to the system ’ s success wants: features nice to have, but not essential

11. 310414 REQUIREMENTS CAPTURE 10/67 FEASIBILITY DETERMINATION  Can we/should we build the system? economic feasibility –costs (development, operation) versus benefits –tangible versus intangible technical feasibility –availability of technology  risk of new technology? –maintenance required operational feasibility –availability of skills to operate the system –fit with current work practices (redesign work practices?) organizational feasibility –politics; training; user acceptance;... legal feasibility –liability; copyright; patent;...

12. 310414 REQUIREMENTS CAPTURE 11/67 CAPTURE AND DOCUMENT SYSTEM REQUIREMENTS static requirements (persistent data) ® domain model describes the important concepts of the application domain as classes  allows the development of a glossary of terms (data dictionary) for communicating among everyone on the project dynamic requirements (processing+constraints) ® use-case model functional requirements - describe the interactions between the system and its environment independent of its implementation nonfunctional requirements - describe user-visible aspects of the system that are not directly related with the functional behaviour of the system  e.g., response time, throughput, security, etc. pseudo requirements - describe restrictions on the implementation of the system imposed by the customer  e.g., implementation language, platform, etc. Requirements should only state what is needed not how it is done

13. 310414 REQUIREMENTS CAPTURE 12/67 Inception Elaboration ConstructionTransition REQUIREMENTS CAPTURE — LIFE CYCLE ROLE Phases Core Workflows Requirements Analysis Design Implementation Testing iter. #1 iter. #2 ————— iter. #n-1 iter. #n Increments Iteration

14. 310414 REQUIREMENTS CAPTURE 13/67 requirements capture is in focus here SYSTEM REQUIREMENTS CAPTURE system requirements capture constructs two main models: –domain model: describes the system ’ s static (data) requirements –use-case model: describes the system ’ s dynamic (processing) requirements the domain model and use-case model are developed over several development increments (mainly during the inception and elaboration phases)  inception phase: identify most domain model elements and use cases in order to delimit the system and scope the project (detail the most critical use cases – less than 10%)  elaboration phase: capture most (80%) of the remaining requirements so we can estimate the size of the development effort –construction phase: capture remaining requirements and implement the system –transition phase: no requirements capture unless there are changing requirements

15. 310414 REQUIREMENTS CAPTURE 14/67 ARTIFACTS & WORKERS Use-Case Specifier Use-Case Specification responsible for User-Interface Designer User-interface Specification & Prototyping responsible for Architect Architecture Description responsible for Domain Analyst responsible for Domain Specification System Analyst Domain Model Actors Glossary Use-Case Model responsible for

16. 310414 REQUIREMENTS CAPTURE 15/67 ARTIFACTS domain model - a model of the persistent classes and their associations in the context of the system – > captures data requirements use-case model - a model of the system containing actors and use cases and their relationships – > captures functional requirements actors - users of the system, outside the system, that collaborate with the system – > represents the external environment glossary - defines important and common terms used by analysts and other developers domain specification - a description of the classes and associations in the domain model use case specification - a description of some functionality that the system offers for an actor – > abstraction of a set of scenarios user-interface specification & prototyping - helps in understanding and specifying the interactions between human actors and the system architecture description - depicts the architecturally significant use cases (5-10%); those that describe some important and critical functionality or that involve some important requirement

17. 310414 REQUIREMENTS CAPTURE 16/67 WORKERS system analyst - responsible for the whole set of requirements; delimits system; finds classes and associations; finds actors and use cases domain analyst - assists the system analyst in specifying detailed descriptions of one or more classes and their associations architect - describes the architectural view of the use-case model use-case specifier - assists the system analyst in specifying detailed descriptions of one or more use cases user-interface designer - visually shapes the user interface

18. 310414 REQUIREMENTS CAPTURE 17/67 UP — SYSTEM REQUIREMENTS CAPTURE PROCESS ArchitectSystem Analyst Use-Case Specifier Find Classes and Associations Prioritize Use Cases Prototype User-Interface Detail Use Cases Structure the Use-Case Model User-Interface Designer Find Actors and Use Cases Domain Analyst Detail Classes and Associations

19. 310414 REQUIREMENTS CAPTURE 18/67 DOMAIN MODELING captures the most important classes and their associations in the context of the system  things that exist or events that occur in the system ’ s environment found from –high-level problem statement –lower-level requirements –domain experts (users)  imperative that this be done well so as to establish a solid foundation and to allow reuse by other systems classes can be: –business objects (e.g., orders, accounts, etc.) –real-world objects and concepts (e.g., suppliers, customers, etc.) –events (e.g., aircraft arrival/departure, sales, reservations, etc.)  described in a class diagram ® static system structure

20. 310414 REQUIREMENTS CAPTURE 19/67 IDENTIFYING CLASSES & ASSOCIATIONS naturally occurring things or concepts in the application domain –classes often appear as nouns/noun phrases in application domain terminology –associations often appear as verbs/verb phrases in application domain terminology  circle or highlight in problem description  put all terms into singular form/active voice decomposition of a problem into classes and associations depends on judgement and experience and the nature of the problem identify only relevant classes ® those that are essential throughout the system ’ s life cycle  leads to a stable system

21. 310414 REQUIREMENTS CAPTURE 20/67 ASU — COURSE REGISTRATION PROBLEM STATEMENT At the beginning of each semester, students may request a course catalog containing a list of course offerings needed for the semester. Information about each course, such as instructor, department, and prerequisites are included to help students make informed decisions. The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or is canceled. No course offering will have more than ten students or fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. Professors must be able to access the online system to indicate which courses they will be teaching, and to see which students signed up for their course offerings. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses.

22. 310414 REQUIREMENTS CAPTURE 21/67 DOMAIN MODEL — KEEPING THE RIGHT CLASSES Are any classes redundant? Are any classes irrelevant to the application domain? Are any classes vague (ill-defined)? Should any classes really be attributes? Do any classes describe an operation? Do any class names describe a role? Do any classes describe implementation constructs?

23. 310414 REQUIREMENTS CAPTURE 22/67 DOMAIN MODEL— KEEPING THE RIGHT ASSOCIATIONS Are there any associations between eliminated classes? Are any associations irrelevant to the application domain? Do any associations describe an operation? Can ternary associations be decomposed into binary associations? Are any associations derived associations? Are any associations named with “ how ” or “ why ” names? Are role names required for any associations? Should any associations be qualified? Are multiplicity, ordering specifications missing? Do any associations describe implementation constructs?

24. 310414 REQUIREMENTS CAPTURE 23/67 DOMAIN MODEL — KEEPING THE RIGHT ATTRIBUTES Are attributes closely related to the class they are in? Should any attributes really be classes? Should any attributes be qualifiers? Have object identifiers been included as attributes? Should any attributes be in an association class?

25. 310414 REQUIREMENTS CAPTURE 24/67 DOMAIN MODEL DETAIL— ATTRIBUTES meaningful name itemPrice not itpr allowable values  continuous - a range of values price: $0 to $10,000 need to note:range typical values exception handling  discrete - only allow certain values marital-status:single, married, widowed, divorced need to note:values and meaning of each (if coded) short description payment -a transaction to record a remittance deposit -the initial amount paid by the company on a purchase order aliases  synonyms - same meaning, but different name customer = client  acronyms - shortened name requisitionNumber = requisNum, reqNo length – as found in the real world  number of digits or letters encoding - physical representation of the value  only if no choice allowed in design phase supplementary - other information relevant to use of the attribute

26. 310414 REQUIREMENTS CAPTURE 25/67 DOMAIN MODEL DETAIL— CLASSES & ASSOCIATIONS for each class we can add any operations that we are aware of at this stage  most operations will be added during analysis & design for each association we need to specify (if known): –a name (optional) –role names (as necessary) –multiplicity –association class (if necessary)  Place all domain model terms and their definitions in a glossary of terms/data dictionary

27. 310414 REQUIREMENTS CAPTURE 26/67 DOMAIN MODEL DETAIL — GENERALIZATION classify classes according to similarity of attributes and operations  look for “ kind-of ” statements that are true in the real world do not nest too deeply –2-3 levels  OK –4-6 levels  maybe –10 levels  too deep! Goal: Goal: simplicity of representation and modeling clarity  Need to decide how to handle associations in which subclasses participate

28. 310414 REQUIREMENTS CAPTURE 27/67 District * 11 * LivesIn DOMAIN MODEL DETAIL — GENERALIZATION (cont’d) Person StudentProfessor District *1 LivesIn

29. 310414 REQUIREMENTS CAPTURE 28/67 * 1 LivesIn DOMAIN MODEL DETAIL — GENERALIZATION (cont’d) 1 * * 11 * LivesIn Person StudentProfessor District StudiesIn

30. 310414 REQUIREMENTS CAPTURE 29/67 USE-CASE MODELING EXAMPLE A video sales and rental shop would like to computerize its management of sales and rental of its movie videos. As well, it would like to establish a presence on the Web and allow its customers to rent and buy videos via the Web. Below are the high-level requirements for a system that will manage the sale and rental of videos for the video shop: –The system must be able to keep track of which movie videos have been bought/rented and by whom. For videos bought, the system must record the quantity bought; for videos rented, the system must record which copy of the video has been rented and when it is due back. –The system must keep track of overdue rental videos and allow notices to be sent to customers who have videos overdue. –The video shop will have a customer membership option for an annual fee, which will entitle the member to discounts (10%) on video sales and rentals. –Members should be able to make reservations for movie video rentals either in person at the store, by telephone or via the Web. –A member can reserve at most five movie videos at any one time, but there is no limit on how many movie videos a member or nonmember can rent at any one time. –As an added feature, the video shop would like to allow customers (either members or nonmembers) to input, via the Web, mini-reviews (up to 100 words)

31. 310414 REQUIREMENTS CAPTURE 30/67 USE-CASE MODELING EXAMPLE (cont’d) and a rating (from 1, lowest, to 5, highest) of movies they have rented. These reviews should be anonymous if the customer so wishes (i.e., the customer can specify whether or not he wants his name to be made known when other customers browse the reviews). –The video shop maintains the following information about all customers (members or nonmembers): name, address, phone number, fax number, age, sex, and email address. In addition, members are assigned a membership number by the video shop when they become members and a password, which allows them to access the members-only area of the video shop's web site, including accessing and changing their personal information. –Using the Web, customers should be able to buy and rent videos and browse the reviews entered by other customers. –Managers must be able to generate various reports on sales/rentals of videos. –Staff must be able to sell/rent videos from the store ’ s inventory and return rented videos to the store's inventory. –When selling or renting videos, staff must be able to look up customer information and determine whether the customer is a member. –An employee must be able to enter the basic information about a movie video (i.e., title, leading actor(s), director, producer, genre, synopsis, release year, running time, selling price, and rental price).

32. 310414 REQUIREMENTS CAPTURE 31/67 DOMAIN MODELING EXAMPLE — ANALYSIS We first analyze the stated domain model requirements and then present the domain model. –The system must be able to keep track of which movie videos have been bought/rented and by whom. For videos bought, the system must record the quantity bought; for videos rented, the system must record which copy of the video has been rented and when it is due back. –The system must keep track of overdue rental videos and allow notices to be sent to customers who have videos overdue. –The video shop will have a customer membership option for an annual fee, which will entitle the member to discounts (10%) on video sales and rentals.

33. 310414 REQUIREMENTS CAPTURE 32/67 DOMAIN MODELING EXAMPLE — ANALYSIS –Members should be able to make reservations for movie video rentals either in person at the store, by telephone or via the Web. –A member can reserve at most five movie videos at any one time, but there is no limit on how many movie videos a member or nonmember can rent at any one time. –As an added feature, the video shop would like to allow customers (either members or nonmembers) to input, via the Web, mini-reviews (up to 100 words) and a rating (from 1, lowest, to 5, highest) of movies they have rented. These reviews should be anonymous if the customer so wishes (i.e., the customer can specify whether or not he wants his name to be made known when other customers browse the reviews).

34. 310414 REQUIREMENTS CAPTURE 33/67 DOMAIN MODELING EXAMPLE — ANALYSIS –The video shop maintains the following information about all customers (members or nonmembers): name, address, phone number, fax number, age, sex, and email address. In addition, members are assigned a membership number by the video shop when they become members and a password, which allows them to access the member's only area of the video shop's web site, including accessing and changing their personal information. –Using the Web, customers should be able to buy and rent videos and browse the reviews entered by other customers. –Managers must be able to generate various reports on sales/rentals of videos. –Staff must be able to sell/rent videos from the store ’ s inventory and return rented videos to the store's inventory.

35. 310414 REQUIREMENTS CAPTURE 34/67 DOMAIN MODELING EXAMPLE — ANALYSIS –When selling or renting videos, staff must be able to look up customer information and determine whether the customer is a member. –An employee must be able to enter the basic information about a movie video (i.e., title, leading actor(s), director, producer, genre, synopsis, release year, running time, selling price, and rental price).

36. 310414 REQUIREMENTS CAPTURE 35/67 TOP 10 DOMAIN MODELING ERRORS 10.Start assigning multiplicities to associations right off the bat. Make sure that every association has an explicit multiplicity. 9.Do noun and verb analysis so exhaustive that you pass out along the way. 8.Assign operations to classes without exploring use cases and sequence diagrams. 7.Optimize your code for reusability before making sure you’ve satisfied the users’ requirements. 6.Debate whether to use aggregation or composition for each of your part-of associations. 5.Presume a specific implementation strategy without modeling the problem space. 4.Use hard-to-understand names for your classes—like CPortMgrIntf—instead of intuitively obvious ones, such as PortfolioManager. 3.Jump directly to implementation constructs such as friend relationships and parameterized classes. 2.Create a one-for-one mapping between domain classes and relational database tables. 1.Perform “premature patternization,” which involves building cool solutions, from patterns, that have little or no connection to user problems.

37. 310414 REQUIREMENTS CAPTURE 36/67 USE-CASE MODELING captures the system behavior from the users ’ point of view developed in cooperation with the domain model helps in: –capturing data and functional requirements –planning iterations of development –validating the system dynamic model gets started with use-case analysis  drives the entire development effort  all required functionality is described in the use cases  use-case model is developed incrementally 2.2.1; 2.4.1

38. 310414 REQUIREMENTS CAPTURE 37/67 Something outside the system that interacts directly with it USE CASE MODEL — ACTORS actor name actors are the source for discovering use cases 4.4.1 can be people or other systems provides input to or takes output from the system a role a user can play ® multiple roles per user; multiple users per role An actor is a stereotype of class an actor is a classifier; a specific user is an instance

39. 310414 REQUIREMENTS CAPTURE 38/67 IDENTIFYING ACTORS Who or what uses the system? What roles do they play in the interaction? Who gets and provides information to the system? Who installs, starts and shuts down or maintains the system? What other systems interact with this system? Does anything happen at a fixed time?  Input devices are not actors!  It is common to have both a domain model class and an actor that represent the same thing.  Time can be an actor.  For each actor, briefly the describe role it plays when interacting with the system.

40. 310414 REQUIREMENTS CAPTURE 39/67 ASU — ACTORS At the beginning of each semester, students may request a course catalog containing a list of course offerings needed for the semester. Information about each course, such as instructor, department, and prerequisites are included to help students make informed decisions. The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or is canceled. No course offering will have more than ten students or fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. Professors must be able to access the online system to indicate which courses they will be teaching, and to see which students signed up for their course offerings. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses.

41. 310414 REQUIREMENTS CAPTURE 40/67 USE CASE MODEL — USE CASE A specific way of using the system by performing some part of its functionality use-case name initially, we are only concerned with the normal or usual sequence of events/actions  ignore exceptions, alternate ways of doing things 2.4.1; 4.4.3 specifies the interaction that takes place between an actor and the system ® considered from the user ’ s viewpoint constitutes a complete sequence of events/actions initiated by an actor A use case is a stereotype of class use case is a classifier; scenario is an instance

42. 310414 REQUIREMENTS CAPTURE 41/67 IDENTIFYING USE CASES What are the tasks that an actor wants the system to perform? What information does an actor access (create, store, change, remove, or read) in the system? Which external changes does an actor need to inform the system about? Which events does an actor need to be informed about by the system? How will the system be supported and maintained?  use case name should be stated from the perspective of the user as a present-tense, verb phrase in active voice  provide a description of the purpose of the use case and a high-level definition of its functionality  use application domain terms in descriptions

43. 310414 REQUIREMENTS CAPTURE 42/67 ASU — USE CASES At the beginning of each semester, students may request a course catalog containing a list of course offerings needed for the semester. Information about each course, such as instructor, department, and prerequisites are included to help students make informed decisions. The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or is canceled. No course offering will have more than ten students or fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester.

44. 310414 REQUIREMENTS CAPTURE 43/67 ASU — USE CASES Professors must be able to access the online system to indicate which courses they will be teaching, and to see which students signed up for their course offerings. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses.

45. 310414 REQUIREMENTS CAPTURE 44/67 USE-CASE MODEL — SCENARIO A concrete, focused, informal description of a single use of the system from the viewpoint of a single actor  an attempt to carry out a use case types of scenarios used in software development as-is-describes a current situation (used to understand the current system) visionary-describes a future system evaluation-describes user tasks to be used to evaluate the system (e.g., acceptance tests) training-used for introducing new users to the system 2.4.1; 4.4.2  used to gain a shared understanding between developers and users of what the system should do

46. 310414 REQUIREMENTS CAPTURE 45/67 IDENTIFYING SCENARIOS Since scenarios are instances of use cases, the same questions can be asked as for identifying uses cases. Note: two viewpoints of use-case modeling 1.top-down:start with use cases, refine with scenarios 2. bottom-up:start with scenarios, abstract use cases  In reality, the use case specifier uses both viewpoints  BUT scenarios mostly used to describe errors and alternate flows

47. 310414 REQUIREMENTS CAPTURE 46/67 WHAT IS A GOOD USE CASE? A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor. Consider students in ASU Course Registration System: –select courses –be added to course offerings –be billed deals with one complete sequence of events/actions Consider Registrar in ASU Course Registration System: –add courses –delete courses –modify courses deals with the same class of objects Generally, it is better to have longer and more extensive use cases than smaller ones

48. 310414 REQUIREMENTS CAPTURE 47/67 WHAT IS A GOOD USE CASE? Arguments for larger use cases 1.We can follow a complete flow through the system 2.From the customer ’ s point of view, it is a logical, cohesive flow of events in the system. 3.Testing may be more effective since a large use case covers more logical cohesive events in the system and failures can be found more easily. 4.It is easier to synchronize the use case since it is one sequence that starts different events in chronological order. Arguments for smaller use cases 1.It may be troublesome to find the right instance of a use case that is of large enough extent since the use case may very well last for several days. 2.From a potential actor ’ s view, it is more logical to have use cases that the actor starts. 3.It may be easier to test the use case since every use case starts from external events and not from internal events.

49. 310414 REQUIREMENTS CAPTURE 48/67 USE-CASE DETAIL — FLOW OF EVENTS A precise, but easy to read, description of the sequence of actions needed to accomplish a scenario/use case  what the system and the actor should do to perform the actions (not how it is done; ignore use case interactions) Basic path:shows one complete normal path from start to end — no errors, no exceptions (always required). Alternate paths: show exceptional conditions or errors.  start with basic path, then add alternate paths as needed Goal: Goal: specify everything the user might do

50. 310414 REQUIREMENTS CAPTURE 49/67 USE CASE DETAIL — USE CASE SPECIFICATION use case name participating actors preconditions (usually on the system state; relevant to this use case) –things that must be true before the use case can execute flow of events –required order of actions ® the normal sequence of events –what interaction the use case has with the actors –what data is needed by the use case postconditions (usually on the system state; relevant to this use case) –things that must be true at the end of the use case execution special requirements (if any) alternate or exceptional flows (if any) Narrative should be event-response oriented (i.e., The system does X. The user does Y. etc.)

51. 310414 REQUIREMENTS CAPTURE 50/67 USE CASE DETAIL — FLOW OF EVENTS SPECIFICATION branching n.If boolean-expression n.1. declarative-statement n.2. declarative-statement n.3. … n+1. repetition: For n.For iteration-expression n.1. declarative-statement n.2. declarative-statement n.3. … n+1. repetition: While n.While boolean-expression n.1. declarative-statement n.2. declarative-statement n.3. … n+1. sequence of short steps that are numbered, declarative, and time-ordered n. The something some-action.(e.g., 3. The user enters a login id.) √ repetition should be used sparingly! √ use-case specification should be kept as simple as possible

52. 310414 REQUIREMENTS CAPTURE 51/67 USE-CASE MODEL DETAIL — GENERALIZATION Since actors and use cases are classifiers, they can be generalized. ManagerSales clerk  represents a design decision! Employee Validate user Check password Retinal scan 2.4.1

53. 310414 REQUIREMENTS CAPTURE 52/67 USE-CASE DETAIL — INCLUDE many use cases may share pieces of the same functionality we can factor out this functionality, place it in a separate use case and relate it to all use cases that need to use it by an > relationship Validate user > Register for coursesSelect courses to teachRequest enrollment list >  represents a design decision! include use case (usually not invoked directly by user) main use cases (invoked directly by user) 2.4.1; 4.4.5

54. 310414 REQUIREMENTS CAPTURE 53/67 models conditional additions to a use case ’ s sequence of actions used to show: –optional behavior –behavior that is executed only under certain conditions –several different subflows that are executed based on the selection of a particular actor USE-CASE DETAIL — EXTEND specifies how a use case description may be inserted into, and thus extend, an existing use case > (semester invalid) Select courses to teach extend use case main use case Invalid semester  represents a design decision! extension point label 2.4.1; 4.4.5

55. 310414 REQUIREMENTS CAPTURE 54/67 IDENTIFYING NONFUNCTIONAL REQUIREMENTS user-visible system properties that cannot be expressed as use cases, but often place constraints on the use cases –performance (time and throughput) requirements –reliability requirements –the environment in which the software is to operate –possible error sources and suitable measures for the prevention of such errors and/or the minimization of their effect –constraints on implementation — hardware, quality, etc. –life-cycle considerations — schedule, budget, etc. 4.4.7 Captured as supplementary requirements on use cases or on the system as a whole

56. 310414 REQUIREMENTS CAPTURE 55/67 USE CASES THROUGH THE DEVELOPMENT Planning –Basis for negotiation with customer  determine which use cases to provide in the first release Political aspects –Demonstrate the system doing something valuable to the most influential people first  use knowledge about how much each user wants their use case Technical aspects –Deliver the highest risk use cases first  use knowledge from risk analysis System validation –“ walk the use case ” to see if it can provide the required functionality

57. 310414 REQUIREMENTS CAPTURE 56/67 USE-CASE MODELING EXAMPLE A video sales and rental shop would like to computerize its management of sales and rental of its movie videos. As well, it would like to establish a presence on the Web and allow its customers to rent and buy videos via the Web. Below are the high-level requirements for a system that will manage the sale and rental of videos for the video shop: –The system must be able to keep track of which movie videos have been bought/rented and by whom. For videos bought, the system must record the quantity bought; for videos rented, the system must record which copy of the video has been rented and when it is due back. –The system must keep track of overdue rental videos and allow notices to be sent to customers who have videos overdue. –The video shop will have a customer membership option for an annual fee, which will entitle the member to discounts (10%) on video sales and rentals. –Members should be able to make reservations for movie video rentals either in person at the store, by telephone or via the Web. –A member can reserve at most five movie videos at any one time, but there is no limit on how many movie videos a member or nonmember can rent at any one time. –As an added feature, the video shop would like to allow customers (either members or nonmembers) to input, via the Web, mini-reviews (up to 100 words)

58. 310414 REQUIREMENTS CAPTURE 57/67 USE-CASE MODELING EXAMPLE (cont’d) and a rating (from 1, lowest, to 5, highest) of movies they have rented. These reviews should be anonymous if the customer so wishes (i.e., the customer can specify whether or not he wants his name to be made known when other customers browse the reviews). –The video shop maintains the following information about all customers (members or nonmembers): name, address, phone number, fax number, age, sex, and email address. In addition, members are assigned a membership number by the video shop when they become members and a password, which allows them to access the members-only area of the video shop's web site, including accessing and changing their personal information. –Using the Web, customers should be able to buy and rent videos and browse the reviews entered by other customers. –Managers must be able to generate various reports on sales/rentals of videos. –Staff must be able to sell/rent videos from the store ’ s inventory and return rented videos to the store's inventory. –When selling or renting videos, staff must be able to look up customer information and determine whether the customer is a member. –An employee must be able to enter the basic information about a movie video (i.e., title, leading actor(s), director, producer, genre, synopsis, release year, running time, selling price, and rental price).

59. 310414 REQUIREMENTS CAPTURE 58/67 USE-CASE MODELING EXAMPLE — ANALYSIS We first analyze the functional requirements of the system and then present the use-case model. Note that for the purposes of producing the use-case model, we are only really interested in those functional requirements that provide something of value for some actor. – The system must be able to keep track of which movie videos have been bought/rented and by whom. For videos bought, the system must record the quantity bought; for videos rented, the system must record which copy of the video has been rented and when it is due back. – The system must keep track of overdue rental videos and allow notices to be sent to customers who have videos overdue.

60. 310414 REQUIREMENTS CAPTURE 59/67 USE-CASE MODELING EXAMPLE — ANALYSIS – The video shop will have a customer membership option for an annual fee, which will entitle the member to discounts (10%) on video sales and rentals. – Members should be able to make reservations for movie video rentals either in person at the store, by telephone or via the Web. – A member can reserve at most five movie videos at any one time, but there is no limit on how many movie videos a member or nonmember can rent at any one time.

61. 310414 REQUIREMENTS CAPTURE 60/67 USE-CASE MODELING EXAMPLE — ANALYSIS – As an added feature, the video shop would like to allow customers (either members or nonmembers) to input, via the Web, mini-reviews (up to 100 words) and a rating (from 1, lowest, to 5, highest) of movies they have rented. These reviews should be anonymous if the customer so wishes (i.e., the customer can specify whether or not he wants his name to be made known when other customers browse the reviews). – The video shop maintains the following information about all customers (members or nonmembers): name, address, phone number, fax number, age, sex, and email address. In addition, members are assigned a membership number by the video shop when they become members and a password, which allows them to access the members-only area of the video shop's web site, including accessing and changing their personal information.

62. 310414 REQUIREMENTS CAPTURE 61/67 USE-CASE MODELING EXAMPLE — ANALYSIS – Using the Web, customers should be able to buy and rent videos and browse the reviews entered by other customers. – Managers must be able to generate various reports on sales/rentals of videos. – Staff must be able to sell/rent videos from the store ’ s inventory and return rented videos to the store's inventory. – When selling or renting videos, staff must be able to look up customer information and determine whether the customer is a member or not.

63. 310414 REQUIREMENTS CAPTURE 62/67 USE-CASE MODELING EXAMPLE — ANALYSIS – An employee must be able to enter the basic information about a movie video (i.e., title, leading actor(s), director, producer, genre, synopsis, release year, running time, selling price, and rental price).

64. 310414 REQUIREMENTS CAPTURE 63/67 TOP 10 USE-CASE MODELING ERRORS 10.Write functional requirements instead of usage scenario text. 9.Describe attributes and methods rather than usage. 8.Write the use case too tersely (i.e., without enough detail). 7.Divorce yourself completely from the user interface. 6.Avoid explicit names for your use cases. 5.Write using a perspective other than the user’s, in passive voice. 4.Describe only user interactions; ignore system responses. 3.Omit descriptions for alternate courses of action. 2.Focus on something other than what’s “inside” a use case, such as how you get there (precondition) or what happens afterward (postcondition). 1.Spend a month deciding whether to use include or extend.

65. 310414 REQUIREMENTS CAPTURE 64/67 VALIDATE SYSTEM REQUIREMENTS requirements should be continuously validated with the customer and the user and they should be: correct - represent the customer ’ s view of the system  everything in the requirements model accurately represents an aspect of the system complete - all possible scenarios through the system are described, including exceptional behaviour  all aspects of the system are represented in the requirements model consistent - do not contradict themselves unambiguous - exactly one system is defined  it is not possible to interpret the specification two or more different ways realistic - the system can be implemented within the constraints  correctness and completeness often difficult to show 4.3.4

66. 310414 REQUIREMENTS CAPTURE 65/67 VALIDATE REQUIREMENTS — ACCEPTANCE TESTS Functional validity – does the system provide the required functionality and obey the required constraints?  Show that a professor can select a course offering to teach.  Show that a student cannot register for more than four courses. Interface validity – do interfaces perform desired functions (accept desired input/provide desired output) and follow consistent design standards?  Show that all required data for course registration can be input. Information content – are the data structures/data bases correct (store the right data in the required format)?  Show that all required information of a student ’ s course schedule is shown. Performance – does the system meet specified performance criteria?  Show the response time to register for a course is less than 1 second. Tests must be specified that will demonstrate to the customer that all functions and constraints of a system are fully operational

67. 310414 REQUIREMENTS CAPTURE 66/67 DERIVING AN ACCEPTANCE TEST PLAN restate written requirements in a concise, precise and testable way –group related requirements –remove any requirements that cannot be tested add any additional requirements gathered from users –look at use cases for functional and interface requirements –look at domain model for information content requirements –look at nonfunctional requirements for performance requirements construct, for each requirement, an evaluation scenario that will demonstrate to the customer that the requirement is met (since most evaluation scenarios depend on the user interface, they can not be completed until the user interface is designed)

68. 310414 REQUIREMENTS CAPTURE 67/67 SUMMARY — SYSTEM REQUIREMENTS CAPTURE requirements are captured over several iterations by specifying: –a domain model –a use-case model –initial user interfaces (and building some user interface prototypes) –an acceptance test plan  These are all documented in the System Requirements Specification (SRS)  Use cases drive the subsequent iterations/phases in subsequent iterations/phases we refine and/or transform the requirements by specifying: –more detail for each of the above artifacts –matching use-case realizations in analysis model –matching use-case realizations in design model –a set of test cases in the test model