Ambiguity and Specificity Steve Chenoweth & Chandan Rupakheti Chapters 23, 24 - Requirements Text Questions 1, 2 Image from

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 Question 3

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. Count On Off Even Odd Power

Off On Off On Duty Cycle B Duty Cycle A

Example No 2 For up to 12 aircraft, the small display format shall be used. Otherwise the large display format must be used.. Which format is this, anyway?

Example No 3 Shut off the pumps if the water level remains above 100 meters for more than 4 seconds. Uh oh…

Example No 4 Create a means for protecting a small group of human beings from the hostile elements of their environment. Your basic hostile element – Empire battle cruiser. From

Example No 5 The product shall show all roads near the destination. Good enough?

Example No 6 The product shall show the weather for the next 24 hours. Required or not?

Example No 7 When the users presses the L and the R button simultaneously, the alarm is turned off. Ok, which ones are L and R? And, do the burglars know this?

Example No 8 The doors of the elevator never open at a floor unless it is stationary.

Some problematic statements Incomplete lists ending with "etc.," "and/or," and "TBD.” Vague words and phrases such as "generally," "normally. Passive voice, such as "the counter is set." (By whom or what?). Words and phrases whose meaning can be disputed between developer and customer, such as ◦ instantaneous, simultaneous, ◦ To the extent practicable, ◦ Where applicable

Which one do you prefer? Or, 1. The system displays the Basic Loss Information Page, with a form to enter basic loss information specific to the claim line. 2. The clerk fills out the form then clicks the "Add" button 3. The system queries the claims database to confirm that there are no existing, possibly competing claims. 4. The system then assigns an ID to the claim and displays the confirmation page. 5. The clerk clicks the "Confirm" button, and the system saves the claim, then triggers acknowledgement to be sent to the agent. 1. The clerk enters basic loss information specific to the claim line. 2. The system confirms that there are no existing, possibly competing claims and assigns a claim number 3. The clerk confirms they are finished; the system saves and triggers acknowledgement to be sent to the agent.

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 Questions 4,5

Technical Methods for Specifying Requirements Finite State Machines Start Question 6

Technical Methods for Specifying Requirements Decision Tables and Decision Trees

Technical Methods for Specifying Requirements Entity Relationship Diagrams ◦ In Milestone 3 the platform team will develop an ER diagram.

Technical Methods for Specifying Requirements Pseudo code ◦ What is it? For each function’s that results from an use case, you must provide the following information ◦ Name ◦ Arguments ◦ Return Type ◦ Pseudo code Develop an architecture diagram. Finish Question 6

374 Transition The strategic thing is for all of you to be in the same section of CSSE374, to avoid having to switch to a different project! We will devise some system to make this possible! Your ideas are welcomed…