Is there a generally accepted template for user requirements on a UX design project?

Question

In one of my projects, user surveys are about to complete and my next tasks are creating the personas and generating the user requirements document. Since this is one of my first UX projects, my proposal took a very by-the-book approach based mostly on A Project Guide to UX Design. That book mentions user requirements but doesn't really elaborate on how they should look.

In my former career in software development, I dealt with requirements that were written out very formally in CMMI style ("The system shall...") and with less formal, wiki-style functional technical specifications on agile projects. I'm wondering how to approach user requirements in this UX redesign project.

This client is an informal group, so I don't want to overwhelm them with information to the point where they will not read it.

So, several questions:

1. What categories of information do I need to spell out in a UX user requirements document? (Are any redesign-specific?)

2. If user surveys are calling for a feature that was not agreed on in the proposal, how should the user requirements address this?

3. Is there a free template for a UX user requirements document online?

4. Is there a book that spells out how to do user requirements? (I'd very much prefer an online template; it's free, and I can start the document sooner.)

Answer 1

Mike Cohn published in his blog a good article, arguing to use User Stories for Requirements. Because

• User stories emphasize verbal communication [between devs and customer]
• They can be used readily in project planning. [...] use cases, on the other hand, are generally too large to be given useful estimates.
• User stories encourage the team to defer collecting details.

• And they emphasise humans and their needs and motivation instead of "the system"

A User Story is written in this format (Question 3):

As a -type of user-, I want -some goal- so that -some reason-.

In his article are two examples of "traditional" use cases. The second is describing a interface or interaction requirement. This way I learnt to write requirements compliant to ISO standards. He also mentions the IEEE 830 specification "The system shall..." but showing its drawbacks.

This type of thinking reinforces the belief that software is complete when it fulfills a list of requirements, rather than when it fulfills the goals of the intended user

At the end of the article you will find some references for deeper reading. (Question 4)

.

I think you will have some non-functional requirements like "it should be easy to use" or "the interface should react fast".

• As a user, I want the site to be available 99.999% of the time I try to access it so that I don’t get frustrated and find another site to use.
• As someone who speaks a Latin-based language, I might want to run your software someday.

Mike covers this topic in an article about Non-functional Requirement as User Stories. I recommend reading the comments as well, as they discuss how to implement it correctly in Agile projects.

Question 2: I would put the extra needs of users (your so called features) put into an extra chapter im the format of User Story as well. Give some hints, how urgent they are if available. May be you can give decision support for a re-priorisation of all User Stories by percentage of user asked for it or measured score of desire.