Program Lecture October 13, 1997
Requirements
-
The Software Problem
-
Software is a formal system; the real world isn't.
-
Where Requirements fit...
-
Requirements happens....
-
The Requirements Document
-
Some Approaches
The Software Problem
-
Most software is late and over-budget, does not meet user needs or expectations,
or is socially irresponsible.
-
The "software engineering" problem is not just a matter of technology,
but a problem of creativity and invention, organization, psychology, artistic
design, group dynamics and culture.
-
In addition considerable knowledge and understanding of the application
area is required to design, implement, market, sell, deploy, support or
maintain a successful system.
-
...and (imho) the hardest part of it, is Requirements.....
-
...but in many ways, it's the most fun!
Software is a Formal System (the real world isn't)
-
where Requirements fit....
-
where Requirements used...throughout!
Requirements happens...
-
Requirements? - anything that drives design...
-
70% of total time (and $$) on requirements, or req. defects.... [ => requirements
used thru-out the process!]
-
The possible approaches -- all model requirements
-
a better understanding thru act of constructing
-
a basis for testing
-
share the understanding
-
make the subject visible
-
#1 enemy -- hidden, false assumptions
-
theory, technique, practis, some help.
Relative Cost to Fix an Error
-
Phase in Which Found
-
Requirements
-
Design
-
Coding
-
Development testing
-
Acceptance testing
-
Operation
The Possible Approaches
-
Get the idea, then build towards the vision.
-
Feature wars.
-
Analysis (DFD, ERM, DDs, OOMs, DTs, use cases, etc.)
-
JAD (participatory design - designers, mgmt, customers, w/ facilitator,
visual aids, scribe)
-
Quality Function Deployment - map customer benefits to design criteria,
and design criteria to features.
-
Soft Systems (Weinberg et al) - heuristics to develop & gain consensus
on customer problems and designer consideratoins.
-
Formal methods - Z, domain specific languages.
SOS Experiences
-
It's obvious, and we all agree. No need to write it down.
-
They don't know what they want, so we'll just develop it.
-
Noone wants to write it down, so we won't.
-
We want to start coding; the difficult part is the technology.
-
We won't know what it is til we start coding.
-
"Requirements" is an ugly word -- limits creativity!
-
They don't have good examples, or good templates....
-
They haven't done it before, so don't know what it is, or how important.
The Requirements Document ...what the system should do, not how it's going
to do it....
-
Introduction ("charter"). narrative -- customer, problem, concept, domain.
-
Functional Requirements - what the system should do. "The system will continuously
display the temperatures of all the machines." (verbs that perform actions).
-
Data Requirements - input or output, and stored in the system.
-
Constraints. "The system must have a 1 sec. response time."
-
Guidelines. (guidance for implementation where >1 strategy.) "Minimize
response times of the system to keyboard requests." vs. "Usage of main
memory should be as small as possible."
Some Constraints
-
Cost
-
Delivery date.
-
Hardware or software to be used
-
Memory or backing store available.
-
Response times
-
Programming language to be used
-
Data volumes (store data on 10,000 students for 4 years)
-
Load levels (100 transactions per min. from POS)
-
Reliability requirements (MTBF of 6 months)
Some Common Deficiencies of the document
-
Vagueness. "The interface will be user friendly."
-
Contradictions. "The data will be stored on mag tape." and "The system
will respond in less than 1 sec."
-
Omissions or Incompleteness. how to deal with input errors.
-
Guidelines or Constraints confused w/ Functional Req'ts. describe the solution,
not the problem.
-
Unclear, or badly written.
-
Insufficient user involvement, market research.
-
Not testable
-
Not traceable back to customer's needs
Use Case - Recycling Machine System
Quality Function Deployment
-
Benefit -- What would benefit the customer? "You'll like this product because
it...." (note also what would dissatisfy the customer...."hard to install")..
Contextual Inquiry. avoid yes/no questions, process checks, affinity analysis.
rate the benefits, relationship matrix to requirements.
-
Requirement (design criteria)
-
testable, states the problem
-
Feature -- describes a specific product, concrete, solution.
-
menus, buttons...
-
Performance is not value.
Soft Systems -- Weinberg's Heuristics
- Methodologies aren't enough...it's the process that's helpful
- Attack ambiguity -- take away the doc, and ask each participant
to write down the requirements.
- Give your customers what they want, not what they need.
- Use decision trees carefully....depend on order of questions, etc.
|
