lecture 1: sign-up, introductionfileadmin.cs.lth.se/cs/education/ets170/lect/2015/l1.pdf · re...

Welcome toETS170 Requirements Engineering (Kravhantering)http://cs.lth.se/ETS170/

Lecture 1:Sign-up, Introduction

Björn RegnellCourse headLecturesExamination

ElizabethBjarnasonCourse coordinator, Exercises,Project, LabExamination

Lena OhlssonCourse secretaryRoom E:217909:30 - 11:3012:45 - 13:30

JohanLinåkerProject,Lab

Recent cs.th.se doctoral theses in Requirements Engineering supervised by Professor Björn Regnell

Elizabeth BjarnasonIntegrated Requirements Engineering – Understanding and Bridging Gaps within Software DevelopmentDoctoral Dissertation, 2013, ISBN 978-91-7473-732-5

Krzysztof Wnuk Visualizing, Analyzing and Managing the Scope ofSoftware Releases in Large-Scale Requirements EngineeringDoctoral Dissertation, 2012, ISBN 978-91-976939-7-4

Richard Berntsson Svensson Supporting Release Planning of Quality Requirements: The Quality Performance ModelDoctoral Dissertation, 2011, ISBN 978-91-976939-4-3

Requirements Engineering (RE)RE means to ...

... dig up, understand, write down, check, prioritize, decide, follow up…

... the features of (software) products

… innebär att

gräva fram, förstå, skrivaner, kolla, prioritera, besluta om, följa upp …

... (mjukvaru-) produktersegenskaper

Kravhantering

You will soon be working as an engineer…

Hannes Lindbeck Requirements specialist, Project Manager, Outsourcing specialistat Sogeti

- I took the requirements engineering course at LTH in 2004, and it was so interesting that I have focused my entire career on requirements and project management. Lessons from the course text book

and my experiences from the course project are still with me every day :)

Economic consequences of requirements engineering problems

[Davis, 1992]

Cos

t of c

orre

ctin

g a

prob

lem

Req Design Coding SystemTesting

AcceptanceTesting

Operation

Course contents 7,5 credit points8 lectures (W1 Mon+Thu, W2 Mon+Thu, W3, W4, W5, W7)

Give overview and structure (not all theory is covered)Scala crash course + reqT scripting L4 in W2Guest lecturer: Hampus Jacobsson L5 in W3Mandatory project examination L8 in W7

5 exercises (W1-5 Tue or Wed, sign-up list today)How to use the theory in the project, prepare for the written examSign up for one exercise time slot – ideally with your project team!

Computer Lab sessions (W3, W5, sign-up list later)Focus on computer tools, preparations mandatory

Project (3 credit points ~ 80 h per person, 6-8 persons, sign-up list today)Purpose: to apply theory in practical workYou act as both customers AND developers

Written exam on all literature (4,5 credit points)Literature: Lauesen + compendiumCompendium is sold at the CS expedition by Lena Ohlsson 12:45

60 SEK – please bring even moneyBonus points for the exam, based on 2 optional hand-ins.

Max 10 bonus points on first exam if you hand in good exam problems proposals

Hand-outs: course program + introduction survey

Hand in surveyafter the break

Examination

Project grade (Fail,3,4,5); groups based grade Labs (Fail, Pass); graded in pairs based on

preparations and examination at the lab Written exam; individual grade.

Total 100p; 50p is required for pass 2 optional hand-ins of exam problem proposals, in

groups, can bring max 10 bonus points to the written exam if good

Final grade (Fail,3,4,5); mapped from exam points with limits based on project grade...

Final grade

0102030405060708090

100

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61

ETS170 HT2014 Tenta

Tenta BonusUK8% 3

10%

439%

543%

http://reqT.org• A scalable requirements modeling tool• Turns requirements models into structured code• Especially developed for this course• Implements important concepts from the literature• Produces documents for hand-ins via auto-generated html, latex, pdf• Integrates with Google docs, Excel, Word etc via txt, html and csv• Integrates with version mgmt. cloud services, e.g GitHub, Bitbucket• Implemented in the Scala language enabling powerful scripting• reqT&Scala tutorial Th W2 @10-12 in MA:05• Used at labs: (1) Reqts Modelling, (2) Reqts Prio+Release Planning• Discuss in your project if/how you want to use reqT

Inlärningsmål:Kunskapsmål

1. definiera grundläggande begrepp och principer inom kravhantering

2. redogöra för ett flertal olika typer av krav3. redogöra för och värdera ett flertal olika metoder och

tekniker för kravhantering4. beskriva och relatera olika delprocesser inom kravhantering5. beskriva kravhanteringsprocessens relation till övriga

processer i produktlivscykeln6. redogöra för kravhanteringens relation till

