Requirements Engineering

Transcription

1 Requirements Engineering Vesa Tenhunen University of Joensuu Dept. of Computer Science & Statistics

2 Requirements Engineering Requirements Engineering, , 5 cu "Vaatimusten käsittely" in Finnish A Master's level course in Software Engineering compulsory to every MSc student in SE optional to all the others (including IMPIT students) Prerequisites basic knowledge about software engineering (e.g. passed courses like "Ohjelmistotuotanto" or "Järjestelmäkehitys")

3 Requirements Engineering Lectures Wednesdays in T/D106 Thursdays in T/D lectures (24 hours) Lecture notes no paper versions downloadable PDF files from course homepage Supplementary reading delivered during lectures, related questions will appear in the exercises and the exam

4 Requirements Engineering Literature: Bray, Ian K., An Introduction to Requirements Engineering (Addison Wesley 2002) Kovitz, Benjamin L., Practical Software Requirements (Manning Publications Company 1999) Lauesen, S., Software Requirements (Addison Wesley 2002) Leffingwell, D. & Widrig, D., Managing Software Requirements (Addison Wesley 2003)

5 Requirements Engineering Exercise sessions group 1: Mondays in T/B181 group 2: Tuesdays in T/B181 6 sessions (12 hours) Exercise tasks tasks are published weekly on course homepage to pass the course, you must do at least one third of the tasks and mark them as done in the exercise sessions no points for e mailed tasks! bonus points awarded for tasks exceeding the minimum of 1/3 (max. 10 % of the maximum exam points)

6 Requirements Engineering Assignment compulsory part of the course scope ca. 2 cu can be done individually or in pairs (max. 2 students) more information later Exam on Thursday, December 11 th at 12:00 14:00 in T/2D106

7 Requirements Engineering Grading exam: 2/3 of the grade assignment: 1/3 of the grade exercise bonus points (for those exceeding 1/3 of the tasks) scale: 50 % = 1, 60 % = 2, 70 % = 3, 80 % = 4, 90 % = 5 Enrollment for the course everyone present should have already done that if not, use WebOodi and do it before the next lecture Course homepage: Studies Courses Requirements engineering direct link:

8 Requirements Engineering Goals: basic concepts significance processes classifications methods modelling testing

9 Contents 1. Introduction 2. Requirements 3. Processes and Models 4. Requirements Elicitation 5. Requirements Analysis and Modelling 6. Requirements Documentation 7. Requirements Validation and Negotiation 8. Requirements Management 9. Testing 10. Tools

