Human-Computer Interaction
In the realm of Human-Computer Interaction, requirements play a crucial role in shaping successful design projects. Discover the significance of requirements, types of requirements, and the process of gathering and defining them. Gain insights into functional and non-functional requirements in software engineering to enhance your understanding of this critical aspect of user-centered design.
Uploaded on Feb 18, 2025 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Human Computer Interaction
Requirements 1. Introduction 2.What are Requirements Activity? 3.What are Requirements? 4.Kinds of Requirements 5. Data Gathering for Requirements
Introduction An interaction design project may aim to replace or update an established system, or it may aim to develop a totally innovative product with no obvious precedent. There may be an initial set of requirements, or the project may have to begin by producing a set of requirements from scratch. Whatever the initial situation and whatever the aim of the project, the users needs, requirements, aspirations, and expectations have to be discussed, refined, clarified, and probably re-scoped. This requires an understanding of: the users and their capabilities, their current tasks and goals, the conditions under which the product will be used, and constraints on the product's performance.
What are We Trying to Achieve in the Requirements Activity? There are two aims: One aim is to understand as much as possible about the users, their activities, and the context of that activity, so the system under development can support them in achieving their goals. Second aim is to produce a set of stable requirements that form a sound basis to start designing.
What are Requirements? A requirement is a statement about an intended product that specifies what it should do or how it should perform. One of the aims of the requirements activity is to make the requirements as specific, unambiguous, and clear as possible. For example: a requirement for a smartwatch GPS app might be that the time to load a map is less than half a second. Another, less precise, example might be that teenagers should find the smartwatch appealing. In the case of this latter example, further investigation would be necessary to explore exactly what teenagers would find appealing.
Different Kinds of Requirements In software engineering, two different kinds of requirements have traditionally been identified: * functional requirements, which say what the system should do * non-functional requirements, which say what constraints there are on the system and its development. For example1: A functional requirement for a new video game may be that it should be challenging for a range of user abilities. For example 2: A functional requirement for There are a lot of software requirements specifications included in the functional requirements of the Hospital Management System, which contains various process, namely Registration, Check out, Report Generation, and Database. Non-functional requirements : A lot of software requirements specifications included in the non-functional requirements of the Hospital Management System, which contains various process, namely Security, Performance, Maintainability, and Reliability.
Data Gathering for Requirements The overall purpose of data gathering in the requirements activity is to collect sufficient, relevant, and appropriate data so that a set of stable requirements can be produced. Even if a set of initial requirements exists, data gathering will be required to expand, clarify, and confirm those initial requirements. Data gathering needs to cover a wide spectrum of issues: 1. The tasks that users currently perform and their associated goals, 2. The context in which the tasks are performed, 3. The rationale for the current situation. There are different techniques for gathering data, which include: interviews, focus group, questionnaire, observation(direct and indirect), studying documentation and researching similar products.
1. Interviews are good for exploring issues, and semi-structured or unstructured interviews are often used early on to elicit scenarios. In the context of establishing requirements, it is equally important for development team members to meet stakeholders and for users to feel involved. This on its own may be sufficient motivation to arrange interviews. Interviews 2. Focus groups. Focus groups are good for gaining a consensus view and highlighting areas of conflict and disagreement during the requirements activity. On a social level it also helps for stakeholders to meet designers and each other, and to express their views in public. It is not uncommon for one set of stakeholders to be unaware that their understanding of an issue or a process is different from another's, even though they are in the same organization. The generic idea of a focus group has been tailored for use within the requirements activity and requirements workshops have grown in popularity. Each workshop is carefully planned, attendees are carefully chosen, and specific deliverables are produced.
3. Questionnaires. Questionnaires may be used for getting initial responses that can then be analysed to choose people to interview or to get a wider perspective on particular issues that have arisen elsewhere. For example: A questionnaire might be used in order to gauge whether a new university online help service would be welcomed by students. This questionnaire could ask for impressions and opinions about current support services and whether the respondent is prepared to be interviewed further. The questionnaire might be used to get opinions and views about specific suggestions for the kind of help that would be most appreciated.
4. Direct observation. In the requirements activity, observation of participants in their natural setting is used to understand the nature of the tasks and the context in which they are performed. Sometimes the observation is carried out by trained observers who record their findings and report them back to the design team, and sometimes the observation is carried out by or with a member of the design team. 5. Indirect observation. Diaries and interaction logging are used less often within the requirements activity where a new product is under development. However, if a product is being developed iteratively or is evolving from an existing product, indirect observation and experience sampling are very valuable. Interaction logging together with sophisticated web analytics are particularly useful for improving websites.
6. Studying documentation. Manuals and other documentation are a good source of data about the steps involved in an activity and any regulations governing a task. Documentation should not be used as the only source, however, as everyday practices may augment it. Taking a user-centred view of development means being interested in everyday practices rather than an idealized account. Studying documentation is good for understanding legislation and getting some background information on the work. It also doesn't involve stakeholder time, which is a limiting factor on the other techniques.
7. Researching similar products. One reason for looking at similar products is to generate alternative designs. Another reason to look at similar products is to help prompt requirements. The choice of data gathering techniques for the requirements activity is influenced by several factors including: 1. The nature of the task, 2. The participants, 3. The analyst 4. The resources available. It is usual for more than one data gathering technique to be used in order to provide different perspectives. For example: Observation to understand the context of task performance, interviews to target specific user groups, questionnaires to reach a wider population, and focus groups to build a consensus view.
H.W Q1) What are the requirements and what is the aims of the requirements activity? Q2) Why we used the questionnaire to gather data? Q3) Compare between functional and non-functional requirements and Give an example of the two cases. Q4) Why do we need to look for similar products when gathering data?
