SYS366 Use Case Review

SYS3662 Contents

SYS3663 Use Case Reviews Seeks to uncover flaws in use cases Final review might validate use cases Involves relevant stakeholders

SYS3664 Types of Reviews Informal Take the form of a walkthough Can be conducted multiple times in the development cycle to get feedback Formal Usually for approval, not for feedback Often approves the results of the informal review which preceded it

SYS3665 Walkthoughs Lead participants through use case step-by-step Can use storyboards to show steps in user interface dialogs Gain important feedback from participants More effective than sending out use cases for review

SYS3666 When to Hold Reviews Informal Often, to get feedback Part of the iterative development process Formal Once, at the end of requirements preparation

SYS3667 Motivation Many participants will not want to review use cases or not see the purpose Motivate them! Invite only those who need to be there Explain why their input is needed Explain the goals and the use case process Explain what they have to do Show them what’s in it for them

SYS3668 Who Should Attend Use case analysts Related developers Testers People from related business area No more that 4-7 people in total

SYS3669 The Review Meeting Moderator Chairs the meeting and keeps it on track Author The creator of the use case who can provide additional details Recorder Takes minutes of the meeting Participants Those providing feedback

SYS36610 Things to Check Actors and use cases have meaningful names Use case diagrams convey the main message Each use case provides value Actors without use cases and vice versa No communication between actors

SYS36611 Interface Issues Prototypes and storyboards provide feedback on the user interface Allow interface problems to be detected early Help participants visualize how the system will work