1. CSE403 Software Engineering Autumn 2000 Requirements
CSE 403 Autumn 2000
CSE403 Software Engineering Autumn 2000 Requirements
Gary Kimura
Lecture #4
October 2, 2000
October 2, 2000

2. Today Two words that bear repeating “Risks” and “Constraints”
Finish the remainder of Wednesday’s talk
A quick word about runtime stack sizes
NT daily build and dog food clarification
NT albatross
Specifying requirements
What makes up a requirement
What is not in a requirement
Ways of specifying requirements
One person’s requirement is usually someone else’s design

3. Some angles on requirements
What vs. How
System requirements vs. Software requirements
Functional vs. non-functional
Requirements change
Keep it realistic
Expect unintended side affects (i.e., customers will use the system in ways you can never imagine)

4. Examples of … Successful projects that met their requirements
Caller ID, Call forwarding, etc.
TCAS
Past failures or future failures (?)
Therac-25 (An Investigation of the Therac-25 Accidents, by Nancy Leveson and Clark S. Turner, 1993)
Computerized radiation therapy machine
Did not follow proper software engineering practices
Internet security
Tower of Babel

5. What should be in a requirement
Desired effects of the system
Know your intended customers and speak their language
Likewise know the implementers and speak their language
Justify your requirements so that the next person understands your reasoning
Expect the requirements (goals) to change, due to customer changes, market place changes, technological changes
Expect the team to change during the product cycle. One of the hardest tasks is to replace people in the middle of a project

6. What should be left out
Practically anything the customer doesn’t need to know to use the system
Implementation details
Over vs. under specified requirements
The Ten Commandments contain 297 words. The Bill of Rights is 463 words. Lincoln’s Gettysburg Address is a mere 266 words. A recent federal directive to regulate the price of cabbage is 26,911 words.

7. How to specify requirements
Natural Language to
Structured Natural Language to
Formal notation
It is an iterative process, a good requirements writer bridges the gap between customer and implementer
Any method for dictating requirements is only as good as the people are willing to use it

8. Who writes the requirements and has major input
Program Managers
Customers
Software Design Engineers
Software Test Engineers
Performance Engineers
Realistic
KISS

9. NT Lessons NT early days vs. later Natural Language
Iterative with many redirections
Various layers OS UI
Compatible and natural progression
Current and proven technology, not bleeding edge technology
Cairo and OFS
Sanity check

10. Class Project Need a plan with milestones Model Requirements Design
Don’t dwell on the exact model
Division of labor is important
Making sure you have a roadmap is important
Requirements
Important to get this written down
Keep this realistic
Expect them to change (not the actual API but definitely the environment and demand on the system will change)
Design
This is where parallel development really starts
Communication is still key

11. More on the class project
Coding and component testing
Integration and system testing
Performance tuning
Deployment and maintenance (if this were a project that has real customers outside of this class and more than one version)

12. Next time Wednesday Friday (Project day) Prototyping
Need to turn in your project requirements
Then next Friday need project plans for each sub-group.
More definition of what each sub-group needs to be doing