2. Some Airline Use Cases
flight details.
4
provides high level visual representation of user requirements
5
Primary actor
Initiates
Extend: Can be extended to
another usecase
More example: ATM
6
Include: subtask
3. relationship
7
uses = includes
8
9
- preferably as a short,
active verb
phrase.
This is
usually an expanded version of what you entered in the “Title”
field.
interacts with your system to achieve the goal of this use case.
first event
in this use case.
4. the state the system is in after all the
events
in this use case have taken place.
field
contains the example from our previous post - i.e. the flow of
events
from preconditions to postconditions, when nothing goes wrong
the
other scenarios for this use case - including exceptions and
error cases.
-explanatory.
10
Activity Diagram to show the flows:
11
12
Use Case Example:
13
5. Another Example:
14
15
Use Case Description for an ATM
Name: Withdraw Cash
Actor: Account Owner
Description: The Account Owner withdraws a specific amount
of cash from
a specified account.
Preconditions:
1. The Account Owner is logged in to the ATM.
2. The Account Owner has at least 1 account with a positive
balance.
3. The ATM contains cash.
Postconditions:
1. The requested amount of cash has been dispensed.
2. The account balance is reduced by the withdrawn amount
plus any fees.
3. The ATM cash balance is reduced by the withdrawn amount.
6. Priority: High
16
Normal Flow:
1. Account Owner selects Withdrawal action.
2. System displays user’s accounts.
3. Account Owner selects desired account.
4. System asks user to choose amount to withdraw from a list.
5. Account Owner chooses amount to withdraw.
6. System dispenses cash.
7. Account Owner removes cash from dispenser.
Alternative Flows:
at step 4, actor can choose to enter a custom amount and join at
step 6
Exceptions:
amount is not a multiple of $20.00
amount exceeds $400
amount exceeds account balance
amount exceeds cash available in ATM
indicate the step number where the exception
7. could take place and how the system handles it 17
or part of the use case, e.g., certain people can
perform specific flows (Admin vs, regular user)
• Conversely, from use cases, some BT maybe
drawn
18
• Identify the actors first, then layout the business
processes supported by the system and define
the use cases for activities where actors and
systems interact
E.g., purchase-a-ticket etc
• Create a specific scenario to illustrate each
business process, then generalize the scenarios
and then identify actors
e.g., assign_a_seat
19
8. “what task must be performed to
complete this process or convert input to
specific output”
e.g., generate_profit_report
the system must respond, then relate this
event to an actor
e.g., sound-alarm
20
• Use CRUD analysis to identify data
entities that require use cases to create,
read, update, delete it.
e.g., change_reservation,
cancel_reservation
• Examine the context diagram, and ask
“what do each external entities want to
achieve with the help of the system?”
e.g., order_a_book
21
9. 22
-Case Traps to Avoid
-cases
-cases
-priority use cases.
23
Questions to ask.
Is the goal (measurable value) of the use case clear?
use case?
alone activity, which could be chained
with others?
10. verifiable, and feasible?
24
iewpoint, shows external
behavior and appearance
with internal behavior, algorithms, storage
◦ Use cases include functional requirements
◦ SRS document includes the write-up of use cases.
25
User Stories for Agile Development (V)
http://www.youtube.com/watch?v=NzSsE37opB0
26
Use Case and User Stories (V)
11. http://www.youtube.com/watch?v=GoudHe5nxfk
END
27
M2 PART 2: Sexuality Development (Guided Notes)Chapter 6 -
CAS 325B
What messages about SEXUAL CULTURE are posed as norms
for adolescents in these contexts?
HINT: May take some thought on your own, in addition to what
is presented in class material.
American culture
media portrayal
community messages
family messages
Development of sexual activities in adolescents:
Current rates by age 20 in US:
Current rates for 12th graders in US:
Current rates for 9th graders in US:
12. Rates of sexual initiation before age 13 (by ethnicity)
African American Teens:
Latino Teens:
Non-Latino White Teens:
Sexual scripts:
Risk factors:
Sexual minorities:
Attitudes:
Behaviors:
Comparison of heterosexual and sexual minority findings:
Similarities:
Differences:
Trends in adolescent pregnancy:
Current number of girls under 18 in US per year birthing a
child:
13. How do US rates compare to rates in…
21 other countries studied:
Rates in the Netherlands:
3 reasons identified in cross-cultural comparison studies:
What is the major concern about sources of sex information for
teens?
Cognitive Factors in Adolescence (impacting sexual decisions)
Explain factor unique to adolescents:
Depersonalized Orientation:
Approaches to Sex Education
availability:
effectiveness:
What is the most effective sex education? (p. 220 connecting
with health and well-being box)
15. 6
Conditions that trigger activities
7
Facts derived from other conditions
8
tions
Formulas, algorithms, tables
9.2 Discovering Business Rules
constraints on process:
◦ Why must we do it that way?
◦ What does the government want?
◦ How is that calculated?
◦ What causes changes to objects?
◦ How does the system know what to do next?
◦ What can and cannot happen? (and why)
◦ What may the user do next?
◦ How are these pieces of data related?
16. 9
10
9.3 Documenting Business Rules
-wide catalog:
◦ ID (for easy reference)
◦ Definition
◦ Type
◦ Probability of change (static/dynamic)
◦ Source (company policy, public law, agency
regulation,…)
11
12
E N D
13
Chapter 10:
18. Template 3
May be slight modified in our
project this semester!!
7
1. Introduction
1.1 Purpose
<This subsection should
a) Delineate the purpose of the SRS; b) Specify the intended
audience for the SRS>
1.2 Scope
<This subsection should
a) Identify the software product(s) to be produced by name
(e.g., Host DBMS, Report Generator, etc.);
b) Explain what the software product(s) will, and, if necessary,
will not do;
c) Describe the application of the software being specified,
including relevant benefits, objectives, and goals;
d) Be consistent with similar statements in higher-level
specifications (e.g., the system requirements
specification), if they exist>
1.3 Definitions, acronyms, and abbreviations
<This subsection should provide the definitions of all terms,
acronyms, and abbreviations required to
properly interpret the SRS. This information may be provided
by reference to one or more appendixes in the
SRS or by reference to other documents.>
19. 1.4 References
<This subsection should
a) Provide a complete list of all documents referenced
elsewhere in the SRS;
b) Identify each document by title, report number (if
applicable), date, and publishing organization;
c) Specify the sources from which the references can be
obtained.
This information may be provided by reference to an appendix
or to another document.>
1.5 Overview
<This subsection should
a) Describe what the rest of the SRS contains;
b) Explain how the SRS is organized.>
Template 3 Explanations:
May be slight modified in our
project this semester!!
8
2. Overall Description
2.1 Product Perspective
<Describe the context and origin of the product being specified
in this SRS. For example,
state whether this product is a follow-on member of a product
family, a replacement for
certain existing systems, or a new, self-contained product. If the
SRS defines a component
of a larger system, relate the requirements of the larger system
20. to the functionality of this
software and identify interfaces between the two. A simple
diagram that shows the major
components of the overall system, subsystem interconnections,
and external interfaces can
be helpful.>
2.2 Product Features
<Summarize the major features the product contains or the
significant functions that it
performs or lets the user perform. Details will be provided in
Section 3, so only a high level
summary is needed here. Organize the functions to make them
understandable to any
reader of the SRS. A picture of the major groups of related
requirements and how they
relate, such as a top level data flow diagram or a class diagram,
is often effective.>
2.3 User Classes and Characteristics
<Identify the various user classes that you anticipate will use
this product. User classes
may be differentiated based on frequency of use, subset of
product functions used,
technical expertise, security or privilege levels, educational
level, or experience. Describe
the pertinent characteristics of each user class. Certain
requirements may pertain only to
certain user classes. Distinguish the favored user classes from
those who are less
important to satisfy.>
9
21. 2.4 Operating Environment
<Describe the environment in which the software will operate,
including the hardware
platform, operating system and versions, and any other software
components or
applications with which it must peacefully coexist.>
2.5 Design and Implementation Constraints
<Describe any items or issues that will limit the options
available to the developers.
These might include: corporate or regulatory policies; hardware
limitations (timing
requirements, memory requirements); interfaces to other
applications; specific
technologies, tools, and databases to be used; parallel
operations; language
requirements; communications protocols; security
considerations; design conventions or
programming standards (for example, if the customer’s
organization will be responsible
for maintaining the delivered software).>
2.6 User Documentation
<List the user documentation components (such as user
manuals, on-line help, and
tutorials) that will be delivered along with the software.
Identify any known user
documentation delivery formats or standards.>
2.7 Assumptions and Dependencies
<List any assumed factors (as opposed to known facts) that
could affect the
22. requirements stated in the SRS. These could include third-party
or commercial
components that you plan to use, issues around the development
or operating
environment, or constraints. The project could be affected if
these assumptions are
incorrect, are not shared, or change. Also identify any
dependencies the project has on
external factors, such as software components that you intend to
reuse from another
project, unless they are already documented elsewhere (for
example, in the vision and
scope document or the project plan).>
10
3. Use Case Diagram with Use-case descriptions
<Use provided form for each use-case description>
11
4. User Interfaces
<Describe the logical characteristics of each interface between
the software product and the users.
This may include sample screen images, any GUI standards or
product family style guides that are
to be followed, screen layout constraints, standard buttons and
functions (e.g., help) that will appear
on every screen, keyboard shortcuts, error message display
standards, and so on. Define the
software components for which a user interface is needed.
Details of the user interface design
23. should be documented in a separate user interface
specification.>
4.1 Hardware Interfaces
<Describe the logical and physical characteristics of each
interface between the software product
and the hardware components of the system. This may include
the supported device types, the
nature of the data and control interactions between the software
and the hardware, and
communication protocols to be used.>
4.2 Software Interfaces
<Describe the connections between this product and other
specific software components (name and
version), including databases, operating systems, tools,
libraries, and integrated commercial
components. Identify the data items or messages coming into
the system and going out and
describe the purpose of each. Describe the services needed and
the nature of communications.
Refer to documents that describe detailed application
programming interface protocols. Identify data
that will be shared across software components. If the data
sharing mechanism must be
implemented in a specific way (for example, use of a global
data area in a multitasking operating
system), specify this as an implementation constraint.>
4.3 Communications Interfaces
<Describe the requirements associated with any communications
functions required by this product,
including e-mail, web browser, network server communications
24. protocols, electronic forms, and so
on. Define any pertinent message formatting. Identify any
communication standards that will be
used, such as FTP or HTTP. Specify any communication
security or encryption issues, data transfer
rates, and synchronization mechanisms.>
12
5. Other Nonfunctional Requirements
5.1 Performance Requirements
<If there are performance requirements for the product under
various circumstances, state them
here and explain their rationale, to help the developers
understand the intent and make suitable
design choices. Specify the timing relationships for real time
systems. Make such requirements
as specific as possible. You may need to state performance
requirements for individual
functional requirements or features.>
5.2 Safety Requirements
<Specify those requirements that are concerned with possible
loss, damage, or harm that could
result from the use of the product. Define any safeguards or
actions that must be taken, as well
as actions that must be prevented. Refer to any external policies
or regulations that state safety
issues that affect the product’s design or use. Define any safety
certifications that must be
satisfied.>
25. 5.3 Security Requirements
<Specify any requirements regarding security or privacy issues
surrounding use of the product
or protection of the data used or created by the product. Define
any user identity authentication
requirements. Refer to any external policies or regulations
containing security issues that affect
the product. Define any security or privacy certifications that
must be satisfied.>
5.4 Software Quality Attributes
<Specify any additional quality characteristics for the product
that will be important to either the
customers or the developers. Some to consider are: adaptability,
availability, correctness,
flexibility, interoperability, maintainability, portability,
reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and
verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as
ease of use over ease of
learning.>
13
6. Other Requirements
<Define any other requirements not covered elsewhere in the
SRS. This
might include database requirements, internationalization
requirements,
legal requirements, reuse objectives for the project, and so on.
26. Add any
new sections that are pertinent to the project.>
7. Data Flow Diagram
<Draw the Data Flow Diagrams with at least 2 – 3 levels, i.e.,
level 0 and level
1 and 2>
14
8. Functional Requirements (FRs)
This section describes specific features of the software project.
ONE
8.1 <Functional Requirement #1> - Name
8.1.1 Introduction <describe what this FR does >
8.1.2 Inputs <any input data need to this FR>
8.1.3 Processing <details of how this FR processes>
8.1.4 Outputs <any output data from this FR>
8.1.5 Error Handling <any error conditions and how to handle
these error
conditions>
8.2 <Functional Requirement#2>
…
8.n <Functional Requirement #n>
9. Sequence Diagram
<Draw the interactions among the classes>
10. Class Diagram
<Identify all classes with relationship, attributes and also
services>
27. 15
E N D
Chapter 7:
Requirements Elicitation
1
7.1 Elicitation
constraints of stakeholders.
es activities to discover,
extract and define requirements.
non-functional requirements.
-prone
and communication intensive aspect of software
development.
2
3
28. 7.2 Elicitation Techniques
Elicitation Techniques(V)
4
• Traditional approach to communicate
with a user or small group
• Structured vs. Non-structured
(pre determined questions)
Vs
(open questions)
5
Encourage stakeholders collaboration in
defining the requirements.
29. stakeholders and formal roles such as
◦ Facilitator—to lead the process.
- Keeping to the agenda
- Staying in scope
- Moving items to the parking lot
- set Time limits
- Drawing out nonparticipants
◦ Scribe/recorder—to write things down
6
Facilitator’s role is crucial
- Everyone reads vision and scope document
before workshop
- Periodically check requirements for compliance
- Stay on topic, leave other requirements for other
days
7
Use parking-lots for later considerations.
- Don’t forget random but important
information just because it seems off-topic
- Write it down—don’t lose it
so person knows he isn’t being ignored
30. 8
Some Ground Rules for sessions
9
Is a representative group of users who
convene in a facilitated meetings to
generate input and ideas on product
functionality and quality requirements.
Participants normally do not have
decision making authority for
requirements
10
31. • Sometimes requirements can be
generated by observing how the users are
performing the tasks
• Can be time consuming and disruptive to
the user
• Typically important or high-risk tasks are
selected
• Can be silent or interactive
11
is a technique where the existing UI is
examined to discover the user and functional
requirements
Refers to examining any existing
documentation for potential software
requirements.
E.g., business processes, decision rationals,
Forms, user manual etc
12
32. Are a way to survey large group of users to
understand their needs across
geographical boundaries.
• Open-ended vs. Closed Questions
• Well-written questions are key to the
success (GIGO)
13
ysis
It reveals functional requirements regarding the
exchange of data and services between systems.
• Context Diagram or Ecosystem maps are
good indicators for the start
• Can also find the validation criteria for
Data being exchanged
14
7.3 Planning Elicitation
Elicitation efforts
33. (see next pages)
15
16
7.4 Preparing for Elicitation
- Need to decide on the scope taking into
account how much the time is available.
- Align the scope with the overall project scope
defined in the business requirement
- Agenda should be itemized with topics to be
covered, time available for each topic, and
objectives.
17
Schedule the physical resources needed, such as
rooms, projectors, tele-conferencing needs, etc
34. Key to success. Usually prepare open-ended
Questions, such as why?, how? Etc
serves as a starting point.
“it is easier to revise a draft model than to
create from scratch”
18
7.5 Perform the Elicitation Activities
- Explain the approach/technique being
used
- How the information will be captured and
reviewed later
19
Assign a scribe who does not take active role
It should contain: attendee list, invitee not
attended, decisions made, actions to be taken,
division of tasks, outstanding issues, high points
of key discussion
Use white boards, white papers, sticky notes and
35. markers.
Use 4 walls to draw diagrams and create lists of
ideas, issues etc
20
7.6 Follow up after Elicitation
- Review and update notes soon after the session is over
while memory is still fresh
- keep the original, raw notes, just in case
- Soon after, share the notes with participants for review
- Consider to share the notes who did not participate
21
- Examine Any items that need further
explanation
- See if any knowledge gaps encountered
- Examine the “parking lot”
22
7.7 Classifying User Input
The all kinds of user input needs to be classified.
36. —financial, marketplace,
benefits
Scenarios)—user goals, paths to goals
—policies, laws and regulations,
formulas
ts—observable behavior
of system
23
—speed, ease of use, robust,
reliable, secure, efficient (all must be quantified)
—signals, messages, files,
devices, UI standards
—sizes, algorithms, platforms,
languages
—formats, types, ranges,
defaults
Solution
37. Ideas—could be a valid constraint or
other attribute
24
7.8 Knowing When You’re Done
functional requirements
future.”
25
7.9 Avoid Incorrect/missing Requirements
39. Sample CRUDL Matrix in Chemical
ordering system
28
Entity
Use Case Order Chemical Requester
Vendor
Catalog
Place Order
Change Order
Manage Inventory
Report Orders
Edit Requestors
C R R R, L
40. U, D R R, L
C, U, D
R R, L R, L
C, U, L
C: Create R: Read U: Update D: Delete L: List
Some additional Elicitation Considerations:
them?) to find requirements
—it makes him
guide the discussion (play dumb)
—there should be lots of them
most annoying features” or “three
most tedious tasks” or “three most wanted
changes”—ranking helps people think
41. 29
END
30
Chapter 6:
Finding the Voice of the User
1
User Involvement is a critical factor in creating
excellent software. Hence, finding the voice of
42. the user is critical.
Fundamental Steps in finding the User’s voice
Step 1: Identify user classes
Step 2: Select and work with individuals
Representing each user class
Step 3: Agree on the decision makers of the
requirements
2
6.1 Step 1: Identify User classes
User Classes(V)
3
(manufacturing, legal,
help desk)
(Procurers,
45. A Patron is a Process Impact employee at the corporate campus
in
Clackamas, Oregon, who wishes to order meals to be delivered
from the
company cafeteria.
stimated
400 are
expected to use the Cafeteria Ordering System an average of 4
times per
week each (source: current cafeteria usage data). Patrons will
sometimes
order multiple meals for group events or guests.
be placed using the
corporate
Intranet, with 10 percent of orders being placed from home.
Patrons will
wish to set up meal subscriptions, either to have the same meal
to be
delivered every day or to have the day’s meal special delivered
automatically.
46. specific day.
7
• The Menu Manager is a cafeteria employee, perhaps the
cafeteria manager, who is responsible for establishing and
maintaining daily menus of the food items available from the
cafeteria and the times of day that each item is available.
Some menu items may not be available for delivery.
• The Menu Manager will also define the cafeteria’s daily
specials.
• The Menu Manager will need to edit the menus periodically
to reflect planned food items that are not available or price
changes.
8
47. 9
• As the Cafeteria Staff prepare orders for delivery,
they will print delivery instructions and issue delivery
requests to the Meal Deliverer, who is either another
cafeteria employee or a contractor.
• The Meal Deliverer will pick up the food and delivery
instructions for each meal and deliver it to the Patron.
• The Meal Deliverers’ primary interactions with the
system will be to reprint the delivery instructions on
occasion and to confirm that a meal was (or was not)
delivered.
10
Another Example:
48. 6.2 User Representatives:
need to select and work with individuals
representing each user class
• are needed for the development life-cycle:
◦ To provide requirements
◦ To review specifications
◦ To evaluate demonstrations
◦ To perform or witness testing
marketing,…) can mistranslate user needs
11
and Development =>
Product Champion is important
• serves as the primary interface between
49. members of a single user class and BA.
• collects the requirements from others members
of the user classes and try to reconcile, if any
inconsistencies
• best if they have power to make the decision
12
External Product Champions
contract customer projects
-term customers
13
50. Examples of Product Champion activities:
Planning
◦ Refine scope and limitation of the product
◦ Identify external with system interfaces
◦ evaluate the impact on business
◦ transition to new system
14
◦ Collect input from the user class (other
users)
◦ develop scenarios/use cases/user stories
◦ resolve conflicts of requirements with the
user class
◦ define priorities
◦ evaluate prototypes
51. ◦ provide input regarding the performance and
other quality requirements(non functional)
15
◦ Review specifications,
◦ develop acceptance criteria,
◦ provide test data,
◦ do beta testing
◦ write or review manuals,
◦ prepare training,
◦ give demonstrations to user class
◦ Evaluate and prioritize defects and enhanceme nts,
◦ determine change impact on user and business
16
52. ◦ Different tasks, needs, experience, knowledge
◦ There may be subclasses
◦ There may be expert/nonexpert users within class
17
resistance of having PC
requirements cause failures
use an non-valuable one
anagers must make decisions” =>
◦ Champion makes user requirements decisions
53. ◦ Managers retain business decisions—scope,
schedule, cost
18
t their users
views
leave decisions to analyst
represent
19
54. 20
6.3 Agree on the decision makers of the
requirements (Resolving Conflicts )
ividual users
=> champion decides
=> most favored user, i.e.,
greatest impact on business success
=> use business objectives to establish priorities
=> defer to champion
=> customer decides
21
