01 - Requirements Engineering Intro

Chapter 1 Requirements Engineering (Introduction)
Organizational Requirements Engineering

Prof. Dr. Armin B. Cremers Sascha Alda
Global View on Software Engineering Problem, Solutions, Basic Techniques

Can you develop this?
Armin B. Cremers, Sascha Alda
Limitations of Non-engineered Software
Requirements
Software
Characteristics of Modern Systems

z
Volatile business environment subject to constant change - BPR; rapid IS development needed Wide range of more complex system types CAD/CAM, GIS, Office Automation, CASE tools Increased use of complex data types - text documents, video, sound, graphics, spatial data Sophisticated user interfaces (GUIs) Client-Server environments / distributed systems Tendency for larger systems with complex and varied interrelationships among software components
z z z
Perspectives on Software Engineering: Quality of Software

z
The average software product released on the market is not error free

Irregular Shutdowns Misbehavior (MS Excel)
z z
Updates are needed to meet users requirements Bug, Problems, Failures Misunderstanding requirements leads to functional misbehavior Errors in code
Standard software: 25 bugs per 1.000 lines of program Windows95: 200.000 errors (!) in 10 Millions lines
Exploding
costs during development Delivery Date can not be met Organizational structure changes
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 5
Perspectives on Software Engineering: Definition

Software Engineering is a collection of techniques, methodologies and tools that help with the production of
z z z
a high quality software system with a given budget before a given deadline while change occurs.
Perspectives on Software Engineering: Scientist vs. Engineer

z
Computer Scientist

Proves theorems about algorithms, designs languages, defines knowledge representation schemes Has infinite time Develops a solution for an application-specific problem for a client Uses computers & languages, tools, techniques, and methods Works in multiple application domains Has only 3 months... while changes occurs in requirements and available technology
Engineer

Software Engineer

Perspectives on Software Engineering: A Problem Solving Activity

General Procedure for Problem-Solving activity: z Formulate the problem z Analyze the nature of problem and break the problem into pieces z Search for solutions/Identify the most appropriate solutions z Specify the solutions The way: z Modeling

Models abstract from a real life system that allows to answer questions about the systems: only relevant aspect are incorporated; Suppress irrelevant details Nonlinear process: addition of new knowledge may invalidate old knowledge Capturing the context in which decisions were made and the rationale behind these decisions
Knowledge Acquisition
Rationale Management
Perspectives on Software Engineering: A Problem Solving Activity

Problem solving needs
z
Notation
Graphical or textual set of rules for representing a model Repeatable technique that specifies the steps for solving a specific problem Collection of methods for solving a class of problems. Specifies how and when each method should be used Instrument or automated systems to accomplish a method
Methods:
Methodologies:
Tools:
Factors affecting the quality of a software system

z
Complexity
The
application (problem) domain is difficult Complex technologies (programming languages) The development process is very difficult to manage Domains are complex that no single person can understand it Fixing a bug causes another bug
z
Change
Requirements
need to be updated when errors are discovered and when developers have a better understanding of the application Project constellation changes (staff turn-around) Technological changes (new standards, languages)
10
Dealing with Complexity

1. 2. 3.
Modularization of the software life cycle Abstraction through modeling various aspects of a problem Decomposition of the system to be modeled
11
Modularization: Software Development Process

Requirements Elicitation Analysis System Design Object Design Implementation Testing
Expressed in Terms of
Structured by
Realized by
Implemented by
Verified by
class... class... class...
?
class....?
Use Case Model
Application Domain Objects

Subsystems
Solution Domain Objects
Source Code
12
Test Cases
Abstraction: Limiting Complexity

z
Motivation: Inherent human limitation to deal with complexity

A
human being is able only able to perceive and to reason about 7 (+/- 2) things simultaneously. (the 7 +- 2 phenomena, Miller 1956)
Limit complexity of problem through abstraction: Models
13
Abstraction: Models are used to provide abstractions

