Requirements: Creation Emerson Murphy-Hill

Requirements Elicitation Need to understand why not just what. Techniques Interviews Observation Examining Documents and Artifacts Joint Application Design (JAD) Groupware Questionnaires Prototypes Focus Groups On-Site Customer Existing System

Requirements Validation Critical step in the development process, Usually after requirements engineering or requirements analysis. Also at delivery Requirements validation criteria: Correctness: The requirements represent the client’s view. Completeness: All possible scenarios through the system are described, including exceptional behavior by the user or the system Consistency: There are no requirements that contradict each other Clarity: There are no ambiguities in the requirements. Concision

Requirements Validation Criteria (continued) Feasible: Requirements can be implemented and delivered Traceability: Each system function can be traced to a corresponding set of functional requirements Understandable Non-prescriptive everything about what the customer wants and nothing about how the programmer(s) will do it. Consistent language Shall, should, may “the physician” vs. “the doctor” Testable

Types of Requirements Statements Traditional “The system shall” Use case based (a.k.a. iTrust) User story – married with acceptance test to supply the detail Agile requirements

Traditional Requirements Statements Shall (== is required to): used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted Should (== is recommended that): used to indicate among several possibilities one is recommended as particularly suitable, without mentioning or excluding others or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited May (== is permitted to): used to indicate a course of action permissible within the limits of the standard Can (== is able to): used for statements of possibility and capability, whether material, physical, or causal http://standards.ieee.org/guides/style/section5.html

Example Traditional Requirements From course pack … There shall be two dice in the game. Each dice shall have six faces. The player’s movement shall be based on the dice roll. If the dice roll is two, the player shall move forward two cells; if the dice roll is three, the player shall move forward three cells; etc. If a player is sent to jail by either landing on the Go to Jail cell or drawing a go to jail card, the player shall pay $50 in bail money to get out of jail at their next turn. If a player lands on jail as the result of a dice roll, nothing shall happen.