10 Introduction Standish Group ( has tracked IT projects since 1994 Three categories for project outcome: 1. succeeded: project is finished within schedule and budget, and all required features and functions are implemented 2. challenged: project is finished and product works, but schedule and/or budget is exceeded and some functions are not implemented 3. failed: project is canceled or product is not implemented

11 Introduction Project outcomes in 2001 according to Standish Group's CHAOS report: 23 % 49 % Failed Succeeded Challenged 28 % (

12 Introduction The development of project outcomes : % 23% 49% % 27% 28% 40% 46% 33% Challenged Failed Succeeded % 31% 53% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% (

13 Introduction Major factors contributing to project success: Executive Support 18 User Involvement 16 Experienced Project Manager 14 Clear Business Objectives 12 Minimized Scope 10 Standard Software Infrastructure 8 Firm Basic Requirements Formal Methodology 6 6 Reliable Estimates Other

14 Introduction Major factors contributing to project failure: Incomplete Requirements Lack of User Involvement Lack of Resources 10.6 Unrealistic Expectations 9.9 Lack of Executive Support 9.3 Changing Reqs. & Specs 8.7 Lack of Planning 8.1 Didn't Need Any Longer 7.5 Lack of IT Management 6.3 Technology Illiteracy 4.3 Other

15 Introduction Requirements have been and still are the main source of errors in software projects Documentation 2 Other 7 Logic Design 28 Interface 6 Requirements 41 Data 6 Environment 5 Human 5 (Source of errors on a US Air Force project; Sheldon, F. et al., Reliability Measurement from Theory to Practice, IEEE Software 9, 1992)

16 Introduction Relative price of fixing a requirement error in different phases 0,1-0,2 0, Specification Design Development Testing Delivery Maintenance

17 Contents 1. Introduction 2. Requirements 3. Processes and Models 4. Requirements Elicitation 5. Requirements Analysis and Modelling 6. Requirements Documentation 7. Requirements Validation and Negotiation 8. Requirements Management 9. Testing 10. Tools

18 Requirements What is a requirement? 1. A condition or capability needed by a user to solve a problem or to achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document 3. A documented representation of a condition or capability as in 1 or 2 (IEEE Standard Glossary of Software Engineering Technology)

19 Requirements Examples of requirements: a system for university students (like WebOodi) "The students shall use the system to enroll for the courses." "Each user has his or her own user name and password which shall be used to log into the system." "The system shall read the information about the current courses from the database XYZ." "New students shall be able to use all the student related functions of the system after one hour of training."

20 Requirements Business Domain Software Engineering Domain Customer understands the business domain, developers understand SE domain Requirements (and requirements engineering) are a way to bridge the gap between these

21 Requirements Requirements can be either functional or non functional 1. Functional requirements describe the system's functionality can be modelled as use cases 2. Non functional requirements describe the system's properties performance, usability, security, maintainability etc.

22 Requirements Functional requirement answers to question WHAT, not HOW Functional user requirements can be high level descriptions of what the system should do Functional system requirements describe in detail all the system's services

23 Requirements The User can browse the whole warehouse catalogue and select whatever subpart she wants. Each product has a unique identification (PRODUCT_ID), and the User can attach it to the permanent memory of her user account. <<extend>> Find product User <<extend>> Get product information Browse catalogue <<extend>> See additional information

24 Requirements Non functional requirement describes a system's property or constraint e.g. requirements for reliability, response time, storage e.g. speed of data transfer devices, presentation form of system data Not directly related to system's functionality Non functional requirements can be more critical than functional: if they are not implemented, the system may be useless

25 Requirements Non functional requirements can be divided into different classes product requirements define that the delivered product must work in some certain way (e.g. reliability, performance, time to recover from error etc.) organisational requirements define the practices and methods used in supplier's organisation (e.g. process standards in use, requirements for implementation etc.) external requirements arise from factors outside of product or its implementation process (e.g. legal issues, compatibility etc.)

26 Requirements Classifications of non functional requirements Non-functional Requirements Product Requirements Organisational Requirements External Requirements Usability Requirements Reliability Requirements Transferability Requirements Compatibility Requirements Ethical Requirements Efficiency Requirements Delivery Requirements Implementation Requirements Standards' Requirements Legislational Requirements Performance Requirements Size Requirements Privacy Requirements Safety Requirements

27 Requirements Metrics for non functional requirements Attribute Speed Size Ease of use Reliability Robustness Transferability Metric # of performed events / second Response time Screen rewrites / second Megabytes # of ROM chips Time for training # of help screens MTBF Frequency of errors Uptime Mean time to recover from failure Percentage of events leading to failure Probability of data corruption Percentage of platform dependant statements # of target systems

28 Requirements Requirements engineering can be defined as: "the process of finding out, analysing, documenting and checking the requirements of the system" (Sommerville 2007) "a systematic way to eliciting, organizing and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system" (Leffingwell & Widrig 2003)

29 Requirements It isn't just a phase or stage Quality means fitfor purpose; you can't say anything about quality unless you understand the purpose All stakeholders need to be identified, not just the user and customer Requirements engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software intensive system, and the contexts in which it will be used. Thus RE acts as a bridge between the real world needs of users, customers and other constituencies affected by a software system, and the capabilities and opportunities afforded by softwareintensive technologies. Communication is as important as analysis Designers need to know how and where the system will be used Requirements are partly about what's needed and partly about what is possible

30 Requirements Maybe you won't need requirements engineering......if you have two persons working with ten requirements But how about......ten persons working with 200 requirements? persons with requirements?...building an Airbus A 320 with requirements? How to organise, prioritise, control access to and provide resources for all the requirements? A set of organised and systematic processes and techniques is needed

31 Requirements RE consists of two parts: requirements development (RD), consisting of eliciting, analysing, modelling, documenting, agreeing on, and reviewing of requirements requirements management (RM), consisting of maintenance, change control, and traceability of requirements

32 Requirements The boundary between RD and RM Marketing, Customers, Management Requirements Marketing Customers Management current baseline Requirements changes Analyse, Document, Review, Negotiate Baselined Requirements Requirements Change Process revised baseline Project changes RD RM Project Environment Source: Wiegers, K.E.: Software Requirements 1999

33 Contents 1. Introduction 2. Requirements 3. Processes and Models 4. Requirements Elicitation 5. Requirements Analysis and Modelling 6. Requirements Documentation 7. Requirements Validation and Negotiation 8. Requirements Management 9. Testing 10. Tools

34 Processes and Models Requirements engineering is one process among other software engineering processes Waterfall model makes requirements fixed in an early stage In spiral model risks are notified and implementation proceeds incrementally Iterative model is a combination of waterfall and spiral models; the lifecycle phases are repeated Because the requirements change as the project advances, the requirements must be managed

35 Processes and Models Requirements engineering is a process: inputs are repeatedly transformed into desired outputs and results Benefits of a mature process are e.g. better management of complex projects improved quality and customer satisfaction keeping project within budget and schedule complying to standards and guidelines is easier RE is a design process: it requires creativity, multidisciplinary cooperation, knowledge of techniques and knowledge and experience about the application domain

36 Processes and Models RE as a process inputs and outputs Existing information about systems Stakeholders' needs Organisation's standards Regulations Knowledge about application domain Requirements engineering process Negotiated requirements System specifications System models

37 Processes and Models Examples of inputs: requirements for an online bookstore existing information about system: The system shall work with all web browsers supporting javascript. stakeholders' needs: The customer shall be able to review her purchases and to see their status in different phases of delivery. organisation's standards: System platform shall be the latest versions of SUSE LINUX Enterprise Server and Apache HTTP Server that are approved by the IT department. regulations: All customer information shall be stored and managed according to law of protection of personal data (523/1999). knowledge of application domain: Each book shall be identified with a unique 10 digit ISBN code.

38 Processes and Models RE processes have large variability between different organisations due to technical maturity commitment organisational culture application domain customer supplier relationship etc. There is no single ideal or correct RE process Process model is a simplified description of a process made from a particular point of view

39 Processes and Models Waterfall model Perceived need Requirement Design Implementation Testing Operation

40 Processes and Models V model Requirement specification System specification Technical design Product design Module design Unit testing System testing Integration testing System review Acceptance testing and operation Coding

41 Processes and Models Prototyping Requirements Design prototype Implementation prototype Test prototype Documentation requirements Design Implementation Testing Operation

42 Processes and Models Spiral model

43 Processes and Models Iterative model Inception Elaboration Construction Transition Prelim iteration... Arch Dev Dev Trans iteration... iteration iteration... iteration... Release Release Release Release Release Release Release Release

44 Processes and Models Activities in an iterative model Inception Elaboration Construction Transition Requirements Analysis & Design Implementation Test Deployment Configuration & change management Project management Initial Elab 1 Elab 2 Const 1 Const 2 Const N Tran 1 Tran 2

45 Processes and Models Informal requirements Requirements elicitation Requirements analysis and negotiation Requirements specification and validation report START Agreed requirements Requirements validation Requirements documentation Requirements specification draft

46 Processes and Models Actors in RE process (or any other process) are persons who, in one way or another, participate in implementing the process Actors are not defined as individuals but as roles In RE the actors are participants in the problem to be solved participants in the solution Role diagrams state which actors take part in which activity

47 Processes and Models Rapid Application Development role diagram for prototyping Actions Understand problem Establish outline requirements Select prototyping system Develop prototype Evaluate prototype Req.engineer Domain expert End user Req.engineer End user Software engineer Project manager Req.engineer Software engineer End user Domain expert Req.engineer Software engineer Roles

48 Processes and Models Requirements engineering has been defined in different kind of standards (ISO) and process improvement models (CMMI and SPICE) ISO IEC identify and meet customer requirements establish methods that can be used to identify customer related requirements and to authorise and track changes in them evaluate risks related to requirements etc.

49 Processes and Models CMMI (Capability Maturity Model Integration) is a de facto standard in assessing maturity of software organisations LEVEL 1 Initial LEVEL 3 Defined (continued) N/A Organizational Project Focus LEVEL 2 Managed Organizational Process Definition Requirements Management Organizational Training Project Planning Integrated Project Management Project Monitoring and Control Risk Management Supplier Agreement Management Integrated Teaming Measurement and Analysis Integrated Supplier Management Process and Product Quality Assurance Decision Analysis and Resolution Configuration Management Organizational Environment for Integration LEVEL 3 Defined LEVEL 4 Quantitatively Managed Requirements Development Organizational Process Performance Technical Solution Quantitative Project Management Product Integration LEVEL 5 Optimizing Verification Organizational Innovation and Deployment Validation Causal Analysis and Resolution

50 Processes and Models Requirement management processes on CMMI level 2: obtain an understanding of requirements obtain commitment to requirements manage requirements changes maintain bidirectional traceability of requirements identify inconsistencies between project work and requirements

51 Processes and Models Requirement development processes on CMMI level 3: develop customer requirements elicit needs develop the customer requirements develop product requirements establish product and product component requirements allocate product component requirements identify interface requirements analyse and validate requirements establish operational concepts and scenarios establish a definition of required functionality analyze requirements analyze requirements to achieve balance validate requirements

52 Processes and Models Connections between requirements development, management and other process areas in CMMI Risk management Configuration management Project planning Product integration Requirements development Requirements management Verification Validation Technical solution Project monitoring and control

53 Processes and Models ISO/IEC aka SPICE (Software Process Improvement and Capability determination) is an international standard for process improvement and capability assessment level 5: optimizing level 4: predictable level 3: established level 2: managed level 1: performed level 0: incomplete

54 Processes and Models In SPICE, the processes are classified into nine process areas I PRIMARY II SUPPORTING III ORGANISATIONAL Acquisition (ACQ) Support (SUP) Management (MAN) ACQ.1 Acquisition Preparation SUP.1 Quality Assurance MAN.1 Organizational Alignment ACQ.2 Supplier Selection SUP.2 Verification MAN.2 Organization Management ACQ.3 Contract Agreement SUP.3 Validation MAN.3 Project Management ACQ.4 Supplier Monitoring SUP.4 Joint Reviews MAN.4 Quality Management ACQ.5 Customer Acceptance SUP.5 Audit MAN.5 Risk Management Engineering (ENG) SUP.6 Product Evaluation MAN.6 Measurement ENG.1 Requirements Elicitation SUP.7 Documentation Process Improvement (PIM) ENG.2 System Reqs. Analysis SUP.8 Configuration Management PIM.1 Process Establishment ENG.3 System Architectural Design SUP.9 Problem Resolution Management PIM.2 Process Assessment ENG.4 SW Requirements Analysis SUP.10 Change Request Management PIM.3 Process Improvement ENG.5 SW Design Resource & Infrastructure (RIN) ENG.6 SW Construction RIN.1 Human Resource Mgmt ENG.7 SW Integration RIN.2 Training ENG.8 SW Testing RIN.3 Knowledge Management ENG.9 System Integration RIN.4 Infrastructure ENG.10 System Testing Reuse (REU) ENG.11 SW Installation REU.1 Asset Management ENG.12 SW & System Maintenance REU.2 Reuse Program Mgmt. Supply (SPL) REU.3 Domain Engineering SPL.1 Supplier Tendering SPL.2 Product Release SPL.3 Product Acceptance Support Operation (OPE) OPE.1 Operational Use OPE.2 Customer Support

55 Processes and Models IEEE STD IEEE Recommended Practice for Software Requirements Specifications content and qualities of good software requirements specification, sample outlines not ideal, but gives some advice on how to write requirements the specifications vary a lot depending on type of the system being specified

56 RE Road Map PROBLEM DOMAIN Problem domain is the home of users and other stakeholders who have technical or business needs requiring to be solved

57 RE Road Map PROBLEM DOMAIN Needs Stakeholder needs must be collected by studying the problem domain

58 RE Road Map Needs PROBLEM DOMAIN Features A feature is a service provided by the system that fulfills one or more stakeholder needs

59 RE Road Map Needs Features Software requirements PROBLEM DOMAIN Requirement is a precise and detailed description of a feature for implementing the system

60 RE Road Map Needs Features Software requirements } } } PROBLEM DOMAIN SOLUTION DOMAIN Solution domain is a description of the system, represented by features and requirements that will drive its design and implementation

