Presentation is loading. Please wait.

Presentation is loading. Please wait.

INFO 620Lecture #31 Information Systems Analysis and Design Requirements and Use Case Modeling INFO 620 Glenn Booker.

Similar presentations

Presentation on theme: "INFO 620Lecture #31 Information Systems Analysis and Design Requirements and Use Case Modeling INFO 620 Glenn Booker."— Presentation transcript:

1 INFO 620Lecture #31 Information Systems Analysis and Design Requirements and Use Case Modeling INFO 620 Glenn Booker

2 INFO 620Lecture #32 Requirements Analysis Like all modern software life cycles, the Rational Unified Process (RUP) advocates management of system requirements Requirements include the capabilities of the system (functions or features), as well as conditional or limitations on how those capabilities are achieved

3 INFO 620Lecture #33 Requirements Change Unlike the waterfall life cycle, the RUP recognizes that requirements, and our understanding of them, change during practically every project Hence a key is to capture our current understanding of requirements as clearly as possible

4 INFO 620Lecture #34 FURPS+ Model One way to help identify requirements is to use the “FURPS+” model Functional Usability Reliability Performance Supportability + = everything else

5 INFO 620Lecture #35 Functional Requirements The biggest category is Functional requirements – what the system can do –To help identify Functional requirements, first identify the kinds of users your system might have

6 INFO 620Lecture #36 Users Users might come from the general public (e.g. anyone on the Internet) Your organization might have managers or administrators who have special needs The developers of the system might be a user type Different departments within your organization might be users (finance, sales)

7 INFO 620Lecture #37 Functional Requirements Then identify what kinds of functions each type of user needs to perform Think of a detailed job description for each type of user; does it include “enter invoices” or “generate reports” or “analyze customers” or ??? A general function may be broken down into more detail; e.g. what kind of reports?

8 INFO 620Lecture #38 Functional Requirements Don’t obsess with getting every functional requirement on the first try; this is an iterative process, and you’ll probably find more requirements later For now, write down requirements grouped by user; this will feed into Use Case documentation soon

9 INFO 620Lecture #39 Usability Requirements The U stands for Usability which includes –Human factors; what characteristics of your system will make it more pleasant to use? –Help; what Help will the user have available? F1? Context sensitive? Online books? –Documentation; what documentation will be created to help the users learn how to use this product? Tutorials? User’s manual?

10 INFO 620Lecture #310 Reliability Requirements Reliability is often critical for many systems Reliability requirements are measured e.g. –Mean Time Between Failures (MTBF); how long can a user use the system before it crashes –Mean Time To Repair (MTTR); how long does it take to fix the system once it crashes? (though this could be a maintainability issue) –Availability is under Performance requirements

11 INFO 620Lecture #311 Performance Requirements Most measures of performance can be made into requirements –Response time for queries (average, maximum) –Throughput (number of records processed per hour or day, transactions per second (TPS)) –Accuracy (scanning or data entry correctness) –Resource usage (CPU or disk space used, network traffic)

12 INFO 620Lecture #312 Performance Requirements AvailabilityDown Time per Year 99.0%3.65 days 99.9%8.76 hours 99.99%52.6 minutes 99.999% (five 9’s)5.26 minutes 99.9999% (six 9’s)31.5 seconds Availability is a common performance requirement

13 INFO 620Lecture #313 Supportability Requirements Supportability requirements include –Maintenance issues; do you provide troubleshooting guides? MTTR could be here –How easy is it to maintain the system? This could include installation of software or hardware upgrades –Internationalization; is your system usable in many languages? –Can your system be reconfigured easily?

14 INFO 620Lecture #314 The “+” Requirements The other requirements in FURPS+ include –Implementation –Interface –Operations –Packaging –Legal –And anything else you think of!

15 INFO 620Lecture #315 Implementation Requirements Implementation requirements are limitations on how the system may be implemented –Resource limitations (cost, schedule, staffing) –Languages and tools (programming environment to be used for development) –Hardware (e.g. must use IBM equipment) –Software (e.g. must use Oracle database) –User hardware limits (must run on PII with 32 MB RAM on Windows 98)

