《软件工程概论》课程教学资源（参考资料）Guide to the Software Engineering Body of Knowledge（SWEBOK）Version 3.0

1-2 SWEBOK Guide V3.0 Software Requirements Sollware Requirements Requirements Requirements Requirements Requirements Software Requircments Pracrical Fundameatals Process Elieitation Analysis Specification Validation Considerations Requirememts Tools Definition of a System erative Nature Softaure Process Models Requirements Kequrements Definition Requirements Requirement Sources f the Classification Revicws Document Product and System Process Process Actors Techniques → Requirements Prototyping Change Requirements Specifieation Management Design and Model Kequtrements Allocation Process Quality Requirements and Tests Tracing Quantifiable Measuring Requirements Analysis Requirements System Requirements and Software Requirements Figure 1.1.Breakdown of Topics for the Software Requirements KA order to solve some problem in the real world.It requirements can be verified within available may aim to automate part of a task for someone resource constraints. to support the business processes of an organiza- Requirements have other attributes in addi- tion,to correct shortcomings of existing software. tion to behavioral properties.Common examples or to control a device-to name just a few of the include a priority rating to enable tradeoffs in many problems for which software solutions are the face of finite resources and a status value to possible.The ways in which users,business pro-enable project progress to be monitored.Typi- cesses,and devices function are typically complex.cally,software requirements are uniquely identi- By extension,therefore,the requirements on par-fied so that they can be subjected to software con- ticular software are typically a complex combina-figuration management over the entire life cycle tion from various people at different levels of an of the feature and of the software. organization,and who are in one way or another involved or connected with this feature from the 1.2.Product and Process Requirements environment in which the software will operate. An essential property of all software require- A product requirement is a need or constraint on ments is that they be verifiable as an individual the software to be developed (for example,"The feature as a functional requirement or at the software shall verify that a student meets all pre- system level as a nonfunctional requirement.It requisites before he or she registers for a course"). may be difficult or costly to verify certain soft- A process requirement is essentially a con- ware requirements.For example,verification straint on the development of the software (for of the throughput requirement on a call center example,"The software shall be developed using may necessitate the development of simulation a RUP process"). software.Software requirements,software test- Some software requirements generate implicit ing,and quality personnel must ensure that the process requirements.The choice of verification

1-2 SWEBOK® Guide V3.0 order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organiza￾tion, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible. The ways in which users, business pro￾cesses, and devices function are typically complex. By extension, therefore, the requirements on par￾ticular software are typically a complex combina￾tion from various people at different levels of an organization, and who are in one way or another involved or connected with this feature from the environment in which the software will operate. An essential property of all software require￾ments is that they be verifiable as an individual feature as a functional requirement or at the system level as a nonfunctional requirement. It may be difficult or costly to verify certain soft￾ware requirements. For example, verification of the throughput requirement on a call center may necessitate the development of simulation software. Software requirements, software test￾ing, and quality personnel must ensure that the requirements can be verified within available resource constraints. Requirements have other attributes in addi￾tion to behavioral properties. Common examples include a priority rating to enable tradeoffs in the face of finite resources and a status value to enable project progress to be monitored. Typi￾cally, software requirements are uniquely identi￾fied so that they can be subjected to software con￾figuration management over the entire life cycle of the feature and of the software. 1.2. Product and Process Requirements A product requirement is a need or constraint on the software to be developed (for example, “The software shall verify that a student meets all pre￾requisites before he or she registers for a course”). A process requirement is essentially a con￾straint on the development of the software (for example, “The software shall be developed using a RUP process”). Some software requirements generate implicit process requirements. The choice of verification Figure 1.1. Breakdown of Topics for the Software Requirements KA

