Tag: Requirements

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.

User Stories: A Vital Step to Craft Successful Software

Written by Suchita Panchal on June 21, 2023. Posted in Articles.

Simple and easy-to-understand user stories are the key to designing and developing successful software applications (products). Mastering the art of writing user stories is crucial for product owners and business analysts. Want to explore more about user stories? Here you go!

User Story 101

The foremost step in developing a project is to have a clear view of what needs to be created. Clarity is the most crucial element in software application design and development to end up with the most efficient solution.

User stories are the step-by-step documentation of a process, which describes the actions and results. It is an agile software development tool that mentions the features from the users’ perspective. The well-documented user stories are the foremost step in the agile development process to design and develop a software application that users love to use.

The primary purpose of writing a user story is to define project deliverables and how they will bring value to the user. No matter how complex a product or project can be, user stories are always written in simple terms. It needs to be as simple as possible so that a non-technical person can understand the document. There are some key considerations that make the creation of user stories even easier.

Key elements of a user story

Simple, straightforward content
Keeps users at the focal point
Collaborate with team members to gather details
Emphasis value deliverables

Apart from this, Business Analysts should also focus on making the entire teams’ and stakeholders’ participation by adding an INVEST element to the user story.

I – Independent (Self-contained without overlapping actions)

N – Negotiable (Keep the scope for negotiation to design a user-centric product)

V – Valuable (Must deliver values to the end users)

E – Estimable (Estimate, prioritize, and fit into sprints)

S – Small (In the form of small stories to complete in a couple of days)

T – Testable (Confirmation via pre-written acceptance criteria)

These elements are crucial in writing well-documented, to-the-point user stories to initiate the product development process. Once you understand the basics of user stories and how they should approach, it becomes easier to create those accurately.

Now that we have understood what user stories are and their key elements, let’s explore why Business Analysts need to master the skill to write definitive user stories.

Why a BA needs to master the skill to write user stories

User stories are the foundational documentation that works as a blueprint while working on a project. The simple and easy-to-understand documents help the entire team to adhere to the project requirements and develop user-friendly features and functionality.

Moreover, it offers a contextual overview before the initiation of a project so that the team can understand what they need to work on. Also, they can think creatively and employ their best efforts to craft a user-centric product.

The most important benefits of user stories include.

Higher clarity on business values and project deliverables
Improved collaboration and visibility across the team
Prioritize features and functionality of the product
Efficient use of the end-users’ feedback
Minimize potential risks like communication gaps, technical flaws

As the user story conveys information about potential users and their actual needs, well-written user stories are essential to developing function-rich software applications. Business Analysts should understand the concept of user stories and focus on crafting user stories that drive value for the businesses via developing user-centric products.

When user stories are created

Generally, user stories are written at all software development stages BEFORE the development is initiated. Especially, while shaping product ideas, prioritizing features, and functionality, and during the development phase.

Who is involved in creating the stories

Business analyst, product owner or project manager, development, and design team, and sometimes stakeholders. Primarily, a business analyst or product owner writes the user stories; however, the entire team’s involvement is essential to create well-versed user stories that contribute to developing a user-centric, feature-rich software application.

How to create user stories

User stories are generalized documentation of why the product (software app) will be created and how it will take action. Here’s a simple way to create user stories that lead to a successful project development process. As mentioned earlier, keep users at the focal point along with what and why.

Who is the user story for?
What action is required?
Why is the action important?

The most commonly used format to create a user story:

As a <user>, I want to <complete this action> so that . Business analysts and the other team members can add other details to make the user stories to-the-point document.

Examples:

As a <user>, I want <to have to sign up feature> so that
As a <customer>, I want <to receive text notification when the item arrives> so that.
As a <customer>, I want <to have online payment terminal> so that
As a <manager>, I want <to generate multiple reports on dashboard> so that

In short, user stories need to be created before product development initiates. The understanding of users and what actions they need to take and why the action is necessary must be reflected in the user story. A well-documented user story will aid in creating a blueprint for project development that will lead to a successful software application. Usually, a product owner is assigned to form user stories; however, a business analyst must know how to create user stories that drive the design and successfully develop a product or software.

Building a House: Analogy for the Business Analysis Role

Written by Nicola Myers on May 10, 2023. Posted in Articles.

Two years ago, my friend asked me what my job role was, and I said that I was a business analyst in Information Technology (IT). However, after all this time, she still doesn’t understand what my job entails. To assist friends of other business analysts around the world, I have written this article to explain what we do. I can’t wait until she reads my article!

Let us propose a world where business analysts are architects, the developers are builders, the inspector is the quality assurance team, and our software client would like to build a house.

Usually, the builders would start building the lounge. This sounds good because they are off to a flying start and the walls are going up, but the builders do not know how many bedrooms the house will need, where the best location for the bedrooms is, or even why they are building the building at all. The kitchen might even end up with four sinks and no oven, or the kitchen might not even exist. Finding out that this is not what the customer wanted when the house is half built is expensive to fix, will not meet the deadline, and worst of all, the house will not be what the customer wants at all!

