functional reqiurements

Question 1

Functional Requirements

Answer 1

External system behavior, characterized by stimulus-response (input-output) pairs
Often in the form of “The system must do [xy]”
* Specify product features of a system

Question 2

Levels and Concepts of Behavioral Modeling

Answer 2

1. Analysis of Business Processes
2. Structured specification of Use Cases and Scenarios
3. Step-by-step refinement to system specification using
   Function Hierarchies

Question 3

Business Process Model

Answer 3

Analysis of Business Processes
* Tasks and causal dependencies
* Roles and responsibilities
* Involved business objects

Question 4

Usage Model

Answer 4

Structured specification of Use
Cases and Scenarios
* Derivation of tasks to be realized
in interaction with the system
* Identification of Use Cases
* Coordination and modeling of
interaction scenarios

Question 5

Function Hierarchy

Answer 5

Specification using Function Hierarchies
* Identification of system functions
based on scenarios
* Refinement of the functions and
identifications of interactions
* Specification of the interfaces

Question 6

What is a Use Case, scenario?

Answer 6

A use case bundles all possible scenarios that can occur when an
actor tries to achieve a certain technical goal with the help of the
system under consideration.

Definition Scenario:
An ordered set of interactions between partners, usually between a
system and a set of external actors [Glinz06]

Question 7

use case vs scenarion

Answer 7

• A use case is a set of scenarios
• A scenario is an ordered set (sequence) of interactions (functional requirements)
• Use cases can be described with the Use Case Template of Cockburn
• The interactions in a scenario can be unfolded into smaller and smaller
  interactions (e.g., “buy a coke” and “put coin into machine”)
• Some scenarios end with success, some end with failure

Question 8

Use Cases vs. Scenarios vs. Functional Requirements

Answer 8

Use Case:
Set of all scenarios
Scenario:
A concrete interaction
process
Functional Requirement:
A (system)-response to a
stimulus (take with a grain of
salt!)

Question 9

Use cases core components

Answer 9

Core Components
Context of use (remember design thinking: “user journey”
extends this idea) * Primary actors and their goals * Precondition: Assumptions about system environment
and the initial situation
* Postcondition: Utilization goal and target situation * Scenarios: Work steps and required Interaction between
actors (users, neighboring systems) and system
→ Control Flow
→ Scenarios (instances per use case)

Question 10

What is a Business Process? Concepts

Answer 10

A business process is a sequence of work steps for the fulfillment of
a goal.

Concepts (simplified)
* Function/Aim (Purpose/Intention - Why?)
* Process steps (tasks/activities) and causal dependencies/sequence
(interaction sequence - what? when? how? )
* Business objects (with what?)
* Distribution of tasks to involved roles (by whom? )
* organizational units, system users
* Systems, processes, HW/SW components of the system
environment

Question 11

Use Cases: From Business Processes to Functions

Answer 11

Capture and Model Business Processes
1. Identification of tasks and steps (building structures)
→ Surveys
2. Specification of partial steps, causal order and actors
→ Surveys, observations, analysis of target models
3. Identification of business objects

Analyze Processes and Identify Functions
1. Identification of use case candidates
→ tasks be performed by the system, which by external systems, which remain manual?
2. Definition of which sub-steps are to be performed by the user and which sub-steps
are to be realized by the system
3. Derivation of interaction scenarios
→ Going through different scenarios, often interactively with modification of the processes
based on new findings → Basis for function hierarchies

Question 12

Meaning of the Usage Model

Answer 12

Meaning of the Usage Model
* Application domain analysis: processes between external actors (users,
neighboring systems) and the system in context; business processes to be
supported
* Essential basis for voting on
* External system behavior (especially unclear/”critical” system behavior)
scenarios and their treatment)
− Identification of functions

Question 13

What is a Function Hierarchy?

Answer 13

Decomposition/structuring of functions and sub-functions as well as (intentional/unintentional)
dependencies (feature interaction) to analyze their required behavior definition according to
different principles, such as
* Tasks - subtasks
* Causal/temporal order
* Communication Relations
* Distribution to system components

Question 14

Importance of Function Hierarchies

Answer 14

• Overview of functions for analyzing system behavior
• Functions are
  1. identified on the basis of use cases,
  2. analyzed/tuned by means of Use Cases and
  3. structured in hierarchies
  → Essential basis for design of the (internal) system behavior

Question 15

Use of the Function Hierarchies

Answer 15

• Creation of syntactic interfaces: Specification of the amount of
  inputs and outputs at system interfaces, which serve the
  realization of the function
• Specification of the behavior (models)
• Definition of a logical component architecture

Question 16

From Scenarios to Functions: Basic Idea

Answer 16

1. Identify system functions based on the use cases / scenarios
   (context of use with assumptions, preliminary and post conditions,
   triggers, …)
2. Refine and structure system functions using a hierarchy
3. Identify dependencies between the functions
4. Define external interfaces
   (Dialogs, Data, …)

Question 17

What is a User Story?

Answer 17

A user story describes functionality that will be valuable to either a user or purchaser of a system
or software. User stories are composed of three aspects: [Cohn04]
* A written description of the story used for planning as a reminder
* Conversations about the story that serve to flesh out the details of the story
* Tests that convey and document details and that can be used to determine when a story is
complete

Question 18

Writing good User Stories

Answer 18

A good User Story is:
* Independent: No dependencies between stories as they lead to planning problems
* Negotiable: User Stories are no requirements, but description of functionality to be negotiated
* Valuable: User Stories should be valuable to users or customers
* Estimable: Developers should be able to estimate the size of a story
* Small: Long stories are difficult to understand and should be split up in a series of smaller stories
* Testable: Stories must be written so as to be testable. Passing all tests proves deployment

Question 19

System Models

Answer 19

Definition System Model:
A system model is a meta model which defines an abstract syntax. This abstract syntax is usually
specified in a modeling tool.
A system model describes certain model views of a system, which determine the structure or the
behavior of this system and their relations among each other.

Question 20

Difference between System Models and Models of a System

Answer 20

System Model (“meta model”):
Which constructs are necessary to
describe models. Conceptual model
using different views on a system.

Model of a System (“artifact model”):
Ideally built on system models like
content models. Structuring of models
in structure models.

Question 21

Projective vs. Synthetic

Answer 21

Projective (“god model”):
Holds all models for all views. God
models gets projected into
requested views

Synthetic (“coupling of models”):
Different views or view types
implemented with specific tools are
pairwise coupled.

Question 22

Critical Aspects when using Models

Answer 22

• Effort/Benefit when using models (e.g., detailed scenarios for “trivial” issues;
  synchronization!)
• Complexity of models and choice of notation
• Analysis and documentation of scenarios is crucial:
  → Scenarios form a communication bridge between
  − Stakeholders (for analysis/coordination)
  − Architects (draft)
  − Testers (specification of test cases