Outline: Software Engineering For Software-Intensive Systems: IV Requirements

University of Paderborn
University of Paderborn Software Engineering Group
Software Engineering Group

Outline
I Introduction
Software Engineering for II Foundations
Software-Intensive Systems: III The Development Life Cycle
IV Requirements IV Requirements
V Analysis & Design
Assistant Professor Dr. Holger Giese VI Implementation
Room E 3.165 VII Verification & Validation
Tel. 60-
60-3321 VIIISummary and Outlook
Email: hg@upb.de
Holger Giese WS05/06 Software Engineering for Software-Intensive Systems IV Requirements IV-2
University of Paderborn University of Paderborn

Software Engineering Group Software Engineering Group
IV Requirements Why are Requirement so important?

IV.1 Requirements Engineering
IV.2 Requirement Specification Distribution of software errors
IV.3 Approach: SysML

IV.4 Approach: Goal-oriented
IV.5 Discussion & Summary
IV.6 Bibliography
Cost of rectifying errors
[Cooling2002]
Holger Giese WS05/06 Software Engineering for Software-Intensive Systems IV Requirements IV-3 Holger Giese WS05/06 Software Engineering for Software-Intensive Systems IV Requirements IV-4

[Thayer&Dorfman1997, p. 29]
What is Requirement Engineering? Requirement Characteristics

Requirement Engineering (RE) is the science and
discipline concerned with analyzing and documenting i. Type: the source and contractual
requirements. applicability
requirement. ii. Application: the object of a requirement
(1) A condition or capability needed by a user to solve a
problem or achieve an objective. iii. Compliance Level: the depth of
(2) A condition or capability that must be met or possessed compliance mandated for a requirement
by a system or system component to satisfy a contract,
standard, specification, or other formally imposed iv. Priority: relative importance of a
documents.
(3) A documented representation of a condition or capability requirement
as in (1) or (2).
[IEEE-Std-610.12-1990]
1
[Thayer&Dorfman1997, p. 29] [Thayer&Dorfman1997, p. 29]
i. Requirement Type ii. Requirement Application

Primary requirements: Sources: Product parameter: applies to a product or service to be
developed
Contract or pre-contract document Qualitative not directly measurable
children (derived requirements) refine which provide quantifiable
established by management or marketing criteria should be met
Quantitative measurable
Derived requirements: children (derived requirements) can be generated for the purpose of
Derived form a primary requirement specifying particular approaches to meet this measurable requirement
Program Parameter: activities associated with enabling the
Derived from a higher level derived creation of the product/service
requirement Task: effort to be performed
Compliance Evaluation: methodology for measuring compliance
Regulatory: administrative elements

iii. Requirement Compliance Level iv. Requirement Priority

Mandatory: must be implemented Characterize the relative importance of a
Guidance: desirable that it be requirement
implemented Basis for trade studies
Information: non-binding statements Unlike the other characteristics the priority
which significantly influence the context, depends on company needs
meaning, and understanding of other
requirements

A Good Set of Requirements is System vs. Software

[Thayer&Dorfman1997]
Correct System Requirement Engineering is the science

and discipline concerned with analyzing and
Unambiguous documenting system requirements.
Complete
origin: user needs
Software Requirement Engineering is the
Consistent science and discipline concerned with analyzing
and documenting software requirements.
Ranked for importance and/or stability
origin: system requirements and/or specification
Verifiable
BUT: For software-intensive systems software
people should be involved in the elicitation of the
[Thayer&Dorfman1997] system requirements!
[IEEE Std. 830-1993]
[IEEE Std. 830-1998]
2
The Context of Requirement Engineering

[Kotonya&Sommerville1998]
The Inputs and Outputs
Input or output Type Description

Existing system information Input Information about the functionality of systems to be
replaced or other systems which interact with the
system being specified
Stakeholder needs Input Descriptions of what stakeholders need from the
system to support their work
Organisational standards Input Standards used in an organisation regarding system
development practice, quality management, etc
Regulations Input External regulations such as health and safety
regulations with which the system must comply
Domain information Input General information about the application domain of
the system
Agreed requirements Output A description of the system requirements which is
understandable by stakeholders and which has been
[Kotonya&Sommerville1998] agreed by them

RE Elements (1) Requirement Elicitation

[Thayer&Dorfman1997] [Thayer&Dorfman1997]
Requirement Elicitation: the process through which the

