Tag: Requirements

Best of BATimes: The Quest for Good Requirements

Written by Martin Schedlbauer on January 19, 2023. Posted in Articles.

The main responsibility of the analyst is the discovery, analysis, documentation, and communication of requirements. A requirement is simply a feature that a product or service must have in order to be useful to its stakeholders. For example, two requirements for a customer relationship management system might be to allow users to update the payment terms for an account and to add new customers.

In this article, we will look at the different aspects of the requirements management process and the lifecycle of requirements.

Definition of a Requirement

A more precise definition is provided by the IEEE Glossary of Software Engineering Terminology and the Business Analysis Body of Knowledge® (BABOK®). Both define a requirement as a

condition or capability needed by a user to solve a problem or achieve an objective.
condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
documented representation of a condition or capability in (1) or (2).

Not all requirements are at the same level. Some might be high level requirements expressed by the business sponsor (e.g., reduce the cost of invoicing customers), others might be very specific requirements that describe a function needed by a particular user (e.g., allow me to click on a customer name and then display that customer’s account history).

The BABOK® defines the following requirements types: business, user (stakeholder), functional (solution), non-functional (quality of service), constraint, and implementation (transition).

Note that these terms are overloaded and often have different definitions within some organizations. For example, a user requirement is referred to as a business requirement in some organizations and a business requirement is sometimes called a business goal or project objective. Functional requirements are also often called technical requirements, detailed requirements, or system requirements. So, it is important to understand the semantics of the terms being used. If in doubt, ask, but don’t assume. In fact, publish a glossary of terms to clarify the meaning of terms that are used by the project team.

Examples of Different Types of Requirements

To clarify the different kinds of requirements types, let’s take a look at some examples for each type.

Table 1. Requirements Examples

Scope

The scope of a project refers to the agreed upon set of features that the final product will contain. Scope creep is a common occurrence and it describes the propensity of scope to expand as stakeholders add requirements during the project without regard to its impact on budget, schedule, and deliverables. The project manager must work with the stakeholders to get agreement on the scope.

Stakeholders

The stakeholders are the main source of requirements. They have specific needs that the analyst must identify. This is easier said than done: often stakeholders are not quite sure what they need and they often don’t know how to express what they need. It is the analyst’s job to help uncover the requirements of the stakeholders.

A stakeholder is anyone who has an interest in the successful outcome of the project, including project sponsors, users, business executives, managers, developers, clients, customers, vendors, and government or regulatory agencies.

Eliciting requirements is surprisingly hard work. Stakeholders often do not know exactly what they need and eliciting the requirements can be quite challenging. As Fred Brooks has stated so poignantly in his seminal essay “No Silver Bullet: Essence and Accidents of Software Engineering”

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirement, including all the interfaces to people, machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

He goes on to say that in a systems development project there are two kinds of complexities that must be managed: accidental and essential (or inherent).

Much of software engineering is focused on reducing accidental complexity, which is the complexity that we add to a project by way of the tools and programming languages that we use. For example, writing code in C is much harder than Java and writing code in Java is much harder than doing a “mashup” with web components.

While it is good to focus on reducing accidental complexity, much of the complexity of a project is rooted in essential (or inherent) complexity. Essential complexity is the difficulty of the problem itself: launching a rocket into orbit is hard no matter what programming language you use. The techniques studied in this book are about managing essential complexity.

Brooks also argues that systems are best developed incrementally. Start with something small that you understand and improve and expand it rather than building the penultimate version at the outset. This approach is the foundation for iterative and agile methods.

Requirements Management

Requirements management is the process of defining and maintaining the requirements that form the agreement between the project team and the stakeholders. A requirements management plan (RMP) is a document that defines the process, procedures, and standards for eliciting, documenting, storing, and updating the requirements. The typical requirement management activities include the following:

Figure 1. Requirements Management Activities

Requirements Management Activities

Requirements management is generally supported by the use of requirements tracking or requirements management tools. There are numerous commercial, free, and open source tools that can be used.

Requirements Process

The process of requirements specification can be broken down into discovery (elicitation), analysis, modeling and documentation, communication, and validation (see Figure 2.) As part of the process, the project team must also negotiate the relative importance of each requirement, so that an appropriate prioritization can be established. The requirements that are considered to be implementable within the allocated time and budget are called the project scope or simply scope.

