Get documents about "Rfp Template for Black Car Service - PowerPoint
W
Description
Rfp Template for Black Car Service document sample
Document Sample
CMPT 370: Information Systems Design
Lecture Topic: Underpinnings of Requirement Analysis
Class Exercise: Use Cases
Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003
Objectives
This lecture introduces Requirements Determination:
• Concept of system requirements
• Techniques to solicit requirements
• Elaboration of use case diagrams
• Organization and documentation of system requirements in
the form of Use Cases
Stakeholders (customers and end users) have goals (also known as
needs) and want computer systems to help them meet them. There are
several ways to capture these goals and system requirements, the
better ones are simple and familiar because they make it easier –
especially for users and customers – to contribute to their definition or
evaluation.
2
Context of requirements analysis
•Build the right product
•Build the product right
Requirements
( Analysis) Design
„What‟ „How‟ SMOP
-fuzzy-
3
Why requirements?
Gap between stakeholders
• Users have the vision
Stakeholders • Developers need the specifications
Analysis and Design span the gap
• Understand user needs
• Transform needs into specifications
??
This is the creative part of software
development
This is the area where projects fail
•interpreting reality
Vision/Requirements
•constructing reality Product
Developers Remember to Observe “Bricks &
Mortar” Business to determine
system behaviour
4
What is a requirement?
A capability needed by the user to solve a problem
to achieve an objective
A capability that must be met or possessed by the
system to satisfy a contract, standard, specification
or other formally imposed documentation
A requirement may range from a high-level abstract statement of
a service or of a system constraint to a detailed functional
specification
5
Evolution of requirements
It is inevitable that requirements will evolve over the course of
the Software Development process
• Some requirements may be well known and understood at
the onset of the project
• Some requirements may not be well fully defined until the
project is well underway
• Some requirements may not be identified or discovered
until later on in the Software Development project
• Requirements can be volatile
Why projects fail w.r.t. bad requirements:
• miscommunications and misunderstandings lead to
increased costs of a software process
Requirements drive
• Assumptions, and Decisions
• Which Affect System Development
• And Information/Tool/Data Design & Architecture (Soln.)
6
What is a goal?
Goal
• A general intention of the use of the system
– ease of use
• Verifiable non-functional requirement
– A statement using some measure that can be objectively
tested (e.g. number of users put onto a system, or reduce
costs of process by $ X dollars)
• An overall objective of a stakeholder (any person or
organization interested in the the success of the system)
– Increase profit by Increasing revenue and/or Decreasing
costs/expenses
Goals are helpful to developers as they convey the intentions of the
system stakeholders
7
Goals and requirements
Goals are the essence of success
• We could meet the requirements in the
development of the project, however if we have
not recognized and thus met the goals the
stakeholders will be unsatisfied by the end result
It is then paramount that as we solicit and develop requirements
that we keep in mind the goals necessary for success
8
Types of requirements
Functional requirements
• Statements of functionality or services the
system should provide, how the system should
react to particular inputs and how the system
should behave in particular situations.
Non-functional requirements
• Constraints on the services or functions offered
by the system such as performance constraints,
standards, reliability, availability (e.g. 24x7, short
Transaction Time)
Domain requirements
• Requirements that come from the application
domain of the system and that reflect
characteristics of that domain
9
Where do requirements come from?
Functional requirements come from users
• Current processes (as-is) – Past or Present
• Desired processes (to-be) – Future
Non-functional requirements come from the
technical environment
• Current operational environment
• Desired operational environment
Domain requirements come from subject matter
experts (SMEs)/domain experts
• Business environment constraints
• Expressed in domain terminology
10
Functional requirements considerations
Wants versus Needs (Priority)
• A want may be a feature of the system or
• A want may be counter to a need
Statement of problem or solution
• Users tend to think of requirements in the form of solutions
... Without truly acknowledging the need
• Users tend to think in terms of automation of current
processes (as-is) without recognizing that creating a
system can also result in changes in process (to-be) (e.g.
What processes changed when Air Canada implemented
self-service kiosks?)
• What is the impact of the system
– Other roles, users, other systems, other processes
11
Non-Functional requirements considerations
Measurability
• Requirements are stated in ways that are difficult to
measure such that at the end of the project it is not clear if
the requirement has been satisfied or not
• In terms of Usability, measurable items may include #
clicks, # screens to complete a task.
• In terms of e-commerce websites, perhaps # transactions
per minute or per hour are measured (temporal)
Source
• It is sometimes imperative that the software development
team themselves introduce and nurture the non-functional
requirements among the stakeholders
12
Domain requirements considerations
Understandability
• Requirements need to be expressed in the language of the
application domain (terminology)
• These requirements may not be understood by software
engineers developing the system
• Example: Airline Industry
– Actors include Passengers, Customers, Stewards, Cleaning
Crew, Maintenance Crew, Pilots
– Business Terminology: Tickets, Fare, Booking, Reservation,
Comp Tickets, Class of Fare (B, M, X, Z)
Implicitness
• Domain specialists understand the area so well that they
do not think of making the domain requirements explicit
• If you are not a domain specialist, how can you become
one to work:
– Documents describing Business or Biz Problem (e.g. RFP)
– Focus on observing “bricks & mortar” operation (actors and
interaction to accomplish tasks)
13
Problem analysis
1. Gain agreement on the problem definition
• A problem may also be an opportunity
2. Understand the root causes
• The problem behind the problem
3. Identify the stakeholders and users
4. Define the system boundary
5. Identify the constraints to be imposed
(assumptions)
The goal of problem analysis is to gain a better
understanding of the problem being solved before
attempting to solve it
14
1. Problem statement
The problem of Describe the problem
Affects Identify the
stakeholders affected
by the problem
Describe the impact of
The result of which this problem on
stakeholders and
business activity
The benefits of Indicate the benefits of
a solution
Write the problem down and see if everyone agrees
15
1. Problem statement example
The problem of Inaccuracies in sales orders
Sales order personnel,
Affects customers, manufactoring,
shipping and customer
service
The result of which Is increased scrap,
excessive handling costs,
customer dissatisfaction,
and decreased profitability
A new system to address
The benefits of the problem include
• Increased accuracy of
sales orders at point of
entry
• Improved reporting of sales
data to management
• Ultimately higher profit
16
2. Root cause
What is the problem behind the problem
• What are the factors that contribute to the
problem
Many times people know the root cause
• But no one has asked before
• May required an impact analysis to quantify the
impact and contribution to the root cause
• Results can identify the which root causes are
the ones to be concerned about
– Some may not be worth fixing
– This justifies thinking about potential solutions
17
3. Identify stakeholders and users
Stakeholder – anyone who could materially
be affected by the implementation of the
system
Stakeholders may be
• Users of the system – needs are easy to focus on
• May be indirect, or only affected by the business outcomes
• Involved in the solution development and / or maintenance
of the system (i.e. requirements from “day one”)
• Will evaluate and „bless‟ the system once developed and
delivered (acceptance testing)
18
4. Define the system boundary
This is a transition state as we take our
understanding of the problem and start to
consider potential solutions
The system boundary defines the border
between solution and the elements outside
the system that surround the system
• Our system
• Things that interact with our system (actors)
19
5. Constraints on the solution
Constraint – a restriction on the degree of
freedom that we have in providing the
solution
Potential system constraints
• Economic – budget considerations
• Political – interdepartmental issues
• Technical – choice of technologies
• System – existing standards or systems
• Environmental – regulatory constraints
• Schedule and Resource – timing and use of
labour, resources can be considered computing
resources too (dynamic on-demand world)
20
Techniques to solicit requirements
The task of the requirements determination
phase is to determine, analyze and
negotiate requirements with the
stakeholders
The task involves various techniques of
gathering information from the customers. It
is concept exploration through structured
and unstructured interviews of users ,
questionnaires, study of documents and
forms, etc.
Requirements negotiation and validation is done in parallel, with
reviews and walkthroughs together with stakeholders
21
Common Issues in Requirements Gathering
Anomalies in nomenclature
• Synonyms – same object to have two different names (e.g.
cost in Inventory, wholesale price in Accounting)
• Homonyms – same attribute name to have two different
meanings (e.g. price – retail or wholesale)
• Inconsistencies (date formats)
Find Business Rules
Large Projects require decomposition into smaller
sub-requirements
For terminology, perhaps have a glossary which
contains information such as: Name, Description,
Ranges, Units, Accuracy, Precision
22
Traditional techniques
Traditional methods of requirements
elicitation include:
• Interviews
• Questionnaires
• Observation
• Study of business documents
23
Interviews
Primary technique of fact finding and information gathering.
Interviews with domain experts are frequently a simple
knowledge transfer, but may be done with different levels of
granularity (i.e. management vs. operational staff – different
roles). Interviews with customers are more complex.
There are two kinds of interviews, structured and
unstructured. A structured interview is prepared in advance,
has a clear agenda and many questions are pre-determined.
Consider multiple interviews or meetings (i.e. clarifications
once more is understood re: domain).
Listening and documenting are key.
Allow diagram drawing to understand the interviewee‟s view
of the relationships and dependencies in a problem domain.
Recognize different personality types may contribute
information willingly at different levels
24
Questionnaires
• Efficient way of gathering information from many
customers. Less productive since we cannot get
clarification (unless collecting personal/private
information – not always allowed)
• Types of Questions
– Multiple-choice Questions
– Rating Questions
– Ranking Questions
25
Observation
Business Process
• “Bricks & Mortar” business operations to observe
actors and actions that are valid
• Passive vs. Active Observation
– Raw Observation vs. Re-enactments
– Does the Presence of Observation make people act
differently?
Existing computing systems already exists
• Observe users through their interactions and
frustrations with the system
26
Study of Business Documentation
Initial Requests for Proposals (RFPs)
Operations Manual
• For training new staff, with information on the “lingo” and
Business Rules
Existing computing systems already exists
• Documentation from the previous design phase
(requirements document)
• Documentation for users (user manual)
“Paper-Trail” Forms
• Processes and Terminology already well thought through
and designed
• Signatures for approval, or carbon copies – suggesting
workflow relationships exist (Patterns)
27
Newer techniques
Methods
• Rapid Prototyping
• Joint Application Design (JAD)
• Rapid Application Development (RAD)
Higher Cost and Effort
Useful when project has higher risk
• Unclear objectives
• Undocumented processes
• Unstable requirements
• Inexperienced developers
• Insufficient user commitment
28
Rapid prototyping
Use the concept of prototyping to discover
requirements
Real-world Web Applications – develop static
HTML Mockups to look at scenarios and answer
data questions
Clarify difficult requirements and avoid
misunderstandings in terms of problem domain
Misunderstandings can occur if customer does not
understand the difference between static mockups
and a live fully-functioning complex dynamic system
Two prototyping methodologies
• Throw-Away – “Quick & Dirty”
• Evolutionary – Targets speedy delivery, so care put into
developing prototype as it will live throughout software
lifecycle
29
Joint Application Design (JAD)
Newer Technique, but has been around since
1970s.
Group synergy is likely to produce better
requirements, increase productivity, learn faster,
make more educated judgments, eliminate errors,
take riskier decisions, focus in important issues
brought up in group environment
Participants
• Leader (communication skills)
• Scribe
• Customers (users and managers)
• Developers
Disaster at Ford with Edsel – car design by
committee
30
Rapid Application Development (RAD)
An approach to software development as a whole, with focus
on quick results
Five-step approach
• Evolutionary Prototyping
• CASE tools with code generation and round-trip engineering
• Specialists with Advanced Tools (SWAT) – the “A” Team of
designers, and developers
• Interactive JAD (with Scribe swapped with SWAT)
• Timeboxing – project management method of fixing development
time period to avoid “scope creep”
Problems encountered with RAD (since we are going so
“rapidly” fast)
• Inconsistent GUI Designs
• Specialized (not Generalized) Solution inhibits reuse
• Deficient Documentation (“Just Do It”)
• Software difficult to maintain or scale up
31
Requirements determination
Requirements analysis includes
negotiations between developers and
customers.
• This step is necessary to avoid and eliminate
contradicting and overlapping requirements and
also to conform to the project budget and
timeline
The product of the requirements
determination phase is a requirements
document.
• This is mostly a narrative text document,
normally in the format of use cases
32
Requirements Document Template
Project Preliminaries
• Purpose and Scope
• Business Context
• Stakeholders
• Ideas for Solutions
• Document Overview
System Services
• Scope of the System
• Functional Requirements
• Data Requirements
System Constraints
• Interface Requirements
• Performance Requirements
• Security Requirements
• Operational Requirements
• Political and Legal Requirements
• Other Constraints
Project Matters
• Open Issues
• Preliminary Schedule
• Preliminary Budget
Appendices
• Glossary
• Business Documents and Forms
• References
33
Use Case Diagrams revisited
Use Case specification includes
representation of actors, use cases and four
kinds of relationships:
• Association
• Include
• Extend
• Use Case generalization
34
Association relationship
The association relationship establishes the
communication path between an actor and a
use case
pump gas
customer
clean the windows
check the oil
35
<<Includes>>
The includes relationship allows the factoring out of
common behaviour in the included Use Case(s)
the included use case is necessary for the completion of the use
case (“HAS TO BE COMPLETED”)
pump gas
«include»
customer
get paper towel
clean the windows
«include»
check the oil
36
<<Extends>>
The extends relationship provides a controlled form of
extending the behaviour of a use case by activating
another use case at specific extension points
the extended use case is optional for the completion of the use
case (“COULD BE COMPLETED”)
pump gas
«include»
customer clean the windows get paper towel
«include»
check the oil
«extend» add oil
37
<<Generalization>>
The generalization relationship provides a form of
specialization to a base use case
the specialized use case is a replacement for the generalized
use case
pump gas
pump propane
«include»
customer clean the windows get paper towel
«include»
check the oil
«extend» add oil
38
Use Diagrams in Practice
In practice projects can put too much effort into discovering
includes and extends type relationships.
When doing Use Case Documents (more later)… Go for
simplicity, flexibility and understandability by stakeholders.
The important aspect of use cases is the descriptive text and
not the diagram.
pump gas
pump propane
customer clean the windows get paper towel
«include»
«include»
check the oil
«extend» add oil
39
Use cases
• A use case is a prose description of a system's
behavior when interacting with the outside world
• Among the various schools of thought people
have suggested and recommended almost all
combinations and permutations of answers to
the basic questions:
– Is a use case a requirement or just a story?
– Is a scenario just another name for a use case?
– Is a use case a formal, semi-formal, or informal
structure?
– Is there a linking structure for use cases, or do they just
come in piles?
40
Use case formality
The happy medium for use cases
• Use cases really are requirements and need a
basic structure, and also
• Allow people to write whatever they want when
they need to.
a use case describes an actor trying to
achieve a goal by using the system
1. Linking use cases to actors' goals is significant
because it shifts the use case writer's attention
away from the function lists that most
developers worry about and puts it back on the
users
2. Note that goals sometimes fail
41
Use case granularity
Goals come in different sizes.
• How do we know what the right size is?
• No easy answer, look for natural goals in terms
of business value
• Look for enforcement of the „contract‟ between
stakeholders and the system
– All stakeholders must be satisfied in terms of their
interests
42
Use case formats
Narrative
• The use case brief consists of two to four sentences
summarizing the use case. It fits well in a spreadsheet cell, and
allows the other columns in the spreadsheet to record business
priority, technical complexity, release number, and other planning
information.
• The casual use case consists of a few paragraphs of text,
covering the items mentioned above.
Scenario (** most popular)
• The fully-dressed use case features the long template with
fields for stakeholders, minimum guarantees, post-conditions,
business rules, performance constraints, and so on.
Conversational
• The conversational use case follows a table - labeled with the
set of actors in the first row. The columns are filled one cell per
row, and going down in a timeline fashion, with information about
the behaviour(s) of one of the actors through specific points of
the conversation
43
Use case format
A use case format is really just a stylized
way of writing, a form of prose having two
sections.
1. The first section describes a basic scenario
containing actions and interactions.
2. The second section presents a set of scenario
fragments, describing how the behavior differs
under varying circumstances.
A use case treats the system as a “black
box”
• the user does this; the system does that; the system talks
to another system; something goes wrong; the system
now does this instead; and so on
44
Use case limitations
Use cases describe behavioural requirements.
They don't take care of system design, UI design,
feature lists, or testing (even though many people
wish they would).
• A use case is normally intended as a requirements
document, and the UI design is a design created by
trained people after being told what the system should do.
UI design is brittle, changing often.
• Use cases have a basic mismatch with feature lists. The
same system feature is likely to show up as a line item in
multiple use cases
• Use cases are not test plans or test cases. They are
missing the data values needed for test cases.
45
Use case common mistakes
The two most common mistakes and most costly to
the project are including too many details and
including UI specifics.
• Both make the use cases long, hard to read, and brittle.
It requires effort to learn how to write in a
technologically neutral way
• System presents the options. User selects an activity.
The greatest value of the use case does not lie in
the main scenario, but in alternative behaviors.
• The main scenario may occupy a quarter to one-tenth of
the total length of the use case, because there are so
many alternatives to handle.
46
Use case example
Example Template
• Template:
CP Rail examples
• UC007 View BOL Status
• UC005 Complete Shipping Instructions
Leads Mgmt System Example (Insurance)
• Manage Agency Profile
47
Use Case impact of Associations, Includes,
Extends and Generalizations
Use cases that are referenced through include,
extend and generalization relationships should be
indicated in the use case itself
• Extension Points
• <If the use case has extension points, list them here.>
• Related Use Cases
• < If the use case include other use cases, list them here.>
Within the steps of the use case itself indicate
transfer of control to another use case
48
Textbook Information
Section 3.1 – Principles of Requirements
Determination
Section 3.2 – Requirements Elicitation
• Traditional Techniques: Interviews, Questionnaires,
Observation, Business Docs
• Newer Techniques: Prototyping, JAD, RAD
Section 3.3 – Requirements Negotiation and
Validation
• Scoping, Requirements Dependency Matrix, Risks and
Priorities
Section 3.4 – Requirements Management
• Classification, Identification, Hierarchies, Change
Management
Section 3.6 – Requirements Document
• Template (pg. 100), System Constraints, Project Matters,
Appendices
49
Exercise
Video (approximately 1 Hour Long)
• Suggest you take notes on the Video
• Apologize in Advance for the Bad Camera
Techniques
Group Yourselves into Two or Three only
Homework, hand in #2 next week in-class
for credit
Setup Business Scenario, Purpose,
Processes for Resort Property Sales,
Locations for Business
50
