Skip to main content

Author: Sergey Korban

BATimes_Sep6_2023

Best of BATimes: How to Prevent the Negative Impacts of Poor Requirements

Written by Sergey Korban on . Posted in Articles.

There is an abundance of stories of failed projects. Research has shown the reasons for IT project failure in the USA, indicated that project success rates were only 34%, with the rest of projects being either “challenged” in some way or failing outright.

The losses can be very significant. For example, British food retailer Sainsbury had to write off its $526 million investment in an automated supply-chain management system. The U.S. Federal Aviation Administration spent $2.6 billion unsuccessfully trying to upgrade its air traffic control system in the 1990s. Ford Motor Company abandoned its purchasing system in 2004, after spending $400 million. In the 8 years since, things probably haven’t changed much.

From the project management perspective, technology projects fail when they do not meet the following criteria for success:

  1. Project delivered on time
  2. Project completed on or under budget
  3. The delivered solution works as required by business stakeholders.

 

A number of factors are involved in any particular project failure. The most often quoted factors are listed below:

  1. Lack of stakeholder involvement
  2. Unrealistic time scales
  3. Poor requirements
  4. Scope creep
  5. Uncontrolled changes
  6. Insufficient testing.

 

The quality of requirements can have a lot of impact on the outcome of the project. One high profile project which was significantly affected by the requirements management process was the Chrysler Comprehensive Compensation System which was supposed to handle paychecks for Chrysler’s 87,000 employees but was shut down after several years of development.

The impact is magnified as the BA moves from high-level requirements towards functional and non-functional requirements. The cost of rework of functional requirements is the highest because these requirements define the technical specification and design of the solution.

Here is a visual summary of the impacts:

korbanIMG01 April30

Project Impacts

Projects are undertaken by the business to satisfy a strategic goal. Poor requirements have the following effects on projects (and subsequently impact the strategic goals of the business):

  • Scope creep negatively affecting budget and completion time
  • Low utilization of resources and higher overheads
  • Inadequate business process design (due to insufficient details about activities)
  • Poor design and ergonomics of the user interface, resulting in lower productivity
  • Inadequate software specification, resulting in lower developer productivity
  • Poor specification amplifies the negative effect of poor requirements when it comes to software testing, leading to higher costs and lower quality of the solution
  • Time-consuming and costly code rework
  • Difficulties in solution integration.

Business/Organization Impacts

More generally, the business as a whole is affected in many different ways by poor requirements through the projects that the business undertakes. Here is the short list of negatively affected areas that I have witnessed:

  • Lost opportunities for the business
  • Lost advantage relative to competitors
  • Breaches of regulatory compliance
  • Poor stakeholder engagement and loss of trust
  • Reduced business process efficiency due to poor solution design
  • Negative user experience due to cumbersome UI design
  • Lack of cohesive IT landscape due to poor integration
  • Negative impact on the bottom line, generally speaking.

 

How to Prevent Poor Requirements

In my experience, there are two ingredients in any given project which help me deliver quality requirements. One ingredient is what I know about the business and the project. The other one is the techniques I use to ensure that I deliver great results.

It probably sounds quite vague at this point, so let’s dive into the specifics.

 

Advertisement

 

Knowledge Needed for Quality Requirements

The foundation for creating the future solution is a good level of understanding of the current state. Regardless of the methodology you are following, you have to start here. What do you need to know?

  1. Know the Context in which the Business Operates

    The business operates in two contexts. One is the external context where market forces define how the business operates and maintains its sustainability. This includes regulatory requirements, competitors and partners.

    The second context is internal. It is actually more complex as it includes organizational structure, business processes, governance around the processes (business rules), people involved in the processes, internal politics, organizational culture and overall pace of changes within the business you work for.

  2. Understand the Business Problem or Opportunity

    This is the actual driver for the project. Without knowing the real business need you won’t be able to find the solution that solves that problem.

  3. Identify Gaps to be Bridged

    Once the business problem and stakeholder concerns are clear, you can draft the future state. When the future state has been confirmed with stakeholders, perform gap analysis. Your focus here is on what should be done within the project scope to resolve the identified problem. It is also good to think about extra value the business can get as a result of the project.

Extra value can be delivered when you have a clear understanding of changes going on in the organization, and how the project you are engaged in fits into the change landscape.

 

Techniques for Better Requirements