The project team generally implements the requirements in order of priority, starting with the most important ones. The reason is simple: most projects have limited time and budget and commonly not all requirements can be addressed. By the time we run out of time and money the stakeholders would want the most important requirements taken care of. While this sounds simple, establishing and negotiating the priorities of requirements can often be very difficult and politically challenging. Stakeholders don’t want to prioritize for fear of not getting what they want; the project team does not want an unlimited scope as they know that they likely cannot accomplish everything with the allotted resources.

Figure 2. Requirements Management Process

Stakeholder Obligations

For an IT project to be successful, the stakeholders have certain responsibilities:

they must spend the time with the analyst and educate them about their business and help them understand their objectives
they need to allocate the time necessary to provide clear requirements and validate the requirements in a timely fashion
they must precisely describe their requirement; vaguely stated requirements are not implementable and documenting them is a waste of time
they must provide feedback when needed
they must provide additional information in a timely fashion
they must prioritize the requirements
they must respect the estimates for time and budget provided by the project team and resist the urge to “negotiate”
they must inform the project team of changes to requirements as soon as they occur

The analyst must continually remind (in subtle ways, of course) the stakeholders of their responsibilities. If the stakeholders don’t live up to them, then that introduces project risks which must be made known to the projects manager and included in the project’s risk catalog.

Requirements Elicitation and Discovery

To discover requirements, the analyst applies a variety of techniques. The steps in requirements elicitation are generally as follows:

Plan the requirements elicitation process and how the team will document and validate the requirements. This plan is referred to as the Requirements Management Plan (RMP) and is considered a key document for project planning.
Write a Project Charter or Project Mission Statement containing the business requirements and the overall scope of the project. Often a Context Diagram is provided to clarify the scope of the system development effort. All stakeholders must agree to the vision for the project. Some organizations refer to this document as the Business Requirements Document (BRD). Use brainstorming and interviewing to arrive at the key business requirements.
Identify the key users and their usage characteristics and select a proxy for each user that can present the requirements for that class of users. These “user representatives” will be consulted throughout the requirements elicitation effort.
Collaborate with the user representatives to identify use cases and then analyze those use cases to derive the detailed functional requirements for the product.
Analyze any events to which the system must respond, such as input from hardware devices or messages from other systems.
Identify any other stakeholders who might provide requirements or constraints.
Convene requirements workshops in which users work together for a few days to explore user needs and to agree on the requirements. Requirements workshops are a way to reduce the amount of time it takes to find all the requirements by getting everyone together at the same time. Joint Requirements Planning (JRP) and Joint Application Development (JAD) are examples of facilitated requirements workshops.
Shadow users as they perform job tasks and use the results of the observations to identify needs and to understand business processes. Document these insights in flow charts or UML Activity Diagrams.
Hold feedback sessions during which users can provide feedback on issues or problems with the current system. The results can be used to formulate requirements on how to enhance the system. Looking at problem reports from the help desk can be particularly insightful.
Build a prototype that demonstrates the requirements and provides realistic feedback to the users.
Identify, document, and address any risks that might have a negative impact on the project, i.e., that might cause a delay in delivery, an increase in budget, or a reduction in scope.
Validate the requirements through walkthroughs and other formal or informal meetings with stakeholder to assure that the right requirements have been discovered.

Requirements Analysis

As soon as requirements have been identified, they must be analyzed to ensure that they are correct, not in conflict with each other, and that they are precisely understood by all stakeholders. During analysis, the requirements must be decomposed into sufficient detail so that the project team can accurately estimate effort for implementation and assure that the requirements are indeed feasible.

Analysis Artifacts

During analysis, the analyst constructs a number of textual, digital and visual artifacts, including:

context diagrams
use case model
conceptual data models and data dictionary
user interface model
business process models
prioritized requirements catalog
business rule catalog
prototypes (horizontal discovery as well as vertical feasibility prototypes)

Requirements Documentation

To communicate the requirements to the stakeholders for validation and to provide the development team with a thorough understanding of what must be done, the analyst must write a requirements specification. This is simply called the requirements package as there are no industry standards for the format of that specification. Every organization has adopted a different document template. It is important, however, that an organization has a standard document template. The template must be flexible as no single structure will fit all projects.

