Introduction to Requirements
Purpose of Analysis phase
The steps in the Analysis process
The Results of Analysis - The SRS (Software Requirements
Specification)
describes the intended solution to solve the customer's problem.
(Selected
from the universe of all possible solutions).
Example: Customer Need - keep track of time passing. Possible
solutions
include sundial, hourglass, focault pendulum, contemporary analog
circular
clock face and hands. Note the clock implementation (e.g. springs,
batteries,
solar, atomic) is NOT part of the specification.
Mnemonic:
- Requirements are WHAT the software must do (externally
observable
behavior)
- Design is HOW the solution will work (underlying
mechanism)
Why the SRS is important - The
Rope Swing Parable
Dangers of inadequate analysis
SRS serves multiple audiences:
- Describing intended solution to customer.
- Serves as the basis for design by developers.
- QA will use it as standard for verifying the final
product.
- Project Managers will use it to refine the project plan
-
cost and
schedule estimates.
- Testing team uses it to develop test cases.
- Publications department uses it to write documentation.
- Advertising and promotional efforts by marketing will be
based
on
it.
- Serves as a legal contract.
The Requirements Document must address four Domains (Mnemonic:
N-FBI).
- Functional
What the software must DO, the features if offers or functions to be
performed. - Informational
The data to be manipulated - Behavioral
The way the software behaves, its external operating characteristics,
including any user interface. - Nonfunctional
Quality
Attributes (e.g., performance, usability, etc.)
Students accustomed to poor requirements received in class assignments.
Payroll
example of vague requirements
Can you find the four domains in this specification
for Jotto?
Format
of SRS document - IEEE Standard Format
Criteria
for good requirements
Examples:
Audio
Tape Calculator
Distributed
Hangman
Encounter
Game
Loan Arranger (Pfleeger textbook)
Real world example - Veterans
Administration
How to gather
requirements (i.e. requirements elicitation)?
Tip: The customer usually doesn't know what the solution is. The
customer
only knows there's a problem.
How to express requirements? Inherent tension between writing for
Customer
and writing for Developers. Easy to read versus unambiguous, precise,
well-defined.
Ambiguity of Natural Language Examples:
- "Would you rather have a lion
chase you or a bear?"
- "To purchase a Christmas Tree, tear off the tag and take it to
the register."
Notations (static and dynamic descriptions)
- plain english "atomic" sentences
- structured english (e.g. Employee Scheduler)
- Decision Table
- Use Cases [examples]
- User Manual
- Data Flow Diagram
- State Transition Diagrams
- Data Dictionary
- Entity Relationship Diagrams
- CRC cards
Example
requirements to critique
Verifying requirements - Walkthroughs and Formal Reviews
Copyright 2002 by John Dalbey