lessons in project management - 6 - requirements engineering

Post on 05-Dec-2014

1.526 Views

Category:

Business

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

Visit the Berlin Consulting Forum at http://consultingforum.becota.org

TRANSCRIPT

International Project Management

Prof. Dr. Frank Habermann

Lecture 6 –

Requirements Engineering & Modeling

© Becota GmbH | www.becota.com | 2010

Legal (contractual) requirements vs. product requirements

Project (management) requirements vs. engineering requirements

Business (organisational) requirements vs. personal requirements

Product versus service engineering

Introducing enterprise models (as a method for connecting perspectives)

Introducing enterprise architectures

The problem of collecting information

Content

© Becota | www.becota.org | 2010

each project is

aboutmeeting

requirements

© Becota | www.becota.org | 2010

Requirements are closely linkedto goals and expectations

Picture sources: http://3.bp.blogspot.com; http://blogs.seattleweekly.com/dailyweekly/contract.jpg

the project contractrequests a certain quality to

meet the project‘s objectives

THE LEGAL REQUIREMENTS

© Becota | www.becota.org | 2010

Requirements are closely linkedto goals and expectations

Picture sources: http://3.bp.blogspot.com; http://blogs.seattleweekly.com/dailyweekly/contract.jpg

a stakeholderrequests a certain feature or quality

to meet his/her objectives

the project contractrequests a certain quality to

meet the project‘s objectives

THE PERSONAL REQUIREMENTS THE LEGAL REQUIREMENTS

© Becota | www.becota.org | 2010

Requirements are closely linkedto goals and expectations

Picture sources: http://3.bp.blogspot.com; http://blogs.seattleweekly.com/dailyweekly/contract.jpg

... and many stakeholdersrequest various features and qualities

to meet their perspectives

the project contractrequests a certain quality to

meet the project‘s objectives

A BUNCH OF PERSONAL REQUIREMENTS THE LEGAL REQUIREMENTS

© Becota | www.becota.org | 2010

Remember lecture 2:each corporate perspective is a source of requirements

regionalperspective (r)

hierarchicalperspective (h)

subject matterperspective (m)

Perspectivesto be integrated :

m * h * r

© Becota | www.becota.org | 2010

As a project manager you have to deal withall these kinds of requirements

Picture sources: http://hirepm.com; http://blogs.seattleweekly.com/dailyweekly/contract.jpg

A BUNCH OF PERSONAL REQUIREMENTS THE LEGAL REQUIREMENTS

TypeNumberLevel of Detail

TypeNumber

Level of Detail

© Becota | www.becota.org | 2010

Time drives requirements (number and level of detail)

TIME

Pre-Project Main Project

KNOWLDGE GAINED

Leve

l o

fre

qu

irem

en

tssp

ecif

icat

ion

© Becota | www.becota.org | 2010

Time drives requirements (number and level of detail)

TIME

Pre-Project Main Project

Leve

l o

fre

qu

irem

en

tssp

ecif

icat

ion

KNOWLDGE GAINED

© Becota | www.becota.org | 2010

Time drives requirements (number and level of detail)

TIME

Pre-Project Main Project

Leve

l o

fre

qu

irem

en

tssp

ecif

icat

ion

Fit

KNOWLDGE GAINED

© Becota | www.becota.org | 2010

Time drives requirements (number and level of detail)

TIME

Pre-Project Main Project

KNOWLDGE GAINED

Leve

l o

fre

qu

irem

en

tssp

ecif

icat

ion

Gap

Fit

© Becota | www.becota.org | 2010

Time drives requirements (number and level of detail)

Picture sources: http://3.bp.blogspot.com; http://blogs.seattleweekly.com/dailyweekly/contract.jpg

TIME

Pre-Project Main Project

Leve

l o

fre

qu

irem

en

tssp

ecif

icat

ion

Gap

Gap

Fit

© Becota | www.becota.org | 2010

Two main taks: developing and managing reqirements

TIME

Pre-Project Main Project

Leve

l o

fre

qu

irem

en

tssp

ecif

icat

ion develop

requirementsto the rightlevel of detail

© Becota | www.becota.org | 2010

Two main taks: developing and managing reqirements

TIME

Pre-Project Main Project

Leve

l o

fre

qu

irem

en

tssp

ecif

icat

ion develop

requirementsto the rightlevel of detail

Gap

managegaps/conflictsin type andlevel of detail