The successful analyst knows how to select the right documentation techniques and does not limit himself to just one documentation approach, such as wireframes, use cases, or narrative requirements. He blends the different approaches to specify all requirements clearly, unambiguously, and concisely.

While writing documentation is generally not a value-added activity from the user’s perspective, it is a necessary mechanism to mitigate certain project risks. The amount of necessary documentation is dependent on the specific risks that are present, particularly when projects are implemented by outsourcing partners, distributed teams, or when access to stakeholders is limited or sporadic.

Requirements Validation

Requirements must be validated prior to implementation to assure that they are correctly understood and still valid lest the team wastes precious resources implementing functionality that is not needed. Validation is achieved through several means, including:

Formal and informal inspection: In this approach, the project team meets and walks through the requirements package, including any visual and executable models.
Stakeholder reviews: Present the requirements, models, and prototypes to the stakeholders for review and validation. At the conclusion of the review, the stakeholders “sign-off” on the requirements to indicate their approval.
Acceptance criteria definition: For each user requirement (generally expressed as a use case), define post conditions so that tests can be constructed that verify that the requirements have been met.

Writing Effective Requirements

Documenting requirements is an essential part of the requirements process. Over the years, many approaches to documenting requirements have been developed. Among the more prominent recommendations is IEEE Standard 830, which contains the recommended practices for writing software requirements specifications (SRS).

Requirements that are useful, exhibit several important characteristics:

complete: the requirement must contain all the information necessary to allow the project team to fulfill the requirement
accurate: the requirement must be correct; validation is generally done through reviews with stakeholders; an accurate requirement cannot be in conflict with another requirement
testable: the requirement can be verified through a test
feasible: the requirement can be implemented; there is no technical or other impediment that make the requirement undoable
necessary: the requirement must describe a feature that the stakeholders actually need; it must relate to a business objective
unambiguous: the requirement must be described in a simple and concise manner that guarantees that there are no differing interpretations of what the requirement means
prioritized: the requirement’s degree of necessity relative to other requirements has been established through stakeholder consultation

Documentation Formats

Requirements are commonly written as simple narrative statements. User requirements are best expressed as more elaborate documents. A common format for documenting user requirements are use cases. In addition, constructing visual models simplifies communication of complex requirements. A visual model, such as a UML diagram, can more precisely describe requirements than a written paragraph. It is also easier to discover mistakes in a diagram than a lengthy narrative. A requirements specification typically includes a combination of narratives, use cases, and visual models.

Requirements Identification

All requirements must be labeled so that it is easy to refer to them through a unique handle rather than its description. The following conventions are often used:

User Requirements are expressed as use cases and use the prefix UC, e.g., UC1.
Functional Requirements use the prefixes R or FR, e.g., R92, FR876
Business Requirements use the prefix O (for objective), e.g., O2
Business Rules use the prefix BR, e.g., BR12
Non-Functional (or Quality of Service) Requirements also use the prefix R, although some prefer to use NFR, e.g., R14 or NFR23

Requirements Traceability

Requirements must be traceable. That means for any requirement, one must be able to ascertain its source and its realization, i.e., a reason why the requirement exists and a guarantee that the requirement has actually been implemented. Generally, analysts construct a matrix that traces each requirement to implementation, test cases, and sources. The source of a requirement is generally some stakeholder but might also be a regulation or mandate.

Requirements Approval

Many organizations have a formal process of “sign-off” or approval where the customer or project sponsor formally agrees to the requirements that have been captured. While it is somewhat formal, sign-off must be viewed as a project milestone rather than a formal contract. Requirements very likely will still change after sign-off. After all, the business does not remain static; things change constantly in the business world. Project teams must adopt a requirements change procedure that stakeholders can fall back on when a requirement does indeed change. Naturally, the project manager must explain to the stakeholders that a change to the requirements (either by adding, modifying, or removing a requirement from the specification) likely will have an impact on the project’s schedule, budget, and delivery milestones.

While it is desirable for the project team that requirements are eventually “frozen” it is not realistic. The project team should be prepared to continually manage the requirements scope: scope is not static, it is dynamic and the development lifecycle must accommodate the dynamic nature of requirements. Because of that inherent dynamic, agile methods have become more appealing to many organizations. Agile methods acknowledge that requirements change and therefore they do not force a formal “sign-off” and “freezing” of the requirements. Scope is managed much more flexibly and informally in agile projects.

