Skip to main content

Tag: Tools

BATimes_May31_2023

The Dilemma of Test Scripts

Written by Kimberly Yoss on . 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!

 

Advertisement

 

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!

BATimes_Apr19_2023

Agile Requirements Management Part 3 – A Collaborative Data Model

Written by Steve Farrall on . 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.

 

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.

 

Soft Systems Methodology for Business Analysis

Written by Giorgos Sioutzos on . 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:

  1. The intervention, including the actors involved,
  2. The socio-cultural context including roles, norms and values and
  3. 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

1st 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

 

Advertisement

 

2nd 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.

 

3rd 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.
[3] CATWOE Analysis: A Holistic Approach to Problem Solving – SlideModel
[4] Mental Models: Learn How to Think Better and Gain a Mental Edge (jamesclear.com)
BATimes_Mar15_2023

Your Next Process Model’s Degree of Abstraction

Written by Edmund Metera on . Posted in Articles.

Any process model is so much more than a flowchart. It is an abstraction of current or future real-world operations.

Process modeling is one of the core competencies of any capable business analyst. Both the International Institute of Business Analysis (IIBA) Business Analysis Standard[1], and the Project Management Institute (PMI) Guide to Business Analysis[2] call for certified business analysts to be capable of preparing and using process models.

Business analysts and process improvement analysts may prepare process models at key points of business process management, information technology, and regulatory compliance project methodologies. They may specify current or future functional, organizational, and information systems architectures, functional requirements, workflow designs, and even automated operations. What any process model needs to communicate will vary from one project to the next.  The highest quality process model examples provide clear, accurate process information of direct interest to their readers.

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve.  You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question:

What is this model’s required degree of abstraction?[3]

There are three generally accepted degrees of abstraction to consider: conceptual, logical, and configuration.

 

A Conceptual Process Model  

A conceptual process model graphically presents the defining structure of what a process is.

Business analysts, project sponsors, project managers, domain subject matter experts, regulators, and other process stakeholders use conceptual process models, for the following purposes:

  • To make process governance and scoping decisions;
  • To gain agreement about and communicate the process’s defined scope and structure, unequivocally distinguishing that process from all others in their business;
  • To design enterprise architecture, to define technology solution architectures,
  • To be the sound foundation on which forthcoming detailed problem analysis or detailed process definition is scoped out or planned;
  • To support project management decisions (e.g. budgeting, scoping).
  • To further elicit and fit logical process details upon its sound contextual and structural foundation.

 

Some business analysts and systems analysts might interpret the term conceptual to mean “high level”. That would be an oversimplification and a mistake. To serve its purpose, a conceptual process model should unequivocally define the sound, stable structure of the process. Despite being the highest degree of abstraction, a high-quality conceptual process model is still precise.  It can clearly and graphically communicate all of these process-defining information:

  • The process’s name.
  • The process’s initiating event(s) that causes the process to be performed.
  • The process’s activities and their expected sequence of execution.
  • The process’s expected outcome(s).
  • The process’s customer(s).

 

Advertisement

 

A Logical Process Model

A logical process model elaborates contextually relevant details about how a process is required to operate, is designed to operate, or currently operates.

A high-quality logical process model could graphically, answer any of these types of how-elaborating questions:

  • The decomposition or summary of some of the process’s activities.
  • The rule-driven or decision-driven conditional work that may be performed.
  • The assigned responsibilities for performing the process’s activities.
  • The data or information required to be used and/or produced.
  • The causes of the process to be delayed or interrupted.
  • The processing errors that may occur while the process is executing, and how they will be resolved.
  • The process’s related performance or measurement data, and text-based operating procedures, documents, or other specifications.

There is a spectrum of uses for logical process models. Process owners and analysts use logical process models to determine what and where to measure an existing process’s performance or to design and communicate proposed process improvements. They also define requirements for, or the design of manual or automated procedures, or describe the design of workflows.

Competent business analysts and process analysts can anticipate, elicit and document a range of logical refinement types, using clear agendas and reusable modeling patterns[4]. They also know that no two logical process models need to communicate all of the same types of logical refinements. So they will consider the model’s mission within each project and tailor their modeling efforts to focus on eliciting and documenting the types of logical refinements that suit each model’s intended use within its project’s methodology.

 

A Process Configuration Model

A process configuration model communicates concrete implementation mechanisms such as software operations and user procedures or workflows.

A process configuration model is the lowest degree of abstraction. Business analysts and systems analysts typically prepare process configuration models in low-code and no-code software platforms. The platform consumes the process configuration model along with detailed process-related roles, security, forms, system interface, and data specifications to generate operating software, on top of an already well-rounded software product architecture. There is otherwise no or very little programmer intervention in translating the model into working software. When updates to requirements or defects emerge, the analyst revises the configuration model, and the platform regenerates and redeploys the software.

You must adopt and adhere exactly to a chosen low-code or no-code platform’s process modeling syntax. You can learn that by taking the training offered by the low-code or no-code platform’s vendor. Along with a process configuration model, you would specify, in detail:

  • System users, their assigned roles, and their responsibilities to perform the configured process flow.
  • The sequence of execution of configurable functional components, of an automated end-to-end workflow.
  • The configurable functional components involved in the process flow configuration. These are typically the user interfaces (e.g. forms, reports) system integrations (e.g. APIs), and the data attributes used in an automated process workflow.

Since process configuration models are precisely translated into operating software and business operations, any errors or omissions in the modeling become errors or omissions in the generated software and business operations.  It stands to reason that to be a successful business analyst or systems analyst in a low-code or no-code environment, you must design process configuration models based on sufficiently detailed logical requirements, that you have elicited and understood.

 

