Ask any group of software developers their pet peeve, and you can guarantee the topic of poorly written user requirements specifications will make an appearance. After all, no one wants to begin aproject unsure of exactly what the client is looking for. Athoughtful and well-written user requirements specification saves time and money, and ensures everyone is singing from the same hymnsheet.
To put it plainly: the better the user requirements specification, the better the outcome. This is athought well worth keeping in mind as you embark on yourproject.
What is auser requirements specification (URS)?
In software engineering or systems design, aURS is aplanning document that specifies what the software or system needs to do. It is written from the point of view of the end user and does not need to be technical or complicated. According to Intersys MD Matthew Geyman, “A well-written URS is clear, unambiguous, well explained and concise. It helps the systems designer or software engineer fully understand aclient’s needs, and can be used to plan atimetable, estimate costs and soon.”
It’s amantra that we follow rigorously when embarking on our numerous software development projects such as our proprietary supply chain risk software for complex, multi-stage supply chains,SCAIR®.
Note: this is aseparate document to the functional or software specification. These are documents produced by the software developer that specify how the requirements in the URS will bemet.
Why it’s important to get itright
A poorly-written URS with vague requirements and ambiguous language can lead to confusion between the client and the provider. In some cases it leads to the need for extensive reworking, which in turn can lead to blown budgets and broken deadlines. “A detailed and explicit spec reduces unknowns and produces tighter quotes, as well as better outcomes,” saysMatthew.
When creating aURS, there are two things to consider: what to include in the document and how to writeit.
What toinclude
The exact information that needs to be included will vary from project to project. Evidently, acomplex project will have more requirements than asimple one. However, there are some fundamental principles and important features that amount to good practice for most projects, regardless ofsize.
Authors
It is agood idea to begin with alist of the people responsible for creating the user requirements specification. This should include the name, job title, date and signature of everyone who co-authored it. Having all responsible stakeholders ‘sign off’ on the URS ensures that all those involved are clear that the document has beenapproved.
Introduction
This can be brief. The most important things to include are who you are and why the need for this URS has arisen. It might be helpful to give avery brief background of the company. For example, [Company Name] is astart-up organisation based in the south west of England. We wish to develop asoftware app that helps hikers and walkers find trails and pathways in their local area. This user requirements specification (URS) documents the user requirements for the development of theapp.
Objective
A good objective clearly describes the goal of the project in non-technical terms.
This should give abrief overview of the project, in non-technical terms. It should be written in anarrative or descriptive style (ie not achecklist or abbreviated language), and outline what the product is intended to do. To assist with writing this section, ask the following questions:
- What am Itrying toachieve?
- What problems will this productsolve?
- How will it streamline or improve the existing system, or similar product in the marketplace (if oneexists)?
In the case of the hiking app example above, it might be something like this: “Our goal is to create an app for both iOS and Android phones that guides walkers and hikers to trails in their immediate vicinity. The app should allow users to create profiles, upload photos, design trails and write reviews. Existing hiking apps often include information that is out of date and/or unverified. By allowing users to update trail information, they will collectively have more reliable data with respect to the condition of agiven trail at any giventime.”
Requirements
This is the most important part of the URS. Take each requirement one at atime, ensuring that it is precisely described. Remember, you should write this in narrative form, focusing on what the product should do, rather than how it should do it. Continuing with the hiking app example, arequirement might be: “I’d like the Welcome screen to include alink to the user’s profile, as well as links to completed trails and suggested trails.”
It is good practice to number each requirement and also to indicate whether it is high, medium or lowpriority.
Think about:
- The impactexpected
- What you want to happen at eachpoint
- What different users would expect to see. For example, ‘As an admin, Iwould expect to see …’ or ‘As an end user of the app, Iwould expect tosee…’
Supporting documents
For some projects, supporting documentation may be appropriate. This mayinclude:
- Images, sketches or mock-ups of concepts central to the project, such as userinterfaces
- Examples of software and systems that already fulfil some of the requirements you’d like incorporated
- A site map (for awebsite)
- End-user personas
Glossary
If your document uses technical or non-technical jargon, abbreviations or acronyms, make sure to explain them clearlyhere.
Index
If your document is particularly long, consider including an index at theend.
How to writeit
The above section outlines what you should include in your document. What follows are some notes on describing your requirements clearly. Don’t see these as ‘style points’ or ‘the icing on the cake’. Ambiguity is the enemy of project success and expressing yourself precisely is vital: your developer will thank you for communicating in an unambiguous way and you’re likely to be far happier with the end resultstoo.
1. Use SMARTtargets
- Specific
- Measurable
- Achievable
- Realistic
- Time-bound
SMART targets provide agood way to ensure your user requirements specification is well-defined andverifiable.
Specific: Your requirements should be clear and specific. For example, rather than drafting avague requirement such as ‘improve ad latency’, think ‘reduce ad latency by50%’.
Measurable: To be measurable, arequirement must state something that can be confirmed by examination, test, or demonstration. Avoid subjective statements such as ‘easy’ or ‘faster’. If it can’t be measured, there’s no way for both parties to agree that the requirement has beenmet.
Achievable: Your objective needs to technically feasible. If you’re not sure whether something is technically possible, further research is needed. If you’re still not certain, word what you want as a ‘goal’ rather than as a ‘requirement’.
Realistic: Even if something is technically achievable, it may not be realistic due to budget constraints, time restrictions, regulatory requirements or other limitations. It’s important to be realistic when determining your requirements.
Time-bound: What is the time-frame for theproject?
2. Avoidambiguity
A user requirements specification should be clearly written, using simple sentences, and without ambiguity. Examples of ambiguous wordsare:
- improve
- fast
- slow
- user-friendly
- easy
- sufficient
What exactly is meant by user-friendly or sufficient? These terms are subjective and therefore impossible tomeasure.
Similarly, avoid acronyms, abbreviations and jargon as they may lead toconfusion.
3. Take one requirement at atime
This makes it easier for everyone to see how each requirement has been developed andtested.
4. Prioritise
Think carefully about word choice. Words such as ‘shall’ and ‘will’ typically define requirements. They imply that the requirement must be met. Words like ‘may’ and ‘could’ define goals that are desirable but not necessarily required. Do not confuse these terms, and make sure you use them consistently in yourdocument.
Following these general guidelines will help ensure that your brief is clear and concise. We will follow up this post with afull user requirement specification template, which you can use when working with Intersys or any other software developer.
Intersys designs bespoke software for awide range of sectors including life sciences, legal, education, renewables, TV and media, and manymore.
Find out more about our software development services or get in touch now to start aconversation.
Find out more about our software development services
