Requirements Elicitation PDF

Requirements 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 requirements specification and serves as a contract between the client and the dev...

Requirements 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 requirements specification and serves as a contract between the client and the developers. The requirements specification is structured and formalized during analysis to produce an analysis model. Both requirements specification and analysis model represent the same information. They differ only in the language and notation they use; the requirements specification is written in natural language, whereas the analysis model is usually expressed in a formal or semiformal notation. The requirements 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 they attempt to represent accurately the external aspects of the system. Given that both models represent the same aspects of the system, requirements elicitation and analysis occur concurrently and iteratively. 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. 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. For 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. The information stored in SatWatch and its accuracy measuring time is such that the watch owner never needs to reset the time. SatWatch adjusts the time and date displayed as the watch owner crosses time zones and political boundaries. For this reason, SatWatch has no buttons or controls available to the user. SatWatch determines its location using GPS satellites and, as such, suffers from the same limitations as all other GPS devices (e.g., inability to determine location at certain times of the day in mountainous regions). During blackout periods, SatWatch assumes that it does not cross a time zone or a political boundary. SatWatch corrects its time zone as soon as a blackout period ends. 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, date, month, year). The display technology used is such that the watch owner can see the time and date even under poor light conditions. When political boundaries change, the watch owner may upgrade the software of the watch using the WebifyWatch device (provided with the watch) and a personal computer connected to the Internet.” Nonfunctional Requirements Nonfunctional requirements describe aspects of the system that are not directly related to the functional behavior of the system. Nonfunctional requirements include a broad variety of requirements that apply to many different aspects of the system, from usability to performance: Usability is the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. Usability requirements include, for example, conventions adopted by the user interface, the scope of online help, and the level of user documentation. Often, clients address usability issues by requiring the developer to follow user interface guidelines on color schemes, logos, and fonts. Usability must be measurable, otherwise it is marketing - Example: Specification of the number of steps to perform a internet-based purchase with a web browser Reliability is the ability of a system or component to perform its required functions under stated conditions for a specified period of time. Reliability requirements include, for example, an acceptable mean time to failure and the ability to detect specified faults or to withstand specified security attacks. More recently, this category is often replaced by dependability, which is the property of a computer system such that reliance can justifiably be placed on the service it delivers. Dependability includes reliability, robustness (the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environment conditions), and safety (a measure of the absence of catastrophic consequences to the environment). Performance requirements are concerned with quantifiable attributes of the system, such as response time (how quickly the system reacts to a user input), throughput (how much work the system can accomplish within a specified amount of time), availability (the degree to which a system or component is operational and accessible when required for use), and accuracy. Supportability requirements are concerned with the ease of changes to the system after deployment, including for example, adaptability (the ability to change the system to deal with additional application domain concepts), maintainability (the ability to change the system to deal with new technology or to fix defects), and internationalization (the ability to change the system to deal with additional international conventions, such as languages, units, and number formats). Constraints The FURPS+ model provides additional categories of requirements typically also included under the general label of nonfunctional requirements: Implementation requirements are constraints on the implementation of the system, including the use of specific tools, programming languages, or hardware platforms. Interface requirements are constraints imposed by external systems, including legacy systems and interchange formats. Operations requirements are constraints on the administration and management of the system in the operational setting. Packaging requirements are constraints on the actual delivery of the system (e.g., constraints on the installation media for setting up the software). Legal requirements are concerned with licensing, regulation, and certification issues. Nonfunctional requirements that fall into the URPS categories are called quality requirements of the system. Nonfunctional requirements that fall into the implementation, interface, operations, packaging, and legal categories are called constraints or pseudo requirements. Budget and schedule requirements are usually not treated as nonfunctional requirements, as they constrain attributes of the projects. The following description depicts the nonfunctional requirements for SatWatch: “Quality requirements for SatWatch Any user who knows how to read a digital watch and understands international time zone abbreviations should be able to use SatWatch without the user manual. [Usability requirement] As the SatWatch has no buttons, no software faults requiring the resetting of the watch should occur. [Reliability requirement] SatWatch should display the correct time zone within 5 minutes of the end of a GPS blackout period. [Performance requirement] SatWatch should measure time within 1/100th second over 5 years. [Performance requirement] SatWatch should display time correctly in all 24 time zones. [Performance requirement] SatWatch should accept upgrades to its onboard via the Webify Watch serial interface. [Supportability requirement] Constraints for SatWatch  All related software associated with SatWatch, including the onboard software, will be written using Java, to comply with current company policy. [Implementation requirement] SatWatch complies with the physical, electrical, and software interfaces defined by WebifyWatch API 2.0. [Interface requirement]” Requirements Validation - Completeness, Consistency, Clarity, and Correctness Requirements are continuously validated with the client and the user. Validation is a critical step in the development process, given that both the client and the developer depend on the requirements specification. Requirement validation involves checking that the specification is complete, consistent, unambiguous, and correct. It is complete if all possible scenarios through the system are described, including exceptional behavior (i.e., all aspects of the system are represented in the requirements model). The requirements specification is consistent if it does not contradict itself. The requirements specification is unambiguous if exactly one system is defined (i.e., it is not possible to interpret the specification two or more different ways). A specification is correct if it represents accurately the system that the client needs and that the developers intend to build (i.e., everything in the requirements model accurately represents an aspect of the system to the satisfaction of both client and developer). Example: “Specification properties checked during validation. Complete—All features of interest are described by requirements. Example of incompleteness: The SatWatch specification does not specify the boundary behavior when the user is standing within GPS accuracy limitations of a state’s boundary. Solution: Add a functional requirement stating that the time depicted by SatWatch should not change more often than once very 5 minutes. Consistent—No two requirements of the specification contradict each other. Example of inconsistency: A watch that does not contain any software faults need not provide an upgrade mechanism for downloading new versions of the software. Solution: Revise one of the conflicting requirements from the model (e.g., rephrase the requirement about the watch not containing any faults, as it is not verifiable anyway). Unambiguous—A requirement cannot be interpreted in two mutually exclusive ways. Example of ambiguity: The SatWatch specification refers to time zones and political boundaries. Does the SatWatch deal with daylight saving time or not? Solution: Clarify the ambiguous concept to select one of the mutually exclusive phenomena (e.g., add a requirement that SatWatch should deal with daylight saving time). Correct—The requirements describe the features of the system and environment of interest to the client and the developer, but do not describe other unintended features. Example of fault: There are more than 24 time zones. Several countries and territories (e.g, India) are half an hour ahead of a neighboring time zone.” - Realism and Traceability Two more desirable properties of a requirements specification are that it be realistic and traceable. The requirements specification is realistic if the system can be implemented within constraints. A requirements specification is traceable if each requirement can be traced throughout the software development to its corresponding system functions, and if each system function can be traced back to its corresponding set of requirements. Traceability includes also the ability to track the dependencies among requirements, system functions, and the intermediate design artifacts, including system components, classes, methods, and object attributes. Traceability is critical for developing tests and for evaluating changes. When developing tests, traceability enables a tester to assess the coverage of a test case, that is, to identify which requirements are tested and which are not. When evaluating changes, traceability enables the analyst and the developers to identify all components and system functions that the change would impact. We can specify Requirements for “Requirements Management” Functional requirements: Store the requirements in a shared repository Provide multi-user access to the requirements Automatically create a specification document from the requirements Allow change management of the requirements Provide traceability of the requirements throughout the artifacts of the system. Tools for Requirements Management DOORS (Telelogic) Multi-platform requirements management tool, for teams working in the same geographical location. DOORS XT for distributed teams. RequisitePro (IBM/Rational) Integration with MS Word Project-to-project comparisons via XML baselines RD-Link (http://www.ring-zero.com) Provides traceability between RequisitePro & Telelogic DOORS Unicase (http://unicase.org) Research tool for the collaborative development of system models Participants can be geographically distributed. Different Types of Requirements Elicitation Requirements elicitation activities can be classified into three categories, depending on the source of the requirements. In greenfield engineering, the development starts from scratch—no prior system exists—so the requirements are extracted from the users and the client. A greenfield engineering project is triggered by a user need or the creation of a new market. SatWatch is a greenfield engineering project. A reengineering project is the redesign and reimplementation of an existing system triggered by technology enablers or by business processes [Hammer & Champy, 1993]. Sometimes, the functionality of the new system is extended, but the essential purpose of the system remains the same. The requirements of the new system are extracted from an existing system. An interface engineering project is the redesign of the user interface of an existing system. The legacy system is left untouched except for its interface, which is redesigned and reimplemented. This type of project is a reengineering project in which the legacy system cannot be discarded without entailing high costs. Nonfunctional Requirements (Questions to overcome “Writers block”) User interface and human factors What type of user will be using the system? Will more than one type of user be using the system? What training will be required for each type of user? Is it important that the system is easy to learn? Should users be protected from making errors? What input/output devices are available Documentation What kind of documentation is required? What audience is to be addressed by each document? Hardware considerations What hardware is the proposed system to be used on? What are the characteristics of the target hardware, including memory size and auxiliary storage space? Performance characteristics Are there speed, throughput, response time constraints on the system? Are there size or capacity constraints on the data to be processed by the system? Error handling and extreme conditions How should the system respond to input errors? How should the system respond to extreme conditions? System interfacing Is input coming from systems outside the proposed system? Is output going to systems outside the proposed system? Are there restrictions on the format or medium that must be used for input or output? Quality issues What are the requirements for reliability? Must the system trap faults? What is the time for restarting the system after a failure? Is there an acceptable downtime per 24-hour period? Is it important that the system be portable? System Modifications What parts of the system are likely to be modified? What sorts of modifications are expected? Physical Environment Where will the target equipment operate? Is the target equipment in one or several locations? Will the environmental conditions be ordinary? Security Issues Must access to data or the system be controlled? Is physical security an issue? Resources and Management Issues How often will the system be backed up? Who will be responsible for the back up? Who is responsible for system installation? Who will be responsible for system maintenance?