Author: Jenny Quillian

What Use Case to Use?

The Use Case is a standard tool in the BA toolkit, and like most tools they come in different shapes and sizes for different jobs.

During Business Analysis Planning it is important to identify the appropriate use case format for the project needs.  At the high end we have a multi-page highly regulated requirements template. The base model is a single actor and basic flow.  Between these is the textbook version with complex flows. This article looks at these use case formats and design influences to consider during your Business Analysis Planning.   

Use Case Formats

  • Simple Flow Use Case
  • Complex Flows Use Case
  • Highly Prescribed Use Case

Simple Flow use cases describe the interaction of a single actor along one basic flow.  This format can be used as the starting point for a more complex effort, as a placeholder for planning purposes, or as the final deliverable for a simple project.  This format is similar to a user story, with post conditions instead of benefits. 

Complex Flow use cases include alternate flows, triggers, business rules, post and exit conditions. The degree of complexity should be determined by the stakeholder needs and perspectives.  For business users the documentation must be readable so that they can follow and agree that you have captured their needs correctly.  For the architects and developers, the details must be specific enough to translate into units of development.  For the testing teams the documentation must provide clear inputs and outputs of success so that they can formulate test cases. 

Highly Prescribed use cases have a multi-page template with approved instructions to complete each section.   There are projects which require such discipline,  but I have also worked on projects where the template became the end rather than the means,  and the degree of detail slowed down the project and produced wasteful documentation.  

Design Factors

Use Case formats will be influenced by:

  • Funding model
  • Requirements complexity
  • Rate of change
  • Regulatory environment
  • Project methodology
  • Project phase
  • Build or Buy

Advertisement

Funding Model

Organizational funding models may impose a need for provide for detailed requirements well in advance of the project development phase, in order to compete for funding.  A use case that identifies all potential steps, alternate flows, business rules and usage estimates can be useful to assist with cost estimates.  Tight funding oversight models will ask for more detailed documentation than open models.

Requirements Complexity

Retail web pages for major sellers can be large and complex because of the product offerings, but the system requirements themselves are repetitive and reusable and changes easily delivered with a user story or simple use case.

A new system with complex requirements needs more detailed documentation than an informational web page.   A new system with many business rules needs detailed documentation and requirements tracing to ensure proper coverage.  Integrated systems need a degree of rigor ad traceability to ensure that front end changes do not break upstream or downstream systems such as integrated re-order or delivery systems. 

Rate of Change

The retail web pages are repetitive but require rapid changes to meet demand and marketing plans. The requirements documentation cannot stand in the way of rapid delivery. 

From another perspective, detailed requirements documentation that can be reviewed in the change management process can help slow down a rush delivery and prevent embarrassing releases.

Regulatory Environment

Systems that are governed by external regulations need detailed requirements documentation that can be read and understood by multiple stakeholders so that all affected parties are able to understand and approve the inputs and outputs of the system to be delivered.  Systems that collect personal information must be able to demonstrate that the correct information is being captured and the appropriate security will be in place to protect this information from misuse.

Project Methodology

Waterfall projects tend to require detailed requirements. Agile projects prefer minimal documentation, user stories, and simple use cases if any.  

Project Phase

Documentation detail may expand or contract during the project phases.  As discussed above, projects may require detailed requirements documentation for early feasibility and cost analysis exercise, but they may then drop down to user stories for the development and delivery.  Other projects may require only simple use cases to outline a concept, and then expand on the use case flows and details during the requirements phase.

Build or Buy

If the project includes a build or buy decision, then a simple use case format that can be transferrable to a matrix of acceptance and evaluation criteria will be most useful when comparing solution options. 

Summary

Use Cases are a valuable business analysis tool that come in multiple flavors.  As part of the Business Analysis Planning step the Business Analyst should identify the degree of rigor and detail that the project and the stakeholders require and select the appropriate use case format(s) to use during the project.

The Remote BA

The purpose of this article is to offer suggestions to the Business Analysts working remotely from your team and your stakeholders.

This article is an extension to my previous article which encourages the Active BA.  With today’s technology and your initiative it is possible to remain a strong and active BA without the face to face engagements which used to dig into requirements and resolve issues. 

My key suggestions are below. I encourage readers to add comments below with their own ideas.

  • Use all the technology available to you.
  • Be proactive at reaching out to your team and stakeholders.
  • Enhance your online meetings with online presence and visual aids.

