image for Writing System Requirements for your Web or Mobile

Writing System Requirements for your Web or Mobile

Published on Monday, 13th March 2017, contributed by Wyamee

Tutorial: Writing System Requirements

At Wyamee we work with clients to build web and mobile apps.  One of the most critical parts of the process is writing system requirements.

We decided to write this article as a tool for any visitors to our website who might be thinking about building a web or mobile application. This guide is designed for any size web or mobile project you’re thinking about starting. The system requirements will become more critical based on the size and scale of the project. Bigger projects have more variables and considerations to map out.

In the world of software, writing system requirements will fall into two types of project approaches; agile or fixed waterfall. However the thing that doesn’t change is the work breakdown structure (WBS), which will help you map out the complete detailed requirements.

Will the software agency write your system requirements, so you don’t need to bother?

Unless you can delegate writing the system requirements to someone else you trust, this will have to be you. A good software agency will write their interpretation of the requirements into their own software specification. However, the initial requirements will need to come from you first. In this type of scenario, you will be the subject matter expert. We need you to explain what you want the software product to do, to reduce any assumptions we might make.

Within this process, you will become known as the product owner.

Finally make sure your requirements are in a structured format, because it will save you money, by cutting down on time and reducing any project variations that might arise later down the line.

I’m in a rush and don’t have time to write system requirements

Please stop!  You have to make time to write them, because without it you could jeopardise your whole project.  We don’t want you to end up with the following outcomes:

  • Unexpected costs and results
  • Poor end product
  • Increased project variations
  • Loose and unmeasurable system objectives

We want to help you avoid making these costly mistakes, because we know how much money goes into building web and mobile apps. If you don’t give this part of the process enough time then you could face bigger challenges further down the line. Remember that software development isn’t wizardry, it’s simply down to a clear understanding and partnership between the client and agency.

A* Star Requirements

If you’ve read all the way down to this section then it’s time to tackle what a good set of requirements looks like.

There are lots of great blogs out there talking about this subject, so be sure to check them out as well as ours.

Wyamee is accredited with the Project Management Institute (PMI), so we tend to align our own processes to the international standards laid out by the PMBOK guide in the PMP.

Part 1 – How do you capture client requirements?

Ideally the software agency you work with should help facilitate the collection of requirements using the following methods:

  • Interviews. You and your team will be treated as subject matter experts, to articulate what the product should be and why this is important.
  • Facilitated Workshops. This is usually delivered by an experienced facilitator and all key client personnel will need to attend the session.
  • Focus Groups. The objective to try and determine the requirements, needs and expectations for the project and its outcome.
  • Group decision-making techniques – the purpose of trying to encourage the whole group to participate and make decisions.
  • Questionnaires and surveys. For large teams of stakeholders that might be dispersed across different locations.
  • Group Creativity. This can be brainstorming, mind-mapping, nominal group technique using votes and priorities and the Delphi technique.
  • Observation. This is running job observations to capture how a process is performed, to potentially identify real data.
  • Prototypes. We’re a really big fan of prototypes because it helps express the requirements into a visual mock-up

Part 2 – Writing requirements?

After collecting all the requirements, the agency is going to have a lot of data that needs to be translated into software requirements. This section explains how to write good requirements and to show you what goes into them.   The key headings you should aim to answer are as follows:

1. Project Description

The project description helps explain what the project is, and how it will be accomplished.  You ultimately want to try and explain the ultimate intended outcome of the project.

Furthermore this should serve as a brief introduction.  Use this opportunity to provide some background about the history of how the project arrived at this point.

2. Project Purpose

The project purpose is to state the purpose of the project and tie the purpose to your company’s strategic goals and objectives. From an outsider, you need to be able to tell the reader why this project is being started and what need it is fulfilling. Finally you need to identify if there are any specific mandates, policies or laws that are driving this change.

3. Business Case

You need to provide information on how the project is going to benefit your business, because it needs to add value. Discuss the alternatives that were considered, if any, and provide information on how the organisation came to the selected approach.

4. Business Requirements

Identify the high-level business requirements that the project is going to fulfil. Remember that this is not a detailed list of system requirements.

5. Assumptions

At the beginning of a project you will need to consider what the different parts of the measures and deliverables will be in relation to assumptions.  When developing the new software system that is going to take three years to fully complete.

6. Constraints

