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

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

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)

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

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

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.

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

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

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

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

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)

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