Block 2 - Unit 2: Establishing an initial set of requirements Flashcards Preview

M364 Revision > Block 2 - Unit 2: Establishing an initial set of requirements > Flashcards

Flashcards in Block 2 - Unit 2: Establishing an initial set of requirements Deck (145)
Loading flashcards...

What are we trying to achieve in the requirements activity? (2)

Identify needs:
Understand as much as possible about users, their work, and the context of that work, so the system under development can support them in achieving goals.

Establish requirements:
Produce, from needs identified, a set of stable requirements than form a sound basis to move forward into thinking about design.


Importance of getting the requirements right.

Cost of fixing errors late in the software development cycle is significantly higher than during the requirements activity.


Requirements gathering / capture?

Implies requirements exist out there and we just need to get hold of them.


Requirements elicitation?

Implies 'others' know the requirements and they just need to tell us.
Even if they 'have' them, they may not have articulated them yet, or have explored them in enough detail.


Requirements analysis?

Investigate and analyse an initial set of requirements that have been gathered, elicited or captured.

Important step, as interpretation of facts (rather than facts themselves) inspires the design.


Requirements engineering?

Recognises that developing a set of requirements is an iterative process of evolution and negotiation, and needs to be carefully managed and controlled.


'Establishing' requirements?

Choosen to represent the fact that requirements arise from data gathering, analysis and interpretation activities and have been established from a sound understanding of the users' needs.

Also implies requirements can be justified by, and related back to, the data collected.


An aim of the requirements activity.

To make requirements as specific, unambiguous and as clear as possible.


Functional requirements?

Say what the system should do.

Fundamental to understand these for an interactive product.


Non-functional requirements?

Describe the various constraints there are on the product.

Can be technical (eg. needs to interface with another system);
or non-technical (eg. needs to support a particular type of user).


Examples of non-functional requirements. (4)

Must be able to run on a variety of platforms.

Target platform is expected to have at least 1 GB of RAM.

Must be delivered in 6 months time (constraint of development activity rather than product).

Interactive products in general - physical size, weight, colour and production feasibility.


Data requirements? (6)



Size / amount.





Environment requirements?

Context of use - circumstances in which interactive product is expected to operate. (4 aspects)


4 aspects of environmental requirements.

1. Physical environment.
Lighting, noise, dust, etc., protective clothing worn?, crowded.

2. Social environment.
Collaboration / coordination.
Eg. data shared? Synchronously or asynchronously?
Physical location of other team members.

3. Organisational environment.
Eg. how good is user support? Facilities / resources for training? How efficient / stable is communication structure?

4. Technical environment.
Eg. What technologies will the product run on or need to be compatible with?
What technological limitations might be relevant?


User characteristics?

Capture the key attributes of the intended user group - the properties of the users that impact on ID.


Some key user characterisitics.

Abilities and skills:
Novice - step-by-step instructions, prompting, constrained interaction.
Expert - flexible interaction with more wide-ranging powers of control.

Nationality, education, preferences, personal circumstances, physical or mental disabilities.


User profile.

The collection of attributes of a class of 'typical user'.

One product may have several different user profiles.



Rich description of typical users of the product under development that designers can focus on and design for.

Precise, credible details helps see personas as real potential users, and hence as people they can design for.


Details included in a persona?

Unique set of goals (inc UX).

Skills, attitudes, tasks and environment (detailed and specific).

Name, photo, personal details (leisure activities etc).



Prioritisation - 'Must have'; 'Should have'; 'Could have'; and 'Won't have right now'.


4 issues for success of data gathering / recording sessions.

Setting goals.

Relationships between collector and provider (of data).


Pilot studies.


Main reason for gathering data?

Glean information about something.

Eg. understand how technology fits into family life;
identify which icon best represents 'send email'.


Why set goals for data gathering?

Many reasons for gathering data - need to identify specific goals.

Goals will influence the nature of sessions, gathering techniques and the analysis to be performed.

Once goals set, you can concentrate on what data to look for and what to do with it then.


Purpose of informed consent forms.

Gatherer - wants to know data can be used in analysis, presented to interested parties and be published in reports.

Provider - knows information will not be used for other purposes, or in a context that would be detrimental.
Children (parent signs) - no threatening / inappropriate / embarrassing questions.


Triangulation (def, example and reason)

Strategy of using more than one data gathering technique to tackle a goal, or using more than one data analysis approach on the same set of data.

Eg. observation to understand context of task performance, interviews to target specific user groups, questionnaires to reach a wider population, and focus groups to build a concensus view.

Provides different perspectives and corroboration of findings across techniques, therefore leading to more rigorous and defensible findings.


Pilot studies.

Small trial run of main study to make sure method is viable.

Data gathering participants are usually unpredictable, even with careful planning.

Potential problems can be identified and rectified.
Eg. equipement, instructions, questions.


Comments on pilot studies. (2)

Can use colleagues / peers for pilot study if difficult to find participants - quick and cheap.

Anyone involved in the pilot study can't be involved in the main study - they will know more about it, which can distort the results.


Most common data recording methods. (4)

Taking notes.





Other data recording methods.

Questionnaires and diary notes 'self-documenting' (participant completes so no further recording needed).

Interaction logs usually generated automatically.


Factors affecting choice of data recording method.

Context, time available and sensitivity of situation - choice impacts on how intrusive data gathering is.

Most settings - audio, photos and notes sufficient.

Sometimes video is essential to record in detail intricacies of the activity and its context.