The techniques I’ve settled on in my practice enable me to use stakeholders’ time efficiently and get a clear picture of the current state. Let me share them with you.

  1. Do Your Homework: Before engaging stakeholders in requirements gathering activities, I read all available documentation on business processes, business applications in use, regulatory requirements (if any), internal communication about changes in the organization, as well as other projects that may have dependencies with the project I am in.I also explore information relevant to the industry as a whole to identify possible good practices that I can re-use.I call this exercise my “homework”. The benefits of the homework exercise are that I know the “language” I will use when talking with stakeholders. I also know what to articulate to confirm information that is unclear. I feel confident about my part in the project and I know that I can help the business.
  2. Power Up Communication with Visuals: There is nothing better than diagrams to explore the current state and get an idea about the desired future state. The time savings due to using visuals can be enormous. How much time do you spend to define the future state? If you don’t use diagrams at present, you could probably save a significant portion of that time. Outline organizational boundaries, processes and data they use, add used applications, process and technology interfaces where required, and finally add roles involved in the processes. Now you have a snapshot of the current state.
  3. Use Templates to Support Your Work: Any business analysis task has to be organized to save your valuable time. Templates are of great help here as they let you re-use the common parts of documentation, and customize as necessary. They also serve as a kind of checklist of required documentation, and ensure that you don’t miss anything. My favourite template is the Current State Analysis. It includes analysis findings, identified business need, visualized current state (including the external context) and recommendations on what the solution may look like in terms of capabilities.
  4. Avoid Common Pitfalls: Requirements become poor and vague when they mix project related tasks, statements about the future state, applied rules and solution design. A good way to avoid these common project pitfalls is to plan business analysis, and to document the planned activities and deliverables in the Business Analysis Plan. It’s an integral part of the project plan. However, the Business Analysis Plan does not deal with project tasks.A hierarchical approach has to be taken to the future solution. Firstly, list the required solution capabilities. They can include both changes to business processes and technology services supporting these processes.Secondly, translate these capabilities into a business process design and business requirements for supporting technology services. You always need to tweak a business process if you change software used to support the process.Thirdly, add relevant business rules to justify future business logic.Next, validate the business process design and specified business requirements with the stakeholders.Finally, transform the validated requirements into functional requirements. These will guide the development and implementation of the solution. Don’t forget to describe business data (along with data types) to be used within the solution.

Adding prototypes of the user interface will make the functional requirements more precise and also help establish new terminology to be used in the solution.

These steps are executed in an iterative fashion so they align well with modern “fast” methodologies such as Agile and Scrum.

 

Summary

Poor requirements may lead to project failure. Functionality that is poorly specified, implementing something that isn’t needed, poor processes, lost development time, missed project deadlines, poor quality of documentation – the list of impacts can go on and on.

I believe that we as business analysts can do our job well and contribute to business success. Sometimes we don’t have enough time to stop and consider why our requirements are poor.
In the article above I listed the key ways to improve requirements. I’ve tested these approaches in many projects and they always produce positive results.

I hope they will help you, too!

 

 

Published on: Apr 30, 2013

Project Manager and Business Analyst In Tandem for Success

Written by Sergey Korban on . Posted in Articles. 1 Comment on Project Manager and Business Analyst In Tandem for Success

korban Nov25I’ve been working in project management and business analysis domains for many years. The projects I’ve been engaged in cover regulatory compliance, business process improvements, software development, ERP implementation and ITIL adherence, just to name a few.

Heated discussions about relationships between a project manager (PM) and a business analyst (BA) are often focused on their non-aligning sides rather than on their mutual efforts to ensure project success.

I tend to think about PMs and BAs working together in projects as two hands carrying a baby. Here is my view on the PM-BA tandem and how it comes together to make a project successful.

 How It Works

I’ve been involved in multiple projects for the last two decades. The projects were of different scales and nature. However, there is one common element in all of them:  a project manager and a business analyst are the two sides of the same coin. Their skills and joined efforts make a project successful and deliver good value to the business. I would like to demonstrate how a PM and a BA could work on a project, and explore each project phase in more detail. Please note that project phases and the documentation involved follow PRINCE2®.

Project Start Up

PM and BA work with project stakeholders throughout the entire project lifecycle. Before the project starts, a PM deals with business stakeholders to identify the business need at a high level. The outcome of this interaction is a Project Initiation document. This document outlines the business need, the impact of the current state on the business, the desired target state, project complexity, estimated project duration and expected benefits.

 ba-pm-article-diagram

 PM-BA: Collaboration Model

