Tag: Tools

Deconstructing the Stress Factors in the Business Analyst Role

Written by Shanekia (Shay) Thomas on July 13, 2023. Posted in Articles.

Over my years as a professional, I have come to realize that the title of Business Analyst (BA) is a heavy one. How each organization defines the role can be completely different. A BA in Company C may be a requirements scribe, whereas a BA in Company D wears many hats: process analyst, project manager proxy, test validator, etc. Whichever way the role is defined, I think stress has plagued many of us who call Business Analysis our profession. If you have found yourself feeling anxious or overwhelmed at any point during your career in business analysis, you are not alone. There are many factors that can play into that feeling. I want to deconstruct a few of the typical stressors here and offer some potential solutions.

1. Not understanding the area of study:

BAs are often on the fringes of the business. It is analogous to being a window cleaner. As each pane gets cleaned, we can see a little more into the room in front of us, but we are still only seeing a portion. Each pane reveals a bit more about the room, but the entire picture may still elude us. We are on the outside looking in. Not having the full picture of the business, its processes, or its business drivers can leave a Business Analyst feeling inadequate and uninformed.

As a BA, questions are your friend (like your squeegee on the dirty window). I have been guilty of feeling like I was asking too many questions. What I realized is that if I don’t ask my second follow-up question, which may lead to a third follow-up question, I risk not gaining the knowledge that I need to understand the business to write better requirements.

Feeling anxious because we don’t know the business is stressful, but not asking enough questions to get the understanding we need will cause more stress later. If you have 100 questions, don’t stop at number 99. Ask all 100. If you find that the participants are getting a little impatient with your questions, gently remind them that you are trying to understand them as an outsider looking in. Once you gain a better understanding, your perspective changes, and you are no longer looking through smudged windowpanes.

2. Large complex projects:

If you have been on projects with multiple stakeholders, then you may feel pressure before you even type the ‘r’ in requirements. It can be daunting to start a new project. You may be working in a new department with all new faces. Unfamiliarity coupled with complexity can be intimidating. In instances like this, it is important to build alliances.

Find project team members that you can trust. Relationship building is so important to your success as a BA and will also go a long way in helping alleviate some of your stress. It can be nice to have a friend when you are on the fringes.

3. Requirement Elicitation is not one size fits all:

For those who do not practice Business analysis, gathering requirements may seem like a simple task. You find out the need, and you write it down. It is not at all that simple. Different stakeholders require different elicitation methods. Some stakeholders are very forthcoming with information. Others can be more guarded or may simply not know how to express the need. Interviewing may work for some. Passing e-mails back and forth may be more appropriate for others.

The key here is to really take the pulse of your stakeholder population (a personality assessment of sorts). Understand their optimal mode of communication and how you can best work within the confines of that. Also, do not neglect your best mode of working as well. Finding the proper balance between stakeholder and BA methods of working will be key to helping alleviate stress.

Do not feel pressured to use an elicitation technique that is not a good fit. We do not want to simply check boxes on the list of deliverables; we want to add true value.

4. Feeling pressured by deadlines:

Every project comes with a start and end date. BAs often occupy a few task lines on that project schedule, and the pressure to meet those deadlines can feel immense. We don’t want to be the ripple that causes the project timeline to shift.

As BAs, we often take the deadlines given to us and work to fit within them. If we do not understand the business, the project is complex, and we don’t know what elicitation method to use when starting a project, then how can we be tied to a deadline?

Speak up when you feel that timelines are not realistic. Open and honest conversations can be uncomfortable but can also be wholly necessary when the quality of work is on the line. The timeline may not shift because you raised a concern, but I guarantee you will feel a little less pressure when you have been open and honest and raised your hand.

This is not an exhaustive list; it is just some of the key things I noticed in my career as a previously stressed and anxious BA. In the end, it is important to remember that your success as a Business Analyst rests in part on your ability to perform the job well. Different stress factors can become obstacles to your performance. Understanding those factors is the first step in tackling them. Apply different techniques to alleviate the stress. You will thank yourself.