z
System Model:
Object
Model: What is the structure of the system? What are the objects and how are they related? Functional model: What are the functions of the system? How is data flowing through the system?
Dynamic z
model: How does the system react to external events? How is the event flow in the system ?
Task Model:
PERT
Chart: What are the dependencies between the tasks? GANTT Chart: How can this be done within the time limit? Org Chart: What are the roles in the project or organization?
z
Issues Model:
What
are the open and closed issues? What constraints were posed by the client? What resolutions were made?
Abstraction: Interdependencies of the Models

System Model (Structure, Functionality, Dynamic Behavior)
Issue Model (Proposals, Arguments, Resolutions)
Task Model (Organization, Activities Schedule)

Abstraction: The Bermuda Triangle of Modeling

System Models
Object Model Forward Engineering Code Reverse Engineering
Functional Model
Dynamic Model
Constraints Arguments Issues Pro Con Proposals
Org Chart PERT Chart Gantt Chart
Issue Model
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering
Task Models
16
Decomposition: Overview
z z
A technique used to master complexity (divide and conquer) Functional decomposition

The
system is decomposed into modules Each module is a major processing step (function) in the application domain Modules can be decomposed into smaller modules
z
Object-oriented decomposition
The
system is decomposed into classes (objects) Each class is a major abstraction in the application domain Classes can be decomposed into smaller classes
Which decomposition is the right one?

Decomposition: Overview
z
Both views are important during software life-cycle Functional decomposition emphasizes the ordering of operations
Very
useful at requirements engineering stage and high level description of the system. Functions are spread over the system Hard to maintain / change
z
Object-oriented decomposition emphasizes the objects that cause the operations.

useful after initial functional description Object Design Encapsulates data and functions helps to deal with change Objects dont change often, but functions do
Very
18
Decomposition: Functional Decomposition

System Function Produce Output
Top Level functions
Read Input
Transform
Level 1 functions
Read Input
Transform
Produce Output
Level 2 functions
Load R10
Add R1, R10
Machine Instructions
19
Decomposition (Object-Oriented): What is This?
20
Decomposition (Object-Oriented): Model of an Eskimo

Eskimo Size Dress() Smile() Sleep()
Shoe Size Color Type Wear()
Coat Size Color Type Wear()
21
Decomposition (Object-Oriented): Iterative Modeling then leads to ....

lives in
Cave Lighting Enter() Leave()
Eskimo Size Dress() Smile() Sleep()
moves around
Environment Temperature Light Season Hunt() Organize()
Entrance
Windhole Diameter
MainEntrance Size
but is it the right model?

22
Decomposition (Object-Oriented): Alternative Model: The Head of an Indian

Indian Hair Dress() Smile() Sleep()
Size listen()
Ear
Face Nose smile() close_eye()
Mouth NrOfTeeth Size open() speak()
23
Decomposition (Hierarchies): Part-of-Hierarchy

Computer
I/O Devices
CPU
Memory
Cache
ALU
Program Counter
24
First View on Requirements Engineering

z z z
Requirements Engineering is the first phase of the Software Lifecycle Production of a specification from informal ideas Goal: Requirements Specification

System requirements specification: requirements describe Software and Hardware Software requirements specification: describe only Software
RE is about what the system should do (not how to do it) Key influencing factor to the development process

Failures made here result in high costs in later development phases System will meet the user/customer needs
25
Software Development Process: A Brief Overview

Requirements Elicitation Analysis System Design Object Design Implementation Testing
Expressed in Terms of
Structured by
Realized by
Implemented by
Verified by
?
class....?
Use Case Model
Application Domain Objects

Subsystems
Solution Domain Objects
Source Code
26
Test Cases
What is Requirements Engineering? (1/2)

z z
Defining Requirements is a very challenging activity Requirements Elicitation needs Collaboration between different groups (stakeholder)
Developers Clients Users
(design knowledge, implementation knowledge)
(domain knowledge)
Two questions need to be answered

How
can we identify the purpose of a system? What is inside, what is outside the system? Very hard to decide!
z
Errors during Requirements Elicitation