A constraint can be a hard deadline or completion date, but other constraints could also be resources, tools or hardware.

These constraints ensure that if the project has no budget for additional servers, the project must find a way to develop the new system using the hardware already in place.

Please bear in mind this could mean juggling servers to fit specific development environment needs while ensuring that the production environment stays up.

7. Risks

This section requires you to state the known risks.

At this stage your risks of the project will be quite high level because you won’t know much about the details of the project. When you perform your cost-benefit analysis, make sure you list the risks you’ve identified as part of that process in this section. If the project is going to span five years and touch multiple third party systems, then integration and technology change would be risks to consider here.

8. Project Deliverables

You need to document what the project deliverables will be on completion of your project. This helps all the people involved have an objective measure of whether they’ve made the system how you envisaged it to look.

9. Project Milestones

Identifying the project milestones is important for everyone involved, so people can plan other activities around them such as marketing, sales and PR if it’s going to be a product launch.

10. Project Manager

You need to identify the project manager to ensure they have the authority to complete the project.  Explain as clearly as possible, the roles and responsibilities of the project manager so there are no grey areas.  Ultimately it’s important to state the project manager’s levels of authority with respect to resource allocation, schedule modifications and purchasing authority.  This part is often overlooked, or approached during an informal conversation, yet it can cause bottle necks during the project life cycle.

11. Project Role and Responsibilities

Define the other key roles and responsibilities within the project team.  If the project team has functional team leads, document them here.

12. Project Life Cycle Methodology and Tools

Identify what project management methodology the project will be using, for example Agile or Waterfall.

In many instances, organisations have their own proprietary version of a waterfall-type life cycle, so that could help the process.

Note: Click here if you would like to download our Project Charter Template

Finally, remember that the project charter should be seen as tool to capture the initial high-level requirements.

Part 3 – Requirements Breakdown

In part 2 we talked about the project charter, which is the high-level overview of the project and only defines the high-level requirements.  Once this part of the project has been signed off, it’s time to really get stuck into the technical part of the requirements.  Your key objective in this next part is to breakdown the high-level requirements into detailed requirements.  It’s a time consuming process, but something you should really try to enjoy.  Finally try and remember it helps articulate your vision of the product into a comprehensive set of definitions for the web or mobile app.

Work Breakdown Structure (WBS)

Give me the details!  The work breakdown structure is a term referred to in project management for the process of building detailed requirements.

The WBS aims to address the following requirements of the project:

  • Defines the project scope in terms of deliverables and components
  • Provides the framework that the project status and progress reports are based.
  • Facilitates communication regarding the project scope, schedule, risk, performance, cost etc with your stakeholders throughout the project lifecycle.
  • Provides inputs into other parts of the project such as estimation, scheduling, risk assessment.

In summary the WBS can sound quite complex, but when you dig a bit deeper with our guide, hopefully you see it’s just a useful structure.

WBS Levels

This maps out all the work that needs to be done and is categorised into hierarchical levels.  The upper levels show the major deliverables for the project.  The lower levels identify the more granular activities that need to be implemented to help achieve the deliverable.  The number and complexity of the WBS levels is down to the size of your project.  As a result each component of the WBS will have a unique identifier because you might need to enhance it further down the line.

WBS Dictionary

The WBS dictionary provides detailed information about the work to be done:

  • Activities
  • Cost estimates
  • Milestones
  • Resources
  • Contract information for each element of the WBS

As a result this part is to try and remove any ambiguity regarding your scope.

Visualisation 

In addition to the hierarchical structure for the WBS that you’ve seen above,  you can also visualise the WBS in a tabular view, or outline view.

Click here to download our tabular view template

Hopefully these templates will help you in your projects.

WBS Element

Each component of the WBS and its attributes comprise of a WBS element, because it provides more detailed information.  As a result these are really important, because they will inform everyone the expected requirements.

Work Package

The lowest level WBS component for each branch is known as the work package.  Therefore the work package includes the schedule activities and milestones to be achieved in order to complete the work package deliverable.  Some of the pitfalls we’ve found are that if the work package is too big then it can subsequently mean the control of the activities are too loose.

Similarly if the work package is too small it would require too much management.  In practice PMBOK inform that a work package should be no less than eight hours and no greater than 80 hours.

In conclusion you need to find a fine balance between these extremes.