Complexity Science Terminology Applied to Business Requirements

Written by Ligia Groza on June 28, 2023. Posted in Articles.

Borrowing from the terminology used in the complexity science field, in which systems are classified as Simple, Complicated or Complex, this article provides a short description of these characteristics, and suggests using the same terms, in a different interpretation, in the context of documenting Business Requirements.

In the book “Getting to Maybe: How the World Is Changed: Westley, Frances, Zimmerman, Brenda, Patton, Michael” the following meaning is given to the three types of systems:

<<Simple>> systems are based on a small set of rules or steps to function. They are robust, in the sense that the same input will generate the same output, with little variance. An example would be baking a cake by following a recipe.

<<Complicated>> system have a high number of rules and laws, even thousands, like the project to launch a spaceship to reach the Space Station. These systems can be managed by computers, are considered predictable, but they are not necessarily robust: an error in an input parameter can lead to a different outcome than desired (the spaceship ending up on another place instead of the Space Station).

<<Complex>> systems are those in which the component agents interact amongst themselves and adapt to the new conditions. For example, raising a teenager is complex because teenagers change their moods, they interact with their peers and the environment, and they adapt to the new context. Such systems are emergent, and other examples include languages, a pandemic spread, or the car traffic.

We can adapt this complexity systems terminology to the situation of a Business Analyst who is part of an on-going project to enhance an ERP application (Enterprise Resource Planning) in a specific organization.

In this framework the starting point are the business users who face the real world and have <<Complex>> problems. The role of the Business Analyst is to translate that complexity into a form that is <<Complicated>> but fully described. The final form of this translation is the Business Requirements Document, aligning the understanding of the requirements among the team members, with sections detailing <<Simple>> logical components.

From this perspective regarding the Business Analysts’ work, the categories are:

<<Complex>> problems known by the business users. These problems may touch several areas of the ERP, have unclear or vague rules, or the granularity of the logic and desired actions is not fully explained.

<<Complicated>> requirements with a high number of rules, parameters, procedures, algorithms. With the huge computing power available nowadays, ERP applications are able to handle such complicated systems, and they routinely process huge number of transactions run very fast on large databases.

Using the complexity lens to look at requirements provides benefits such as:

First, this perspective can reduce the frustration within the project team around requirements, by emphasizing the complex and changing nature of the business user’s problems.

Second, it increases the appreciation for the Business Analysts’ role in the team, since their talent and ability to translate <<Complex>> problems into <<Complicated>> requirements are key in this framework.

Lastly, untangling complex problems requires judgment, intuition, and context sensing – all characteristics that are unique to the human mind. In the current environment dominated by Artificial Intelligence applications, a Business Analyst with this view in mind would have less to worry about a being replaced by a robot and losing their job, if they see themselves from the position of contributing to the translation of complex problems into complicated requirements.

Equipped with the tools and techniques recommended by the BABOK, Business Analysts are in a unique position in the process of documenting the business requirements.

The following components of a Business Analyst’s toolkit are particularly useful in the requirements elicitation and documentation described in this framework:

Offering mock-ups and diagrams: Visual representations of the requirements can be highly effective in helping stakeholders understand the proposed solution.
Setting up test cases in the ERP application, to assess how well the information currently provided by the ERP system can support the proposed changes.
Performing a gap analysis between current and future state. This technique helps ensure that the requirements align with the overall business objectives and can serve as a basis for defining the scope and priorities of the project.
Organizing walkthrough sessions to gather feedback and ensure that the requirements are accurately captured. Business Analysts can generate and present iterations of the BRD with revision points, and address follow-up questions from stakeholders.
Asking open-ended questions to encourage stakeholders to share their insights, perspectives, and concerns, which can help uncover hidden requirements and potential issues that may not be captured through closed-ended questions.
Nudging the discussion towards “what” is the ultimate need, instead of the “how” to meet that need. This approach encourages stakeholders to articulate their true requirements and avoid premature solutioning. This approach allows for more creativity and flexibility in exploring different options and arriving at the most appropriate solution.
Being flexible in case the requirements change in time as the project progresses. and appreciate that the scenarios might be unchartered territory for the users themselves.

