Robertson

1
Robertson RobertsonChapter 2 Software
SpecificationLecture 10

• Prepared by
• Stephen M. Thebaut, Ph.D.
• University of Florida

2
Volere Tour

• Visit www.volere.co.uk for a current overview of
  the Volere method
• Resources available include
• document templates
• lists of books, articles, etc.
• various freeware downloads
• lists of services

3
The Volere Requirements Process

• A generic but detailed requirements gathering and
  specification process.
• Core set of activities based on an iterative
  process of Trawling, Writing, and Quality Gateway
  activities.

Software Specification RR Chapter 2
4
Project Blastoff

• Get the astronauts on-board!
• A meeting to prepare for the project and ensure
  its feasibility.
• Principal stakeholders client, main users, lead
  developers, technical AND business experts, other
  key people.

Software Specification RR Chapter 2
5
Blastoff Objectives

• Ensure that the project has a worthwhile (and
  clearly understood) purpose
• Is feasible and
• Has commitment from the stakeholders.

Software Specification RR Chapter 2
6
Blastoff Tools/Activities

• Brainstorm to identify all the stakeholders.
• Develop Context Model to help determine the scope
  of work to be studied (the product will do part
  of this work).
• Produce a statement of purpose.
• Develop a preliminary cost estimate and
  assessment of risks.
• Arrive at a consensus based Go/No-Go decision.

Software Specification RR Chapter 2
7
Trawling For Knowledge

• Work that needs to be studied (from context
  model) is divided into business events and
  assigned to analysts.
• Favored techniques are apprenticing and use-case
  workshops.
• Focus is on working with users as they describe
  work they do now and work they hope to do.
• As context knowledge grows, focus of trawling
  shifts towards gathering requirements for the
  product.

Software Specification RR Chapter 2
8
What are business events?

• We use the term business event (sometimes just
  event) to mean a business related happening
  within a system adjacent to the work that we are
  studying. The happening causes the work to
  produce an event-response.

9
Other Trawling Techniques

• Interviews with non-user stakeholders.
• Brainstorming sessions to generate ideas for
  particular aspects of the product.
• Surveys of (other) potential users.
• Scenarios of work activities are developed to
  understand context and product roles.
• Prototyping

Software Specification RR Chapter 2
10
Scenarios

• User-led stories constructed to show steps needed
  to complete some piece of work in the current
  environment.
• Facilitates context understanding.
• Stories showing role of product in completing
  some piece of work in the envisioned environment.
• Facilitates product requirements understanding.

Software Specification RR Chapter 2
11
Prototyping

• Used when trawling gets stuck or risks are high.
• Also when something more concrete than written
  requirements is needed (e.g., when dealing with
  GUI issues).
• Provides a simulation of (part of) the product.
• May be high-fidelity (automated, close to
  reality) or low-fidelity (e.g., pencil and paper,
  quick and dirty).

Software Specification RR Chapter 2
12
Writing the Potential Requirements Down

• Written for the client, using the clients
  language, in a consistent format.
• A fit criterion is also provided to quantify
  the requirement for designers and to ensure
  testability.
• Tools Requirements Specification Template (ala
  IEEE Guideline) and Shells (template for
  individual requirements)

Software Specification RR Chapter 2
13
Requirements Specification Template Table of
Contents

• Purpose of Product
• Client, Customer, and other Stakeholders
• Users of the Product
• Constraints
• Naming Conventions Definitions
• Relevant Facts
• Assumptions
• Scope of Product

• Functional and Data Requirements
• Look Feel Reqmts
• Usability Reqmts
• Performance Reqmts
• Operational Reqmts
• Maintainability Portability Reqmts
• Security Reqmts
• Legal Reqmts

Software Specification RR Chapter 2
14
Requirements Specification Template Table of
Contents (contd)

• Cultural and Political Reqmts
• Open Issues
• Off-the-Shelf Solutions
• Installation Problems
• Tasks

• Cutover (transition)
• Risks
• Costs
• User Documentation
• Waiting Room (reqmts for future releases)

Software Specification RR Chapter 2
15
Shells
Event/Use Case
Requirement Type
Requirement
Description
Rationale
Source
Fit Criterion
Customer Dissatisfaction
Customer Satisfaction
Conflicts
Dependencies
Supporting Materials

• History

Software Specification RR Chapter 2
16
Requirement Shell
17
Quality Gateway (Initial Review Process)

• Every requirement must pass through to become
  part of the specification.
• An analyst and senior user serve as gate keepers.
• Every requirement is checked for completeness,
  relevance, coherency, traceability, etc.
• Prevents requirements leakage. (What is that?)

Software Specification RR Chapter 2
18
Other Important Ideas

• Reusing requirements from similar products.
• Specification Stock-take a final review for
  consistency and completeness, and an opportunity
  to reassess costs and risks.
• Tailoring the process every project needs a
  different process
• Post Mortems

Software Specification RR Chapter 2
19
Post Mortems

• Series of interviews with stakeholders,
  developers, and all others involved in the
  requirements process.
• Questions
• What did we do right?
• What did we do wrong?
• How would we do it differently?

Software Specification RR Chapter 2
20
Post Mortems (contd)

• The most notable feature of post mortems is
  that the companies thatmake (them) part of their
  process consistently report startling improvement
  in their RE process. (They) are probably the
  cheapest investment you can make in your own
  process.

Software Specification RR Chapter 2
21
Robertson RobertsonChapter 2 Software
SpecificationLecture 10

• Prepared by
• Stephen M. Thebaut, Ph.D.
• University of Florida