2. 310313 REQUIREMENTS CAPTURE 1 SYSTEM REQUIREMENTS CAPTURE 310313 SOFTWARE ENGINEERING 310313 SOFTWARE ENGINEERING

3. 310313 REQUIREMENTS CAPTURE 2 LEARNING OBJECTIVES 1. Understand the role and importance of requirements capture in the software development process. 2. Know the major activities that take place during requirements capture. 3. Understand that the majority of system requirements can be captured by building two models: domain model and use-case model. 4. Learn how to capture and model the data requirements and the processing requirements of a system. 5. Learn how to design acceptance tests to validate the system requirements. 6. Know the characteristics of people that every software engineer should understand to build effective user interfaces.

4. 310313 REQUIREMENTS CAPTURE 3 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

5. 310313 REQUIREMENTS CAPTURE 4

6. 310313 5 SYSTEM REQUIREMENTS CAPTURE: LIFE CYCLE ROLE 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—going first breadth, then depth (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 th 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. requirements capture is in focus here

7. 310313 REQUIREMENTS CAPTURE 6 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

8. 310313 REQUIREMENTS CAPTURE 7 SYSTEM REQUIIREMENTS CAPTURE: WORKRS The system analyst is responsible for the whole set of requirements. He delimits the system and finds classes, associations, actors and use cases. The domain analyst assists the system analyst in specifying detailed descriptions of one or more classes and their associations. The use-case specifier assists the system analyst in specifying detailed descriptions of one or more use cases. He works closely with users of use case(s). The user-interface designer visually shapes the user interface. The architect describes the architectural view of the use-case model and selects architecturally significant use cases.

9. 310313 REQUIREMENTS CAPTURE 8 SYSTEM REQUIIREMENTS CAPTURE: ARTIIFACTS The domain model is a model of the persistent classes and their associations in the context of the system.  It captures data requirements. The use-case model is a model of the system containing actors and use cases and their relationships.  It captures functional requirements. The actors are users of the system, outside the system, that collaborate with the system.  They represent the external environment of the system. The glossary defines important and common terms used by analysts and other developers. The domain specification is a description of the classes and associations in the domain model. The use case specification is a description of some functionality that the system offers for an actor.  It is abstraction of a set of scenarios. The user-interface specification & prototyping helps in understanding and specifying the interactions between human actors and the system. The architecture description depicts the architecturally significant use cases (5-10%). Those that describe some important and critical functionality or that involve some important requirement that must be developed early in the system s life cycle. It is used as input when use cases are prioritized for development.

10. 310313 REQUIREMENTS CAPTURE 9 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 The results of requirements capture also help in project planning.  requires the collaboration of several groups of participants with different backgrounds KnowledgeGAPKnowledgeGAP 4

11. 310313 REQUIREMENTS CAPTURE 10 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

12. 310313 REQUIREMENTS CAPTURE 11 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!

13. 310313 REQUIREMENTS CAPTURE 12 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

14. 310313 REQUIREMENTS CAPTURE 13 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) System Requirements Specification (SRS) documents requirements. (Serves as a contract between the client and developer!).

15. 310313 REQUIREMENTS CAPTURE 14 USER NEEDS — IDENTIFICATION collect data on application domain (may include existing system) investigation  existing documentation observation  work practices interviews  questionnaires, personal prototyping  interface, functions –In doing so it is important to:  elicit problems, not solutions  distinguish needs (critical) from wants (nice to have)  prioritize needs  challenge client’s/users’ model of the world Define the scope of the development effort. –What is inside/outside the system? Who decides? Define the system’s design goals. –What “qualities” do we want the system to have? 4.5.1 Effective communication skills needed to gather requirements.

16. 310313 REQUIREMENTS CAPTURE 15 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

17. 310313 REQUIREMENTS CAPTURE 16 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;...

18. 310313 REQUIREMENTS CAPTURE 17 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

19. 310313 REQUIREMENTS CAPTURE 18 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