Software Requirements 1-3 technique is one example.Another might be the depend for their interpretation on subjective use of particularly rigorous analysis techniques judgment ("the software shall be reliable";"the (such as formal specification methods)to reduce software shall be user-friendly").This is par- faults that can lead to inadequate reliability.Pro- ticularly important for nonfunctional require- cess requirements may also be imposed directly ments.Two examples of quantified requirements by the development organization,their customer,are the following:a call center's software must or a third party such as a safety regulator. increase the center's throughput by 20%;and a system shall have a probability of generating a 1.3.Functional and Nonfunctional Requirements fatal error during any hour of operation of less than 1 *10-.The throughput requirement is at a Functional requirements describe the functions very high level and will need to be used to derive that the software is to execute;for example,for-a number of detailed requirements.The reliabil- matting some text or modulating a signal.They ity requirement will tightly constrain the system are sometimes known as capabilities or features. architecture. A functional requirement can also be described as one for which a finite set of test steps can be 1.6.System Requirements and Software written to validate its behavior. Requirements Nonfunctional requirements are the ones that act to constrain the solution.Nonfunctional In this topic,.“system”means requirements are sometimes known as constraints or quality requirements.They can be further clas- an interacting combination of elements sified according to whether they are performance to accomplish a defined objective.These requirements,maintainability requirements. include hardware,software,firmware, safety requirements,reliability requirements, people,information,techniques,facilities, security requirements,interoperability require- services,and other support elements, ments or one of many other types of software requirements (see Models and Quality Character- as defined by the International Council on Soft- istics in the Software Quality KA). ware and Systems Engineering(INCOSE)[3]. System requirements are the requirements for 1.4.Emergent Properties the system as a whole.In a system containing software components,software requirements are Some requirements represent emergent proper- derived from system requirements. ties of software-that is,requirements that can- This KA defines“user requirements”ina not be addressed by a single component but that restricted way,as the requirements of the sys- depend on how all the software components tem's customers or end users.System require- interoperate.The throughput requirement for a ments,by contrast,encompass user requirements, call center would,for example,depend on how requirements of other stakeholders (such as regu- the telephone system,information system,and latory authorities).and requirements without an the operators all interacted under actual operat- identifiable human source. ing conditions.Emergent properties are crucially dependent on the system architecture. 2.Requirements Process [1*,c4s4][2*,cl-4,c6,c22,c23] 1.5.Quantifiable Requirements This section introduces the software requirements Software requirements should be stated as clearly process,orienting the remaining five topics and and as unambiguously as possible,and,where showing how the requirements process dovetails appropriate,quantitatively.It is important to with the overall software engineering process. avoid vague and unverifiable requirements that

Software Requirements 1-3 technique is one example. Another might be the use of particularly rigorous analysis techniques (such as formal specification methods) to reduce faults that can lead to inadequate reliability. Pro￾cess requirements may also be imposed directly by the development organization, their customer, or a third party such as a safety regulator. 1.3. Functional and Nonfunctional Requirements Functional requirements describe the functions that the software is to execute; for example, for￾matting some text or modulating a signal. They are sometimes known as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior. Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements. They can be further clas￾sified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability requirements, security requirements, interoperability require￾ments or one of many other types of software requirements (see Models and Quality Character￾istics in the Software Quality KA). 1.4. Emergent Properties Some requirements represent emergent proper￾ties of software—that is, requirements that can￾not be addressed by a single component but that depend on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operat￾ing conditions. Emergent properties are crucially dependent on the system architecture. 1.5. Quantifiable Requirements Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague and unverifiable requirements that depend for their interpretation on subjective judgment (“the software shall be reliable”; “the software shall be user-friendly”). This is par￾ticularly important for nonfunctional require￾ments. Two examples of quantified requirements are the following: a call center’s software must increase the center’s throughput by 20%; and a system shall have a probability of generating a fatal error during any hour of operation of less than 1 * 10−8 . The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliabil￾ity requirement will tightly constrain the system architecture. 1.6. System Requirements and Software Requirements In this topic, “system” means an interacting combination of elements to accomplish a defined objective. These include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements, as defined by the International Council on Soft￾ware and Systems Engineering (INCOSE) [3]. System requirements are the requirements for the system as a whole. In a system containing software components, software requirements are derived from system requirements. This KA defines “user requirements” in a restricted way, as the requirements of the sys￾tem’s customers or end users. System require￾ments, by contrast, encompass user requirements, requirements of other stakeholders (such as regu￾latory authorities), and requirements without an identifiable human source. 2. Requirements Process [1*, c4s4] [2*, c1–4, c6, c22, c23] This section introduces the software requirements process, orienting the remaining five topics and showing how the requirements process dovetails with the overall software engineering process

