Week 3 - Requirements

Question 1

Requirement

Answer 1

A statement about what the system should do and characteristics the system should have.

Question 2

Importance of requirements

Answer 2

Important in analysis and design stage of system development lifecycle.
Guide development of the system in the right direction.
Incomplete requirements was the most common reason for project failure (E. Hull, K. Jackson and Jeremy Dick (2011) Requirements Engineering, Springer).

Question 3

Good requirements

Answer 3

A good requirement is clear, can be expressed in natural language and is measurable/testable.
Should be complete (include descriptions of all requirements) and consistent (no conflicts or contradictions) although this can be hard in practice.

Question 4

Reasons for incomplete requirements

Answer 4

Can be difficult to anticipate everything for large problems.
Different users have different requirements/priorities leading to a compromise being made.
Wicked problems.

Question 5

Wicked problems

Answer 5

Problems which are very complex and challenging to understand.
Leads to requirements often being incomplete and inconsistent.

Question 6

Types of requirements

Answer 6

• Business requirements (overall goals of the project)
• User requirements (defined by the user)
• Functional requirements (what software should do)
• Non-functional requirements (characteristics the system should have)
• System requirements (how the system should be built)

Question 7

Functional vs non-functional requirements

Answer 7

Functional requirements are what the system must do and how the system will be implemented.
Non-functional requirements are the qualities or characteristics that the system must have and the way the functionality operates.
Both are equally as important.

Question 8

Categorising non-functional requirements

Answer 8

Quality requirements: maintainability, reliability, performance, usability of the system.
Process requirements: how the software development process is going to be carried out.

Question 9

Requirements engineering

Answer 9

Establishing user requirements - designing the right thing.
Getting things right from the start, rather than fixing things later.

Question 10

Stages of requirement engineering

Answer 10

Requirement elicitation (gathering).
Requirement analysis.
Requirement documentation.
Requirement verification and validation.

Question 11

Requirement elicitation (gathering)

Answer 11

Understanding users’ needs, constraints and any processes that need to be followed.
Understanding problem to be solved, organisation needs and specific features/functionality required by stakeholders.
Understand users attitudes (what people think), emotions (how people feel), values (what is considered important) and behaviours (what people do)

Question 12

Methods for requirement elicitation (gathering)

Answer 12

• Questionnaires: asking people for their responses to questions.
  + Scalable, quantitative, insight to attitudes.
  − little insight into “why”, less useful for exploratory/open-ended situations, less insight into emotions and behaviours.
• Interviews: semi-structured one on one questions.
  + Flexible, in-depth, insight into reasons for attitudes.
  − Time consuming, not scalable, social behaviour factor (answer they think you want rather than real answer).
• Observations: observing what people do e.g., how people use a current system before it is updated.
  + Insight into behaviours, contextual insights (seeing activity where it would actually happen).
  − Time consuming, not easy - needs practice, challenging in non-work settings, people may not behave naturally when observed.
• Think aloud technique: users talk through what they are doing as they are doing it.
  + insight into reasons behind actions, can provide more information than just watching someone.
  − Cognitively demanding for participants, not all processes have rationale, narrating can make processes less natural.
• Focus groups/workshops: similar to interviews but with more people.
  + insights from multiple people at once, insight into group norms, generate rich discussion/ debates.
  − Social desirability factor (people go for common opinion rather than their own), difficult to manage/ facilitate.

Question 13

Requirements analysis

Answer 13

Checking over gathered requirements, check for any conflicts/contradictions. Check for missing requirements.

Question 14

Requirements documentation

Answer 14

Must express and document requirements in a structured way.
Must be understandable to users.
Usually are numbered/ranked by importance.
Usually categorised into functional and non-functional.
Often accompanied by use cases, process models and data models.

Question 15

Requirement verification and validation

Answer 15

Checking requirements with users and stakeholders and detecting any differences in understanding and interpretation before the requirements are used to develop the system.
Verifying: is this correct? Are we building the system right?
Validating: is that what the users want? Are we building the right system?

Question 16

Requirements challenges

Answer 16

Can be hard to find what users really want - users don’t know/ struggle to articulate it, users do not understand technical constraints, difficulties in communication between users and designers (background, knowledge, vocab, goals).
Conflicts in stakeholder needs.