Technology Projects: Defining Business Requirements

Don McIntyre, Digital Consultant for Chess, reviews the process of using Microsoft 365 for a recent technology project in a blog series. In this first part, he covers:

• Jump to Digital Transformation Common Challenges >
• Jump to Deploying Microsoft 365 in a Further Education Establishment >
• Jump to The Process of Using Microsoft 365 >
• Jump to Introduction to Defining Business Requirements >
• Jump to Practical Tips to Define Business Requirements >
• Jump to Book Your Free Consultation >
• Jump to Glossary of Terms >

.

Digital Transformation Common Challenges

As a digital consultant, I often work with a range of companies and organisations that would consider themselves creative. I regularly engage with businesses and departments aware of the benefits of adopting Microsoft SharePoint but have developed understandable transformation paralysis.

There seem to be several reasons for this:

• Not knowing where to start
• Lack of awareness of the features and benefits available within the Microsoft environment
• Uncertainty in terms of which of the Microsoft tools to learn and deploy first
• Not knowing how various to use Microsoft products together
• Uncertainty around how to engage and educate colleagues
• Lack of knowledge regarding maintenance of operational activities following the transition

It occurred to me that these challenges are common in various organisations I have worked with across many sectors, including Engineering, Academia, Local Government and Healthcare.

Our Approach to Change Management

Ensure adoption and ROI in your organisation

Read Blog

Deploying Microsoft 365 in a Further Education Establishment

Recently, I have been working with the the Innovation department of a prominent design school to develop their website. At the same time, there was a requirement to compile an asset library, mostly imagery generated by the school, to be used across the website and other offline and online media. Despite being a globally recognised organisation and having technically astute graduates who go on to work for the likes of Google and Facebook, the school did not utilise Microsoft 365 fully. So we were presented with an opportunity to address some of the issues preventing more widespread use of the solutions in the organisation through a live, meaningful project.

The Process of Using Microsoft 365

I've created a blog series documenting the process of using Microsoft 365 to plan and support a website and asset repository development. In each instance, I liaise with Microsoft specialists at Chess to provide insight and knowledge around best practices.

We'll cover:

• Establishing business requirements and capturing these in a backlog using Microsoft 365
• Evaluating the available Microsoft 365 estate, including licence types and the products available within each, including Business Basic, Standard and Premium
• Identifying which tools within Microsoft 365 are the most appropriate for the project
• Educating colleagues about the purpose, scope and limitations of each tool
• Using Planner to manage progress and allocate tasks
• Using SharePoint to store and categorise imagery
• Developing and sharing best practices
• Ensuring security and privacy of data

We'll look at how best to begin defining requirements in the form of both business requirements - why are we doing this - and functional requirements - what does the product or service need to do to meet the needs of the business. These aspects form part of a more extensive process we use at Chess outlined by Karl Wiegers in his seminal book 'Software Requirements, versions and evolutions of which are used by many software development companies including Microsoft.

"At the start of the project, we knew what we wanted to achieve, but we didn’t quite know how to frame our requirement. Chess guided us through every step of the journey, gave us confidence and demonstrated value. There’s no reason for us to look anywhere else for an IT partner.”

- Robin Birrell, Data and Systems Manager, Scotwork

Introduction to Defining Business Requirements

Why are we doing this anyway?
The business requirements effectively explain 'why' the project is taking place and what it needs to achieve.

Using an example from a recent project for a healthcare organisation that Chess delivered:

• Reduce waiting lists by 15% through a digital 'front door', which allows citizens to self-serve.

Alternatively, in the context of the Innovation School website, the key business requirements would be:

• Save staff time by creating a repository of imagery that, through the tagging, allows for media to be quickly viewed and retrieved.
• To increase applications to undergraduate courses in the next academic year.
• To increase the number of relevant organisations who contact the Innovation School to establish partnerships.

You would write the business requirements in a document that outlines the vision and scope of the project. However, depending on the project size, these could be agreed between key stakeholders in email format. Regardless, it is helpful to state and circulate critical elements at this stage in the project. For example, at Chess, we use the following checklist when working on client software development:

• Business Requirements
• Background
• Business Opportunity
• Business Objectives
• Success Metrics
• Vision Statement
• Business Risks
• Business Assumptions and Dependencies
• Scope and Limitations
• Major Features
• Scope of initial release
• Scope of subsequent releases
• Limitations and exclusions
• Business Context
• Stakeholder profiles
• Project Priorities
• Deployment Considerations

It's rare that there will be the need to define all these elements, and some of them will already be known quantities. The checklist above is particularly relevant when working on client-related activities where the project, content and objectives may be unknown to the development team.

Practical Tips to Define Business Requirements

Try to avoid confusing Business Requirements and Functional Requirements. It's easily done in the same way that it's sometimes easier to imagine how technology can be used rather than consider 'what problem do I need to solve'. Focus on the 'why,' i.e., why are we undertaking this project? What are the (quantifiable) goals the organisation expects to be able to achieve?

Determine who the project stakeholders are and the needs of each group. There are often more than you initially think. For example, in the case of the Innovation School, in addition to the obvious prospective students, there are also staff members, schools, potential partners and, very importantly, the parents of potential and existing students. Each of these groups will have different goals and levels of digital literacy.

When defining all requirements (business, user and functional) it can be helpful to think in terms of the flow - a (user) needs to (action) so that (outcome). In the example of the school this might translate as: a high school student considering further education options needs to find out more about courses available so that they can evaluate whether, when comparing with other institutions, they may want to apply.

In the next article, Defining User Requirements, we'll look at ways of eliciting user needs, including those 'hidden' aspects that only become apparent when the first prototype is made available (we've all been there!), and how these can be most effectively documented.

We can help you on your journey and advise on the best approach for your organisation. Contact our expert team and book your FREE technology consultation today.

Glossary of Terms

You may come across the following terms in this series:

• Business Requirement: A high-level business objective of an NHS Trust e.g., a 25% reduction in waiting lists.
• Business Rule: A policy, guideline, standard or regulation that defines or constrains some aspect of the Trust, e.g. NHS England Identity Guidelines.
• Constraint: A restriction that is imposed on the choices available to Chess for the design and construction of the web services e.g., an agreed hosting environment, such as Azure.
• External Interface Requirement: A description of a connection between the software systems and a user, another software system (such as System One EHR), or a hardware device.
• Feature: One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements.
• Functional Requirement: A description of a system's behaviour under different conditions.
• Non-functional Requirement: A description of a property or characteristic that a system must exhibit. This could relate to the speed with which a page has to load or the need to comply with accessibility standards such as WCAG2.1
• Quality Attribute: A non-functional requirement that describes a service or performance characteristic of a product.
• System Requirement: A top-level requirement for all the web services. Very relevant in this instance if the various Trust websites are being hosted in a single environment.
• User Requirement: A goal or task that specific classes of users must be able to perform using the website and associated services. This can also refer to a desired attribute.