Lecture 7: Scrum, Domain Analysis, Requirements Analysis Flashcards

1
Q

What are the different scrum roles?

A

Product owner
Scrum Master
Development Team

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

What are the traits of a product owner?

A

Defines the features of the product
Decides on release date and content
Prioritizes features
Adjusts features and priority every iteration, as needed
Accepts or rejects work results

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

What are the traits of a scrum master?

A

Represents management to the project
Responsible for ensuring adherence to scrum practices
Removes impediments
Ensures that the team is fully functional
Shields team from external interference

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

What are the traits of the development team?

A

Members are assumed cross-functional
Only title for member is “developer”
No sub-teams
Optimal size is 3-9 members

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

What is a sprint?

A

“Heart” of scrum
Usually one month or less, consistent development throughout
“Done”, usable product increment is created
New sprint starts immediately after previous ends
Quality attributes don’t change
Scope can be clarified/re-negotiated

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

What is a sprint planning meeting?

A

Work to be performed in upcoming sprint is planned
Suggested meeting length is 8 hours for a one month sprint
What will be delivered and how will the work get done?

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

What are deliverables?

A

Product owner presents a list of items to complete, team develops a sprint goal, considering the backlog, capacity, and past performance

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

What is in the sprint backlog?

A

Selected product backlog items
Estimated time to complete each item
Assigned tasks to individual members

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

What is the goal of a daily scrum meeting?

A

15 minutes to synchronize and plan for the next 24 hours
Same time, same place
Questions: What was accomplished, what will be done before next meeting, and what obstacles are in the way?

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

What is the goal of the sprint review meeting?

A

Present accomplishments
Form of a demo of new features or progress
Informal, entire team participation

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

What is the sprint retrospective?

A

Opportunity to reflect and plan for improvements during the next sprint

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

What is a project charter?

A

Problem statement
Project objectives
Stakeholders
Deliverables

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

What is a product backlog?

A

Ordered list of everything that might be needed in the product (source of requirements)
Product owner is responsible for the backlog
Never complete
Lists all features, function, requirements, enhancements, fixes
Format: As a, I want, so that” (called user stories)

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

What is a burn down chart?

A

Graphical representation of work left to do vs. time left in which to do it

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

What are some scrum criticisms?

A

Assumes you can estimate task duration
A lot of meetings
Difficult to collaborate with outside groups
Assumes development will be ongoing

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

What do the terms “Greenfield” and “Brownfield” mean?

A

Greenfield: From scratch
Brownfield: Must work with existing systems

17
Q

What is design?

A

Deciding how the requirements should be implemented using available technology

18
Q

What is domain analysis?

A

Process by which a software engineer learns about the domain (general field of business or technology in which the software will be used) to better understand the problem
Benefits: Faster development, better system, easier to anticipate future modifications

19
Q

What are the different types of requirements?

A

Real: functional and performance
Constraints: non-functional (all software must be in C)
Possible: non-measurable, subjective (look good)
Probably not: Expectations, wishes, desires

20
Q

How do you gather requirements?

A

Observation: Read documents and discuss requirements with users, shadow potential users
Interviewing: Ask about specific details, stakeholder’s vision, etc.
Prototype: Draw pictures and show them to users, develop a mock-up UI

21
Q

How do you explore the requirements?

A

Need to determine what the system is compared to the world
Can change: System
Can influence: Boundary
Can’t change: World

22
Q

What are user stories?

A

Short, simple descriptions of a feature told from the perspective of the person who wants the feature, usually a user or a customer
“As a “type of user”, I want “some goal”

23
Q

Why are user stories helpful?

A

Help define the scope of the system, help plan, form basis for test cases

24
Q

What is a use case?

A

A typical sequence of actions that a user performs to complete a given task
Cover the full sequence of steps from beginning to end
Describe the user’s interaction with the system
As independent from UI design as possible

25
Q

What do use case diagrams look like?

A

Use case: horizontal ellipse
Actor: Stick figure, person, organization or external system
Associations: Lines, connect actors and use cases

26
Q

What are use case extensions?

A

Make optional interactions explicit
Handle exceptional cases
Think “hardware interrupt”

27
Q

What are use case generalizations?

A

Represent several similar use cases
One or more specializations provides details of the similar use cases
Ex: Manage Personal Account and Manage Business Account inherit behavior from Manage Account but add specific steps

28
Q

What are use case inclusions?

A

Allow one to express commonality between several use cases
Included in other use cases
Represents the performing of a lower-level task with a lower-level goal

29
Q

What is the purpose of exploring requirements?

A

Reduce the uncertainty about what was needed and not requested and what was asked for and not needed

30
Q

What are the steps to managing requirements?

A

Review them
Track them
Verify them
Control the changes to them

31
Q

What are the considerations when reviewing requirements?

A

Benefits that outweigh the costs
Important
Unambiguous
Consistent, etc.