The Dilemma of Test Scripts

Written by Kimberly Yoss on May 31, 2023. Posted in Articles.

Mention software testing to 10 people in IT and you will get several different responses.

“That’s what QA is for.”

“Unit testing covers what we need.”

“What do we need to test for? The application works fine!”

“We’re Agile. We don’t need to test.”

“The client’s not banging down my door – so all is good.”

“No, we can’t release to UAT yet. I’m only halfway through writing the test scripts.”

“I don’t have time to test.”

“I don’t know how to test this. I’ll need some guidelines.”

“That’s not in the budget.”

If you work as a BA in an IT department, you have likely heard all of these retorts – sometimes even from those who should know better.

It is also a trigger that can lead down a deep rabbit hole of shortcuts and excuses, with the ultimate result being sloppy code, error-prone software, and possibly tons of rework post-release. Not only impacting you and your team, but also potentially leaving your company with very unhappy customers.

Software testing has several variations, all meant to ensure that the customer is happy in the end and that fewer issues, or bugs come back to haunt the product development team. Unit testing and smoke-testing are two of the most common types of testing. Unit testing is ordinarily done by the engineer as a part of coding and is meant to test the individual functions of the various components of the specific software. Smoke-testing is done after the release of the code into production. It serves as a means to make sure that nothing has been broken by the new code. Another critical form of testing is called regression testing, which focuses on how the new code works with the existing code. Regression testing requires additional planning and visibility of enhancements between releases.

At a bare minimum, unit testing and smoke-testing are essential. They are cheap and easy and require a minimal amount of effort.

The real testing, however, comes in the form of functional tests and acceptance tests. This is how you connect the code that is created by the engineers with the business needs of the customers and the real-life use of the application.

Functional tests validate that the newly designed process aligns with the requirements that were provided to the development team. Functional testing is best performed by either the business analyst or the QA analyst. A distinct benefit is gained here when functional tests are designed and completed by someone who is familiar with both the application and the enhancement requirements. Here is a tip: well written requirements and an experienced QA analyst are your best friend for stellar results!

Acceptance tests (also known as User Acceptance Testing or UAT) validate that the finished product aligns with the needs of the business user. This type of testing allows the end user to touch-and-feel the new process to make sure that it will correctly address the defined business need. An end user is also looking to make sure that the workflow is not made worse. At the end of the day, the user still has a job to do!

A well-designed set of test scripts is the most efficient way to track results, and to facilitate tracing the functionality back to the requirements. A plethora of applications exist that do this for you! Many of these applications can also run the test scripts in an automated fashion, which works great for regression testing. If I have access to an experienced QA analyst, I leave the decision up to that person. I simply provide rock-solid requirements and expectations and make myself available for questions.

That said, I am a big advocate of DIY.

If I am running functional tests myself, I create test scripts the old-fashioned way: Excel spreadsheets. The perception is that this takes too much time. Yes. It can be tedious. However, if you consider that good test scripts can also be used for system and user documentation – a bonus for start-ups – it is an essential task, regardless of the effort. They can be maintained and re-used.

Put your user hat on and give it a try!

Begin with a few basic columns:

Who is the user? What role is the user filling while performing this task?

What is being tested? Describe the function in simple terms.

What are the exact steps to get the desired result?

What is supposed to happen when the steps are completed?

What actually happened when the steps were completed? Ideally, you would want this to be the same as what was supposed to happen. Many times, it is not.

Did the test Pass or Fail?

Add more context for tracking and tracing back to the requirements, like test IDs for each test and date tracking to facilitate repeat testing. Add a column for additional comments so that the person who is running through the tests can add additional observations about what was experienced during the test.

In short, product quality drives customer satisfaction. Complete and consistent testing and retesting is one of the best ways to drive customer satisfaction with new products and product enhancements. It’s well worth your time and effort.