(1) Requirement Elicitation customer and developer discover, review, articulate, and
understand the users needs and constraints on the
(2) Requirement Analysis software and development activities
(3) Requirement Specification
Requirements elicitation is about discovering what
(4) Requirement Validation requirements a system should be based upon
This doesnt involve just asking stakeholders what they
(5) Requirement Management Want. It requires a careful analysis of:
The organisation
The application domain
Organisation processes where the system will be used
To determine what the stakeholders Need.

Elicitation Process Stakeholders

Establish objectives Organise knowledge Who are they? Stakeholders backgrounds
Business goals Stakeholder Anyone with a stake in
vary: they may:
Problem to be solved identification come from different
creating or using a new
System constraints Goal prioritisation system departments
Domain knowledge be trained in different
Hands-on users
filtering disciplines
Their managers
Understand background Collect requirements The system administrator have different (possibly
Organisational structure
Stakeholder
conflicting) goals
The client (system owner)
Application domain requirements be unwilling to consider
The requirements engineer
Existing systems
Domain requirements
other stakeholders goals
Other Engineers
have more or less political
Organisational Software designers
requirements influence over
Programmers
requirements decisions
3
Uncovered Knowledge Requirements Elicitation Techniques

Application domain knowledge Interviews
E.g. knowledge about airport systems Questionnaires
Problem context knowledge Examination of documentation
E.g knowledge about Dallas Airport Standards
Systems manuals
Problem knowledge
Statement of requirements
E.g. knowledge about Dallass baggage-handling system
Prototyping
Stakeholders needs and work processes to be Contextual Design
supported
Conversation and interaction analysis

(2) Requirement Analysis Analysis & Negotiation

Requirement Analysis: the process of analyzing The analysis has to

establish an agreed
the customers and users needs to arrive at a set of requirements
definition of the requirements which are complete,
consistent, and
unambiguous. Such
requirements analysis. a set can be used as
(1) The process of studying user needs to arrive at the basis for systems
development.
a definition of system, hardware, or software Negotiation:
requirements. Stakeholders often
(2) The process of studying and refining system, disagree over
hardware, or software requirements. requirements.
Therefore they need
[IEEE-Std-610.12-1990] to negotiate to try to
reach agreement.

(3) Requirement Specification (4) Requirement Validation

[Thayer&Dorfman1997] [Thayer&Dorfman1997]
Requirement Specification: the Requirement Validation: the process of

development of a document that clearly and ensuring that the requirement specification is
precisely records each of the requirements in compliance with the user needs, system
of the software. requirements, conforms to document
standards, and is an adequate basis for the
see IV.2 architectural design.
see Chapter VII
4
(5) Requirement Management Requirements for Complex Systems

Requirement Management: the planning A system of any but the smallest size will
and controlling of the requirements be decomposed into a hierarchy of
elicitation, specification, analysis, and elements (partitioning):
verification activities. This is reflected at the requirement level by:
(1) Allocation: assigning requirements to
elements
(2) Flowdown: requirements which respond to the
allocated highel level requirements
(3) Traceability: keep track of the dependencies

Effort Distribution for Complex Systems Requirements vs. Design

[Coolman2002]
Naive view
Distinction:
For complex Design solution: HOW to achieve something
systems due to Requirements: WHAT to achieve
allocation and
Two cases where a requirements and desigin solutions are mixed up:
flowdown the The customer mandates a design solution as a requirement
requirement Design solution (HOW): provide a database for X
Requirements (WHAT): capabilities for navigation and sort for X
engineering Otherwise:
continues during [Coolman2002]

Restrict design space
Risk to miss requirements: ask WHY!
the design (and A derived requirement which is actually a design solution and no
requirement
implementation) See allocation and flowdown
phase

Often alternation of requirements analysis and design
One persons design is the next persons requirements

IV.2 Requirement Specification Terminology

IV.1 Requirements Engineering requirements specification.

IV.2 Requirement Specification A document that specifies the requirements
for a system or component. Typically
IV.3 Approach: SysML included are functional requirements,
IV.4 Approach: Goal-oriented performance requirements, interface
IV.5 Discussion & Summary requirements, design requirements, and
development standards. Contrast with:
IV.6 Bibliography design description. See also: functional
specification; performance specification.
[IEEE-Std-610.12-1990]
5
A Good Requirement Specification Software Requirements Specification (1/4)

Table of Contents
Correct 1. Introduction
1.1 Purpose
1.2 Scope
Unambiguous 1.3 Definitions, acronyms, and abbreviations
1.4 References
Complete 1.5 Overview

