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

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
Perspectives on Software Engineering: Quality of Software

The average software product released on the market is not error free
Irregular Shutdowns Misbehavior (MS Excel)
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 a high quality software system with a given budget before a given deadline while change occurs.
Perspectives on Software Engineering: Scientist vs. Engineer

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

General Procedure for Problem-Solving activity: Formulate the problem Analyze the nature of problem and break the problem into pieces Search for solutions/Identify the most appropriate solutions Specify the solutions The way: Modeling
Models abstract from a real life system that allows to answer questions about the systems: only relevant aspect are incorporated; Suppress irrelevant details
Knowledge Acquisition
Nonlinear process: addition of new knowledge may invalidate old knowledge
Rationale Management
Capturing the context in which decisions were made and the rationale behind these decisions
Perspectives on Software Engineering: A Problem Solving Activity

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

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
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

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

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 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?
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
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
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
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
Object-oriented decomposition emphasizes the objects that cause the operations.

Very useful after initial functional description Object Design Encapsulates data and functions helps to deal with change Objects dont change often, but functions do
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

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)

Defining Requirements is a very challenging activity Requirements Elicitation needs Collaboration between different groups (stakeholder)
Developers (design knowledge, implementation knowledge) Clients Users (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!
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

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

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

Current situation: The Problem to be solved Description of one or more scenarios Some initial requirements
Functional and Non-functional requirements Constraints (pseudo requirements)
Project Schedule
Major milestones that involve interaction with the client including deadline for delivery of the system
Target environment
The environment in which the delivered system has to perform a specified set of system tests
Client Acceptance Criteria

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

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)

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

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

Functional requirements
Describe the interactions between the system and its environment independent from implementation
Non-functional requirements (Most typical)

User visible aspects of the system not directly related to functional behavior. Reliability, Performance, Availability, Supportability, Usability, Tailorability, Security
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

Idea: A Library Management System should be designed. Information on books, CDs, DVDs, Journals, Problem Statement etc. can be stored and retrieved Possible Requirements:
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
functional requirement Implementation requirement performance requirement
availability requirement
What is usually not in the requirements?

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

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

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
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

Client/Customer
Contract partner who orders the software product Decides on budget and system functionality
User
uses the system important for successful introduction (involvement during RE!)
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
Project Manager
contract partner controls budget
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

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 project manager system specialist customer requirements engineer system user
Elicitation
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

Make conflicts explicit (avoid emotional conflicts) Develop relevant alternatives (incl. underlying rationales) Make right decisions
Votings, Decision Support Systems etc.
system specialist
Elicitation
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
Formal languages can be used (Consistency) In intermediate status inconsistencies may occur and must be tolerated Participants
administrative officer software engineer (programmer)
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
Elicitation
project manager
software engineer
Negotiation
marketing expert
Validation
am I building the right product? Checking if the specification meets users needs
programmer
Participants
Software engineer System specialist Customer
49
4 Worlds: Structuring the Context of Information Systems

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

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 Transformations between them Agreement Accomplish common agreement on the final specification Allow personal views meanwhile
Pohl et al.
52
Three Dimensions of Requirements Engineering: How to get there

Document the problem understanding reached Different views on the specification
Graphical, textual, etc.
Document the agreement reached

Negotiations Rationales
Be traceable
Contracts Understanding and acceptance Change Management Forward traceability (problem, refinement, requirement) and Backward traceability (requirement origin)
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering
Pohl et al.
53
Some problems concerning requirements engineering

Goals have to be identified Different stakeholders have different interests
Complex dependencies Changing interests and goals
Deficits in quality of descriptions and documentations

Redundancies Ambiguities Inconsistencies
54
Good Requirements
Complete
Functionality is described completely
Necessary
Requirement should be needed by customer and user
Correct
According to stakeholders intentions
Realisable
Requirements are to be realized in a software system
Consistent
There are no two requirements that can not be reached in one single system
Traceable
(discussed earlier)
Well-Defined
Requirement can only be understood in one single way Leaves no space for interpretation
Checkable
Requirements can be used to generate tests on the final software (or sinlge modules)
Comprehensible
Requirements are to be understood by all stakeholders
Overview of future lessons

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
Requirements Engineering is one of the early phases of software engineering process Iterative process Interaction between
Developers Customer Users
Input: Wishes, Problems, Unclear requirements, etc. Output: Analysis Model
57
References
Brgge and Dutoit: Object-Oriented Software Engineering
Chapter
Pohl, Klaus: Requirements Engineering: An Overview

For download (personal use only)
ftp://sunsite.informatik.rwth-aachen.de/pub/CREWS/CREWS-96-02.pdf
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

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

Limit complexity of problem through abstraction:

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

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()

Armin B. Cremers, Sascha Alda

Organizational Requirements Engineering

Decomposition (Object-Oriented): Iterative Modeling then leads to ....