Customer requirements (Braude, Holub, Pressman)
•	"13 arguments" and "Startup.com“
•	Customer requirements vs. developer requirements
•	How to write down customer requirements
•	Use cases
•	Improving inspection of Software Requirements Specification

"13 arguments"
•	You cannot assume you understand the customers' needs
•	Every software package needs users at some point -- must find them and figure out what they need
•	Related to software testing maxim:
–	If you can’t test it, it’s not a valid requirement
•	Holub: implement only what the users actually need
"Startup.com"
•	documentary about the rise and fall of govworks.com
•	rise: peaked at ~300 employees
–	got $50M from venture capitalists
–	CEO got to consult with Pres. Clinton
•	fall: ran out of money, founders got nothing, taken over
–	http://www.publicdatasystems.com/gw/

Why govworks failed
•	Did everything as fast as possible 
–	requirements defined on the fly
•	division of labor poorly defined
–	no testing plan

Customer requirements vs. developer requirements
•	All requirements must be unambiguous
–	must be written down
•	All requirements must be kept current
•	Customer requirements
–	must be clear to customer
–	lists customer's wants and needs
•	Developer requirements
–	more structured, detailed
–	includes things the developer must follow but will not directly affect the customer
A mini-process for requirements, part 1 (based on fig 3.5 of Braude)
•	Identify who is the customer(s)
–	Interview customer representative(s)
•	Write customer requirements
–	use a standard form
•	Inspect requirements
•	review with customer reps
•	After customers are satisfied, create developer requirements
Identifying customer
•	May be more than one group of customers
–	ex: person buying the software vs. person actually using the software
•	Some customer groups vary widely
–	ex: people using e-mail
•	(Holub) If you can’t find real users, pick people from Marketing to imitate them, not Sales
–	Marketing researches what people need most
–	Sales deals with individual customers
Examples
•	What would the customer groups be for:
–	a home security system?
–	an account management system?
–	a computer game?
Example (Pressman)
Our research indicates that the market for home security systems is growing at a rate of 40 percent per year. We would like to enter this market by building a microprocessor- based home security system that would protect against and/or recognize a variety of undesirable "situations" such as illegal entry, fire, flooding, and others. The product, tentatively called SafeHome, will use appropriate sensors to detect each situation, can be programmed by the homeowner, and will automatically telephone a monitoring agency when a situation is detected.
Questions for example
•	who do you need to talk to?
•	what are some missing specifications?

Writing customer requirements
•	Need to ask questions to get details of wants and needs
•	use cases -- describe single interactions with program
Use cases
•	A use case is a single task, performed by the end user of a system, that has some useful outcome  (Holub)
–	Ex: logging in is not a complete use case
–	Ex: making a deposit at an ATM is
•	for the most popular sequences
–	ex: for word processor, opening a file, printing a file are popular; inserting a footnote less so
•	want use cases that are not too similar
–	ex: opening and saving a file -- one is enough
Use case example (from Braude, Fig. 3.11)
•	Initialize: (Player in a role-playing game)
–	System displays character in dressing room
–	System displays window to set character ratings
–	Player sets ratings
–	Player chooses door
–	System moves character into the room through the door
Use-case: sec. system activation
(from Pressman)
•	Homeowner checks panel to see if system is ready. "Not ready" indicates that windows or doors are open and must be closed.
•	Homeowner uses keypad to enter 4-digit password. The system stores the password and checks if the numbers match. If so, the panel is ready for the next step. If not, it beeps once and resets.
Security alarm system use case (cont’d)
•	The homeowner selects and keys in "Stay" or "Away" (Pressman, Fig. 11-2). "Stay" activates only perimeter sensors (inside motion detecting sensors are deactivated). "Away" activates all sensors. 
•	When activation occurs, a red alarm light can be observed by the homeowner.
Improving requirements specification
•	Divide process into steps
–	preparation, customer interviews, write-up, review (inspection)
•	count defects per page, time per step
•	compare with data from previous projects

Improving requirements specification
•	self-assessment of each step
–	For poorly done steps
–	Spend more time
•	Be more detailed
–	Change how step is performed 
–	ex: what if SRS has two different uses of the same term? (ex: blank) How would you address this?
List of questions to consider
•	Is there another way of interpreting the requirement?
•	How is the requirement related to the goals of the project?
•	Is this requirement consistent with the other requirements?
•	Is the requirement feasible?
–	Ex: performance guarantee must factor in how users connect, maximum # users, etc.
Attitude
•	same as with debugging programs
•	goal is to find bugs, not to defend document
•	one reason why a second opinion is important
•	read carefully
•	should not think inspection is a waste of time
Testing
•	Spell-check, grammar-check
•	check against established set of rules
•	can prepare quiz for inspector(s)
–	ask questions that test comprehension of requirements
•	write prototype based on requirements
•	generate random scenarios
Scenarios
•	Walking through what might happen to user
•	Useful for finding errors to handle
•	ex: registering for a course that is full
–	print an error message?
–	should address this with customer (want waiting list? what if the course is needed for graduation?)
Re: SRS for project
•	Written use cases are fine
•	Goal: everyone in the group understands exactly what the software will and will not do
•	Goal: anyone reading your SRS will understand exactly what the software will and will not do
•	[Note: implementation will probably not be complete]