5 requirements

Requirements are NOT about how (implementation)
[Yes, I know that sometimes customers insist on a particular way to implement;
but the danger of that is, you might miss a better way to implement]
In any event, testing is not about the implementation, but about the functionality

(white box testing requires knowledge of implementation)

must know what the user wants, in order to validate
stake holders might see differently
hospital: only ask doctors? Nurses? Insurance? Patients? administration?
(stated requirements versus user stories versus structured english)
Go for more precision and less ambiguity

Airplanes and spaceships need better statements than social media and computer games
(Lawyers LIVE off of requirements; i.e. legal code)
(Structured English can help)

TESTABLE clear (verifiable) explanation of what changes as the system runs
Complete 
Consistent 
Unambiguous 
Quantitative 
Feasible to test 

(Aim for quantitative rather than qualitative)
Some measurable objectives are impractical to test in real life

functional versus nonfunctional
(what it does versus how it does it; any requirement that is not what it does is non-functional)
	functional –what the system does
	non-functional—other qualities
		speed
		cost
		quality
		documentation
		security
design a system
	organize by sections; 
	split requirements as well
	give meaningful names (not numbers)