Week 1 Flashcards

1
Q

What is a requirement?

A

A statement expressing a need (capability) and its associated constraints
and conditions

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

What is the goal of a requirement specification?

A

Enable an agreed understanding between stakeholders

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

Requirements document
Attributes

A
  • Collection of requirements
    For each requirement:
  • Identification
  • Dependencies
  • Source(s)
  • Rationale- reasoning
  • Priorities (MoSCoW – Must have, Should have, Could have, Won’t have)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Steps for requirements specification

A
  1. Identify actors and their goals
  2. Specify inputs, outputs of the system
  3. Write requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Steps for requirements specification given informal text

A
  1. Identify the system
  2. Identify actors and their goals
  3. Specify inputs, outputs of the system
  4. Go through text sentence by sentence, try if sentence gives rise to one or more requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Requirement Engineering

A

Process of getting from user needs to requirement specification is called requirement engineering:
1. Requirement elication
2. Requirement specification
3. Requirement verification and validation
4. Requirement management

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

Requirement elication

A

3.2.1 Requirement elication (requirement gathering)
- Interviewing
- Brainstorming
- observing
- Task analysis
- Scenario-based analysis
- Prototyping
- use case analysis

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

Requirement specification

A

Requirement specification
once requirements are understood the problem can be described

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

Requirement verification and validation

A

Requirements validation: focuses on ensuring that the software correctly implements a specific function.

Requirements verification: ensures that the requirements specification itself satisfies its quality criteria.

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

Requirements management

A

Requirements are hardly ever stable, and a good requirements management process allows for changes in the requirements during the process.

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

”The electric car drives using only electric power but carries a generator on
board that burns regular fuel. When the battery level drops below 15%,
the generator is started automatically. The generator cannot be started if
the fuel tank is empty.”

Actors?
Inputs?
Outputs?
R1?

A

Actors: controller, generator, fuel sensor, battery level indicator

Inputs: fuel level, battery level; outputs: start generator signal, out of fuel

R1: When the battery level indicator shows the battery level is below 15% and the fuel level is greater than 0, the controller should set the start generator signal within x seconds

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

What are good requirements?

A
  • Necessary
  • Appropriate
  • Unambiguous
  • Consistent
  • Complete
  • Singular
  • Feasible
  • Verifiable
  • Correct
  • Conforming

NASVUFCCCC

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

Semi-formal requirements – ISO29148

A

[Condition][Subject][Action][Object][Constraint of Action]

  • [Condition] when is the requirement applicable
  • [Subject] actor, e.g., “the application”, “the system”, “the librarian”
  • [Action] action or verb of requirement, e.g. “shall return to”, “shall send”
  • [Object] of the action, e.g., “message”, “book”, a particular state
  • [Constraint of Action] restriction on the action, e.g., time limit
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

“When signal x is received, the system shall set signal x received bit
within 2 seconds.

Identify the [Condition][Subject][Action][Object][Constraint of Action]

A

When signal x is received [Condition], the system [Subject] shall set
[Action] signal x received bit [Object] within 2 seconds [Constraint of
Action]

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

Use cases

A

Use case
* Fundamental concept of many object-oriented development methods

Use case diagram
* Expresses expectations of customers/stakeholders
* Essential for detailed design
* Used during entire analysis and design process
* Can be used to answer:
* What is being described? (The system.)
* Who interacts with the system? (The actors.)
* What can the actors do? (The use cases.)

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

Use Case

A
  • Describes functionality expected from system under development
  • Provides benefit for one or more actors that communicate with use case
  • Derived from collected customer/stakeholder wishes
  • Set of all use cases describes functionality system shall provide
  • Documents the functionality that a system offers.
17
Q

Actors

A
  • Interact with the system …
  • by using use cases,
    i.e., the actors initiate the execution of use cases
  • by being used by use cases
    i.e., the actors provide functionality for the execution of use cases
  • Represent roles that users adopt
  • Specific users can adopt and set aside multiple roles simultaneously
  • Are not part of the system
    i.e., they are outside of the system boundaries
18
Q

Type of Actors

A
  • Human: Student, Professor,…
  • Non-human: E-Mail Server,…
  • Primary: has main benefit of execution of use case
  • Secondary: receives no direct benefit
  • Active: initiates the execution of use case
  • Passive: provides functionality for execution of the use case
19
Q

Detailed description of Use Cases

A

Structured approach
* Name
* Short description
* Precondition: prerequisite for successful execution
* Postcondition: system state after successful execution
* Error situations: errors relevant to the problem domain
* System state on the occurrence of an error
* Actors that communicate with the use case
* Trigger: events which initiate/start the use case
* Standard process: individual steps to be taken
* Alternative processes: deviations from the standard process

NSPPESATSA

20
Q

Relationships between Use Cases and Actors

A
  • Actors are connected with use cases via solid lines (associations)
  • Every actor must communicate (be associated) with at least one use
    case
  • An association is always binary
  • Multiplicities may be specified
21
Q

«include»

A

1

22
Q

«extend»

A

1

23
Q

Relationships between Use Cases

A

1

24
Q

Relationships between Actors

A

1

25
Q

Best Practices: Identifying Actors

A

Ask (and answer):
* Who uses the main use cases?
* Who needs support for their daily work?
* Who is responsible for system administration?
* What are the external devices/(software) systems with which the
system must communicate?
* Who is interested in the results of the system?

26
Q

Best Practices: Identifying Use Cases

A

Ask (and answer):
* What are the main tasks that an actor must perform?
* Does an actor want to query or modify information in the system?
* Does an actor want to inform the system about changes in other systems?
* Should an actor be informed about unexpected events within the system?

27
Q

Example: Vending machine

After client interview, the following scenarios were identified:
* A customer buys a product
* The supplier restocks the machine
* The supplier collects money from the machine; this happens during
restocking

A

Actors:
* Customer
* Supplier
* Collector (in this case, Collector = Supplier)

Use cases:
* Buy product
* Restock machine
* Collect money

28
Q

«Include» common mistakes

A

1

29
Q

«Extend» common mistakes

A

1

30
Q

Typical errors to avoid

A

1

31
Q

Requirements DON’Ts

A
  • Superlatives: such as best, most.
  • Subjective language: user friendly, easy to use, cost effective.
  • Vague pronouns: it, this, that.
  • Ambiguous adverbs and adjectives: almost always, significant, minimal.
  • Open-ended, non-verifiable terms: provide support, but not limited to, as a minimum.
  • Comparative phrases: better than, higher quality
  • Loopholes: if possible, as appropriate, as applicable.
  • Negative statements
  • Passive voice: shall be able