Class 1 - Requirements Flashcards

1
Q

Requirement

A

A specific description of your client’s needs

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What are the 5 different requirement activities that happen when creating a product for a client?

A
  • Eliciting
  • Expressing
  • Prioritizing
  • Analyzing
  • Managing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Want

A

A functionality or feature that a client would like the product to have, which may add value, but is not necessarily core to the product itself

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Need

A

A core functionality that the product must have in order to fulfill the product’s purpose

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Eliciting Requirements

A

The process of determining what a client needs and wants. It is an in-depth discussion and collaboration between client(s) and the development team

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Expressing Requirements

A

Framing the requirements identified through discussion in a way that allows a product to be built. This is where use cases, user stories, and story maps are created

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Use Cases

A

A usage scenario for a piece of software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

User Story

A

Written description of what a user wants to achieve with a system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Prioritizing Requirements

A

Prioritizing client needs to ensure the most important needs will be completed. MoSCoW is often used to prioritize requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

MoSCoW

A

Must Have
Should Have
Could Have
Would like but won’t get

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Analyzing Requirements

A

Weighing what is possible given scope, schedule, and budget

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What are the most important types of requirements?

A
  • User requirements
  • Functional requirements
  • Non-functional requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

User Requirements

A
  • Use cases
  • User stories
  • Story maps
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Non-functional Requirements

A

Quality Requirements. Examples include:
- Accuracy
- Dependability
- Security
- Usability
- Efficiency
- Performance
- Maintainability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Product Vision

A

The purpose and value of a product to the client. Includes the needs a project solves.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

True or False: Changes to a project can change the product vision

A

False. A project should never move away from the client’s vision. However, it is possible that a project may not fulfill the entire vision (only part of it)

17
Q

Scope

A

What a project can realistically achieve

18
Q

User Story Format

A

As a who, I want to what, so that why.

E.g. As a customer, I want to be able to identify dietary restrictions, so that I know I can eat the food I order

19
Q

Scope Creep

A

Happens when the scope of a project grows as the result of an increase or change in requirements

20
Q

How can you determine if a user story is good?

A

Recall INVEST. User stories should be:
- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable

21
Q

Independent (INVEST)

A

A requirement can exist outside of other user stories and still be meaningful

22
Q

Negotiable (INVEST)

A

User stories should be general enough for the development team and client to work around their implementation. They should not focus on specific technical details

23
Q

Valuable (INVEST)

A

User stories should bring value to the client

24
Q

Estimatable (INVEST)

A

It should be possible to estimate how much time it would take to design and implement the requirement in the user story

25
Q

Small (INVEST)

A

A user story should be small because it is meant to be developed in a short time period

26
Q

Testable (INVEST)

A

User stories should be verifiable against a set of criteria in order to determine if it is done. This is often accomplished using acceptance tests

27
Q

Epic User Story

A

User stories with descriptions that are too vague or broad. These user stories can be difficult to estimate

28
Q

Cone of uncertainty

A

The time estimates to develop a user story become less accurate the further into the future the feature is intended to be developed

29
Q

How can epic user stories be avoided?

A

Provide just enough information to implement a feature, but not the implementation details

30
Q

Acceptance Tests

A

Basic criteria to determine if a user story is fully implemented. Written from the client’s point of view

31
Q

Agile Flying Fingers

A

An exercise used in project planning to determine how many story points to assign to a user story. Each team member holds up the number of fingers corresponding to the number of story points they think a user story should have

32
Q

Story Points

A

How long it will take to finish a piece of work in relation to other pieces of work.

33
Q

True or False: Story points can be represented by number of hours to complete a task

A

False. Story points are how long a task will take relative to other tasks. They estimate effort rather than time commitment.

34
Q

Product Backlog

A

A set or list of software features that the software product manager and development team plan to develop for a product over the course of a project

35
Q

Wireframes (Mock-ups)

A

A basic visual representation of a product that shows where buttons, text fields, and images are placed. UI design and colour palettes are not part of a wireframe