capturing the problem: use case development and requirement analysis
DESCRIPTION
Capturing the problem: Use case development and requirement analysis. Peter Fox Xinformatics ITEC, ERTH, CSCI 4400/6400 Week 4, February 12, 2013. Contents. Discussion of reading Background on use cases Developing use cases Uncovering requirements Evaluation Assignment 2 Next class(es). - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/1.jpg)
1
Peter Fox
Xinformatics
ITEC, ERTH, CSCI 4400/6400
Week 4, February 12, 2013
Capturing the problem: Use case development and requirement analysis
![Page 2: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/2.jpg)
Contents• Discussion of reading
• Background on use cases
• Developing use cases
• Uncovering requirements
• Evaluation
• Assignment 2
• Next class(es)
2
![Page 3: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/3.jpg)
Reading…• Shannon• Awareness in Context-Aware Information Systems• GUI ICON Sets Sequence logos• http://www.helsinki.fi/science/commens/dictionary.html• Information Models - Conceptual, Logical and Physical• optional Peirce• http://cogsci.uwaterloo.ca/courses/phil256.html• http://www.ncbi.nlm.nih.gov/pmc/articles/PMC131031/• Social Machines• CIM• Presentation
3
![Page 4: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/4.jpg)
4
![Page 5: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/5.jpg)
Developed for NASA TIWG
Use Case
• Is a collection of possible sequences of interactions between the system under discussion and its Users (or Actors), relating to a particular goal.
• The collection of Use Cases should define all system behavior relevant to the actors to assure them that their goals will be carried out properly.
• Any system behavior that is irrelevant to the actors should not be included in the use cases.
![Page 6: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/6.jpg)
Developed for NASA TIWG
Use Case
• is a prose description of a system's behavior when interacting with the outside world.
• is a technique for capturing functional requirements of business systems and, potentially, of an IT system to support the business system.
![Page 7: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/7.jpg)
Developed for NASA TIWG
Use Case
• Must be documented (or it is useless)• Should be implemented (or it is not well
scoped)• Is used to identify: objects ~ resources,
processes, roles (aka actors), requirements, etc.
• Should iterate with as many actors as possible on wording and details at least once
![Page 8: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/8.jpg)
Developed for NASA TIWG
Use Case Examples:• I have a gazillion images of the night sky from
a survey but there’s no way I (or all of the known professional galactic astronomers) can classify all those galaxies – what can I do?
• Provide browse and quick look access to a broad variety of climate, weather and ocean data.
• Provide web portal access to a federation of library catalogs with drill-down search and access of published articles
![Page 9: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/9.jpg)
Developed for NASA TIWG
Use Case Examples:• Provide high-performance data transfer of
specific climate model data products into the CDAT tool for analysis independent of their storage format, organization or location on the internet
• Perform real-time MRI image analysis to detect abnormal tissue growth in adult humans.
![Page 10: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/10.jpg)
Developed for NASA TIWG
Use Case Examples:
A US 9th grade teacher is preparing a lesson plan aimed at getting students to learn more about the ‘northern lights’, addressing NSES content standards in earth science. The teacher wants the students to learn the scientific terminology, where the phenomena occurs and retrieve some data or graphics for a recent occurrence. The goal of the lesson plan is the engage students, using authentic data from the aurora, as part of an inquiry-based program.
![Page 11: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/11.jpg)
Developed for NASA TIWG
Elements of a Use Case
• http://wiki.esipfed.org/index.php/SolutionsUseCase_Template
• Start with the Plain Language Description• Short Definition• Purpose• Describe a scenario of expected use• Definition of Success
![Page 12: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/12.jpg)
Developed for NASA TIWG
Short Definition
• Define the use case in plain sentences• Wherever possible avoid specifying
technical solutions or implementation choices
• Concentrate on the application aspects of the intended scenario
• Also note when the use case may be applicable to more than one application area
![Page 13: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/13.jpg)
Developed for NASA TIWG
Purpose
• A plain language description of • why this use case exists,• what the problem is to be solved, and• what a successful outcome, and • what the impact may be.
• Often termed the ‘business case’
![Page 14: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/14.jpg)
Developed for NASA TIWG
Scenario of expected use
• A verbose (more detailed) description of one instance of a problem to be solved• what resources are generally needed (if known)• what a successful outcome and impact may be• who might be expected to do the work or provide the
resources and • who might be expected to benefit from the work.
• List any performance or metric requirements for this use case and any other other considerations that a user would expect.
![Page 15: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/15.jpg)
Developed for NASA TIWG
Definition of Success
• Quick test that would show whether or not the case is working as described.
![Page 16: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/16.jpg)
Developed for NASA TIWG
At this stage
• Use case modelers should have a good sense of what the use case goal is.
• They proceed on to the next stage to extract details.
• They may contact other team members, e.g. domain experts, one-on-one for additional information.
![Page 17: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/17.jpg)
But for Xinformatics?• Everything up to now can be considered
‘informational’ and is accessible to people
• It is intended to keep people in the loop
• Let’s discuss this use case:– I have a gazillion images of the night sky from a
survey but there’s no way I (or all of the known professional galactic astronomers) can classify all those galaxies – what can I do?
– What would you do?
• Breakouts!!!17
![Page 18: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/18.jpg)
Reference – READ THIS• Slides 19-51 – yes, you will need to read and
use this in Assignment 2!
18
![Page 19: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/19.jpg)
Developed for NASA TIWG
Formal Use Case Description
• Use Case Identification• Revision Information• Definition• Successful Outcomes• Failure Outcomes
![Page 20: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/20.jpg)
Developed for NASA TIWG
Use Case Elaboration• Actors• Primary Actors• Other Actors
• Preconditions• Postconditions• Normal Flow (Process Model)• Alternative Flows• Special Functional Requirements• Extension Points
![Page 21: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/21.jpg)
Developed for NASA TIWG
Non-functional requirements• Performance• Reliability• Scalability• Usability• Security• Other Non-functional Requirements• Repeatability?
![Page 22: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/22.jpg)
Developed for NASA TIWG
Alternate form• Use case name• Summary• Activity diagram• Preconditions in tabular form• Triggers• Basic flow• Alternate flow• Post conditions
![Page 23: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/23.jpg)
Developed for NASA TIWG
Comparison b/w formats
• Long format - intended to be a full capture of the use case and is used by domain contributors (first section) and technologists. Categories are more faceted.
• Short format - captures important basic and necessary elements of use case. Categories are more integrative.
![Page 24: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/24.jpg)
Developed for NASA TIWG
Preconditions - data/model
![Page 25: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/25.jpg)
Developed for NASA TIWG
Preconditions - event/application
![Page 26: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/26.jpg)
Developed for NASA TIWG
Which format to use?
• Short (in document) format for:• Exploratory phase of a project where you want to
collect a lot of use cases • An example for others to use• Including in a proposal (or an assignment)
• Long (on wiki) format for:• Detailed documentation of the use case• Life cycle documentation for implementation• Asynchronous/ collaborative development
![Page 27: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/27.jpg)
Developed for NASA TIWG
Table of Contents• ==Plain Language Description==• ===Short Definition===• ===Purpose===• ===Describe a scenario of expected use===• ===Definition of Success===• ==Formal Use Case Description==• === Use Case Identification===• ===Revision Information===• ===Definition===• ===Successful Outcomes===• ===Failure Outcomes===• ==General Diagrams==• ===Schematic of Use case===• ==Use Case Elaboration==• ===Actors===• ====Primary Actors====• ====Other Actors====• ===Preconditions===• ===Postconditions===• ===Normal Flow (Process Model)===• ===Alternative Flows===
• ===Special Functional Requirements===• ===Extension Points===• ==Diagrams==• ===Use Case Diagram===• ===State Diagram===• ===Activity Diagram===• ===Other Diagrams===• ==Non-Functional Requirements==• ===Performance===• ===Reliability===• ===Scalability===• ===Usability===• ===Security===• ===Other Non-functional Requirements===• ==Selected Technology==• ===Overall Technical Approach===• ===Architecture===• ===Technology A===• ====Description====• ====Benefits====• ====Limitations====• ===Technology B===• ====Description====• ====Benefits====• ====Limitations====• ==References==
• ===Special Functional Requirements===• ===Extension Points===• ==Diagrams==• ===Use Case Diagram===• ===State Diagram===• ===Activity Diagram===• ===Other Diagrams===• ==Non-Functional Requirements==• ===Performance===• ===Reliability===• ===Scalability===• ===Usability===• ===Security===• ===Other Non-functional Requirements===• ==Selected Technology==• ===Overall Technical Approach===• ===Architecture===• ===Technology A===• ====Description====• ====Benefits====• ====Limitations====• ===Technology B===• ====Description====• ====Benefits====• ====Limitations====• ==References==
![Page 28: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/28.jpg)
Scoping
• Focus initially on:• Core functionality• What it takes to implement the use case, resist early
generalizations• May (will) have to iterate on use case and
requirements
• Acknowledge other important issues such as:• Required vs. optional• Non-functional requirements• Available personnel (skills) and resources
![Page 29: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/29.jpg)
29
Implementation Basics• Review your documented use case with team and
experts• Go into detail of your model; test it using the tools
you have• Look at the use case document and examine the
actors, process flow, artifacts, etc.• You will start to develop a design and an
architecture• Keep in mind that it is more flexible to examine
your interfaces, i.e. between layers and components in your architecture, i.e. between ‘users’ and ‘information’
![Page 30: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/30.jpg)
Actors• The initial analysis will often have many human
actors• Begin to see where these can be replaced with
machine actors – may require additional encoding• If you are doing this in a team, take steps to
ensure that actors know their role and what inputs, outputs and preconditions are expected of them
• Often, you may be able to ‘run’ the use case (really the model) before you build anything
30
![Page 31: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/31.jpg)
Developed for NASA TIWG
Actors• Real people (round heads – smart
consumers of information) and computers (block heads – dump consumers)
• E.g. Data provider, end-user, data manager, alert service
• Primary – initiate (act on)
• Secondary – respond (acted upon)
![Page 32: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/32.jpg)
Developed for NASA TIWG
What’s a pre-condition?
• defines all the conditions that must be true (i.e., describes the state of the system) for the trigger to meaningfully cause the initiation of the use case.
![Page 33: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/33.jpg)
Preconditions• The preconditions are external to your
information system development and you may not understand how they fit in the implementation
• Some level of modeling of these preconditions may be required (often this will not be in your first pass encoding which focuses on the main process flow, goal, description, etc.)
• Beware of using another entities data and services: policies, access rights, registration, and ‘cost’
33
![Page 34: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/34.jpg)
Developed for NASA TIWG
What’s a post-condition?
• describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.
![Page 35: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/35.jpg)
Developed for NASA TIWG
Success scenarios
• A re-statement of how the use case via its flows and actors and resources results in achieving the result
• Describe artifacts produced
• Describe impacts and metric values
![Page 36: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/36.jpg)
Developed for NASA TIWG
Failure scenarios• A statement of how the use case via its flows
and actors and resources did not result in achieving the result
• Describe role of actors in failure• Describe role of resources in failure• Describe what artifacts were and were not
produced• Describe impacts of failure and any metric
values• And when you are doing science this is 80%
of the outcome!
![Page 37: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/37.jpg)
Developed for NASA TIWG
Normal (process) flows
• A basis step of (usually) distinct steps that result when the use case is triggers (commences)
• Steps are often separated by actor intervention or represent modular parts of the flow (can encapsulate activities)
• Can have loops
• Should end with the final goal achieved
![Page 38: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/38.jpg)
Process flow• Each element in the process flow usually denotes
a distinct stage in what will need to be implemented
• Often, actors mediate the process flow• Consider the activity diagram (and often a state
diagram) as a means to turn the written process flow into a visual one that your experts can review
• Make sure the artifacts and services have an entry in the resources section
38
![Page 39: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/39.jpg)
Developed for NASA TIWG
Alternate (process) flows• Variations from the main flow, often invoked
by valid but non-usual (or rules)
• Activity diagrams are useful in representing this part of the document
• Do not usually represent exceptions/ error flows
• Can often help to identify general patterns in the use case via similarities with the normal flow
• While many are possible, usually only include one - illustrative
![Page 40: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/40.jpg)
Developed for NASA TIWG
Non-functional requirements• (from Wikipedia): requirements which specify
criteria that can be used to judge the operation of a system, rather than specific behaviors.
• This should be contrasted with functional requirements that specify specific behavior or functions.
• In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be.
![Page 41: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/41.jpg)
Developed for NASA TIWG
More - non-functional• (from Wikipedia): Non-functional requirements are
often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements".
• Qualities, aka. non-functional requirements, can be divided into two main categories.– Execution qualities, such as security and usability, are
observable at run time.– Evolution qualities, such as testability, maintainability,
extensibility and scalability, are embodied in the static structure of the software system.
![Page 42: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/42.jpg)
Artifacts – things left behind• Add artifacts that the use case generates to the
resources list in the table• It is often useful to record which artifacts are critical
and which are of secondary importance• Be thinking of provenance and the way these were
produced, i.e. what went into them and produce suitable metadata or annotations
• Engage the actors to determine the names of these artifacts and who should have responsibility for them (usually you want the actors to have responsibility for evolution)
42
![Page 43: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/43.jpg)
Developed for NASA TIWG
General Diagrams
• Schematic of the Use case• Drawing diagrams:• Stick figures for actors (person or
computer)• Boxes to denote resources• Arrows to denote process flow• Concept maps are a useful tool
![Page 44: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/44.jpg)
Developed for NASA TIWG
Schematic
![Page 45: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/45.jpg)
45
![Page 46: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/46.jpg)
Diagrams
• Use Case Diagram• State Diagram• Activity Diagram• Other Diagrams
![Page 47: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/47.jpg)
47
![Page 48: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/48.jpg)
Schematic
![Page 49: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/49.jpg)
Reviewing the resources• Apart from the artifacts and actor resources, you may
find gaps• Define/ find the authoritative sources for data,
information, metadata, configuration• Your encodings can also be a resource, make it a first
class citizen, e.g. on the web give it a namespace and a URI
• Sometimes, a test-bed with local data is very useful as you start the implementation process, i.e. pull the data, maybe even implement their service (database, etc.)
49
![Page 50: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/50.jpg)
So far … Summary
• By now, the reality of going into complete detail for the design should be apparent
• Keeping it simple is also very important as you begin to implement
• Being prepared to iterate is really essential• Now is the time to validate your model with
domain experts and your team• The next stage would be to assess your
technology components and design (but we cover that later) 50
![Page 51: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/51.jpg)
Interfaces
• Increasingly in tiered architectures there are numerous interfaces
• Information flow at interfaces and thus software engineering at those interfaces becomes a very important consideration
• Is often left to the ‘finish work’ but usually should not
51
![Page 52: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/52.jpg)
Back to what’s next…
52
![Page 53: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/53.jpg)
Developed for NASA TIWG
Informatics Requirements• Functional requirements specify specific behavior or
functions. – In general, functional requirements define what a system
is supposed to do whereas non-functional requirements define how a system is supposed to be.
• Requirements which specify criteria to judge the operation of a system, rather than specific behaviors aka "constraints", "quality attributes", "quality goals" and "quality of service requirements". – Execution qualities, such as security and usability, are
observable at run time.– Evolution qualities, such as testability, maintainability,
extensibility and scalability, are embodied in the static structure of the software system.
![Page 54: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/54.jpg)
Requirements• Start with the actors and capture their
required actions, artifacts, outcomes, etc.• At each stage of the general (and alternate)
process flow, ask them what is required at the stage (and what is optional)
• Also ask about non-functional requirements (preferably without calling them that)
• This is required for human and computer actors! Yes, how do you ask a computer?• Read the documentation, try it out, or have
someone do that for you
![Page 55: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/55.jpg)
Metrics• Things you can measure (numerical)• Things that are categorical• Could not do before• Faster, more complete, less mistakes,
etc.• Wider range of users
• Measure or estimate the baseline before you start – use case!
55
![Page 56: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/56.jpg)
Evaluation?• Can be structured or less-structured• A good way to start is to get members of
your team (or someone else) to do a peer evaluation
• This is a professional exercise, treat it that way at all times
• Other possible techniques for moving forward on evolving the design, what to focus upon, priorities, etc.: SWOT, Porter’s 5 forces
56
![Page 57: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/57.jpg)
Evaluation References• Twidale, Randall and Bentley (1994) and
references therein• Scriven (1991, 1996)• Weston, Mc Alpine, and Bordonaro, (1995)• Worthen, Sanders, and Fitzpatrick, (1997)
57
![Page 58: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/58.jpg)
Result/ outcome• Refer to the use case document
• Outcome (and value of it) is a combination of data gathering processes, including surveys, interviews, focus groups, document analysis and observations that will yield both qualitative and quantitative results.
• Did you meet the goal?
58
![Page 59: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/59.jpg)
Evaluation (Twidale et al.)• An assessment of the overall effectiveness of
a piece of software, ideally yielding a numeric measure by which informed cost-benefit analysis of purchasing decisions can be made.
• An assessment of the degree to which the software fulfils its specification in terms of functionality, speed, size or whatever measures were pre-specified.
59
![Page 60: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/60.jpg)
Evaluation• An assessment of whether the software fulfils
the purpose for which it was intended.• An assessment of whether the ideas
embodied in the software have been proved to be superior to an alternative, where that alternative is frequently the traditional solution to the problem addressed.
• An assessment of whether the money allocated to a research project has been productively used, yielding useful generalizeable results. 60
![Page 61: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/61.jpg)
Evaluation• An assessment of whether the software
proves acceptable to the intended end-users.• An assessment of whether end-users
continue to use it in their normal work.• An assessment of where the software fails to
perform as desired or as is now seen to be desirable.
• An assessment of the relative importance of the inadequacies of the software.
61
![Page 62: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/62.jpg)
(Orthogonal) Dimensions of evaluations
Structured Less structured
Quantitative Qualitative
Summative Formative
Controlled experiments Ethnographic observations
Formal and rigorous Informal and opportunistic
62
• evaluation carried out for two reasons:• grading translations = summative evaluation• giving feedback = formative evaluation
![Page 63: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/63.jpg)
Keep in mind• You need an evaluation plan that can lead to
improvements in what you have built• You need an evaluation to value what you
have built• You need an evaluation as part of your
preservation documentation – um, so that you might actually use the approach again, or um, reproduce it ;-)
63
![Page 64: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/64.jpg)
Summarizing…
64
![Page 65: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/65.jpg)
Developed for NASA TIWG
When someone asks: “What is your use case”?
• Treat it like your ‘elevator pitch’• Know them, especially the ones you
have implemented• Tell them how you used it to develop
a solution FOR use
![Page 66: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/66.jpg)
If you have not developed one
• Try reverse engineering • Start with a personal example• E.g. balancing your checkbook (hah,
that’s SO 80’s)• What’s an example that comes to
mind?
66
![Page 67: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/67.jpg)
Developed for NASA TIWG
Resources• http://alistair.cockburn.us/index.php/Use_cases,_ten_years_later• http://members.aol.com/acockburn/papers/AltIntro.htm• http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases• http://alistair.cockburn.us/images/Usecasesintheoryandpractice180.ppt• http://alistair.cockburn.us/images/Agileusecases1dy.ppt• http://alistair.cockburn.us/index.php/Structuring_use_cases_with_goals• http://www.foruse.com/publications/bibliographies/usecases.htm• http://en.wikipedia.org/wiki/Use_case• http://www.ddj.com/dept/architect/184414701• Omnigraffle (Mac) or • Cmap• ESIP wiki template
http://wiki.esipfed.org/index.php/SolutionsUseCase_Template
![Page 68: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/68.jpg)
Discussion• About use cases?
• Requirements?
• Backward assignment (previous weeks)– Detect the use cases in the presentations (if they
are not explicit)– Drive your friends crazy but asking them for their
use case
68
![Page 69: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/69.jpg)
Assignment 2• Surprise: use case development
• Due in ~ three 1/2 weeks (before SPRING break!)
• Let’s take a closer look
69
![Page 70: Capturing the problem: Use case development and requirement analysis](https://reader033.vdocuments.net/reader033/viewer/2022051401/568148ad550346895db5c020/html5/thumbnails/70.jpg)
What is next• NO CLASS next week
• Office hours are on Tuesday 19th, 3pm
• Week 5+6 (26th) – presentations – be prepared
• Reading for this week is review
• Reading for week 5 is in preparation for week 6! 70