System
fails to support users work: Missing or incorrect functionality Corrections are expensive
What is Requirements Engineering? (2/2)

Requirements Engineering Requirements Elicitation
Basis for Discussions with customer Definition of the system in terms understood by the customer (Problem Description)
Requirements Analysis
Design basis for developers Technical specification of the system in terms understood by the developer (Problem Specification)
28
Process of Requirements Elicitation: Products of Requirements Process

Problem Statement Requirements Elicitation Requirements specification: functional and non-functional requirements Requirements Analysis
Analysis Model: dynamic model object model

Organizational Requirements Engineering 29
Requirements Engineering: Input and Output

z
Initial Input

A Vision of a system to be created (vague) Different stakeholders with different interests Problem Statement Specification as complete as possible
Complete coverage of the problem (all relevant requirements are
Desired Output
captured)
Complete and exact definition of each requirement
30
Starting with the Problem Statement

z
The problem statement is developed by the client as a description of the problem addressed by the system A good problem statement describes

The current situation The functionality the new system should support The environment in which the system will be deployed Deliverables expected by the client Delivery dates A set of acceptance criteria
31
Starting with the Problem Statement: Ingredients

z z z
Current situation: The Problem to be solved Description of one or more scenarios Some initial requirements
Functional
and Non-functional requirements Constraints (pseudo requirements)

z
Project Schedule
Major
milestones that involve interaction with the client including deadline for delivery of the system environment in which the delivered system has to perform a specified set of system tests for the system tests
Target environment
The
Client Acceptance Criteria

Criteria
32
Starting with the Problem Statement: Current Situation - Problem To Be Solved

z
There is a problem in the current situation

Examples: The response time in a travel booking system is far too slow There have been illegal attacks to the system
A change either in the application domain or in the solution domain has appeared
Change
in the application domain
A new function (business process) is introduced into the business Example: A function is provided for credit payment with fingerprint as
authorization
Change
in the solution domain
A new solution (technology enabler) has appeared Example: New standards (implementation) for secure network
communication
The Goal: Analysis Model
(vs. Requirements Specification)

z
Both models focus on the requirements from the users view of the system. Requirements specification uses natural language (derived from the problem statement) The analysis model uses formal (Z, pi-calculus) or semi-formal notation (for example, a graphical language like UML)
Formal notations encompass an exact mathematical syntax and semantic
The starting point is the problem statement
34
Requirements and their Meaning

z
Definition of term Requirement

A condition or capability needed by a user to solve a problem or to achieve an objective Condition or capability that must be met by a system
Satisfies a contract, standard, specification
35
Functional and Non-Functional Requirements

z
Functional requirements
Describe the interactions between the system and its environment independent from implementation User visible aspects of the system not directly related to functional behavior. Reliability, Performance, Availability, Supportability, Usability, Tailorability, Security
Non-functional requirements (Most typical)

Pseudo requirements (Non-functional requirements B)

Imposed by the client or the environment in which the system operates Legal requirements Design and Implementation Constraints
Project Management (Non-functional requirements C)

Budget, Release Date
Example: Library System

z
Idea: A Library Management System should be designed. Information on books, CDs, DVDs, Journals, Problem Statement etc. can be stored and retrieved Possible Requirements:
functional requirement Implementation requirement performance requirement
Searching by Title, Author, and/or ISDN should be possible User Interface should be web-based (accessible via WWW Browser) At least 20 transactions per seconds should be possible All services should be available within 10 minutes Users have no access to personal data of other users
Security requirement
availability requirement
What is usually not in the requirements?

z z z z z
System structure, implementation technology Development methodology Development environment Implementation language Reusability It is desirable that none of these above requirements are constrained by the client.
38
Software Requirements Standards

z
Many guidelines and standards exist that define the content and structure for good requirement specification document. Examples:

IEEE Recommended Practice for Software Requirements Specifications (IEEE Std-830) JPL Software Requirements Analysis Phase (JPL D-4005)
39
Requirements Specification Model (RSM) 1/3:First view