16 INFO 620Lecture #316 Interface Requirements Interface requirements are that your system may communicate with external systems –Legacy systems in your organization –Vendors or suppliers –Teammates or corporate partners –External organizations (IRS, SBA, FDA, etc.)

17 INFO 620Lecture #317 Operations Requirements Your system must be managed while it’s in operational use What functions will the managers need? –Add users or groups –Define permissions for users or groups –Monitor resource usage (CPU, disk, network) –Monitor physical environment (temperature)

18 INFO 620Lecture #318 Packaging Requirements How will your product be packaged? –Distribution medium? CD-ROM? DVD? –What documentation is written vs. electronic? –Who will the users contact for help? –Are different distributions needed for different countries? Languages?

19 INFO 620Lecture #319 Legal Requirements How is your product licensed? –By user? By site? –By computer? –By processor? Are there different versions of your product? (academic vs. commercial) Are there places where your product can’t be sold? (export restrictions)

20 INFO 620Lecture #320 Requirements So the FURPS+ categories can help identify many kinds of requirements Will need to establish priorities for requirements (esp. the functional ones), to help put them into timeboxes later –{Required, Desired, Optional} is one basic set of priorities, kind of like {High, Medium, Low}

21 INFO 620Lecture #321 More Requirements Sources For more info, see –Cockburn’s Writing Effective Use Cases, Addison Wesley (2001) –Software Engineering Body of Knowledge (

22 INFO 620Lecture #322 Use Case Modeling “Use Case” modeling is a major tool for capturing requirements It is not object oriented, just very useful The use case diagram captures functional requirements – the rest only show up in use case documentation –So don’t forget the documentation!!!

23 INFO 620Lecture #323 Use Case Model A use case is a description of how some user uses the system; more formally –“The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.” (UML 1.5 spec) Focus here is on what the system can do, not how

24 INFO 620Lecture #324 We get to Act? “Actor” is the UML term for “type of user” in the context of a use case –“A coherent set of roles that users of use cases play when interacting with these use cases. An actor has one role for each use case with which it communicates.” (UML 1.5 spec) An Actor can be a person (by role, e.g. cashier), external system, or organization

25 INFO 620Lecture #325 Brief Format Use Case One way to describe a use case is with a written narrative describing how the actor interacts with the system (p. 46) BTW, use cases (actually usage cases) were first defined by Ivar Jacobson in 1986

26 INFO 620Lecture #326 Scenarios A scenario is a description of one use case, a.k.a. a use case instance A scenario can have a good (intended) outcome – a success scenario –Customer purchased books If not, there might be a failure scenario –Customer’s credit card was rejected

27 INFO 620Lecture #327 Scenarios The main intent of a use case is the Main Success Scenario, which should satisfy some user goal or need But there may be several Alternate Scenarios, both successful and not –Alternate scenarios are variations on what might happen, e.g. paying with various methods, or failing to complete the transaction

28 INFO 620Lecture #328 Use Case Objective The assumption is: If all use cases have been identified, then all system functional requirements have been identified Use cases should avoid all implementation concepts – keep all options open for the design of the system –This is the black box use case concept

29 INFO 620Lecture #329 Use Case Description Formality There are three levels of formality for describing use cases –Brief (one paragraph for the main success scenario), p. 46 –Casual (a few paragraphs including alternate scenarios), p. 47 –Fully dressed (complete), p. 50-53

30 INFO 620Lecture #330 Use Case Formatting One-column format uses one narrative, where each paragraph is another action by an actor or the system, p. 50 Two-column format uses the left column for all actor actions, and the right column for all system actions, p. 53 Generally easier to generate the one-column format (preferred, but not required)

31 INFO 620Lecture #331 Use Case Description The written description for one use case can include the following sections –Primary Actor –Stakeholders and Interests –Preconditions –Postconditions –Main Success Scenario

32 INFO 620Lecture #332 Use Case Description –Extensions –Special Requirements –Technology and Data Variations List –Frequency of Occurrence –Open Issues See also the template from

