Beruflich Dokumente
Kultur Dokumente
1
Stages in RE
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management
2
Inception
• ask a set of questions that establish …
– basic understanding of the problem
– the people who want a solution
– the nature of the solution that is desired
– the effectiveness of preliminary communication
and collaboration between the customer and the
developer
3
Elicitation
• elicit requirements from all stakeholders
– address problems of scope
– address problems of understanding
• customers are not sure about what is needed,
skip “obvious” issues, have difficulty
communicating with the software engineer,
have poor grasp of problem domain
– address problems of volatility (changing
requirements)
4
Elaboration and negotiation
• Elaboration: create an analysis model that identifies data,
function, features, constraints and behavioral requirements
5
Specification
• can be any one (or more) of the following:
– A written document
– A set of models
– A formal mathematical model
– A collection of user scenarios (use-cases)
– A prototype
6
Validation
• a review mechanism that looks for:
– errors in content or interpretation
– areas where clarification may be required
– missing information
– inconsistencies (a major problem when large
products or systems are engineered)
– conflicting or unrealistic (unachievable)
requirements
– tests for requirements
7
Management
• involves managing change:
– Feature traceability: how requirements relate to
observable system/product features
– Source traceability: identifies source of each
requirement
– Dependency traceability: how requirements are
related to each other
– Subsystem traceability: categorizes requirements
by the sub system (s) they govern
– Interface traceability: how requirements relate to
both external and internal system interfaces
8
Methods and tools
many of them available
• lists
– elicitation question list
– checklists for validation
• graphical diagrams, good for communication
• formal methods
– e.g. UML for elaboration and specification
9
Quality Function Deployment
A technique of translating customer needs into technical
system requirements:
• Normal requirements: reflect stated customer goals
and objectives
• Expected requirements: implicit to the product or
system; their absence will cause significant customer
dissatisfaction
• Exciting requirements: featured going beyond
customer expectations, causing customer euphoria (;-)
• concentrate on maximizing customer satisfaction
10
Cont…
• Function deployment: determines the “value” (as
perceived by the customer) of each function required
of the system
• Information deployment: identifies data objects and
events, ties them to functions
• Task deployment: examines the behavior of the
system
• Value analysis: determines the relative priority of
requirements
11
Modeling approaches
12
Requirements Analysis
13
Stakeholder Identification
Stakeholders are people or organizations that have a valid
interest in the system. They may be affected by it directly or
indirectly.
Stake holders may include:
Anyone who operates the system
Anyone who benefits from the system
Anyone involved in purchasing or procuring the system
People opposed to the system (negative stakeholders)
Organizations responsible for the system
Requirements Analysis
15
Stakeholder Interviews
Interviews are a common technique used in requirement
analysis.
This technique can serve as a means of obtaining the highly
focused knowledge from different stakeholders perspectives
Requirements Analysis
16
Types of Requirements:
Customer Requirements:
Operational distribution or deployment: Where will the system be
used?
Mission profile or scenario: How will the system accomplish its
mission objective?
Performance and related parameters: What are the critical system
parameters to accomplish the mission?
Utilization environments: how are the various system components
to be used?
Effectiveness requirements: How effective or efficient must the
system be in performing its mission?
Operational life cycle: How long will the system be in use by the
user?
Environment: what environments will the system be expected to
operate in an effective manner?
Requirements Analysis
17
Types of Requirements:
Architectural Requirements:
A formal description and representation of a system, organized
in a way that support reasoning about the structure of the
system which comprises system components, the externally
visible properties of those components, the relationships and
the behavior between them, and provides a plan from which
products can be procured and systems developed, that will work
together to implement the overall system.
Requirements Analysis
18
Types of Requirements:
Functional Requirements:
Defines functions of a software system or its components. They
may be calculations, technical details, data manipulation and
processing and other specific functionality that define “what a
system is supposed to accomplish?”
They describe particular results of a system.
Functional requirements are supported by Non-functional
requirements.
Requirements Analysis
19
Types of Requirements:
Non-Functional Requirements:
They are requirements that specify criteria that can be used to judge
the operation of a system, rather than specific behavior.
Functional requirements define what the system is supposed to do,
whereas non-functional requirements define how a system is
supposed to be.
Non-functional requirements can be divided into two main
categories:
Execution qualities, such as security and usability, which are
observable at runtime.
Evolution qualities, such as testability, maintainability and
scalability.
Requirements Specifications
20
Initial Changed
understanding understanding
of problem of problem
Initial Changed
requirements requir ements
Time
Requirement Management
28
Set of activities that help project team to identify, control, and track
requirements and changes as project proceeds
Requirements begin with identification. Each requirement is assigned a unique
identifier. Once requirement have been identified, traceability table are
developed.
Traceability Table:
Features traceability table - shows how requirements relate to customer
observable features
Source traceability table - identifies source of each requirement
Collaboration Diagram
Describes the sequence of message passing among objects in
the system. Equivalent to sequence diagram , except that it
focuses on the object—s role.
Each communication link is associated with a sequence order
number plus the passed messages.
Class Diagram
Class diagrams can be derived from use-case diagrams or
from text analysis of the given problem domain. A class
diagram is
generated by system analysts and designers and will be
iteratively refined in the subsequent phases during the
software development life cycle.
Cont.
33
Activity Diagram
Outline of activity—s data and control flow among
related objects. An activity is an action for a system
operation or a business process, such as those
outlined in the use-case diagram.
It also covers decision points and threads of complex
operation processes. It describes how activities are
orchestrated to achieve the required functionality.
Design Models
34
Deployment Diagram
Describes system hardware, software, and network
connections for distributed computing.
It covers server configuration and network
connections between server nodes in real-world
setting.
Use case Diagram
36
Sequence Diagram
37
Collaboration diagram
38
Class Diagram
39
Activity Diagram
40
State Diagram
41
Component Diagram
42
Deployment Diagram
43
SEG3101 (Fall 2010)
46
URN Overview (2)
URN models can be used to specify and analyze
various types of reactive systems, business processes,
and telecommunications standards
jUCMNav
URN editor & analysis tool
Eclipse plug-in
Open source project
47
URN Overview
vision (3)
GRL Model business goals, called
stakeholders’ priorities, alternative strategies,
compared
solutions, rationale, and decisions with GRL
evaluation
traceability mechanis
with URN extensible
with m
links metadata
with UCM
traversal
UCM Model & test use cases; mechanis
m based
investigate high level architecture; on UCM
transform to more detailed models scenario
definitions
49
URN – Main Objectives
50
About ITU-T
51
ITU Languages
52
Transformations
Transformations connect URN models to other models
Some transformations discussed in publications or
implemented in jUCMNav’s predecessor UCMNav have not
yet been implemented in jUCMNav Requirements
Management
Test Cases (Fitnesse, TTCN) (Telelogic DOORS)
UML activity/sequence/state/use case diagrams
SDL
Textual Use Cases User Requirements Notation Core Scenario
(jUCMNav) Model
(UCEd *)
(CSM)
(for performance modeling)
Message Sequence
Charts
(MSC Viewer)
Summary
54
GRL Editor with Strategy Evaluation
Toolba
r
Navigator Editor
view
Outline
view
Palett
e
Propertie
Scenarios and s
Strategies view
view
UCM Editor with Scenario Traversal Perspectiv
e
Graphica
l Outline
Problem
s view
Integrated MSC Viewer for Exported UCM Scenarios
MSC
viewer
Outline
view
SOFTWARE DOCUMENTATION
Discussion Topics
1. Introduction
2. Documentation Requirements
3. Process and Product Documentation
4. Document Quality
5. Standards
Introduction
Schedules
Standards
Etc.
System Documentation
User Documentation
Product Documentation
System Documentation
Describes how the system works, but not how to operate it
Examples:
Requirements Spec
Architectural Design
Detailed Design
Commented Source Code
Including output such as JavaDoc
Test Plans
Including test cases
V&V plan and results
List of Known Bugs
Product Documentation
System Administrator
IEEE
Has a published standard for user documentation
Stable parts
Variant parts
IEEE/ANSI 830 - 1993
72
1. Introduction:
Purpose of the requirements document
Scope of product
Definitions, acronyms and abbreviations
References
Overview of the remainder of the document
2. General Description:
Product perspective
Product functions
User characteristics
General constraints
Assumptions and dependencies
IEEE/ANSI 830 - 1993
3. Specific Requirements
Covering functional, non functional & interface requirements,
these should document
External interfaces
Functionality
Performance requirement,
Logical database requirement,
Design constraints,
System attributes
Quality characteristics
IEEE/ANSI 830 - 1993
4. Appendices
5. index
75
Thank You!
Q?