1 Issues in Documenting Requirements Requirements are often poorly documented and become a source of risk Too vague, not specific enough, subject to too much interpretation or has critical information missing Example: “The system will be user friendly.” Vague! Too general! What exactly might have user friendliness issues? Too specific, overly constraining, irrelevant or misleading or confusing information Example: “The system will have a 5 second response time.” Do all parts of the system have to have a this response time?, Is it exactly 5 seconds, or 5 seconds or less? Why 5 seconds? Two important questions to ask when reading a requirement: 1.“Does this requirement provide enough information to be implemented? 2.“If this requirement were implemented, how would we know it was actually satisfied?

2 A Necessary Condition for Documenting Requirements All requirements must be testable and implementable (subject to risk considerations of course…) Testable: There must be some way to demonstrate that a requirement has been satisfied by the system (should be documented) Implementable: There must be enough information specified so it can be implemented

3 It is important to know what kind of requirement you have as they differ in how to meet the necessary condition Kind of requirement Documentation of satisfaction Capability Requirement supports or does not support a typical or non-trivial usage scenario (Use-Case) Projectmust have a measure, what is being measured, definition of what is satisfactory Level of Servicemust have a measure, specific instances with respect to capabilities, satisfaction threshold (relative measures are useful) System Interfacemust specify checklist or specification for all interface parameters Evolutionarymust refer to a design or implementation scenario that supports possible future satisfaction

4 Documenting System Capabilities Kind of Requirement: Capability Requirement Documentation: Must describe how the capability is used in a typical or non-trivial usage scenario (Use-Case) Example (from HICSS Registration System): SC-RQ1: Registrant will be able to make payments by credit card online. Usage scenario: Registrant selects “pay by credit card online” in registration form and is directed to a secure online payment site (e.g. Paypal) to enter their credit card information. After completing the transaction, the registrant is taken back to the registration site and provided a confirmation receipt containing the transaction ID and their registration number.

5 Documenting Project Requirements Kind of Requirement: Project Requirement Documentation: Must describe a measure, what is being measured, and definition of what is satisfactory Example (from HICSS Registration System): PR-RQ1: Development costs shall not exceed $1,500 Development costs include all payments to developers, set-up fees, licenses and does not include equipment or supplies.

6 Documenting Level of Service Kind of Requirement: Level of Service Documentation: Must describe how the level of service is measured, what specific system capabilities need the level of service, and what constitutes an acceptable service level relative to the measure (relative measures are very useful here – e.g. will perform 10x faster than the current system) Example (from HICSS Registration System): LOS-RQ1: Online registration process will not demand more than 15% more time to complete a registration for typical HICSS attendees than the existing download and fax registration process.

7 Documenting System Interface Requirements Kind of Requirement: System Interface Documentation: Must provide a specification for all relevant interfaces and/or a checklist of interface parameters Example (from HICSS Registration System): SI-RQ1: The online registration form should have a look and feel similar to the downloadable registration form.

8 Documenting Evolutionary Requirements Kind of Requirement: Evolutionary Documentation: Must describe a design or implementation scenario that shows how the to-be system can support the satisfaction of the requirement in the future and possible issues if implemented. Example (from HICSS Registration System): EV-RQ1: The system will allow the registrant to retrieve and edit their registration information. Future implementation scenario: Registrant can enter some previously saved information (e.g. name, phone, etc.) into the blank registration form and select “find and edit existing registration” rather than “submit registration” (the current only option). The registration data will be searched for a unique match with the entered data. If found, the data from this record will be used to fill out the empty registration form fields and the registrant can make edits. When the user submits the edited form, the previous record is replaced with the new data from this form (registration number and other system defined values will not change). Can user change payment type? What is paid online by CC?

9 Get into teams of size two. Based on a “correct” requirement type determination: For one of the requirements R2,R3,R4, R5, indicate how it satisfies or does not satisfy the “ Necessary Condition for Documenting Requirements ” as specified in the previous slides e.g. “Be accessible by Web users” is a system interface and does not satisfy the necessary condition subject to risk considerations. Checklist or specification: “The application’s front page is viewable via Internet Explorer V6 or greater” Risk considerations: The particular web server and web browsers the system is required to use are not specified. Even though “Web accessibility” is generally understood in current practice and it would be risky to build the system without first having an idea of what kinds of browsers users are likely going to be using to access this system. For example, can we assume Java is installed? If so, what version? How about scurrility? Will the browsers support 128 bit SSL? *Note that while this requirement is likely “testable” to some degree, the lack of specifications make it difficult or very risky to implement. Exercise: Requirement Documenting