ETS170 Kravhantering Lecture 2: Elicitation: Lau:8 Specification part 1: Data reqts: Lau:2, Funtional reqts part 1: Lau:3.1-3.5 Course ombudsman volunteers Instructions on exam problem hand-ins Björn Regnell http://www.cs.lth.se/ETS170
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
)
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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?
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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] . . .
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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. . .
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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.
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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?
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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?
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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, . . .
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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