CSE403 Software Engineering Autumn 2000 Requirements

1. CSE403 Software Engineering Autumn 2000Requirements Gary Kimura Lecture #4 October 8, 2001

2. Today • Two words that bear repeating “Risks” and “Constraints” • 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 Documentation Guidelines • What you need in your requirements document • Identify the all the users and what they can expect from the product • Usage scenarios • Hardware and software requirements • It feels about 10 to 20 pages with diagrams

11. More on the Class Project • Need a plan with milestones • Model • 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)

12. Yet More on the Class Project • Design • This is where parallel development really starts • Communication is still key • Coding and component testing • Integration and system testing • Deployment and maintenance (if this were a project that has real customers outside of this class and more than one version)

13. Next time • Wednesday • Prototyping • Friday • Design