Long distance teams are quite common in today’s IT projects, and there are a number of offerings for team collaboration.  Use them all.  If the dev team has a Slack channel,  then join it and monitor it every day.  If the PMs are using  Microsoft Teams then sign on and learn that too.  You may need to install multiple web and video conferencing tools because one stakeholder group uses Go To Meeting and another uses Amazon Chime.  Become proficient in both so that you are a proactive attendee.

Proficiency in communication tools is essential to 1) keep up the flow of ideas, discussions and feedback, and 2) maintain the soft skill of Presence when conducting meetings.

The role of Business Analyst is to provide the bridge between business and technology teams.  Much of this occurs during hallway chats and office drop-ins.  You pass the PM’s desk and stop to say Hi.  They have a small issue that you help with by reaching out to the stakeholder immediately with a quick question. It is essential to replace these informal communications by being comfortable with all tools to the extent you can casually reach out across the ether. Replace the office walk-by with a brief daily update to each of your contacts in whatever mode they are working in.  Keep the bridge together by proactively reaching out to teams and stakeholders.


Advertisement

Conducting successful requirements sessions over collaboration tools starts with the same basics as your on-site meetings – Preparation and Presence.

Preparation was covered in my earlier article, The Active BA.  The concept applies to on-site and n-line meetings.  The soft skill of Presence requires new approaches for on-line meetings.

BATimes May6 1 2020

Rule #1 – use a web camera.  Maintaining the illusion of face to face communication is essential to make the remote connection and prevent audience drift.  Use the tool function to keep the attendees visible during all screen shares.   

Rule #2 – use visual aids as much as possible.  Use screen shares with a powerpoint or other visual display to keep focus on today’s agenda and current topic. If the purpose of the meeting is just a daily catch up,  then a screen of just faces is fine,  but if the purpose of the meeting is to provide deliverables – answers, ideas, input – then do not allow your audience to talk to a blank screen.

Speak with strength when talking to your audience.  The screen is now your stage and your role is still “Powerful BA”.   Carry the same confidence that you use in a meeting room.  If you like to walk the room while presenting in meetings, then get Bluetooth connectors and step back from your desk.  Set up a white board in your home office.  Practice and film your presentations for play back and review.

If the meeting is a daily stand-up – then feel free to stand up. 

One final observation – check the background clutter in your home office or whatever room you are working from.  Remove all distracting items.  Align the camera to display your certificates and not your personal photos.

The Active BA

The purpose of this article is to encourage Business Analysts to be active in your role.

On some teams the BA is a project management support role rather than a leader.  While PMs always need our assistance, all projects benefit from having a strong BA with a focus on delivering the business needs.  I extend the concept to include proactive and reactive

  • Be Active. Don’t be a passive member of the project team. Be active in meetings, in proposing ideas, and contributing to the discussions
  • Be ProActive. Create and present a business analysis plan and BA methodologies to the project team
  • Be ReActive. Be ready to react quickly when new information, technology or needs are introduced

Be Active

Be active in meetings, in proposing ideas, and contributing to the discussions.

Project meetings can be a lot of fun.  The exchange of ideas among technology experts can be uplifting and inspirational.  Requirements gathering meetings can also be lively and productive as stakeholders share their knowledge and ideas.  But sometimes meeting can be dull and they can be frustrating, especially when participants go off track or monopolize the discussion.   Whatever the situation, the active BA is leading or contributing to the discussion.  There are two techniques that can help – Preparation and Presence. 

Preparation means know your subject. 

Within the project team we are the conduit between the technology teams and the business they are supporting.  We can bring to the project team an understanding of the user needs and of management’s expectations of how the technology product / output will benefit their organization.   It is not necessary to be a Subject Matter Expert in the technology or in the user’s business domain, but you should have sufficient knowledge of both to be an effective liaison between the customer and the development team.  Stay current with the technologies of your architecture and your business. Be active in offering your ideas.  It is especially important to offer your thoughts in project meetings on requirements that are implied in discussions.  Clarify early and often.

The BA Times article Mind Maps for Business Analysis shows how to use the 5W Mind Map to present requirements and anchor team members during project meetings. 

Before the first requirements gathering session make sure that you have some understanding of the organization and business of your stakeholders.  In large organizations it may be necessary to create your own org chart to place the stakeholders and at least recognize where there may be differing expectations.  Talk to a few individuals to get a sense of direction.  Think of this as you would a vacation trip to a new country, where research and talking to others who have been there helps get the best out of your days once there.


Advertisement

For all requirements meetings ensure that you have a powerpoint or other visual display to keep focus on today’s agenda and current topic, with an appendix readily at hand of all requirements and decisions previously confirmed.   To run a good meeting, be prepared with 1) visual clues and 2) the ability to steer discussion back to the subject of your choice.  The latter requires presence.

