Requirements Engineering

1. RequirementsEngineering Southern Methodist University CSE 7316 – Chapter 6, Quality Requirements

2. Introduction • How well a system must perform its functions • Response time • Usability • Security • Maintainability • Non-functional requirements • Absent in many specifications

3. Introduction • Some are mandatory • Response time requirements in a process control system • Others not as mandatory • Soft targets, lower cost • Tactics have been to focus on functional early and let non-functional catch up • Simulation systems

4. Quality factors • McCall (US Air force) • Operation; daily use by end users • Revision; maintenance/extension of SW • Transition; use of SW in new technical settings

5. Operation • Integrity • Correctness • Reliability • Usability • Efficiency

6. Revision • Maintainability • Testability • Flexibility

7. Transition • Portability • Interoperability • Reusability

8. ISO 9126 • Functionality • Reliability • Usability • Efficiency • Maintainability • Portability • Suitability • Compliance and conformance • New sub factors

9. IEEE 830 • Performance • Software system attributes • Reliability • Availability • Security • Maintainability • Portability • Ease of use

10. Quality factors

11. The quality grid • Some quality factors are important while others are not • Quality grids are used to find important quality factors in a systematic way • Select factors • Assess importance • Specify concerns • Be balanced

13. Open metric and open target • A quality requirement will normally have a numerical target to reach • Open target approach is to ask the supplier to specify what response time they can provide (R5) • Customer specify expectation and ask supplier to specify what they can offer • Open metric; customer may not know how to measure the quality of the system

14. Open target and open metric

15. Planguage • Tag; factor we talk about • Gist; what we are after in broad terms • Scale; measurement scale • Meter; how we measure in practice • Must; absolutely critical level • Plan; level where we can claim success • Wish; what the user expects • Past; what the old system did

16. Planguage version of target

17. Cost/benefit of quality • Response time is a matter of cost and benefit • Cost; if the response time has to decrease, the system will be more expensive. Typically the customer has to buy more HW • Benefit; if the response time decreases, the system will save more money because users can work faster

18. Cost/benefit of response time

19. Capacity and accuracy requirements • Simplest kind of quality requirement • Usually mandatory in the sense that a smaller target value makes the system useless • Capacity requirements are computer resources that the product can occupy for some time

20. Capacity and accuracy requirements

21. Accuracy requirements • These requirements cover both the range and the precision of the data • How large and how small can data values be and how accurate should they be?

22. Performance requirements • How fast the product shall be • Can also be domain related such as the maximum time it takes for an experienced user to perform a specific task

23. Performance requirements

24. Psychological limits • Performance limits can be based on human psychology • Mental preparation during typing (this is when temp files are saved) • Waiting more than 20 seconds • Task changes are a large mental effort

25. Average and upper limits • Don’t insist on stated response time in all cases • This can be very expensive

26. Response time probabilities • Worst case is extremely rare • There are several ways to do this (see following slides) • When you specify response times in multi user systems, never specify maximum response times. • Maximum is exceedingly rare. • Specifying for instance the 95% limit is OK

27. Response times M/M/1

28. Response times M/D/1

29. Multi user systems • In some cases the supplier cannot take responsibility for end user requirements because other parties are involved • Internet • Response time as seen by end user • Response time from server • Delay in the internet • Supplier cannot take responsibility for both • Customer should specify response time for the server (assume internet has zero delay) • Customer should specify delay on the internet in contract with the ISP

30. Usability • Most agree that a computer system should be easy to use • But it must be verifiable • Tailor made or COTS • What is a “new user”? • We can develop systems to get high usability

31. Usability

32. Usability problems • A situation where a user cannot figure out how to carry out a task or finds it too cumbersome • Other defect types • Bugs • Missing functionality

33. Usability problems

34. Usability tests • Most effective technique to find the usability problems is a usability test • Have the user carry out realistic tasks using the system or a mockup of it • Observe only • Think aloud

35. Usability test and heuristic evaluation

36. Heuristic evaluation • Hire an expert and have them look at the screens and point out problems • The user interface equivalent of what programmers call code inspection or review • Finds a lot of problems but always the right ones

37. Defects and usability factors

38. Usability factors • Usability = fit for use + ease of use • Fit for use means that the system can support the tasks that the user has in real life • From a requirements viewpoint this is what the functional requirements deal with

39. Usability factors • Ease of use means that that the system is easy o learn, efficient in day to day work, etc • Usability factors • Ease of learning • Task efficiency • Ease of remembering • Subjective satisfaction • Understandability

40. Usability requirements

41. Security • Security requirements aim at preventing misuse cases. • Other kinds of requirements aim at supporting use cases • Threats • Input process • Storage process • Output process

42. Security risk assessment • Hard to specify all security risks • Identify the more critical threats by means of a security risk assessment producing an estimate of frequency of each threat and the loss if it occurs • Illegal access • Disk crash • Computer crash • Sabotage • Fraud • Virus

43. Threats

44. Security risk assessment

45. Safeguards • Prevention • Detection • Repair

46. Input process • Physical distortion • Disaster • Simple user errors • Program errors • Sabotage • Illegal access • Stealing passwords • Wire tapping • Programmed crime

47. Timing Constraints

48. Timing Constraints • Define response time requirements for software and/or the environment • Many simple cases • key press response time < 10 msec • Four basic types of timing constraints • stimulus-response • response-response • stimulus-stimulus • response-stimulus

49. Timing Constraints • Stimulus is an action performed by the user or environment on the system • Response is an action by the system on the user or environment

50. Stimulus-Response • Stimulus-response; constraint that the system must produce a response in accordance with a specified timing relationship to an earlier user stimulus to the system