Project Initiation

The PM engages the BA to help with project scoping and definition of the business need, expected project outcome (deliverables) and project acceptance criteria.

While the PM works on drafting a project plan, the BA develops a BA plan outlining BA deliverables, communication patterns with stakeholders, requirements management approach and estimation of effort. The BA agrees the BA plan and Requirements Management plan with the PM.

Once the plans are agreed, the BA works closely with the project stakeholders on clarifying the business need, specifying high level business requirements, conducting stakeholder analysis, identifying risks, assumptions and constraints, as well as tolerances to a solution. The BA determines solution scope, high level requirements, solution approach, reusable and new components to be used in the final solution. The BA works closely with the PM to align solution scope with project scope. The BA informs the PM about all identified and potential risks.

The PM maintains the risk register and develops mitigation strategies for the identified risks.

The joined efforts result in two key documents: Project Vision and Solution Vision. The former contains the problem statement, desired outcome statement, acceptance criteria for deliverables, stakeholder analysis, business context, assumptions, constraints and scoping definitions (in scope/out of scope).

The latter describes the problem statement, solution statement, provides a solution overview, stakeholder summary (RASCI), determines “to be” capabilities and business context, defines what is in and what is out of solution scope.

These two documents support the Business Case document in medium and large projects, supporting project sponsor’s decision-making on whether to go ahead with the project.

The PM and BA work jointly on developing a WBS to ensure that the solution can be assembled in a way that enables cost efficiency and adherence to project time and resource constraints.

Project Execution

This phase flags even more close collaboration between PM and BA. They work together in requirements workshops to prioritise and validate requirements. They conduct workshops with vendors of components to the solution (where applicable).

Changes to solution scope lead to changes in project scope so the PM applies change management process to ensure that only justified changes will be accepted. The PM maintains the change request register throughout the project.

BA’s reporting on progress in turn supports the PM’s reporting on project progress to the project sponsor and other interested parties.

The PM supports the BA in communication with solution architects, software developers and other engaged third parties with regards to solution validation activities. The same is true when it comes to user acceptance testing. The PM’s support is invaluable here.  The duo works hard to ensure that solution acceptance criteria will be met within the predefined tolerances. The BA facilitates solution implementation to ensure a smooth transition to the “business as usual” mode.

Project Closure

Having the project deliverables accepted by the business, the PM works on closing the project. The BA facilitates the project closure by providing feedback for the post-implementation review. The BA reports on how well the solution met the business requirements. They jointly work on the Lessons Learned log to ensure that all valuable information has been captured for further use in future projects.

The BA hands over artifacts such as business requirements, functional requirements, use cases, non-functional requirements and solution technical specification to the business. These artifacts form a basis for business documentation on how to use the solution.

When the project has been formally closed, the BA files all approved BA artifacts in a central repository.

Pain Point

From observing over the years how different PMs tackle their projects, I would like to highlight some things that can trigger a blaming attitude.

A bossy attitude to a BA, a lack of understanding of the business domain, skipping important project background where the rotation of PMs takes place, “managing” customer expectations without involving the BA, expectations of having the final solution requirements identified by the BA after a single requirements elicitation iteration with project stakeholders – all these elements create a foundation for blame for not delivering on time and under budget.

Conclusion

The complexity of modern projects has increased to a great degree. Changes to business processes are coupled with changes to business applications, IT infrastructure, and interfaces with the company’s environment. The PMs and BAs are required to be more productive in projects of different nature. My experience gained from over 35 projects confirms that to deal with the changing demands and make projects successful, the BA and PM should work in tandem pushing towards the finish line.

Shared responsibilities, mutual respect and support combined with collaborative attitude pave a way to project success.

Don’t forget to leave your comments below.

How to Prevent the Negative Impacts of Poor Requirements

Written by Sergey Korban on . Posted in Articles. 2 Comments on How to Prevent the Negative Impacts of Poor Requirements

There is an abundance of stories of failed projects. Research has shown the reasons for IT project failure in the USA, indicated that project success rates were only 34%, with the rest of projects being either “challenged” in some way or failing outright.

The losses can be very significant. For example, British food retailer Sainsbury had to write off its $526 million investment in an automated supply-chain management system. The U.S. Federal Aviation Administration spent $2.6 billion unsuccessfully trying to upgrade its air traffic control system in the 1990s. Ford Motor Company abandoned its purchasing system in 2004, after spending $400 million. In the 8 years since, things probably haven’t changed much.