Presence means having the ability to focus the audience on you and your line of discussion. 

There are many tricks and tips for controlling meetings. Agendas, time boxed discussions and parking lots all help, but even with these a facilitator with no Presence can lose an audience. 

Entertainers have presence.  They move around the stage and engage their audience.  Elton John played a piano, but he jumped around that piano to keep the audience eyes on him.  When it’s time to focus the audience, stand up and move around as you speak.  Use hand movements and point to the presentation as needed.  Write comments on the wall boards while you continue the dialog.  When you have made your point and want member discussion, sit down and allow the focus to move back to them.

Speak with strength when talking to your audience.  I have an accent which goes down well with my local audience, but that alone would not keep their attention if I mumbled.  The meeting room is your stage and your role is “Powerful BA”.  

Another lesson from the entertainment business is practice.  Strong speaking skills can be developed with practice.  If your organization has a BA work group, then use this to present a topic to your peers. If you are part of a local IIBA Chapter then volunteer to make a presentation. 

Be ProActive

Create and present a business analysis plan and BA methodologies to the project team.

The proactive BA starts with a business analysis plan and BA methodologies, then presents the plan to the project team during a kick off meeting so that they understand and support it.  The plan should include roles and responsibilities with regard to requirements analysis,  In a great project team, and especially in scrum teams, there is a degree of  this analysis conducted by technical members. The business analysis plan will set boundaries for the team to understand who is responsible for getting requirements to a level of specificity so that can be ingested by the developers.  

BA Jan15 20 1

The BA operates in a continuous change environment, so continuous learning is an essential part of the Active BA career.  Learning should include development of BA skills as well as staying current with technology.  One of my recent projects was migrating apps to AWS cloud, so I spent time learning the vocabulary and cloud concepts to increase my effectiveness in the team.  See BA Times article Add BA value to your AWS cloud Project.

Be ReActive

The third branch of the active BA is to be reactive to change.  Be prepared and act quickly when new information, technology, or needs are introduced.  Reaction times are faster for the active BA with preparation and continuous learning in place, and the ability to ignore sunk costs.

Sunk Costs is an Economic principle that costs already incurred have no part in decisions on future expenditure.  For a BA this means that time and effort spent to date sometimes have to be wiped out when requirements change mid-project.  Forget the hours spent defining the module that will now be outsourced.  Let Finance worry about the dollars and cents of wasted time. The BA should immediately pivot to new requirements and how this change affects existing requirements.

The same assessment applies to the backlog and deliverables on Agile projects, but with regular adjustments from sprint feedback, and strategy changes can still occur during a delivery phase that wipe out existing work.  An Agile BA is Active, Proactive and Reactive.

Mind Maps for Business Analysis

The purpose of this article is to demonstrate the use and benefits of Mind Maps for business analysis.

The 5W mind map uses the journalists’ five questions (Who, What, Where, When, Why) plus How to provide a template for a business analysis guide that can be used through the project lifecycle.

This technique is the first action I take for every new project, giving me a project overview that is then used as a check list and visual reminder during the course of the project. I use a free download version, but there are many mind mapping tools available and the paid versions offer more sophistication for presentations and integration with other project tools. (The mind map tools provide the ability to embellish your view with markers, images, colors and labels, but beware of drowning your big picture in a pool of emoji’s).

The diagram below shows the 6 major topics, and the initial round of sub-topics for each. The choice of sub-topic may vary with your project or your own area of responsibility.

BA Oct17 1

USAGE BY KNOWLEDGE AREA

The mind map will grow and change during the course of the project and can be used under each of the BABOK knowledge areas as follows:

  • Business Analysis Planning and Monitoring
    • At the start of each project, create a new mind map to organize and coordinate plans for the analysis tasks
    • Add information from the project proposal to each topic
    • Use the mind map tool to expand the sub topics as knowledge is gathered
  • Strategy Analysis
    • Identify stakeholders and project partners under Who
    • Record the high level business case under Why
  • Elicitation and Collaboration
    • As requirements are gathered, add the high level business requirements and business rules under the What topic
    • Record sizing and usage estimates against Who, How or What
  • Requirements Lifecycle Management
    • Use the mind map during the course of the project to maintain focus on the high level requirements and to reinforce relationships between and justifications for requirements
    • Use to analyze proposed changes
    • Print out the mind map and pin to your wall or the project war room for all to see, especially during team discussions when members need to be anchored
    • Refer to the mind map when developing presentations to stakeholders and project teams to maintain consistency over long projects
    • Update the mind map during the course of the project, maintaining version numbers
  • Requirements Analysis and Design Definition
    • Validate the requirements against the other project topics
  • Solution Evaluation
    • Identify key aspects of the solutions and delivery methods under How
    • Record implementation locations and delivery sites under Where