marknadsorienterad produktledning7. diskutera några forskningsresultat inom

kravhanteringsområdet

English version in course program

Inlärningsmål:Färdighetsmål

1. kunna välja lämplig kravhanteringsteknik för sammanhanget

kunna använda flera olika tekniker för att ...2. elicitera (identifiera)3. specificera4. validera5. prioritera... krav


Inlärningsmål:Attitydmål

1. medvetet kunna välja arbetssätt efter hur kravbilden ser ut2. visa prov på ett systematiskt och långsiktigt arbetssätt3. medvetet kunna problematisera över kravkvalitetens påverkan

på slutproduktens kvalitet4. på ett adekvat sätt kunna involvera användare i kravprocessen5. medvetet kunna problematisera över kravhanteringens relation

till ekonomiska aspekter i produktutveckling


Kursinnehåll1. Krav på olika abstraktionsnivåer och i olika sammanhang2. Kravhanteringens delprocesser och deras relation3. Specificering av datakrav, t ex med virtuella fönster och

datamodeller4. Specificering av funktionella krav, t ex med egenskapskrav och

uppgiftsbeskrivningar5. Specificering av olika typer av kvalitetskrav (icke-funktionella

krav), t ex användbarhet, prestanda, och tillförlitlighet6. Olika tekniker för elicitering, t ex fokusgrupper, prototyper7. Olika tekniker för validering, t ex granskningar8. Olika tekniker för prioritering, t ex parvisa jämförelser9. Marknadsorienterad kravhantering, produktledning och

prioritering


Project organization

Another team isyour developer

Another team isyour customer

System Requirements

Project Mission

Work as customer 20%Work as developer 80%

Project Supervisor

Your team

System Requirements

Project Mission

Project 6-8 persons per project Sign-up list for project teams during the break Mandatory project exam L7, Mon W7, starting 10:05 sharp This week W1 you shall create a Project Mission to be delivered latest this

Friday at 09.00 via email To: [email protected] ; [email protected] ; [email protected] ;Subject: [ETS170] Team X: PM v1

The Project Mission shall fit on one A4 page an be in .pdf-format It shall contain a project title and name + email of all group members Check out examples from previous years at the course web site All subsequent project hand-ins are sent to your project supervisor assigned

to your group by Monday W2 Next Monday at lecture L3 you will choose Project Mission.

♦ The choice order is randomized. You cannot choose your own PM.

What is a good Project Mission?

You have a deep knowledge of the domain You have a genuine interest in the system You can evaluate detailed requirements on the system The mission has a large scope of interesting possibilities

As customer you act as:Key Customer Your are one of many potential customer.

The development team owns the product and decides on priorities and product content, while your team gives input and provides feedback.

Project deadlines

Iteration 1R1Project

Mission v1PMv2

Iteration 2R2

Iteration 3R3

W4Mon

W6Mon

W7Fri

W1Fri

W3Mon

W2

Meeting w supervisor



Project Roles

P3RM Project, Process, Prioritization, and Release Manager (1)

SCCVM Stakeholder, Customer Communication and Validation Manager (1)

TDEVM Tools, Documents, Experiences and Version Manager (1-2)

EPM Elicitation and Prototyping Manager (1-2)

QRM Quality Requirements Manager (1)

DRM Data Requirements Manager (1)

Discussion to activate prior knowledge

Vad var realistiskt eller orealistiskt med den kravhantering ni varit med om i tidigare projekt (tex i PUSS-kursen)?

Vilka olika sorters krav stötte ni på?

What was realistic or unrealistic with the requirements engineering you did in previous project courses?

What different types of requirements did you encounter?

Actions during the brake

1. Sign up on a project team2. Sign up on exercises (whole team!)3. Fill in the introductory survey and

hand it in after the break

Intro to the theory part of the course

Motivation The role of Requirements

Engineering (RE) Basic concepts Different types of RE Different types of requirements (reqs) Reqs at different abstraction levels

Lau Compendium

Motivering Kravhanteringens roll Grundläggande begrepp Olika sorters kravhantering Olika sorters krav Krav på olika

abstraktionsnivå

2014

READ THE TEXT BOOKREAD THELITERATURE

!!!

READ THE TEXT BOOKGO TO EXERCISES

!!!

Basic terminology

Lausen: “A requirement specification is a document that describes what the system should do.”

What is “what” and what is “how”?Always a “document”?What is “the system”? How much about the domain?

Definition enl. IEEE [1990]

A requirement is:(1) A condition or capability needed by a user to solve a problem or

achieve an objective.(2) A condition or capability that must be met or possessed by a

system or system component to satisfy a contract, standard, specification, or other formally imposed document.

(3) A documented representation of a condition or capability as in (1) or (2).

What are requirements?

Requirements are similar to shopping lists

