Tag: Use Cases

Data Science: Critical role of a Business Analyst

Written by Suraj Chatrath on October 19, 2017. Posted in Articles.

The last decade has witnessed a sudden spurt in vast amount of data, which enterprises possess, on their customers.

This data is generated from disparate sources like social media, mobile, applications, financial transactions, e-commerce, search and Internet of Things etc. According to an IDC estimate, from 2005 to 2020, the digital universe will grow by a factor of 300, from 130 exabytes to 40,000 exabytes, or 40 trillion gigabytes. From now until 2020, the digital universe will about double every two years. Further, IDC estimates that only a tiny fraction of the digital universe has been explored for analytic value. By 2020, as much as 33% of the digital universe will contain information that might be valuable if analyzed.

Previously, companies were able to analyze relatively smaller set of data through various data mining techniques and tools. However, with the data exploding from multiple sources, data science as a field is quickly emerging. Data science refers to interdisciplinary field about scientific methods, processes, and systems to extract knowledge or insights from data in various forms, structured or unstructured, similar to data mining. The key highlight of the definition is “insights” as it means generating findings which are previously not known from traditional data mining techniques or simple trend and regression analysis. That is why data science as a field is considered to be at an intersection of mathematics, statistics, software and business domain knowledge. One of the simplest examples of usage of data science for any company is its ability to predict customer churn in advance. It can help the company to work on the customer retention instead of focusing only on costlier customer acquisition.

While there are various tools available in the market for data science, but a very critical part for success of any data science initiative is defining the use cases from business standpoint. In most companies, technology teams are adept at understanding the data and running analysis over them. However, field of data science in unique in a way as the teams can sometimes not know what they are looking for in the data as the insights may mostly not be a established fact. Hence the role of business analyst becomes so critical in this field as you would need a person who is fluent not only in the IT domain but also speak in the language of business leaders.

For example, data science business analyst would be expected to convert the business problem statement “Given past performance and current trends, what is the likely outcome of a certain action” to an IT problem statement which means what data needs to be analyzed to arrive at the insights. The data would then be reviewed with the technology team and results would be delivered to the business team in form of insights and data patterns. Business analyst should also be knowledgeable enough to apply various predictive modeling techniques and right model selection for generating insights for the problem at hand.

One would argue, what’s the difference between a business analyst in data science domain compared to a general business analyst. One of the key skills, which differentiate the data science business analyst, is its deep understanding of data as well as industry and functional expertise, which would enable him/her to understand the business context and identify the use case. Data science business analyst is required to have deep business knowledge and understanding of data as depth and breadth of data increases. Further, business analyst would also have to work alongside with business and technical teams and should be comfortable speaking in their language. Mckinsey in its report on “The age of analytics” mentions that while data scientist is a critical skill, companies need “translator” who serves as the link between analytical talent and practical applications to business questions. Mckinsey also highlights that first of the five critical elements for establishing successful data and analytics transformation require use cases which are also defined as source of value. The uses cases should clearly articulate the business need and projected impact.

Another key role of the business analyst for data science assignments is to identify the “optimal” model for the data based use case at hand. The business analyst should possess the knowledge to frame the right hypothesis to test it. Albert Einstein once said, “If I were given one hour to save the world, I would spend 59 minutes defining the problem and one minute solving it.” In simple terms, business analyst puts a framework to the problem solving process. Business Analyst should be able to answer questions like:

“What is clustering or regression and when should I use these techniques?”
“How do I formulate a hypothesis on my data?”

Most companies are not able to realize the true potential from data science assignments as they rely heavily on data scientists who are very proficient at data preparation, cleaning and modeling or writing software code via tools like python, R but lack the domain knowledge and meaning of data in business context. This is where the business analyst plays a very crucial role of bridging the divide between the business teams and IT department for complex data science assignments.

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.