Introduction-to-Requirements-Engineering_II.pdf

There are many ways to portray the discipline of requirements engineering depending on the viewpoint of the definer. Requirements engineering is the branch of software engineering concerned with the real- world goals for, functions of, and constraints on software systems. It is also concerned w...

There are many ways to portray the discipline of requirements engineering depending on the viewpoint of the definer. Requirements engineering is the branch of software engineering concerned with the real- world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families. (Zave 1997) But we wish to generalize the notion of requirements engineering to include any system, whether it be software only, hardware only, or hardware and software (and many complex systems are a combination of hardware and software), so we rewrite Zave’s definition as follows: Requirements engineering is the branch of engineering concerned with the real-world goals for, functions of, and constraints on systems. It is also concerned with the relationship of these factors to precise specifications of system behavior and to their evolution over time and across families of related systems. What is a "Requirement"? Varies from high-level, abstract statements to formal specifications. Can be informal (sketches, notes) or formal (mathematical models). Stakeholder Needs Different levels of detail required by different stakeholders. Example: Business customers vs. design engineers. Stakeholder Abilities Varying capacities to create and understand requirements. Diverse backgrounds lead to different representation styles.  Aligning stakeholder needs and abilities with requirement details. Ensuring clarity and consistency across different representation forms. Managing diverse quality in requirement documentation. Customers often confuse requirements, features, and goals (and engineers sometimes do too). Requirement specifies how a goal should be accomplished by a proposed system. Goals are high-level Feature is a set of logically objectives of a business, related requirements that organization, or system allows the user to satisfy the goal. “Smart Home System” Goals - automate that which does not need human interaction Features - providing automated water purification to the system “Smart Home System” Requirement 1. Shall have a reverse osmosis water purification system. 2. System shall store how much water passes through the filtration unit each day. 3. System may send notifications to users about how much water passes through the filtration system. 4.System shall incorporate a water softener system into the water system. 5. System shall send notifications to users when salt in softener gets below user-defined levels. Requirements engineering is the branch of engineering concerned with the real-world The process of establishing the goals for, functions of, and services that the customer constraints on systems. It is requires from a system and the also concerned with the constraints under which it relationship of these factors to operates and is developed precise specifications of system behavior and to their evolution over time and across families of related systems. Requirements Level Requirements Classification Specifications Types User Requirements System Requirements Design Specifications User Requirements They specify what services (user functionality) the system is expected to provide and any constraints. System Requirements Detailed descriptions of the services and constraints. These requirements are derived from analysis of the user requirements, and they should be structured and precise. Design or Software Specifications design specifications emerge from the analysis and design documentation used as the basis for implementation by developers. User Requirements The system shall accurately compute sale totals including discounts, taxes, refunds, and rebates; print an accurate receipt; and update inventory counts accordingly. System Requirements Each sale shall be assigned a sales ID. Each sale may have one or more sales items. Each sale may have one or more rebates. Each sale may have only one receipt printed. Design or Software Specifications The system shall assign a unique sales ID number to each sale transaction. Each sales ID may have zero or more sales items associated with it, but each sales item must be assigned to exactly one sales ID Requirements Level Requirements Classification Specifications Types User Requirements Functional Requirements System Requirements Non-Functional Requirements Design Specifications Functional Requirements (FRs) What the system does. Describe the services the system should provide and how the system will react to its inputs. FRs need to explicitly state certain behaviors that the system should not do They are user requirements, that can be detailed, expressing inputs, outputs, exceptions, and so on Nonfunctional Requirements (NFRs) These are non-functional behavior (how the system behaves concerning some observable attributes like reliability, reusability, maintainability). Security Performance Interoperability Reliability Usability Constraints Maintainability Testability Functional Requirements (FRs) When the operator presses the "total" button, the current sale is finalized. For each sale item in the sale, its total is calculated when the sale is finalized. For each non-sale item in the sale, the total is calculated by multiplying the quantity of the item by its list price. Nonfunctional Requirements (NFRs) Performance: Complete transactions within 2 seconds. Usability: Easy to use with minimal training. Security: Protect customer data and ensure compliance with regulations. 1 2 3 4 5 Involves uncovering what the customer needs and wants. Involves discovering who the stakeholders Involves determining the NFRs, which are often overlooked. Involve techniques to deal with a number of problems with requirements in their “raw” form, that is, after they have been collected from the customers. They don’t always make sense. They often contradict one another (and not always obviously so). They may be inconsistent. They may be incomplete. They may be vague or just wrong. They may interact and be dependent on each other. Involves converting the requirements processed raw requirements into some model Various techniques are used for requirements representation including informal (e.g., natural language, sketches, and diagrams) formal (mathematically sound representations) semiformal (convertible to a sound representation or can be made fully formal by the addition of a semantic framework). Is the process of determining if the specification is a correct representation of the customers’ needs. Validation answers the question “Am I building the right product?” Involves various semiformal and formal methods text-based tools visualizations inspections and so on  Involves managing the realities of changing requirements over time. It also involves fostering traceability through appropriate aggregation and subordination of requirements and communicating changes in requirements to those who need to know.  Architect meets with and Requirements engineer meets interviews clients. Tours property. with customers and uses Takes notes and pictures. interviews and other elicitation techniques. Architect makes rough sketches Requirements engineer makes (shows to clients, receives models of requirements to show feedback). to customers (e.g., prototypes, draft SRS).  Architect makes more sketches Requirements engineer refines (e.g., elevations) and perhaps more requirements and adds formal sophisticated models (e.g., and semiformal elements (e.g., cardboard, 3D-virtual models, fly- UML).More prototypingis used. through animations). Architect prepares models with Requirements engineer uses additionaldetail (floor plans). information determined above to develop complete SRS. Future models (e.g., construction Future models (e.g., software drawings) are for contractors’use. design documents) are for developers’use. User Requirements The system shall accurately compute sale totals including discounts, taxes, refunds, and rebates; print an accurate receipt; and update inventory counts accordingly. System Requirements Each sale shall be assigned a sales ID. Each sale may have one or more sales items. Each sale may have one or more rebates. Each sale may have only one receipt printed. Design or Software Specifications The system shall assign a unique sales ID number to each sale transaction. Each sales ID may have zero or more sales items associated with it, but each sales item must be assigned to exactly one sales ID Functional Requirements (FRs) When the operator presses the "total" button, the current sale is finalized. For each sale item in the sale, its total is calculated when the sale is finalized. For each non-sale item in the sale, the total is calculated by multiplying the quantity of the item by its list price. Nonfunctional Requirements (NFRs) Performance: Complete transactions within 2 seconds. Usability: Easy to use with minimal training. Security: Protect customer data and ensure compliance with regulations.