20. 310313 REQUIREMENTS CAPTURE 19 DOMAIN MODELING 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 The class and association are found from –high-level problem statement --  a specification of user needs. –domain experts (users) --  by collecting data & identifying user needs.  It is imperative that this be done well so as to establish a solid foundation and to allow reuse by other systems The 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

21. 310313 REQUIREMENTS CAPTURE 20 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

22. 310313 REQUIREMENTS CAPTURE 21 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 forty students or fewer than ten students. A course offering with fewer than ten 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.

23. 310313 REQUIREMENTS CAPTURE 22 ASU: POSSIBLE CLASSES 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.

24. 310313 REQUIREMENTS CAPTURE 23 ASU: POSSIBLE CLASSES No course offering will have more than forty students or fewer than ten 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.

25. 310313 REQUIREMENTS CAPTURE 24 ASU: POSSIBLE CLASSES 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.

26. 310313 REQUIREMENTS CAPTURE 25 ASU: POSSIBLE ASSOCIATIONS 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.

27. 310313 REQUIREMENTS CAPTURE 26 ASU: POSSIBLE ASSOCIATIONS 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 forty students or fewer than ten students. A course offering with fewer than three students will be canceled.

28. 310313 REQUIREMENTS CAPTURE 27 ASU: POSSIBLE ASSOCIATIONS 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.

29. 310313 REQUIREMENTS CAPTURE 28 ASU: POSSIBLE ASSOCIATIONS 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.

30. 310313 REQUIREMENTS CAPTURE 29 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?

31. 310313 REQUIREMENTS CAPTURE 30 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? Do any associations describe implementation constructs?

32. 310313 REQUIREMENTS CAPTURE 31 IDENTIFYING ATTRIBUTES Usually correspond to nouns followed by possessive phrases –e.g., password of the student; student’s address. Adjectives usually represent specific enumerated values –e.g., Fall semester; PhD degree. Attributes are likely to be fully specified in the problem statement. Draw on knowledge of the application domain and real world. Only specify attributes that directly relate to the application domain. Most attributes will not be given in a problem statement and will have to be obtained from domain experts or application documentation.

33. 310313 REQUIREMENTS CAPTURE 32 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?

34. 310313 REQUIREMENTS CAPTURE 33 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)-->should say”what” not “how” or “why” –role names (as necessary) –Multiplicity (If Known) –association class (if necessary) Place all domain model terms and their definitions in a glossary of terms/data dictionary

35. 310313 REQUIREMENTS CAPTURE 34 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  need to note: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

36. 310313 REQUIREMENTS CAPTURE 35 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

37. 310313 REQUIREMENTS CAPTURE 36 District * 11 * LivesIn DOMAIN MODEL DETAIL — GENERALIZATION (cont’d) Person StudentProfessor District *1 LivesIn

38. 310313 REQUIREMENTS CAPTURE 37 * 1 LivesIn DOMAIN MODEL DETAIL — GENERALIZATION (cont’d) 1 * * 11 * LivesIn Person StudentProfessor District StudiesIn

39. 310313 REQUIREMENTS CAPTURE 38 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)

40. 310313 REQUIREMENTS CAPTURE 39 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).

41. 310313 REQUIREMENTS CAPTURE 40 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.

42. 310313 REQUIREMENTS CAPTURE 41 DOMAIN MODELING EXAMPLE — ANALYSIS –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.

43. 310313 REQUIREMENTS CAPTURE 42 DOMAIN 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.

44. 310313 REQUIREMENTS CAPTURE 43 DOMAIN MODELING EXAMPLE — ANALYSIS –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.

45. 310313 REQUIREMENTS CAPTURE 44 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).

46. 310313 REQUIREMENTS CAPTURE 45 UP — SYSTEM REQUIREMENTS CAPTURE ACTIVITIES 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

47. 310313 REQUIREMENTS CAPTURE 46 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 The dynamic model gets started with use-case analysis  Use cases drives the entire development effort  The use-case model is developed incrementally 2.2.1; 2.4.1 All required functionality is described in the use cases

48. 310313 REQUIREMENTS CAPTURE 47 An actor represents 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