From the project management perspective, technology projects fail when they do not meet the following criteria for success:

  1. Project delivered on time
  2. Project completed on or under budget
  3. The delivered solution works as required by business stakeholders.

A number of factors are involved in any particular project failure. The most often quoted factors are listed below:

  1. Lack of stakeholder involvement
  2. Unrealistic time scales
  3. Poor requirements
  4. Scope creep
  5. Uncontrolled changes
  6. Insufficient testing.

The quality of requirements can have a lot of impact on the outcome of the project. One high profile project which was significantly affected by the requirements management process was the Chrysler Comprehensive Compensation System which was supposed to handle paychecks for Chrysler’s 87,000 employees but was shut down after several years of development.

The impact is magnified as the BA moves from high-level requirements towards functional and non-functional requirements. The cost of rework of functional requirements is the highest because these requirements define the technical specification and design of the solution.

Here is a visual summary of the impacts: 
korbanIMG01 April30

Project impacts 

Projects are undertaken by the business to satisfy a strategic goal. Poor requirements have the following effects on projects (and subsequently impact the strategic goals of the business):

  • Scope creep negatively affecting budget and completion time
  • Low utilzation of resources and higher overheads
  • Inadequate business process design (due to insufficient details about activities)
  • Poor design and ergonomics of the user interface, resulting in lower productivity
  • Inadequate software specification, resulting in lower developer productivity
  • Poor specification amplifies the negative effect of poor requirements when it comes to software testing, leading to higher costs and lower quality of the solution
  • Time-consuming and costly code rework
  • Difficulties in solution integration.

Business/organization impacts

More generally, the business as a whole is affected in many different ways by poor requirements through the projects that the business undertakes. Here is the short list of negatively affected areas that I have witnessed:

  • Lost opportunities for the business 
  • Lost advantage relative to competitors
  • Breaches of regulatory compliance
  • Poor stakeholder engagement and loss of trust
  • Reduced business process efficiency due to poor solution design
  • Negative user experience due to cumbersome UI design
  • Lack of cohesive IT landscape due to poor integration
  • Negative impact on the bottom line, generally speaking.

How to prevent poor requirements

In my experience, there are two ingredients in any given project which help me deliver quality requirements. One ingredient is what I know about the business and the project. The other one is the techniques I use to ensure that I deliver great results. 

It probably sounds quite vague at this point, so let’s dive into the specifics. 

Knowledge needed for quality requirements

The foundation for creating the future solution is a good level of understanding of the current state. Regardless of the methodology you are following, you have to start here. What do you need to know?

  1. Know the context in which the business operates

    The business operates in two contexts. One is the external context where market forces define how the business operates and maintains its sustainability. This includes regulatory requirements, competitors and partners.

    The second context is internal. It is actually more complex as it includes organizational structure, business processes, governance around the processes (business rules), people involved in the processes, internal politics, organizational culture and overall pace of changes within the business you work for.

  2. Understand the business problem or opportunity

    This is the actual driver for the project. Without knowing the real business need you won’t be able to find the solution that solves that problem. 

  3. Identify gaps to be bridged

    Once the business problem and stakeholder concerns are clear, you can draft the future state. When the future state has been confirmed with stakeholders, perform gap analysis. Your focus here is on what should be done within the project scope to resolve the identified problem. It is also good to think about extra value the business can get as a result of the project.

Extra value can be delivered when you have a clear understanding of changes going on in the organization, and how the project you are engaged in fits into the change landscape.

Techniques for better requirements

