Ambiguity and Specificity Sriram Mohan

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.

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

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

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”

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.

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.

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

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.

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.