© Becota | www.becota.org | 2010

Requirements levels

enterprise

departments(= special interest groups)

employees(= users of the solution)

one

some

many

© Becota | www.becota.org | 2010

Requirements levels

BusinessChallenge(Mission)

enterprise

departments(= special interest groups)

employees(= users of the solution)

engineeringthe contract

(blueprintingthe solution)

one

some

many

© Becota | www.becota.org | 2010

Requirements levels

BusinessChallenge(Mission)

enterprise

departments(= special interest groups)

employees(= users of the solution)

engineeringthe contract

(blueprintingthe solution)

engineeringthe solution

one

some

many

© Becota | www.becota.org | 2010

Requirements levels

BusinessChallenge(Mission)

enterprise

departments

users

engineeringthe contract

(blueprintingthe solution)

engineeringthe solution

one

Requirements engineering in a strict sensemeans specifying the solution

© Becota | www.becota.org | 2010

project requirements

versus

productrequirements

© Becota | www.becota.org | 2010

Requirements engineering is aboutproduct requirements

THE CONTRACTUAL REQUIREMENTS

WHAT

The „object“ tobe delievered, i.e. the project product

PRODUCT requirements

HOW

The „way“ ofrunning the project

and producing the deliverables

PROJECT requirements

© Becota | www.becota.org | 2010

Requirements engineering is aboutproduct requirements

WHAT

• Solution components• Solution features• Solution-related services• …

HOW

• Project rules (e.g. corporate forms)• Project guidelines (e.g. following Prince2)• Project tools and methods (e.g. MS Project)• …

THE CONTRACTUAL REQUIREMENTS

© Becota | www.becota.org | 2010

Requirements engineering is aboutproduct requirements

WHAT

• Solution components• Solution features• Solution-related services• …

HOW

• Project rules• Project guidelines• Project tools and methods• …

requirementsengineering ismodeling theproject product

ímpacts

THE CONTRACTUAL REQUIREMENTS

© Becota | www.becota.org | 2010

Remember lecture 1…

Picture Source: www.infrastructurist.com

PROJECT RESULT

1. Temporary(a project got a

clear start and end date)

2. Unique(a project provides individual

and substantial results)

© Becota | www.becota.org | 2010

The product can also be a service product!

PROJECT PRODUCT Deliverable

SERVICEPRODUCT

PHYSICALPRODUCT

COULD BE

e.g. designingan innovative

restaurant processservice engineering

e.g. designingan innovative

and delicious mealproduct engineering

requirements engineering

© Becota | www.becota.org | 2010

Relationship between processes, services, products

Be seated Place order Get served Eat

„Dining at a fine restaurant“

Process chain

Pay

Meal

© Becota | www.becota.org | 2010

Relationship between processes, services, products

Be seated Place order Get served Eat

Place order Pay Get servedSeat

yourself

„Dining at a fine restaurant“

„Dining at a fast-food restaurant“

Process chain

Process chain

Pay

Eat

Meal

Meal

> Sometimes the service makes the difference!

© Becota | www.becota.org | 2010

Another famous example of service innovation

Picture source: http://www.n-tv.de/img/

© Becota | www.becota.org | 2010

some brief considerations

about product

quality

© Becota | www.becota.org | 2010

What is product quality?

The International Standardization Organization (ISO) says:

“The totality

of features and characteristics

of a product or service that

bears its ability to satisfy

stated or implied needs.“

© Becota | www.becota.org | 2010

What is product quality?

The International Standardization Organization (ISO) says:

“The totality

of features and characteristics

of a product or service that

bears its ability to satisfy

stated or implied needs.“

in just two words…

MATCHED

EXPECTATIONS

© Becota | www.becota.org | 2010

Unfortunately, a project manager has to cope with manyexpectations from all kinds of stakeholders…

Picture source: www.blackcommentator.com

> First rule: stay manageable, i.e.learn to say „no“

© Becota | www.becota.org | 2010

… and this – to make matters worse – is a great source ofmisunderstanding (e.g. in IT projects)

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse –is a great source of misunderstanding

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse –is a great source of misunderstanding

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse –is a great source of misunderstanding

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse –is a great source of misunderstanding

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse –is a great source of misunderstanding

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse –is a great source of misunderstanding

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse –is a great source of misunderstanding

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse –is a great source of misunderstanding

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

… and this – to make matters worse – is a great source ofmisunderstanding (e.g. in IT projects)

