CPRE-FL Module 6: Model-based Requirement Documentation

3 types of requirements
GoalsGoals
Use Cases
and
Scenarios
Use Cases
and
Scenarios
System
Requirements
System
Requirements
Describe intentions of
stakeholders or groups of
stakeholders
Documents sequences of system
usage. Scenarios are grouped
together in use cases
Describes detailed functions and
qualities that the system to be
developed shall implement or
possess
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/6-model-based-requirement-documentation-2561

Properties of models
Pragmatic property
Models contain only
information necessary
for the specific purposes
Properties
of Models
Mapping of reality
Descriptive model
construction (AS IS)
Prescriptive model
construction (TO BE)
Reduction of reality
Selection
Compression

Requirements models vs. design models
Conventional models document
solutions chosen during system
development
Requirements models, depict
specific aspects of the
underlying problem

Goals in requirements engineering
Goals represent stakeholders’
intentions which specify system
characteristics
A system’s high level goals can
be refined further
Goals can be documented using
natural language or by using goal
models
Refining a goal is known as goal
decomposition

UML use case diagrams
Simple models to schematically
document the functions of a
system from a user’s perspective
It documents the interrelations of
the functions of a system
And the relations between these
functions and their environment
It comprises of :
Use cases
Actors
System boundaries
Include relation
Extend relation
Generalization

Use case specifications
Use case diagrams provide more
detailed information
Typical sections of a use case template
include:
Unique identification of use case
Management attributes
Description of use case
Specific use case attributes
Actors
Pre- and Post-conditions
Result of use case
Main scenario, alternative and
exception scenarios, and quality
requirements

3 modeling perspectives on requirements
3 overlapping perspectives of
requirements models are:
Data
Function
Behavior
Each perspective is documented
separately but certain aspects of
one perspective can also be found
in other perspectives

Requirements Modeling in
Data Perspective

Requirements Modeling in the Functional
Perspective

UML activity diagrams
UML activity diagrams are well
suited to model action sequences
It depicts the control flow
between activities or actions
They are well suited to document
relationships and execution
conditions of main, alternative,
and exception scenarios.
It comprises of:
Action nodes
Control flows

Activity diagram - Syntax/Semantics
Control flows
Control flows represent
directions of flow from one
activity to another
Object flows
Object flows represent flows of data
from one activity to another
Synchronization bars
Synchronization bars allow for
concurrent execution of control
flows
By making use of activity
partitions, different activities
can be documented as
responsibility of specific actors

State diagram - Syntax/Semantics
States
States refer to conditions or
situations objects are at particular
points of times during its life cycle
Initial states are represented by a
solid circle
Final states are represented by
filled circles nested inside another
circles

UML State diagrams
UML 2 defines entry points
and exit points as an
extension of state-charts
that allow for additional
hierarchization of states
An exit point is an externally
visible pseudo-state that is
immediately associated with
an internal state
An exit point is an
externally visible pseudo-
state that has its origin in
an internal state

Correct Option for Question 1
A. Use cases provide features, do not provide process
steps.

Question 3
3. In requirements engineering, which two substantial
advantages do graphical models (e.g. use case models or
state machines) have over plain textual specifications in
natural language? (2 answers)
a. A model representing reality contains condensed information
and can therefore be comprehended faster by a person with
modeling knowledge.
b. Models allow for complete description of the planned system.
c. Models can be better checked than natural language, as they
follow formalized syntax and semantics.
d. Models are created with tools using a repository. Therefore,
models are better suited for managing requirements.

B. Definition

Question 6
6. A system is described in different perspectives.
What is described in the functional perspective?
a. Portability of the system
b. Reaction time of the system upon external events
c. Static usage relations and dependencies
d. Structure of input and output data

B. Describes data flow diagram.

Question 9
9. As per the following use case
diagram, a team member can
a. Add backlog to schedule
b. Add and view backlog
c. Update backlog
d. Import backlog

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

CPRE-FL Module 6: Model-based Requirement Documentation

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de Flevy.com Best Practices

Mais de Flevy.com Best Practices (20)

Último

Último (20)

CPRE-FL Module 6: Model-based Requirement Documentation