Advertisement

USAGE BY TOPIC

Each topic provides an opportunity for the BA to start shallow and take deep dives. Add all findings as you go – but do not hesitate to remove or edit as new facts or requirements are discovered.

Who – Stakeholders and Project Partners

The key stakeholders of the proposed system should be identified in the project proposal, but stakeholders are also uncovered during the life of the project. An example is downstream consumers of the product or data being delivered. User estimates can be noted against active and downstream users.

Making a note of the executive sponsors and influencers serves as a flag to follow up when there is an organization change or an executive mind shift. How will that affect your requirements? The BA should be aware of other partners such as Finance, delivery team, and the planned support team as potential influencers of the system requirements.

BA Oct17 2

What – Requirements and Business Rules

Detailed requirements and user stories should be left out of the mind map, but they should map back from your requirements management tool to the mind map. The requirements in the What topic serve as a guide and constraint on the detailed requirements. There should be sufficient information so that the mind map is a stand-alone overview for when you are faced with an executive in the elevator asking what this project is about.

Where – Locations

The Where may prove to be not significant for a particular project, but including this in your initial template provides the opportunity to consider first then ignore – rather than ignoring first. Will the infrastructure be hosted in a public cloud or in-house servers? Will there be international users? Will the support be local or outsourced. The requirements must cover these variables. The delivery variables

When – Project Timelines

Making a note of the high level project timelines at minimum completes the overview of the project, but this branch may also include requirements analysis plans, sprint plans, and/or key business event dates.

How – Solutions and Methods

The Business Analyst is not responsible for technical solutions or project methodologies, but these may have an impact on requirements, and therefore the BA should be aware early of technical decisions such as COTS or Build, In-house or Outsourced, Agile or Waterfall. Record just enough information to show how the technical project decisions support the requirements. Sizing estimates should be recorded here because the technical solution should be compatible with the expected traffic and data volume on the system.

Why–Business Case

Recording the high level justification for the project provides another guideline reference for the business analysis work, and red flags during requirements analysis.

BENEFITS

The following section lists benefits from using mind maps for project and requirements management. In addition, I find them just fun to use. I was hooked on mind maps from the day our new Director introduced himself to the team through a colorful and informative mind map of his resume and interests.

  1. Generate discussion and ideas. The loose structure of the visual and the flexibility of the software work together to open minds and to overcome reluctance to offer ideas and changes.
  2. Multiple perspectives. The mind map shows horizontal and vertical perspectives. The drill-down design allows viewers to see big pictures and their underlying details in a single view. Discussions can go down rabbit holes into the detail but the presenter has a tool to bring them back to the shared big picture.
  3. Highlight relationships. The central positioning of the major topics in the 5W template provide the horizontal perspective, and makes the viewer think about the relationships between topics. How does the project methodology impact the requirements delivery? Do the requirements match the business case? Do the requirements reflect all locations and stakeholders?
  4. Easy to recall. Mind maps create a visual representation of your project, and the picture really can be worth a thousand words. Visuals are easier for memory retention than pages of words.
  5. Enable change. Today’s software development environment is short and agile. The BA operates in an environment driven by change, disruption and transformation. The 5W mind map enables free thinking within defined boundaries, and also provides an impact map to assess shifts and changes.

SUMMARY

The 5W mind map is a useful tool for requirements planning and management. The starting topics of Who, What, Where, When, Why and How provide a check list when collecting requirements and a reference during the life of the project.

The attached file presents an example of a 5W mind map for a hypothetical project to provide digital signage at local swimming pools.

Adding BA value to your AWS cloud project

This article is intended for Business Analysts who are about to embark on a project that will use Amazon Web Services (AWS)

instead of on-premise servers to host a web application or other software service.

An understanding of the common AWS concepts and terms are helpful in two aspects of the BA role in the cloud project – Communication and Cost Analysis. AWS terms and product offerings can seem like a new language to the uninitiated. Adding these to your project vocabulary will enhance your standing and increase your contribution to the success of the project.

Communication

We are called “Business” Analysts because we are the conduit between the technology teams and the business they are supporting. We bring to the project team an understanding of the user needs and of management’s expectations of how the technology product / output will benefit their organization. We translate technology-speak into business-speak to explain both limitations of the technical solution and opportunities that the technology has opened up that the business had not considered. This is especially important in the esoteric world of cloud computing.

