1 / 76

Chapter 4: Requirements Elicitation

Chapter 4: Requirements Elicitation. Qutaibah Malluhi Software Engineering Qatar University. Based on slides by Bernd Bruegge & Allen H. Dutoit . Overview. Agenda. Overview What is requirement elicitation? Requirements are challenging Concepts Problem statement Types of requirements

mason-weber
Download Presentation

Chapter 4: Requirements Elicitation

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 4: Requirements Elicitation Qutaibah Malluhi Software Engineering Qatar University Based on slides by Bernd Bruegge & Allen H. Dutoit

  2. Overview

  3. Agenda • Overview • What is requirement elicitation? • Requirements are challenging • Concepts • Problem statement • Types of requirements • Requirements validation • Types of requirement elicitation • Scenarios • Use cases • Requirements elicitation activities

  4. Where are we right now? • Three ways to deal with complexity: • Abstraction • Decomposition (Technique: Divide and conquer) • Hierarchy (Technique: Layering) • Two ways to deal with decomposition: • Object-orientation and functional decomposition • Functional decomposition leads to unmaintainable code • Depending on the purpose of the system, different objects can be found • What is the right way? • Start with a description of the functionality (Use case model). Then proceed by finding objects (object model). • What activities and models are needed? • This leads us to the software lifecycle we use in this class

  5. Software Lifecycle Definition • Software lifecycle: • Set of activities and their relationships to each other to support the development of a software system • Typical Lifecycle questions: • Which activities should I select for the software project? • What are the dependencies between activities? • How should I schedule the activities? • What is the result of an activity

  6. Example: Selection of Software Lifecycle Activities for a specific project The Hacker knows only one activity Implementation Activities used this course Requirements Elicitation Analysis System Design Object Design Implemen- tation Testing Each activity produces one or more models

  7. class... class... class... class.... Software Lifecycle Activities Requirements Elicitation Requirements Analysis System Design Object Design Implemen- tation Testing Implemented By Expressed in Terms Of Structured By Realized By Verified By ? ? Application Domain Objects Solution Domain Objects Use Case Model Source Code SubSystems Test Cases

  8. What is Requirement Elicitation?

  9. Requirements • Elicitation: What does the customer want?

  10. Requirements Elicitation I want you to build a game ... client game developer

  11. Requirements Elicitation I want an RPG better than anything seen before! client game developer

  12. Requirements Elicitation Ok ... off you go! Call me when its done. client game developer

  13. Requirements • Problem Statement: What does the customer say they want? • Elicitation: What does the customer really want?

  14. Requirements Elicitation Oh yeah ... Here is the description of the game. client game developer

  15. Requirements Elicitation BTW, it needs to be done in 3 months and I only want to pay you $3000 to build it. client game developer

  16. Requirements • Problem Statement: What does the customer say they want? • Elicitation: What does the customer really want? • Analysis: Formalize, analyze  What can provide?

  17. Requirements Elicitation I want an RPG better than anything seen before! client game developer

  18. Requirements Elicitation Oh yeah ... Here is the description of the game. client game developer

  19. Requirements Elicitation It needs to be ready in 3 months! client game developer

  20. So how much will it cost? client game developer

  21. Requirements Analysis Just write a blank check. I’ll fill in the amount when I’m done! client game developer

  22. Requirements • Problem Statement: What does the customer say they want? • Elicitation: What does the customer really want? • Analysis: Formalize, analyze  What can provide? • System Requirements Specification: What do we agree to provide?

  23. Requirements Specification Game Design Document game developer client System Requirements Specification

  24. First Step in Establishing the Requirements: System Identification • The development of a system is not just done by taking a snapshot of a scene (domain) • Important requirement process questions: • How can we identify the purpose of a system? • How to define of the system boundary • What is inside, what is outside the system? • Two general requirement activities: • Requirements Elicitation: Definition of the system in terms understood by the customer • “Problem Description” and “System Specification” • Requirements Analysis: Technical specification of the system in terms understood by the developer • “Analysis model”

  25. System Specification vs. Analysis Model • Both models focus on the requirements from the user view of the system. • System specification uses natural language (derived from the problem statement) • The analysis model uses formal or semi-formal notation (for example, a graphical language like UML) • The starting point is the problem statement

  26. Problem Statement Generation Requirements Elicitation Requirements Analysis Products of Requirements Process (Activity Diagram) Problem Statement system specification: Model analysis model: Model

  27. Specifying Requirements is Challenging

  28. Requirements are Hard “The hardest single part of building a software system is deciding precisely what to build.No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” • Frederick P. Brooks Jr. in “No Silver Bullet: Essence and Accidents of Software Engineering.”

  29. Requirements are Hard “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.” • Frederick P. Brooks Jr. in “No Silver Bullet: Essence and Accidents of Software Engineering.”

  30. Requirement Errors are Common • 1992 Iowa State study of safety-critical errors in software systems for Voyager and Galileo: The majority of safety-critical software errors were not caused in the design or implementation process. They were due to errors in the requirements specification. The systems as specified were flawed.

  31. Cost of Delay in Fixing Requirements Errors Data: Boehm & Papaccio (1988) IEEE Trans. Software Eng. 200-fold increase after delivery Nominal unit cost 20-fold increase

  32. Why Hard? • Customer’s don’t usually know what they want/need • Even if they do know what they want/need, they are likely to change their minds • Requires bridging communication gap between user, client and developer

  33. Growth in requirements % increase in requirements during project life Source: Applied Software Measurement, Capers Jones, 1997. Based on 6,700 systems.

  34. Communication Gap • Requires collaboration and communication of people with different backgrounds • Users with application domain knowledge • Developers with solution domain knowledge (design knowledge, implementation knowledge) • Client with constraints (time, budget, etc.) (can be different than the user’s entity) • Bridging the gap between user and developer: • Scenarios: Example of the use of the system in terms of a series of interactions with between the user and the system • Use cases: Abstraction that describes a class of scenarios

  35. Problem Statement

  36. Problem Statement • The problem statement is developed by the client as a description of the problem addressed by the system • Other words for problem statement: • Statement of Work

  37. Ingredients of a Problem Statement • Current situation: The Problem to be solved • Description of one or more scenarios • Requirements • Functional and Nonfunctional requirements • Constraints (“pseudo requirements”) • Deliverables • Project Schedule • Major milestones that involve interaction with the client including deadline for deliverables • Target environment • The environment in which the delivered system has to perform a specified set of system tests • Client Acceptance Criteria • Criteria for the system tests

  38. Current Situation: The Problem To Be Solved • There is a problem in the current situation • Examples: • The response time when playing letter-chess is far too slow. • I want to play Go, but cannot find players on my level. • What has changed? Why can address the problem now? • There has been a change, either in the application domain or in the solution domain • Change in the application domain • A new function (business process) is introduced into the business • Example: We can play highly interactive games with remote people • Change in the solution domain • A new solution (technology enabler) has appeared • Example: The internet allows the creation of virtual communities.

  39. ARENA: The Problem • The Internet has enabled virtual communities • Groups of people sharing common of interests but who have never met each other in person. Such virtual communities can be short lived (e.g people in a chat room or playing a multi player game) or long lived (e.g., subscribers to a mailing list). • Many multi-player computer games now include support for virtual communities. • Players can receive news about game upgrades, new game levels, announce and organize matches, and compare scores. • Currently each game company develops such community support in each individual game. • Each company uses a different infrastructure, different concepts, and provides different levels of support. • This redundancy and inconsistency leads to problems: • High learning curve for players joining a new community, • Game companies need to develop the support from scratch • Advertisers need to contact each individual community separately.

  40. ARENA: The Objectives • Provide a generic infrastructure for operating an arena to • Support virtual game communities. • Register new games • Register new players • Organize tournaments • Keeping track of the players scores. • Provide a framework for tournament organizers • to customize the number and sequence of matchers and the accumulation of expert rating points. • Provide a framework for game developers • for developing new games, or for adapting existing games into the ARENA framework. • Provide an infrastructure for advertisers.

  41. Requirement Types FURPS+: Functional, Usability, Reliability, Performance, and Supportability (+ constraints)

  42. Types of Requirements • Functional requirements: • Describe the interactions between the system and its environment independent from implementation • Examples: • An ARENA operator should be able to define a new game. • Nonfunctional requirements: • User visible aspects of the system not directly related to functional behavior. • Examples: • The response time must be less than 1 second • The ARENA server must be available 24 hours a day • Constraints (“Pseudo requirements”): • Imposed by the client or the environment in which the system operates • The implementation language must be Java • The system must interface to the dispatcher system written in 1956

  43. Functional Requirements for SatWatch SatWatch is a wrist watch that displays the time based on its current location. SatWatch uses GPS satellites to determine its location and internal data structure to convert the location into a time zone. The information stored in SatWatch and its accuracy measuring time is such that the watch owner never needs to reset the time. SatWatch adjusts the time and date displayed as the watch owner crosses time zones and political boundaries. For this reason, SatWatch has no buttons or controls available to the user. SatWatch determines the location using GPS satellites and, as such, suffers from the same limitations as all other GPS devices (e.g., inability to determine location at certain times of the day in mountainous regions). SatWatch has a two-line display showing, on the top line, the time (hour, minute, second, time zone) and on the bottom line, the date (day, date, month, year). The display technology used is such that the watch owner can see the time and date even under poor light conditions. When the political boundaries change, the watch owner may upgrade the software of the watch using the WebifyWatch device (provided with the watch) and a personal computer connected to the Internet. Focus on interactions between SatWatch and external world (owner, GPS, WebifyWatch). No implementation details (language, display tech, etc.)

  44. Nonfunctional Requirements • URPS categories of nonfunctional requirements • Usability: ease of use • E.g. GUI guidelines by client, color schemes, fonts, logos, help, documentation • Reliability • E.g. acceptable MTBF, ability to detect certain faults or to withstand specific security attacks • Performance • Response time, throughput, availability, accuracy • Supportability: ease of change after deployment • Portability, adaptability (deal with additional application concepts), maintainability (deal with new technology, fix defects), internationalization (additional conventions, languages, etc.)

  45. Usability Reliability Performance Performance Performance Supportability URPS Requirements Example (SatWatch) • Any user who knows how to read a digital watch and understands international time zone abbreviations should be able to use SatWatch without the user manual • As the SatWatch has not buttons, no software faults requiring the resetting of the watch should occur • Satwatch should display the correct time zone within 5 minutes of the end of a GPS blackout period • SatWatch should measure time within 1/100th second over 5 years • SatWatch should display time correctly in all 24 timezones • SatWatch should accept upgrades to its onboard via the Webify Watch serial interface

  46. Constraints (Pseudo Nonfunc. Reqs.) • Implementation Requirements • Tools, Programming Lang., hardware platforms • Interface Requirements • Imposed by external systems • E.g., Formats, standards, legacy systems • Operations Requirements • E.g. sys administration and management req. • Packaging Requirements • E.g., installation media, internet download, etc. • Legal Requirements • Licensing, government regulations, certification issues

  47. Implementation Requirement Interface Requirement Constraints Example (SatWatch) • All related software associated with SatWatch , including the onboard software, will be written using Java, to comply with the current company policy • SatWatch complies with the physical, electrical, and software interfaces defined by the WebifyWatch API 2.0

  48. What is usually not in the requirements? • It is desirable that none of the following is constrained by the client. Fight for it! • System structure, implementation technology • Development methodology • Development environment • Implementation language • Reusability • Notice: we are considering budget and schedule to be project attributes rather than software requirements

  49. Requirements Validation • Critical step in the development process • Usually after requirements elicitation or requirements analysis. Also at delivery (client acceptance test). • Requirements validation criteria: • Correctness: • The requirements represent the proper client’s view. • Completeness: • All possible scenarios, in which the system can be used, are described, including exceptional behavior by the user or the system • Consistency: • There are functional or nonfunctional requirements that contradict each other • Realism: • Requirements can be implemented and delivered within constraints • Traceability: • Each system function can be traced to a corresponding set of functional requirements

  50. Types of Requirements Elicitation • Greenfield Engineering • Development starts from scratch, no prior system exists • Triggered by user needs • Requirements extracted from the end users and the client • Re-engineering • Re-design and/or re-implementation of an existing system using newer technology • Triggered by technology enabler • Requirements extracted from existing system + users and client • Interface Engineering • Provide the services of an existing system in a new environment • Triggered by technology enabler or new market needs • Requirements extracted from existing systems + users and client

More Related