Business Requirements

Views:
 
     
 

Presentation Description

Learn how to effectively define business requirements in your business or line of work using this free Business Requirements Template.

Comments

Presentation Transcript

slide 1:

August 17 2020 Business Requirements: How to Create a Business Requirements Document Free Template process.st/business-requirements Jane Courtnell August 17 2020 Business Management Project Management T o m: “I need a new warm down jacket for my next trip.” M e: “Great I would opt for Patagonia or Arcteryx.” Why did I recommend these brands to Tom and these brands only It is due to brand trust. I know these brands deliver exactly what I want consistently. As consumers Tom and I are Patagonia and Arcteryx stakeholders. We have expectations these two outdoor brands need to satisfy to retain our custom. These expectations translate into requirements. In this scenario our requirements were: Value for money Robust long-lasting products Functional products Products that deliver on their intention 1/17

slide 2:

Patagonia and Arcteryx meet the business requirements for their products satisfying stakeholder and business needs. And so the brands thrive with a good reputation brand identity leading to a healthy bottom-line and company success. Defining the business requirements of a new product project system service or software is vital. Without defined requirements there is an absence of clear goals focus and progression measures. This doesn’t bode well for success. For instance a study by Pulse of the Profession reported 37 of software projects failed due to poorly defined requirements. Because we don’t want you to fail in this Process Street article we explain exactly what business requirements are and how you can identify them for your business or line of work. We explain the benefits that come from correctly defining business requirements. We then clarify how you can document business requirements in a Business Requirements Document using Process Street’s Business Requirements Template. Sounds like the article you need to read to succeed…right As such let’s jump to it. Click on the relevant subheaders below to hop-across to that section. Alternatively scroll down to read all we have to say: Correctly defining the business requirements for your organization or line of work starts here. Keep reading and learn how to consistently meet the needs of your stakeholders. Ready Business Requirements Template To kick off this article I present you with Process Street’s free Business Requirements Template. Use this template to identify key stakeholder needs that must be met in your new project product service system or software. By using this template you will: Gain stakeholder agreement for the new product/service or project Communicate needed solutions that satisfy customer and business needs Provide the required input to introduce the changes necessary Describe what and how the customer/business needs will be met by your introduced changes. Click here to access our Business Requirements Template Don’t have a Process Street account No worries Sign up for a free trial today to get access to hundreds of premade templates like this one. What are business requirements and why you should care 2/17

slide 3:

Business requirements are critical activities an organization must perform to meet stakeholder needs and organizational objectives. Business requirements are set and documented in a Business Requirements Document BRD. When setting business requirements – also termed as Stakeholder Requirement Specifications StRS – a business process system software product or service is analyzed with the end-user as a priority. A solution to meet the needs of the end- users/stakeholders is detailed as a business requirement within the BRD. The BRD can be referenced at any point. From the below image you can see a skeleton structure of a BRD. 3/17

slide 4:

Understanding what business requirements are by grasping what business requirements aren’t Take a minute to think about the following for a moment: 1. An objective or expected benefit from a product/service/software/process or system 2. A description of a product/service/software/process or system ❓ Question: Which one of the above details a business requirement ❓ What’s your answer – Use the comments section at the end of this article to note down your thoughts as I would love to hear from you. If you have taken the time to note down your response I thank you ​ ♀ ️. But I also want to apologize as I have been a bit of a trickster. You see both of the above demonstrate exactly what a business requirement is not. Why The above are objectives or expected benefits of a product/service/software/process or system. Business requirements are not objectives or expectations in themselves rather they meet objectives and expectations when satisfied. It is important to understand this separation to accurately define what business requirements are so you can correctly identify the business requirements in your organization or line of work. For instance consider the following. I have split the example up in terms of objectives expectations and business requirements to highlight the differences. Objective: Improve employee efficiency Expectations: To increase output providing stakeholders with a quick responsive service Business requirement: Track employee time in the office From the above can distinguish between the objectives expectations and requirements This information can be added to your BRD as indicated in the image below. 4/17

slide 5:

