Identifying Needs & Capturing User Requirements Lecture 15 PDF

Identifying Needs & Capturing User Requirements LECTURE 15 Requirement Elicitation Techniques Interviews 1 Scenarios Protot...

Identifying Needs & Capturing User Requirements LECTURE 15 Requirement Elicitation Techniques Interviews 1 Scenarios Prototypes Elicitation Facilitated meetings Techniques Task analysis User stories Introspection 2  Interviewing 1 Formal or informal interviews with stakeholders are part of most RE processes. Types of interview 1. Closed interviews based on pre-determined list of questions 2. Open interviews where there is no predefined agenda. Various issues are explored with stakeholders. Effective interviewing 1. Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders. 2. Prompt the interviewee to get discussions going using a requirements proposal, or by working together on a prototype system. 3 Scenarios 1 Scenarios are real-life examples of how a system can be used. They should include 1. A description of the starting situation; 2. A description of the normal flow of events; 3. A description of what can go wrong; 4. Information about other concurrent activities; 5. A description of the state when the scenario finishes. 4  Scenario for Collecting Medical History in MHC-PMS 1 5  Questionnaires-1 1 Questionnaires are mainly used during the early stages of requirements elicitation and may consist of open and/or closed questions. To be effective, the terms, concepts, and boundaries of the domain must be well established and understood by the participants and questionnaire designer. Questions must be focused to avoid gathering large amounts of redundant and irrelevant information. They provide an efficient way to collect information from multiple stakeholders quickly, but are limited in the depth of knowledge they are able to elicit. 6  Questionnaires-2 1 Survey questions of any type can be For example, some possible survey used. For example, questions can be questions for the pet store POS system are closed- (e.g., multiple choice, true-false) How many unique products (SKUs) do you or open-ended—involving free-form carry in your inventory? responses. a) 0-1000 b) 1001-10,000 c) 10,001-100,000 d) >100,000 Closed questions have the advantage of How many different warehouse sites do easier coding for analysis, and they help you have? ____ to bound the scope of the system. How many different store locations do you Open questions allow for more freedom have? ____ and innovation, but can be harder to How many unique customers do you analyze. currently have? ____ 7  Task Analysis 1 Task analysis employs a top-down approach where high-level tasks are decomposed into subtasks and eventually detailed sequences until all actions and events are described. The primary objectives of this technique is to construct a hierarchy of the tasks performed by the users and the system, and determine the knowledge used or required to carry them out. Task analysis provides information on the interactions of both the user and the system with respect to the tasks as well as a contextual description of the activities that take place. 8  Partial task analysis for the pet store POS system 1 9  Introspection 1 The technique of introspection requires the analyst to develop requirements based on what he or she believes the users and other stakeholders want and need from the system. This technique is mainly used only as a starting point for other requirements elicitation efforts. Introspection is only effective when the analyst is not only very familiar with the domain and goals of the system, but also expert in the business processes performed by the users. In cases where the analyst is forced to use this technique more, for example when the users have little or no previous experience with software systems in their work environment, a type of facilitation introspection should take place via other elicitation techniques such as interviews. 10  Card Sorting-1 1 This technique involves having stakeholders complete a set of cards that includes key information about functionality for the system. It is also a good idea for the stakeholders/customers to include ranking and justification for each of the functionalities. Giving stakeholders too much time, however, can slow the process unnecessarily. It is recommended that a minimum of one week (and no more than two weeks) be allowed for the completion of the cards. 11  Card Sorting-2 1 In any case, after each session of card generation the requirements engineer organizes these cards in some manner, generally clustering the functionalities logically. These clusters form the bases of the requirements set. The customer can be shown this sorted list of functionalities for correction or missing features. Then, a new round of cards can be generated if necessary. The process continues until the requirements engineer and customer are satisfied that the system features are substantially captured. 12 A tiny subset of the unsorted cards generated by customers for the pet 1 Sorted cards for the pet store POS system. store POS system 13 Laddering In laddering, the requirements engineer asks the customer short prompting questions (“probes”) to elicit1 requirements. Follow-up questions are then posed to dig deeper below the surface. The resultant information from the responses is then organized into a tree-like structure. RE: Name a key feature of the system? Customer: Customer identification. RE: How do you identify a customer? Customer: They can swipe their loyalty card. RE: What if a customer forgets their card? Customer: They can be looked up by phone number. RE: When do you get the customer’s phone number? Customer: When customers complete the application for the loyalty card. RE: How do customers complete the applications? … 14  Ethnography People often find it very difficult to explain1 how they carry out their routine tasks and how they work together in particular situation. 1. How to tie a shoelace? 2. Difficult to describe but easy to demonstrate process People do not have to explain or articulate their work. Observation is a better way of understanding this type of tasks to understand what support people need from a computer-based system Ethnography is an observational technique that can be used to understand operational processes and help derive requirements for these processes. A social scientist spends a considerable time observing and analysing how people actually work. For example observing workers in a bank to understand their everyday work and hence derive requirements for computer support. 15 Requirement Analysis 1  Analyze requirements to:  detect and resolve conflicts between requirements;  discover the bounds of the software and how it must interact with its environment  elaborate system requirements to derive software requirements  Requirements analysis process:  Use one of a number of analysis methods  Classify requirements 16  1 17 Identifying Needs & Capturing User Requirements LECTURE 16 Requirement Analysis 1  Analyze requirements to:  detect and resolve conflicts between requirements;  discover the bounds of the software and how it must interact with its environment  elaborate system requirements to derive software requirements  Requirements analysis process:  Use one of a number of analysis methods  Classify requirements 2 Requirement Analysis 1  Requirements classification to identify:  Process requirements or product requirements  Functional and non-functional requirements  High-level requirements or an emergent requirements  Requirement priority  Scope of the requirement  Other characteristics of the requirement 3 Requirement Analysis use case diagrams 1 data flow models state models Conceptual goal-based models Models user interactions object models data models others 4 Requirement Analysis 1  How to choose a model?  The nature of the problem  The expertise of the software engineer  The process requirements of the customer  It is useful to start by building a model of the software context  To identify the intended software interfaces with the environment 5 Software Requirements Specification 1  Software requirements specification  establishes the basis for agreement between customers and contractors or suppliers on what the software product is to do as well as what it is not expected to do  permits a rigorous assessment of requirements before design can begin and reduces later redesign  can be used as the basis for developing effective verification and validation plan  provides an informed basis for transferring a software product to new users or software platforms  can provide a basis for software enhancement. 6 Software Requirements Specification  Commitment 1  Commitment is the degree of obligation of meeting the requirement.  The commitment is defined through key words: “must”, “will”, “should”, “would”, “could”.  Examples: ◼ “The system should […]”  Key words “must”, “will”, “should”, “would”, “could” relate to business and user requirements before agreement.  After agreement and baselining the requirements’ key words should determine the degree of obligation in strict way: ◼ The system will...  In some cases the requirement is described with both degree of obligation and a priority: ◼ The system will… [priority = high] ◼ The system will… [priority = medium] ◼ The system will… [priority = low] 7 Ways of Writing Requirements Specification 1 Notation Description Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured natural The requirements are written in natural language on a standard form or template. language Each field provides information about an aspect of the requirement. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical These notations are based on mathematical concepts such as finite-state machines specifications or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract 8  Example Requirements for the Insulin Pump Software System 1 3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.) 3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.) 9  TYPES OF SPECIFICATIONS 1 1- Structured Specifications An approach to writing requirements where the freedom of the requirements writer is limited, and requirements are written in a standard way. This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements. 10  Structured Specifications 1 1. Definition of the function. 2. Description of inputs and where they come from. 3. Description of outputs and where they go to. 4. Description of the action to be taken. 5. Pre and post conditions (if appropriate). 6. The side effects (if any) of the function. 11  A Structured Specification of a Requirement for an Insulin Pump 1 12  A Structured Specification of a Requirement for an Insulin Pump 1 13 2- Tabular Specification 1 1. Used to supplement natural language. 2. Particularly useful when you have to define a number of possible alternative courses of action. 3. For example, the insulin pump systems bases its computations on the rate of change of blood sugar level and the tabular specification explains how to calculate the insulin requirement for different scenarios. 14  Tabular Specification of Computation for an Insulin Pump 1 Condition Action Sugar level falling (r2 < r1) CompDose = 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of CompDose = 0 increase decreasing ((r2 – r1) < (r1 – r0)) Sugar level increasing and rate of CompDose = increase stable or increasing round ((r2 – r1)/4) ((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then CompDose = MinimumDose 15  Software Requirements Specification  Quality criteria for requirements (IEEE 830 and IEEE 1233), 1 each requirement must be:  Correct – the requirement must accurately describe the functionality to be provided.  Feasible – the requirement must be possible to implement within the known capabilities and/or limitations of the system and the environment.  Necessary – the requirement should document what the customer (or other stakeholders) really need.  Prioritized – the requirement should have a priority assigned indicating how essential it is for a particular product release.  Unambiguous – the requirement should be interpreted only in one way. Different readers of a requirement should have the same interpretation and understanding of a requirement.  Verifiable – the requirement should be possible to verify if it is implemented correctly. 16 Software Requirements Specification 1  Quality criteria for requirements (IEEE 830 and IEEE 1233), requirements specification must be:  Complete – no requirements or necessary information should be missing in the requirements specification.  Consistent – the requirement cannot conflict with other requirements or with higher level (system or business) requirements.  Modifiable – the specification must allow introducing changes in the requirements. A history of changes made to each requirement should be maintained.  Traceable – each requirement should be possible to link to its source (for example, a higher-level system requirement a use case, or a customer’s statement) and related implementation artifacts (for example, design elements, source code, and test cases). 17  1 18 Identifying Needs & Capturing User Requirements LECTURE 17  Requirements Validation 1 Requirements validation is the process of checking that requirements actually define the system that the customer really wants. Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. 2  Requirements Validation Checking 1 Validity 1. Does the system provide the functions which best support the customer’s needs? 2. A user may think that a system is needed to perform certain functions. However, further analysis may identify additional or different functions that are required Consistency 1. Requirements in the document should not conflict. 2. That is, there should not be contradictory constraints or different descriptions of the same system function. Completeness 1. The requirements document should include requirements that define all functions and the constraints intended by the system user. 3  Requirements Validation Checking 1 Realism Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented. These checks should also take account of the budget and schedule for the system development. Verifiability To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement. 4 Requirements Validation Techniques 1 Requirements reviews 1. The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies. 2. Both client and contractor staff should be involved in reviews. Prototyping 1. Using an executable model of the system to check requirements. 2. Client can experiment with this model to see if it meets their real needs. Test-case generation 1. Developing tests for requirements to check testability. 2. If a test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered. 5  Requirements Validation Example of requirements validation checklist 1 Are requirements stated clearly? Can they be misinterpreted? Is the source (e.g., a person, a regulation, a document) of the requirement identified? Has the final statement of the requirement been examined by or against the original source? What other requirements relate to this requirements? Are they clearly noted via a cross- reference matrix or other mechanism? Does the requirement violate any system domain constraints? Is the requirement testable? Is the requirement traceable to any system model that has been created? Is the requirement traceable to overall system/product objectives? Is the specification structured in a way that leads to easy understanding, easy reference, and easy translation into more technical work products? 6  1 7 Identifying Needs & Capturing User Requirements LECTURE 12  1 2 What is a Requirement? 1 Requirement (ISO/IEC 29148:2011): statement which translates or expresses a need and its associated constraints and conditions ▪ It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. ▪ The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. 3 What is a Requirement? 1 Requirements may serve a dual function 1. May be the basis for a bid for a contract - therefore must be open to interpretation; 2. May be the basis for the contract itself - therefore must be defined in detail; 3. Both these statements may be called requirements. 4  Requirements completeness and consistency 1 In principle, requirements should be both complete and consistent. 1. Complete They should include descriptions of all functionality required. 2. Consistent There should be no conflicts or contradictions in the descriptions of the system facilities. In practice, it is impossible to produce a complete and consistent requirements document. 5 Ironic Example Dear Architect, 1 Please design and build me a house. I am not sure of what I need, so you should use your discretion. My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one. Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don’t have nearly enough insulation in them). PS: My wife has just told me that she disagrees with many of the instructions, I’ve given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can’t handle this responsibility, I will have to find another architect. 6  Activity  Develop the Tic-Tac-Toe game.  The grid can be 3x3, 5x5, or 7x7 1  This must be a Mobile APP  The APP runs on Android Platform  The Game can be played by 2 players online/offline or with the computer. Computer Agent must use RL to learn the game.  UI is dynamic, user can change background, colors, …  Game can be played thru voice/eye  Player scores are saved on the google cloud  Ads enabled  …. Do you think now that Tic-Tac-Toe is an easy App? 7 Requirements Engineering  ISO/IEC/IEEE Systems and Software Engineering 1 Vocabulary (SEVOCAB) defines  Software Requirements: complete description of features/functions of the target system.  Requirements Engineering: The process of gathering, analyzing, and documenting requirements from the client. The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. “Requirements engineering establishes a solid “The hardest single part base for design and construction. Without it, of building a software the resulting software has a high probability system is deciding what to of not meeting customer’s needs” build” Roger S. Pressman Fred Brooks 8 Requirements Engineering 1 RE (ISO/IEC 29148:2011): interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software or service of interest RE is concerned with: discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting, and managing requirements 9  WHY RE? 1 10 WHY RE? Standish Group Chaos Report 2015 1 11 WHY RE?  When the IT project is cancelled: 1  Waste of time, budget and resources  When the IT project is challenged:  Requirements are not fully met, the implemented solution does not meet the business user expectations  Milestones not met, planning slips, behind the schedule, go-live date postponed 1, 2, n times  Project over initial budget 12  WHY RE? 1 13  WHY RE? 1 14  WHY RE? 1  TOP 10 Reasons why RE is not done: ① 10. We don't need requirements ② 9. The users don't know what they want ③ 8. We already know what the users want ④ 7. Who cares what the users want? ⑤ 6. We don't have time to do requirements ⑥ 5. It's too hard to do requirements ⑦ 4. My boss frowns when I write requirements ⑧ 3. The problem is too complex to write requirements ⑨ 2. It's easier to change the system later ⑩ 1. We have already started writing code: we don't want to spoil it 15 Software Requirements is the base 1 Software Quality Software Testing Software Architecture Software Requirements and Design Software Maintenance Software Engineering 16 Types of Requirement 1 1. User Requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. 2. System Requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. 17 Types of Requirement 1 18 Types of Requirement constraint on the 1 development of the software Development requirements Functional What the software Requirements requirements does? Product requirements Non-functional How good the software a need or constraint requirements does something? on the software to be developed 19 Types of Requirement 1 They describe the functions that the software is to execute; for example, Functional requirements formatting some text or modulating a signal. They are sometimes known as constraints Non-functional requirements or quality requirements. 20 Types of Requirement 1 1. Functional Requirements Statements of services the system should provide, how the system should react to inputs and how the system should behave in particular situations. 2. Non-Functional Requirements a. Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. b. Often apply to the system as a whole rather than individual features or services. 21  1 22 Identifying Needs & Capturing User Requirements LECTURE 13 Types of Requirement 1. User Requirements 1 Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. 2. System Requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. User requirements define the results and qualities the user wants; system requirements define what the system must do to achieve this. User requirements are owned by the users, whereas system requirements are owned by the developers. 2 Types of Requirement 1 3 Types of Requirement constraint on the 1 development of the software Development requirements Functional What the software Requirements requirements does? Product requirements Non-functional How good the software a need or constraint requirements does something? on the software to be developed 4 Types of Requirement 1 They describe the functions that the software is to execute; for example, Functional requirements formatting some text or modulating a signal. They are sometimes known as constraints Non-functional requirements or quality requirements. 5 Types of Requirement 1 1. Functional Requirements Statements of services the system should provide, how the system should react to inputs and how the system should behave in particular situations. 2. Non-Functional Requirements a. Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. b. Often apply to the system as a whole rather than individual features or services. 6  Functional Requirements 1 1. Describe functionality or system services. 2. Depend on the type of software, expected users and the type of system where the software is used. 3. When expressed as user requirements, functional requirements are usually described in an abstract way that can be understood by system users. 4. More specific functional system requirements describe the system functions, its inputs and outputs, exceptions, etc., in detail. 7  Functional Requirements for the MHC- 1 PMS 1. A user shall be able to search the appointments lists for all clinics. 2. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. 3. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number. 8  Non-Functional Requirements 1. These define system properties and 1constraints ▪ System properties such as reliability, response time and storage requirements. ▪ Constraints on system implementation, such as I/O device capability, processor speed, network bandwidth, data representation used in interfaces with other systems 2. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. 9  Non-Functional Classifications 1 1. Product requirements ▪ Requirements which specify that the delivered product must behave in a particular way e.g., execution speed, reliability, etc. 2. Organisational requirements ▪ Requirements which are a consequence of organisational policies and procedures e.g., process standards used, development process requirements (programming language) operational requirements (how the system will be used), etc. 3. External requirements ▪ Requirements which arise from factors which are external to the system and its development process e.g., regulatory requirements (such as a central bank;), legislative requirements (ensure that the system operates within the law), etc. 10  Types of Non-Functional Requirements 1 Non-functional requirements Organizational Product requirements External requirements requirements Usability requirements Delivery Legal requirements Reliability requirements constraints implementation Safety requirements Economic requirements constraints standards Efficiency requirements Interoperability requirements requirements Performance requirements Capacity requirements 11  Examples of Non-Functional Requirements in the MHC-PMS 1 Product requirement The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement Users of the MHC-PMS system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan-03-2006-priv. 12 Non-Functional Requirements Implementation 1 ▪ Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components. ▪ A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. 13 Usability Requirements 1 1. The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal) 2. Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non- functional requirement) 14  Metrics for Specifying Non-Functional Requirements 1 Property Measure Performance Processed transactions/second User/event response time Screen refresh time Capacity Mbytes Ease of use Training time Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Portability Percentage of target dependent statements Number of target systems 15  1 16 Identifying Needs & Capturing User Requirements LECTURE 14  Metrics for Specifying Non-Functional Requirements 1 Property Measure Performance Processed transactions/second User/event response time Screen refresh time Capacity Mbytes Ease of use Training time Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Portability Percentage of target dependent statements Number of target systems 2 Requirement Elicitation  Requirements elicitation is: 1  concerned with the origins of software requirements and how the software engineer can collect them  the first stage in building an understanding of the problem the software is required to solve  fundamentally a human activity  where the stakeholders are identified, and relationships established between the development team and the customer. requirements requirements requirements capture discovery acquisition 3 Requirements Elicitation 1 software engineers work with customers and system end- users to find out about the application domain, what services the system should provide, the required performance of the system, and hardware constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, etc. These are called stakeholders. 4 Requirement Elicitation 1  One of the fundamental principles of a good requirements elicitation process is that of effective communication between the various stakeholders.  A critical element of requirements elicitation is informing the project scope.  A description of the software being specified  The purpose of the software  The Deliverables 5  No registration CEOs, if not paid Executives, etc. 1 Time/schedule Experts limitations Stakeholders Business rules in the domain The Domain operational knowledge environment Use IOs platform The Requirements Goals organizational sources environment 6  Goals Domain knowledge “Goal” (“business concern” or “critical Domain knowledge provides the 1 success factor”) refers to the overall background against which all elicited objectives of the software. Goals provide requirements knowledge must be set in the motivation for the software but are order to understand it. often vaguely formulated. The software engineer needs to acquire Software engineers need to pay particular or have available knowledge about the attention to assessing the value and cost application domain. of goals. Stakeholders Much software has proved unsatisfactory because it has stressed the requirements of one group of stakeholders at the expense of others. Hence, the delivered software is difficult to use, or subverts the cultural or political structures of the customer organization. The software engineer needs to identify, represent, and manage the “viewpoints” of many different types of stakeholders 7 Business rules These are statements that define or constrain The operational environment 1 some aspect of the structure or the behavior of Requirements will be derived from the the business itself. environment in which the software will be “A student cannot register in next semester’s executed. These may be, for example, timing courses if there remain some unpaid tuition constraints in real-time software. fees” would be an example of a business rule These must be sought out actively because that would be a requirement source for a they can greatly affect software feasibility university’s course-registration software. and cost as well as restrict design choices. The organizational environment Software is often required to support a business process, the selection of which may be conditioned by the structure, culture, and internal politics of the organization. The software engineer needs to be sensitive to these since, in general, new software should not force unplanned change on the business process. 8 Requirement Elicitation 1  Once the requirements sources have been identified, the software engineer can start eliciting requirements from them. It can be very difficult, in fact users:  may have difficulty describing their tasks  May leave important information unstated  May be unwilling or unable to cooperate.  The software engineer should identify the known, unknown and unknowable using elicitation techniques. 9  Understanding the Application Domain 1 Identifying the Sources of Requirements Requirements Elicitation Analysing the Stakeholders Process Selecting the Techniques, Approaches, and Tools to Use Eliciting the Requirements from Stakeholders and Other Sources 10  1-Understanding the Application Domain 1 1. Investigate and examine in detail the situation or “real world” in which the system will ultimately reside (sometimes called the application domain) 2. The current environment needs to be thoroughly explored including the political, organizational, and social aspects related to the system. 3. Existing work processes and the related problems to be solved by the system need to be described with respect to the key business goals and issues. 11  2-Identifying the Sources of Requirements Requirements may be spread across many sources 1 and exist in a variety of formats Stakeholders represent the most obvious source of requirements for the system. Users and subject matter experts are used to supply detailed information about the problems and user needs. Existing systems and processes represent another source for eliciting requirements, particularly when the project involves replacing a current system. Existing documentation about the current systems and business processes including manuals, forms, and reports can provide useful information about the organization and environment, as well as requirements for the new system and their supporting rationale and importance 12  3-Analyzing the Stakeholders 1 1. Stakeholders are people who have an interest in the system or are affected in some way by the development and implementation of the system. 2. The customer, and more specifically the project sponsor, is usually the most apparent stakeholder of the system. 3. One of the first steps in requirements elicitation therefore is to analyze and involve all the relevant stakeholders. 4. In some cases, however the actual users of the system may be the most important. 5. Process of analyzing the stakeholders also often includes the identification of key user representatives and product champions. 13 4-Selecting the Techniques, Approaches, and Tools to Use 1 It is generally accepted that an individual requirements elicitation technique or approach cannot possibly be suitable for all projects. The choice of techniques to be employed is dependent on the specific context of the project and is often a critical factor in the success of the elicitation process. Elicitation technique may be selected for a variety of reasons. (a) the technique selected is the only one the analyst knows, (b) the technique selected is the analyst’s favorite, In the majority of projects several methods are employed during and at different stages in the software development life cycle. 14 5-Eliciting the Requirements from Stakeholders and Other Sources 1 1. Once the sources of requirements and the specific stakeholders have been identified, the actual elicitation of the core requirements then begins using the selected elicitation techniques, approaches, and tools. 2. During this activity it is important to establish the level of scope for the system and investigate in detail the needs and wants of the stakeholders, especially the users. 3. It is also essential to determine the future processes the system will perform with respect to the business operations and examine the ways in which the system may support them in order to satisfy the major objectives and address the key problems of the business. 15 Requirement Elicitation Techniques Interviews 1 Scenarios Prototypes Elicitation Facilitated meetings Techniques Task analysis User stories Introspection 16  1 17