z
RSM is embraces the most common requirements standards into a single metamodel.

Model: an abstraction of a system that omits irrelevant details Metamodel: A model that explains a set of related models
z z
RSM was proposed by Gibbels and Pohl Hierarchical Conception: Using classification, generalization, aggregation, and attribution Can help structuring requirements according to a specific scheme
40

Abstract-Functional-RQ
(Taken from K. Pohl)

(Taken from K. Pohl)

Some stakeholders in the RE Process

z
Client/Customer
Contract partner who orders the software product Decides on budget and system functionality
z
User
uses the system important for successful introduction (involvement during RE!)
z
User Advocate
speaks two languages: the one of the users, and the one of the developers should be
technical experienced (what can be built) domain expert
z
Project Manager
contract partner controls budget

z
Programmer/Software/Requirements Engineer
has knowledge on system development

Requirements Engineering Process: Four Phases (Another Perspective)
Elicitation
Analysis/ Negotiation
Documentation
Validation
Analysis Model
User requirements Existing systems Standards
Requirements Document
System specification
44
Requirements Engineering Process: Four Phases (Another Perspective)

requirements engineer system user system specialist
customer
Validation & Verification
Elicitation
project manager/ user advocate
software engineer
Specification & Documentation
Negotiation
marketing expert
administrative officer
programmer
Organizational Requirements Engineering 45
Four Phases 1: Elicitation

z z
Elicit requirements, needs, and constraints Collecting knowledge about

domain (problem, laws) existing standards and systems existing specifications (may be in a variety of representations)
software engineer system specialist
customer
requirements engineer system user
Elicitation
project manager
Negotiation
marketing expert
Using
scenario-based approaches interviews simulations and prototypes
programmer
Participants

requirements engineer User client

Four Phases 2: Negotiation

customer requirements engineer system user
Reaching agreements on the requirements between all stakeholders involved

system specialist
Elicitation
Make conflicts explicit (avoid emotional conflicts) Develop relevant alternatives (incl. underlying rationales) Make right decisions
Votings, Decision Support Systems etc.
project manager
software engineer
Negotiation
marketing expert
programmer
Important: Recording and Documentation of Decisions (might be unstable) Participants

project manager marketing expert programmer
47
Four Phases 3: Specification and Documentation

customer requirements engineer system user
No monolithic model, rather a bunch of models

taking into account different perspectives representing intermediate as well as final results
system specialist
Elicitation
project manager
software engineer
Negotiation
marketing expert
z z
Formal languages can be used (Consistency) In intermediate status inconsistencies may occur and must be tolerated Participants

programmer
administrative officer software engineer (programmer)
48
Four Phases 4: Validation and Verification

customer requirements engineer system user system specialist
Verification

am I building the product right? Checking specification against formally defined constraints am I building the right product? Checking if the specification meets users needs Software engineer System specialist Customer
Elicitation
project manager
software engineer
Negotiation
marketing expert
Validation

programmer
Participants

49
4 Worlds: Structuring the Context of Information Systems

z
Information Systems can be seen from different perspectives
Subject
Domain of the system Stakeholders = Subjects that are represented within system Example: Car Recommender System, Cars
Usage
Stakehoders = Users of the system Usage world can be outside the subject world Example: Customers, Car Dealer
System
Operating and Maintaining Example: Car dealers system manager
Development
Example: Developers, Architects, User Representative etc.
All four perspectives (and contexts) are dependent on each other
50
4 Worlds: Dependencies
Impact privacy ownerships
Subject World
Representation accuracy, timeliness
System World
Interface Efficiency Friendliness Presentation Functionality
Usage World
Correct representation Domain knowledge
Legacy systems Maintainability Reuse Configurations
Participation Business Processes Needs
Development World
Three Dimensions of Requirements Engineering or: Three Goals

