Software Engineering: Chapter 7 - Requirements Elicitation, Analysis, and Management, Study notes of Software Engineering

Download Software Engineering: Chapter 7 - Requirements Elicitation, Analysis, and Management and more Study notes Software Engineering in PDF only on Docsity! ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 1 Chapter 7 Requirements Engineering Process ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 2 Objectives ● To describe the principal RE activities. ● To introduce techniques for requirements elicitation and analysis. ● To describe requirements validation. ● To discuss the role of requirements management in support of other RE processes. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 5 Spiral RE Process Model Emphasizes iterative nature of core activities ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 6 Feasibility Study Feasibility study issues ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 7 Feasibility study ● Aims to answer three basic questions: § Would the system contribute to overall organizational objectives? § Could the system be engineered using current technology and within budget? § Could the system be integrated with other systems already in use? ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 10 Elicitation and analysis ● Involves working with customers to learn about the application domain, the services needed and the system’s operational constraints, etc. ● May also involve end-users, managers, maintenance personnel, domain experts, trade unions, etc. (That is, other stakeholders.) ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 11 Problems of elicitation and analysis ● Getting all, and only, the right people involved ● Stakeholders often: § don’t know what they really want § express requirements in their own terms. § have conflicting or competing requirements. ● Requirements naturally change as insight improves. (Should this really be thought of as a problem?) (cont'd) ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 12 Problems of elicitation and analysis (cont’d) ● New stakeholders may emerge. ● Political or organizational factors may affect requirements. (Examples?) ● The environment may evolve during the RE process. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 15 Viewpoint-oriented elicitation ● Stakeholders represent different ways of looking at a problem (“viewpoints”). ● A multi-perspective analysis is important as there is no single correct way to analyze system requirements. ● Provides a natural way to structure the elicitation process and organize requirements. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 16 Types of viewpoints ● Interactor viewpoints § People or other systems that interact directly with the system. ● Indirect viewpoints § Stakeholders who do not use the system themselves but who influence the requirements. ● Domain viewpoints § Domain characteristics and constraints that affect the requirements. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 17 Method-based RE ● “Structured methods” to elicit, analyze, and document requirements. ● Examples include: § Ross’ Structured Analysis (SA), § Volere Requirements Process (www.volere.co.uk) § Knowledge Aquisition and Sharing for Requirement Engineering (KARE) Esprit project (http://cordis.europa.eu/esprit/home.html), § Sommerville’s Viewpoint-Oriented Requirements Definition (VORD), and § Thebaut’s Scenario-Based Requirements Engineering (SBRE) part of “SA/SD” Suzanne & James Robertson, Atlantic Systems Guild ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 20 KARE workbench architecture ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 21 Sommerville’s VORD method ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 22 VORD standard forms two points of reference ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 25 Scenarios ● Depict examples or scripts of possible system behavior ● People often relate to these more readily than to abstract statements of requirements “Give me an example to help tie the parts together” (into a coherent whole.) ● Particularly useful in elucidating fragmentary, incomplete, or conflicting requirements ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 26 Scenario elements 1. System state at the beginning of the scenario (if relevant) 2. Sequence of events for a specific case of some generic task the system is required to accomplish. 3. Any relevant concurrent activities. 4. System state at the completion of the scenario. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 27 A simple scenario t0: The user enters values for input array A. The values are [1, 23, -4, 7, 19]. t1: The user executes program MAX. t2: The value of variable BIG is 23 and the values of A are [1, 23, -4, 7, 19]. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 30 Scenario for a “start transaction” event different scenarios different scenarios ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 31 UML use-cases and sequence diagrams ● Graphical notations for representing abstract scenarios in the UML. (UML is the de facto standard for OO Analysis & Design) ● Identify actors in an interaction and describe the interaction itself. ● A set of use-cases should describe all types of interactions with the system. ● Sequence diagrams show the sequence of event processing. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 32 Library use-cases ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 35 Example • Consider a system which allows senior manage- ment to access information without going through middle managers. § Managerial status – Senior managers may feel that they are too important to use a keyboard. § Managerial responsibilities – Managers may not have time to learn how to use the system § Organizational resistance – Middle managers who will be made redundant may deliberately provide misleading or incomplete information so the system will fail. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 36 Ethnography ● A social scientist observes and analyzes how people actually work. ● Subjects do not have to explain or otherwise articulate what they do. ● Social and organizational factors of importance may be observed. ● Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 37 Focused ethnography ● Developed during a project studying the air traffic control process. ● Combines ethnography with prototyping. ● Prototype development raises issues which focus the ethnographic analysis. ● Problem with ethnography alone: it studies existing practices which may not be relevant when a new system is put into place. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 40 Requirements attributes ● Validity: Does the system provide the functions which best support the customer’s needs? ● Consistency: Are there any requirements conflicts? ● Completeness: Are all functions required by the customer included? ● Realism: Can the requirements be implemented given available budget and technology ● Verifiability: Can the requirements be tested? (More precisely, can the system be tested to determine whether or not the requirements are met?) (as opposed to wants?) ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 41 Requirements validation techniques ● Requirements reviews / inspections – systematic manual analysis of the requirements. ● Prototyping – using an executable model of the system to check requirements. Covered in Chapter 17. ● Test-case generation – developing tests for requirements to check testability. ● Automated consistency analysis – checking the consistency of a structured requirements description. (CASE – e.g., “Wisdom” tool in KARE workbench) ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 42 Requirements reviews / inspections ● Regular reviews should be held while require- ments are being formulated. ● Both client and contractor staff should be involved in reviews. (+ other stakeholders) ● Reviews may be formal or informal… ● Good communication between developers, customers and users can resolve problems at an early stage. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 45 Requirements management… ● …is the process of understanding and controlling requirements change. ● Requirements evolve, priorities change, and new requirements emerge as § a better understanding of the system is developed, and § the business and technical environment of the system changes. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 46 Enduring and volatile requirements ● Enduring requirements: Stable requirements derived from the core activity of the customer organization. (E.g., a hospital will always have doctors, nurses, etc. May be derived from domain models.) ● Volatile requirements: Requirements which change during development or when the system is in use. (E.g., requirements derived from the latest health-care policy.) ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 47 Types of volatile requirements ● Mutable – those that change due to changes in the organization’s operating environment. ● Emergent – those that emerge as a better understanding of the system develops. ● Consequential – those that result from the introduction of the system. ● Compatibility – those that change due to changing systems or processes within the organization. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 50 CASE tool support ● Requirements storage – in a secure, managed data store ● Change management – a workflow process whose stages can be defined and information flow between the stages partially automated ● Traceability management – automated discovery and documentation of relationships between requirements (keyword search, common scenarios, etc.) ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 51 Change management process ● Applied to all proposed requirements changes ● Principal stages: § Problem analysis – analyze identified requirements problem and propose specific change(s) § Change analysis and costing – assess effects of change on other requirements § Change implementation – modify requirements document (+ system design and implementation, as necessary) to reflect the change ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 52 Change management process (cont’d) ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 55 Key points (cont’d) ● Business, organizational, and technical changes inevitably lead to changing requirements. ● Requirements management involves careful planning and a change manage- ment process. ©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 56 Chapter 7 Requirements Engineering Process