Some definitions

1. Some definitions • Functional Requirement:A system/software requirement that specifies a function that a system/software system or system/software component must be capable of performing. These are software requirements that define behavior of the system, that is, the fundamental process or transformation that software and hardware components of the system perform on inputs to produce outputs. • Non-Functional Requirement:In software system engineering, a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Non-functional requirements are difficult to test; therefore, they are usually evaluated subjectively.

2. Causes of Downtime Structural Design Problems are No. 1 36% 34% 25% 5% <1% Design Operations Physical Configurations Environmental • NaturalCatastrophe • Power/ACLoss • ScheduledDowntime • Application Failure • HW/SWIntegration • Network Failure • HumanIntervention • DBA Error • Faulty Practices • Hard DiskFailure • DiskControllerCrash • Power Surge • CPU Failure Source: IEEE/Oracle Research

3. Bottom line impact of downtime "CNN Moment" Financial Broker $6.5M Credit Card Sales $2.6M Pay-Per-View Television $150K Airline Reservations $90K Banking ATM - $14K Average Cost per Hour of Downtime* * Based on IDC Data

4. Bottom line: The “ilities” have become strategic • Architecture determines success, not products or platforms • “Ilities” are Service Level Requirements (SLRs) • e.g., securability, scalability, flexibility, reliability • In the past “ilities” like availability, were afterthoughts in most systems development • “Ilities” have become strategic requirements • “Ilities” must be primary considerations throughout the design and development process

5. Example: Credit Card System • Your client wants the system to be fast and accurate. • What is meant by ‘fast and accurate”? • How fast is fast? • When should it be fast? • When there is a light load • When there is heavy usage • All the time? • Goals clarify what is meant by the terms fast etc: “The system is fast and accurate day and night, during peak shopping periods, during crime waves, etc…) • A goal evaluates to true IF it is satisficed

6. The NFR Framework • Uses NFRs such as security, accuracy, performance, and cost to drive the overall design process. • Puts NFRs foremost in the developer’s mind. Major steps • Acquire general knowledge about • The domain & system being developed • Functional requirements for the system • Particular kinds of NFRs and associated development techniques • Identify particular NFRs for the domain • Decompose NFRs

7. Major steps (continued…) • Identify operationalizations (possible design alternatives for meeting NFRs in the target system.) • Deal with • Ambiguities • Tradeoffs and priorities • Interdependencies among NFRs and operationalizations • Select operationalizations • Support decisions with design rationales • Evaluate the impact of decisions

8. High-Level NFR Catalogue NFR Types Performance Cost User-friendliness Security Time Space Confidentiality Availability Integrity Resp-onseTime ProcessManage-ment Time MainMemory Secondary Storage Accuracy Complete-ness Throughput

9. Fit Criterion • “Fit” means that a solution completely satisfies a requirement. • To measure “Fit” we must attach a quantification to the requirement. • Fit criterion enables the fulfillment of the requirement to be tested. • The fit criterion also establishes a goal for the developers to strive for. • Example “I want the product to look nice” • What does “nice” mean? • How can “nice” be measured?

10. Finding Scale of Measure • Description:The product shall accept only British currency • Rationale:To prevent fraudulent use, and protect revenue • Fit Criterion:Actual valid sterling currency received by the product shall be equal to value of revenue recorded. • Consider applying a business toleranceActual valid sterling currency received by the product shall be at least 99% of the value of revenue recorded.(ie the customer may be unwilling to invest sufficient money in the system to differentiate between ALL world currencies.) Problems???

11. Functional Fit Criteria • A functional requirement describes system functionality. • Fit criteria needs NO scale of measure. • It simply ensures that the function has been successfully carried out. • Description:The product shall record the weather station readings. • Fit Criterion:The recorded weather station readings shall match the readings sent by the weather station.

12. Non Functional Fit Criteria • Some NFRs may at first seem hard to quantify. • If you CANNOT quantify the requirement then you should reconsider its value. • DescriptionThe product shall be user friendly • Fit Criterion:New users shall be able to add, change and delete roads within 30 minutes of their first attempt at using the product.

13. Product Failure? • We can also find fit criterion by asking the customer what they would consider a failure in meeting the requirement. • DescriptionThe product must produce the road de-icing schedule in an acceptable time. • The client considers a wait of > 15 seconds unacceptable. Therefore:The road de-icing schedule shall be available to the engineer within 15 seconds for 90% of the times that it is produced. The remaining times it will be available within 20 seconds.

14. Usability • The product shall be intuitive and self-explanatory. • What is meant by intuitive? • A road engineer shall be able to produce a correct de-icing forecast within ten minutes of encountering the product for the first time. • Nine out of ten road engineers shall be able to successfully complete [list of selected items] after one day’s training. • What would you do to the following “requirements”? • Teachers shall be able to easily enter grades into the grade management system. • The pilot shall be able to intuitively interpret the warning signals.

15. User’s Bill of Rights (Karat 1998) • The user is always right. If there is a problem with the use of the system, the system is the problem, not the user. • The user has the right to easily install and uninstall software and hardware systems without negative consequences. • The user has a right to a system that performs exactly as promised. • The user has a right to easy-to-use instructions (user guides, online or contextual help, error messages) for understanding and utilizing a system to achieve desired goals and recover efficiently and gracefully from problem situations.

16. User’s Bill of Rights (Karat 1998) • The user has a right to be in control of the system and to be able to get the system to respond to a request for attention. • The user has the right to a system that provides clear, understandable, and accurate information regarding the task it is performing and the progress toward completion. • The user has a right to be clearly informed about all system requirements for successfully using software or hardware. • The user has a right to know the limits of the system’s capabilities.

17. User’s Bill of Rights (Karat 1998) • The user has a right to communicate with the technology provider and receive a thoughtful and helpful response when raising concerns. • The user should be the master of software and hardware technology, not vice versa. Products should be natural and intuitive to use.

18. Performance Requirements • Performance requirements describe characteristics such as response time, throughput, & space considerations. • Example:The response shall be fast enough to avoid interrupting the user’s flow of thoughts. Fit criterion:The response time shall be no more than 1.5 seconds for 95% of responses, and no more than 4 seconds for the remainder.