Chapter 3 Requirements Elicitation

Chapter 3: Requirements Elicitation Introduction Requirement’s elicitation focuses on describing the purpose of the system. The client, the developers, and the users identify a problem area and define a system that addresses the problem. Such a definition is called a system specificati...

Chapter 3: Requirements Elicitation Introduction Requirement’s elicitation focuses on describing the purpose of the system. The client, the developers, and the users identify a problem area and define a system that addresses the problem. Such a definition is called a system specification and serves as a contract between the client and the developers. The system specification supports the communication with the client and users. The analysis model supports the communication among developers. They are both models of the system in the sense that 2 … Overview of Requirements Elicitation Requirements elicitation and analysis focus only on the user’s view of the system. For example: the system functionality, the interaction between the user and the system, the errors that the system can detect and handle, and the environmental conditions in which the system functions, are part of the requirements. The system structure, the implementation technology selected to build the system, the system design, the development methodology, and other aspects not directly visible to the user are not part of the requirements. 3 … Req’ts elicitation Requirements elicitation includes the following activities: Identifying actors. During this activity, developers identify the different types of users the future system will support. Identifying scenarios. During this activity, developers observe users and develop a set of detailed scenarios for typical functionality provided by the future system. Scenarios are the different activities the users carry on using the system Identifying use cases. developers derive from the scenarios a set of use cases that completely represent the future system. 4 … Requirements elicitation activities Refining use cases. During this activity, developers ensure that the system specification is complete, by detailing each use case and describing the behavior of the system in the presence of errors and exceptional conditions. Identifying relationships among use cases. During this activity, developers consolidate the use case model by eliminating redundancies. Identifying nonfunctional requirements. During this activity, developers, users, and clients agree on aspects that are visible to the user but not directly related to functionality. Non-functional requirements include constraints on the performance of the system, its documentation, the resources it consumes, its security, and its quality 5 Requirements elicitation methods During requirements elicitation, developers access many different sources of information, including: client-supplied documents about the application domain, manuals and technical documentation of legacy systems We focus on three methods for eliciting information and making decisions with users and clients: 1. Joint Application Design (JAD) focuses on building consensus among developers, users, and clients by jointly developing the system specification JAD is a means to bring together the key users, managers, and systems analysts involved in the analysis of a current system. The goal of JAD is to collect systems requirements simultaneously from the key people involved in the system. JAD sessions are usually conducted in a location away from where the people normally work, to keep them away from all distractions 6  People involved in JAD include: JAD session leader, Users, System analysts, Sponsor 2. Knowledge Analysis of Tasks (KAT) Focuses on eliciting information from users through observation. 3. Usability testing Focuses on validating the requirements elicitation model with the user through a variety of methods. 7 Requirements elicitation concepts Functional requirements Nonfunctional and pseudo-requirements Levels of descriptions Correctness, completeness, consistency, clarity, and realism Verifiability and traceability Greenfield engineering, reengineering, and interface engineering 8 Functional requirements Functional requirements describe the interactions between the system and its environment independent of its implementation. The environment includes the user and any other external system with which the system interacts. Example, the following is an example of functional requirements for SatWatch, a watch that resets itself without user intervention SatWatch is a wrist watch that displays the time based on its current location. SatWatch uses GPS satellites (Global Positioning System) to determine its location and internal data structures to convert this location into a time zone SatWatch adjusts the time and date displayed as the watch 9 Functional requirements of SatWatch SatWatch has a two-line display showing, on the top line, the time (hour, minute, second, time zone) and, on the bottom line, the date (day of the week, day, month, year). The display technology used is such that the watch owner can see the time and date even under poor light conditions. When a new country or state institutes different rules for daylight savings time, the watch owner may upgrade the software of the watch using the WebifyWatch serial device (provided when the watch is purchased) and a personal computer connected to the Internet. SatWatch complies with the physical, electrical, and 10 Non-Functional and Pseudo-Requirements Nonfunctional requirements describe user-visible aspects of the system that are not directly related with the functional behavior of the system. Nonfunctional requirements include quantitative constraints, such as response time, user interface issues (how easy is the system to use), security, etc Nonfunctional requirements for SatWatch 100 feet accuracy, inability to determine location at certain times of the day in mountainous regions. The battery life of SatWatch is limited to 5 years, which is the estimated life cycle of the housing of SatWatch. The SatWatch housing is not designed to be opened once manufactured, preventing battery replacement and repairs. SatWatch is priced such that the watch owner is expected to buy a new SatWatch to replace a defective or old SatWatch 11 Pseudo-requirements are requirements imposed by the client that restrict the implementation of the system. Typical pseudo-requirements are the implementation language and the platform on which the system is to be implemented For life-critical developments, pseudo-requirements often include process and documentation requirements (e.g., the use of a formal specification method, the complete release of all work products). Example: Pseudorequirement for SatWatch All related software associated with SatWatch, including the onboard software, will be written using Java, to comply with current company policy 12 Correctness, Completeness, Consistency, Clarity, and Realism Requirements are continuously validated with the client and the user. Requirement validation involves checking if the specification is correct, complete, consistent, unambiguous, and realistic. A specification is correct if it represents the client’s view of the system (i.e., everything in the requirements model accurately represents an aspect of the system). It is complete if all possible scenarios through the system are described, including exceptional behavior The system specification is consistent if it does not contradict itself. The system specification is unambiguous if exactly one system is defined (i.e., it is not possible to interpret the specification two or more different ways). It is realistic if the system can be implemented within constraints. 13 Requirements Elicitation Activities These map a problem statement into a system specification that we represent as a set of actors, scenarios, and use cases Requirements elicitation activities include: identifying actors identifying scenarios identifying use cases refining use cases identifying relationships among use cases identifying participating objects identifying nonfunctional requirements 14 Identifying Actors Actors represent external entities that interact with the system. An actor can be human or an external system. In the SatWatch example, the watch owner, the GPS satellites, and the WebifyWatch serial device are actors. Actors define classes of functionality. the watch owner wears and looks at her watch; the watch monitors the signal from the GPS satellites; the WebifyWatch downloads new data into the watch 15 … Identifying Actors WatchOwner moves the watch (possibly across time zones) and consults it to know what time it is. SatWatch interacts with GPS to compute its position. WebifyWatch upgrades the data contained in the watch to reflect changes in time policy Example 2: For the Friend systemWarehouse in fire FieldOfficer and system Dispatcher are actors 16 … Identifying Actors Questions for identifying actors Which user groups are supported by the system to perform their work? Which user groups execute the system’s main functions? Which user groups perform secondary functions, such as maintenance and administration? Will the system interact with any external hardware or software system? 17 Identifying Scenarios A scenario is a concrete, focused, informal description of a single feature of the system from the viewpoint of a single actor It enhances requirements elicitation by providing a tool that is readily understandable to users and clients Below is an example of scenario for the FRIEND system, an information system for incident response. In this scenario, a police officer reports a fire and a Dispatcher initiates the incident response 18 19 Identifying Use Cases A scenario is an instance of a use case, that is, a use case specifies all possible scenarios for a given piece of functionality. A use case is initiated by an actor. After its initiation, a use case may interact with other actors as well. 20 21 Identifying Relationships We use extend relationships to separate exceptional and common flows of events. We use include relationships to reduce redundancy among use cases. Extend relationships between use cases A use case extends another use case if the extended use case may include the behavior of the extension under certain conditions. In the FRIEND example, assume that the connection between the FieldOfficer station and the Dispatcher station is broken while the FieldOfficer is filling the form. The FieldOfficer station needs to notify the FieldOfficer that his form was not delivered and what measures he should take. 22  The ConnectionDown use case is modeled as an extension of ReportEmergency Connection Down extends the Report Emergency use case. The Report Emergency use case becomes shorter and solely focused on emergency reporting. 23 Include relationships between use cases Redundancies among use cases can be factored out using include relationships. Assume, for example, that a Dispatcher needs to consult the city map when opening an incident ViewMap describes the flow of events for viewing a city map (e.g., scrolling, zooming, query by street name) and is used by both OpenIncident and AllocateResources use cases. 24 Identifying Non-Functional Requirements Nonfunctional requirements describe user-visible aspects of the system that are not directly related to the functional behavior of the system. Nonfunctional requirements span a number of issues, from user interface look and feel to response time requirements to security issues. Examples: Security:- the system provides two levels of security due to very sensitive data: Smart card and pin code Performance characteristics. How responsive should the system be? How many concurrent users should it support? What is a typical or extreme load? 25 … Non-Functional Requirements User interface and human factors. What kind of interface should the system provide? What is the level of expertise of the users? Hardware considerations. Are there hardware compatibility requirements? Will the system interact with other hardware systems? Quality issues. How reliable/available/robust should the system be? System modifications. What is the anticipated scope of future changes? Who will perform the changes? Physical environment. Where will the system be deployed? Are there external factors such as weather conditions that the system should withstand? 26 Documenting Requirements Elicitation The results of the requirements elicitation activity and the analysis activity are documented in the Requirements Analysis Document (RAD). This document completely describes the system in terms of functional and nonfunctional requirements and serves as a contractual basis between the client and the developers. The audience for the RAD includes: the client, the users, the project management, the system analysts (i.e., the developers who participate in the requirements), and the system designers (i.e., the developers who participate in the system design). 27  The first part of the document, including use cases and nonfunctional requirements, is written during requirements elicitation. The formalization of the specification in terms of object models is written during analysis. The first section of the RAD is an Introduction. Its purpose is to provide a brief overview of the function of the system and the reasons for its development, its scope The introduction also includes the objectives and success criteria of the project. The second section, Current system, describes the current state of affairs. If the new system will replace an existing system, this section describes the functionality and the problems of the current system 28  RAD template 29