Happy testing!

Agile Requirements Management Part 3 – A Collaborative Data Model

Written by Steve Farrall on April 19, 2023. Posted in Articles.

In this article I want to explore how to integrate data requirements with product features and user stories; the result is some very useful traceability to where a particular data entity or attribute is being used across a product.

A conceptual data model is an integral part of the analysis process, it allows the analyst to better understand the overall requirement and how the various elements are related to each other. This enables the correct features to be identified to support the requirement and may well identify some gaps in the requirement where data is not being setup ready for the next process to collect and consume.

The data model will then naturally provide the start point for the database design and will ensure that all the features and associated user stories are all be singing from the same hymn sheet. The sprint teams will benefit from a shared understanding of the data that they are being tasked to manage.

The Tool

Initially my thoughts were that a true data modelling tool with a built-in dictionary were needed, having used these kinds of tools in previous projects.

As the choice of tool was limited, we explored whether Confluence might provide a useful stand in solution; we were already using Confluence to manage the requirements and user stories, so this looked like a natural plug-in to our existing Confluence wiki.

Develop the Model

For convenience, a separate data modelling space was setup to hold all the diagrams and page content for the data model which could then be referenced across the Wiki pages to add understanding to the requirements.

The Confluence service we were using came with the Gliffy diagramming tool; this allowed us to create entity relationship diagrams (class models). As the model was quite large, it was split into distinct data domains, this is easily managed by creating a view (diagram) for each domain.

Create Data Entities

In order to make the Confluence data model more like a true tool-based model, hyperlinks were included in the diagrams attached to drawing objects like an entity or domain; click on a high-level domain in the diagram view and the attached URL will then launch the associated domain view diagram, allowing a drill down to the detailed entity level.

Once down at the entity level, the next step is to setup each entity as a separate Confluence page; the last click at the entity level will arrive on a page that can be enriched with content for collaboration with the team.

Each data entity is loaded as a separate Confluence page; this approach also means that you can link to individual features and user stories using the page URL but also provides a ready-made folder to hold related content like data attributes.

Tip – Setup Data Domains

Setup a domain hierarchy in Confluence to file the entities appropriately, this will facilitate creating views of subsets of the model using the ancestor filter option in the reporting macro.

Trace Data Requirements

Now we have the model available in Confluence with each entity loaded as a separate page the data requirement can be integrated into the requirements wiki traced to the product features and included in user stories as a URL link to the relevant pages.

Tip – Identify Data Usage

The more comprehensive the application of this approach the greater value will be realised; if you go down to attribute pages then it will be possible to drill down to where data items are being processed.

Setup Data Attributes

Defining the data attributes is a useful activity to ensure that the system will include all the required data and manage it in a consistent manner.

Data attributes can be simple and self-explanatory items, the name alone can be enough to understand the purpose intended; however, it is often the case that the meaning can be very subtle and having an attribute page available to record an explanation is very useful.

Data attributes are setup as child pages to the parent data entity page to provide a natural filing plan but they can be referenced anywhere and shared in conversations with team members to clarify their purpose and ensure consistent data usage.

Tip – Attribute Names

Page names must be unique within a Confluence space, so it is a good idea to fully qualify the page name with the entity name as a prefix to avoid any duplication issues across different entities.

Integrate Data Requirements

This is where the data model becomes integrated and collaborative, a big advantage over separate modelling tools.

Whenever a user story is referencing a data requirement then the URL to the entity page can be plugged into the story as part of the narrative. For example, the narrative “Create a Customer record for the order received” can replace the plain text “customer” with a URL to the customer entity page instead. Once this approach is adopted the data usage can easily be discovered; starting from the entity page under the page information details all the incoming and outgoing links to the page will be shown, revealing where the data is used and with a single click the reader can jump straight to the story page.

Tip – Business Rules

Including attribute links in business rules will ensure the sprint teams are looking in the right place when implementing the user stories. For example, check the “order delivery date” has not be missed; otherwise, an alert must be triggered to follow-up on the delay with the customer.

