1. SWE311_Ch07 (071) Software & Software Engineering Slide 1 Chapter 7 Requirements Engineering

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

3. SWE311_Ch07 (071) Software & Software Engineering Slide 3 Overview Requirements engineering helps software engineers better understand the problems they are trying to solve. 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. 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. 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 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. 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). Several different work products might be used to communicate this understanding (user scenarios, function and feature lists, analysis models, or specifications).

4. SWE311_Ch07 (071) Software & Software Engineering Slide 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) 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. Engineering: implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant... etc. Requirement Engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a system. Requirement Engineering 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 RE means that requirements for a product are defined, managed and tested systematically

5. SWE311_Ch07 (071) Software & Software Engineering Slide 5 Requirements Engineering Must be adapted to the needs of a specific process, project, product, or people doing the work. 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. 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. 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. It is essential that the software engineering team understand the requirements of a problem before the team tries to solve the problem.

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

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

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

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

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

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

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

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

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

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

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

17. SWE311_Ch07 (071) Software & Software Engineering Slide 17 Requirements management Requirements management Set of activities that help project team to identify, control, and track requirements and changes as project proceeds 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 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) 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) 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 Database systems are invaluable in helping software teams track requirement changes

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

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

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

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

22. SWE311_Ch07 (071) Software & Software Engineering Slide 22 Eliciting Requirements meetings are conducted and attended by both software engineers and customers meetings are conducted and attended by both software engineers and customers rules for preparation and participation are established rules for preparation and participation are established A flexible agenda is suggested A flexible agenda is suggested a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting 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 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 the goal is to identify the problem to identify the problem propose elements of the solution propose elements of the solution negotiate different approaches, and negotiate different approaches, and specify a preliminary set of solution requirements specify a preliminary set of solution requirements

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

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

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

26. SWE311_Ch07 (071) Software & Software Engineering Slide 26 Elicitation Work Products a statement of need and feasibility. a statement of need and feasibility. a bounded statement of scope for the system or product. a bounded statement of scope for the system or product. a list of customers, users, and other stakeholders who participated in requirements elicitation a list of customers, users, and other stakeholders who participated in requirements elicitation a description of the system’s technical environment. 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 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. 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 any prototypes developed to better understand requirements.

27. SWE311_Ch07 (071) Software & Software Engineering Slide 27Use-Cases A collection of user scenarios that describe the thread of usage of a system 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 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: Each scenario answers the following questions: Who is the primary actor, the secondary actor (s)? Who is the primary actor, the secondary actor (s)? What are the actor’s goals? What are the actor’s goals? What preconditions should exist before the story begins? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What main tasks or functions are performed by the actor? What extensions might be considered as the story is described? What extensions might be considered as the story is described? What variations in the actor’s interaction are possible? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? Does the actor wish to be informed about unexpected changes?

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

29. SWE311_Ch07 (071) Software & Software Engineering Slide 29 Use Case Modeling A full use-case model comprise of: A full use-case model comprise of: A diagram, describing relations between use-cases and actors. A diagram, describing relations between use-cases and actors. A document describing the use case in details 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 Actors are NOT part of the system

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

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

32. SWE311_Ch07 (071) Software & Software Engineering Slide 32 Use Cases Each use case has a name In the UML, a use case is represented as an oval 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

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

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

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

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

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

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

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

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

41. SWE311_Ch07 (071) Software & Software Engineering Slide 41 Example 1: Validate PIN Use Case (Cont’d) Alternatives Alternatives If the system does not recognize the card, the card is ejected. 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 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 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-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 the incorrect PIN three times, the system confiscates the card. If the customer enters Cancel, the system cancels the transaction and ejects the card. If the customer enters Cancel, the system cancels the transaction and ejects the card. Postcondition Postcondition Customer PIN has been validated. Customer PIN has been validated.

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

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

44. SWE311_Ch07 (071) Software & Software Engineering Slide 44 Example 2: Withdraw Funds Use Case (Cont’d) Alternatives 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 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 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 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. If the ATM is out of funds, the system displays an apology, ejects the card, and shuts down the ATM. Postcondition Postcondition Customer funds have been withdrawn. Customer funds have been withdrawn.

45. SWE311_Ch07 (071) Software & Software Engineering Slide 45 The sections of a use case Name. The name should implicitly express the user's intent or purpose of the 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. 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. Description. Several sentences summarizing the use case. Actors [Optional]. The list of actors associated with the use case. Actors [Optional]. The list of actors associated with the use case.

46. SWE311_Ch07 (071) Software & Software Engineering Slide 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. 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. 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. 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. Postconditions. A list of the conditions, if any, that will be true after the use case finishes successfully.

47. SWE311_Ch07 (071) Software & Software Engineering Slide 47 The sections of a use case (cont.) Extended use case [Optional]. The use case that this use case extends (if any). 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. 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. 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. 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. 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.

48. SWE311_Ch07 (071) Software & Software Engineering Slide 48 The sections of a use case (cont.) Change history [Optional]. Details about when the use case was modified, why, and by whom. 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. 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. 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.

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

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

51. SWE311_Ch07 (071) Software & Software Engineering Slide 51 Key points It's not a competition It's not a competition Map out a strategy Map out a strategy Listen actively Listen actively Focus on other party's interests Focus on other party's interests Don't let it get personal Don't let it get personal Be creative Be creative Be ready to commit Be ready to commit

52. SWE311_Ch07 (071) Software & Software Engineering Slide 52 Validating Requirements-I Is each requirement consistent with the overall objective for the system/product? Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Do any requirements conflict with other requirements? Do any requirements conflict with other requirements?

53. SWE311_Ch07 (071) Software & Software Engineering Slide 53 Validating Requirements-II Is each requirement achievable in the technical environment that will house the system or product? Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Is each requirement testable, once implemented? Does the requirements model properly reflect the information, function and behavior of the system to be built. Does the requirements model properly reflect the information, function and behavior of the system to be built. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.