Considerations for Your User Requirement Specification

by | Sep 25, 2015 | Capital Projects, Services, Consulting & Training | 0 comments

Emerson's Scott Turner

Author: Scott Turner

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.

User-Requirement-SpecTo start the process off I would like to suggest that people who are writing User Requirements Specifications consider the following points:

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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.
  7. When writing a requirement in the URS it is a good idea to think about how it may be tested.
  8. 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.
  9. Consider including a list of people who may be contacted with queries and their contact information.
  10. Feel free to describe the expected benefits of each requirement.
  11. Do not limit yourself to control system requirements only. It is often worth considering other requirements such as maintenance and operations.
  12. List what you feel are the project risks.
  13. 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.

Popular Posts



Related Posts

Follow Us

We invite you to follow us on Facebook, LinkedIn, Twitter and YouTube to stay up to date on the latest news, events and innovations that will help you face and solve your toughest challenges.

Do you want to reuse or translate content?

Just post a link to the entry and send us a quick note so we can share your work. Thank you very much.

Our Global Community

Emerson Exchange 365

The opinions expressed here are the personal opinions of the authors. Content published here is not read or approved by Emerson before it is posted and does not necessarily represent the views and opinions of Emerson.

PHP Code Snippets Powered By :