The techniques I’ve settled on in my practice enable me to use stakeholders’ time efficiently and get a clear picture of the current state. Let me share them with you. 

  1. Do your homework

    Before engaging stakeholders in requirements gathering activities, I read all available documentation on business processes, business applications in use, regulatory requirements (if any), internal communication about changes in the organization, as well as other projects that may have dependencies with the project I am in.

    I also explore information relevant to the industry as a whole to identify possible good practices that I can re-use. 

    I call this exercise my “homework”. The benefits of the homework exercise are that I know the “language” I will use when talking with stakeholders. I also know what to articulate to confirm information that is unclear. I feel confident about my part in the project and I know that I can help the business.

  2. Power up communication with visuals

    There is nothing better than diagrams to explore the current state and get an idea about the desired future state. The time savings due to using visuals can be enormous. How much time do you spend to define the future state? If you don’t use diagrams at present, you could probably save a significant portion of that time.

    Outline organizational boundaries, processes and data they use, add used applications, process and technology interfaces where required, and finally add roles involved in the processes. Now you have a snapshot of the current state.

  3. Use templates to support your work

    Any business analysis task has to be organized to save your valuable time. Templates are of great help here as they let you re-use the common parts of documentation, and customize as necessary. They also serve as a kind of checklist of required documentation, and ensure that you don’t miss anything.

    My favourite template is the Current State Analysis. It includes analysis findings, identified business need, visualized current state (including the external context) and recommendations on what the solution may look like in terms of capabilities.

  4. Avoid common pitfalls

    Requirements become poor and vague when they mix project related tasks, statements about the future state, applied rules and solution design.

    A good way to avoid these common project pitfalls is to plan business analysis, and to document the planned activities and deliverables in the Business Analysis Plan. It’s an integral part of the project plan. However, the Business Analysis Plan does not deal with project tasks.

    A hierarchical approach has to be taken to the future solution. Firstly, list the required solution capabilities. They can include both changes to business processes and technology services supporting these processes.

    Secondly, translate these capabilities into a business process design and business requirements for supporting technology services. You always need to tweak a business process if you change software used to support the process.

    Thirdly, add relevant business rules to justify future business logic. 

    Next, validate the business process design and specified business requirements with the stakeholders.

    Finally, transform the validated requirements into functional requirements. These will guide the development and implementation of the solution. Don’t forget to describe business data (along with data types) to be used within the solution.

Adding prototypes of the user interface will make the functional requirements more precise and also help establish new terminology to be used in the solution.

These steps are executed in an iterative fashion so they align well with modern “fast” methodologies such as Agile and Scrum.

Summary

Poor requirements may lead to project failure. Functionality that is poorly specified, implementing something that isn’t needed, poor processes, lost development time, missed project deadlines, poor quality of documentation – the list of impacts can go on and on.

I believe that we as business analysts can do our job well and contribute to business success. Sometimes we don’t have enough time to stop and consider why our requirements are poor.
In the article above I listed the key ways to improve requirements. I’ve tested these approaches in many projects and they always produce positive results.

I hope they will help you, too!

Don’t forget to leave your comments below.

The Structure of Business Analysis Documents

Written by Sergey Korban on . Posted in Articles. 74 Comments on The Structure of Business Analysis Documents

The structure of business analysis documents isn’t a commonly discussed topic. This article will show what documents are produced by a BA and the main sections they contain.

These are the main documents produced by a BA over the course of a project:

  • Current state analysis document
  • Project vision document
  • Solution vision document
  • Business requirements document
  • Business process design document
  • Use case model document
  • Use case specification document
  • System-wide requirements document
  • Solution glossary

 

The diagram below shows the attributes common to all documents:

 

Korban Diagram01 08 05 2012

Current State Analysis

Once a project has been mandated and the Project Initiation document (PID) is drafted, a business analyst can start to work on requirements gathering. In my experience the best way to tackle this task is to start from current state analysis. It helps understand the business need, primary pain points, business processes affected, the stakeholders involved in these processes, and so on.

The area of the current state analysis is illustrated below:

Korban Diagram02 08 05 2012

The main purpose of the analysis is to present the “AS IS” state: the existing business context, background, business functions and existing business processes, and finally stakeholders involved in these business processes. Depending on the project nature, some components of the underlying infrastructure can be included in the document as well.

A Current State Analysis document lists the key pain points within the identified business processes and tasks within them, and highlights the areas where a change is expected.

The last section of the document is about presenting recommendations. It recaps the key findings and lists the key changes expected. Any caveats should be presented here as well.

The content structure of the Current State Analysis document is presented below:

Korban Diagram03 08 05 2012

This document serves as a foundation or a reference point for other artifacts produced by a business analyst. The other documents will be discussed in the following articles.

Project Vision

The Project Vision is a document which is shared by a project manager and business analyst. They work together to outline the problem statement, determine the desired state, describe the criteria of business acceptance of the deliverables and how project success will be measured. The document contains a section with stakeholder analysis which shows all the parties involved along with their responsibilities and needs:

Korban Diagram4 08 05 2012

