1 / 53

Chapter 7 Requirements Engineering

Chapter 7 Requirements Engineering. Objectives. Introduce Requirements Engineering concepts Introduce major tasks of Requirements Engineering. Overview . Requirements engineering helps software engineers better understand the problems they are trying to solve.

jiro
Download Presentation

Chapter 7 Requirements Engineering

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 7Requirements Engineering SWE311_Ch07 (071) Software & Software Engineering

  2. Objectives • Introduce Requirements Engineering concepts • Introduce major tasks of Requirements Engineering SWE311_Ch07 (071) Software & Software Engineering

  3. Overview • Requirements engineering helps software engineers better understand the problems they are trying to solve. • Building an elegant computer solution that ignores the customer's needs helps no one. • It is very important to understand the customer's wants and needs before you begin designing or building a computer-based solution. • The requirements engineering process begins with inception, moves on to elicitation, elaboration, negotiation, problem specification, and ends with review or validation of the specification. • The intent of requirements engineering is to produce a written understanding of the customer's problem. • Several different work products might be used to communicate this understanding (user scenarios, function and feature lists, analysis models, or specifications). SWE311_Ch07 (071) Software & Software Engineering

  4. Requirements Engineering • Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s) • Engineering: implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant . . . etc. • RequirementEngineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a system. • RE means that requirements for a product are defined, managed and tested systematically SWE311_Ch07 (071) Software & Software Engineering

  5. Requirements Engineering • Must be adapted to the needs of a specific process, project, product, or people doing the work. • Begins during the software engineering communication activity and continues into the modeling activity. • In some cases requirements engineering may be abbreviated, but it is never abandoned. • It is essential that the software engineering team understand the requirements of a problem before the team tries to solve the problem. SWE311_Ch07 (071) Software & Software Engineering

  6. Types of Requirements • Functional requirement • A requirement that specifies a function or service that a system must be capable of performing from user’s point of view. • Non-functional requirement • A requirement that describes the property of the system including performance, reliability, usability etc. SWE311_Ch07 (071) Software & Software Engineering

  7. What do we achieve by end of RE • Full understanding of what the stakeholders really need of the system • Complete and accurate representation of that to be communicated to system developers SWE311_Ch07 (071) Software & Software Engineering

  8. Characteristics of a Good Requirement • Clear and Unambiguous • standard structure • has only one possible interpretation • Not more than one requirement in one sentence • Correct • A requirement contributes to a real need • Understandable • A reader can easily understand the meaning of the requirement • Verifiable • A requirement can be tested • Complete • Consistent • Traceable SWE311_Ch07 (071) Software & Software Engineering

  9. Why is Getting Good Requirements Hard? • Stakeholders don’t know what they really want. • Stakeholders express requirements in their own terms. • Different stakeholders may have conflicting requirements. • Organisational and political factors may influence the system requirements. • The requirements change during the RE process. New stakeholders may emerge and the business environment change. SWE311_Ch07 (071) Software & Software Engineering

  10. Requirements Engineering Tasks • Inception • Elicitation • Elaboration • Negotiation • Specification • Requirements Validation • Requirements management SWE311_Ch07 (071) Software & Software Engineering

  11. Requirements Engineering-I • Inception—ask a set of questions that establish … • basic understanding of the problem • the people who want a solution • the nature of the solution that is desired, and • the effectiveness of preliminary communication and collaboration between the customer and the developer SWE311_Ch07 (071) Software & Software Engineering

  12. Elicitation • Elicitation—elicit requirements from all stakeholders • Find out from customers what the product objectives are • what is to be done • how the product fits into business needs, and • how the product is used on a day to day basis SWE311_Ch07 (071) Software & Software Engineering

  13. Elaboration • Elaboration—create an analysis model that identifies data, function and behavioral requirements • Focuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitation SWE311_Ch07 (071) Software & Software Engineering

  14. Negotiation • Negotiation—agree on a deliverable system that is realistic for developers and customers • Requirements are categorized and organized into subsets • Relations among requirements identified • Requirements reviewed for correctness • Requirements prioritized based on customer needs SWE311_Ch07 (071) Software & Software Engineering

  15. Requirements Engineering-II • Specification—can be any one (or more) of the following: • A written document • A set of models • A formal mathematical specification • A collection of user scenarios (use-cases) • A prototype SWE311_Ch07 (071) Software & Software Engineering

  16. Requirements Validation • Requirements Validation—formal technical review mechanism that looks for • errors in content or interpretation • areas where clarification may be required • missing information • inconsistencies (a major problem when large products or systems are engineered) • conflicting or unrealistic (unachievable) requirements. SWE311_Ch07 (071) Software & Software Engineering

  17. Requirements management • Set of activities that help project team to identify, control, and track requirements and changes as project proceeds • Many of these activities are identical to those that make up the software configuration management (SCM) process • Requirements are first identified, tagged with a unique identifier and classified by type (functional, data, behavioral, interface, or output) • Traceability tables (e.g., features, source, dependency, subsystem, interface) are developed and updated any time a requirement is modified) • Database systems are invaluable in helping software teams track requirement changes SWE311_Ch07 (071) Software & Software Engineering

  18. Traceability Tables • Features traceability table (shows how requirements relate to customer observable features) • Source traceability table (identifies source of each requirement) • Dependency traceability table (indicate relations among requirements) • Subsystem traceability table (requirements categorized by subsystem) • Interface traceability table (shows requirement relations to internal and external interfaces) SWE311_Ch07 (071) Software & Software Engineering

  19. Initiating Requirements Engineering Process • Identify stakeholders • “who else do you think I should talk to?” • Recognize multiple points of view • Work toward collaboration • The first questions • Who is behind the request for this work? • Who will use the solution? • What will be the economic benefit of a successful solution • Is there another source for the solution that you need? SWE311_Ch07 (071) Software & Software Engineering

  20. The next set of questions enable developers to better understand the problem and the customer's perceptions of the solution • How would you characterize good output form a successful solution? • What problem(s) will this solution address? • Can you describe the business environment in which the solution will be used? • Will special performance constraints affect the way the solution is approached? SWE311_Ch07 (071) Software & Software Engineering

  21. The final set of questions focuses on communication effectiveness • Are you the best person to give "official" answers to these questions? • Are my questions relevant to your problem? • Am I asking too many questions? • Can anyone else provide additional information? • Should I be asking you anything else? SWE311_Ch07 (071) Software & Software Engineering

  22. Eliciting Requirements • meetings are conducted and attended by both software engineers and customers • rules for preparation and participation are established • A flexible agenda is suggested • a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting • a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used • the goal is • to identify the problem • propose elements of the solution • negotiate different approaches, and • specify a preliminary set of solution requirements SWE311_Ch07 (071) Software & Software Engineering

  23. Eliciting Requirements SWE311_Ch07 (071) Software & Software Engineering

  24. Quality Function Deployment • Function deployment determines the “value” (as perceived by the customer) of each function required of the system • Information deployment identifies data objects and events • Task deployment examines the behavior of the system • Value analysis determines the relative priority of requirements SWE311_Ch07 (071) Software & Software Engineering

  25. User-scenarios/use-cases • describe how the system will be used • Developers and users create a set of usage threads for the system to be constructed SWE311_Ch07 (071) Software & Software Engineering

  26. Elicitation Work Products • a statement of need and feasibility. • a bounded statement of scope for the system or product. • a list of customers, users, and other stakeholders who participated in requirements elicitation • a description of the system’s technical environment. • a list of requirements (preferably organized by function) and the domain constraints that apply to each. • a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. • any prototypesdeveloped to better understand requirements. SWE311_Ch07 (071) Software & Software Engineering

  27. Use-Cases • A collection of user scenarios that describe the thread of usage of a system • Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way • Each scenario answers the following questions: • Who is the primary actor, the secondary actor (s)? • What are the actor’s goals? • What preconditions should exist before the story begins? • What main tasks or functions are performed by the actor? • What extensions might be considered as the story is described? • What variations in the actor’s interaction are possible? • What system information will the actor acquire, produce, or change? • Will the actor have to inform the system about changes in the external environment? • What information does the actor desire from the system? • Does the actor wish to be informed about unexpected changes? SWE311_Ch07 (071) Software & Software Engineering

  28. Use-case Drawbacks • Lack of formality in use-case descriptions • Not all systems have explicitly defined actors • Use-cases are not inherently object-oriented • Developers have a tendency to functionally decompose use-cases. SWE311_Ch07 (071) Software & Software Engineering

  29. Use Case Modeling • A full use-case model comprise of: • A diagram, describing relations between use-cases and actors. • A document describing the use case in details • Use Case • A sequence of actions a system performs to yield an observable result of value to a particular actor • Stevens/Pooley: A task which an actor needs to perform with the help of the system • Actor • Someone or something outside the system that interacts with the system • A user of the system in a particular role • Actors are NOT part of the system SWE311_Ch07 (071) Software & Software Engineering

  30. Use Case Diagram Objective • Create a semi-formal model of the functional requirements • Analyze and define: • Scope • External interfaces • Scenarios and reactions SWE311_Ch07 (071) Software & Software Engineering

  31. What Makes Good Use-Case Specification? • Lack of ambiguity • Each requirement must be interpreted in a single manner. • Completeness • They should cater for all current demands of the system. • Consistency • Requirements should not conflict with each other. If there are, tradeoffs must be detected and discussed. • Avoid design • Requirements should raise a need, not answer it. (Why?) SWE311_Ch07 (071) Software & Software Engineering

  32. Use Cases • Each use case has a name • In the UML, a use case is represented as an oval • A family (or set, or class) of scenarios • A sequence of interactions • A set of different but related scenarios • Documenting Use Cases • A UML Diagram showing all of them • Actors are stick-figures; use cases are ovals • For each use case define using English • A clear textual description • A set of scenarios in outline form SWE311_Ch07 (071) Software & Software Engineering

  33. Relationships between Use Cases • UML supports two relationships between two use cases • <<includes>> • before UML 1.3 <<includes>> was <<uses>> • The source use case always includes the actions specified in the target use case • <<extends>> • The target use case my include the behavior of the source use case SWE311_Ch07 (071) Software & Software Engineering

  34. Documenting Use Cases • Use case name • Each use case is given a name. • Summary • A brief description of the use case, typically one or two sentences. • Dependency • Description of whether the use case depends on other use cases, that is, whether it includes or extends another use case. • Actors • Names of the actors that participate in the use case SWE311_Ch07 (071) Software & Software Engineering

  35. Documenting Use Cases (Cont’d) • Preconditions • One or more conditions that must be true at the start of the use case • Description • Description of the main sequence of the use case, which is the most usual sequence of interactions between the actor and the system. • Alternatives • Description of alternative branches off the main sequence. • Postcondition • Condition that is always true at the end of the use case if the main sequence has been followed. SWE311_Ch07 (071) Software & Software Engineering

  36. Preconditions • One or more conditions that must be true at the start of the use case • Examples • User account exists • User has enough money in her account • There is enough disk space SWE311_Ch07 (071) Software & Software Engineering

  37. Post-Conditions • Condition that is always true at the end of the use case if the main sequence has been followed. • Examples • Money was transferred to the user account • User is logged in • The file is saved to the hard-disk SWE311_Ch07 (071) Software & Software Engineering

  38. Use-Cases – Common Mistakes • Complex diagram • No system • No actor • Too many user interface details • “User types ID and password, clicks OK or hits Enter” • Very low goal details • User provides name • User provides address • User provides telephone number • … SWE311_Ch07 (071) Software & Software Engineering

  39. Example 1: Validate PIN Use Case • Use case name • Validate PIN • Summary • System validates customer PIN. • Actor • ATM Customer • Precondition • ATM is idle, displaying a Welcome message. SWE311_Ch07 (071) Software & Software Engineering

  40. Example 1: Validate PIN Use Case (Cont’d) • Description • Customer inserts the ATM card into the Card Reader. • If the system recognizes the card, it reads the card number. • System prompts customer for PIN number • Customer enters PIN • System Checks the expiration date and whether the card is lost or stolen. • If card is valid, the system then checks whether the user-entered PIN matches the card PIN maintained by the system. • numbers match, the system checks that accounts are accessible with the ATM card. • System displays customer accounts and prompts customer for transaction type: Withdrawal, Query, or Transfer. SWE311_Ch07 (071) Software & Software Engineering

  41. Example 1: Validate PIN Use Case (Cont’d) • Alternatives • If the system does not recognize the card, the card is ejected. • If the system determines that the card date has expired, the card is confiscated. • If the system determines that the card has been reported lost or stolen, the card is confiscated. • If the customer-entered PIN does not math the PIN number for this card, the system re-prompts for the PIN. • If the customer enters the incorrect PIN three times, the system confiscates the card. • If the customer enters Cancel, the system cancels the transaction and ejects the card. • Postcondition • Customer PIN has been validated. SWE311_Ch07 (071) Software & Software Engineering

  42. Example 2: Withdraw Funds Use Case • Use case name • Withdraw Funds • Summary • Customer withdraws a specific amount of funds from a valid bank account. • Actor • ATM Customer • Dependency • Include Validate PIN abstract use case • Precondition • ATM is idle, displaying a Welcome message. SWE311_Ch07 (071) Software & Software Engineering

  43. Example 2: Withdraw Funds Use Case (Cont’d) • Description • Include Validate PIN abstract use case. • Customer selects Withdrawal, enters the amount, and selects the account number. • System checks whether customer has enough funds in the account and whether the daily limit will not be exceeded. • If all checks are successful, system authorizes dispensing of cash. • System dispenses the cash amount. • System prints a receipt showing transaction number, transaction type, amount withdrawn, and account balance. • System ejects card. • System displays Welcome Message. SWE311_Ch07 (071) Software & Software Engineering

  44. Example 2: Withdraw Funds Use Case (Cont’d) • Alternatives • If the system determines that the account number is invalid, it displays an error message and ejects the card. • If the system determines that there are insufficient funds in the customer’s account, it displays an apology and eject the card. • If the system determines that the maximum allowable daily withdrawal amount has been exceeded, it displays an apology and ejects the card. • If the ATM is out of funds, the system displays an apology, ejects the card, and shuts down the ATM. • Postcondition • Customer funds have been withdrawn. SWE311_Ch07 (071) Software & Software Engineering

  45. The sections of a use case • Name. The name should implicitly express the user's intent or purpose of the use case • Identifier [Optional]. A unique identifier, such as "UC1701," that can be used in other project artifacts to refer to the use case. • Description. Several sentences summarizing the use case. • Actors [Optional]. The list of actors associated with the use case. SWE311_Ch07 (071) Software & Software Engineering

  46. The sections of a use case (cont.) • Status [Optional]. An indication of the status of the use case, typically one of: work in progress, ready for review, passed review, or failed review. • Frequency. How often this use case is invoked by the actor. Example, once per each user login or once per month. • Preconditions. A list of the conditions, if any, that must be met before a use case may be invoked. • Postconditions. A list of the conditions, if any, that will be true after the use case finishes successfully. SWE311_Ch07 (071) Software & Software Engineering

  47. The sections of a use case (cont.) • Extended use case [Optional]. The use case that this use case extends (if any). • Included use cases [Optional]. A list of the use cases this one includes. • Assumptions [Optional]. Any important assumptions about the domain that you have made when writing this use case. • Basic course of action. The main path of logic an actor follows through a use case. Often referred to as the main path because it describes how the use case works when everything works as it normally should. • Alternate courses of action. The infrequently used paths of logic in a use case, paths that are the result of an alternate way to work, an exception, or an error condition. SWE311_Ch07 (071) Software & Software Engineering

  48. The sections of a use case (cont.) • Change history [Optional]. Details about when the use case was modified, why, and by whom. • Issues [Optional]. A list of issues or action items, if any, that are related to the development of this use case. • Decisions . A list of critical decisions pertaining to the content of the use case. It is important to record these decisions to maintain a group memory. SWE311_Ch07 (071) Software & Software Engineering

  49. An Example • A complete example may be found in the following site • http://www.cs.gordon.edu/courses/cs211/ATMExample/index.html SWE311_Ch07 (071) Software & Software Engineering

  50. Negotiating Requirements • Identify the key stakeholders • These are the people who will be involved in the negotiation • Determine each of the stakeholders “win conditions” • Win conditions are not always obvious • Negotiate • Work toward a set of requirements that lead to “win-win” SWE311_Ch07 (071) Software & Software Engineering

More Related