How Fast is “ Fast ”? Demystifying NFRs

1. How Fast is “Fast”? Demystifying NFRs Terry Wiegmann, CBAP, CSQE, PSPO, ATM-G Director, People Service Line Lead Quick Solutions, Inc. @twieg

2. Heard these? Fast Easy to Use Available when I need it to be Accurate Accommodate a large number of users

3. 4 Ws and an H What are they Why do we care Who has them Where can we find them How to organize them

4. What are they?

5. Functionality

6. Oxymorons, Ilities, QoS

7. What are they? • Functional requirements define what a system is supposed to do; NFRs define how a system is supposed to be. Non-functional requirements specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

8. BABOK V2, Chapter 9, Techniques Purpose Is to describe the required qualities of a system, such as its usability and performance characteristics. These supplement the documentation of functional requirements, which describe the behavior of the system.

9. ISO/IEEE Definition A software requirement that describes not what the software will do but how the software will do it (ISO/IEC/IEEE 24765:2010 Systems and software engineering--Vocabulary)

10. Karl Wiegers A description of a property or characteristic that a software system must exhibit or a constraint it must respect, other than an observable system behavior

11. Rachel Davies/Execution Qualities • Observable at run time: Security, usability • Evolution qualities • Testability, maintainability, extensibility, scalability, embodied in the status and structure of the system

12. Domain Requirements Problems Implicitness Domain specialists understand the area so well that they do not think of making the domain requirements explicit Understandability • Requirements are expressed in the language of the application domain; not understood by developers

13. Why do we care?

14. Square Pegs, Round Holes Have more impact on design than stories Cross-cutting scope, apply universally or to more than one strand of functionality Elicitation forces consideration of design and architecture

15. Loss of Customers

16. Bad Press

20. Loss of Investment, Life

21. Who has them?

22. Stakeholders NFRs: qualities of a system that are important to: • User community • usability, learnability, reliability, etc. • Development community • scalability, maintainability, reusability, etc.

23. ERD for NFRs • Known Bugs • Workarounds Enhancement Requests Customer Support Operations Security • Support the system in Prod • OS updates • Maintenance Windows New System • Hostile users • Competitors’ Beta testers • DR/BC Finance Legal • FAS 86 • SOP 98 • SLAs • ROI/BC? Trainers Contractual Attributions Escrow Sales, Marketing • Set up Trainees’ User IDs • Refresh data • Separate enviroment • Ability to create demos • Press Releases • Trade Shows

24. Often Overlooked Stakeholders • Operations • Support the system once in Production • Support/Help Desk • Known Bugs, Workarounds, Enhancement Requests • Security • Hostile users, Competitors’ Beta testers • Trainers • Set up users, Refresh data, separate enviroment • Legal & Finance • Contractual attributions, Escrow, SLA, FAS86, SOP98

25. Capacity Max users Max concurrent users Max transactions Data Set sizes

26. Reliability • Degree to which the system performs as required • System defect rate shall be less than 1 failure per 1000 hours of operation.

27. Security • Ability to resist unauthorized attempts at usage • Continue providing service to legitimate users

28. Performance

29. Performance Examples • System shall be able to process 100 payment transactions/second in peak load. • In standard workload, the CPU usage shall be less than 50%, leaving 50% for background jobs. • Production of a simple report shall take less than 20 seconds for 95% of the cases. • Scrolling one page up or down in a 200 page document shall take at most 1 second.

30. Availability • System shall meet or exceed 99.99% uptime. • System shall not be unavailable more than 1 hour/1000 hours of operation.

31. Testability • Ability to detect, isolate, and fix defects • Time to set up test env & run tests • Test coverage (requirements coverage, code coverage…)

32. SLAs

33. Usability Learnability Efficiency Memorability Error avoidance

34. Accessibility • Video games: Compliance with age/content ratings systems (e.g., no violence) Web-based system: Compliance with standards for the blind

35. Pretty, Fun, Cool What about NFRs such as “fun” or “cool” or “beautiful” or “exciting”?

36. Reference Model

37. Where can we find them?

38. Where to Find Them

39. Stakeholder Interrogation

40. How do we organize them?

41. Attributes/Gottesdiener

42. IIBA Spotlight Webinar: Oh, No! Not Nonfunctional with Roxanne Miller

43. User Needs

44. Measures and Metrics • Metric: mean time between failures • Measure: number of failures in a period of time (an observation!)

45. Defined Circumstances • Valid – for use case ABC the system will respond to a valid user entry within 5 seconds for a median load of 250 active users and 2000 logged in users 95% of the time; or within 10 seconds for a peak load of 500 active users and 4000 logged in users 90% of the time. Invalid – the system should respond to user input within 10 seconds.

46. RASSUI(NCR) Reliability Availability Serviceability Security Usability Installability

47. And Accuracy and Security and a Pony…

48. FURPSHewlett-Packard • Functionality • Feature set, Capabilities, Generality, Security • Usability • Human factors, Aesthetics, Consistency, Documentation • Reliability • Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure • Performance • Speed, Efficiency, Resource consumption, Throughput, Response time • Supportability • Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability

49. FURPS+

50. Competitive Engineering, Tom Gilb