49. 310313 REQUIREMENTS CAPTURE 48 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 /output 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.

50. 310313 REQUIREMENTS CAPTURE 49 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.

51. 310313 REQUIREMENTS CAPTURE 50 USE CASE MODEL — USE CASE A use case is 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 UML class use case is a classifier; scenario is an instance

52. 310313 REQUIREMENTS CAPTURE 51 USE-CASE MODEL — SCENARIO A scenario is a concrete, focused, informal description of a single use of the system from the viewpoint of a single actor  It is an actual attempt to carry out a use case Note: There are two viewpoints of use-case modeling : 1.top-down : start with use cases, refine with scenario 2.Bottom-up : start with scenarios, abstract use cases. –In reality, the use-case specfier uses both viewpoints. 2.4.1; 4.4.2  BUT, scenarios are mostly used to describe errors and alternate flows.

53. 310313 REQUIREMENTS CAPTURE 52 IDENTIFYING USE CASES AND SCENARIOS 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?  State a 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

54. 310313 REQUIREMENTS CAPTURE 53 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.

55. 310313 REQUIREMENTS CAPTURE 54 ASU — USE CASES 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.

56. 310313 REQUIREMENTS CAPTURE 55 ASU — USE CASES 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.

57. 310313 REQUIREMENTS CAPTURE 56 USE CASE DETAIL — USE CASE SPECIFICATION use case name (present-tense, verb phase in active voice) participating actors (invoked by; communicates with ) 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 –the 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)

58. 310313 REQUIREMENTS CAPTURE 57 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 (So as to specify everything the user might do) Narrative should be event-response oriented (i.e., The system does X. The user does Y. etc.)

59. 310313 REQUIREMENTS CAPTURE 58 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 This is a suggested format only!

60. 310313 REQUIREMENTS CAPTURE 59 USE-CASE MODEL DETAIL — GENERALIZATION Since actors and use cases are classifiers, they can be generalized. ManagerSales clerk The uses of generization represents a design decision! Employee Validate user Check password Retinal scan 2.4.1

61. 310313 REQUIREMENTS CAPTURE 60 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 > The use of an > relationship 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

62. 310313 REQUIREMENTS CAPTURE 61 It models conditional additions to a use case’s sequence of actions It is 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 The use of an > represents a design decision! extension point label 2.4.1; 4.4.5

63. 310313 REQUIREMENTS CAPTURE 62 USE-CASE DETAIL — EXTEND(cont’’d) 1. The «extend» relationship includes both a condition for the extension and a reference to an extension point in the main use case. 2. The main use case must be a complete flow of events in itself (i.e., it stands alone as an independent use case). – We describe the main use case totally independent of any extended functionality. 3. The main use case pays no attention to any flow of events that might be inserted. – We can add new extensions without (functionally) changing the description of the main use case. 4. We can view an extension as an interrupt in the main use case, which occurs where the «extend» use case is to be inserted.

64. 310313 REQUIREMENTS CAPTURE 63 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

65. 310313 REQUIREMENTS CAPTURE 64 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)

66. 310313 REQUIREMENTS CAPTURE 65 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).

67. 310313 REQUIREMENTS CAPTURE 66 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.

68. 310313 REQUIREMENTS CAPTURE 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.

69. 310313 REQUIREMENTS CAPTURE 68 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.

70. 310313 REQUIREMENTS CAPTURE 69 USE-CASE MODELING EXAMPLE — ANALYSIS –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.

71. 310313 REQUIREMENTS CAPTURE 70 USE-CASE MODELING EXAMPLE — ANALYSIS – 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. – 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).

72. 310313 REQUIREMENTS CAPTURE 71 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

73. 310313 REQUIREMENTS CAPTURE 72 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.