Conclusion

In this article, we summarized the important aspects of gathering, analyzing, documenting, communicating, and validating requirements. The techniques provided should serve as a foundation for your own best requirements management practices.

Published: 01/25/2011

Dr. Martin Schedlbauer, consultant and instructor for the Corporate Education Group, is an accomplished business analysis subject matter expert, and has been leading and authoring seminars and workshops in business analysis, software engineering, and project management for over twenty years. Beyond that, he coaches his clients in business analysis practices, process modeling, and lean project management. When he is not working with his clients or delivering workshops for CEG, he lectures at Northeastern University in Boston in his capacity as Clinical Professor.

[1] Brooks, F., “No Silver Bullet: Essence and Accidents of Software Engineering”. IEEE Computer, 20 (4), April 1987, pp. 10 – 19.

[2] A mashup is a re-combination of available web components to provide powerful new functionality using simple visual editors and little programming. As examples, see Yahoo pipes and Google mashups.

Best of BATimes: BRD Vs FRD

Written by Arpan Rewatkar on January 18, 2023. Posted in Articles.

Documentation is the most important aspect for any BA.

The documentation is useful to depict the requirements and the detailed discussion about new features and change request if any. There are many different types of documents that a BA prepares. Some of the important ones are listed below –

Business Requirement Document (BRD)
User Stories
Use Case Specification Document
Functional Requirement Document (FRD)
Requirements Traceability Matrix (RTM)
Market Requirements Document (MRD)
Product Requirements Document (PRD)

Apart from these there are several other documents that is created by Business Analyst. It helps in understanding the business process and business events. A business events is a trigger that gives birth to the requirement. These requirements are then fulfilled by opting for IT solution.

Diagrammatically the documents can be pictured as a simple sheets of papers which contains some useful matter.

Let’s take a look at the similarities and striking differences between BRD and FRD.

Business Requirement Document

BRD highlights “Business Requirements” – i.e., high-level business goals of the organization developing the product or solution with the help of IT.
In other words it describes at very high level the functional specifications of the software
A formal document illustrating the requirement provided by the client
The requirements could be collected either by verbal or written or both
Created by a Business Analyst (usually) who interacts with the client
Entire work is executed under the supervision of the Project Manager
It is derived from the client interaction and requirements

The BRD is important since it is the foundation for all subsequent project deliverable, describing what inputs and outputs are associated with each process function. It describes what the system would look like from a business perspective. Following are the most common objectives of BRD –

To arrive at a consensus with stakeholders
To provide input into the next phase of the project
To explain how customer/business needs will be met with the solution
Holistic approach to business needs with the help of strategy that will provide some value to the customer

Basically, stakeholder’s requirements can be small or big. Thus it needs to be break wherever it requires and should be taken as multiple requirements.

Format of BRD –

There are many formats or templates that the organization follows. However, it depends upon the practices that is carried in the organization. For a product based company the BRD format is different as compared to service based firms. Standard format which is followed in most organizations are shown below. It is important to note that for clear understanding of the document we should include list of acronyms used.

The BRD template contains –

document revision
approvals
RACI chart
introduction
business goals
business objectives
business rules
background
project objective
project scope
in-scope functionality
out-scope functionality
assumptions
constraints
risks
business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
legacy systems
proposed recommendations
business requirements
appendices
list of acronyms
glossary of terms
related documents

Now let’s try to dig more in FRD..

Functional Requirement Document

FRD highlights “Functional Requirements” i.e., functionality of the software in detail
Depending on the product, FRD document can be between 10 to 100 pages
It too describes at a high level the functional and technical specification of the software
Usually created by Business Analyst under the supervision of technical expert, for instance System Architect
In a small and medium sized organizations a BA take care of this
Few companies did not create FRD, instead they used BRD as it is detailed enough to be used as FRD as well
FRD is derived from the BRD

Actually, the process to reach the expectancy of the BRD is an FRD itself. Here an analyst after discussing with stakeholders and project manager ponder on questions like –

