In this five-part series, I will be providing guidance on how to write an effective User Requirement Specification. I will try and pull ideas and information from a number of different sources. For example, I have recently asked people through LinkedIn to provide examples. I would like people to comment on the blog post with their own ideas and own suggestions so that it is a collaborative effort and a living blog.
To start the process off I would like to suggest that people who are writing User Requirements Specifications consider the following points:
- The user requirement contents should be as complete and correct as you can make them. If you are unsure of the quality or accuracy of information, it may be best to just leave it out.
- It is important to number each of your Titles and each of your statements. This makes it much easier for control system suppliers to reference individual requirements. They may need to do this because of customer requests to indicate compliance with requirements or alternatively for traceability reasons. The control system suppliers may wish to trace the requirements through design, execution and testing as a means of ensuring they deliver the correct functionality.
- It is important to avoid the words similar to ‘may’ and ‘could’. These usually result in a phone call from the control system supplier asking if it is to be included in the project scope. Please ensure that the URS is concise.
- Create a consolidated list of document holds (maybe in a table at the front of the document) and explain to the control system supplier how you would like them to handle the holds. For example, do you want them to be included as an option?
- Consider indicating which requirements are a must have and which requirements are a nice to have. The nice to have requirements can then be priced as an option.
- Please use revision control on your document (even if it is just an issue date). It also helps if you indicate in a summary at the front of the document what has changed between revisions. Use track changes between revisions that are issued to control system suppliers for their consideration.
- When writing a requirement in the URS it is a good idea to think about how it may be tested.
- Where topics follow a particular theme, group them under the same heading. If necessary, consider using techniques such as affinity mapping to understand the groupings.
- Consider including a list of people who may be contacted with queries and their contact information.
- Feel free to describe the expected benefits of each requirement.
- Do not limit yourself to control system requirements only. It is often worth considering other requirements such as maintenance and operations.
- List what you feel are the project risks.
- Include information on any other parallel projects which you are (the end user) running and how many people you expect to be involved in the project. This will help the control system supply, when scheduling, not to overload you.
Remember the aim of a URS is to specify ‘what’ without going into ‘why’ and an ambiguous URS is worse than an incomplete URS.
Stay tuned for part 2 and good luck with writing your own URS documents. Please feel free to comment on this blog post with your own experiences and suggestions.
From Jim: You can connect and interact with other project execution professionals in the Plan & Design and Implement & Build groups in the Emerson Exchange 365 community.