The business analyst adds the high level requirements which are within the scope of the project, and marks each requirement as compulsory or optional. To clearly define the project scope and avoid ambiguity, all out-of-scope requirements are also listed at the end of the section.

Based on the results of the current state analysis the business analyst describes the current business context, the key business processes and services used to support them. After that the required changes are mapped to the current business context. It can be a good idea to present this mapping as a diagram for easy communication of the proposed changes to the business stakeholders.

Solution Vision

Once the Project Vision document is approved, the preparation of the Solution Vision document starts.

Korban Diagram05 08 05 2012

First, the business analyst recaps the problem statement from the Project Vision artifact. The solution statement describes the target audience of the solution, what will be satisfied by the solution and what the key benefits will be. The statement of differentiation of the solution from possible alternative options is added as a conclusive point in positioning of the solution.

The document describes stakeholders within the target audience along with their roles using a RACI matrix.

The main part of a Solution Vision is a detailed section devoted to the solution capabilities comprised of both functional and non-functional features, with priorities given by the business stakeholders.

The next section presents the business context in its future “to be” state. It’s a good idea to include a a diagram illustrating the key changes and additions to the existing state, as well as a brief narrative to clarify the proposed changes.

Similarly to the Project Vision document, the features that are out of scope are clearly listedin the last section to make sure everyone is on the same page with regards to what will be implemented.

Business Requirements

This document focuses on providing details about the current processes and gives enough information to describe the business problem and how it fits into the scope of the project. This section reiterates the findings of the Current State Analysis document, however here they are aligned with the project objectives.

Korban Diagram6 08 05 2012

The business requirements that are going to be fulfilled by the solution are listed in the “In Scope” section. Business rules that apply to the described requirements are presented in a separate section. This approach simplifies the confirmation of the rules with business stakeholders. 
Any assumptions and dependencies identified in relation to the business requirements are to be listed in the appropriate section.
The proposed changes to stakeholder roles, new or modified business processes and business services that support them are presented in the last section.

Business Process Design

This document focuses on the scope of changes to business processes, providing details about the current business context, existing business processes, and stakeholders involved in these business processes.

Korban Diagram7 08 05 2012

It also describes the future state: the proposed business processes and the “to be” information environment. The new processes are accompanied with narratives to facilitate communication of the proposed changes to stakeholders and business end users. This “as is” section reiterates the findings of the Current State Analysis document, however here they are aligned with the changes to supporting business services.
Any assumptions and dependencies identified in relation to changes to the business processes are listed in the appropriate section.

Use Case Model

The Use Case Model lists all the scenarios for using the solution required by the business stakeholders. It is useful to describe the solution as a set of functional areas and group the scenarios per functional area. Such an approach allows to use this document more efficiently in communication with the business stakeholders as they can easily refer to the sections of their interest.

Korban Diagram08 08 05 2012

The model lists all possible scenarios in scope, their brief summary, actors involved in each scenario, frequency of use, triggering events and the two possible outcomes – success and failure.
One of the key attributes of the scenarios is a reference to the high-level requirements and required capabilities which allows to establish traceability.
Note: when making changes to Use Case Specifications, do not forget to update the Use Case Model document accordingly.

Use Case Specification

A Use Case Specification document presents more detailed information about the use cases in the Use Case Model document.

Korban Diagram09 08 05 2012

Each specification includes:

  • Brief use case overview
  • Reference to the functional area
  • Preconditions
  • Actors involved
  • Main flow
  • Alternative flows
  • Exception handling flows
  • Functional requirements for the solution
  • Traceability to the business requirements
  • Market or business rules applicable to the scenario
  • User interface, controls and data

System-Wide Requirements

This document is prepared when the Business Requirements, Use Case Model and Use Case Specifications are complete. The main purpose of the document is to present a “qualitative” side of the solution.

Korban Diagram10 08-05-2012

The “Load patterns” section is the most interesting as it illustrates how the solution is expected to be used during a business day. This information gives good insight into business requirements from the “non-functional” perspective and helps clarify the business requirements where required.As solutions are often based on information technology, some attention should be given to solution resilience. Disaster mitigation approaches and solution recovery requirements play a major role here.It is a rare case nowadays that a solution is completely new. The common practice is to integrate the solution into the existing business environment. The system-wide requirements document describes the interfaces with internal and external systems and solutions, the data flowing between them, its formats and data elements. Where the solution should interface with external systems, samples of data must be presented in appendices.Apart from business reporting capabilities, the solution must provide reporting capabilities for monitoring how the solution operates. These reports are listed in the last section of the document.

