How to Correctly Gather User Requirements for IT Project Success

There are many phases in a computerised system project and all are important, but none more so than gathering User Requirements.

There is an old saying that “you can’t test quality into a system” but by the same token, you cannot test functionality into a system either.

That is, if the real requirements (actual needs) have not been properly defined, understood, designed and developed, it doesn’t matter how few bugs the system contains, it will not do what is expected of it.

There are many reasons why user requirements are not properly developed including:

• Lack of skill /experience in gathering requirements
• Lack of time given to gather requirements
• Lack of interest or commitment by key stakeholders to give accurate requirements
• Lack of skill / experience in documenting requirements
• Lack of knowledge of what is a requirement versus a capability
• Lack of understanding between a requirement (what) and a design element (how)

The statistics for IT project delivery failure are high, and it would seem apparent that there is a direct relationship between project failure and incomplete/inaccurate requirements.

The disappointing thing is that many projects continue to run even if they have more chance of failure than success.  This is because most people don’t know the difference between a well written and badly written requirements document.

This paper has been written to give some guidance to both gathering requirements and what a good requirements document should contain.  Every project is slightly different, so it is sometimes a grey area as to what is a ‘requirement’ and what is a ‘design element’, but by asking the right questions to the right people (and that is the key) it should become evident where the boundary is for that project.

Remember that requirements cover more than just the obvious functional requirements.  Consider IT, Management, Quality Assurance, interface and support requirements amongst others.

Gathering Requirements

There are several ways to gather requirements (and the aim of the project should assist with which way is best for your project).

If you are simply replacing a current process (automated or not) with a computerised system then gathering all information about the current process is required.

This may include:

• Gathering all forms and SOPs currently used and reviewing these
• Talking to key users and stakeholders using the current process
• Witnessing the current process being performed

If the new process is a major change to a current process or a brand new process, then the above won’t exist and discussing the new process in detail is required.  Note that even when replacing an existing process, discussing new and better ways of performing certain actions is also required.

Just asking and documenting what users say they require can be a dangerous way of gathering requirements.  Users often give ‘wants’ (rather than ‘needs’) that may dictate the design before all the real needs have been discussed.

For example, a user may want ‘an Excel spreadsheet to add multiple numbers, perform a complex calculation and display the result’.  What the user really needs is a secure way of entering numbers, validating the numbers are within limits, performing the respective calculation, saving the result with a timestamp, and displaying the secure result for use.  It may not necessarily need Excel or even a spreadsheet, but if it was written as such, it may dictate the way the design is developed.

Each requirement should be unique, provable/testable and traceable.

Some Good and Bad Examples

As you can see, it is important to listen to the full needs from users and to document them in such a way that the full intent is described but the method of delivery is as open as possible (to allow for all delivery options to be considered).

If the company has already purchased a product to use, then those restrictions should be entered as requirements.  If no such restrictions exist, then it is important not to impose additional restrictions.

Requirements discussion and approval is an iterative exercise, but it is important not to let this spiral out of control.  Completion dates for requirements and approval must be defined to avoid the exercise drifting on for an extended period of time.

Major projects with many requirements can take several weeks to define, but generally requirements gathering should not take more than a couple of weeks; assuming that the key stakeholders are available for discussions and can make decisions in a timely manner.  It is up to the project manager to ensure this.

Common Mistakes / Things to Avoid

Who Should Write the User Requirements Specification?

It is preferable to have someone who can construct well written and easy to read sentences, as a poorly written document has less chance of being well reviewed.  If you are spending your time correcting spelling and grammar issues, then you are less focussed on the actual content.

However, more important than who writes the document is who has input and reviews / approves the requirements.

Documenting Requirements

There are a couple of common ways of documenting requirements:

1. Simple statements that describe the process in some detail
2. Numbered rows of single requirements, optionally specifying whether the requirement is mandatory or optional

A better way is to use a combination of both methods above with a preamble to each section in the requirements document describing the background and overview, and rows of requirements to be used as the actual traceable requirements.

If well written, this will lead to a better chance of transitioning successfully to the next phase of the project.

How to Document Requirements

There are many ways to collect the requirements, but the best way I have found is to perform and in-depth interview. Ask many questions (as many as you can) and then document both what you hear and what you think would be a good idea for the system in question (the latter part of this does rely on some experience and skills from previous projects).

Even if you have not discovered what a user wants in a particular function (or whether the function is required at all), document it with an action to make the user respond.

Send as much information as you have back to the user for update.  If additional requirements are wrong or not required, the user will tend to respond with the correct requirements – and you have documented more detail than you would have by not putting anything down originally.

By continuing this approach, with every iteration you will gather as many requirements as you can in the time provided.

Remember that requirements are never truly complete (as the system will continue to adapt with enhancements when it eventually goes live) but they should be as accurate as possible at the time of approval.

What a Good User Requirements Specification Looks Like

There is no single format for a good requirements document, but consider the following sections:

• Purpose - why is this document being created
• Associated documents – related documents
• Standards and Guidelines – that this complies with
• Definitions – for terms used within this document
• Executive Summary – very important for background to the project and to ease into the requirements
• Objectives – bullet points of the main expected outcomes
• System Overview – high level system process diagrams and description
• Functional requirements – break each individual process into as small a section as required and describe that sub-process in detail. Try to order the processes as much as possible (although some processes happen in parallel and some are not sequence-related to others).
• Data requirements – any requirements that are specific to or related to the actual data (e.g. database, data import)
• Environmental requirements – specific to the hardware or physical constraints
• Interface requirements – if interfaces to other systems are required
• Constraints – any additional constraints not described in other sections
• Implementation requirements – training, support, warranty, development, etc.
• Validation requirements – audit log, testing, requirements

Reviewing and Approving the User Requirements Specification

Much time and effort can be expended in developing a requirements document, but this can all be wasted if the appropriate people do not make the effort to ensure that the details recorded are accurate, unambiguous and complete.

Simply emailing or physically passing a document to someone to review is often not enough.  Even if there is time to properly review the details, often people simply glance over a document and approve it.

Having enforced walkthroughs (dedicating meetings between the key stakeholders to read each requirement and discuss it in detail) will enforce a more thorough review process and give a greater chance of success to the project.

Conclusion

There is no guarantee to a successful project, but a good requirements specification gets the project off on a solid foundation and support effective IT project management.

Projects can still be successful without detailed requirements, but will rely on other factors such as experienced project members who are very familiar with the expected outcomes for success.

For most projects (where there are a number of experienced and inexperienced team members, and new processes or technologies), having a well written and reviewed requirements document that has been conveyed to all team members, so they understand the intent, is the best way to launch a project and to give it the best chance to succeed.

Contact us to explore how you can leverage SeerPharma's expert IT Project Management services to help deliver your IT project successfully.