Oosad 03

475 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
475
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Oosad 03

  1. 1. Validating Requirements Chapter 03
  2. 2. Introduction• It is not enough to gather requirements; you also need to verify that they are correct• A wide range of experience combined with unambiguous models, reduces the chance of misunderstood requirements• Beware of gold plating• Successful projects meet the needs of their users but if you have an analysis error you wont fully meet their needs• To test your requirement models you can apply one or more of the following techniques – Use case scenario testing – User Interface walkthroughs – Requirement reviews
  3. 3. Use Case Scenario Testing• Used to test domain models, if it accurately reflects the aspects of the business that you are modeling• Steps 1. Perform domain modeling 2. Create the use case scenarios 3. Assign classes to your SMEs 4. Describe how to act out a scenario 5. Act out the scenarios 6. Update the domain model 7. Save the Scenarios
  4. 4. Create Use Case Scenarios• Conceptually similar to use cases – A use case describes the logic including the basic and alternate courses of action, for a single cohesive task – A use case scenario describes a single path of logic through one or more use cases• When you describe a use case scenario, you want to give it a name and short description and then a description of the steps to take to fulfill the scenario.• Helps to catch unusual scenarios• You can identify new scenarios in several ways – Consider tasks the system should and shouldn’t be able to handle – Explore business rules – Do some more brainstorming
  5. 5. Acting Out Scenarios• Steps 1. Call out a new scenario 2. Determine which card should handle the responsibility 3. Update the cards whenever necessary 4. Describe the processing logic 5. Collaborate if necessary 6. Pass the ball back when done
  6. 6. Use Case Name: Place OrderActors: Registered Shopper (Has an existing account, possibly with billing and shipping information), Non-registered Shopper(Does not have an existing account), Fulfillment System (processes orders for delivery to customers), Billing System (billscustomers for orders that have been placed)Triggers: The user indicates that she wants to purchase items that she has selected.Preconditions: User has selected the items to be purchased.Post-conditions: The order will be placed in the system, The user will have a tracking ID for the order, The user will know theestimated delivery date for the order.Basic Courses of Actions•The user will indicate that she wants to order the items that have already been selected.•The system will present the billing and shipping information that the user previously stored.•The user will confirm that the existing billing and shipping information should be used for this order.•The system will present the amount that the order will cost, including applicable taxes and shipping charges.•The user will confirm that the order information is accurate.•The system will provide the user with a tracking ID for the order.•The system will submit the order to the fulfillment system for evaluation.•The fulfillment system will provide the system with an estimated delivery date.•The system will present the estimated delivery date to the user.•The user will indicate that the order should be placed.•The system will request that the billing system should charge the user for the order.•The billing system will confirm that the charge has been placed for the order.•The system will submit the order to the fulfillment system for processing.•The fulfillment system will confirm that the order is being processed.•The system will indicate to the user that the user has been charged for the order.•The system will indicate to the user that the order has been placed.•The user will exit the system.
  7. 7. Alternate Flows:3A1: The user enters billing and shipping information for the order. The user desires to use shipping and billinginformation that differs from the information stored in her account.1.The user will indicate that this order should use alternate billing or shipping information.2.The user will enter billing and shipping information for this order.3.The system will validate the billing and shipping information.4.The use case continues5A1: The user will discover an error in the billing or shipping information associated with their account, and willchange it.1.The user will indicate that the billing and shipping information is incorrect.2.The user will edit the billing and shipping information associated with their account.3.The system will validate the billing and shipping information.4.The use case returns to step 2 and continues.5A2: The user will discover an error in the billing or shipping information that is uniquely being used for thisorder, and will change it.1.The user will indicate that the billing and shipping information is incorrect.2.The user will edit the billing and shipping information for this order.3.The use case returns to step 3A1 step 3.10A1: The user will determine that the order is not acceptable (perhaps due to disatisfaction with theestimated delivery date) and will cancel the order.1.The user will request that the order be cancelled.2.The system will confirm that the order has been cancelled.3.The use case ends.
  8. 8. Advantages of use Case Scenario Testing• Use case scenario testing • Your SMEs must make the helps you to find and fix time to do the testing analysis errors • Managers often feel real inexpensively work isn’t being• Use case Scenario testing accomplished provides you with a detailed • Developers are often descriptions of the business skeptical logic of the system• Use case scenario testing is simple and it works• Scenarios help to define how people interact with the system
  9. 9. User Interface Walkthroughs• Similar to use case scenario testing sessions, the only difference being your system’s user interface is being tested instead of your domain model
  10. 10. Requirement Reviews• The requirement team prepares for review• The team indicates it is ready for review• The review facilitator performs a cursory review• The review facilitator plans and organizes the review• The reviewers review the package prior to the review• The review takes place• The review results are acted on

×