33 INFO 620Lecture #333 Primary Actor The Primary Actor for a use case is the actor (type of user) who starts using the system to achieve some goal Hence it is the initiator of the use case The Primary Actor is generally human, unless some external system is automated to prompt your system for some reason

34 INFO 620Lecture #334 Stakeholders and Interests This section is a list of all actors involved in this use case, and a description of what they want to get from the main success scenario Usually one or two sentences per actor is adequate

35 INFO 620Lecture #335 Preconditions Preconditions are the entry conditions for starting this use case This should describe any assumptions about what the primary actor has already done (or not done), and what action on the part of the primary actor motivates them to use the system for this purpose

36 INFO 620Lecture #336 Postconditions Postconditions, or Success Guarantee, is a summary of the desired outcomes at the end of this use case Again, this applies to the main success scenario; “if everything goes well” what will the end of use case achieve?

37 INFO 620Lecture #337 Main Success Scenario The main success scenario is a step-by-step description of the use case if everything goes well This describes the intended purpose of the use case All steps are from the point of view of the actor – describe only what they see or do

38 INFO 620Lecture #338 Extensions Extensions, or Alternate Flows, describe what might happen to alter or clarify the main success scenario This includes things going wrong (credit card failed validation), and merely different options to achieve success (pay with cash versus paying with a check)

39 INFO 620Lecture #339 Extensions Extensions are numbered by adding letters to the step in the main success scenario where the different behavior happened Main success scenario 3. Cashier enters item identifier Extension 3a. Invalid identifier Then describe the steps for the extension

40 INFO 620Lecture #340 Extensions Hence extensions have two parts for each entry; the condition which flags use of that extension, and the handling of that extension (what to do as a result) Condition: 3a. Invalid item identifier Handling: 1. System shows error and rejects item entry.

41 INFO 620Lecture #341 Special Requirements Special requirements can include non-functional requirements or other constraints on the use case –Performance, reliability, usability, and design constraints might get mentioned in this area, if they specifically apply to this use case General constraints go in the Supplementary Specification

42 INFO 620Lecture #342 Technology and Data Variations List This section describes different types of technology which may be applied for performing the steps –Data format or input device options Only applies if the differences do NOT result in different steps being followed; then it would be an Extension

43 INFO 620Lecture #343 Frequency of Occurrence This is a straightforward section to indicate how often this use case will be exercised –1000 times per day? –Once per month? Helps sort out priorities for use cases, and may affect design issues later

44 INFO 620Lecture #344 Open Issues This section is to flag uncertain assumptions, likely changes in technology, or any other issues which are not fully resolved Unresolved legal, process, or interface issues could also go here

45 INFO 620Lecture #345 How Find Use Cases? Two methods for finding use cases –Business Use Cases Boundaries are typically organizations. Each use case is an Elementary Business Process. Actors are business organizations. –System Use Cases Boundaries are the system we’re creating. Each use case is a way of using the system. Actors are users of the system. We will use this.

46 INFO 620Lecture #346 Good Use Cases Good, or primary use cases satisfy some user goal A use case starts and finishes some task Secondary use cases are needed for the system to work, but are not fulfilling goals –Log in, log out, and shut down the system are secondary use cases –Optional use cases may not be implemented

47 INFO 620Lecture #347 Secondary Actors Secondary, or supporting actors are those which wait for the system to tell to do something They do not initiate any use case Often an external system which provides a needed service (printing, data, etc.)

48 INFO 620Lecture #348 Actor-Goal List For each primary actor, list all of the goals they need to fulfill in their job –A simple 2-column table will do (p. 65) Each Primary actor is something that interacts directly with the system – so in a retail environment, Customer may not be a primary actor!

49 INFO 620Lecture #349 Name Use Cases Give use cases a brief name, generally of the form: verb [adjective(s)] noun –Rent items –Generate status report –Maintain inventory –etc.

50 INFO 620Lecture #350 Essential Style Try to focus use case descriptions on the intent of the actor, not how it is implemented through the interface Instead of “log in” maybe the purpose is to “identify and authenticate user” Describing the interface limits how the system is implemented…