Picture source: http://govfor.us

© Becota | www.becota.org | 2010

In projects there is much room for misunderstanding

Picture source: http://jarodrosello.com/blog/wp-content/uploads/2009/ © Becota

> Second rule: for requirements engineeringchoose a language that everybodyaccepts and understands

© Becota | www.becota.org | 2010

this leads us to

enterprise

modeling

© Becota GmbH | www.becota.com | 2010

… before beginninga bigger project

… before fabricatingsomething which cannotbe changed anymore

… before investing serioustime and money

Thus a model always

– serves a higher purpose

– is an instrument

– is „made for something“

Architects (and artists) start with a model…

Picture source: http://www.marmo.ch/var/scultura/storage/images/www_home/kurse

© Becota GmbH | www.becota.com | 2010

What‘s a model?

© Becota | www.becota.org | 2010

Modeling – an example

Model Domain

Abstract

Model

Modeling Purposee.g. your

friend‘s birthday

Modeling Methode.g. interviewing yourGrandma and takinghand-written notes

© Becota | www.becota.org | 2010

Develop your individual example

Context (Model Domain)

Abstract

Model

Modeling Purpose???

Modeling Method???

Source: Scheer/Habermann/Thomas

???

???

© Becota GmbH | www.becota.com | 2010

Missing the two-faced god orwhy technical system design needs architectures and models

© Becota GmbH | www.becota.com | 2010

BusinessWorld

TechnicalWorld (here: ICT)

UnderstandingBusiness

UnderstandingTechnology

Missing the two-faced god orwhy technical system design needs architectures and models

© Becota GmbH | www.becota.com | 2010

BusinessPeople

TechPeople

BusinessWorld

ICTWorld

Missing the two-faced god orwhy technical system design needs architectures and models

© Becota GmbH | www.becota.com | 2010

Markets, Orders,Efficiency, Costs,

Revenues… Servers, Systems, Classes, Tools, Plattforms…

BusinessPeople

TechPeople

BusinessWorld

ICTWorld

Missing the two-faced god orwhy system design needs architectures and models

© Becota GmbH | www.becota.com | 2010

Business-oriented

View

BusinessWorld

ICTWorld

SharedModelWorld

Missing the two-faced god orwhy system design needs architectures and models

Technologyoriented

View

© Becota GmbH | www.becota.com | 2010

Business

Towards a modeling architecture

Technology

Shared Model World

© Becota GmbH | www.becota.com | 2010

Business

Towards a modeling architecture

Technology

© Becota GmbH | www.becota.com | 2010

Business

Modeling views

Technology

Data Function …Orga

© Becota GmbH | www.becota.com | 2010

Business

Modeling phases

Technology

Step 1

Step 2

Step n

© Becota GmbH | www.becota.com | 2010

Business

Modeling architecture a.k.a. methodology

Technology

EA

Data Functions …Orga

… Analysis

Design…Implementation…

© Becota GmbH | www.becota.com | 2010

Modeling – a business example

Model Domain

Abstract

Model

here: process model

Modeling Purposee.g. introduction of

a new logistics system

Modeling Methodhere: Value Chain

Diagram

Source: Scheer/Habermann/Thomas

© Becota GmbH | www.becota.com | 2010

• Process: Aircraft production

• Activity: Check turbine

• Customer: Airline

• Process duration: 22 days (on avarage)

• Process: Production of aircraft 4711

• Activity: Check turbine 4711-13b

• Customer: Emirates (order 201012)

• Process duration: May 1st, 2009 to June 3rd, 2009

Types vs. instances

Business type Business instance

© Becota GmbH | www.becota.com | 2010

Summary: Ways of reducing complexity…

1. Reduce information by havinga step-by-step approach (phase model)

Business

Technology

Analysis

Design

Implementation

© Becota GmbH | www.becota.com | 2010

Summary: Ways of reducing complexity…

1. Reduce information by havinga step-by-step approach (phase model)

Business

Technology

Analysis

Design

Implementation

2. Reduce information by concentratingon particular enterprise aspects (set your focus by selecting a view)

Business

Technology

Data Function …Orga

© Becota GmbH | www.becota.com | 2010

Summary: Ways of reducing complexity

Procure-ment

Support

Pro-duction

ShippingSales

Sales4712

Sales4713

Sales4711

3. Reduce information by identifyingcommon rules and characteristics (develop a model!)

types

