Chapter 7 Requirements Engineering - PowerPoint PPT Presentation

chapter 7 requirements engineering n.
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 7 Requirements Engineering PowerPoint Presentation
Download Presentation
Chapter 7 Requirements Engineering

play fullscreen
1 / 53
Download Presentation
Chapter 7 Requirements Engineering
Download Presentation

Chapter 7 Requirements Engineering

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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 • 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