61 RE Road Map Needs Data collection PROBLEM DOMAIN Traceability Features Software requirements } } Solution domain } PRODUCT TO BE BUILT Test cases

62 Contents 1. Introduction 2. Requirements 3. Processes and Models 4. Requirements Elicitation 5. Requirements Analysis and Modelling 6. Requirements Documentation 7. Requirements Validation and Negotiation 8. Requirements Management 9. Testing 10. Tools

63 Requirements Elicitation Needs Data collection PROBLEM DOMAIN Traceability Features Software requirements } } Solution domain } PRODUCT TO BE BUILT Test cases

64 Requirements Elicitation Problem analysis is used to gain understanding of the problem so that a system providing the solution can be build The actual customer needs can be dug out with problem collection The required system features can be derived from analysis of needs The features wanted are described as requirements

65 Requirements Elicitation Requirement can also be defined more like a system's feature than a user's need: The requirements are [...] descriptions of what should be implemented. They are descriptions of how the system should function [...] They can be constraints for system's development process. (Sommerville & Sawyer 1997) What: a feature the system must have for solving an existing problem How: product parameters functional and non functional requirements Constraints: process parameters

66 Requirements Elicitation To find out requirements for a system, several things must be determined first, including system's scope and goals roles of different stakeholders and users tasks and responsibilities of the persons in different roles stakeholder needs and their prioritisation workflow, practices of use structure of the processed data