How we develop the expected requirement(s)?
What are the features and functionalities?
What are the tools and/or systems used and their dependencies?
How will the customer reacts when they start using the solution?
Any assumptions or constraints?

Most common objectives of FRD –

Depict each process flows for each activity interlinking dependencies
Holistic view for each and every requirements, steps to built
Estimating detailed risks for each new change request
Highlight the consequences if the project health is weak to avoid scope creep

The FRD should document the operations and activities that a system must be able to perform.

Format of FRD –

Likewise BRD, FRD has a somewhat different format focusing more on risks and interfaces. Although there is no such standard format that a Business Analyst should opt for. Companies belonging to different domains use their own template. For instance, you would find many points would be repeating as in BRD.

But there should be no confusion for BA to prepare this document.

The FRD template contains –

Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, document overview
Methodology
Functional Requirements
Modelling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
Other Requirements – Interface Requirements, Hardware/Software Requirements,
Glossary

Now the use of BRD or FRD in organizations depends on the organization policies, practices followed by the project team and stakeholders. As in my organization all projects are being hoped from Waterfall to Agile. If the stakeholders is positive with the documents then BA will design the same. But if there is a need for the continual delivery of working product then documentation will not be preferred.

However, documentation will remain a valid artefact of any project in distant future.

Published: 06/12/2017

Best of: 6 Personal Traits That a Professional Business Analyst Should Have

Written by Mark Delarika on December 29, 2022. Posted in Articles. 1 Comment on Best of: 6 Personal Traits That a Professional Business Analyst Should Have

Business analysts are facilitators, communicators, agents of change and negotiators.

They have to understand the needs and purposes of a business in order to consider technology solutions.

They need degrees and certifications, skills, experience and domain knowledge but they also need critically important soft skills to be most successful and become CEOs in the future. Here are some of the personal skills they need.

1. Good communication skills

Business analysts must have communication skills as they have to communicate with a variety of stakeholders. They need to understand why what they’re doing has value and then articulate that to stakeholders. This includes convincing people to work on activities that may not be their top priority.

For example, a business analyst might have to persuade a Sales Director to help define performance metrics for the upgrade of a CRM database.

Good communication skills involve both verbal and written communication. Business analysts who have excellent verbal communication skills but battle with the written words may decide to receive help from writing services with skilled writers at Essay Mama.

Various forms of communication, such as workshops, meetings and other informal methods may be necessary to bring every stakeholder on board.

2. Active listening skills

Business analysts use active listening skills to make sure that all stakeholders are heard. They understand the importance of making eye contact with speakers and always attempt to identify exactly how they feel about what they are saying.

Observing words and body language is important for them to get to the bottom of what is being said. To do this, they must know how to dial out any internal or external distractions.

Business analysts can keep an open mind and acknowledge different opinions as well as know when to move the subject along. They are able to take all input into account without being too ruffled by disagreements. There will always be disagreeing stakeholders and part of their skill is in being able to handle this.

Holding excessively lengthy sessions is not necessary for them and they understand that these often lead to a lack of interest and attention. They prefer web conferences over traveling to different offices and hold meeting. This saves times and shows that you believe in working fast and don’t mind being tech-savvy.

They and honor confidentiality agreements and are generally seen as being above listening to any office gossip. This enables them to establish trusting relationships where they follow through on commitments.

3. Problem-solving skills

Many business analysts say that what they love most about their work is solving problems. Problem-solving can combine analytical thinking and creative thinking. It involves resolving cases of conflicting information, incomplete information, missing information etc.

Solutions aren’t always simple when problems occur within a company. Analysts often have to examine multiple scenarios and operations to find a solution. Understanding the problem usually involves exploring the overt symptoms, in the form of the effects on costs, sales, and performance metrics.

Examining every aspect of the situation provides context and a greater understanding of the big picture. All parties need to have input and give feedback. They have to answer many questions posed by the business analyst such as “why do you need this?”, “what does this mean?”, and “what happens next?”

Finding a solution involves some kind of change within the organization. For example, putting the change into practice could involve augmenting technology or improving a process. The ideal scenario when solving a problem is not only to solve the current problem but to ensure that it never occurs again.

4. Analytic skills

Analytic skills are necessary to be able to interpret business needs and translate them into practical, operational requirements.