Technical limitations in today’s cloud platforms do not generally impact the business, but business related limitations are presented in some of the pricing models. The section below explains some cloud cost concepts. Sizing, data usage and growth estimates are key non-functional requirements for cloud projects in order to get optimal balance between the high availability features of AWS and the pay-as you go pricing structure.

The business analyst can align their knowledge of cloud features with their understanding of the business to identify those features which may provide additional benefit to the business. In this role the BA acts as an advocate for the opportunities that new cloud technology can bring to the business. For example, how can the AWS data analytics tools help the business?

An effective Business Analyst does not have to be a Subject Matter Expert in cloud-speak or in the user’s business domain- but they should appear knowledgeable to the respective teams. They must have or learn sufficient subject matter knowledge of the business and the cloud technology to be an effective liaison between the customer and the developers. In the BA task of translator between business and technology you will be engaging with software engineers who are highly skilled and immersed in the cloud world. It helps to know what they are talking about. The sections below cover some of the key AWS concepts.

  • EC2 is the first term to understand. This stands for “Elastic Compute Cloud”, and is the Amazon equivalent of the on-premise servers or VMs. Amazon provides space on their server hardware, and services associated. “Elastic” in EC2 refers to the ability to scale your infrastructure. But see discussion later on costs.
  • Containers are self contained packages of code, configurations and libraries which are installed on the EC2 server. ECS is the AWS Elastic Container Service. Docker is a tool that packages software into containers. A Cluster is a group of containers.
  • S3 stands for Simple Storage Services, just one of the storage options in AWS.
  • RDS is the Relational Database Service, which manages any of the relational database products that AWS offers.
  • AWS has a broad product offering of their own tools such as Athena for SQL queries, Redshift for data warehousing, and QuickSight for data analytics.

Note: Some information in this article is taken directly from aws.amazon.com to ensure that I am using the correct terminology and phrasing. AWS online help is extensive and I encourage you to familiarize yourself with this before and during your project.


Advertisement

Cloud Costs

Two important concepts in cloud hosting costs are the payment grids and service sizing.

“Elastic” in EC2 refers to the ability to scale your infrastructure and also to the payment rate chart. The rate for a small pilot app with 16 GB memory could be 20 cents an hour per GB used, but the production installation with high usage and multi-gigabyte storage could be double the cost for the same transaction result because of the increasing complexity of the services needed to successfully and securely run the app.

EC2 pricing is based on instance type (standard, high cpu, high I/O). For example, an “a1.xlarge” provides 4 CPU’s and 8 Gig memory with low I/O while the “c4.xlarge” delivers 4 CPU’s and 3.75 Gig with high I/O. The hourly on-demand cost jumps from 10 cents to 20 cents. Storage sizing is another important second sizing and data input/output have an impact on the total cost of AWS.

Architectural sizing decisions are the responsibility of the project SA or SE, but are made based on forecasts of volume and usage from the business or app owners. A successful BA can help gather and interpret this valuable input for the team. Requirements should include data and usage patterns and estimates over time, not just the final max estimates.

The selection of best sizing is also dependent on the granularity of the system/app that is being built. Apps that are made up of small micro services are more cost effective in the cloud than those made of large complex services. The BA can support this in the use case analysis. A use case may begin as a high level story, which the BA can help break down into smaller services for the app team to develop. For example: The business use case may be “As a bank cardholder, I can insert my debit card into an ATM machine to get my account balance”. The micro services behind that request could include:

  1. As a card reader service I can read the account number from a debit card …
  2. As a PIN reader service I can collect PIN numbers for validation…
  3. As a PIN validation service I can validate a PIN value against an account number …
  4. As an account balance service, I can provide the current balance of an account …

These services are granular and reusable. The use case or user story template for a cloud project should provide the ability to cross reference reusable services between use cases / user stories.

A second cost consideration is the multitude of add-on services that the AWS platform provides. Many of these are deceptively easy to initiate, with the cost not apparent until the monthly charges are reviewed. I know of a case where a cloud engineer with developer rights signed up for an annual data warehousing license from the AWS Marketplace. The cost was significant. Cost management is generally not part of the BA role, but on a cloud project the BA can help their Finance partners by gaining a knowledge of the services on the monthly – or daily – cost reports to assist in recognizing and questioning cloud services that have been incurred that were not part of the original plan.

Summary

The Business Analyst can add value to their cloud project by learning and understanding the concepts of cloud architecture and the services their cloud provider offers, so that they can enhance communication with the business and financial partners.