1-4 SWEBOK®Guide V3.0 2.1.Process Models marketing people are often needed to estab- lish what the market needs and to act as The objective of this topic is to provide an under- proxy customers. standing that the requirements process Regulators:Many application domains,such as banking and public transport,are regu- is not a discrete front-end activity of the soft- lated.Software in these domains must com- ware life cycle.but rather a process initiated ply with the requirements of the regulatory at the beginning of a project that continues to authorities. be refined throughout the life cycle; Software engineers:These individuals have identifies software requirements as configu- a legitimate interest in profiting from devel- ration items and manages them using the oping the software by,for example,reusing same software configuration management components in or from other products.If, practices as other products of the software in this scenario,a customer of a particu- life cycle processes; lar product has specific requirements that needs to be adapted to the organization and compromise the potential for component project context. reuse,the software engineers must carefully weigh their own stake against those of the In particular,the topic is concerned with how customer.Specific requirements,particu- the activities of elicitation,analysis,specifica- larly constraints,may have major impact on tion,and validation are configured for different project cost or delivery because they either types of projects and constraints.The topic also fit well or poorly with the skill set of the includes activities that provide input into the engineers.Important tradeoffs among such requirements process,such as marketing and fea- requirements should be identified. sibility studies. It will not be possible to perfectly satisfy the 2.2.Process Actors requirements of every stakeholder,and it is the software engineer's job to negotiate tradeoffs that This topic introduces the roles of the people who are both acceptable to the principal stakeholders participate in the requirements process.This pro-and within budgetary,technical,regulatory,and cess is fundamentally interdisciplinary,and the other constraints.A prerequisite for this is that all requirements specialist needs to mediate between the stakeholders be identified,the nature of their the domain of the stakeholder and that of soft- "stake"analyzed,and their requirements elicited. ware engineering.There are often many people involved besides the requirements specialist,each 2.3.Process Support and Management of whom has a stake in the software.The stake- holders will vary across projects,but will always This section introduces the project management include users/operators and customers(who need resources required and consumed by the require- not be the same). ments process.It establishes the context for the Typical examples of software stakeholders first topic(Initiation and Scope Definition)of the include(but are not restricted to)the following: Software Engineering Management KA.Its prin- cipal purpose is to make the link between the pro- Users:This group comprises those who will cess activities identified in 2.1 and the issues of operate the software.It is often a heteroge-cost,human resources,training,and tools. neous group involving people with different roles and requirements. 2.4.Process Ouality and Improvement Customers:This group comprises those who have commissioned the software or who rep-This topic is concerned with the assessment of resent the software's target market. the quality and improvement of the requirements Market analysts:A mass-market product process.Its purpose is to emphasize the key role will not have a commissioning customer,so the requirements process plays in terms of the

1-4 SWEBOK® Guide V3.0 2.1. Process Models The objective of this topic is to provide an under￾standing that the requirements process • is not a discrete front-end activity of the soft￾ware life cycle, but rather a process initiated at the beginning of a project that continues to be refined throughout the life cycle; • identifies software requirements as configu￾ration items and manages them using the same software configuration management practices as other products of the software life cycle processes; • needs to be adapted to the organization and project context. In particular, the topic is concerned with how the activities of elicitation, analysis, specifica￾tion, and validation are configured for different types of projects and constraints. The topic also includes activities that provide input into the requirements process, such as marketing and fea￾sibility studies. 2.2. Process Actors This topic introduces the roles of the people who participate in the requirements process. This pro￾cess is fundamentally interdisciplinary, and the requirements specialist needs to mediate between the domain of the stakeholder and that of soft￾ware engineering. There are often many people involved besides the requirements specialist, each of whom has a stake in the software. The stake￾holders will vary across projects, but will always include users/operators and customers (who need not be the same). Typical examples of software stakeholders include (but are not restricted to) the following: • Users: This group comprises those who will operate the software. It is often a heteroge￾neous group involving people with different roles and requirements. • Customers: This group comprises those who have commissioned the software or who rep￾resent the software’s target market. • Market analysts: A mass-market product will not have a commissioning customer, so marketing people are often needed to estab￾lish what the market needs and to act as proxy customers. • Regulators: Many application domains, such as banking and public transport, are regu￾lated. Software in these domains must com￾ply with the requirements of the regulatory authorities. • Software engineers: These individuals have a legitimate interest in profiting from devel￾oping the software by, for example, reusing components in or from other products. If, in this scenario, a customer of a particu￾lar product has specific requirements that compromise the potential for component reuse, the software engineers must carefully weigh their own stake against those of the customer. Specific requirements, particu￾larly constraints, may have major impact on project cost or delivery because they either fit well or poorly with the skill set of the engineers. Important tradeoffs among such requirements should be identified. It will not be possible to perfectly satisfy the requirements of every stakeholder, and it is the software engineer’s job to negotiate tradeoffs that are both acceptable to the principal stakeholders and within budgetary, technical, regulatory, and other constraints. A prerequisite for this is that all the stakeholders be identified, the nature of their “stake” analyzed, and their requirements elicited. 2.3. Process Support and Management This section introduces the project management resources required and consumed by the require￾ments process. It establishes the context for the first topic (Initiation and Scope Definition) of the Software Engineering Management KA. Its prin￾cipal purpose is to make the link between the pro￾cess activities identified in 2.1 and the issues of cost, human resources, training, and tools. 2.4. Process Quality and Improvement This topic is concerned with the assessment of the quality and improvement of the requirements process. Its purpose is to emphasize the key role the requirements process plays in terms of the