74. 310313 REQUIREMENTS CAPTURE 73 NONFUNCTIONAL REQUIREMENTS Interface – specifies requirements on the interface to an external system or sets constraints on formats, timing, etc. Physical – specifies hardware requirements (e.g., implementation platform). Design – constrains the design to have certain qualities (e.g., speed, throughput, response time, maintainability, reliability, etc.). Implementation – specifies or constrains the coding or construction of the system (e.g., standards, languages, resource limits, etc.). Management – schedule, budget, etc. 4.4.7 Nonfunctional requirements are captured as supplementary requirements on use cases or on the system as a whole. A user-visible system property that cannot be expressed as a use case, but often places constraints on a use case. A user-visible system property that cannot be expressed as a use case, but often places constraints on a use case.

75. 310313 REQUIREMENTS CAPTURE 74 IDENTIFYING NONFUNCTIONAL REQUIREMENTS To help identify nonfunctional requirements some categories to consider and "trigger questions" to ask for each category are given below. 1. User Interface and Human Factors – What type of user will be using the system? – Will more than one type of user be using the system? – What sort of training will be required for each type of user? – Is it particularly important that the system be easy to learn? – Is it particularly important that users be protected from making errors? – What sort of input/output devices for the human interface are available and what are their characteristics? 2. Documentation – What kind of documentation is required? – What audience is to be addressed by each document? 3. Hardware Considerations – What hardware is the proposed system to be used on? – What are the characteristics of the target hardware, including memory size and auxiliary storage space?

76. 310313 REQUIREMENTS CAPTURE 75 IDENTIFYING NONFUNCTIONAL REQUIREMENTS 4. Performance Characteristics – Are there any speed, throughput or response time constraints on the system? – Are there size or capacity constraints on data processed by the system? 5. Error Handling and Extreme Conditions – How should the system respond to input errors? – How should the system respond to extreme conditions? 6. System Interfacing – Is input coming from systems outside the proposed system? – Is output going to systems outside the proposed system? – Are there restrictions on the format or medium that must be used for input or output? 7. Quality Issues – What are the requirements for reliability? – Must the system trap faults? – Is there a maximum acceptable time for system restart after a failure? – What is the acceptable system downtime per 24-hour period? – Is it important that the system be portable (able to move to different hardware or operating system environments)?

77. 310313 REQUIREMENTS CAPTURE 76 IDENTIFYING NONFUNCTIONAL REQUIREMENTS 8. System Modifications – What parts of the system are likely candidates for later modification? – What sorts of modifications are expected? 9. Physical Environment – Where will the target equipment operate? – Will the target equipment be in one or several locations? – Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibration, magnetic fields)? 10. Security Issues – Must access to any data or the system itself be controlled? – Is physical security an issue? 11. Resources and Management Issues – How often will the system be backed up? – Who will be responsible for the back up? – Who is responsible for system installation? – Who will be responsible for system maintenance? Source:http://www.csee.umbc.edu/courses/undergraduate/345/spring04/mitchell/nfr.html

78. 310313 REQUIREMENTS CAPTURE 77 REQUIREMENTS VALIDATION 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 4.3.4 è correctness and completeness often difficult to show

79. 310313 REQUIREMENTS CAPTURE 78 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

80. 310313 REQUIREMENTS CAPTURE 79 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)

81. 310313 REQUIREMENTS CAPTURE 80 UP — SYSTEM REQUIREMENTS CAPTURE ACTIVITIES 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

82. 310313 REQUIREMENTS CAPTURE 81 USER INTERFACE (UI) SPECIFICATION The UI establishes a dialog between the system and its user. –This dialog needs to be clear and unambiguous. UI specification determines what information passes between the actors and the system through the UI and what the UI will look like. –UI data input/output, UI layout (look and feel), UI dialog structure. UI prototyping determines how the UI will function from the user’s viewpoint and gathers user feedback to evaluate and improve the UI. Developing a UI has as much to do with the study of people as with technology issues!

83. 310313 REQUIREMENTS CAPTURE 82 FACTORS IMPACTING ON UI DEVELOPMENT To help ensure a better chance of success of the new system, we need to look beyond just the technology characteristics of the people (users) –physiology–cognitive abilities –sensory/motor capabilities–cultural influences characteristics of the tasks –physical objects and events–concepts, goals and plans –perceptions and actions–purpose and value of the task characteristics of the users’ environment –the physical world–language and concepts –stimuli/affordances–society An understanding of these factors will help us design better user interfaces!

