Unit 3 - 3. Simple use case models Flashcards

(14 cards)

1
Q

use case

A

The purpose of the use case is to describe a goal and have all the necessary steps to achieve it.

A description, of a piece of functionality that a system performs to yield an observable result of some value to an actor.

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

use case diagram

A

A diagram that shows a set of use cases and actors and their associations.

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

assosiations

A

The relationships between actors and use cases represented by a line.

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

system boundary

A

A conceptual division between the system to be studied and ‘everything else’.

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

Name two aspects of software development where use case modeling can help.

A
  1. Eliciting requirements
  2. Representing requirements.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Suggest a reason why use case diagrams are an aid to communication between user and developer.

A

Use cases offer users an opportunity to understand the system since the use case notation is relatively simple and doesn’t require an understanding of UML.

This provides a mechanism that enables developer and client to share a common understanding of the system.

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

scenario

A

Illustrates one particular way the use case can unfold, by describing the sequence of interactions the actors have with the system.

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

How do use cases help with requirements capture?

A

Use cases help with requirements capture through the identification of actors and tasks in the system.

For each actor, a set of use cases describes what that actor requires from the software system.

Use cases can help with the communication of requirements between the software developers and the customer.

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

How do use cases help the elicitation of detailed software requirements

A

Detailed software requirements can be associated with each step in a use case scenario. There may be more than one requirement for each step.

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

How do use cases help with the elicitation of detailed software requirements?

A

Detailed software requirements can be associated with each step in a use case scenario. There may be more than one requirement for each step.

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

How do use cases help with development?

A

The use case descriptions help the developer to:

  • understand the complexity of each use case
  • determine which actors interact with each use case and to what extent
  • establish which use cases carry the most risk
  • estimate how long each use case is likely to take to implement.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

How do use cases help with the system’s architecture?

A

Use cases can be grouped in terms of similar functionality, therefore potentially influencing the architecture of the system.

Scenarios can be used to check how an architecture meets non-functional requirements, in particular those that can be affected by the architecture, such as security and safety requirements.

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

How do use cases help with system validation?

A

One way to validate a system is to use the walk-through technique, checking the functionality related to each use case in turn.

The walk-through technique can also be used to create tests where each use case is required to deal with a number of scenarios – a process known as verification.

For each software requirement generated from a step of a scenario, the fit criterion helps to devise the test.

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

How would you write uses cases for agile development?

A

Write use cases as needed instead of writing all use cases upfront.

Write just enough content rather than complete descriptions.

Write use cases that are useful for communication, not heavy ones that are difficult to understand and change.

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