67 Requirements Elicitation Problem Analysis Problem analysis is a process to find out and to gain understanding of the real problems and user's needs, and to find solutions to them Domain of possible solutions PROBLEM DOMAIN

68 Requirements Elicitation Problem Analysis "A problem can be defined as the difference between things as perceived and things as desired." (Gause & Weinberg 1989) If a user perceives something as a problem, then it is a problem! There are, however, many different ways to address the problem we do not always need to build a new system If we do, our aim is to define and implement a new system that narrows the difference between "perceived" and "desired"

69 Requirements Elicitation Problem Analysis A problem must be described, conceptualized and made sure that everybody see it similarly Finding root causes leads often to better understanding of the real problem Causes of the problem and their relationships must be understood WHAT is the cause WHY the cause exists WHERE the cause appears WHEN the cause appears WHO confronts the cause HOW the cause affects the problem

70 Requirements Elicitation Phases of Problem Analysis There is no point in trying to create a solution before the problem is understood well enough Phases of problem analysis (Leffingwell & Widrig 2003): 1. Gain agreement on the problem definition 2. Identify the problem's root causes 3. Identify the users and other stakeholders 4. Define the system's scope 5. Identify the solution's primary constraints

71 Requirements Elicitation Phases of Problem Analysis 1. Gain agreement on the problem definition What is the problem To whom does it affect Describe the problem Identify and define the stakeholders What/where does it affect Describe the problem's effects Solution's benefits List the benefits that the solution will provide......

