4 Reasons Why BA’s Should Embrace Use Cases and Tips For Creating Quality Use Cases

Long ago, in a time before I was born (1986), the software prophet, Ivar Jacobsen, delivered unto us the mighty and all powerful use case. Since its inception, it has been more clearly defined and enhanced. Most all IT professionals, who in some way define requirements, know of this wonderous concept, yet, so few actually take the time to use it.

Why...

Well like I said, I was born after 1986, meaning I haven't been a professional long enough to know why something so awesome and older than me is so under utilized, however, I can give you a few good reasons why you should use them.

4 Reason You Should Start Using Use Cases... Today

Writing Use Cases

Use cases give us a semi-formal framework to structure user stories

The standard is formal enough that it requires a certain level of quality, which your basic text requirements just don't do. Even a new BA with little instruction will produce quality use cases if that how there directed to document.

Use case make it easy for untrained users to understand requirements

You don't have to be educated in any standards to quickly understand what a uses cases is trying to tell you.

Uses cases define system requirements for the error situations.

It's easy to remember what you want the system to do given all things are perfect, but we often forget to build our requirements for the imperfections of life. Use cases make it easy to define what should happen when things go wrong.

Use cases mesh well with object-oriented software development

Uses cases are basically units of functionality, which translate well into functions and objects.

Quick tips for Writing High Quality Use Cases

  1. Use case name should be a clear verb+object statement (example: submit timesheet, place order, apply for a job), that completes a single goal.
  2. A use case should represent a complete goal or "user valued transaction" with the post condition being the accomplishment of that goal
  3. Interface details should not be included (mouse clicks, list boxes, window design). This will reduce having to rework use cases in the design and development phases.
  4. Sentence fragments should be avoided when defining the steps. You should have a Subject+Verb+Object

Use cases are meant to capture what a system must to (functional requirements). Performance requirements, complex business rules, data structures, and product line descriptions should be captured using text, document, or other appropriate artifact types.

Also See Business Analysis Skills For Producing High Quality Deliverables @ Udemy.com

Leave a Reply

Your email address will not be published. Required fields are marked *