Conclusion

Confluence may not appear to be the obvious tool to consider for managing data requirements; however, the fact that it can be integrated with the product features and user stories is quite powerful. The ability to see where individual data attributes are being used facilitates impact analysis and support; the business rules can be expressed precisely and facilitate the development of an integrated system.

It will require careful management to ensure changes can flow through the process and can easily be identified but this is true of all these kinds of tools.

Last but not least is a the record of feedback and comments added to the pages in Confluence, explaining why certain decisions were made and how data attributes introduced are being used by the system. This record will be invaluable for assurance and support queries to understand the how and why a piece of data is being used by the system.

Soft Systems Methodology for Business Analysis

Written by Giorgos Sioutzos on April 13, 2023. Posted in Articles.

Soft systems methodology is an approach that an analyst can embrace when phasing messy and complex problems. SSM is a way of organizing, thinking and learning in a problematic situation.[1] [2]This methodology allows the observer, faced with a vague and unstructured problem situation, the possibility to approach as holistically as possible, concentrating, combining and co-housing all existing perceptions and to suggest ways to improve the existing situation.

Business Analysts can use Analysis with SSM before the analysis and design of an information system begins (i.e. before using UML or a traditional structured development methodology).

The Methodology

A basic pillar of the methodology is the distinction between the real world and the systems thinking about real world. The methodology recognizes the complexity of the modern world and tries to reconcile the mental models we try to construct to simplify the world with the real needs and environment upon which any change will be implemented.

In addition to eliciting the perspectives from different stakeholders, it is also important to investigate different perspectives of the problematical situation.

This involves analyses of:

The intervention, including the actors involved,
The socio-cultural context including roles, norms and values and
Existing power structures

The following diagram depicts seven-stage model of SSM (adapted from Checkland & Scholes, 1990, p. 27)

We can group the activities in the real world versus the activities in systems thinking.

Ιn real world:

First: we learn/analyze the problematic situation
Ultimately: we intervene with the aim of bringing about improvements

Systems thinking include:

Identifying relevant systems of human activity with ‘key definitions’
Creating mental models from the basic definitions

Tools

1^st Step:

To understand the complex problem situation we use the rich image.

Emphasis is placed on illustrating the following:

roles in the system and views,
disputes and controversies,
system limit,
elements of the environment

An example of rich image is given below:

Source: elabor8.com.au

2^nd Step:

In the next stages of the methodology (systems thinking) we create basic definitions and then a mental model of the system.

The basic definition can follow the following structure:

Do P by Q in order to contribute to achieving R” (P = what? Q = how? R = why?)
CATWOE is a good way to think holistically about actors.[3]

A mental model is an explanation of how something works. The phrase “mental model” is an overarching term for any sort of concept, framework, or worldview that you carry around in your mind.[4]

The following diagram represents the structure of a simple mental model.

3^rd Step:

Finally we return to the “real world” for the last 3 stages of the methodology, aiming to make effective changes to the problem situation.

Collaborative learning is achieved through the SSM process. Development of shared meaning and understanding across individuals and groups are enabled and can ensure faster requirements elicitation and more precise requirements that will add value to the different stakeholders.

Conclusion

The internal and external conditions are complex, interdependent and unique. Either the change of only an internal or external component creates a different dynamic and a different system and may trigger a chain of events that can affect indirectly other components. The “Ceteris paribus” assumption in some microeconomics models seems to be utopia in the modern business environment. Systems thinking and the holistic approach are basic characteristics for effective conduction of business analysis. SSM encapsulates the systems thinking mindset and can be a useful methodology in the pre-analysis and/or early analysis phases.

[1] Checkland P. Systems thinking, systems practice. Chichester: John Wiley and Sons; 1981

[2] Checkland P, Poulter J. Learning for action: a short definitive account of soft systems methodology and its use, for practitioners, teachers and students. John Wiley and Sons Ltd: Chichester; 2006.