72 Requirements Elicitation Phases of Problem Analysis 2. Identify the root causes Cause 1 Cause 2 Cause 3 Cause 4 Cause 5 Cause 6 Problem Cause 1 Cause 2 Cause 3 Cause 4 Cause 5 Cause 6 Fishbone diagram Pareto diagram

73 Requirements Elicitation Phases of Problem Analysis 3. Identify the users and other stakeholders identify all the stakeholders not just customers and understand their different views and needs end users of the system those who use the results provided by the system those who are responsible for the system's maintenance roundabout users outside agencies, customer's customers etc.

74 Requirements Elicitation Phases of Problem Analysis 4. Define the system's scope Internet New software system Other systems

75 Requirements Elicitation Phases of Problem Analysis 5. Identify the solution's primary constraints customers subcontractors competitors authorities technology economics system platform... $$$

76 Requirements Elicitation Phases of Problem Analysis After a careful problem analysis, the project team can be reasonably confident that it has understood well both the problem to be solved and the root causes behind it identified thoroughly all stakeholders (whose judgment tells in the end whether the system is successful or not) understood the scope and where the solution's boundaries are most likely to be found understood both the constraints and liberties for solving the problem

77 Requirements Elicitation Resolving Customer Needs Resolving customer's needs or requirement elicitation is usually a difficult task domain information can be fragmented no clear, single document contradictory sources tacit knowledge hard to formalize commonly used "self evident" knowledge difficulties in observation those who know are often busy observing work practices will change them distortions company culture, personal relations etc. influence on what is told users may not want to tell everything