You often want things you don't need ...

You can't always getwhat you want ...

What is a req?MåsteMust

ÖnskemålWish

BehovNeed

ProduktProdukt-egenskapFeature

Dokumenterad

representation

DokumenteradrepresentationDocumentedrepresentation

?BeslutDecision

KvalitetQuality

FunktionFunction

IdéIdea

BegränsningConstraint

Requirements Entities Examples from the reqT metamodel

Product, Interface, Stakeholder,Idea, Goal, Feature, Data, Function, State, Event, Quality, Design, Scenario, Story, UseCase, Risk, Release, Issue, Test, Variant, Req

Requirements Engineering

Important sub-processes:Elicitation – to identify the requirementsSpecification – to document the requirementsValidation – to check the requirementsPrioritization – to select the best requirementsThese processes are interdependent and are best done iteratively, in parallel and continuously.When are we ready?

The Requirements Engineering process is also a…

... Learning process... Intelligence process

... Decision process... Innovation process

Example: MOBILE VENDOR X

Where do requirements come from?Who are the stakeholders?

External stakeholdersCustomers

Direct customersOperators

Global customersRegional customersOther key customers

RetailersIndirect customers

ConsumersMarket segments

Service providersContent providers

Product providersDirect Competitors

Mobile phone developersIndirect Competitors

CamerasMobile music players… consumer wallet competition

Platform providersOperating SystemsTechnical Platforms

Network system providersStandardization bodiesLegislation and authorities

NationalInternational

Manufacturing sub-contractorsComponent providers…

Internal stakeholdersMarketing

Long term brandingCustomer relations

Product managementProduct planningRoadmapping and portfolios

Product developmentHardware design

ElectronicsAnalogDigital

MechanicsSoftware design

User interfaceService logicNetwork accessCodecs

Platform developmentMother, daughters, clusterGlobal functions

Sub-contracting managementTechnical platforms Operating systemsOriginal Design Manufacturing

Technology forecastingMarket researchCustomer Services

SupportRepair

LegalSourcingAccessories…

… find the right person to talk to …… get the deep domain knowledge …

SW Value chains are getting more and more complex...

Software Ecosystems

Orders of magnitude in Requirements Engineering

Abrev. Level Order of magnitude

Managing a complete set of interdependencies…

SSRE Small-ScaleRequirementsEngineering

~10 reqs requires small effort.

MSRE Medium-Scale RequirementsEngineering

~ 100 reqs is feasible but requires large effort.

LSRE Large-Scale RequirementsEngineering

~1000 reqs is practically unfeasible, but feasible among small bundles of requirements.

VLSRE Very Large-Scale RequirementsEngineering

~10000 reqs among small bundles of requirements is unfeasible in practice.

Dealing with very large sets of requirements

Profitable?

Expensive?

Ambiguous?Related?

Group?Complete? Split?

Reject?

Strategic?

RequirementsDatabaseToo

much

Different contexts and project types In-house – Internutveckling för egna behov Product Development – Produktutveckling för öppen marknad, t.ex.

inbyggda system, generella appar för en marknad (COTS), etc. Time & Materials – Utveckling på löpande räkning, rörligt pris Commercial Off-The-Shelf software (COTS) purchase

– Inköp av generisk (hyll-) programvara Customization – Kundspecifik anpassning av generisk programvara Tender – Anbudsförfrågan

♦ Customer specific: för upphandling av kundspecifik utveckling♦ Generic (COTS): för upphandling av generisk programvara

Contract development – Kontraktsbaserad utveckling med fast/rörligt pris Sub-contracting – Underleverantörskontrakt med fast/rörligt pris Unknown, pre-study – Okänd, förstudie för att utreda lämplig projekttyp Hybrid – kombinationer av ovanstående ... ?The context is critical to the requirements engineering!

Fig 1.2 Project types

Project types Customer SupplierIn-house User dept. IT dept.Prod. devel. Marketing SW dept.Time & materials Company SW houseCOTS purchase Company (Vendor)Tender Company SupplierContract devel. Company SW houseSub-contracting Supplier SW houseUnknown Inhouse?

COTS?

From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002

Internutveckling för egna behov (In-house) Produktutveckling för öppen marknad

(Product Dev.) Utveckling på löpande räkning

(Time&Materials) Inköp av generisk (hyll-)programvara

(COTS purchase) Kundspecifik anpassning av generisk

programvara Anbudsförfrågan (Tender)

♦ för upphandling av kundspecifik utveckling♦ för upphandling av generisk programvara

Kontraktsbaserad utveckling med fast/rörligt pris

Underleverantörskontrakt med fast/rörligt pris

Okänd – förstudie för att utreda lämplig projekttyp

Hybrider – kombinationer av ovanstående