How to Choose Your Next Process Model’s Degree of Abstraction

Follow these guidelines to choose what the required degree of abstraction of your next process model will be:

Use conceptual process models to get agreement about and communicate what the process is. What is the scope? What causes it to be performed? What are the activities and their expected sequence? What is or are the expected outcome(s)? Use conceptual process models for planning, scoping, and architecture definition.

Use logical process models to get agreement and communicate how a process works or is required to work. Be prepared to elicit and document the answers to logical details such as: What are the detailed or summary activities? Who is responsible for what? What happens if? What happens when? What decisions will be made? What information is produced or used? Remember to elicit and include the details that are relevant to your model’s intended audience: those who participate in the lifecycle of your business process management or information technology project. Keep your model’s intended audience in mind when eliciting and documenting details. Use appropriately detailed logical process models for detailed functional requirements or design.

Use process configuration models to specify the configuration of concrete software modules, physical devices, and/or manual operating procedures that implement a process.

You typically use process configuration models in no-code or low-code software generation. To gain the benefits, you must specify very precise and accurate process implementation details, and exactly follow the process configuration modeling syntax.

 

Conclusion

A process model is not just a flowchart. It communicates what are, or will be, real-world operations. It may play a crucial role in the success or failure of your next business process management, information technology, or regulatory compliance project.

The most competent business analysts and process analysts clarify what their model’s required degree of abstraction will be, at the start of their analysis. They then focus their own and their project stakeholders’ efforts and time on the types of model content and format that will best suit each project’s unique needs.

You are welcome to learn more or share your comments and experiences about Your Next Process Model’s Degree of Abstraction via the Contact Us page at www.ProcessModelingAdvisor.com.

Copyright 2023, Edmund Metera
[1] The Business Analysis Standard (IIBA, November, 2022)
[2] PMI Guide to Business Analysis (PMI Inc, 2017)
[3] The Universal Process Modeling Procedure: The Practical Guide to High-Quality Business Process Models (Metera, 2018, 2022)
[4] The Universal Process Modeling Procedure: The Practical Guide To High-Quality Business Process Models Using BPMN (Metera, 2022)
BATimes_Mar2_2023

Business Analysis Amalgamation with Product Management

Written by Neethu Nair on . Posted in Articles.

In today’s fast-paced business environment, organizations constantly seek ways to improve their processes, products, and services. Business Analysis and Product Management are two key areas essential to achieving these goals. Traditionally, these functions have been viewed as separate disciplines, with Business Analysts focusing on identifying and analyzing business requirements, while Product Managers focus on the development and management of products and services.

However, there has been a growing trend towards amalgamating these two functions to create a more integrated approach in recent years. By combining Business Analysis with Product Management, companies can benefit from a more holistic understanding of customer needs, more effective use of data, and improved collaboration and communication between teams.

An Overview of Business Analysis and Product Management:

Business Analysis is the process of identifying, analyzing, and documenting business requirements, processes, and workflows. The role of a Business Analyst is to help organizations improve their processes and systems by identifying areas of improvement, gathering and analyzing data, and making recommendations for change. Business Analysts often work closely with stakeholders and other teams within an organization, including IT and project management.

Product Management, on the other hand, is focused on developing and managing products or services. The role of a Product Manager is to identify market opportunities, define product requirements, and work with cross-functional teams to bring products to market. Product Managers must have a deep understanding of customer needs and market trends and/ or the ability to manage budgets, timelines, and resources.

 Benefits of Amalgamating Business Analysis and Product Management:

While Business Analysis and Product Management are distinct roles, there are many benefits to amalgamating the two functions. Here are a few of the key advantages.

  • Better understanding of customer needs:

One of the key benefits of amalgamating Business Analysis and Product Management is the ability to better understand customer needs. By working together, these two functions can create a more complete picture of customer requirements, preferences, and pain points. This can lead to better product design, more effective marketing, and higher customer satisfaction.

  • Alignment towards Business Goals:

Amalgamating Business Analysis and Product Management also improve team collaboration and communication. These two functions can ensure that everyone is aligned on business goals, product requirements, and timelines. This can lead to better project outcomes and faster time to market.

 

Advertisement

 

  • More practical use of data:

Another benefit of combining Business Analysis and Product Management is effectively using data. Business Analysts are skilled at collecting, analyzing, and interpreting data, while Product Managers deeply understand market trends and customer needs. These two functions can leverage data to improve product design, pricing, and marketing decisions by working together.

  • Faster problem-solving:

Amalgamating Business Analysis and Product Management also lead to faster problem-solving. By having a team of experts who can analyze data, identify issues, and recommend solutions, organizations can respond more quickly to changing market conditions or customer needs. This can help companies stay ahead of the competition and achieve their business objectives more effectively.

  • Better outcomes over outputs:

Finally, combining Business Analysis and Product Management can improve project outcomes. By working together, these two functions can ensure that products are designed to meet customer needs and that projects are delivered on time and within budget. This can lead to improved customer satisfaction, increased revenue, and a stronger competitive position in the market.

The amalgamation of Business Analysis and Product Management can benefit organizations looking to stay ahead in today’s competitive business landscape. By combining these two functions, companies can improve collaboration and communication, better understand customer needs, use data more effectively, and achieve better project outcomes. Whether a small start-up or a large enterprise, an integrated approach to Business Analysis and Product Management can help you achieve your business objectives more effectively.