78 Requirements Elicitation An Example Problem domain: loan department of a large bank. Supplier's representative tries to resolve the rules and actions involved in granting a loan Possible difficulties: implicit knowledge not all the rules can be found in documents controversial knowledge users have various interpretations of rules controversy between words and deeds users don't do their work as they (or their superiors) describe observation effect users change their habits when watched distortion users may fear for their jobs, so they show only tasks requiring manual input

79 Requirements Elicitation Resolving Customer Needs There are many methods and techniques to resolve customer needs Different methods are appropriate in different situations and they usually complement each other An appropriate set of methods must be selected for each project

80 Requirements Elicitation Resolving Customer Needs Traditional methods: check lists inspection of documents collecting "hard data" interviews open closed questionnaires meetings

81 Requirements Elicitation Resolving Customer Needs Collaboration techniques: limited topic workshops brainstrorming sessions JAD/RAD workshops prototyping participatory design Cognitive techniques: knowledge acquisition techniques protocol analysis task analysis

82 Requirements Elicitation Resolving Customer Needs Contextual methods: ethnographical techniques observation ethnomethodology discourse analysis analysing uses of written, spoken or signed language sociotechnical methods soft systems methodology

83 Requirements Elicitation Resolving Customer Needs Presentation methods: goal oriented method: starts with writing down organisation's goals requirements defining how the new system leads to attaining goals obstacles indicating when a goal is impossible to attain constrains indicating when a goal is possible to attain and continues with creating a more fine grained goal hierarchy; result is a description of why the requirements are what they are