Through rightful depiction and subsequent identification business requirements will: Reduce project failure rate: Misaligned or misinterpreted requirements can lead to project failure as stakeholder expectations are not met. Defining the business requirements creates a strong foundation from which a structured process or method is created to meet stakeholder needs. Contribute to the development of the business case: Well-defined business requirements help describe a project in its entirety. This is critical for the execution of a business strategy and to meet specific goals. Projects will remain on track reducing failure rate and providing positive traction with key project stakeholders. 5/17

slide 6:

Saves costs: The establishment of business requirements early on not only improves a project’s success rate but also reduces costs in the long run. Think about it by keeping a project on track change requests and the costs associated are reduced. In addition value is obtained from accurately delivering on the stakeholder need. Creates a user focus: An effective BRD uses integration and impact analysis within all departments prioritizing stakeholder needs. The aim is to balance the end user’s expectations with what is feasible to deliver. Business requirements vs functional requirements As we have established business requirements are key components for any business project. They ensure the end project results meet stakeholder needs. As you can see from the example BRD presented above ⬆ – see 3.1 Functional Requirements – ⬆ business requirements come as a pair along with functional requirements – some more jargon to add to your vocabulary. Functional requirements are a detailed breakdown explaining how a project outcome will operate to meet the business requirements specified. It’s getting a bit confusing isn’t it To explain further let’s run through an example. As a content writer at Process Street I work remotely along with other members of Process Street’s content creation team. Our team works hard to satisfy the business requirements set for our department. Our objective: To produce quality content regularly consistently meeting the needs of our readers and to get our posts ranking on Google’s front page Business requirement: Implement a system that reduces errors and increases the efficiency of written content production Functional requirements: To address how many employees the system must accommodate to fix common writing errors and identify the steps each writer must take to meet content quality needs 6/17

slide 7:

As you can see business and functional requirements are integral to a project. Business and functional requirements have a shared goal however functional requirements are far more specific. With continuous review comparing the functional requirements to business requirements your project will stay on track. Talking more about functional requirements is beyond the scope of this article. It is necessary to understand what functional requirements are though. For more information about functional requirements read: Functional Requirement Functional and Nonfunctional Requirements: Specification and Types 7/17

slide 8:

How to create a Business Requirements Document A Business Requirements Document BRD details the project of focus. As we have already discussed business requirements are highlighted in the BRD to clearly define what the organization hopes to achieve. Let’s say you introduce a new project product service software or system. Or you want to increase capacity retrench or reduce the capacity for other ventures. Or you change your focus. Regardless these changes demand new business requirements to be set. With so much going on sometimes it can be hard to handle these changes which is why a BRD is needed. The hard part of creating a BRD is gathering the right information. Luckily for you you have free access to Process Steet’s Business Requirements Template. This template details every step needed to create an effective BRD meaning you can stringently assess stakeholder’s needs to set your requirements appropriately. Creating a BRD using Process Street step 1: Identify stakeholder needs Once you have gathered your team determine how you will identify your stakeholder needs. Will you run focus groups Hand-out surveys Create a product prototype Our Business Requirements Template will detail best practices for each method used to identify the needs of your stakeholders see image below. 8/17

slide 9:

Best practices are detailed for each method used to identify stakeholder’s needs. In this case a stepped-process is given to successfully run focus groups for stakeholder’s need identification. Creating a BRD using Process Street step 2: Define organizational objectives expectations and requirements You can use the identified stakeholder needs to define organizational objectives and expectations. Use your objectives and expectations to define your business requirements. Creating a BRD using Process Street step 3: Determine work activities that correspond to a particular requirement Once you have identified your business requirements determine work activities that correspond to a particular requirement. For instance peer reviews following an Editing Checklist and team-wide reviews are 9/17

slide 10:

work activities used to reduce error in Process Street’s content creation process. Also following processes such as our Pre-publish Checklist maximizes content creation efficiency. Creating a BRD using Process Street step 4: Detail accountability priority metrics and acceptance criteria Next detail who is accountable for which requirement. List requirements in order of priority before deciphering metrics and acceptance criteria. To exemplify the latter at Process Street we follow a BAMM review system assessing the quality of produced content. A percentage score is given from following this system to determine how good a piece of content is detailing the needed amendments for the content to be of the quality required. 10/17

