Rfp Template for Black Car Service - PowerPoint

Document Sample
Rfp Template for Black Car Service - PowerPoint Powered By Docstoc
					    CMPT 370: Information Systems Design

Lecture Topic: Underpinnings of Requirement Analysis
Class Exercise: Use Cases

          Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003
   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

 Context of requirements analysis

                              •Build the right product
                              •Build the product right
( Analysis)          Design

      „What‟             „How‟       SMOP

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
                          This is the area where projects fail

                    •interpreting reality 
                    •constructing reality  Product

Developers               Remember to Observe “Bricks &
                          Mortar” Business to determine
                          system behaviour

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

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.)

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

    Goals are helpful to developers as they convey the intentions of the
                             system stakeholders

 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

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
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

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

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

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)
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

The goal of problem analysis is to gain a better
   understanding of the problem being solved before
   attempting to solve it

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
1. Problem statement example
   The problem of           Inaccuracies in sales orders
                             Sales order personnel,
   Affects                   customers, manufactoring,
                              shipping and customer
   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
                               • Improved reporting of sales
                                 data to management
                               • Ultimately higher profit

2. Root cause
   What is the problem behind the problem
    • What are the factors that contribute to the

   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

3. Identify stakeholders and users
   Stakeholder – anyone who could materially
    be affected by the implementation of the
   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)

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)

5. Constraints on the solution
   Constraint – a restriction on the degree of
    freedom that we have in providing the
   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)
Techniques to solicit requirements
   The task of the requirements determination
    phase is to determine, analyze and
    negotiate requirements with the
   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

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
   For terminology, perhaps have a glossary which
    contains information such as: Name, Description,
    Ranges, Units, Accuracy, Precision

Traditional techniques
   Traditional methods of requirements
    elicitation include:
    •   Interviews
    •   Questionnaires
    •   Observation
    •   Study of business documents

   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

  • 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

   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
   Existing computing systems already exists
    • Observe users through their interactions and
      frustrations with the system

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)

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

Rapid prototyping
   Use the concept of prototyping to discover
   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

Joint Application Design (JAD)
   Newer Technique, but has been around since
   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

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

Requirements determination
   Requirements analysis includes
    negotiations between developers and
    • This step is necessary to avoid and eliminate
      contradicting and overlapping requirements and
      also to conform to the project budget and
   The product of the requirements
    determination phase is a requirements
    • This is mostly a narrative text document,
      normally in the format of use cases

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

Use Case Diagrams revisited

   Use Case specification includes
    representation of actors, use cases and four
    kinds of relationships:
    •   Association
    •   Include
    •   Extend
    •   Use Case generalization

Association relationship
   The association relationship establishes the
    communication path between an actor and a
    use case

                            pump gas

                            clean the windows

                       check the oil

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

                                                       get paper towel
                      clean the windows

                 check the oil

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
                     pump gas

customer             clean the windows                  get paper towel


                        check the oil

                                            «extend»        add oil

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

  customer            clean the windows                  get paper towel


                        check the oil

                                           «extend»          add oil

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


                      check the oil

                                             «extend»         add oil

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
    – Is there a linking structure for use cases, or do they just
      come in piles?

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
    2. Note that goals sometimes fail

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

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
    • 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

Use case format
   A use case format is really just a stylized
    way of writing, a form of prose having two
    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
    •   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

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.

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.

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

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

Textbook Information
   Section 3.1 – Principles of Requirements
   Section 3.2 – Requirements Elicitation
    • Traditional Techniques: Interviews, Questionnaires,
      Observation, Business Docs
    • Newer Techniques: Prototyping, JAD, RAD
   Section 3.3 – Requirements Negotiation and
    • Scoping, Requirements Dependency Matrix, Risks and
   Section 3.4 – Requirements Management
    • Classification, Identification, Hierarchies, Change
   Section 3.6 – Requirements Document
    • Template (pg. 100), System Constraints, Project Matters,
   Video (approximately 1 Hour Long)
    • Suggest you take notes on the Video
    • Apologize in Advance for the Bad Camera
   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


Shared By:
Description: Rfp Template for Black Car Service document sample