Lecture_07 Flashcards

Requirements Scenarios & Templates

1
Q

What are the main ways to capture/document requirements?

A

1) Natural language:
-User stories
-Traditional SRS (Software Requirements Specifications) form.
-Templates
-Structured text
2) Using models

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

What are scenarios in requirements engineering?

A

They describe interactions between users and the system considering: Time, Ordering, and pre- and post conditions.
Can be represented as text or models
Examples: Use Case templates (text) and Customer Journey maps (models)

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

Why are scenarios important?

A

1) Help identify missing requirements
2) Provide a different view of the system
3) Consider the temporal flow of interactions

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

What are the key methods for representing scenarios?

A
  • Text: Use Case Templates (e.g., Cockburn’s Use Case Template)
  • Models: Customer Journey Maps
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are the key elements of Cockburn’s Use Case Template (Part 1)?

A

Use Case: Number and name
Goal in Context: Longer statement of the goal
Scope: System under design
Level: Summary, Primary task, Subfunction
Preconditions: Required initial state
Success End Condition: Desired outcome
Failed End Condition: What happens if it fails
Primary Actor: Who initiates
Trigger: What starts the use case

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

What are the key elements of Cockburn’s Use Case Template (Part 2)?

A
  • Main Success Scenario: Step-by-step flow from trigger to goal
    -Extensions: Alternative flows for specific steps
    -Sub-variations: Variations in the scenario
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What are the key elements of Cockburn’s Use Case Template (Part 3)?

A
  • Priority: Importance of the use case
    -Performance Target: Expected execution time
    -Frequency: How often it occurs
    -Superordinate Use Case: Related higher-level use case
    -Subordinate Use Cases: Linked sub-use cases
    -Channel to Primary/Secondary Actors: How actors interact with the system
    -Open Issues: Outstanding questions
    -Schedule: Timeline for implementation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What is an example of a use case using Cockburn’s template?

A

Use Case: #2 Pay for Bike
Goal in Context: To give payment to rent a bike
Scope: Bike rental system
Preconditions: User selected bike, logged in if registered
Success End Condition: Payment successful
Failed End Condition: Payment failed or aborted
Primary Actor: User (bike renter)
Trigger: User tries to rent a bike

Main Success Scenario:
1) User is prompted to pay
2) User confirms amount
3) User selects payment method
4) User completes payment
5) System confirms payment

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

What are some structured requirements templates?

A
  • Volere Template
  • List of attributes from IEEE
  • Cockburn’s Use Case Template
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What is the Volere Template used for?

A

-Structured form for capturing requirements
-Helps analysts collect complete information
-Encourages consistency and completeness

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

What are some attributes in the IEEE template for requirements?

A
  • Identification
  • Version Number
  • Owner
  • Stakeholder Priority
  • Risk
  • Rationale
  • Difficulty
  • Type (Functional, Quality)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What is EARS (Easy Approach to Requirements Syntax)?

A

A structured natural language approach to writing requirements. Uses specific patterns to ensure clarity.
Patterns include:
- Ubiquitous: “The system shall <action> <object>."
- Event-driven: "When <trigger>, the system shall <action> <object>."
- State-driven: "While <state>, the system shall <action> <object>."
- Unwanted behavior: "If <condition>, then the system shall <action>."
- Optional feature: "Where <feature>, the system shall <action>."</action></feature></action></condition></object></action></state></object></action></trigger></object></action>

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

What are some examples of EARS syntax?

A
  • Ubiquitous: “The mobile phone shall have a mass of less than 200g.”
  • Event-driven: “When ‘mute’ is selected, the laptop shall suppress all audio.”
  • State-driven: “While there is no card in the ATM, the ATM shall display ‘Insert card’.”
  • Unwanted behavior: “If an invalid credit card number is entered, the website shall display an error message.”
  • Optional feature: “Where the car has a sunroof, it shall include a sunroof control panel.”
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What are the three types of requirements in Rupp’s Template?

A
  • Independent system action: “The system shall <process>."</process>
  • User interaction: “The system provides the user with the ability to <process>."</process>
  • Interface requirement: “The system is able to <process>."</process>
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What is Planguage in requirements engineering?

A

A method using structured keywords to define requirements.
Examples of keywords:
GIST: Short description
SCALE: Measurement scale
METER: How to measure it
MUST: Minimum requirement
STRETCH: Ideal target
WISH: Desirable outcome
PAST: Previous benchmark
TREND: Historical trend

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

Give an example of a requirement using Planguage.

A

Example: Bike Return