Business analysts have to analyze information from a variety of sources, such as documentation, surveys, existing systems and requirement gathering sessions. EssayHave is a reliable custom writing service that’s available to write papers, such as research papers, if necessary.

Business analysts are passionate about analyzing data and usually have a variety of different ways to analyze it. They want to see what they can do with it and how they can tease different facets of meaning from it.

Everyday interpretations of data can easily fall into patterns that can hide shades of meaning. Critical thinking and valuable analysis are not necessarily straightforward. Good analysts will resist trying to come up with a neat solution to solve the problem before extensively analyzing data. Of course, analysis paralysis can also occur and they have to understand when to stop analyzing.

5. Multi-disciplinary skills

Many business analysts have expertise and experience in IT and their domain. However, it also helps to have experience in performing tasks in unrelated fields across various industries.

Those with such experience are more easily able to elicit information, interact with stakeholders and identify opportunities. They know more about the world, business trends, tech updates and have a deeper knowledge of the processes of business.

They can leverage this knowledge to apply information and techniques to their current project. Their wide range of knowledge affords them with innovative ways to deliver value. They tend to be more versatile and to avoid the thinking that certain tools, techniques and work products are suitable for every situation.

Business analysts wanting to change jobs and looking for a new resume should consider reading a ResumesPlanet Review. Find out about expert resume writers who understand exactly what to include in a business analyst resume.

6. Decision-facilitation skills

In consulting with managers and offering advice to developers, business analysts need to exercise sound judgment. After they have received input from all the stakeholders and assessed a situation, they need to facilitate the making of certain decisions.

The goal is not just to bring about change but to bring about the right change. Business analysts need to help others to make the right decisions so that the right needs are met. If a decision isn’t made, nothing happens.

Good business analysis involves defining all the decisions that need to be made, who will make the decisions and the information the decision-maker will use to make the decision. When multiple people need to make a decision, they are not always on the same page. Getting buy-in from all decision-makers takes some skill.

Concluding thoughts

Finding the best business analysts can take some time and effort. The above traits can help to identify individuals who have the potential to be great, even if they don’t have the experience yet or are in different roles.

Individuals who have a unique blend of the right hard and soft skills are usually most successful as business analysts. They know the importance of communicating and listening properly and are adept at managing and analyzing large amounts of detailed information. They know how to present and articulate value to stakeholders enabling them to make the right decisions.

The Beautiful Game as a Modern, Event-Driven Business Process Structure

Written by Edmund Metera on December 1, 2022. Posted in Articles.

The Beautiful Game

Whether you call it football or soccer, “the Beautiful Game” as it is widely known, has simple rules of play. But playing soccer is another matter. It is a highly dynamic, agile process. In the flow of a single match, an eleven-player professional team can make more than 500 passes and there can be dozens of game stoppages.

In the eyes of process analysts, quality improvement professionals, and business analysts, who still rely on the more than 100 years-old, strictly procedural notions of a process and on flowcharting notations that were also invented in the last century, IT IS IMPOSSIBLE to perceive and model something like playing soccer as a sequential process.

The Modern Business Process Modeling Solution

The most effective business processes are not only structurally sound and efficient but also highly dynamic and agile. A high-quality business process structure today is one that has been conceived, structured, and can be readily configured as a network of specialized, collaborating, event-driven, and outcome-oriented services, not just as a sequential procedure.

If a business analyst, process analyst, quality analyst, or manager adopts that modern business process paradigm and a modeling notation that is aligned with how today’s business relationships and processes work, then perceiving and modeling something as dynamic and agile as the beautiful game as a process, IS NOT ONLY POSSIBLE, BUT ELEGANT.

Universal Business Process Definition[1]

The Universal Business Process Definition is not constrained to a strictly procedural notion of a process. It is an event and outcome-oriented business process paradigm. The Universal Business Process Definition’s four common-sense rules define all processes, workflows, and activities, regardless of a process’s scale, the overarching project methodology, the model’s required degree of abstraction, the modeling participants, and the organizations and the technologies that will implement the process or workflow.

The Universal Business Process Definition, and the Business Process Normalization technique are defined in the Universal Process Modeling Procedure (UPMP), published by ProcessModelingAdvisor.com.

Business Process Modeling and Notation[2]

