L6 User Requirement Gathering

Question 1

Why is identifying system requirements considered the hardest part of software engineering?

Answer 1

Because it defines exactly what to build, and mistakes here severely affect the entire system. It’s also the most difficult to correct later.

Question 2

What quote from Fred Brooks supports this idea?

Answer 2

“No other part of the conceptual work is as difficult as establishing the detailed technical requirements… No other part so cripples the system if done wrong.”

Question 3

Why is usability engineering considered central to requirements engineering?

Answer 3

Because usability directly affects whether the system helps users achieve their goals effectively, making it integral to requirements.

Question 4

How does this relate to the concept of ‘fit’ in UCD?

Answer 4

A system must ‘fit’ with user contexts, goals, and constraints to be truly usable—not just functionally correct.

Question 5

Define the difference between functional and non-functional requirements.

Answer 5

Functional: What the system must do. Non-functional: How the system performs.

Question 6

What question can you ask to distinguish if a requirement is functional?

Answer 6

“Is this something the system needs to do?”

Question 7

What question reveals a non-functional requirement?

Answer 7

“Is this about how the system performs or is experienced?”

Question 8

Give two examples of non-functional usability requirements.

Answer 8

“The app must be intuitive to new users.” / “Tasks should be completed in under 3 clicks.”

Question 9

What does ISO 13407 say about user and organisational requirements?

Answer 9

They must identify relevant users, set goals, priorities, measurable criteria, and be documented.

Question 10

How do user requirements and usability requirements relate?

Answer 10

User requirements define needs; usability requirements ensure the system is easy/effective to use.

Question 11

Why shouldn’t requirements be fixed too early in design?

Answer 11

Because they evolve with understanding, and fixing them too early limits user-focused solutions.

Question 12

What are the risks of treating requirements as ‘given’?

Answer 12

They may be incorrect or biased, leading to flawed designs.

Question 13

How can stakeholder conflict affect requirement gathering?

Answer 13

Conflicting priorities or needs may require balancing and negotiation.

Question 14

Why does Henry Ford’s ‘faster horses’ quote apply to UCD?

Answer 14

Users might ask for old solutions, unaware of better alternatives.

Question 15

How should a good design process treat evolving requirements?

Answer 15

Iteratively: refining through feedback and improved understanding.

Question 16

What does ‘just enough detail’ mean in a good requirement?

Answer 16

Detailed enough to guide design, not overly rigid.

Question 17

List 5 things you should discover about a user’s context of use.

Answer 17

Who, when, where, what tools, and information needs.

Question 18

What are environmental requirements?

Answer 18

Conditions like noise, lighting, or social factors that influence use.

Question 19

What are usability-related physical/cognitive needs?

Answer 19

Needs that ensure mental and physical comfort while using the system.

Question 20

How can you capture a user’s real motivations if they don’t state them clearly?

Answer 20

By observing behaviour, asking ‘why’, and identifying patterns.

Question 21

Why is the evaluation of early mock-ups valuable?

Answer 21

To validate requirements before investing in full development.

Question 22

What is a persona and what makes it effective?

Answer 22

A fictional user archetype, effective when based on real data.

Question 23

List 4 optional traits that can be included in detailed personas.

Answer 23

Education, salary, technical comfort, and social habits.

Question 24

Why are personas useful in UCD?

Answer 24

They help teams empathise and design with real users in mind.

Question 25

What are guerrilla personas?

Answer 25

Quick, low-resource personas for time/budget-limited projects.

Question 26

What are three common issues with personas?

Answer 26

Too abstract, potentially misleading, or lack empathy.

Question 27

What’s the role of a scenario in relation to a persona?

Answer 27

Describes context of product use by that persona.

Question 28

Give an example of a simple scenario.

Answer 28

“Lisa checks her camera feed after receiving a motion alert abroad.”

Question 29

What is the structure of a good user story?

Answer 29

“As a [persona], I want [action], so that [goal].”

Question 30

How do user stories directly lead to system requirements?

Answer 30

They clarify goals that inform required features and qualities.

Question 31

How are user stories linked to agile development?

Answer 31

They help prioritise tasks that deliver user value.

Question 32

What requirements would emerge from: 'As a parent, I want alerts when my kids unlock the front door'?

Answer 32

Functional: alerts, child profiles; Non-functional: speed, reliability.

Question 33

Why must requirements be clearly and unambiguously defined?

Answer 33

So they can be implemented and tested consistently.

Question 34

What’s the value of defining requirements as ‘measurable’ early on?

Answer 34

It enables testing success during evaluation.

Question 35

What usability qualities should be engineered into the system? Name 4.

Answer 35

Efficiency, intuitiveness, low workload, satisfaction.

Question 36

How does the star lifecycle model support flexible requirement development?

Answer 36

It encourages iteration and evaluation at all stages.

Question 37

What are the four key quadrants of the empathy map, and what do they capture?

Answer 37

Says, Thinks, Does, Feels – user input and emotions.

Question 38

Why is it important to map user Pains and Gains explicitly?

Answer 38

To understand what frustrates or motivates the user.

Question 39

How might an empathy map improve the quality of your personas?

Answer 39

By grounding them in real emotional/behavioural data.

Question 40

According to this diagram, what’s the starting point of requirement identification?

Answer 40

Engaging directly with users through observation and interaction.

Question 41

What’s the difference between identifying and gathering requirements?

Answer 41

Identifying is discovering needs; gathering is documenting them.

Question 42

Why is iterative feedback important in the process?

Answer 42

Because needs evolve, and requirements must adapt over time.

Question 43

What does the star lifecycle tell us about the design process?

Answer 43

It’s non-linear and centred around constant evaluation.

Question 44

Why does this model emphasise iteration between any two activities?

Answer 44

To support evolving insights throughout the process.

Question 45

How does the model support both Agile and UCD approaches?

Answer 45

By promoting user feedback and flexible iteration.

Question 46

Where does “Specify user and organisational requirements” fit in this diagram?

Answer 46

After defining context of use, before design solutions.

Question 47

What does the cycle say about evaluating against requirements?

Answer 47

Designs must be tested against original user needs.

Question 48

Why is this process circular?

Answer 48

Because human-centred design is iterative and never final.

Question 49

What are the benefits of following the ISO 13407 model?

Answer 49

Ensures usability is built-in and continuously validated.