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

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

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

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? INFO 620 Lecture #3

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 INFO 620 Lecture #3

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? INFO 620 Lecture #3

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

Performance Requirements
Availability is a common performance requirement Availability Down 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 % (six 9’s) 31.5 seconds INFO 620 Lecture #3

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? INFO 620 Lecture #3

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

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) INFO 620 Lecture #3

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.) INFO 620 Lecture #3

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) INFO 620 Lecture #3

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? INFO 620 Lecture #3

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) INFO 620 Lecture #3

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} INFO 620 Lecture #3

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

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!!! INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

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 INFO 620 Lecture #3

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

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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? INFO 620 Lecture #3

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

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

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: System shows error and rejects item entry. INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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. INFO 620 Lecture #3

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 INFO 620 Lecture #3

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.) INFO 620 Lecture #3

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! INFO 620 Lecture #3

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. INFO 620 Lecture #3

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… INFO 620 Lecture #3

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

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

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

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 INFO 620 Lecture #3

Supplementary Specification
Adapted from pp 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 INFO 620 Lecture #3

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

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

* A term unique to your project
Glossary Term Aliases Definition Source UPC Universal Product Code A 12-digit code which identifies a product Snigglefratz Widget which provides interface to local network Project Team* * A term unique to your project INFO 620 Lecture #3

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’ INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

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 INFO 620 Lecture #3

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’ INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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 INFO 620 Lecture #3

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) INFO 620 Lecture #3

Stereotypes These special use cases have stereotypes in the use case diagram to show their special status <<include>> or <<uses>> <<extend>> or <<extends>> An unfilled arrow points TO the included or extended use case (NOT the base use case) p. 391 INFO 620 Lecture #3

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

Similar presentations

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

Similar presentations

About project

Feedback

Log in

Auth with social network:

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

Similar presentations

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

Similar presentations

About project

Feedback