Lecture 3 of CSC2101-PSD & TP1 Functional and Non-functional Requirements.pdf

Singapore CSC2101 – PROFESSIONAL SOFTWARE DEVELOPMENT & TEAM PROJECT 1 LECTURE 3: FUNCTIONAL AND NON- FUNCTIONAL REQUIREMENTS Assoc. Prof. Cao Qi [email protected]  School of Acknowledgement Computing Science Contents of CSC2101 – PSD & TP1 are derived from:...

Singapore CSC2101 – PROFESSIONAL SOFTWARE DEVELOPMENT & TEAM PROJECT 1 LECTURE 3: FUNCTIONAL AND NON- FUNCTIONAL REQUIREMENTS Assoc. Prof. Cao Qi [email protected]  School of Acknowledgement Computing Science Contents of CSC2101 – PSD & TP1 are derived from: COMPSCI4015 - Professional Software Development (H), University of Glasgow (UoG). Acknowledgement: Dr. Tim Storer, UoG, UK. COMPSCI3005 - Software Engineering M3, UoG Acknowledgement: Dr. Richard McCreadie. Software Engineering. Acknowledgement: Author: Ian Sommerville. Publisher: Pearson. ICT2101/2201 - Introduction to Software Engineering, Acknowledgement: Dr. Alex Chen. COMPSCI5059 - Software Engineering M5, UoG Acknowledgement: Dr. Marwa Mahmoud, Handan Gul Calikli. 2  School of Lecture Contents Computing Science Evolving Requirements. Functional and non-functional Requirements (NFR). Measures of NFR. 3 School of Computing Science Evolving Requirements 4  School of Potential Risks Computing Science Mis-understand business context of software Mis-understand system domain functions Culture difference of Customers and Teams Vague functional/non-functional requirements 5 School of Evolving Requirements Computing Science New risks or Business opportunities Priority uncovered Changes Customers’ Problem Understanding Domain Increases Changes 6  School of Moving Target Problem Computing Science Change in the requirements while the software is being developed. Track requirement changes to a software under development. 7  School of Requirement Iterations Computing Science Requirement engineering, an iterative process of elicitation, specification and validation. 8  School of Requirement Elicitation Computing Science Discovering requirements from customers in iteration. Requirement elicitation is a difficult stage. Keep communications with customers. Common techniques in an on-going and iterative process: Interview Survey 9  School of Interview or Survey Computing Science Questions Structure questions to resolve requirement uncertainty or identify new requirements. Coordinate questions with other group members for good question coverages. Rehearsal interview to avoid time over-run. Open questions Please describe what details about an appointment are currently booked. Closed questions How important is the appointment booking function? Not at all important. Not very important. Somewhat important. Very important. Essential. 10  School of User Stories and Actors Computing Science Actor: a person, device or entity interacts with software. As an [actor] I want to [action on or by the system] So that [rationale] User stories: interactions of actors and the software system. As a first-time house buyer, As an estate agent, I want to enquire on I want to be notified about available properties that a new enquiry, match my preferences, So that I can follow up with So that I can find a the new client. property to stay. 11  School of Requirement Computing Science Documents Natural language. Structured natural language such as user stories. Pseudo codes. Unified Modeling Language (UML) diagrams. Class Diagram Use case diagram Activity diagram Sequence diagram State diagram 12  School of MoSCoW Prioritization Computing Science Must Have: Requirements are critical to the current delivery, highest importance for success. Should Have: Important requirements but not vital, large impact on project success. Could Have: Desirable requirements but less important, less impact if left out. Won’t Have: Features are relevant but not a priority in the current timeframe. 13 School of Computing Science Functional and Non- functional Requirements 14  School of Functional and Non- Computing Science functional Requirements Functional Requirements Non-Functional Requirements “What” “How well” Actions or tasks that Quality Attributes of software product must software product be able to perform from design constraints or the user perspective. performance. 15  School of Functional Computing Science Requirements Functions a software Intended behaviors must perform. of a system How system should react to particular inputs. What inputs the system should accept. What outputs the system should produce. What data the system should store. What computations the system performs. Can be tested at different levels of testing. 16  School of Functional Computing Science Requirements Should describe the requirements in detail. Map a problem to a solution in users’ language. Describe interactions between the system and its environment. e.g., in a Patient Management System for clinics. A user is able to search the appointment lists for all clinics. System shall generate each day a list of patients who are expected to attend appointments that day. Each staff member using the system shall be uniquely identified by the eight-digit employee number. 17  School of Non-functional Computing Science Requirements (NFR) NFR define quality attribute of a software; specify external constraints must be met. NFR are important and essential to ensure usability and effectiveness. If not met, system is useless. Imprecise NFR may be difficult to verify. ISO 9126 – NFR linked to “quality in use”. 18  School of Non-functional Computing Science Requirements (NFR) Quality Attributes. Reliability Robustness Security Usability Performance Design Constraints Platform constraints Response times 19  School of Functional and Non- Computing Science functional Requirements No clear distinction between functional & non- functional requirements (depend level of details). e.g., system shall ensure data is protected from unauthorised access. (considered NFR) System shall include a user authorisation procedure. Users must identify themselves with username & password. Only authorised users may access data. Functional requirement as specifies a function (user login) incorporated in system. 20 School of Computing Science Measures of Non- functional Requirements (NFR) 21  School of Computing Science NFR Testing NFR describes emergent properties of overall system that must be measured and satisfied. NFR cannot typically be checked for in unit tests or static analysis. NFR can only be tested at system testing with implementation of prototype or final system. 22  School of Information Needed for Computing Science Testing NFR Properties Property of the system to be measured. Measure metric to be used. Operating conditions in which the requirement must be satisfied. Threshold the system behaviour must exceed to satisfy the requirements. 23  School of Computing Science Quantification of NFR NFR need to be measurable: – Avoid subjective terms: good, optimal, better, etc. Values are not just randomly specified: – Must have a rational. – Stakeholder must understand trade-offs. – Important to rank and prioritize the requirements. Precise numbers are unlikely to be known at the beginning of the requirement process. 24  School of Computing Science Example: Quantification Requirements: o The system should be easy to use by experienced controllers, and should be organised in such a way that user errors are minimised. By quantification of NFR: o Experienced controllers shall be able to use all system functions after two hours training. o After this training, average number of errors made by experienced users shall not exceed two per day. 25  School of Examples: Computing Science Quantification Measures Property Measure Speed Processed transactions per second User/event response time; Screen refresh time Size K Bytes; Number of RAM chips; Ease of Use Training time; Number of help frames Reliability Mean time to failure (MTTB); Probability of Unviability; Rate of failure occurrence; Down time. Robustness Time to restart after failure; Percentage of events causing failure; Probability of data corruption on failure; Portability Percentage of target dependent statements; Number of target systems; 26  School of Measures of Computing Science Reliability Testing Software reliability testing for systems operating in safety critical environments: Probability of no failure in a specified time interval. Probability of failure on demand: estimate of the probability of failure each time system is accessed. Mean time to failure (MTTF): how long for a software to fail from initiation, or average time between failures. Down time: how much time can be lost to system outages over a year. 27  School of Example - Measures of Computing Science Reliability Testing Precision of calculations shall be at least 1/106. The system defect rate shall be less than 1 failure per 1,000 hours of operation. No more than 1 per 1,000,000 transactions shall result in a failure, requiring a system restart. Down time of the system should be less than 1 week per year. 28  School of Computing Science Security Testing Software security testing for systems operating in hostile environments (threats or attackers): The ability to resist unauthorized attempts at usage. Continue providing service to legitimate users while under denial of service attack (resistance to DoS attacks). 29  School of Computing Science Security Testing Metrics Time and resources to penetration. Unpatched vulnerabilities per line of code. Patches issued per year. Successful penetrations per year. Attack surface exposure. Lifespan of a password, of a session. Encryption level. 30  School of Computing Science Security Testing Methods Vulnerability testing: SQL injection testing: the most commonly used web hacking techniques for accessing, manipulating and destroying databases. Port scanning: determine which ports are open. Fuzz testing: supply with malformed (fuzzed) inputs causing system to behave in unexpected ways (if can cope with malformed inputs). Penetration testing: authorized simulated attacks to evaluate software security, using the same tools, techniques, and processes as attackers. 31  School of Examples: Measures Computing Science of Security Testing Software shall ensure that the employee's name in human resource and payroll databases exactly matches the name printed on employee’s NRIC. At least 99% of intrusions shall be detected within 10 seconds. 32  School of Computing Science Performance Testing Focus is requirements related to throughput, response time, memory utilization, input / output rates, loss of information, latency, etc. Requirements must be stated in quantifiable terms. Statistical testing based on an operational profile is often employed. Usually with probabilities, confidence levels. 33  School of Performance Testing Computing Science Metrics Properties: Throughput: amount of transactions that a system can process in a given time. Response: average or maximum length of time taken to respond to a transaction request. Threshold: Limit: demonstrate a system behaves as expected within required operating limits. Stress: demonstrate a system continues to behaves reliably when operating outside of normal limits. 34  School of Examples: Measures of Computing Science Performance Testing System shall be able to process 100 payment transactions per second in peak load. In standard workload, 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. 35  School of Computing Science Usability Metrics Ease of use and of training end users: Learnability: Proportion of functionalities or tasks mastered after a given training time. Operability: Capability of the software to enable users to operate and control it. Likeability: Capability of the software to be liked by users. User satisfaction: Satisfaction ratio per user class. 36  School of Examples: Measures of Computing Science Usability Four out of five users shall be able to make a booking within 5 minutes after a 2-hour introduction to the system. Novice users shall perform tasks X and Y in 15 minutes. Experienced users shall perform tasks X and Y in 2 minutes. At least 80% of customers after a 3 months usage period shall rate their satisfaction at > 7 on a scale of 1 to 10. 37  School of Computing Science Next Lecture Lecture 4: UML Structure Modelling 38