Business Process Modeling and Notation (BPMN) is a graphical notation for illustrating modern business process elements. It overcomes the limitations of the last century’s procedural flowcharting and process mapping notations.

BPMN was defined by the Business Process Modeling Initiative (BPMI) and is maintained by the Object Modeling Group (OMG). BPMI states that the goal of BPMN is:

“To provide a notation that is readily understandable by all business users.”

BPMN is the best-suited notation for illustrating modern business process and workflow structures. It includes sequential flowcharting elements, but BPMN also includes symbols for illustrating concepts that are relevant to today’s dynamically collaborating systems and business processes. Namely, events and messaging.

The Beautiful Game as an Example

We don’t need process models about playing soccer. We’d rather be playing or spectating. But we’ve all observed enough about playing soccer to use it as a commonly understood example. Playing soccer happens to be similar to how modern-day business processes and operating relationships work. Let’s use soccer to demonstrate how to apply a modern business process modeling paradigm and modeling notation to discover and illustrate a sound, modern business process structure.

Event-Driven Business Process Flow

A contextually and structurally sound model of the Play Soccer process can be discovered by answering the Universal Basic Business Process Flow Elicitation Agenda[3] and the Universal Event and Outcome-Oriented Business Process Flow Elicitation Agenda[4], found in The Universal Process Modeling Procedure.

This basic, event and outcome-oriented (non-procedural) BPMN process flow diagram communicates the normal, dynamic flow of Play Soccer as a set of collaborating, specialized activities.

The Play Soccer process is initiated by a kick-off at center field. It is comprised of 4 activities: Tend Goal, Defend, Play Midfield, Play Striker. Activities are performed by the players of two teams. The expected outcome of Play Soccer is that a match has been played to its allotted time limit, according to its rules.

A free kick from center starts a match. Once the match starts all players in their assigned positions maneuver freely, whether they possess the ball or not. The expected succession of the keeper’s, defenders’, midfielders’, and strikers’ activities is determined dynamically, by the players, while the match is played, by receiving or intercepting passes, stopping shots, and by making passes or taking shots.

The player with the ball will pass the ball to any one of up to 10 other teammates or take a shot; Either the intended teammate will receive a pass, or an opposing player will intercept a pass or stop a shot, to possess the ball. Any player that possessed the ball will then maneuver (according to their assigned position level and their own skill) and then pass the ball to any one of up to 10 other teammates or take a shot. This succession of activities continues, until a stoppage in play.

The success of the expected outcome (pass made or shot taken) of one Play Soccer activity will determine the initiating event (pass received/intercepted or shot stopped) of another Play Soccer activity. The actual flow of a game is determined dynamically, by the players who are assigned to perform Play Soccer’s activities.

This basic, event and outcome-oriented process view of Play Soccer is contextually and structurally sound, but still basic. It is upon this solid, defining structure that one can elicit, add and communicate logical details that are relevant to how the Play Soccer process will “flow” and, that this model’s readers likely expect to see. What about conditional activities, like throw-ins, corner kicks, penalty kicks, substitutions, fouls, out-of-bounds, injuries), and delays (like injury time-outs, and half-time)?

Logically Refined Business Process Flow

The logical details about the periodic conditions, activities, and delays in the execution of the Play Soccer process can be straightforwardly discovered by asking and answering simple agendas that are defined in The Universal Process Modeling Procedure[5]. This refined BPMN process flow diagram communicates the conditional activities and delays that are expected to periodically occur throughout the dynamic flow of Play Soccer.

The BPMN process diagram shows that game events, not a sequential procedure determine what and when certain activities are performed in the Play Soccer process.

Even with all those refinements made, the contextually accurate and sound basic structure of the Play Soccer process, that we previously established, has not changed. These refinements can be graphically included or excluded, without any rework of the basic contextual meaning or basic diagrammatic structure of Play Soccer.

Activity dependencies are contextually accurate, without depicting a sequential procedure and sequential flows. Dynamic, alternate activities, paths, and timings throughout the process are accounted for in the model. Undue model complexity, and the analyst’s time that would have been spent on it, has been avoided. Process navigation decisions, and alternate flow paths are in fact modelled, but need not be explicitly illustrated as sequence flows.

Conclusion