A far better idea is to include an architect on the team.

Firstly, the architect will sit with the customer and find out the high-level goals of the building, for example, the customer would like a family house in a quiet suburb because currently they live in a noisy complex. They are also expecting a second child. The business analyst (BA) is gathering context on the problem and the customer’s vision.

Right from the start the architect explains the process that will be followed, builds a trusting relationship with the customer, and starts to manage the expectations of the customer, for example, steering the customer away from a water slide in the lounge which could take an extra six weeks. This is change management, which should happen as early as possible and should set the tone for the rest of the project. It should also be noted that the business analyst is the ambassador of user needs and so is the team member that focuses on them.

The architect will then dive into the details and obtain the customer’s requirements, draw diagrams, and can even print a 3D model of the house. It will become clear to the architect and the customer exactly where the main bedroom will be, how large it is, how many windows it will have and so much more. This is the Business Analyst (BA) conducting requirement elicitation, drawing up wireframes, and prototyping the solution. The BA will also choose the best way to engage with the customer, such as through prototyping in workshops or sticky notes on a virtual whiteboard.

To double-check that the architect and the customer are on the same page, the architect will draw up some basic design criteria that the building must meet, for the example given that the room is the older child’s room, when the builders are building the walls, then they must build two windows. This is writing acceptance criteria.

A very important step is that the architect will confirm their findings with the customer to make sure everything is covered and covered correctly. This is the validation and sign-off stage. Note that architects can suggest solutions to fill in the gaps, for example, they can suggest that the house should face north, but it is ultimately it is the customer who makes the decision.

Our builders are brilliant in their field, but they are better at building than communicating. This means that the BA needs to translate what the customer needs so that they fully understand what to do. BAs bridge the gap between the business and technical sides. The architect explains “what” needs to be done, the builders decide “how” it will be done, for example, the builders will use wheelbarrows.

The architect will sit with an interior designer and discuss the finer details to make the house as well designed as possible, for example how to place the cupboards in the kitchen to make the layout practical. This represents the interaction of the BA with the user experience experts to make sure the software is intuitive and a positive experience.

Now the builders know what to do, the building continues nicely, with a few hiccups along the way such as the bricks weren’t delivered on time. The architect will work closely with the builders every day and if the builders have any questions or are unclear on anything then the architect needs to go back to the customer for answers.

Each day the entire team, with the customer, will stand on the pavement and have a quick meeting to let the other team members know what they did yesterday, what they are doing today, and if there are any blockers or dependency issues. This is a daily standup meeting.

Every second week, the team sit around a table on Friday afternoon with some drinks and discuss how the project is going. They say what has worked well and what could have gone better. They decide what to keep doing and what new ways can be put in place to improve the way they are doing their work. This is a retrospective meeting used with an agile approach.

Once a section of the building is complete, then the architect will walk around the building with the building inspector. The inspector will check every detail to ensure the house is built to code and is safe while the architect will ensure that the building is what the customer actually wanted. Sometimes the builders can get really enthusiastic, go off course, and place a central fountain in the kitchen and forget the sink. This is a verification process step.

The house is completed, with a few bumps along the way, but the customer is thrilled (hopefully) and can’t wait to move in.

In conclusion, call us business analysts, business architects, solution designers, or craftsmen but understand that we undertake many daily tasks and play a vital role in the development of successful software projects. We may not build the building but direct it (builders like to build theme parks) and save the customer a lot of money. Hopefully, my friend will understand what I do now!

Best of BATimes: Six Effective Elicitation Questions to Ask Your Stakeholders

Written by Angela Wick on April 27, 2023. Posted in Articles.

Asking questions during interviews or as part of a structured requirements workshop is commonplace. However, the most important question is one you should be asking yourself:

Am I asking the RIGHT questions?

Here are a few of my favorite elicitation questions and what they might reveal about your project.

1. What are the biggest challenges in your role?

A key part of any BAs role is to understand the context of the project: where does this project “sit” within the larger organization.
Having stakeholders describe the challenges in their role prompts both leaders and doers to share information that moves “outside the box” of the project.

Especially in an interview setting, this question allows the collection of “stories” that will elaborate and cement the value of the project and its required capabilities. These “stories” are concrete examples of the business need that will communicate the value of the project to sponsors, vendors, testers, developers, etc. throughout the project lifecycle.

Though you want to be cautious to avoid scope creep, briefly stepping outside the confines of the project can also help you identify:

Organizational risks
Missing stakeholders
Requirement gaps

2. What does success look like?

As I noted in my May article, “The Top 5 Mistakes in Requirements Practices and Documentation”, many project teams spend too much time focusing on the as-is current state.

Asking stakeholders to define success is a perfect way to move workshop or brainstorming discussions from the current state into the future state.

In the initial stages of elicitation, this question will help gather a clear overview of what capabilities are required for the project. The output of this question to can be used to create high-level conceptual models of the future state.

This question can also be used in beginning to elicit requirements for very specific features and capabilities. The challenge will be keeping stakeholders focused on the “what”: users, processes, rules, events and data. The discussion migrating to technology, systems and solution may risk that the true needs go undiscovered.

