Requirement Engineering: Understanding Essential Software Requirements and Processes, Lecture notes of Software Engineering

Download Requirement Engineering: Understanding Essential Software Requirements and Processes and more Lecture notes Software Engineering in PDF only on Docsity! products »frijare. _ Solutiong-= “lato As. vit va area I =p darn QUSHTY vo as i =requitements= ‘Walue!= aclitioners = > a fematie me a es Software Requirement Engineering Requirement Engineering Lecture # 4 Part! SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHO The essential software requirement Requirements from the customer’s perspective Good practices for requirements engineering The business analyst Requirement Engineering According to International Requirements Engineering Board (IREB): * Requirements engineering is a cooperative, iterative, incremental process, aimed at guaranteeing that: DAll relevant requirements are known and understood with the necessary degree of refinement, O The stakeholders involved come to a satisfactory agreement concerning the known requirements, OAll requirements have been documented as defined by the documentation guidelines or specification guidelines. Requirement Engineering Requirement Engineering ° Requirements engineering is the sub-discipline of systems engineering and software engineering that encompasses all project activities associated with understanding a product's necessary capabilities and attributes. Includes both requirements development and requirements management. Requirement Development ¢ “The process of defining a project's scope, identifying user classes and user representatives, and eliciting, analyzing, specifying, and validating requirements. Its product is a set of documented requirements that defines some portion of the product to be built.” Requirement Development (Cont..) * Requirements development is subdivided into: o Elicitation, oO Analysis, O Specification, and OQ Validation. * These sub-disciplines encompass all the activities involved with exploring, evaluating, documenting, and confirming the requirements for a nrodiict Elicitation * Elicitation encompasses all of the activities involved with discovering requirements, such as: Interviews, Workshops, Document analysis, Prototyping, Test Scenarios OoOoOagagda 0 and others. Analysis ¢ “The process of classifying requirements information into various categories, evaluating requirements for desirable qualities, representing requirements in different forms, deriving detailed requirements from high-level requirements, negotiating priorities, and related activities.” Analysis (Cont..) * Following are the principal activities: OAnalyzing theinformation received from users to distinguish — their task goals from functional requirements, quality expectations, business rules, suggested solutions, and other information Oo Decomposing high-level requirements into an appropriate level of detail Oo Deriving functional requirements from other requirements information Oo Understanding the relative importance of quality attributes Analysis (Cont..) * Following are the principal activities: OAllocatingrequirementsto software components defined in thesystem architecture Oo Negotiating implementation priorities Oldentifying gaps in requirementsor unnecessary requirementsas they relate to the defined scope Validation (Cont..) ° The central activities are: O Reviewing the documented requirements to correct any problems before the development group accepts them. O Developing acceptance tests and criteria to confirm that a product based on the requirements would meet customer needs and achieve the business objectives. Requirement Development * Iteration is a key to requirements development success. ¢ Plan for multiple cycles of exploring requirements, progressively refining high-level requirements into more precision and detail, and confirming correctness with users. Requirements Development Process Framework A Structured Approach to Requirement Development How much, how deep? YOUR USER REQUIRE- MENTS INCLUDE FOUR HUNDRED FEATURES. DO YOU REALIZE THAT GOOD POINT. NO HUMAN WOULD BE I'D BETTER ADD ABLE TO USE A PRODUCT i EASY TO USE WITH THAT LEVEL OF Tae tee COMPLEXITY? A Structured Approach to RD 1. Define stakeholders! eWho is interested in the system? eWho makes decisions? Who are the users, managers, developers, etc.? O In other words, WHO has influence on the software requirements? A Structured Approach to RD Coarse goals WHO "a 7 WHAT Granular goals A Structured Approach to RD 3. Define requirements! *Goals can be derived into concrete requirements *How to get to the requirements? (goal-based!) ¢ Model those requirements using diagrams, templates, etc. O In other words, HOW will the goals be achieved? A Structured Approach to RD WHO Coarse goals Diagrams Templates Requirement Management Requirement Management * Requirements management activities include the following: O Defining the requirements baseline, a snapshot in time that represents an agreed-upon, reviewed, and approved set of functional and nonfunctional requirements, often for a specific product release or development iteration. O Evaluating the impact of proposed requirements changes and incorporating approved changes into the project in a controlled way. Requirement Management (Cont..) * Requirements management activities include the following: O Keeping project plans current with the requirements as they evolve XO Negotiating new commitments based on the estimated impact of requirements changes oO Defining the relationships and dependencies that exist between requirements O Tracing individual requirements to their corresponding designs, source code, and tests Oo Tracking requirements status and change activity throughout the project Requirement Engineering Process Requirement Engineering Process Define 5 Define requirements system’s context Analyse Model the stakeholders system BT lat Validate goals requirements Describe Document scenarios ig=(e 6 llg—i eat —) a1 be) Adapted from “Requirements Engineenng Process” (Michael Schenkel, microTOOL 2074) Benefits of RE Process ° Fewer defects in requirements and °* Fewer miscommunications. in the delivered product. * Reduced scope creep. * Reduced development rework. * Reduced project chaos. ° Faster development and delivery. * Higher customer and team ° Fewer unnecessary and unused member satisfaction. features. * Products that do what they * Lower enhancement costs. are supposed to do.