Design UX- Understanding Requirement
Understanding Requirement
Requirement is something the product must do or a quality that the product must have.
There has always been much debate about which of the following terms should be used for the requirements activity:
- Requirements gathering: suggests requirements are lying around waiting to be picked up with little interaction between designer and stakeholders.
- Requirements generation: suggests a more creative activity that tends to de-emphasize links to current practice.
- Elicitation requirements: suggests some interaction between stakeholders and designers.
- Requirements engineering: often used in software engineering projects, usually a very formal approach.
Being developers also need a clear requirements specification at some point in the development process so that they can cost the project and manage it successfully. Requirements specifications increasingly include prototypes, screen shots and other media. When written they should be expressed in clear, unambiguous language, and worded so that it will be possible to test whether the requirement has been met in the final system. Requirements are divided into two types, functional and non-functional. Functional requirements are what the system must do. Non-functional requirements are a quality that the system must have: they concern the way the functionality operates.
Prioritizing Requirement
These classify the requirements into:
- Must have – fundamental requirements without which the system will be unworkable and useless, effectively the minimum usable subset.
- Should have – would be essential if more time was available, but the system will be useful and usable without them.
- Could have – of lesser importance, therefore can more easily be left out of the current development.
- Want to have but won’t have this time round – can wait till a later development.
Participative Design
As a designer must involve various techniques to understand and analyze the needs, goals, and aspirations of the user. The designer must understand the user desires by interviewing and then finding out what the user really needs.
Interviews
One way to find out what the user wants is by interview. The structured interview uses questions that are developed beforehand. With the interview, all user requirements will be fulfilled.
Stories, Scenarios and Early Prototyping in Interviewing
Scenarios and stories are helpful aids to understanding activities and help avoid having people imagine (or reconstruct) situations in the abstract. Prototypes anything from paper sketches to semi-functioning products are very often used to embody scenarios in possible technology. Whether or not a prototype is used, the analyst and the customer ‘walk through’ the scenario, while the analyst probes for comments, problems, possible alternatives, and suggestions in general.
Practical Consideration Interviewing
- Preparation: Get to know the background.
- Keeping track of the interview:
- Telling stories
- Reflection and exploration
- General-purpose exploratory questions
- When to stop