Perhaps most importantly, focusing on success frames the discussion in a positive light, emphasizes benefits, and gets stakeholders excited about the value the project will provide to their organization.

3. Who do you think is impacted (positive and negative) by the project and how?

We have all seen that even small projects can create a ripple effect that touches many parts of an organization. All of the people touched by the project’s ripples are potential stakeholders. Identifying and categorizing the roles of various stakeholders is key to successful elicitation.

In the initial phases of business analysis, understanding who is affected by the project will help you refine the scope of the solution and build your core team of stakeholders.

Asking this question throughout the project lifecycle will also help you:

Identify new stakeholders
Identify and mitigate risks/constraints
Redefine needs or identify new needs
Elaborate requirements
Prioritize requirements

4. What would happen if we don’t change the way things are done today?

Use this question as an alternative to: “Why are we doing this project?” or “Why is this project important?”

As you may know, I love the question “Why?” but I hate to use it. “Why” questions tend to put people in a defensive position and can inhibit open and honest communication.

Also, framing the discussion in terms of “no changes”, is essentially asking stakeholders to define the current state. However, this phrasing will limit the “as-is” discussion to the processes and events that need to change.

Stakeholders will help you understand the key opportunities, risks of dormancy, the benefits of change — all-important inputs for successful elicitation.

5. What other changes are happening within the organization that may impact this project?

Most organizations function in a state of constant change. To avoid being blindsided, find stakeholders that understand how new strategies, policies, regulations, processes, and technology, might impact our projects.

Many project teams tend to isolate themselves within the silo of their business unit—often in an effort to stay focused. However, too much isolation can lead to missed opportunities for:

Collaboration
Integration
Sharing of best practices

Keeping attuned to organizational changes can help to:

Mitigate risks
Estimate project deliverable dates
Manage scope
Identify constraints
Understand interdependencies

6. How would you describe the process?

This is really a technique, with multiple questions, that I use frequently with SMEs in one-on-one interviews or in small groups. This technique is most effective when delving into the details of specific processes or events. Here’s what I do:

I ask the SME/s to describe the process for me.
Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
As they explain the process I ask, “What parts of the process would you improve and why?”
I also ask, “What ideas do you and your teammates talk about as ways to improve the process?”

At the end of this exercise, I leave the room with a validated visual of the current state of the process and a list of opportunities to add value to the organization.

Let me know if these questions will help you or share your favorite elicitation questions below.

Best of BATimes: The 7 Habits of Highly Effective BAs

Written by Priyanka Agrawal on April 26, 2023. Posted in Articles.

In my experience as a Business Analyst (BA), I have seen many analysts struggle in trying to strike the right levels of analysis. Some analysts tend to overanalyze while others, under analyze. Getting trapped in the dilemma of when to stop and/or when to continue analyzing can put you into a vicious cycle of ineffectiveness and devaluation. The result: zero business outcome yet a ton of frustration and a huge load of wasted time and effort.

The 7 habits of highly effective BAs guide you in establishing thresholds and protocols for your analysis finish line and helps you determine how far you are from the finish line. These 7 habits provide you with a compass that guides you to determine when to hit the breaks and/or when to accelerate your analysis.

1. Be cognizant of the allotted project budget and schedules. Create a mini work breakdown structure (WBS) for yourself that distributes analysis tasks and activities based on the allotted time and effort. Over time, you won’t need to formally put this down on paper and your mind will automatically signal you when you’ve exceeded or unfulfilled the allotments. However, be aware that this strategy alone may not help you in striking the perfect level of analysis. For best results, combine this technique with one or more strategies described below. For example, requirements analysis can be about 25-30% of an overall development project. If the analysis is taking more time than testing and programming put together, there is something evidently wrong. The flaw with this approach is that you will need to continuously monitor your project spend before you determine you’re on the wrong track which sometimes can be too late in the game to backtrack.

2. Establish and communicate success criteria at the onset to understand where the real finish line is. Once you have fulfilled the success criterion, you’ll know that you’ve more or less completed the required level of analysis.

3. When performing use case analysis, ensure you’ve considered not only normal and alternate flows but also exception flows. In my experience, at least 1 normal flow, 2-3 alternate flows, and 0-1 exception flows are typically enough.

4. Ensure you understand the inputs (preconditions), outputs (outcomes and postconditions), and actors before you start your analysis. This will help you say focused and on the right track in terms of scope.

5. Always refer back to the business objectives, goals, and vision. When performing any sub-activity, always ask yourself if what you are doing is related to, impacts or is impacted by the overarching goals. If the answer is no, stop! If the answer is yes, continue and go back to the success criterion.

6. Define limitations, assumptions, and constraints and keep those in mind all along when performing analysis. This will help you rule out some scenarios and help you continue on your journey to a fruitful analytical activity.

7. Know your audience. Ask yourself these questions: Who is the receiver of my analysis? Who would my work interest? Knowing who you are performing the analysis for will help you identify the level of detail required and therefore the amount of analysis to perform.