ETS170 Kravhantering - fileadmin.cs.lth.se

ETS170 Kravhantering

Lecture 2:

Elicitation: Lau:8Specification part 1:

Data reqts: Lau:2, Funtional reqts part 1: Lau:3.1-3.5

Course ombudsman volunteersInstructions on exam problem hand-ins

Björn Regnellhttp://www.cs.lth.se/ETS170

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 develpment), etc. Time & Materials – Utveckling på löpande räkning, rörligt pris Commercial Off-The-Shelf software purchase (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!

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

Level of detail, specification quality

The goal-design scale:Goal/Domain/Product/Design

Model(Goal("accuracy") has

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

Why?

Who?

What?

How?

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

Elicitation: [Lau:8]Get out there and dig up reqts!

”You cannot sit in your office and produce requirements based on intuition and logic. You have to discover the non-trivial requirements from users and other stakeholders.”

[Lausen, page 42]PROVOKING AN

UNDERSTANDING

Fig 1.6B Ask “why”

Neural diagnosticsSystem shall have mini keyboard with start/stop button, . . .Why?

Possible to operate it with “left hand”.Why?

Both hands must be at the patient.Why?

Electrodes, bandages, painful . . .

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

Deep domain knowledge is critical tosuccessful requirements engineering!!

Fig 1.6C Recommendation: why + how

Measuring neural response is a bit painful to the patient. Electrodes must be kept in place . . . So both hands should be at the patient during a measurement.

R1: It shall be possible to perform the commandsstart, stop, . . . with both hands at the patient.

Might be done with mini keyboard (wrist keys), foot pedal, voice recognition, etc.

Domain- why

Req.

Example- how


Why+How+Example

Model(Feature("navigate") has (

Why("Measuring neural response is a bit painful to the patient. Electrodes must be kept in place ... So both hands should be at the patient during a measurement."),

Spec("It shall be possible to perform the commands start, stop, ... with both hands at the patient."),

Example("Might be done with mini keyboard (wrist keys), foot pedal, voice recognition, etc.")

))

© Björn Regnell

DiscussionElicitation

Why is elicitation so challenging in real projects?

Fig 8.1 Elicitation issues

Should be simple.Ask stakeholders what they need!

Barriers:Cannot express what they needCannot explain what they do and whyMay ask for specific solutions

Lack of imagination - new waysLack of imagination - consequences

Conflicting demandsResistance to change

Luxury demandsNew demands once others are met

Things to elicit - intermediate work products:Present work, Present problemsGoals and critical issuesFuture system ideasRealistic possibilities

Consequences and risksCommitment, Conflict resolutionRequirements, PrioritiesCompleteness


Fig 8.2 Elicitation techniques

Pres

ent w

ork

Pres

ent p

robl

ems

Goals

& ke

y iss

ues

Futu

re sy

stem

idea

sRe

alist

ic po

ssib

ilities

Cons

eque

nces

&

Com

mitm

ent

Conf

lict r

esol

utio

nRe

quire

men

tsPr

iorit

iesCo

mpl

eten

ess

Stakeholder analysis(Group) interviewObservationTask demoDocument studiesQuestionnairesBrainstormFocus groupsDomain workshopsDesign workshopsPrototypingPilot experimentsSimilar companiesAsk suppliersNegociationRisk analysisCost / benefitGoal-domain analysisDomain-reqs analysis

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

Studier av & med (enskilda) intressenter eller dokument

Förberedda gruppaktiviteter

Exekvering av system

Avvägningar, risker, analys av kopplingar mellan nivåer

Nul

äge

Fram

tidÅ

taga

nde&

sam

syn

Kra

v &

der

as v

ärde

Omvärldsanalys

Stakeholder analysis (intressentanalys)

Example: In-house (internprojekt) Sponsors – want value for their money Users at different departments Managers at different departments Authorities, security managers, accountants etc. System management and support, Other indirect stakeholders that may provide valuable input

Example: product development: Distribution channels and retailers Solution providers building on your product Competitors

Interviews in requirements elicitationOn or more stakeholders are

interviewed by a requirements engineer (aka analyst)

Probably the most common elicitation method.

Reflect on pros and cons with ...• Individual or group interviews?• Structured: prepared questions

and perhaps also response alternatives

• Semi-structured: some Q prepared, but freedom in order and depth

• Unstructured: no preconceived closed questions; open questions to start off: “What is your view on the system?”

En eller flera intressenter tillfrågas av en kravingenjör.

Förmodligen den vanligaste metoden.För och nackdelar med… Enskilda eller gruppvisa intervjuer? Strukturerade:

förbestämda frågor, ev förbestämda svarsalternativ

Semi-strukturerade: vissa frågor är förberett men frihet i ordning och djup

Ostrukturerade: inga förberedda frågor alt. några få öppna frågor

”Berätta om din syn på systemet?”

Intervjuer för att elicitera krav

Fig 8.4 Focus groups

• Several stakeholder groups• Brainstorm - bad experience• Brainstorm - wishes & ideal future• Each group selects top ten issues• A few days later: Decide. • Each group must get something


Concrete example in Lau:10.2

Fig 8.5 Business goals

Shipyard goals. Business administrationA1. Replace outdated platformA2. Integrate order documents and databaseA3. Use experience data for quotationA4. Support systematic marketingA5. Faster capture of cost dataA6. Speed up invoicing

Hospital goals. Payroll and roster planningB1. Reduce IT costsPersonnel departmentB2. Automate some tasksB3. Remove error sourcesB4. Observe deadlinesB5. Less trivial work and less stressHospital departmentB6. Reduce over- and undertime paymentB7. Faster roster planningB8. Improve roster quality

Noise source location. New productD1. Marketing plan.

Demand, competitors ...

P

D

Q

P

D

Q


Fig 8.6 Cost/benefit analysis

Shipyard NPV Y0 Y1 Y2 Y3 Y4Hard benefits m$Avoided losses 6.5 0.2 1.0 4.0 4.0More orders 2.5 0.4 1.0 1.0 1.0Hard costsSupplier’s price -0.4 -0.4Hardware -0.6 -0.6Staff training -0.3 -0.3Enter exp. data -0.4 -0.1 -0.1 -0.1 -0.1 -0.1Net value 7.3 -1.4 0.5 1.9 4.9 4.9

Soft factors Now FutureIT flexibility 0 3Customer comm. 3 4Stress absence 1 3Total points 4 10 (S

cale

0-5

)


Fig 8.7A Goal-domain tracing - critical areas

Replace IT platformIntegrate doc and dataExperience dataSystematic marketingCapture cost dataSpeed up invoicing

Mark

etin

gQu

otat

ion

Prod

.plan

ning

Cost

regi

str.

Invo

icing

. . .

Payr

oll

IT o

pera

tions

Usab

ility

Resp

onse

tim

e

Goal requires improvement inthis work area or quality area

= This work area / quality factoris critical for this goal

• För varje affärsmål: Vilka subdomän säkerställer måluppfyllnad?

• För varje subdomän:Vad är dess syfte i relation till affärsmålen?

Fig 8.8 Quality-issue analysis

Example: Shipyard, usability

Issue: Job calculation easy to learn.

Style: Task time.

Req. outline: After xx hour course, marketing staff can perform task yy in zz minutes.

Req., final: After ___ hour course, marketing staff can calculate proposal B in ___ minutes. Customer expects 12 hour course.

How can we tell?

How can wemeasure it?

What are xx,yy, and zz?


Att gå från domän till krav

In practice you need to iterate and work in parallel

Elicitation

Specification

Validation

Prioritization

Specifying functional requirements

Overview of techniques for functional requirements (Swedish terms)Datakravstilar:Datamodell ( =E/R-diagr.)DataordlistaReguljära uttryckVirtuella fönster

Funktionella kravstilar:KontextdiagramHändelse- & FunktionslistorProduktegenskapskravSkärmbilder & PrototyperUppgiftsbeskrivningarEgenskaper från uppgifterUppgifter och stöd(Levande) ScenarierHögnivåuppgifterAnvändningsfallUppgifter med dataDataflödesdiagramStandardkravKrav på utvecklingsprocessen

Funktionella detaljer:Enkla och sammansatta funktionerTabeller & BeslutstabellerTextuella processbeskrivningarTillståndsdiagramÖvergångsmatriserAktivitetsdiagramKlassdiagramSamarbetsdiagramSekvensdiagram

Speciella gränssnittRapporterPlattformskravProduktintegrationTekniska gränssnitt

First read the ”gray box” of all styles so that you understand what they are about and their pros and cons. Then read in depth as needed.

All techniques have + and -depending on the context

When is a specific style good?

The answer depends on… abstraction level project type the stakeholders tool support the amount of requirements…

Use a well-balanced combination!…but how do you know that it all fits together? -> checking consistency is an important part of validation!

Data requirements

Data model (e.g. E/R-diagrams) Data dictionary Data expressions Virtual windows

Example data from the mobile domain:Subscriber data, roaming data, phone book data, image data (when, resolution, name, category), music data (album, artist, genre, name, frequency played, rating), etcetera

Data requirements techniques – SummaryData model (E/R-diagr.)

♦ Block diagram describing data inside and outside the product♦ Precise and insensitive to abstraction level♦ Excellent for experts – difficult for users; takes time to learn♦ Easy to verify by experts that the data is handled by the product♦ Difficult to decide how much detail should be included in the model

Data dictionary♦ Textual description of data inside and outside the product♦ Structured and systematic descriptions using verbal text♦ Very expressive, can be used for all levels of detail and special cases♦ Easy to validate by experts and non-experts♦ Takes long time to write; when is it good enough? (Start with difficult parts!!)

Data expressions (regular expressions)♦ Compact formulas for describing data sequences♦ Useful for composite data and message protocolls♦ Excellent for experts, acceptable for many users♦ No visual overview

Virtual windows♦ Simplified screens with graphics and realistic data, but no buttons and menues♦ Excellent for both experts and users♦ Easy to validate and verify♦ Risk of overdoing it and start designing the user interface

passport number = letter + {digit}*8room state = { free | booked | occupied | repair }account data = transfer + {account record}* + done

Fig 2.1 The hotel system

Task listBook guestCheckinCheckoutChange roomBreakfast list &other services

Data aboutGuestsRoomsServices


Fig 2.3 Data dictionary

Class: Guest [Notes a, b ... refer to guidelines]The guest is the person or company who has to pay the bill. A guest has one or more stay records. A company may have none [b, c]. “Customer” is a synonym for guest, but in the database we only use “guest” [a]. The persons staying in the rooms are also called guests, but are not guests in database terms [a].

Examples1. A guest who stays one night.2. A company with employees staying now and then, each of them with his own stay

record where his name is recorded [d].3. A guest with several rooms within the same stay.

Attributesname: Text, 50 chars [h]

The name stated by the guest [f]. For companies the official name since the bill is sent there [g]. Longer names exist, but better truncate at registration time than at print out time [g, j].

passport: Text, 12 chars [h]Recorded for guests who are obviously foreigners [f, i]. Used for police reports in case the guest doesn’t pay [g] . . .


Data dictionary example

Lau: fig 2.3

Fig 2.2A Data model (E/R-diagram)

R2: The system shall store the following data:

Stay

RoomState

Room

Service ServiceType

date, #persons,state (booked|occupied|repair)

name, address1, address2, address3, passport

room#,#beds, typeprice1, price2

name, price

date, count

Guest

stay#,paymethod,employee

Stays

Guests

One-to-many (1:m)Each guest connected to zero or more stays

Each stayconnected to one guest record

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

Entities and RelationshipsCardinality of relationshttp://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

Fig 2.4A Data expressions

Notation with plus as concatenator

booking request = guest data + period + room type

guest data = guest name + address + paymethod+ [passport number]

passport number = letter + {digit}*8

room state = { free | booked | occupied | repair }

account data = transfer + {account record}* + done


Fig 2.5 Virtual Windows

R1: The product shall store data corresponding to the following virtual windows:

R2: The final screens shall look like the virtual windows ??

Rooms 7/8 8/8 9/8 10/811 Double Bath 800 600 O B12 Single Toil 600 O O B B13 Double Toil 600 500 B B B

Service charges

Breakf. rest. 40Breakf. room 60. . .

Stay#: 714GuestName: John SimpsonAddress: 456 Orange Grove

Victoria 3745Payment: Visa

Item #pers7/8 Room 12, sgl 1 6008/8 Breakf. rest 1 408/8 Room 11, dbl 2 8009/8 Breakf. room 2 1209/8 Room 11, dbl 2 800

Breakfast 9/8In In

R# rest room11 212 113 1 1


Course ombudsmen –volunteers?• A course ombudsman collects experiences and improvement

suggestions during the course and gives this feedback to the teachers

• Any course member are encouraged to talk to the teachers about how the course work!

• When the Course Experience Questionnaire (CEQ) is ready, the two ombudsmen meets with the course head and discusses the working report and writes a short summary.

• D och eller C:are och någon/några från annat program? • ???

http://www.dsek.lth.se/sektionen/srd/kursombud/

Functional Requirements Part 1 Summary

Context Diagram♦ Diagram of product and its surrounding♦ Defining product scope♦ Very useful!

Event- and function lists♦ Lists of events and functions

Domain or product level♦ Good as checklists at verification♦ Validation at product level?

Feature requirements♦ Textual requirement: ”the product shall …”♦ High expressive power♦ Acceptable to most stakheolders♦ Can lead to false sense of security

How to ensure that goal-level covered?

Screens and Prototypes♦ Screen pictures + what buttons do♦ Excellent as design-level requirements

if carefully tested♦ Not good when for COTS-based systems

Hotelsystem

Guest

Accountsystem

confirmation,invoice

booking,checkout,service note,. . .

Recep-tionist

Telephonesystem

R1: The product shall support the following businessevents / user activities / tasks:

R1.1 Guest booksR1.2 Guest checks inR1.3 …

R1: The product shall be able to record that a room is occupied for repair in a specified period.

R2: The product shall ….

R3: The product shall ….

Fig 3.1 Human-computer - who does what?

guest’swishes

Rooms

guest name

User Product

choice

period+room typeFindFreeRoom

free rooms

chosen room#

FindFreeRoom

guest’swishes

Roomsguest name+ chosen room#

Physical model:work split

Domain model:parties joined


Hotelsystem

Guest

Accountsystem

Fig 3.2 Context diagram

confirmation,invoice

booking,checkout,service note,. . .

R1: The product shall have the following interfaces:

Hotelsystem

Guest

Accountsystem

AccountantWaiter

R2 ??:The reception domain communicates with the surroundings in this way:

Reception

Recep-tionist Telephone

system


Recep-tionist

Fig 3.3 Event list & function list

R1: The product shall support the following businessevents / user activities / tasks:

R1.1 Guest booksR1.2 Guest checks inR1.3 Guest checks outR1.4 Change roomR1.5 Service note arrives

. . .

Product eventsDomain events(business events)

Domain-product:many-to-many

R2: The product shall handle the following events / The product shallprovide the following functions:User interface:R2.1 Find free roomR2.2 Record guestR2.3 Find guestR2.4 Record bookingR2.5 Print confirmationR2.6 Record checkinR2.7 CheckoutR2.8 Record serviceAccounting interface:R2.9 Periodic transfer of account

data. . .


Fig 3.4 Feature requirements

R1: The product shall be able to record that a room is occupied for repair in a specified period.

R2: The product shall be able to show and print a suggestion for staffing during the next two weeks based on historical room occupation. The supplier shall specify the calculation details.

R3: The product shall be able to run in a mode where rooms are not booked by room number, but only by room type. Actual room allocation is not done until checkin.

R4: The product shall be able to print out a sheet with room allocation for each room booked under one stay.

In order to handle group tours with several guests, it is convenient to prepare for arrival by printing out a sheet per guest for the guest to fill in.


Feature =product function + related data

What is a ‘feature’?

Some possible definitions:1. A textual shall-statement requirement2. A releasable characteristic of a (software-

intensive) product3. A (high-level, coherent) bundle of

requirements4. A ‘decision unit’ that can be ‘in’ or ‘out’ of a

release plan depending on:♦ What it gives (investment return)♦ What it takes (investment costs)♦ Politics, Beliefs, Loyalties, Preferences ...

Fig 3.5A Screens & prototypes

R1: The product shall use the screen pictures shown in App. xx.

R2: The menu points and buttons shall work according to the process description in App. yy.Error messages shall have texts as in . . .

R3: Novice users shall be able to perform task tt on their own in mm minutes.

The customer imagines screens likethose in App. xx. Makes sense?


Fig 3.5A Screens & prototypes

R1: The product shall use the screen pictures shown in App. xx.

R2: The menu points and buttons shall work according to the process description in App. yy.Error messages shall have texts as in . . .

R3: Novice users shall be able to perform task tt on their own in mm minutes.

The customer imagines screens likethose in App. xx. Makes sense?


Design("screen1") has Image("screen1.png")

Appendix xx. Required screens

Fig 3.5B Screens & prototypes

Appendix yy. Required functions

Stay windowBook:. . .Checkin:If stay is booked, record the

booked rooms as occupied.If stay is not recorded,

Check selected rooms free and guest information complete.Record guest and stay. Record selected rooms as occupied.

If stay is checked in, . . .


Del 1 på Tentan: Påstående-anledning-frågor

För varje par av påstående/anledning svara med ett av följande alternativ:A: Både påståendet och anledningen är korrekta uttalanden OCH

anledningen förklarar påståendet på ett korrekt sätt.B: Både påståendet och anledningen är korrekta uttalanden, men

anledningen förklarar inte påståendet.C: Påståendet är korrekt, men anledningen är ett felaktigt uttalande.D: Påståendet är felaktigt, men anledningen är ett korrekt uttalande.E: Både påståendet och anledningen är felaktiga uttalanden.

Påstående Anledning SvarVirtuella fönster passar bra för att beskriva icke-funktionella krav.

Virtuella fönster är en bra hjälp vid validering av fullständighet av datakrav.

Kontextdiagram är en bra hjälp för att upptäcka saknade gränssnitt och diskutera vad som ska levereras.

Ett kontextdiagram ger en lättbegriplig översikt av systemets avgränsning och dess aktörer.

D

A

Part 1 of the written exam: Proposition-reason-pairsFor each pair of proposition-reason statements answer one of the following:A: Both the proposition and the reason are correct statements,

AND the reason explains the proposition in a correct way. B: Both the proposition and the reason are correct statements,

BUT the reason does not explain the proposition.C: The proposition is true, but the reason is false.D: The proposition is false, but the reason is a true statement.E: Both the proposition and the reason are false.

Proposition Reason AnswerVirtual windows are good for describing non-functional requirements.

With virtual windows, it is easy for users to validate if data requirements are complete.

With a context diagram it is easy for customers to identify missing interfaces and discuss what should be included in the system.

A context diagram gives an easy to understand overview of interfaces and describes the borders of the system and its actors.

D

A

Why should you propose exam problems?

Focus on the learning objectives Demands deeper understanding Learning in groups Demands ability to assess different solutions Stimulate literature penetration during the

course instead of at the end

What is a good exam problem?

Relates to one or more of the learning objectives in the course program,

Requires deep understanding, Is not easier if you have photographical memory Connects different parts of the theory

Plagiarism is not allowed; create new variants, compared to previous exams and hand-ins on the course web

Each problem shall have a literature reference and a motivation

Your group’s two hand-ins shall together give a good coverage of important parts of the course literature

Your exam problems should cover these theory partsHand-in W46-8 problems (one per person)that cover:• [Lau:1] 1-2 problems• [Lau:2] 1-2 problems• [Lau:3,4] 2 problems• [Lau:8] 2 problems

Hand-in W66-8 problems (one per person)that cover:• [Lau:5,7] 1 problem• [Lau:6, QUPER] 2 problems• [Lau:9, INSP] 1-2 problems• [MDRE+PRIO+RP] 1-2 problems• [AGRE+INTDEP] 1 problem

Suggestion: Everyone in the project makes an individual proposal for each area above. Then you all meet and discuss which problems are best and select/merge problems. You can also exchange feedback with your customer group.

Template example

Problem 8: Virtual WindowsProposition: Virtual windows are good for describing non-functional requirements.Reason: With virtual windows, it is easy for users to validate if data requirements are complete.Correct answer: D (Proposition is false, but the reason is a true statement.)Motivation: The proposition is false as virtual windows are aimed for describing data requirements and are not suitable for describing quality requirements. The reason is a true statement as virtual windows includes concrete examples of data from the domain and is thereby easier to understand by also others than computer scientists (compare e.g. with data models as E/R diagrams). This in turn makes it easier for users and customers to assess if the requirements are correct. Reference: Lau: Chapter 2 pages 66, 69, 54Learning objective: 2, 3Main responsible: <One person in the group>

Mall+exempel för inlämning

Fråga 12. Virtuella fönsterPåstående: Virtuella fönster (eng. virtual windows) passar bra till att beskriva icke-funktionella krav.Anledning: Det är lätt för kunder att med virtuella fönster validera om beskrivningar av data är fullständiga.Rätt svar: D (Påståendet är felaktigt, men anledningen är ett korrekt uttalande)Motivering: Påståendet är falskt eftersom virtuella fönster är till för att beskriva datakrav och passar dåligt för kvalitetskrav. Anledningen är sann eftersom virtuella fönster innehåller konkreta exempel på data och är därmed mer lättbegripliga för icke-datatekniker (jämfört med t.ex. datamodeller i form av E/R-diagram), vilket i sin tur underlättar för kunderna att avgöra om det är rätt krav.Litteraturhänvisning: Lau: 2 sid 66, 69, 54Inlärningsmål: 2, 3Huvudansvarig: <En person i gruppen>

Hand-in of exam problems (optional)Via email to (all of these) [email protected] [email protected] [email protected] [email protected]

Wednesdays W4 and W6 - latest by midnight for a chance of bonus (max 5+5p) One .pdf file per hand-in The file must be named <groupletter>Q<1|2>.pdf The email must have exactly this form of subject:[ETS170] Group A, Exam Q1 dat14xyz, elt12abc, ada13ijk, adi13efd, ...

/* Note: Q1 without space and stil ID of all group members */

<<Attachment: AQ1.pdf>>

Lab sign-up list now available

Link on lab session page of cs.lth.se/ets170

Click here

- Sign up using your stil id- If you want a specific lab partner, SIGN-

UP TOGETHER

Problems? Contact [email protected]

Then selectsession

To Do Read Lau:8, Lau:2,3.1-3.5 Project Mission (PM) deadline tomorrow 0900 Study all PM over the weekend and make a complete

priority order Discuss in each project your ambitions and how you

would like to work, solve conflicts, etc. Lecture 3 on Monday with project mission selection.

Each project must be represented. Tutorial on reqT and Scala next Thursday 10-12

Preparations: download and run "hello reqT" See instructions at http://cs.lth.se/ets170/reqthttp://reqt.org/documentation.html#hello

Documents

ETS170 Kravhantering - fileadmin.cs.lth.se