Posts Tagged ‘requirements’

Requirements Gathering – Finding What User Wants

Tuesday, June 2nd, 2009

Often in big blue sky projects there is no brief. The end users see an opportunity or have a problem and require a solution.

When there is no brief requirement gathering is a real skill and can involve the following tools:

Questionnaires

This is a quick method to get a wide range of responses from a large number of people. There are lots of online tools that will collate the answers for you. However this method is not widely used as it is subject to question bias and most people will not fill it in with enough care.

Interviews

One on one interviews with key users and stakeholders is an excellent way to find out what users really want. Face to face the interviewer (if they are experienced) can really hone in and find out what the key motivations are.

Observing

Watching people in their operational environment can be a good way to identify requirements, Ideo have made this technique famous as a route for innovation. This only works if you are trying to improve a product and not if the product is entirely new.

Focus Groups

Getting different groups of people together and asking them what they want and then really listening to what they say can be very productive in getting to the real requirements. It requires great skill for the facilitator to keep the conversations on topic.

Requirements Testing

Remember that once you have formulated your requirements they should go through thourough testing and review. Once they have been agreed by the sponsor they should be baselined and subject to change control to stop scope creep.

Requirements – What Users Want

Monday, April 20th, 2009

The first step in any project is finding out what the users actually want.

Requirements management is the process of documenting, testing and analysing the statement of stakeholder wants and needs.
Requirements are the statement of need that a project has to satisfy, theystate the problem to be solved and define the scope of the solution.

However users are not always able to communicate what they want clearly, and the key is to gather the requirements while allowing flexibility for the chosen solution.

Requirements gathering is a creative process and involves careful listening, brainstorming and elicitation. A good requirement is:

  • Clearly defined
  • Testable
  • Agreed by all stakeholders

There are two types of requirements:

Functional Requirements

These are the statement of capabilities, they express what the intended product must do in terms of behaviour. They are binary in nature, they are either present or absent.

Non Functional Requirements

These are the quality attributes of the functional attributes, they are often called soft requirements. They include things such as speed, efficiency and longevity. They should still be testable and clearly defined. A product may fulfill its use but still not be usable to clients, so non functional requirements address this space.

Tomorrow I will be looking at the process of good requirements gathering.