Sammanhanget är avgörande för kravhanteringen!

Mutual relationshipcustomer - supplier

Who has the power?Who has the knowledge?

Who takes the biggest risk?Wo takes the biggest profit?

In the short term?In the long run?

Mutual benefit?

Contract

Analysis

Reqspec

Op & maint

Design

Program

Test

Fig 1.1 The role of requirements

DemandsElicitation

Stakeholders Tacitdemands

& reqs

Tracing:Forwards . . .Backwards . . .

Req. management:Changing reqs


Functional requirements, each interface:Record, compute, transform, transmitTheory: F(input, state) -> (output, state)Function list, pseudocode, activity diagramScreen prototype, support tasks xx to yy

System

Platform:HW, OS, DBSpreadsheet

Ext. products:Sensors, dev.Special SW

Fig 1.3 Contents of ReqSpec

User groups

Quality reqs:PerformanceUsabilityMaintainability. . .

Other deliverables:DocumentationInstall, convert,train . . .

Managerial reqs:Delivery timeLegalDevelopment process . . .

Helping the reader:Business goalsDefinitionsDiagrams . . .

Interfaces

Data requirements:System state: Database, comm. statesInput/output formats


Requirements versus design

Product Architecture

A B

C D

L2L1

DB

GUI

REQ

REQ REQ

REQ

Cost?Value?Long-term versus short term? Different types of requirements?

REQ

Product

Platform

Controlcomputers

Fig 1.5A Domain and product level

User activities

Domain

DomainI/O Product

I/O

Product-level reqs:The product shall accept the following input: . . .

Clients

“Business” domain Actors?

Elevators

Domain-level req:The product shall support the following user activities: . . .


Product

Controlcomputers

Fig 1.5B Redefined limits

User activities

Domain

Clients

“Business”domain


Beware: the word “domain” is used in many ways

Beroende på hur situationen ser ut kan ett nytt system innebära att domängränserna ritas om. Kanske sker en upphandling där styrsystemet ingår i produkten och då blir hissarna aktörer som kommunicerar direkt med systemet.

Mycket av affärsutveckling handlar om att skaka om I domängränserna och tex låta användaren göra mer själv. Exempel: COOP Forums shop express. SAS web check-in.

Fig 1.6A The goal-design scale

R1. Our pre-calculations shall hit within 5%

R2. Product shall support cost recording and quotation with experience data

R3. Product shall have recording and retrieval functions for experience data

R4. System shall have screen pictures as shown in app. xx

Goal-levelrequirement

Domain-levelrequirement

Product-levelrequirement

Design-levelrequirement

Which requirement to choose?

If the supplier isA vendor of business applications?A software house - programmers?PriceWaterhouseCoopers?From: Soren Lauesen: Software Requirements

© Pearson / Addison-Wesley 2002

Mål-nivå bakomliggande syfte, affärsmål, användarnytta, effekt, vinst

Domän-nivå sammanhang, omgivning, hur användarna och produkten samverkar för att ge nytta

Produkt-nivå externt observerbara funktioner och egenskaper

Design-nivå specifik utformning av produktens innehåll

Evolving mix of levels of detail & quality in continuous requirements engineering

Level of detail, specification quality

The goal-design scale in reqTModel(

Goal("accuracy") hasSpec("Our pre-calculations shall hit within 5%"),

Feature("quotation") hasSpec("Product shall support cost recording and

quotation with experience data"), Function("experienceData") has

Spec("Product shall have recording and retrieval functions for experience data"),

Design("screenX") hasSpec("System shall have screen pictures as shown

in Fig. X"))

Product("reqT") has Feature("toHtml")

Product("reqT") has Feature("toTable")

Product("reqT") has Feature("toGraph")

Model(Feature("f1") has (Spec("The system shall..."), Status(IMPLEMENTED)),

Story("s1") has (Gist("As a user I want..."), Status(ELICITED)),

Story("s1") requires Feature("f1"))

Metamodel:EntityRelationAttribute

To do … Hand in the introduction survey if not done it already Get the book (e.g. AdLibris) and the compendium (12:45 at the dep. SEK60) Read Lauesen Chapter 1 – a very important chapter of the book Exercise 1. Bring Lauesen’s book!!! Read about the project in course program (also on course web) Meet with your project group and get going as soon as possible Assign project management roles Extra first-week Lecture 2: Thursday 10-12 in E:B on Elicitation & Specification Project Mission before Friday 09:00 (see prev. instructions on email&subject) See mission examples for inspiration from previous years on the course web You get the week-end to study all Project Missions

♦ Arrive at a consensus in your group about a priority order of all missions♦ You get to choose in random order per project on Monday

You will be assigned a project supervisor by Monday♦ Book meeting time with your project supervisor for W2, W4, W6