1. The Art of Writing Use Cases Sioban Lanigan Maui County Sioban.aine@gmail.com

2. What’s to Come  Where Use Cases fit in the overall SDLC  Use Cases – Definition, Their Value  Why you need Use Cases  Documentation Consolidation techniques  with examples and methods  Use case sections  How to extend and enhance Use Cases to suit your needs and constraints

4. Use Cases – Definition  A software modeling technique  A list of actions or event steps, which are used to achieve a goal; (should only describe a single thread of activities)  Typically defining the interactions between a role (actor) and a system, to achieve a goal.  Implementation how and system independent  Types: Business and System (system development)  This talk will focus on the System and  I will show you some RAD models - All in One Approach

5. Use Cases – Serve as  Careful communication between you and your customers *  Facilitates that communication  Clarifies the final agreement (sets expectations)  Documents the agreement between IT and the customers  Serves in legacy information cleanup  Argument for money and Time * Btw, I use (customers to mean users of systems not customers of a company). *ITIL: The Customer of an IT service provider is the person or group who defines and agrees the service level targets.

6. Why you need Use Cases / why you should fight for them.  Because it communicates Goals, it defines the scope of the Use Case, (should only describe a single thread of activities)  is an important and valuable a requirement analysis techniquemotto  – no sense building what they do not want  Use Cases can remember what you forgot and provide necessary documentation to support personnel.  Existing Use Cases can serve the planning for upgrades and software requests  Valuable for setting scope and communicating expectations

7. Why you need Use Cases / why you should fight for them. more  Because it communicates Goals, it defines the scope of the Use Case, (should only describe a single thread of activities),  Is a means of conversation with customers:  my favorite because  listeners hear different than what speakers believe  it costs money and valuable IT currency to build something customers will not like or worse truly believe we got it wrong  reminds users what they forgot to tell you  People are more careful approving a written document than giving a “verbal approval”

8. Use Cases Cross Cultures  Crosses cultures: Customers’ cultural terms may not be understood and we need to learn theirs to understand them.  Are the people in Jail Intake (get right terminology from Corrine) same in culture, needs and viewpoint to the people in:  Records, or  Community relations?  And what about IT we have our own viewpoint – for me it is the backend databases and procedures. (ILeads configuration xmls).  Terms and Dictionaries inside use cases help readers to understand one another

9. Use Cases Help Identify and Correct – areas of miscommunication  Helps resolve Conflicting agreements  Main communication between customers and development, vendor  No matter how well we listen customers do not say what they really mean.  They might be trying to help by not asking too much or restricting to what they “think” the s system can do.  Implementation independent and that can in turn encourage users to think outside what is to what they want. (Be sure to include enough information that the customers will not limit the design to what they know (current system) )

10. Use Cases define the agreements with the customer and provide clarification to the vendor and developer  Anyone here had a customer truly believe they asked for something you did not build?? Echoed in Simon and Garfunkel’s “The Boxer”

12. I get everything I want and more

13. Use Cases Help Avoid Technical Debt  Especially the type of Technical – described as “not quite right” code typically introduced with …software releases because of an incomplete understanding of how the system should work.  But sometimes, technical debt is simply the result of dealing with complex requirements.  To meet a project deadline, complicated proprietary code may be developed, even though simpler alternatives may have been available. With each such action, technical debt proliferates. This is like high-interest, short-term borrowing. If you don’t pay off the debt - promptly, compounding kicks in.  What led to the wisdom “…..how will you have time to fix it later”  ** Originally coined by Ward Cunningham in 1992 and excerpted from Deloitte Press at:  http://dupress.com/wp-content/uploads/2014/02/Tech-Trends-2014_FINAL-ELECTRONIC_single.2.24.pdf

14. Use Cases Are the Main Input to Testing.  I have worked in companies where testing would not look at anything from Dev. – That is Good!!  Of course all agreed to changes were carried back into the Use Cases. WHY? Because they are living documents which can inform later – not just IT but Customers as well.  If you work with 3 customers to develop the initial requirements. Those 3 people have reported that to the whole department  If later during development, agreements are made to postpone some of the functionality, those agreements need to go back to the testers and customers – all of them. Method: update the Use Cases, redistribute and get agreements as part of the process.  Remember Testing ONLY uses the use cases Maintenance too!!

15. Documentation Consolidation techniques with examples This is the biggie! Hopefully you know why you want: Use Cases, Requirements, Design documents and Service Support documents. But how do you create them when  Time is always at a premium  Your Task list is never ending  and management wants it yesterday.

16. If you don’t have time to do it right, You must have time to do it over.* *John Robert Wooden was an American basketball player and coach.

17. Match your type of Use Cases to your processes, time constraints, your needs (intended uses)  Take it as a given that time is short, so:  Review the type of use cases and their components.  Look at the components that you need for your project.  Choose the components that will meet those needs.  That is your case and you can do it faster than you think.  Use templates  I have provided a few and there are resources on line to.  If you do not see what you want then put the components you want in your cases. There is no one authority on this and just by lasting through this discussion, you probably know more than most.

18. Basic Components of a Use Case  Title  Problem Statement  Solution Overview  Scope  Stakeholders  Glossary (a list of all the terms ALL the readers need to know) this includes how user’s refer within their own vernacular.  Desired process in user steps  Assumptions:  Basic Flow

19. Sometimes a Use case Has:  Preconditions  Post Conditions  Extensions  Current process in user steps

20. Consolidated Use Cases may contain  Functional Requirements  Function Requirements and use cases must specify requirements sufficiently so that developers can write code and testers test.  Data Dictionary  Includes and Extensions Technical Use Cases (usually used between developer and Technical Analyst) may contain  Deployment Specifications  Example is included in the electronic handouts (EXPORT OF I/LEADS ACCIDENT DRAWINGS )

21. Documents Available for Attendees  Export of I/Leads accident drawings for Hawaii state analysis and design specifications  This PowerPoint: “The Art of Writing Use Cases”  Example Flow of ALL uses cases from an a Large Global Project  Documents in SDLC Process  Suspension Use Case  VM Workstations  Accident export Requirements and Technical Spec_Accepted  SIFramework Use Case Template  Use cases and Aspects  Using Use Cases for Requirements Capture – McBreen  Playbook

22. Thank you for hanging out to the end!! Please send emails with questions or suggestions