slide 11:

At this point the information you have so far obtained is summarized in the task titled business requirements report notes exemplified below. Once these notes are approved by the relevant personnel simply transcribe the information into an official BRD report. Creating a BRD using Process Street step 5: Create a business requirements checklist With a BRD clarity is provided focus is retained and ambiguity is removed. But your work doesn’t stop here. You need to devise a methodology to track and report the status of each requirement – remember meeting your business requirements is an ongoing process. As process masters we at Process Street recommend you create a project requirements checklist. Using this checklist will ensure all requirements are completed before the formal implementation of a new product/project/service/software or system. For more information on how you can create and edit checklists in Process Street watch the below video: Basics of Creating and Editing Templates. Creating a BRD using Process Street step 6: Effectively manage change in your organization As you introduce a new product/process/system/service or software you are installing change into your organization. To successfully satisfy your set business requirements your team needs to be open to the relevant proposed changes. For this you need to adopt a change management model that is proven effective. To help you Process Street’s content creation team has been working hard to provide top free template resources to help you plan for and manage change appropriately. 11/17

slide 12:

Keep reading for more information and access to these free change management model checklists. These checklists are to be used in conjunction with our Business Requirements Template for you to effectively execute change to meet your newly introduced business requirements. Creating a BRD using Process Street step 7: Continually manage your business requirements Implement systems that will continually report on your business requirements status and make sure the need for these systems is communicated within your team. Establish processes for your team to report on issues or concerns. Requirements may change or be altered in some way. It is important to acknowledge and accommodate this. Manage change appropriately via a change management model As previously mentioned introducing newly set requirements initiates organizational change that needs to be managed correctly. For successful management of change check out Process Street’s change management model checklists. Access to these checklists is provided below along with the relevant checklist details. Lewin’s Change Management Model Process Checklist In Lewin’s Change Management Model change is split into three stages: Stage 1: Unfreeze the status quo Stage 2: Make changes Stage 3: Refreeze to lock-in changes for a new status quo Lewin’s model breaks change down into bitesize chunks taking people and processes into account. The model works to release rigid processes to introduce change which in this case will allow the satisfaction of set business requirements. Click here to access Lewin’s Change Management Model Process Checklist Bridges Transition Model Process Checklist Bridges Transition Model looks at change as a journey instead of an abrupt shift. Three stages of this journey are detailed: Stage 1 – Ending losing and letting go Stage 2 – The neutral zone Stage 3 – The new beginning 12/17

slide 13:

Each stage is characterized by the feelings instigated within the employee during that period. In essence Bridges Transition Model provides emotional support to employees as changes are introduced to meet your set business requirements. Click here to access Bridges Transition Model Process Checklist ADKAR Model Change Management Process Checklist The ADKAR Model takes a bottom-up approach for the application of change. Each letter in the acronym stands for a goal to be reached: A: Awareness of the need for change D: Desire to participate and support the change K: Knowledge on how to change A: Ability to implement the required skills and behaviors for change R: Reinforcement to sustain change With these goals the ADKAR Model successfully plans for change on both an individual and organizational level. As a change management model ADKAR is easy to learn creates a new lens for viewing change drives action and addresses how change happens. Click here to access the ADKAR Model Change Management Process Checklist McKinsey 7-S Model Process Checklist The McKinsey 7-S Model identifies 7 elements of a company detailing how one will impact the other. These elements are split into 2 categories hard and soft. Hard elements are driven by management and are more tangible. Soft elements are driven by culture and are less tangible. Hard elements include: Strategy Structure Systems Soft elements include: Shared values Style Staff Skills The model aims to align these 7-S elements so that they support each other and the change objectives which in this case are to satisfy the introduced business requirements. 13/17

slide 14:

