Requirements AnalysisLesson 4:Some Key Definitions of Requirementsand their AttributesDr Cornelius NcubeRoom P104 Dcncube@bournemouth.ac.uk
ObjectivesTo make you aware of:– Importance of effective requirements engineering– Range and types of problems which arise– Leading edge research and practiceTo give you:– Practical skills in leading-edge methods and techniques– Practical knowledge of requirements engineering tools– Outside speakersTo make you think about:– Requirements engineering is part of a wider designprocess– Free your mind - be prepared to do creative design aswell as systematic requirements engineering
Reading MaterialTwo good overall text books to use are:– Robertson S. & Robertson J., 1999, ‘Mastering theRequirements Engineering Process’, Addison-WesleyLongman;– Sommerville I. & Kotonya G., 1998, ‘RequirementsEngineering’, John Wiley.Other useful textbooks are:– Sommerville I. & Sawyer P., 1997, "RequirementsEngineering: a Good Practice Guide", John Wiley.– Davies A.M., 1993, 'Software Requirements: Objects,Functions, States', Prentice-Hall.
What is a Requirement?Definitions of a requirement– Something that a product must do or a quality that theproduct must have (Robertson & Robertson 1999)• Interesting focus on product rather than software system– Expression of the required phenomena that are sharedbetween a machine (product) and the domain orenvironment (Jackson 1995)• Requirement refers to both the domain and the machine– Requirements invariably contain a mixture of probleminformation, statements of system behaviour andproperties, and design and implementation constraints(Sommerville and Sawyer 1997)• Requirements can be nasty little things to express
The Structure of a RequirementUse the VOLERE template– Available from http://www.atlsysguild.com– See also standards such as PS-005 (Mazza et al. 1994)Requirement: Requirement Type: Event/use case:Description:Rationale:Source:Fit criterion:Customer satisfaction:Dependencies:Supporting materials:History:Customer dissatisfaction:Conflicts:
Supermarket Checkout System ExampleImportant attributes– Type: Functional requirement– Description: The system shall print a receipt for eachcustomer– Rationale: Customers need receipts as evidence...–Source: Store management team– Fit Criterion– For a representative sample of 100 customers and 1000 customer purchases withcash, debit cards, credit cards, cheques, club cards and special offer vouchers,the system prints the correct receipt with the correct information for 100% ofall purchases. An independent human checker will test compliance by randomsampling of 100 customers purchasing a representative range of items during one8-hour test period, checking purchased items against items on the receipt.– Satisfaction: 3 Dissatisfaction: 5– Dependencies: Electronic cashier system– Supporting materials: Supermarket document XYZ.
Another Supermarket Checkout Example– Type: Performance requirement– Description: The system shall print all receipts withina time acceptable to the customer– Rationale: Customers get impatient if kept waiting–Source: Customer representatives– Fit Criterion– For a representative sample of 100 customers and 1000 customer purchases thesystem prints all receipts of less than 25 items in less than 3 seconds, receiptsof 26-40 items in less than 5 seconds, and 99% of a random sample of all receiptsin less than 10 seconds from pressing the ‘transaction complete’ button. Anindependent human checker will test compliance by random sampling of 100customers purchasing a representative range of items during one 8-hour testperiod. Timings will be tested using an electronic stopwatch based on observation.– Satisfaction: 4 Dissatisfaction: 4– Dependencies: Previous Functional Requirement– Supporting materials: Supermarket document XYZ.
Functional RequirementsThe most common type of requirement– Something (service, behaviour or function) that aproduct must do (Robertson & Robertson 1999)Examples are simple to find– Supermarket: The system shall print a receipt– LAS-CAD: The system shall detect the location of allambulances–CORA-2: The system shall present all candidateresolutions to the air traffic controllerHow to test whether a functional requirement is met– Measurable fit criterion in terms of predicted outcomes– The receipt is printed, location of all ambulances areknown, controller has access to all resolutions
Non-Functional RequirementsAlso known as Quality requirements– Express the desirable qualities of the product– Predefined set of types: Performance, look-and-feel,device, usability, training, availability, maintainability,recoverability, portability, reliability, security, safety,contract and supplier-type requirements (based onRoman 1985, Robertson & Robertson 1999)– Predefined types of units of measure and test, by typePerformance requirement– Specifies time to do things, required throughput rates– Measure using response times or times to undertake anaction (speed), actions per time period (throughput), ornumbers of units handled (load)– Test using response timing, load tests, throughput tests
More Non-Functional RequirementsLook-and-feel requirement–Specifieshow end-users will perceive the product–Measureusing adherence to specified standards, use ofcolours, adoption of designs–Testusing observations of the product by independentassessors, standards compliance rulesDevice requirement–Specifiesfeatures, perhaps interactive, of the product–Measureusing adherence to specified standards, devicefeatures and attributes–Testusing observations of the product by independentassessors, standards compliance rules
More Non-Functional RequirementsUsability requirement–Specifieshow people will interact with the product–Measureusing task completion times, usage error-ratesand usage rates and frequencies– Test (with HCI techniques) with usability evaluation,protocol analysis and cognitive walkthrough techniquesTraining requirement–Specifieslevels and nature of training to use the product–Measureusing training duration and outcomes–Testusing training course outcomesAvailability requirement–Specifiesnature and levels of access to the product–Measureusing times when available, %age downtimes– Test using system-level trials and user experiences
More Non-Functional RequirementsMaintainability requirement–Specifiesthe acceptable levels of upgrade of product– Measure using time and resources to maintain– Test using simple maintenance tasksRecoverability requirement– Specifies the repair of the product in case of failure– Measure using time and likelihood to recover– Test using simple maintenance and recovery tasksPortability requirement– Specifies platforms that product needs to operate on– Measure using the names and versions of products andoperating systems– Test using usage trials on range of products
More Non-Functional RequirementsReliability requirement– Specifies levels of failure supported in the product– Measure using mean-time between (defined) failures– Test using product reliability trials, customer evidenceSecurity requirement– Specifies levels of illegal access to the product– Measure using specified access functions, and meantimebetween breaches– Test using security expertsSafety requirement– Specifies how safe is the product– Measure using number/risk of injuries in total/over time– Test using health and safety compliance techniques
An Example RequirementLook-and-feel requirement–Description: The passengers’ open-door buttons shallbe accessible to all passengers– Criterion: The button is recognisable and accessible topeople whose height is equal or above the averageheight of 5-year old UK child (x cms), adults inwheelchairs, people who are partially-sighted orregistered-blind or registered disabledCould have gone further...– Could have gone to define how to test the requirements- possibly through different passenger-typerequirements (decomposition), each with own fit criterion
Another Example RequirementMaintenance requirement–Description: The tube door system shall be maintainableand allow an engineer to readily access the electricaland mechanical mechanisms– Criterion: Using experience of systems in operation, anddesign alternatives, a set of common problems shouldbe accumulated by the LU engineers. This set ofproblems should be further decomposed/ordered basedon the average turnaround time to repair. An engineershould be able to reach and fix all known/commonproblems within the average turnaround times asspecified. It is inevitable that a new system will bringnew problems, and repair times for these should bebased on past engineer experience. An engineer shouldbe able to locate a fault within 15 minutes of inspection,and fix it within a further 2 hours.
And Another Example….Reliability requirement–Description: The system shall function as required in adusty or smoky atmosphere– Fit Criterion: The system shall function correctly withinan atmosphere below the maximum curve in the graphbelow, showing dust tolerance for the system% per cubic metre1008060402000.1 1 10 100 1000Particulate Size () Log
Requirements AnalysisTutorial:The Wide Range of Stakeholders andRequirements
Tutorial Week 3 & 4Learning objective– To uncover the range of stakeholders and theirrequirements for the LAS-CAD systemWork in small groups– Choose one of group of stakeholders to be– Imagine/brainstorm requirements that you might havefor the system. Write them down using VOLERE snowcards– Types are performance, look-and-feel, device, usability,training, availability, maintainability, recoverability,portability, reliability, security, safety, contract, supplierClass discussion– Groups present requirements– Others compare/critique these requirements!!