84 Requirements Elicitation Resolving Customer Needs Presentation methods (cont.): use cases and scenarios simulation especially appropriate when the customer representatives are inexperienced (ie. the customer hasn't previously had a comparable system) prototypes must be thought out beforehand what is wanted to find out with prototype and how it is measured after prototype is finished prototypes can be classified as explanatory experimental and evolving

85 Requirements Elicitation Traditional Methods Inspection of documents sources: reports, organisation charts, procedure guidelines, task descriptions, documentation of existing systems, etc. helps to get information about the customer before meeting users and stakeholders, helps in preparing other methods of information gathering, may tell the detailed requirements of the current system written documents are not necessarily true, they may contain a lot of irrelevant information method is suitable in situations where the supplier is not familiar with the customer and its organisation

86 Requirements Elicitation Traditional Methods Collecting "hard data" recognising hard data repositories indicators, economical information, reports used in decision making, survey results, marketing information, etc. selecting a representative sample no use to go through all information, but the sample must be large enough pros and cons similar to document inspection, but cost of data analysis may be higher

87 Requirements Elicitation Traditional Methods Interviews one of the most important and most commonly used methods well suited for defining problem domain and eliciting user need understanding real problems bringing forth possible solutions viewpoint of users, customers and other stakeholders interviews must be conducted properly thorough preparations right questions for right persons accurate recording of answers recapitulation KERTAUS in the end to ensure understanding open or closed

88 Requirements Elicitation Traditional Methods Questionnaires fast and easy method problems: small number of answers and lack of communication can be used before interviews to find suitable interviewees or afterwards in complementing interviews no substitute for interviews! Meetings used in summaries and to give and to receive feedback e.g. meeting of participants in the end of different project phases discussion of results decision about requirements agreeing on planning, etc.

89 Requirements Elicitation Collaboration Techniques Workshops efficient way to collect requirements key stakeholders meet and talk about the system max. length of the workshop is one day requires and skilled and experienced facilitator problems and solutions are generated with brainstorming

90 Requirements Elicitation Collaboration Techniques Joint/Rapid Application Development workshops a 3 5 days long workshop instead of interviews, usage of a lot of visual tools systematic and rational approach: requirements elicitation and analysis process is defined with brainstorming sessions and top down analysis clear documents every JAD session produces a document and its content is agreed upon during the same session

91 Requirements Elicitation Collaboration Techniques Prototyping possibility to demonstrate something in an early state instant feedback for solution proposals better estimates for budget and schedule better detection of unknown and undefined requirements disposable prototype (discarded after feedback) or development prototype (its development is continued until finished product) problem: customer may get an impression of development taks being easy and fast

92 Requirements Elicitation Cognitive Techniques Knowledge elicitation techniques aimed to discover expert knowledge and expertise Protocol analysis eliciting knowledge about work practices based on thinking aloud and description of thoughts direct relation with actual work easy to spot problems with current system self reflection is unreliable and lacks a social dimension

93 Requirements Elicitation Contextual Approaches Ethnographic techniques participating observer becomes a part of customer's organisation can reveal al lot of information that is impossible to gain with any other technique extremely time consuming, the constructed big picture may be difficult to analyse Ethnometodology subdomain of anthropology: finding different behavioural patterns with similar purpose and meaning tightly controlled research methods, used to gain knowledge of social situations

94 Requirements Elicitation Problems There are many problems and difficulties customer knows what she wants, but cannot express it customer doesn't really know what she wants customer thinks she knows what she wants (until she gets what she said she wants) supplier thinks she knows the customer's needs better than the customer Users are experts in their work Usually users know better what they do not want let them tell about that

95 Requirements Elicitation Problems What is not commonly regarded as requirements? system's structure implementation techniques development methods development environments implementation languages criteria for reuse Customer shouldn't be allowed to set constrains to any of these

96 Requirements Elicitation Interviews Interview is a simple and direct technique and it can be used in most situations Two options closed (or structured) interview: questions made in advance; a clear purpose; heavy workload; more information gathered, yet some things can remain uncovered open interview: more like a face to face conversation; no premeditated questions (or just few); suitable in charting basic information; doesn't produce systematic data The effect of interviewer's biases and prejudices can be circumvented with context free questions

97 Requirements Elicitation Interviews Steps in conducting an interview: prepare questions in advance and review their suitability (C) familiarise yourself beforehand with interviewee's and her organisation's background (start interview with confirming them) use recorder or write down the answers review your list of questions time to time (C) let the interviewee answer in her own time and with her own words make a recap in the end, or a few times before, of the most important things and confirm you got them correctly make a summary of the three most important needs that came up during the interview (C) = closed interview

98 Requirements Elicitation Interviews It doesn't take many interviews to find out the most critical needs provided that stakeholder analysis is conducted properly The summary of the three most important needs starts usually to show some common themes after a few interviews 10 interviewees x 3 needs!= 30 requirements Summaries of these most important needs is a starting point for building a requirements repository

99 Requirements Elicitation Requirements Workshop Workshop is on of the most efficient ways to elicit requirements if you have resources only for one method, use this Workshop gathers together all stakeholders' key personnel for a short time (max. one day), during which they concentrate only on requirements Efficiency can be improved by appointing a requirements engineering expert as a workshop facilitator (who is otherwise not involved in the project) The most important part of workshop is brainstorming session

100 Requirements Elicitation Requirements Workshop Benefits of well organised workshops improves team spirit and commitment to project all the stakeholders get a chance to voice their opinions helps the stakeholders and developers gain a common understanding about system's purpose can expose problems and offer solutions to them in work methods that could interfere with project results are available right after the workshop Problems of workshops relies a lot on the facilitator heated arguments and other misbehaviour possible distortions in the results

101 Requirements Elicitation Requirements Workshop Preparing a workshop: selling the idea making sure the right stakeholders will participate meticulously taking care of arrangements preparing and distributing the material beforehand project information innovation enticing reading appointing an outsider facilitator (if possible) creating an agenda and schedule

102 Requirements Elicitation Requirements Workshop Conducting a workshop: new ideas during brainstorming sessions no critique, no (lengthy) conversations discussion, evaluation and pruning of ideas after brainstorming debates,votes prioritisation of ideas facilitator keeps things rolling and adheres to the schedule in the end of the day, the found requirements are collected and delivered to the development team If it's not possible to physically get everyone together, brainstorming can be arranged on line

103 Requirements Elicitation Storyboard Storyboard (kuvakäsikirjoitus) gives an opportunity to get feedback and reactions from customer in an early phase Storyboard can be passive, pen and paper, screen shots, PowerPoint slides active animation, "PowerPointware" or interactive demonstration

104 Requirements Elicitation Storyboard Storyboard is a very cheap and flexible technique Suitable for situations where customer isn't sure what she wants For every function/action/task, three things must be described in storyboards who are the actors users, systems or equipment what happens to them behaviour of actors when interacting with the system how it happens events, states, state changes

105 Requirements Elicitation Features Needs Data collection PROBLEM DOMAIN Traceability Features Software requirements } } Solution domain } PRODUCT TO BE BUILT Test cases