instances

© Becota GmbH | www.becota.com | 2010

Summary: Ways of reducing complexity

Procure-ment

Support

Pro-duction

ShippingSales

Sales4712

Sales4713

Sales4711

Procure-ment

Support

Pro-duction

ShippingSales

CheckResourcesHandle

RequestPresent

ProposalNegotiate Contract

PrepareProposal

3. Reduce information by identifyingcommon rules and characteristics(develop a model!)

4. Reduce information by settingthe focus on parts and pieces (develop specified sub-models)

types

instances

level 1

level 2

level 3, 4, 5 …

© Becota | www.becota.org | 2010

Imagine your product would be a car …

© Becota | www.becota.org | 2010

What are its parts?

Picture source: h ttp://farm3.static.flickr.com/2317/2066997439_41215dcafa_o.jpg

© Becota | www.becota.org | 2010

And how can you model their hierarchical structure?

… … …

© Becota | www.becota.org | 2010

Aggregation / specification –another example (now service engineering)

ebay

externalevent

externalcustomer

.. Shopping at ebay

© Becota | www.becota.org | 2010

Aggregation / specification –another example (now service engineering)

ebay

externalevent

externalcustomer

.. Shopping at ebay

.. seeking insights (here: sub-processes) Auction

Support

PaymentShipping

Explo-ration

© Becota | www.becota.org | 2010

Aggregation / specification –another example (now service engineering)

ebay

externalevent

externalcustomer

.. Shopping at ebay

.. seeking insights (here: sub-processes) Auction

Support

PaymentShipping

Explo-ration

.. aiming at a deeper understanding of all business activities (i.e. theirhierarchical structure as well as their business logic)

A2A1 A4 A5

A3

© Becota | www.becota.org | 2010

Top-down vs. bottom-up modeling(in practice you combine both approaches)

ebay

externalevent

externalcustomer

Auction

Support

PaymentShipping

Explo-ration

A2A1 A4 A5

A3

top-down

bottom-up

© Becota | www.becota.org | 2010

Summary: Modeling

VIEW(e.g. process)

PHASE(e.g. design)

(SUB)MODEL

METHOD(e.g. Value Chain)

REAL WORLD

focus shape

© Becota | www.becota.org | 2010

profession

To sum it up: we use models to find a common language …

belief, behavior

knowledge

belief, behavior knowledge

education

age group

gender

ethnicity

nationality

Hierarchicalposition

profession

education

age group

gender

ethnicity

nationality

Hierarchicalposition

Picture inspired by www.filderfunkost.org/lk_bayreuth/pix/interdiscourse.jpg

syntax

MODEL =TRANSLATOR

sematics

© Becota | www.becota.org | 2010

… in order to avoid inconsistent solutions …

© Becota | www.becota.org | 2010

… as well as unpleasant misfits

© Becota | www.becota.org | 2010

I cannot overemphasize this point!

© Becota | www.becota.org | 2010

last but not least …

how to collect

informationfor

requierements analysis?

© Becota GmbH | www.becota.com | 2010

Analyse the requirements (1/2)

OrganisationalRequirements

UsabilityRequirements

TechnicalRequirements

ExternalRequirements

COLLECT

© Becota GmbH | www.becota.com | 2010

Analyse the requirements (2/2)

Picture Source: Sony

OrganisationalRequirements

UsabilityRequirements

TechnicalRequirements

ExternalRequirements

COLLECT

DISCUSS

APPROVE

SystemAnalysis

Architecture Functions Data Others…

© Becota | www.becota.org | 2010

Inquiry problems –the difficulties of capturing the actual situation

• Crucial question: Where do you get your information from?-> often from document studies, observation and interviews

• Problem: those process descriptions typically don‘t match the reality– Information is missing/incomplete– Information is redundant/inconsistent– Information is misleading/false– Two particular problems in practice, if you interview people:

• Is the person unbiased and objective? • Can and will the person risk to be “brutally” honest?

– Descriptions are on divergent levels of detail– Descriptions are in the „language“of the business area,

where the knowledge owner belongs to

Thank you very much!

presentation by

Frank Habermann

founder of Becota and Professor of Business

http://de.linkedin.com/in/frankhabermann/en

If you have enjoyed this presentation, please let us know!

You can download this file from theBerlin Consulting Forum

-> join the forum at http://consultingforum.becota.org

-> visit our corporate website at http://www.becota.com

top related