84. 310313 REQUIREMENTS CAPTURE 83 PEOPLE CHARACTERISTICS THAT AFFECT IN DEVELOPMENT Physiology –We need to consider what are the users:  physical size and strength (e.g., men vs. women; adults vs. children)?  reaction to stimuli and range of motion for muscular action?  comfort levels for ambient light, temperature, noise, etc.?  sensitivity to environmental stresses, fatigue, etc. (e.g., RSI)? Sensory/motor capabilities –We need to consider what are the users:  capabilities and limitations of the senses (typing speed, deafness)?  strength, range and speed of motor action (young vs. older people)? Cognitive abilities –We need to consider how users’ process information and use memory and processing resources in perception, thought and action? Cultural influences –We need to consider:  societal influences: The influence of the entire body of knowledge and beliefs to which users are exposed (e.g., oriental vs. western thinking).  organizational influences: The “corporate” culture of work may be very different from the societal culture.

85. 310313 REQUIREMENTS CAPTURE 84 TASK CHARACTERISTICS THAT AFFECT IN DEVELOPMENT Physical objects used and events that occur –tools used to accomplish the task (e.g., typewriter, paper, etc.) –material objects that form the starting point for the task (e.g., paper invoice, a web purchase) –physical events that occur as the user does the task (e.g., interruptions) Perceptions and actions –things a user needs to be aware of during the task and the actions performed Concepts, goals and plans –the user’s understanding of:  the task and the objects involved in the task  the goal to be attained  a plan or mental image of the steps to be taken Purpose and value of the task –why is this task being done (i.e., what is the user’s motivation)? –what is its value? –> to the individual; to the organization; to society

86. 310313 REQUIREMENTS CAPTURE 85 USER ENVIRONMENT CHARACTERISTICS THAT AFFECT IN UI DEVELOPMENT The physical world –all the physical objects and events in the environment of the user Stimuli/affordances –stimuli are events generated in the environment that require the user’s attention/action –affordances are perceived properties of objects that “afford” (facilitate) action (e.g., handles on doors, keys on a typewriter, etc.) Language and concepts –the user’s background knowledge about objects in the environment –the language available for thinking and talking about them Society –is the carrier of culture –embodied in the set of people the user encounters at work or in society at large –has a strong influence on an individual’s perception of the purpose and value of a task

87. 310313 REQUIREMENTS CAPTURE 86 UI SPECIFICATION : USERS Know who your users will be! not all users are the same! –different levels of expertise in problem domain –different levels of knowledge of the system –different frequency of using the system –different need to use the system  they are not all like the designer! So what? we need to: –understand the differences –understand why the differences exist –design to deal with the differences  either exploit or minimize their effect

88. 310313 REQUIREMENTS CAPTURE 87 UI SPECIFICATION :— USER TASKS We gather information on current/desired tasks that will help in (re)designing tasks for the new system top-down –>look at a task as a meaningful unit of work e.g.,register for courses  helps in understanding task goals and designing overall flow of steps in the new system use cases contain this information!  The ultimate focus should be on task goals, not task steps  identify breakdowns in current tasks bottom-up –>look at a task as a sequence of steps/actions e.g.,specify semester and year specify primary choices specify alternate choices, etc.  helps in understanding user’s goals and identifying objects (data) involved in the task

89. 310313 REQUIREMENTS CAPTURE 88 UI REQUIREMENTS CAPTURE — UI ELEMENTS Try to identify breakdowns in current tasks A breakdown is a situation where the flow of the current task is awkward or some goal cannot be satisfied due to current system limitations. –These are opportunities for improvements in the new system!