Solution Glossary

Business stakeholders often use terms and jargon in their communication. To get up to speed with this terminology (you can be quite new to it), the Solution Glossary document is used. It helps establish common terminology for the project team and key stakeholders, and for use within the solution. The structure of this document is simple:

Korban Diagram11 08 05 2012

It’s a good practice to divide the solution into functional areas. These functional areas serve as small knowledge domains for the stakeholders involved in the project. This document serves as a reference point for all the previously discussed documents.

Don’t forget to add your comments below.

Addressing Information Security in Business Analysis with SABSA

Written by Sergey Korban on . Posted in Articles. 1 Comment on Addressing Information Security in Business Analysis with SABSA

Feature Apr24 36090508 XSIn this article, I would like to show how the SABSA (Sherwood Applied Business Security Architecture) framework can be applied to address information security as part of business analysis.

In the business analysis domain, information security was not of much interest throughout the last decade or so. However, an incredible rate of development in mobile technology and the penetration of mobile computing into the corporate environment has increased the importance of information security.

This has led me to explore how the SABSA framework can be helpful to a business analyst in addressing the security needs of the business. While I have found quite a lot of value in applying the ITIL framework, I think the SABSA framework aims to fill the gaps in the ITIL framework regarding information security.

The Governance Pyramid

First of all, let’s consider governance. Governance in any business is not a simple set of internal rules. Each business has its own policies and procedures governing the functioning of the business, and they form the bottom layer of the governance pyramid.

Alex Governance Pyramid

Best practices are incorporated to improve the functioning of the business and make it more competitive and sustainable. These practices make up the middle layer of the governance pyramid.

The top layer consists of industry regulation and laws coupled with standards to which businesses have to adhere.

Each of these layers has specific information security requirements. However, they are not consistent across these layers as there is no underlying system that translates multiple requirements into a cohesive set of requirements applicable to a particular business and covering the business objectives.

The SABSA framework serves as a system to ensure that the information security needs of an organisation are thoroughly understood, designed, delivered and well supported along with the IT infrastructure.

The Four Ps

Successfully ensuring information security is not just about using the best hardware and software. It requires a broader view that incorporates the four Ps: People, Processes, Products and Partners.

 Alex 4 Ps

Internal policies, well-designed processes with a focus on information security, properly configured hardware and software products, and well maintained relationships with partners and suppliers create a coherent set of information security practices within the business.

How SABSA Empowers a Business Analyst

As SABSA is an enterprise security architecture framework, it can be used for the development of business solutions at any level of granularity and complexity.

Alex Security Service Arch

The value that SABSA creates for business analysis lies in the questions that have to be answered before beginning a solution design. These questions help specify the solution more precisely and avoid costly mistakes and low user satisfaction.

The SABSA model has a layered structure as shown in the diagram above. Each layer provides a set of questions asked from different viewpoints.

The contextual layer guards business analysts from jumping to a conclusion at the start of a project. It gives a business analyst the following information:

  • business context
  • business asset taxonomy
  • business motivation
  • affected processes
  • users involved in the processes
  • location where the solution is required
  • time when the solution needs to be available.

The common questions to ask here are:

  • Why does the business want this solution?
  • What type of solution should be built?
  • What aspects of business security should be addressed?
  • How will the solution be used?
  • What business processes and data require information security?
  • Who will use the solution (types of users, their mobility and their numbers)?
  • What credentials should be allocated to users to enable the use of the solution?
  • Where should the solution be located?
  • What security measures should be in place to ensure the secure use of the solution?
  • What are the solution’s relationships with the existing business landscape?
  • When will the solution be used (usage patterns, critical business days, etc.)?

The conceptual layer is concerned with the selection of logical and physical components that will be used to build the solution later. Here the business analyst learns about:

  • business risk strategy
  • control objectives
  • the process mapping framework
  • IT architecture strategies
  • roles and responsibilities of stakeholders (users, service providers).

The questions revolve around the security principles that will be used within the solution, and include the following:

  • What business information should be protected within the solution?
  • Why is the protection of the identified information important?
  • How can the required protection be achieved at the business process level?
  • Who will be involved in security management during the production use of the solution?
  • Where should the protection be applied (boundaries)?
  • When is the protection sufficient (measurement)?

