Chapter 3.pdf

Chapter 3 Tuesday, September 17, 2024 1:54 PM Contradictory Requirements: when a project includes a wide range of Stakeholder Identifying all customers and stakeholders is the first step in preparing for requirements elicitation. Brainstorming consists of informal sessions with customers and...

Chapter 3 Tuesday, September 17, 2024 1:54 PM Contradictory Requirements: when a project includes a wide range of Stakeholder Identifying all customers and stakeholders is the first step in preparing for requirements elicitation. Brainstorming consists of informal sessions with customers and other stakeholders to generate overarching goals for the systems. Brainstorming can be formalized to include a set agenda, minute- taking, and the use of formal structures (e.g., Robert’s Rules of Order). Card Sorting involves having stakeholders complete a set of cards that includes key information about functionality for the system/software product. It is recommended that a minimum of 1 week (and no more than 2 weeks) be allowed for the completion of the cards. The sorted cards can also be used as an input to the process to develop CRC (capability, responsibility, collaboration) cards to determine program classes in the eventual code. Another technique to be discussed shortly, QFD, includes a card-sorting activity. Crowdsourcing is a business model that harnesses the power of a large and diverse number of people to contribute knowledge and solve problems. Capturing the requirements directly from the crowd (the bigger the crowd, the better) gives the requirements engineers access to a wide diversity of actual and potential users which has the potential to increase the comprehensiveness and quality of the captured requirements. Crowdsourcing in requirements elicitation has the potential to increase the comprehensiveness and quality of the captured requirements by giving the requirements engineers access to a wide diversity of actual and potential users. Social media (e.g., LinkedIn, Facebook, Twitter) provide the best-developed mechanisms to efficiently get feedback from crowds. Designer as apprentice is a requirements discovery technique in which the requirements engineer “looks over the shoulder” of the customer in order to learn enough about the customer’s work to understand their needs. Domain analysis involves any general approach to assessing the “landscape” of related and competing applications to the system being designed. Such an approach can be useful in identifying essential functionality and, later, missing functionality. The QFD elicitation approach explicitly incorporates domain analysis, and we will discuss this technique shortly. Ethnographic observation refers to any technique in which observation of indirect and direct factors inform the work of the requirements engineer. Ethnographic observation is a technique borrowed from social science in which observations of human activity and the environment in which the work occurs are used to inform the scientist in the study of some phenomenon. Goal-based approaches comprise any elicitation techniques in which requirements are recognized to emanate from the mission statement, through a set of goals that lead to requirements. That is, looking at the mission statement, a set of goals that fulfill that mission is generated. These goals may be subdividedmone or more times to obtain lower-level goals. Then, the lower-level goals are branched out into specific high-level requirements. Finally, the high-level requirements are used to generate lower- level ones. These goals can then be decomposed into requirements using a structured approach such as goal-question-metric (GQM). GQM is an important technique used in many aspects of systems engineering such as requirements engineering, New Section 1 Page 1 used in many aspects of systems engineering such as requirements engineering, architectural design, systems design, and project management. GQM incorporates three steps: state the system’s objectives or goals; derive from each goal the questions that must be answered to determine if the goal is being met; and decide what must be measured in order to be able to answer the questions. Group work is a general term for any kind of group meetings that are used during the requirements discovery, analysis, and follow-up processes. The most celebrated group-oriented work for requirements elicitation is JAD. Elicitation through interviews involves in-person communication between two individual stakeholders or a small group of stakeholders (sometimes called a focus group). Interviews are an easy-to-use technique to extract system-level requirements from stakeholders, especially usability requirements. Three kinds of interviews can be used in elicitation activities, and they can be applied to individuals or focus groups: Unstructured, Structured, Semi-structured. When a requirements engineer develops requirements based on what he thinks the customer wants, then he is conducting the process of introspection. In essence, the requirements engineer puts himself in the place of the customer and opines “if I were the customer I would want the system to do this …” JAD involves highly structured group meetings (sometimes called “miniretreats”) with system users, system owners, and analysts focused on a specific set of problems for an extended period of time. In laddering, the requirements engineer asks the customer short prompting questions (probes) to elicit 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. A protocol analysis is a process where customers, together with the requirements engineers, walk through the procedures that they are going to automate. During such a walkthrough, the customers explicitly state the rationale for each step that is being taken. Prototyping involves the construction of models of the system in order to discover new features, particularly usability requirements. Prototyping is a particularly important technique for requirements elicitation. Quality function deployment (QFD) is a technique for discovering customer requirements and defining major quality assurance points to be used throughout the production phase. QFD provides a structure for ensuring that customers’ needs and desires are carefully heard, then directly translated into a company’s internal technical requirements—from analysis through implementation to deployment. Requirements engineers often use questionnaires and other survey instruments to reach large groups of stakeholders. Surveys are generally used at the early stages of the elicitation process to quickly define the scope boundaries. Repertory grids incorporate a structured ranking system for various features of the different entities in the system and are typically used when the customers are domain experts. Repertory grids are particularly useful for the identification of New Section 1 Page 2 domain experts. Repertory grids are particularly useful for the identification of agreement and disagreement within stakeholder groups. If an existing system has outdated documentation (or even nonexistent documentation), then reverse engineering can be applied to the system to extract the requirements from the system to understand what the system does. This elicitation technique can be particularly useful for migration projects when dealing with legacy systems. Generally, there are two types of reverse engineering techniques: Black-Box Reverse Engineering: the system is studied without examining its internal structure (function and composition of software). White-Box Reverse Engineering: The inner workings of the system are studied (analyzing and understanding of software code). Scenarios are informal descriptions of the system in use that provide a high-level description of system operation, classes of users, and exceptional situations. Like many of the hierarchically oriented techniques that we have studied already, task analysis involves a functional decomposition of tasks to be performed by the system. That is, starting at the highest level of abstraction, the designer and customers elicit further levels of detail. This detailed decomposition continues until the lowest level of functionality (single task) is achieved. Use cases are a way for more sophisticated customers and stakeholders to describe their desiderata. Use cases depict the interactions between the system and the environment around the system, in particular, human users and other systems. They can be used to model the behavior of pure software or hybrid hardware-software systems. User stories are short conversational texts that are used for initial requirements discovery and project planning. User stories are widely employed in conjunction with agile methodologies. Viewpoints are a way to organize information from the (point of view of) different constituencies. On a most general level, workshops are any gathering of stakeholders to resolve requirements issues. We can distinguish workshops as being of two types— formal and informal. Nonfunctional requirement (NFR) elicitation techniques differ from functional requirements elicitation techniques. NFRs are generally stated informally during the requirements analysis, are often contradictory, and are difficult to enforce and validate during the software development process. New Section 1 Page 3