Software Requirements 1-5 cost and timeliness of a software product and of to ensure the customer's most important business the customer's satisfaction with it.It will help to needs are satisfied first.This minimizes the risk orient the requirements process with quality stan- of requirements specialists spending time elicit- dards and process improvement models for soft- ing requirements that are of low importance.or ware and systems.Process quality and improve- those that turn out to be no longer relevant when ment is closely related to both the Software the software is delivered.On the other hand.the Quality KA and Software Engineering Process description must be scalable and extensible to KA,comprising accept further requirements not expressed in the first formal lists and compatible with the previous requirements process coverage by process ones as contemplated in recursive methods. improvement standards and models; ·requirements process measures and 3.1.Requirements Sources benchmarking: improvement planning and implementation; Requirements have many sources in typical soft- ·security/CIA improvement/planning and ware,and it is essential that all potential sources implementation. be identified and evaluated.This topic is designed to promote awareness of the various sources of 3.Requirements Elicitation software requirements and of the frameworks for [1*,c4s5][2*,c5,c6,c9] managing them.The main points covered are as follows: Requirements elicitation is concerned with the origins of software requirements and how the ·Goals..The term“goal”(sometimes called software engineer can collect them.It is the first “business concern”or“critical success fac stage in building an understanding of the problem tor")refers to the overall,high-level objec- the software is required to solve.It is fundamen- tives of the software.Goals provide the moti- tally a human activity and is where the stakehold- vation for the software but are often vaguely ers are identified and relationships established formulated.Software engineers need to pay between the development team and the customer. particular attention to assessing the value It is variously termed "requirements capture," (relative to priority)and cost of goals.A fea- “requirements discovery,”and“requirements sibility study is a relatively low-cost way of acquisition.” doing this. One of the fundamental principles of a good Domain knowledge.The software engineer requirements elicitation process is that of effec- needs to acquire or have available knowl- tive communication between the various stake- edge about the application domain.Domain holders.This communication continues through knowledge provides the background against the entire Software Development Life Cycle which all elicited requirements knowledge (SDLC)process with different stakeholders at must be set in order to understand it.It's different points in time.Before development a good practice to emulate an ontological begins,requirements specialists may form the approach in the knowledge domain.Rela- conduit for this communication.They must medi- tions between relevant concepts within the ate between the domain of the software users(and application domain should be identified. other stakeholders)and the technical world of the Stakeholders (see section 2.2,Process software engineer.A set of internally consistent Actors).Much software has proved unsat- models at different levels of abstraction facilitate isfactory because it has stressed the require- communications between software users/stake- ments of one group of stakeholders at the holders and software engineers. expense of others.Hence,the delivered A critical element of requirements elicitation is software is difficult to use,or subverts the informing the project scope.This involves provid- cultural or political structures of the cus- ing a description of the software being specified tomer organization.The software engineer and its purpose and prioritizing the deliverables needs to identify,represent,and manage

Software Requirements 1-5 cost and timeliness of a software product and of the customer’s satisfaction with it. It will help to orient the requirements process with quality stan￾dards and process improvement models for soft￾ware and systems. Process quality and improve￾ment is closely related to both the Software Quality KA and Software Engineering Process KA, comprising • requirements process coverage by process improvement standards and models; • requirements process measures and benchmarking; • improvement planning and implementation; • security/CIA improvement/planning and implementation. 3. Requirements Elicitation [1*, c4s5] [2*, c5, c6, c9] Requirements elicitation is concerned with the origins of software requirements and how the software engineer can collect them. It is the first stage in building an understanding of the problem the software is required to solve. It is fundamen￾tally a human activity and is where the stakehold￾ers are identified and relationships established between the development team and the customer. It is variously termed “requirements capture,” “requirements discovery,” and “requirements acquisition.” One of the fundamental principles of a good requirements elicitation process is that of effec￾tive communication between the various stake￾holders. This communication continues through the entire Software Development Life Cycle (SDLC) process with different stakeholders at different points in time. Before development begins, requirements specialists may form the conduit for this communication. They must medi￾ate between the domain of the software users (and other stakeholders) and the technical world of the software engineer. A set of internally consistent models at different levels of abstraction facilitate communications between software users/stake￾holders and software engineers. A critical element of requirements elicitation is informing the project scope. This involves provid￾ing a description of the software being specified and its purpose and prioritizing the deliverables to ensure the customer’s most important business needs are satisfied first. This minimizes the risk of requirements specialists spending time elicit￾ing requirements that are of low importance, or those that turn out to be no longer relevant when the software is delivered. On the other hand, the description must be scalable and extensible to accept further requirements not expressed in the first formal lists and compatible with the previous ones as contemplated in recursive methods. 3.1. Requirements Sources Requirements have many sources in typical soft￾ware, and it is essential that all potential sources be identified and evaluated. This topic is designed to promote awareness of the various sources of software requirements and of the frameworks for managing them. The main points covered are as follows: • Goals. The term “goal” (sometimes called “business concern” or “critical success fac￾tor”) refers to the overall, high-level objec￾tives of the software. Goals provide the moti￾vation for the software but are often vaguely formulated. Software engineers need to pay particular attention to assessing the value (relative to priority) and cost of goals. A fea￾sibility study is a relatively low-cost way of doing this. • Domain knowledge. The software engineer needs to acquire or have available knowl￾edge about the application domain. Domain knowledge provides the background against which all elicited requirements knowledge must be set in order to understand it. It’s a good practice to emulate an ontological approach in the knowledge domain. Rela￾tions between relevant concepts within the application domain should be identified. • Stakeholders (see section 2.2, Process Actors). Much software has proved unsat￾isfactory because it has stressed the require￾ments 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 cus￾tomer organization. The software engineer needs to identify, represent, and manage

1-6 SWEBOK®Guide V.3.0 the "viewpoints"of many different types of has yet to be obtained from end users.The impor- stakeholders. tance of planning.verification,and validation in Business rules.These are statements that requirements elicitation cannot be overstated.A define or constrain some aspect of the struc- number of techniques exist for requirements elici- ture or the behavior of the business itself."A tation;the principal ones are these: student cannot register in next semester's courses if there remain some unpaid tuition Interviews.Interviewing stakeholders is a fees"would be an example of a business rule "traditional"means ofeliciting requirements. that would be a requirement source for a uni- It is important to understand the advantages versity's course-registration software. and limitations of interviews and how they The operational environment.Requirements should be conducted. will be derived from the environment in Scenarios.Scenarios provide a valuable which the software will be executed.These means for providing context to the elicita- may be,for example,timing constraints tion of user requirements.They allow the in real-time software or performance con- software engineer to provide a framework straints in a business environment.These for questions about user tasks by permitting must be sought out actively because they can s“what if”and "how is this done'”questions greatly affect software feasibility and cost as to be asked.The most common type of sce- well as restrict design choices. nario is the use case description.There is a The organizational environment.Software link here to topic 4.2(Conceptual Modeling) is often required to support a business pro- because scenario notations such as use case cess,the selection of which may be condi- diagrams are common in modeling software. tioned by the structure,culture,and internal Prototypes.This technique is a valuable tool politics of the organization.The software for clarifying ambiguous requirements.They engineer needs to be sensitive to these since, can act in a similar way to scenarios by pro- in general,new software should not force viding users with a context within which they unplanned change on the business process. can better understand what information they need to provide.There is a wide range of 3.2.Elicitation Techniques prototyping techniques-from paper mock- ups of screen designs to beta-test versions of Once the requirements sources have been iden- software products-and a strong overlap of tified,the software engineer can start eliciting their separate uses for requirements elicita- requirements information from them.Note that tion and for requirements validation (see requirements are seldom elicited ready-made. section 6.2,Prototyping).Low fidelity proto- Rather,the software engineer elicits information types are often preferred to avoid stakeholder from which he or she formulates requirements. “anchoring'”on minor,incidental character- This topic concentrates on techniques for getting istics of a higher quality prototype that can human stakeholders to articulate requirements- limit design flexibility in unintended ways. relevant information.It is a very difficult task and Facilitated meetings.The purpose of these the software engineer needs to be sensitized to the meetings is to try to achieve a summative fact that (for example)users may have difficulty effect,whereby a group of people can bring describing their tasks,may leave important infor- more insight into their software require- mation unstated,or may be unwilling or unable to ments than by working individually.They cooperate.It is particularly important to understand can brainstorm and refine ideas that may be that elicitation is not a passive activity and that, difficult to bring to the surface using inter- even if cooperative and articulate stakeholders are views.Another advantage is that conflicting available,the software engineer has to work hard requirements surface early on in a way that to elicit the right information.Many business or lets the stakeholders recognize where these technical requirements are tacit or in feedback that occur.When it works well,this technique

1-6 SWEBOK® Guide V3.0 the “viewpoints” of many different types of stakeholders. • Business rules. These are statements that define or constrain some aspect of the struc￾ture or the behavior of the business itself. “A student cannot register in next semester’s courses if there remain some unpaid tuition fees” would be an example of a business rule that would be a requirement source for a uni￾versity’s course-registration software. • The operational environment. Requirements will be derived from the environment in which the software will be executed. These may be, for example, timing constraints in real-time software or performance con￾straints in a business environment. These must be sought out actively because they can greatly affect software feasibility and cost as well as restrict design choices. • The organizational environment. Software is often required to support a business pro￾cess, the selection of which may be condi￾tioned 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. 3.2. Elicitation Techniques Once the requirements sources have been iden￾tified, the software engineer can start eliciting requirements information from them. Note that requirements are seldom elicited ready-made. Rather, the software engineer elicits information from which he or she formulates requirements. This topic concentrates on techniques for getting human stakeholders to articulate requirements￾relevant information. It is a very difficult task and the software engineer needs to be sensitized to the fact that (for example) users may have difficulty describing their tasks, may leave important infor￾mation unstated, or may be unwilling or unable to cooperate. It is particularly important to understand that elicitation is not a passive activity and that, even if cooperative and articulate stakeholders are available, the software engineer has to work hard to elicit the right information. Many business or technical requirements are tacit or in feedback that has yet to be obtained from end users. The impor￾tance of planning, verification, and validation in requirements elicitation cannot be overstated. A number of techniques exist for requirements elici￾tation; the principal ones are these: • Interviews. Interviewing stakeholders is a “traditional” means of eliciting requirements. It is important to understand the advantages and limitations of interviews and how they should be conducted. • Scenarios. Scenarios provide a valuable means for providing context to the elicita￾tion of user requirements. They allow the software engineer to provide a framework for questions about user tasks by permitting “what if” and “how is this done” questions to be asked. The most common type of sce￾nario is the use case description. There is a link here to topic 4.2 (Conceptual Modeling) because scenario notations such as use case diagrams are common in modeling software. • Prototypes. This technique is a valuable tool for clarifying ambiguous requirements. They can act in a similar way to scenarios by pro￾viding users with a context within which they can better understand what information they need to provide. There is a wide range of prototyping techniques—from paper mock￾ups of screen designs to beta-test versions of software products—and a strong overlap of their separate uses for requirements elicita￾tion and for requirements validation (see section 6.2, Prototyping). Low fidelity proto￾types are often preferred to avoid stakeholder “anchoring” on minor, incidental character￾istics of a higher quality prototype that can limit design flexibility in unintended ways. • Facilitated meetings. The purpose of these meetings is to try to achieve a summative effect, whereby a group of people can bring more insight into their software require￾ments than by working individually. They can brainstorm and refine ideas that may be difficult to bring to the surface using inter￾views. Another advantage is that conflicting requirements surface early on in a way that lets the stakeholders recognize where these occur. When it works well, this technique