Proceeding downwards, we come to the logical layer. This layer helps the business analyst determine:

  • the current inventory of IT assets (CMS means Configuration Management System. See ITIL v.3 for more detail)
  • risk management policies
  • processes and enabling IT services (service catalogue)
  • entities and trust models
  • interaction flows between locations
  • schedule of events (start time, duration, end time).

In practice, the contextual and logical layers listed above are the most difficult and few businesses are ready to demonstrate what they have in place. The reason for this awkward state is that quite often the IT department does not have a business service catalogue and a supplementary configuration management system detailing all IT assets.

The following questions should be asked at this point:

  • Why does the specified business data require protection (policies, regulation)?
  • What business data should be secured?
  • How should the business data be protected?
  • Who will be involved in securing the data? What will be their relationships?
  • Where do the security measures apply (security domains and their boundaries)?
  • When do the security measures start to apply (deadlines, schedules)?

The logical model ensures that the solution can satisfy the business objectives and are realistic from an engineering perspective.

Once the logical security modåel is understood, it is time to look at the physical layer. The logical model of information security is translated into the physical security mechanisms, and this layer helps the business analyst learn:

  • the business data dictionary
  • business data objects
  • risk management rules and procedures
  • existing applications, middleware and security mechanisms employed
  • user interfaces to IT services
  • access control mechanisms in use
  • the IT infrastructure (platforms, networks and their layout).

Here the following questions should be asked:

  • Why should the specific logic be applied (procedures, conditions, rules)?
  • What security-related data structures (business data models) should be included in the solution scope?
  • How will the security mechanisms (encryption, access control, digital signatures) be applied?
  • Who will be affected by the security mechanisms?
  • Where will the security infrastructure be hosted (locations, layouts, communication links)?
  • When will the specified security mechanisms be embedded into the processes?

Now let’s have a look at the existing environment and select the elements that will be re-used within the solution.

The component layer focuses on the assembly approach to ensure that all pieces fit nicely together and serve the purpose as expected. The logical and physical layers feed the gathered information into the component layer, which helps the business analyst learn:

  • the IT products (business applications, servers, repositories)
  • risk analysis, monitoring, recording and reporting tools
  • protocols used to enable business processes
  • user roles, their functions, actions and access permissions.

The questions to ask here are:

  • What IT components (applications, servers, repositories) are in the solution’s scope?
  • How will the specified IT components be used?
  • Who will assemble the components (identities, roles, access control)?
  • Where will the assembled components be located?
  • When should the assembly process start?
  • What is the time schedule for the solution to be assembled?

The final layer is security service management, which is concerned with ongoing maintenance of the solution and the embedded security mechanisms over the production use of the solution.

The answers obtained at this stage will facilitate the handover process at the end of the project. The questions to ask here are:

  • What service delivery practices will be applied to ensure operational continuity?
  • Why should these practices be in place (risk assessment, business continuity planning, risk monitoring and reporting)?
  • How will security-related operations (user security administration, data backups, security monitoring, etc.) be carried out?
  • Who will be responsible for account provisioning and user support management?
  • Where will the security service management be executed (locations, sites, buildings)?
  • When will the solution’s security service management be activated (security-related calendar or timetable)?

Added value to business analysis

When going through the layers discussed above, a business analyst will collaborate with architects, IT management, IT infrastructure practitioners and partners to ensure:

  • the collected information is accurate and unambiguous
  • policies and procedures are in place
  • the existing IT landscape is known to the architects
  • the existing components will be re-used to minimise solution costs and operational expenses
  • the organisation’s requirements are translated unambiguously to partners to ensure trustworthy relationships.

Conclusion

The core function of business analysis is to transform business needs into requirements and ensure that a solution carries out its intended purpose. It is often not sufficient to gather the requirements to a solution to satisfy the explicitly stated business need, but it is easy to skip the requirements for business security by incorporating people, business process and data, premises where the business resides, and trustworthy relationships with business partners.

One more challenge in practice is that stakeholders think that technology covers all bases on its own, and it is hard to get buy-in from senior management of an organisation regarding the need for well-established and maintained information security.

The SABSA framework encourages business analysts to ask more questions to make the requirements clear and fully stated. This framework helps business analysts learn more about the organisations where they work and deliver extra value to these organisations.

Don’f forget to leave your comments below.

  • 1
  • 2