Introduction to Requirements

Purpose of Analysis phase

Why analysis is important - The Rope Swing Parable

Mnemonic:

Requirements are WHAT the software must do (externally observable behavior)
Design is HOW the solution will work (underlying mechanism)

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.
Tip: Beware the customer who thinks they know what the solution is. (Humorous example)

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.

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 it 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
Distribute d Hangman
Encounter Game
Loan Arranger (Pfleeger textbook)
Real world example - Veterans Administration

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