Author: Michelle Green

The Use Case and I – My 10-Year Journey

Written by Michelle Green on July 5, 2017. Posted in Articles.

I’ve been a BA for nineteen years, and it wasn’t until about ten years ago that I met my first Use Case.

Since then I’ve used use cases in different ways for different types of project efforts. I’ve used them for:

As stand-alone requirements
As a supplement to stakeholder requirements
As a vision and scope communication tool
As functional requirements

In this article, I’ll be taking you through my journey with Use Cases in the hope that you might gain a better understanding of what use cases can do for you. I’m not saying that any of these approaches is right for everyone or even work all the time, but learning is an evolution. I live by the Brian Tracy quote, “You can only grow if you’re willing to feel awkward and uncomfortable when you try something new.”

Stand Alone Requirements

Ten years ago, we were picking up a new automated workflow system to replace an outdated product. An independent consultant was brought in to help our newly formed Business Process Office (BPO) determine some standards and processes they wanted to use within their organization. The objective was to learn how to identify, document, and select business processes that were good candidates for automation. I was brought in to learn the new processes and help identify ways that the company’s Business Analysts and the new BPO Subject Matter Experts (SME) could work together with the system developers as one team. One of the tools the consultant recommended to capture workflow automation requirements was a Use Case Specification Document, including, among other things the Use Case Diagram and Use Case Narrative.

It was an “Ah-Ha” Moment. I had never used use cases before, but I could tell right away that it was going to be the start of a beautiful friendship! I had finally found something that the business and the technical team could both relate to while representing the voice of the customer.

During the next couple years, we used a Use Case Specification Document as our sole requirements document for all things “automated workflow.” In hindsight, this approach only worked well because we were developing workflow automation. Business SMEs were the workflow designers, business analysts were working with them during use case development, and the technical resources were active team members for the entirety of the project. We weren’t working within an agile framework, but the co-located team principal and light documentation concept applied.

Supplement to Stakeholder Requirements

Flash forward a couple of years. The BPO had grown and was now engaged in most business projects that involved workflow enhancements. They were comfortable with use cases, but we had a project where use cases alone weren’t enough. We agreed to attach the use cases to the Business Requirements Document (BRD) and trace to them in the stakeholder requirements. Functional requirements were then written and traced back to the Stakeholder requirements.

During System Integration Testing we noticed some inconsistencies in expectations. What we found was that although many of the stakeholder requirements traced back to the use cases, the programmers were concentrating on delivering on the functional requirements, ignoring the higher-level detail. They had only looked at the use cases the first time they reviewed the Business Requirements Document (BRD) and didn’t follow the traceability all the way through. They considered them as a guide rather than an expectation. There was not cohesive understanding of the purpose of the use case.

Here’s the lesson we learned: If I could do that project over again, I would have included the use cases in the functional requirements and highlighted the purpose they provide.

Vision and Scope Communication Tool

I was paired with a Project Manager (PM) and Solutions Architect (SA) to work with a business unit to determine a high-level scope of a project for making a buy versus build decision. The goal was to replace an existing user interface system with one that could handle more complex business rules. We were on a tight deadline and every day counted.

In the first Joint Application Development (JAD) session it became obvious the business had a very clear vision for the system capabilities. It was also evident that the architect did not fully understand the scope of the request to determine what technology should be considered. We only had days to present options and t-shirt sizes to our sponsor. I needed to quickly achieve a joint understanding of the vision and scope and communicate it effectively to both the business team and the solutions architect.

Then it hit me. I could create a vision use case. Writing the use case at a high-level, I was able to insert existing system interfaces (which could potentially be re-used), show exceptions, and get a business agreement that the use case met their expectations for the new system. I took the use case to the architect, and we walked through it. With his previous architecture experience, he leveraged the use cases to draft different context diagrams highlighting interfaces for each of the build/buy solutions. The two items together allowed the business to make a quick decision, and the documents became our scope and outline to fund our detailed requirements.

Moral of this story was that in the right landscape, you could utilize use cases to communicate vision, define scope, and by the time you’re done have a great high-level requirements document,

Functional Requirements

With use cases there tends to be two different schools of thought: 1) Functional requirements are written to support use cases, and 2) Use cases are functional requirements. For this last project, and most of my projects after that, I have been leveraging use cases as functional requirements.