2. Overall description
2.1 Product perspective
Consistent 2.2 Product functions
2.3 User characteristics
2.4 Constraints
Ranked for importance and/or stability 2.5 Assumptions and dependencies
3. Specific requirements
3.1 External interface requirements
Verifiable 3.2 Functional requirements
3.3 Performance requirements
Modifiable 3.4 Design constraints

3.5 Software system attributes
3.6 Other requirements
Traceable [Thayer&Dorfman1997]
Appendixes
Index
[IEEE Std. 830-1993] [IEEE Std. 830-1998]
[IEEE Std. 830-1998]

Software Requirements Specification (2/4) Software Requirements Specification (3/4)

3.1 External interface requirements A detailed description of all inputs into 3.2 Functional requirements Organized using system mode
3.1.1 User interfaces and outputs from the software system.
3.1.2 Hardware interfaces Complements the interface descriptions 3.2.1 Mode 1 Some systems behave quite
3.1.3 Software interfaces in 2.1 (not repeated information) 3.2.1.1 Functional requirement 1.1 differently depending on the
3.1.4 Communications interfaces mode of operation (training,
Content/format: normal, or emergency)
Name of item; 3.2.m Mode m
Description of purpose;
3.2.m.1 Functional requirement m.1
Source of input or destination of output; Alternatives:
Valid range, accuracy, and/or tolerance;
User class
Units of measure; 3.2.m.n Functional requirement m.n
Timing; Objects
Relationships to other inputs/outputs; Feature
Screen formats/organization;
Window formats/organization;
Stimulus
Data formats; Response
Command formats;
Functional hierarchy
End messages.
[IEEE Std. 830-1998] [IEEE Std. 830-1998]

Software Requirements Specification (4/4) IV.3 Approach: SysML

3.3 Performance requirements 3.4 Design constraints
static and the dynamic numerical This should specify design
IV.1 Requirements Engineering
requirements placed on the constraints that can be imposed
software or on human interaction by other standards, hardware
IV.2 Requirement Specification
with the software limitations, etc.
a) The number of terminals to be 3.5 Software system attributes
IV.3 Approach: SysML
supported;
b) The number of simultaneous
Examples IV.4 Approach: Goal-oriented
Reliability
users to be supported;
c) Amount and type of information
Availability IV.5 Discussion & Summary
to be handled. Safety
d) Amount of data to be processed Security IV.6 Bibliography
within certain time periods for Maintainability
both normal and peak workload Portability
conditions.
3.6 Other requirements
[IEEE Std. 830-1998]
6
SysML An Upcoming Standard From Document centric to Model centric

System modeling language (SysML):
defines a modeling language for systems engineering applications Past Specifications Future
supports the specification, analysis, design, verification and validation of a range
of complex systems
intended to assist in integrating systems and software methodologies
Interface requirements
Who? System design

International Council on Systems Engineering (INCOSE) joint with
Object Management Group (OMG) in January 2001 Analysis & Trade-off
Why Model based? Test plans

Improved communications
Reduced ambiguity
Reduced errors
More complete representation Here: only
Enhanced knowledge capture Moving from Document centric to Model centric
Requirements!
[SysML1.0alpha]

SysML & UML 2.0 [SysML1.0alpha]

SysML Diagrams [SysML1.0alpha]
UML 2.0 SysML
(1)Requirement Diagrams
(2)Use Case Diagrams
(3)Scenarios: Sequence/Activity Diagrams

Sample Problem [SysML1.0alpha]

(1) Requirement Diagram [SysML1.0alpha]
A Requirement specifies a capability or condition that a system

The sample problem describes the the must satisfy. A requirement may define a function that a system
must perform or a performance condition that a system must fulfill.
development of a Hybrid Sports Utility Vehicle Requirements are used to establish a contract between the
customer (or other stakeholder) and those responsible for
(SUV) system. The problem is derived from a designing and implementing the system.
A composition describes how a compound requirement can be
marketing analysis which indicated the need to decomposed into multiple sub-requirements.
A Derive relationship is a trace dependency between a derived
increase the fuel economy and eco-friendliness of requirement and a source requirement, where the derived
requirement is generated or inferred from the source requirement.
the vehicle from its current capability without A Satisfy relationship is dependency between a supplier
requirement and a client model element that fulfills the requirement.
sacrificing performance. Only a small subset of the
A test case is a behavior or operation that specifies how a
functionality and associated vehicle system requirement is verified. A test case can address one or more
verification methods. A test case always returns a verdict.
requirements and design are addressed to A Verify relationship is a trace dependency between a supplier
requirement and a client test case that determines whether a
highlight this application. system fulfills the requirement.
7
Requirement Decomposition [SysML1.0alpha]