GIST: The system shall allow the user to return their bike to any available slot.
TAG: bike.return
STAKEHOLDER: Bike rental user
MUST: Allow bike return
PAST: Bikes could only be returned to the original rack
STRETCH: Allow return to any rack or slot
DEFINED [slot]: A space in the rack where a bike can be returned
PLAN: Full product release by 01-Sep-2025

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

What is the purpose of structured requirements templates?

A

Provide a systematic way to capture requirements
Ensure completeness and uniformity
Help identify missing information
Facilitate better communication among stakeholders

18
Q

What is the main advantage of using structured language for requirements?

A

Reduces ambiguity
Improves readability
Enforces completeness and uniformity
Makes requirements easier to validate and verify

19
Q

What are the benefits of using Cockburn’s Use Case Template?

A

Emphasizes time and flow of interactions
Provides a structured way to document use cases
Helps identify missing steps or alternative paths
Facilitates better communication among stakeholders

20
Q

What are preconditions and postconditions in a use case?

A

Preconditions: The required state of the system before the use case starts

Postconditions: The expected state of the system after the use case completes successfully

21
Q

What is a “Main Success Scenario” in a use case?

A
  • A step-by-step sequence of actions from trigger to successful goal completion
    Describes the ideal flow of interaction
    Does not include errors or alternate flows
22
Q

What are “Extensions” in a use case?

A
  • Describe alternative flows or variations of the main scenario
    Often occur when an expected step has a different outcome
    Example: “User enters incorrect PIN → Payment fails”
23
Q

What is a “Sub-variation” in a use case?

A
  • A variation of a step in the main success scenario
    Can lead to different paths in the scenario
    Example: “User chooses to pay with credit card vs. debit card”
24
Q

What are the key components of a requirements template?

A

Requirement ID
Description
Preconditions
Postconditions
Priority
Stakeholders
Related requirements

25
What is the Volere Template?
- A structured template for capturing software requirements Developed by James & Suzanne Robertson Includes attributes like rationale, stakeholders, constraints, and acceptance criteria
26
What are the main attributes in the IEEE 29148 standard for requirements?
Requirement ID Version number Owner Priority Risk Rationale Requirement Type (Functional/Non-functional)
27
What is the difference between functional and non-functional requirements?
- Functional Requirements: Define what the system should do (e.g., "The system shall allow users to log in.") -Non-functional Requirements: Define system qualities (e.g., performance, security, usability)
28
What are some examples of non-functional requirements?
- Performance (e.g., "The system must process requests in under 2 seconds.") - Security (e.g., "User data must be encrypted at rest and in transit.") - Usability (e.g., "The system should be accessible to visually impaired users.")
29
What is the EARS approach?
- A structured way of writing requirements Uses a small set of templates to improve clarity Reduces ambiguity and improves testability
30
What are the five EARS requirement patterns?
1) Ubiquitous: "The system shall ." 2) Event-driven: "When , the system shall ." 3) State-driven: "While , the system shall ." 4) Unwanted behavior: "If , then the system shall ." 5) Optional feature: "Where , the system shall ."
31
What is an example of a ubiquitous requirement in EARS?
"The mobile phone shall have a mass of less than 200g."
32
What is an example of an event-driven requirement in EARS?
"When ‘mute’ is selected, the laptop shall suppress all audio."
33
What is an example of a state-driven requirement in EARS?
"While there is no card in the ATM, the ATM shall display ‘Insert card’."
34
What is an example of an unwanted behavior requirement in EARS?
"If an invalid credit card number is entered, then the website shall display an error message."
35
What is an example of an optional feature requirement in EARS?
"Where the car has a sunroof, it shall include a sunroof control panel."
36
What are the three types of system activities in Rupp’s Template?
1) Independent system action: "The system shall ." 2) User interaction: "The system provides the user with the ability to ." 3) Interface requirement: "The system is able to ."
37
What is Planguage?
- A requirements specification language developed by Tom Gilb Uses structured keywords to define requirements Helps quantify and measure requirements
38
What are the key elements in Planguage?
GIST: Short description SCALE: Measurement scale METER: How to measure it MUST: Minimum requirement STRETCH: Ideal target WISH: Desirable outcome PAST: Previous benchmark TREND: Historical trend
39
How does Planguage express a requirement?
Example TAG: bike.return STAKEHOLDER: bike rental user MUST: Allow bike return PAST: Bikes could only be returned to the original rack STRETCH: Allow return to any rack or slot
40
What was the key takeaway from the related study on templates?
- Using templates improves quality factors in requirements - Leads to better compliance with guidelines - Increases the number of requirement statements - Different templates perform differently based on the context