51 INFO 620Lecture #351 Time for Pictures!!! Remember that the written use case description is the main tool for capturing requirements – the use case diagram is just a high level summary of it At a high level, a use case diagram has similar ideas as a context diagram, but with more of a process focus

52 INFO 620Lecture #352 Use Case Diagram A use case diagram shows: –Use cases (one per bubble) –Actors (all kinds, human and not) –Which actors can apply which use cases (lines connecting actors to use cases) –System boundary (a box called System, for example)

53 INFO 620Lecture #353 Use Case Diagram Borrowed from p. 71

54 INFO 620Lecture #354 Use Case Diagram So the use case diagram just shows the names of all the use cases, and what actors are involved in which use cases It does not show the logic or sequence in which use cases are applied (if any exists) Use case diagram does not show TIME

55 INFO 620Lecture #355 Planning Use Cases Once the use cases have been identified, can –Define criticality (biz value) for each –Assess risks of implementing each use case –Importance of that use case to the system’s structure (architectural significance) Can score each of these factors from 0-3 to determine use cases’ priority (see p. 577) –Add (score*weight) for each use case

56 INFO 620Lecture #356 Planning Use Cases Based on this analysis, determine which use cases need to be implemented first These could feed the high level Phase Plan, then each Iteration Plan within those phases This is what we mean by use case driven development (which the RUP is)

57 INFO 620Lecture #357 Global Use Case Documentation The Supplementary Specification captures non-functional requirements which apply to many use cases, or the system as a whole The Glossary captures terms and definitions; later it is also a data dictionary The Vision captures the purpose and intent of the project

58 INFO 620Lecture #358 Supplementary Specification The Supplementary Specification (SS) mostly follows the FURPS+ structure to identify global or common requirements Sections within the SS include: –Revision History; since the SS captures requirements, it needs to be controlled like any other part of the system –Introduction; explain purpose of the SS Adapted from pp. 84-87

59 INFO 620Lecture #359 Supplementary Specification –Functionality (those requirements common across many or all use cases) –Usability –Reliability –Performance –Supportability –Implementation Constraints Purchased Components

60 INFO 620Lecture #360 Supplementary Specification Open Source Components –Interfaces; description of unusual input & output devices, interfaces to external systems –Operations –Packaging –Legal Issues –Business Rules; see next slide –Additional Domain Information

61 INFO 620Lecture #361 Business Rules Business (or Domain) Rules describe rules which will affect how various functions are implemented Often based on your organization’s way of doing business (hence the name), but some are also legally imposed (charging sales tax) For each business rule, also define how frequently it changes, and who defined it

62 INFO 620Lecture #362 Additional Domain Information Called “Information in Domains of Interest” in the text This section is used to provide additional information on various concepts or aspects of system functionality May provide links to detailed technical information for interfaces or regulations

63 INFO 620Lecture #363 Vision The Vision statement is a summary business case for your product What do you want to do, and why is it worth doing? Vision sections include –Revision History –Introduction; provide 1-2 sentence summary of what needs your product will fulfill (objective)

64 INFO 620Lecture #364 Vision –Positioning; provide a description of what is wrong with the existing market for your type of product, who your product is intended for, and what the major competition can and can’t do –Stakeholder Descriptions; more general than the use case description, this should identify demographics & skills for users of your product, and identify what goals and problems they face

65 INFO 620Lecture #365 Vision –Product Overview; summarize the use case diagram into one use case for the entire system, and show all the actors which use or support it. This is a System Context Diagram. Provide a summary of the main features of the product, and how they will benefit the stakeholders –Summary of System Features; may be somewhat redundant with the previous section

66 INFO 620Lecture #366 Glossary The Glossary is a dictionary for the project Identify terms and acronyms, and write definitions of them Definitions may be your own, or from an external source Might include hyperlinks for more information

67 INFO 620Lecture #367 Glossary Glossary includes only three sections –Revision History –Definitions; a table with the definitions (see next slide), and sources where available –Sources; a bulleted list of sources used for definitions

68 INFO 620Lecture #368 Glossary TermAliasesDefinitionSource UPCUniversal Product Code A 12-digit code which identifies a product http://www.uc SnigglefratzWidget which provides interface to local network Project Team* * A term unique to your project