The Beautiful Game serves us as a beautiful example of a process that is a set of dynamically collaborating sets of specialized services. It is not a sequential procedure. Modern business processes are not just sequential procedures either.

The Universal Process Modeling Procedure, with its Universal Business Process Definition and elicitation agendas, provides a modern process modeling paradigm, capable of event-driven as well as sequential business process elicitation and modeling. BPMN is a modern process modeling notation, that includes the graphical elements to represent business event-driven, not just sequential process flows.

With these tools in-hand, process analysts, quality improvement professionals, and business analysts, are capable of eliciting, perceiving, normalizing, defining and graphically illustrating structurally sound, modern business process structures.

[1] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera, 2018, 2022) www.ProcessModelingAdvisor.com

[2] Object Modeling Group, www.OMG.org

[3] Universal Process Modeling Procedure, Step 3 – Define Basic Business Process Flow (Metera, 2018, 2022)

[4] Universal Process Modeling Procedure, How to Specify Event/Outcome Oriented Business Process Flow (Metera, 2018, 2022)

[5] Universal Process Modeling Procedure, Step 5 – Refine Business Process Flow(s) (Metera, 2018, 2022)

Avoid Illusory Constraints And Incentives

Written by Adrian Reed on November 23, 2022. Posted in Articles.

If you were learning to drive in the UK, chances are you’d get in touch with a driving instructor. Over here, many of the driving schools they work for have company names starting with the number 1 (often ‘1st CompanyName Driving School’). I suppose if I were a driving instructor my default company name would be “1st Reed” or something similar.

It might seem curious as to why there are so many driving schools with “1st” in their company names. We might assume it’s a signal that people who learn with them pass their driving test first time… but I suspect there’s another legacy reason, which goes back twenty years or more. You see, when I learned to drive, you didn’t Google a driving instructor, you used the Yellow Pages.

For anyone unfamiliar with the Yellow Pages, it used to be a thick local telephone directory of different companies. It probably still exists, but twenty years ago it was an essential reference for every household and could usually be found close to the (corded) landline telephone. It was printed on thin yellow paper, and had thousands and thousands of companies listed.

You’d search for a category (‘driving instructor’) and then (with the exception of paid ads) the companies were generally listed in alphabetical order. And company names starting with numbers were given preference, so a company named “1st Aardvark Driving School” would be listed above “Aardvark Driving School”… hence the incentive to start a company name with the phrase “1st…”.

The Constraints and Incentives Of Yesterday Might Be Irrelevant Today

Today, I would guess that very few people search for a driving school using a paper telephone directory, so this necessity to preface a company name with ‘1st’ is no longer valid. Not only this, it could actually hinder findability…. Imagine if you heard somebody say their company name was “First Reed”. Would the URL be 1stReed.com, FirstReed.com, First-Reed.com, or something else? What keyword would you type into Google to search for them?

I wonder if issues of ‘digital findability’ might also start to affect musicians. With more and more people using voice-activated assistants, bands might get more airplay if they have a band name and a song name that is “voice assistant friendly”. Don’t believe me? Try to get an AI assistant to find music by 90s band Campag Velocet and you’ll likely see the problem.

The point here is that constraints and incentives of yesterday (“We must start our company name with ‘1st’” or “Unusual band names sell records!”) might actually be disadvantages today. The incentives and constraints have changed, and those that recognize that can use it to their advantage.

What This Means For BAs: The Importance of Healthy Challenge

This is where good business analysis helps. It often feels that there is a human tendency to revert-to-norm and to “do what we’ve always done”. In our world as BAs, this might relate to the way work is undertaken, the way a process works, or the way that technology is used.

In these situations there is a huge opportunity to tactfully challenge: to ask does it still need to be that way? And also ask what are the implications if it is implemented that way? Are we ‘baking in’ a constraint that is no longer relevant?

This starts by identifying those tacit assumptions and constraints and seeing whether they are really still valid. Techniques such as ‘five whys’, the brown cow model, or just informally asking questions with curiosity and listening deeply to the response can help a great deal.

Whichever techniques we use, having the confidence to build rapport and tactfully challenge accepted practices is key. Sometimes there might be a valid reason for the status quo… but if there isn’t, we might be able to help co-create a better way with our stakeholders. And if we can create something better, cheaper, slicker, better… that has to be a good thing!