Understanding Requirements REQUIREMENTS descriptions of what the system

Understanding Requirements

REQUIREMENTS �descriptions of what the system should do—the services that it provides and the constraints on its operation. �reflect the needs of customers for a system that serves a certain purpose such as: • controlling a device • placing an order • finding information.

Functional & Non Functional Requirements Functional requirements: �Statements of services the system should provide, �how the system should react to particular inputs, and �how the system should behave in particular situations. �the functional requirements may also explicitly state what the system should not do. Non-functional requirements: �Constraints on the services or function offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. �Apply to the system as a whole, rather than individual system features or services.

Functional requirements �what the system should do �depend on the type of software being developed, the expected users of the software, and the general approach taken by the organization �describe the system functions, its inputs and outputs, exceptions, etc. , in detail. �the functional requirements specification of a system should be both complete and consistent For Example: 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 eight-digit employee number.

Non-functional requirements �Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users. �They may relate to emergent system properties such as reliability, response time, and store occupancy �Constraints on the system implementation such as the capabilities of I/O devices or the data representations used in interfaces with other systems �Non-functional requirements, such as performance, security, or availability, usually specify or constrain characteristics of the system as a whole. �failing to meet a non-functional requirement can mean that the whole system is unusable.

Non-functional requirements 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. 2. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define new system services that are required. In addition, it may also generate requirements that restrict existing requirements.

Requirements Engineering �The broad spectrum of tasks and techniques that lead to an understanding of requirements is called “requirements engineering” �Requirements engineering is a major software engineering action that begins during the communication activity and continues into the modeling activity. �It must be adapted to the needs of the process, the project, the product, and the people doing the work. �Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system.

Tasks to be done in Requirements Engineering �It encompasses seven distinct tasks: 1) Inception 2) Elicitation 3) Elaboration 4) Negotiation 5) Specification 6) Validation 7) Management.

Inception Ask a set of questions that establish: � basic understanding of the problem � the people who want a solution � the nature of the solution that is desired, and � the effectiveness of preliminary communication and collaboration between the customer and the developer

Elicitation Requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. �The practice is also sometimes referred to as requirements gathering. �Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases.

Problems encountered in Elicitation �Problems of scope. The boundary of the system is illdefined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives. �Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious, ” specify requirements that are ambiguous or untestable. �Problems of volatility. The requirements change over time.

Elaboration �Create an analysis model that identifies data, function and behavioral requirements �The information obtained from the customer during inception and elicitation is expanded and refined during elaboration. �Elaboration is driven by the creation and refinement of user scenarios that describe how the end user (and other actors) will interact with the system.

Negotiation �Agree on a deliverable system that is realistic for developers and customers. �Customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts in priority. �Using an iterative approach that prioritizes requirements, assesses their cost and risk, and addresses internal conflicts, requirements are eliminated, combined, and/or modified so that each party achieves some measure of satisfaction.

Specification It can be any one (or more) of the following: � A written document � A set of graphical models � A formal mathematical model � A collection of user scenarios (use-cases) � A prototype It is sometimes necessary to remain flexible when a specification is to be developed. For large systems, a written document, combining natural language descriptions and graphical models may be the best approach.

Requirement Specification Template

Validation �Requirements validation examines the specifications to ensure that all software requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product. A review mechanism that looks for � errors in content or interpretation � areas where clarification may be required � missing information � inconsistencies (a major problem when large products or systems are engineered) � conflicting or unrealistic (unachievable) requirements.

Requirements management �Requirements for computer-based systems change, and the desire to change requirements persists throughout the life of the system. �Requirements management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds

Requirements Validation Checklist