Click here to access the McKinsey 7-S Model Process Checklist PDCA Cycle Change Management Model Process Checklist The PDCA cycle looks at change as a continuous process for improvement. There are four stages: Stage 1: Plan Stage 2: Do Stage 3: Check Stage 4: Act These stages are iterative that is as a circle each stage is completed again and again and again… Problems are identified solutions are tested systematically results are assessed and new solutions are implemented when needed. It is recommended to use the PDCA Cycle as you come to the end of our Business Requirements Template in the ongoing requirements management section. Click here to access the PDCA Cycle Change Management Model Process Checklist Kotter’s Change Management Model Process Checklist Kotter’s Change Management Model’s core focus is to create a sense of urgency for change. The model states with this urgency momentum for change is obtained. The model splits the application of change into 8 stages: Stage 1 – Creating a sense of urgency Stage 2 – Building a core coalition Stage 3 – Forming a strategy vision Stage 4 – Getting everyone on board Stage 5 – Removing barriers and reducing friction Stage 6 – Generating short-term wins Stage 7 – Sustaining acceleration Stage 8 – Setting the changes in stone The first stages create drive within your team to implement the needed change. The following stages focus on sustaining this drive seeing the change through to the end. Click here to access Kotter’s Change Management Model Process Checklist Kubler-Ross Change Curve Process Checklist The Kubler-Ross Change Curve recognizes the emotional burden of change on employees within a company. These emotions can place a stranglehold on productivity. 14/17

slide 15:

However if acknowledged and managed correctly the negative emotional repercussions of change can be minimized. The Kubler-Ross Change Curve details five stages of grief during the change process: Stage 1: Denial Stage 2: Anger Stage 3: Bargaining Stage 4: Depression Stage 5: Acceptance With knowledge of these stages the model suggests a way to manage control and direct these emotions positively and progressively leading the way for change to meet your set business requirements. Click here to access the Kubler-Ross Change Curve Process Checklist Nudge Theory Change Management Model Process Checklist The Nudge Theory for change is more of a theory – hence the name – than a change management model. The idea is that individuals are nudged into making the desired decision by altering the environment in which the individual is making that decision. This environment is the choice architecture. You can use the Nudge Theory to introduce changes needed to meet your defined business requirements. Click here to access the Nudge Theory Change Management Model Process Checklist For more information on Nudge Theory and Choice Architecture read: Choice Architecture Explained: How To Remove Human Bias From Your Business Today Satir Change Management Model Process Checklist Developed by Virginia Satir the Satir Change Management Model explores five stages of grief that employees are predicted to feel during organizational change. These grief stages are: Stage 1: Late status quo Stage 2: Resistance Stage 3: Chaos Stage 4: Integration Stage 5: New status quo The stages are designed to track the impact of change on employee performance. In the long run meeting your newly defined business requirements will mean your business is more aligned with the needs of your stakeholders. Therefore despite the initial 15/17

slide 16:

emotional turbulence by managing this appropriately the benefits of the introduced business requirements will be realized in the long-run. Click here to access the Satir Change Management Model Process Checklist New to Process Street A quick tour to help you get started Process Street is superpowered checklists. How are our checklists superpowered Well as you shall witness via using our change management model checklists and our Business Requirements Template our checklists are jam-packed-full of first-class fabulous functional features. These include but are not limited to: Stop tasks to ensure task order. Dynamic due dates so no deadline is missed. Conditional logic creating a dynamic template that caters to your needs. Role assignments to ease task delegation within your team. Approvals allowing decision-makers to give the go-ahead or rejection on important items. Also the necessary comments can be provided. Webhooks so apps can send out automated messages or information directly to other apps. A great feature keeping your other tools notified about the status of checklists and tasks in Process Street. Task assignments to assign users and groups to individual tasks in your checklists making it easy to see who is responsible for what. Embed Widget allowing you to view and interact with other apps without leaving your checklist. I bet you’re itching to get started Sign up to Process Street for free today Start defining your business requirements today and consistently meet the needs of your stakeholders Establishing business requirements early on is vital for the success of a new product/project/service/software or system. Clearly defined business requirements will: Save you money Save you time Significantly reduce the probability of failure Contribute to the development of your business case Help you stay in sharp focus to deliver on your stakeholder needs. What’s there to lose With Process Street’s Business Requirements Template setting business requirements 16/17

slide 17:

has never been easier. Use our Business Requirements Template to create a BRD. Use your BRD along with our change management model checklists for the successful implementation of your new product/project/service/software or system. 17/17

authorStream Live Help