1. Ambiguity and Specificity
Sriram Mohan

2. 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
When specifying requirements, you need to hit the sweet spot. It is the balance point between the greatest amount of understandability and the least amount of ambiguity. You have to make sure that it is detailed enough to be well understood by the developers, but at the same time, you must avoid getting into decisions that are clearly design decisions. The question then we have to answer is “how much should I state in order to avoid any chances of being misunderstood.
Unfortunately, there is no clear answer to this question. It really depends on the situation and the project at hand.

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
This seems fairly straight forward, but lest us looks it from the perspective of a developer, what does it mean to flash the bulb every one second

4. On Off Duty Cycle A On Off Duty Cycle B 1 2 3 4 5 6
What level of specificity should be provided? It depends on the context of your application and on how well the developers can make the right decisions or at least ask questions where there is ambiguity. In case of the counting device, the way we have it specified is enough, but if it was a pacemaker, which had to provide a surge to the heart, then we have to be more specific. In that case, a timing diagram like the one above which exactly specifies must be included.
Duty Cycle B 1 2 3 4 5 6

5. Techniques for Disambiguation
How do we detect it?
Memorization technique
Emphasis 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
End users, client and other stakeholders prefer that natural language is used, but keep in mind that people in different cultures and different countries might have a different interpretation of each word. For instance the simple word “check”

6. Technical Methods for Specifying Requirements
Finite State Machines
Technical method for specifying requirements are appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood.
Finite state machines: Think of your system as a hypothetical machine which can be in only in a discrete set of states. In response to an user input or an interaction with an input device, the machine changes its state and then generates an output or an action. The output and the action depends on the current state of the system and the event that caused the transaction.
An even more precise form of representing FSM is to use a finite state transition matrix. Which shows every possible state of the device, and the effect of all possible events on every state.

7. Technical Methods for Specifying Requirements
Decision Tables and Decision Trees
Technical method for specifying requirements are appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood.
Decision Trees and flow charts can also be used.

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

9. 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
You must also develop an architecture diagram.

10. System Architecture Diagram
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
List the functions by the module and map the use case to the module/functions. You can develop a package/class diagram if you prefer.