Trade Analysis [SysML1.0alpha]
A Measure of Effectiveness (MoE)

states an optimization condition
that a system must satisfy.
Whereas the requirements for a
system define the domain of the
solution, the solution space, the
Measures of Effectiveness drive the
solution to a particular region in that
space. Each MoE has a weight
attribute to reflect its relative
importance and a score attribute to
capture its value based on the
alternative under investigation.

Example [SysML1.0alpha]
Derived Requirement [SysML1.0alpha]

Requirements Satisfaction [SysML1.0alpha]

Requirements Verification [SysML1.0alpha]
8
Traceability [SysML1.0alpha]
(2) Views & Viewpoints [SysML1.0alpha]
A View is an abstraction of a whole system that

addresses one or more concerns of the system
stakeholders. A view has only one viewpoint.
A Viewpoint specifies the purpose, stakeholders,

stakeholder concerns, language selections and
method selections related to a view.
A Conform relationship is dependency between a

supplier viewpoint and a client view that fulfills
the requirement.
Remark: The defintions of view and viewpoint used

by SysML are intended to be compatible with the
IEEE 1471 Recommended Practice for
Architecture Description. [IEEE-Std-1471-2000]

Examples [SysML1.0alpha]
(2) Use Case Diagram [SysML1.0alpha]
Aids by establishing:
the scope and context of the system under
development (:HybridSUV),
identifying key external entities (people,
external systems, etc.) that interact with the
system along with the associated external
interfaces, and
providing the initial high level decomposition
of behavior according to key system threads
or scenarios.

Example Refining Use Cases

Scenarios
Sequence Diagrams
Activity Diagrams
See Chapter V
9
IV.4 Approach: Goal-oriented Conceptualising Systems Using Goals

IV.1 Requirements Engineering We can understand a envisoned systems in terms
of the goals it is intended to meet
IV.2 Requirement Specification A goal is an expression of a state to be achieved or
IV.3 Approach: SysML avoided
There are high-level goals and low-level goals
IV.4 Approach: Goal-oriented
IV.5 Discussion & Summary Deriving goal hierarchies:
top-down decomposition of high-level goals
IV.6 Bibliography
Elicit goals from the stakeholders; then build a
hierarchy from the elicited goals
Infer the existence of goals

Decomposing Goals A Goal Hierarchy

High-level goals may be decomposed into lower-
level goals in two ways to produce a goal
hierarchy:
G1 is
G1 is achieved if
achieved if either
G1.1 an G1.1 or
G1.2 are G1.2 is
achieved achieved
Refine until leaf goals can be satisfied

Multiple implementation alternatives!

Conflicting Goals Inferred Goals

Sometimes goals in a goal
hierarchy may conflict with
one another. For example,
in a library system, two
conflicting goals may be:
Conflict Detection:
Manual treatment does not scale up well
Alternative: re-express each goal formally and then use a theorem
prover to detect inconsistencies, i.e. conflict.
Conflict resolution:
return to the stakeholders who own the conflicting goals to see
whether they would be prepared to accept a compromise (satisficing).
Using only the goal with the highest priority
10
IV.5 Discussion & Summary IV.6 Bibliography (Additional ones)

[Anton+1998] A. Anton et al. The Use of Goals to Surface Requirements for
Requirements is a crucial element of developing Evolving Systems, International Conference on Software
Engineering, pp157-166, IEEE Comp. Soc. Press, 1998
systems as about 80% of the software errors are [Cooling2002] Jim Cooling, Software Engineering for Real-time Systems. Addison
located in the requirements. Wesley, November 2002
ISBN: 0201596202
The system modeling language (SysML) [IEEE-Std-830-1993] Standards Coordinating Committee of the IEEE Computer Society,
The Institute of Electrical and Electronics Engineers, Inc., 345 East
provides a modeling language for systems 47th Street, New York, NY 10017-2394, USA, IEEE Recommended
Practice for Software Requirements Specifications, IEEE Std 830-
engineering applications that supports the 1993.
[IEEE-Std-830-1998] Standards Coordinating Committee of the IEEE Computer Society,
specification and analysis of requirements and The Institute of Electrical and Electronics Engineers, Inc., 345 East
47th Street, New York, NY 10017-2394, USA, IEEE Recommended
integrates systems and software methodologies. Practice for Software Requirements Specifications, IEEE Std 830-
1998.
Goal-oriented requirements engineering [IEEE-Std-1471-2000] Standards Coordinating Committee of the IEEE Computer Society,
The Institute of Electrical and Electronics Engineers, Inc., 345 East
facilitates the detection and resolution of intrinsic 47th Street, New York, NY 10017-2394, USA, Recommended
Practice for Architectural Description of Software-Intensive Systems,
conflict and facilitates the identification and IEEE-Std-1471-2000.
exploration of alternative solutions.
University of Paderborn
Bibliography (Additional ones)

