1 / 47

Chapter 6

Chapter 6. Requirements Engineering Processes Processes used to discover, analyze, and validate system requirements. Requirements engineering processes. They vary widely depending on the application domain the people involved the organization developing the requirements .

garin
Download Presentation

Chapter 6

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 6 Requirements Engineering Processes Processes used to discover, analyze, and validate system requirements

  2. Requirements engineering processes • They vary widely depending on • the application domain • the people involved • the organization developing the requirements CSDP 405 Software Engineering I

  3. Four activities • Requirements elicitation • Requirements analysis • Requirements validation • Requirements management CSDP 405 Software Engineering I

  4. The requirements engineering processBlock Diagram CSDP 405 Software Engineering I

  5. 1. Feasibility studies • Determine if the proposed system • will contribute to organizational objectives, • can be built with current technology within budget, and • can be integrated with other systems in use. • Involving • information assessment • information collection • report writing CSDP 405 Software Engineering I

  6. 2. Elicitation and analysis • Working with the customers to understand the application domain • Determining the services that the system should provide • Determining the system's operational constraints • May involve (called stakeholders) • end-users • managers • engineers involved in maintenance • domain experts • trade unions, etc. CSDP 405 Software Engineering I

  7. Problems of requirements analysis • Stakeholders don’t know what they really want. • Stakeholders express requirements in their own terms. • Stakeholders may have conflicting requirements. • Organizational and political factors may influence the system requirements. • The requirements may change during the analysis process due to • emergence of new stakeholders or • change in business environment. CSDP 405 Software Engineering I

  8. Elicitation and analysis activities • Requirements discovery • Requirements classification and organisation • Requirements prioritization and negotiation • Requirements documentation CSDP 405 Software Engineering I

  9. Elicitation and analysis spiral process CSDP 405 Software Engineering I

  10. 1) Viewpoint-oriented elicitation • Stakeholders represent different ways of looking at a problem • It recognises multiple perspectives and provides a framework for discovering conflicts in the requirements proposed by different stakeholders CSDP 405 Software Engineering I

  11. Example: Banking ATM system • It is an automated-teller-machine system which provides some automated banking services • It offers some services to customers of the bank who own the system and a narrower range of services to other customers • Services include cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds CSDP 405 Software Engineering I

  12. Different viewpoints toward an ATM • Bank customers • Representatives of other banks • Hardware and software maintenance engineers • Marketing department • Bank managers and counter staff • Database administrators and security staff • Communication engineers • Personnel department • National banking regulators CSDP 405 Software Engineering I

  13. Types of viewpoint • Interactor viewpoints • Represent people or other systems that interact directly with the system • Provide detailed system requirements covering the system features and interfaces • Indirect viewpoints • Represent stakeholders who do not use the system themselves but who influence the requirements in some way • Provide higher-level organizational requirements and constraints • Domain viewpoints • Represent domain characteristics and constraints that influence the system requirements • Provide domain constraints CSDP 405 Software Engineering I

  14. Viewpoints Example (LIBSYS) All VPs Indirect Domain Interactor Library Manager Finance Article Provider Library staff UI standards Classification System Users Students Staff External System Managers Catalogues CSDP 405 Software Engineering I

  15. 2) Interviewing • Formal or informal interviews with system stakeholders are part of most requirements engineering processes • Requirement Engineering Team proposes questions • Stakeholders answer the questions • Requirements are derived from the answers CSDP 405 Software Engineering I

  16. Two types interviews • Closed interviews • Open interviews CSDP 405 Software Engineering I

  17. Effective interviewers • Two characteristics • 1. open-minded, avoid preconceived ideas • 2. prompt the interviewee to start discussions CSDP 405 Software Engineering I

  18. Advantages • Interviews are good for • Getting an overall understanding of what stakeholders do • How they interact with the system • The difficulties they might face CSDP 405 Software Engineering I

  19. Disadvantages • Interviews are not so good for understanding the requirements from the application domain • Application specialists use terminology and jargon that is specific to a domain • Some domain knowledge is so familiar to stakeholders so they do not want to mention or cannot explain CSDP 405 Software Engineering I

  20. 3) Scenarios • Scenarios are descriptions of how a system is used in practice. • They are helpful in requirements elicitation • Scenarios are useful for adding detail to an outline requirements CSDP 405 Software Engineering I

  21. Scenario descriptions may include • System state at the beginning of the scenario • Normal flow of events in the scenario • What can go wrong and how this is handled • Other concurrent activities • System state on the completion of the scenario CSDP 405 Software Engineering I

  22. Type • Event Scenario • Text Scenario CSDP 405 Software Engineering I

  23. Event scenarios • To describe how a system responds to a event CSDP 405 Software Engineering I

  24. Event scenario - start transaction CSDP 405 Software Engineering I

  25. Text Scenario Example • To describe how a user of the LIBSYS may use the system. • The user wishes to print a personal copy of an article • Free to subscribers • The user knows the article, title and date of publication CSDP 405 Software Engineering I

  26. Text Scenario Example CSDP 405 Software Engineering I

  27. Cont. CSDP 405 Software Engineering I

  28. 4) Use cases • Use-cases are a scenario based technique in the UML (Unified Modelling Language) • which identify the actors in an interaction • which describe the interaction itself • A set of use cases should describe all possible interactions with the system • Sequence diagrams may be used to add details CSDP 405 Software Engineering I

  29. Use-cases Examples CSDP 405 Software Engineering I

  30. Use cases for the Library System CSDP 405 Software Engineering I

  31. System interactions for Article printing CSDP 405 Software Engineering I

  32. Social and organizational factors • Software systems are used in a social and organizational context. This can influence or even dominate the system requirements • Social and organizational factors are not a single viewpoint but are influences on all viewpoints • Good analysts must be sensitive to these factors but currently no systematic way to tackle their analysis CSDP 405 Software Engineering I

  33. Ethnography • It is an observational technique that can be used to understand social and organizational requirements • An analyst immerses himself in the working environment where the system will be used • The day-to-day work is observed and notes made of the actual tasks in which participants are involved • The value of ethnography is that it helps discover implicit system requirements CSDP 405 Software Engineering I

  34. 3. Requirements validation • Concerned with demonstrating that the requirements define the system that the customer really wants • Requirements error costs are high so validation is very important • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error CSDP 405 Software Engineering I

  35. Requirements checking • 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 • Use a set of tests to demonstrate the system meets each specified requirement. CSDP 405 Software Engineering I

  36. Requirements validation techniques • Requirements reviews • Systematic manual analysis of the requirements • Prototyping • Using an executable model of the system to check requirements. Covered in Chapter 8 • Test-case generation • Developing tests for requirements to check testability • Consistency analysis • Checking the consistency of a structured requirements description CSDP 405 Software Engineering I

  37. Requirements reviews • Regular reviews should be held while the requirements definition is being formulated • Both client and contractor staff should be involved in reviews • Reviews may be formal (with completed documents) or informal CSDP 405 Software Engineering I

  38. Review checks • Verifiability • Is the requirement realistically testable? • Comprehensibility • Is the requirement properly understood? • Traceability • Is the origin of the requirement clearly stated? • Adaptability • Can the requirement be changed without a large impact on other requirements? CSDP 405 Software Engineering I

  39. Automated consistency checking CSDP 405 Software Engineering I

  40. 4. Requirements management • It is the process of managing changing requirements during the requirements engineering process and system development • Requirements are inevitably incomplete and inconsistent • New requirements emerge during the process as business needs change and a better understanding of the system is developed • Different viewpoints have different requirements and these are often contradictory CSDP 405 Software Engineering I

  41. Requirements change • The priority of requirements from different viewpoints changes during the development process • System customers may specify requirements from a business perspective that conflicts with end-user requirements • The business and technical environment of the system changes during its development CSDP 405 Software Engineering I

  42. Requirements management planning Plan for: • Requirements identification: How requirements are individually identified? • A change management process: How to assess the impact and cost of changes? • Traceability policies: What relationships among requirements and system design need to be maintained? • CASE tool support CSDP 405 Software Engineering I

  43. Traceability Three types of traceability information may be maintained: • Source traceability • Links from requirements to stakeholders who proposed these requirements • Requirements traceability • Links between dependent requirements • Design traceability • Links from the requirements to the design CSDP 405 Software Engineering I

  44. A traceability matrix CSDP 405 Software Engineering I

  45. CASE tool support • Requirements storage • Requirements should be managed in a secure, managed data store • Change management • The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated. • Traceability management • Automated retrieval of the links among requirements CSDP 405 Software Engineering I

  46. Key points • The process includes a feasibility study, and elicitation, analysis, specification, and management of requirements. • Requirements analysis involves domain understanding, and requirements collection, classification, structuring, prioritization, and validation. • Each system have multiple stakeholders with different requirements. CSDP 405 Software Engineering I

  47. Key points (continued) • Social and organizational factors influence system requirements. • Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability. • Business changes inevitably lead to changes in requirements. • Requirements management includes planning and change management. CSDP 405 Software Engineering I

More Related