1 / 56

Chapter 7

Chapter 7. Requirements Engineering Process. 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.

jirair
Download Presentation

Chapter 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 7 Requirements Engineering Process

  2. Objectives • To describe the principalREactivities. • 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.

  3. RE processes… • Vary widely depending on: • Application domain • People involved • Organization developing the requirements • Generic activities common to most: • Feasibility study • Requirements elicitation and analysis • Requirements specification • Requirements validation core, iterative activities

  4. RE Process Model

  5. Spiral RE Process Model Emphasizes iterative nature of core activities

  6. Feasibility Study Feasibility study issues

  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?

  8. Feasibility study issues (a high-level checklist) • How would the organization cope if the system wasn’t implemented? • What are the current process problems and how would the system helpwith these? • What will the integration problems be? • Is new technologyneeded? New skills? • What must be supported by the system, and what need not be supported?

  9. Elicitation and Analysis Problems Process activities Viewpoint-oriented elicitation Method-based RE Interviewing Scenarios Social and organizational factors Ethnography & focused ethnography

  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.)

  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)

  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.

  13. Elicitation and analysis process activities • Requirements discovery • Interacting with stakeholders to discover product and domain requirements • Requirements classification and organization • Grouping and organizing requirements to facilitate analysis • Prioritization and negotiation • Prioritizing requirements and resolving requirements conflicts. • Requirementsdocumentation • Requirements are documented and input into the next round of the spiral.

  14. Elicitation and Analysis spiral

  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 organizerequirements.

  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.

  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) Suzanne & James Robertson, Atlantic Systems Guild part of “SA/SD”

  18. Volere Requirements Process Start here

  19. Volere requirement shell

  20. KARE workbench architecture

  21. Sommerville’s VORD method

  22. VORD standard forms two points of reference

  23. Interviewing • RE’s meet with stakeholders to discuss the system currently in place and the system to be developed. • May be: • formalorinformal • closed(with a pre-defined agenda), open (no pre-defined agenda), or a mix • Useful for learning how stakeholders might affect or be affected by the system. (cont'd)

  24. Interviewing (cont’d) • Less useful for learning about domain requirements since: • RE’s may not understand domain-specific terminology; • stakeholders may not communicate such requirements because they are so obvious (to the stakeholders) • Gause & Weinberg (“Exploring Requirements: Quality Before Design,” Dorset House, 1989) describe many useful interviewing techniques.

  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

  26. Scenario elements • System state at the beginning of the scenario (if relevant) • Sequence of events for a specific case of some generic task the system is required to accomplish. • Any relevant concurrent activities. • System state at the completion of the scenario.

  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]. (Compare this to the interface and operational specification examples from the Chap. 6 lecture notes.)

  28. Scenario-Based Requirements Engineering (Thebaut) • A CASE tool supports the rapid construction of an operational specification of the desired system and its environment. • Utilizes a forward chaining, parallel, rule-based language. • An interpreter executes the specification toproduce natural language based scenarios of system behavior.

  29. Scenario representation in VORD (Sommerville) • VORD supports the graphical description of multi-threaded “event scenarios” to document system behavior: • Data provided and delivered • Control information • Exception processing • The next expected event • Multi-threading supports description of exceptions. (blurs the distinction between scenarios and operational specifications)

  30. Scenario for a “start transaction” event different scenarios different scenarios

  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 diagramsshow the sequence of event processing.

  32. Library use-cases

  33. Catalogue management sequence diagram time

  34. Social and organizational factors • All software systems are used in a social and organizational context. This can influence or even dominate system requirements. • Good analysts must be sensitive to these factors, but there is currently no systematic way to tackle their analysis.

  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.

  36. Ethnography • A social scientistobserves and analyzeshow people actually work. • Subjects do not have toexplain 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. (Good for studying existing practices, but how will things change when the new system is introduced?)

  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 studiesexisting practiceswhich may not be relevant when a new system is put into place.

  38. Requirements Validation attributes techniques

  39. Requirements validation • Concerned with whether or not the requirements define a system that the customer really wants.(as opposed to needs?) • Requirements error costs are high, so early validation is very important.(Fixing a requirements error after delivery may cost 100 times that of fixing an error during implementation.)

  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?)

  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)

  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…who?) • Reviews may be formal or informal… • Good communication between developers, customers and users can resolve problems at an early stage.

  43. Review check-list • Verifiability: Is the requirement testable? • Comprehensibility: Is the requirement understandable? • Traceability: Is the origin of the requirement clearly stated?and rationale! • Adaptability: Can the requirement be changed with minimum impact on other requirements?(Especially when change is anticipated!)

  44. Requirements Management Enduring vs. volatile requirements Planning considerations Traceability CASE support Change management process

  45. Requirements management… • …is the process of understanding and controllingrequirements 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.

  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.)

  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 changingsystems or processes within the organization.

  48. Requirements management planning requires decisions on: • Requirements identification – how requirements will be individually identified • A change management process – to be followed when analyzing the impact and costs of a requirements change • Traceability policies – the amount of information about requirements relationships that is maintained • CASE tool support – the tool support required to help manage requirements change

  49. Traceability… • …is concerned with the relationshipsbetween requirements, their sources, and the system design. • Types of traceability: • Source traceability – links from requirements to stakeholders who proposed the requirements. (or other sources) • Requirements traceability – links between dependent requirements. • Design traceability – links from the requirements to the design.

  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.)

More Related