Business Requirements – Are you doing your Business Requirements well enough?
During all my years of doing business requirements gathering, software requirements engineering and requirements analysis on a wide variety of projects I have always managed to find a new challenge and a fresh new topic to learn more of. You may look at my BA certifications and think I follow lots of specific methodologies and must be doing business analysis strictly according to the book – after all in many Business Analyst Courses that is what you get taught to do. It is however quite the opposite with me. Sure, in the earlier years of being a business analyst I have wondered about which tools to use for which purpose when doing business requirements work and often had doubts about whether I was “doing it right”, but these days I only apply what is required and often it is only a fraction of what is prescribed by a tool or technique.
One of the aims of the Business Requirements Management game is to learn when to apply a particular methodology (such as Agile) or technique more based on professional intuition than any specific prescribed process. This is what makes this profession highly rewarding and diverse.
Business Requirements and YOU.
Understanding the Business Need.
As first step, we identify and engage with the key stakeholders. Have chat, a formal stakeholder interview or even a problem definition workshop, but it is essential to start the hunt for more information on ‘the business need’. Find the people or person who raised this need, talk to them first. The key stakeholders are those groups or individuals in the organisation that is affected by the current business problem and who will be affected by us introducing a solution. We will use various requirements gathering techniques and review many types of materials in a quest to understand their need or problem. Example stakeholders often include: department heads, business area managers, operation staff and offcourse your own project team members who may have information too!
Typical other sources of information of the business need or problem to find during this activity can include business cases, process documents, existing systems and artefacts such as invoices, application forms and so on. There are many different ways that we go about trying to understand what the business need is. A lot of collateral (more specifically referring to the Soft System Methodology as an example) will refer to this activity as the process of gathering information to understand the “unstructured” version of the business problem we are aiming to fix.
Translate the business need into an objective, clear and specific language.
Once we have gained a grasp on what the business need is, we start to translate and interpret that need into a more structured problem, need or description of our scope. Very importantly at this stage we document the business need into a language (business requirements, software requirements or functional requirements) which can be understood by the business. We don’t dive into any technical modelling or
‘analysis speak’ but where appropriate we will use techniques to illustrate the problem.
By now you would have used a decision making model to choose between methodologies and decided which one will fit best for your business requirements management on the project.
This key step of clarifying and drafting the business need can include diagrams such as use case diagrams, activity flows or process models to express the problem. These are great tools to use to demonstrate an understanding of a business problem’s current state and assist you in ensuring there is clarity around what the business need it that is being addressed. This step is iterative and involves a lot of discussion, rewriting, redrawing and finalising of what it is we are trying to solve. A handy tip here is for you to always get to the bottom of WHY is something a problem.
Determine where we are going to.
Once we clarified, expressed and agreed what the current business need is, we start the process of brainstorming ideas of how we can address this need (really start to gather business requirements in earnest). What is the stakeholder’s nirvana, what do they believe is the solution that will address the problem. Again, this process involves you engaging with all the stakeholders and getting people’s views in the most appropriate way. This can include more business requirements workshops, stakeholder interviews or even doing market research for relevant trends and products.
Important to note: You will find that the business stakeholders will start with the solution and often start providing software requirements way before stating and understanding the root of the problem of business need. It is your job to get to the problem or business need first!
Business Requirements – Manage change of business needs in our project.
Another very important part of this role on any project is to manage the change of business requirements right from the very start of any business or technology project. It doesn’t matter whether you are on a mostly unstructured waterfall based project, or whether you are on a closely managed Agile project the one thing that you will be managing is change. Change to business problem, change to requirements for a solution and change just because. All projects consist of a myriad of people and where there are people, there is constant change. It is well worth your while to plan for how you will manage change to your business scope, your business requirements and once you start implementing a solution, and how this will be managed. If you don’t manage the change factor on your project, you may be swallowed whole.
Build solid relationships with all stakeholders.
Leaving this crucial point to last is definitely not because it is least important. It is because it is most important! If you don’t have good relationships with the business stakeholders, your project team stakeholders and the supporting technical team stakeholders you will fail. You will not be able to do any of the above three important tasks effectively and business requirements efforts will not be as good if you neglect building strong relationships with everyone involved. This is key – know who all your stakeholders are, engage with them often, build strong rapport with primary stakeholders and keep communicating. You will build trust this way and it will make your work easy, rewarding and best of all you will deliver high quality output.