Skip to main content

Tag: Requirements

BATimes_May10_2023

Building a House: Analogy for the Business Analysis Role

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.

 

Advertisement

 

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!

BATimes_Apr27_2023

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

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

 

Advertisement

 

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:

  1. I ask the SME/s to describe the process for me.
  2. Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
  3. As they explain the process I ask, “What parts of the process would you improve and why?”
  4. 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.

 

BATimes_Apr26_2023

Best of BATimes: The 7 Habits of Highly Effective BAs

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.

 

Advertisement

 

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.

BATimes_Apr19_2023

Agile Requirements Management Part 3 – A Collaborative Data Model

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.

 

Advertisement

 

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.

 

BATimes_Mar30_2023

Agile Requirements Management: The Art of Collaboration

In this article I want to expand on how to manage requirements, particularly focused on delivering user stories to development teams ready for sprint refinement sessions. The starting line is a set of requirements that have already been formulated and issued, for example as part of a tendering process for a new service or upgrade to an existing service.

The Tool

We adopted the Confluence wiki collaboration tool as it is well integrated with the preferred Jira sprint management tool from the same supplier, Atlassian. The objective was to build a knowledge base for the product that is sharable and retains useful insights posted by stakeholders and the project team; this will facilitate future enhancements but also be invaluable in answering the inevitable question – “Why did we do that?”

 

The start point is to load each requirement as a separate Confluence page; this approach means that you can link to individual requirements using the page URL but also provides a ready-made folder to hold related content. This has an initial overhead in loading the requirement pages but provides lots of advantages downstream, so its well worth the effort; we managed to load in excess of 800 requirements for one contract.

You may be thinking why not use a table embedded in Confluence page to hold all the requirements but this is hard to manage and you cannot easily address each requirement.

 

Tip – Setup Subject Areas

Setup a subject area hierarchy in Confluence and file requirements appropriately, this will facilitate creating views of subsets of requirements using the ancestor filter option in the reporting macro.

 

Trace Requirements

Add at least one trace for each requirement, one for each feature impacted by the change or new feature that will need to be developed.

In parallel, features can be added to the wiki, again as separate pages – one per feature; it does not matter that the feature page has little content at this stage, the aim is to have a place holder that is ready to receive content and will allow everything to start to become joined up.

If the feature is already in place, then you can just plug in the link in the trace page and you are ready to move forward.

Tip – Identify Impacts

Each impact will need a separate trace, however traces can be grouped together for delivery as a single story. Trace pages are filed as child pages to the parent requirement, so everything is kept together.

 

Advertisement

 

Validate the Solution

Validate the proposed feature changes with the Product Owner and SME’s, this is achieved using workshops and reviewing the trace page content and adding clarifications to pages during the sessions, so everything is up to date and immediately available to the team.

The sort of points to consider are – does the Product Owner agree with the introduction of a new feature or a change to an existing feature, are there better options to consider such as buying a third part add-in; these kinds of questions need to be answered before moving into a more detailed analysis of the requirements.

 

Tip – Agree Solution

Stories to be written are agreed before they are actually written to reduce the risk of wasted effort.

At this stage a story title may be added as a reminder to the author of what needs to be covered, this will then be replaced with the URL to the story page once it has been created.

 

The Collaboration Solution

I’m guessing by now people will be wondering how on earth will all those requirement, feature and trace pages be manageable once they have been loaded into Confluence.

This is where you can use a feature of Confluence known as the Decision macro, at first glance it does not appear to offer much – the ability to create logs of decisions to manage, so each decision is a separate page but you get a consolidated view that pulls them together – a bit like a spreadsheet.

The next step is to realise that requirements, traces and features are really just decisions – a decision to request a feature in a product, to deliver a product feature using an agile user story etc. The nice thing about decision pages is that they can be customised, we devised templates for each type of decision – requirement, trace, feature etc. So now we have logs of all our requirements, traces and features but each can be managed separately as a Confluence wiki page.

 

Tip – Setup Filters

Logs can become quite large, so the solution we adopted was to use the requirement subject areas to create filtered views that only included traces for a particular branch.

 

Create User Stories

Write the user story content to fulfil the requirements including the detailed process flows and business rules.

As stories may relate to multiple requirements they are filed in a separate branch and not under a specific requirement, they are still linked back to the requirement via the trace pages.

 

Tip – Story Content

Add as little or as much content to ensure that the requirement will be met including process flows and business rules.

This is more effective than trying to develop business rules once sprints have started.

User stories may be grouped together where a lot of stories need to be managed.

 

Validate User Stories

Check the proposed changes with SME’s, are the business rules correct, you may include mock-ups of user interfaces to facilitate the process and give context to the proposed changes.

 

Tip – Workshops

Workshops can be used to present user stories prior to development to mitigate the risk of the wrong solution being delivered.

 

Conclusion

Finally, we created a Jira ticket for each story and link it to the Confluence story page; Confluence is a better tool for content than Jira but they are both only one click away from each other. Click on the Jira link in the story page and you are taken to the Jira ticket and similarly you can navigate back from Jira to the Confluence story.

In fact, you can navigate right back to the requirement(s) behind each story, all the links will be setup and ready to use with no additional effort.

Don’t forget to update your feature pages with the story releases – cut and paste job mainly; otherwise, you will need to read through all the stories for a given feature, in chronological sequence, just to find out what it is currently meant to be doing in production!