functional reqiurements Flashcards
Functional Requirements
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
Levels and Concepts of Behavioral Modeling
- Analysis of Business Processes
- Structured specification of Use Cases and Scenarios
- Step-by-step refinement to system specification using
Function Hierarchies
Business Process Model
Analysis of Business Processes
* Tasks and causal dependencies
* Roles and responsibilities
* Involved business objects
Usage Model
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
Function Hierarchy
Specification using Function Hierarchies
* Identification of system functions
based on scenarios
* Refinement of the functions and
identifications of interactions
* Specification of the interfaces
What is a Use Case, scenario?
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]
use case vs scenarion
- 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
Use Cases vs. Scenarios vs. Functional Requirements
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!)
Use cases core components
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)
What is a Business Process? Concepts
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
Use Cases: From Business Processes to Functions
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
Meaning of the Usage Model
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
What is a Function Hierarchy?
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
Importance of Function Hierarchies
- 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
Use of the Function Hierarchies
- 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
From Scenarios to Functions: Basic Idea
- Identify system functions based on the use cases / scenarios
(context of use with assumptions, preliminary and post conditions,
triggers, …) - Refine and structure system functions using a hierarchy
- Identify dependencies between the functions
- Define external interfaces
(Dialogs, Data, …)
What is a User Story?
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
Writing good User Stories
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
System Models
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.
Difference between System Models and Models of a System
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.
Projective vs. Synthetic
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.
Critical Aspects when using Models
- 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