90. 310313 REQUIREMENTS CAPTURE 89 UI SPECIFICATION : UI ELEMENTS Identify what data (attributes) the user will manipulate Consider the actors that interact with each use case and ask: 1.What information does the actor need to supply to the system? 2.What information does the system need to supply to the actor? 3.Which of the domain model classes are suitable as user-interface elements for the use case? 4.What user-interface elements does the actor work with? 5.What actions can the actor invoke, and what decisions can the actor make? 6.What guidance and information does the actor need before invoking each action in the use case?

91. 310313 REQUIREMENTS CAPTURE 90 UI SPECIFICATION : UI ELEMENTS For each UI display (screen), we need to decide what UI elements are needed, how the UI elements will be represented (e.g., text box, menu, etc.) and where they will be placed. Can use: – sketch  to get a rough idea of layout and look (e.g., can use sticky notes or PowerPoint). – prototype  for the most important actors to get their feedback. We also need to verify that each UI display: – provides a consistent look and feel and way of working. – complies with standards (button size, toolbar placement, etc.).

92. 310313 REQUIREMENTS CAPTURE 91 UI SPECIFICATION: DIALOG DESCRIPTION For each user task we construct a “mainline” dialog description that describes what the user normally has to do to complete the task using the UI (ignoring errors). – This is a step-by-step description of how a user and the system interact via the user interface to accomplish a task (i.e., a scenario).  A dialog should be described from the perspective of the user, not the system. Dialog descriptions are analyzed procedurally to verify that the steps involved are efficient and accomplish the desired task. –Can use sketches, mock-ups, prototyping, etc. GOAL : Seamlessness (When an object or function is need) for a task in progress. It is “right there”)

93. 310313 REQUIREMENTS CAPTURE 92 UI SPECIFICATION: DIALOG STRUCTURE We need to put individual dialogs together into a dialog structure for the system’s user interface –sequencing of/flow between individual tasks –optional versus required tasks –dialog style  menus, forms, commands, function keys, etc. –input aspects  action language –output aspects  presentation language  there are many alternatives from which to choose  UI prototyping tools can help to get user feedback and evaluate alternative dialog structures

94. 310313 REQUIREMENTS CAPTURE 93 UI SPECIFICATION: GENERAL USABILITY PRINCIPLES Consistency  similar actions in similar situations Closure –organize actions so that the user knows that a task has completed Error handling –minimize users’ opportunity to make errors (e.g., keystrokes) Reversibility –actions should be reversible Control –users should always feel in control of the interaction Cognitive load –the load on the user’s short term memory should be minimized Accuracy & completeness –the information must be as accurate and as complete when using the system as without it Speed –a task should not take longer to do with the help of the system than without it  shortcuts can help Feedback –there should be informative feedback for every user action

95. 310313 REQUIREMENTS CAPTURE 94 UI SPECIFICATION :EVALUATION We need to assess the usability of the UI and whether it meets user requirements.  This should be part of the normal testing process. We need a set of usability attributes  part of design goals. e.g., learnability, speed of operation, robustness, recoverability, etc. Systematic, formal evaluation can be expensive and time consuming! Informal (i.e., less costly) evaluation techniques include: –questionnaires  collect users opinions. –observations  in person; via video; “thinking aloud” sessions. –monitoring code  to discover most used facilities/common errors.

96. 310313 REQUIREMENTS CAPTURE 95 SYSTEM REQUIREMENTS CAPTURE: RETROSPECTIVE Domain Modeling Captures the static (database) requirements of an application. class diagram – shows classes and the relationships among them. Use-case Modeling Captures the dynamic (processing) requirements of an application. use-case model – shows the use cases that provide the system functionality and the actors that use the functionality. flow of events – describes the sequence of actions that comprise a use case’s functionality. Requirements Validation Demonstrates that the system meets all stated requirements. acceptance test plan – details how the client verifies that the requirements have been met. User Interface Specification and Prototyping Demonstrates that the user interface meets all stated requirements.

97. 310313 REQUIREMENTS CAPTURE 96 SUMMARY — SYSTEM REQUIREMENTS CAPTURE Requirements are captured over several iterations by specifying: –a domain model –a use-case model –an acceptance test plan –initial user interfaces (and building some user interface prototypes)  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