z
Specification Developing as complete as possible requirements specification Include cost schedule Representation Provide integrated representation formalisms of all aspects
Informal, semi-formal, formal as
needed
z
Pohl et al.
Transformations between them Agreement Accomplish common agreement on the final specification

Allow personal views meanwhile
52
Three Dimensions of Requirements Engineering: How to get there

z z
Document the problem understanding reached Different views on the specification
Graphical, textual, etc.
Document the agreement reached
Negotiations Rationales
z
Be traceable
Pohl et al.
Contracts Understanding and acceptance Change Management
Forward traceability (problem, refinement, requirement) and Backward traceability (requirement origin)
Some problems concerning requirements engineering

z z
Goals have to be identified Different stakeholders have different interests

Complex dependencies Changing interests and goals Redundancies Ambiguities Inconsistencies
Deficits in quality of descriptions and documentations

54
Good Requirements
z
Complete
Necessary
Functionality is described completely

z
Requirement should be needed by customer and user Requirements are to be realized in a software system (discussed earlier)
Correct
Realisable
According to stakeholders intentions

z
Consistent
Traceable
There are no two requirements that can not be reached in one single system Requirements can be used to generate tests on the final software (or sinlge modules) Requirements are to be understood by all stakeholders
Well-Defined
Checkable
Requirement can only be understood in one single way Leaves no space for interpretation
Comprehensible
55
Overview of future lessons

z z z z z z z z z z z z
Modeling with UML Software Development Process Models Requirements Elicitation Requirements Analysis Requirements Verification Requirements Management Methods for Requirements Engineering Viewpoint-oriented Requirements Methods Non-functional Requirements Interactive Systems Groupware Systems Practitioners talks (tba)
Conclusions
z
Requirements Engineering is one of the early phases of software engineering process Iterative process Interaction between

z z
Developers Customer Users
z z
Input: Wishes, Problems, Unclear requirements, etc. Output: Analysis Model
57
References
z
Brgge and Dutoit: Object-Oriented Software Engineering
Chapter For download (personal use only)

ftp://sunsite.informatik.rwth-aachen.de/pub/CREWS/CREWS-96-02.pdf
Pohl, Klaus: Requirements Engineering: An Overview
58

01 - Requirements Engineering Intro

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01 - Requirements Engineering Intro

Uploaded by

Copyright:

Available Formats

Chapter 1 Requirements Engineering (Introduction)

Organizational Requirements Engineering

Global View on Software Engineering Problem, Solutions, Basic Techniques

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Limitations of Non-engineered Software

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Characteristics of Modern Systems

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Perspectives on Software Engineering: Quality of Software

Irregular Shutdowns Misbehavior (MS Excel)

Perspectives on Software Engineering: Definition

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Perspectives on Software Engineering: Scientist vs. Engineer

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Perspectives on Software Engineering: A Problem Solving Activity

Perspectives on Software Engineering: A Problem Solving Activity

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Factors affecting the quality of a software system

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Dealing with Complexity

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Modularization: Software Development Process

class... class... class...

Use Case Model

Application Domain Objects

Solution Domain Objects

Organizational Requirements Engineering

Abstraction: Limiting Complexity

Motivation: Inherent human limitation to deal with complexity

Limit complexity of problem through abstraction: Models

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Abstraction: Models are used to provide abstractions

Abstraction: Interdependencies of the Models

Issue Model (Proposals, Arguments, Resolutions)

Task Model (Organization, Activities Schedule)

Abstraction: The Bermuda Triangle of Modeling

class... class... class...

Constraints Arguments Issues Pro Con Proposals

Org Chart PERT Chart Gantt Chart

A technique used to master complexity (divide and conquer) Functional decomposition

Which decomposition is the right one?

Object-oriented decomposition emphasizes the objects that cause the operations.

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Decomposition: Functional Decomposition

Add R1, R10

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Decomposition (Object-Oriented): What is This?

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Decomposition (Object-Oriented): Model of an Eskimo

Shoe Size Color Type Wear()

Coat Size Color Type Wear()