69 INFO 620Lecture #369 Glossary Later will expand Glossary into a data dictionary to identify specific attributes used for this project Keep in mind what units apply to attributes ($, feet, degrees, etc.) Glossary also can define larger ideas (composite terms) such as ‘sale’ or ‘order’

70 INFO 620Lecture #370 Connection to RUP Life Cycle The Supplementary Specification, Vision, and Glossary should all be started early in the life cycle, in the Inception phase They will be mostly finalized during the Elaboration phase, though adjustments may be needed during the Construction phase

71 INFO 620Lecture #371 Elaboration Phase The Elaboration phase is when –The requirements are defined, –Major risks are identified (and mitigated wherever possible), and –The core architectural elements of the system are implemented

72 INFO 620Lecture #372 Inception Review From the Inception phase, we should have: –Identified key functional and non-functional requirements, using interface prototypes where needed –Identified actors, goals, and major use cases –Written most use cases in at least brief format, and fully documented critical ones

73 INFO 620Lecture #373 Inception Review –Written drafts of the Supplementary Specification, Vision, and Glossary –Conducted proof of concept for key technical concepts (risk reduction) –Determined which major components will be obtained elsewhere –Started thinking about high level architecture –Planned the first iteration

74 INFO 620Lecture #374 Elaboration Phase Key concepts during elaboration include –Do timeboxed iterations –Start programming early –Design, implement, and test core parts of system architecture –Test early and test often –Use feedback, especially from users –Complete most use cases in detail

75 INFO 620Lecture #375 Core Architecture? Focus on making sure the subsystems can communicate with each other, even if their contents don’t exist yet (“wide & shallow”) –“Designing at the seams” (Booch) –Integrate and test interfaces early, especially external systems –Implement significant scenarios –Test key usability, exception, or stress situations

76 INFO 620Lecture #376 Plan Next Iteration Use the Risk, Coverage, and Criticality to determine the next iteration –Technical or other risk –Covering all major parts of the system (also called architectural significance last week) –Business value criticality Large use cases may take multiple iterations

77 INFO 620Lecture #377 Relating Use Cases After use cases have been identified, it may be possible to isolate some activities These subfunctions can be described as extended, included, or generalized use cases They are closely related concepts; we prefer to focus on included use cases These are never used for business modeling (too detailed)

78 INFO 620Lecture #378 Warning! Much time can be wasted arguing over included use cases –If in doubt whether it really is an included use case, leave it out When it is used, included use cases can simplify your system and encourage reuse

79 INFO 620Lecture #379 How to Find Included Use Cases Look for activities which are: –A clearly defined subset –Used by at least two use cases The point of included use cases is to identify functions which can be called by more than one other use case Classic example is ‘making a payment with a credit card’

80 INFO 620Lecture #380 How to Find Included Use Cases ‘Use include when you are repeating yourself in two or more separate use cases to avoid repetition’ (Fowler00) Another special case is when a function can be used any time during another use case –That function can be an included use case, e.g. check spelling

81 INFO 620Lecture #381 Special Use Case Terms A concrete use case is done entirely by the primary actor (Process Sale) An abstract use case is never done by itself (Handle Credit Payment) The use case which invokes an included, extended, or generalized use case is the base use case –The invokee is an addition use case

82 INFO 620Lecture #382 Extended Use Case If you find special scenarios for a use case, and don’t want to amend the base use case’s description, an extended use case can be added An extended use case still has clear start and stop, but the base use case may or may not need it Nearly identical to an included use case

83 INFO 620Lecture #383 Generalized Use Cases Generalized use cases are not yet well defined This is the same generalization concept as applied to classes, namely: –A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed. (UML 1.5 spec)

84 INFO 620Lecture #384 Stereotypes These special use cases have stereotypes in the use case diagram to show their special status – > or > An unfilled arrow points TO the included or extended use case (NOT the base use case) p. 391

Download ppt "INFO 620Lecture #31 Information Systems Analysis and Design Requirements and Use Case Modeling INFO 620 Glenn Booker."

Similar presentations

Ads by Google