I was assigned the task of eliciting requirements for implementing custom packages for a Commercial Off-The-Shelf (COTS) system. In the BRD there were plenty of standard functional “The system shall…” requirements for pieces of functionality, but where a workflow was involved, use cases were embedded with the functional requirements.

Example:

In later projects, I have been known to add another section in the functional requirements for Use Cases as stand-alone components.

Conclusion

I have read different articles where experts recommend placement of use cases in requirements documents, but I like to go with the principal that the best direction to take is whatever gets you to a place of joint understanding before your audience. Learn all you can about how to use the tools in your BA Toolbox, then experiment with how to use them for your audience, as I did with my friend the Use Case.

The CBAP was My BA Booster Shot

Written by Michelle Green on April 12, 2017. Posted in Articles.

A few years ago, my company generously paid for a CBAP certification class to be held in one of our local offices.

That class was the start of a journey that would lead me down a path I could not have anticipated. I liken it to a kid getting a booster shot to strengthen the immune system. It’s not that the CBAP exam itself contained some magic elixir, but the journey leading to taking the exam, and that which followed, has changed me in ways I could not have anticipated.

In class, we were challenged to choose a date to take our exam. That date was a big looming doomsday sign. I needed help. To get it, I looked into my local IIBA chapter. I found a meeting and went to see what it was all about. That day was the day of the Annual General Meeting. The chapter was very small, and they did not have enough IIBA members at the meeting to fill all their open Board positions. I had some website building experience, so I volunteered to become their chapter webmaster. They never did have enough people that year to hold a CBAP study group, but I was able to reach out to other members who had taken or were studying to take the exam themselves. While I was practicing for my exam, I was attending monthly board meetings, chapter training opportunities, and more. By April of 2015, I had become the chapter’s President.

I will never forget it; my exam date was June 6, 2015. Moreover, I can tell you, failing that test while holding the title of Chapter President was not an option in my mind! It spurred me to study harder, and take my certification seriously. I had the absolute support of my family, my management team, my chapter board, and a colleague who accepted a panicky call or two the day before the exam which helped to guide me to success. I passed!

So, the test was done. Mission accomplished, right? Not completely. At this point, it’s important to know that I am extraordinarily lucky and thrilled to be celebrating my 20th year with my company. Of those 20 years, about 18 of them were in a business analyst capacity. When you have spent most of your adult life with the same employer, unless you make a conscious decision to be active in your field outside your company, you can form habits that aren’t productive for you or your future. It can be challenging to improve your communication if you are communicating with the same people you have known most of your career. How do you become a better leader when you grew up with everyone you lead and don’t realize where you need help or where you are great? You can take class after class on topics such as leadership, communication, business writing, and more, but until you can put the training into practice, it is just a class with the limited opportunity for application, or it was in my case anyway. Studying for the CBAP provided me with the insight to know where I needed help. I was able to partner with my management team to build development plans that worked for me and incorporated what I was learning as a chapter leader to be able to apply it on the job. Crazy right?

Once I had my CBAP and was active and growing in my chapter, I felt I had an obligation to pay it forward. I volunteered to moderate our chapter’s CBAP study group. I started to see students pass that I had mentored, and that put a fire in my belly push myself further. As I did more and was working with new individuals with all different levels of experience and backgrounds, I became a better leader, teacher, and friend. I learned different leadership techniques and used communication techniques I’d never had to use in my day-to-day job. I have since taught a CBAP Boot Camp, become a mentor for other BAs, and created training and document standards in my chapter that are now shared across all IIBA chapters. I was a guest speaker at our local Business Analysis Development Day conference, and have submitted papers for national conferences. I volunteer anywhere I can with the IIBA International chapter to move our profession forward. I work with our local PMI and QAA chapters to see how we can work together to make each other better. The more I give, the more I receive. Colleagues have pointed out differences in me they are seeing, and I get a wonderful sense of accomplishment from that recognition. All in all, I am happier in my career than I have ever been. I am definitely more well-rounded and have a better grasp of the ins and outs of my profession. Moreover, it all started because I had to take that test.

The things I learned leading up to and after getting my CBAP have made me a better me. A new improved and stronger me to be proud of. Oh, and apparently, there was enough of an extra dose of confidence in my booster shot actually to write and submit this article. Who knew?