Ambiguity and Specificity Sriram Mohan/ Steve Chenoweth Chapters 23, 24 - Requirements Text 1

Problem Specification must be easy to understand and must be clear. ◦ Balancing the two might be difficult ◦ Must be easy enough for the client to understand ◦ Must be unambiguous for the developers 2

Light Box Exercise After On pushed but before Off pushed system is termed “power on”. After Off pushed but before On pushed system is termed “power off”. Since most recent On press if count has been pressed an Odd/Even number of times, Odd/Even shall be lit. If either light burns out, the other shall flash every 1 second. 3 Count On Off Even Odd Power

4 Off On Off On Duty Cycle B Duty Cycle A

Techniques for Disambiguation How do we detect it? ◦ Memorization technique ◦ Emphasis technique or Keyword Technique How do we avoid it? ◦ Use natural language if possible ◦ Use pictures and diagrams to illustrate intent ◦ Communicate – When in doubt ask? ◦ Augment with technical specs 5

Technical Methods for Specifying Requirements Finite State Machines 6

Technical Methods for Specifying Requirements Decision Tables and Decision Trees 7

Technical Methods for Specifying Requirements Entity Relationship Diagrams ◦ You will get extra credit for Milestone 3 if you develop an ER diagram. 8

Technical Methods for Specifying Requirements Pseudo code ◦ What is it? ◦ We will use it for our design phase in 371. For each function(s) that results from an use case, you must provide the following information ◦ Name ◦ Arguments ◦ Return Type ◦ Pseudo code You must also develop an architecture diagram. 9

System Architecture Diagram 10 Bloomington Ford Database Ford Main Module Authentication Module DB Connector Module Exception Handler Module Utilities Generator Module Blue Log Module White Log Module Find Module Reports Module Maintenance Module Help Module