[Kotonya&Sommerville1998] G. Kotonya and I. Sommerville,
Requirements Engineering. John Wiley,1998. Systems
Requirements Engineering, P. Loucopoulos et al., Mc
Graw-Hill, 1995
[Lamsweerde2001] A. van Lamsweerde, Goal-Oriented Requirements
Engineering: A Guided Tour, 5th International
Symposium on Requirements Engineering, IEEE
Computer Society Press, 2001
[Loucopoulos&Karakostas1995] Loucopoulos, P., and Karakostas, V.,
System Requirements Engineering, McGraw-Hill,1995
[Sommerville&Sawyer1997] Sommerville, I., and Sawyer, P.,
Requirements Engineering, John Wiley,1997
[Thayer&Dorfman1997] Software requirements engineering Thayer,
Richard H. And Dorfman, Merlin [Hrsg.]:. - Los
Alamitos, Calif. [u.a.] : IEEE Computer Soc. Press ,
1997 .
ISBN: 0-8186-7738-4
Holger Giese WS05/06 Software Engineering for Software-Intensive Systems IV Requirements IV-63
11

Outline: Software Engineering For Software-Intensive Systems: IV Requirements

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Outline: Software Engineering For Software-Intensive Systems: IV Requirements

Загружено:

Авторское право:

Доступные форматы

University of Paderborn

University of Paderborn Software Engineering Group

Software Engineering Group

University of Paderborn University of Paderborn

IV Requirements Why are Requirement so important?

IV.3 Approach: SysML

University of Paderborn University of Paderborn

What is Requirement Engineering? Requirement Characteristics

[Thayer&Dorfman1997, p. 29] [Thayer&Dorfman1997, p. 29]

i. Requirement Type ii. Requirement Application

University of Paderborn University of Paderborn

iii. Requirement Compliance Level iv. Requirement Priority

University of Paderborn University of Paderborn

A Good Set of Requirements is System vs. Software

Correct System Requirement Engineering is the science

The Context of Requirement Engineering

The Inputs and Outputs

Input or output Type Description

University of Paderborn University of Paderborn

RE Elements (1) Requirement Elicitation

Requirement Elicitation: the process through which the

University of Paderborn University of Paderborn

Elicitation Process Stakeholders

Uncovered Knowledge Requirements Elicitation Techniques

University of Paderborn University of Paderborn

(2) Requirement Analysis Analysis & Negotiation

Requirement Analysis: the process of analyzing The analysis has to

University of Paderborn University of Paderborn

(3) Requirement Specification (4) Requirement Validation

Requirement Specification: the Requirement Validation: the process of

see Chapter VII

(5) Requirement Management Requirements for Complex Systems

University of Paderborn University of Paderborn

Effort Distribution for Complex Systems Requirements vs. Design

University of Paderborn University of Paderborn

IV.2 Requirement Specification Terminology

IV.1 Requirements Engineering requirements specification.

A Good Requirement Specification Software Requirements Specification (1/4)

Complete 1.5 Overview

Modifiable 3.4 Design constraints

University of Paderborn University of Paderborn

Software Requirements Specification (2/4) Software Requirements Specification (3/4)

[IEEE Std. 830-1998] [IEEE Std. 830-1998]

University of Paderborn University of Paderborn

Software Requirements Specification (4/4) IV.3 Approach: SysML

[IEEE Std. 830-1998]

SysML An Upcoming Standard From Document centric to Model centric

Who? System design

Why Model based? Test plans

University of Paderborn University of Paderborn

SysML & UML 2.0 [SysML1.0alpha]

UML 2.0 SysML

University of Paderborn University of Paderborn

Sample Problem [SysML1.0alpha]

A Requirement specifies a capability or condition that a system

Requirement Decomposition [SysML1.0alpha]

A Measure of Effectiveness (MoE)

University of Paderborn University of Paderborn

University of Paderborn University of Paderborn

Requirements Satisfaction [SysML1.0alpha]

A View is an abstraction of a whole system that

A Viewpoint specifies the purpose, stakeholders,

A Conform relationship is dependency between a