106 Requirements Elicitation Features Features at general level are derived from the needs collected from users and other stakeholders Features are high level descriptions of system's functions It is necessary to keep features separate from needs often users talk about features when they describe their needs Difference must be kept in mind while eliciting requirements if the need behind a feature is not understood or recognised, implementing the feature may not fulfil user's need

107 Requirements Elicitation Features Examples of features Application Domain Elevator control: Warehouse inventory: Defect tracking: Salaries: Lightning control: Launching nuclear missile: Word processing software: (Functional) Feature Manual control of doors in emergency Show real time status of all items Show trend data for quality tracking Show only selected fields in reports Random lightning while building is empty Launch requires two separate confirmations Compatibility with Windows XP

108 Requirements Elicitation Features Usually features is enough recommended to keep the number below 50 if there seems to be more, describe features on a higher level of abstraction Relatively small and limited number of features is a sufficient basis for product description communication with stakeholders scope management project management

109 Requirements Elicitation Features Features are described with attributes helps to track, identify, prioritise and classify features Recommended attributes: status for tracking and monitoring progress during development; e.g. proposed / approved / finished priority/benefit for scope management; e.g. critical / important / useful effort for budget and schedule estimations, e.g. number of person months, or low / medium / high

110 Requirements Elicitation Features risk probability of feature's undesirable effects; e.g. low / medium / high stability probability that the feature will change; e.g. low / medium / high target release in which product version a feature will appear for the first time; e.g. version 1.0 assigned to who is responsible for feature's implementation cause for tracking the source of a requirement; e.g. page and chapter number in product description, line number in customer interview transcript