Weekly notes

Meeting 1

• Er is wel budget. Om onderdelen te krijgen, moet je wel even duidelijk maken waarom je het nodig hebt (mooi praatje).
• Een idee om minder aandacht aan de constructie van de robot zelf te hoeven besteden is bijvoorbeeld uit lego lopende spinnen te maken.
• Als het meer gaat om de interactie, hoe belangrijk is dan het uiterlijk?

Doelen van de communicatie:

• Wat voor soort interactie willen we?
• Geruststellen / Spraakverbinding met hulpverlener

Andere vragen:

• Hoe autonoom willen we de robot? Kan bijvoorbeeld ook bestuurd worden door iemand met een camera.
• In dat geval speciale personen inzetten om met de robot de omgeving te analyseren. Die personen kunnen het goed inschatten.
• Warmte sensoren om personen te vinden
• Hoe volgt hij zijn pad? Hoe navigeert hij in een disaster area, want je kan hem geen route meegeven.
• Shared control

Nu 2 doelen:

• Het vinden van mensen in rampgebieden
• De interactie tussen robot en mensen

Kiezen wat haalbaar is in 7 weken.

Meeting 2

Persona:

• niet specifiek profiel voor een slachtoffer
  • pak een gemiddelde leeftijd, algemene behoeftes van een slachtoffer.
• Goed nadenken over welke verschillende invalshoeken een rol spelen
  • kijken naar literatuur, bijvoorbeeld over ervaringen van slachtoffers.
• Hulpverleners, nu iemand van de brandweer. Misschien ook nog een medisch persoon.
  • kan ook weer in de literatuur kijken

Design:

• hoe specifiek het wordt ligt aan onszelf.

Users:

• user analyse gekoppeld aan user needs
• kijken naar de wensen en problemen van onze users, dit ook meenemen in ons design.

• Probleem nog verder uitleggen
• systeem eisen
• requirements → die volgen uit wat de stakeholders nodig hebben.

Onze functies die we nu hebben uitgezocht nog meer focussen op de user. We zijn nu eigenlijk twee stappen tegelijk aan doen. We zijn al bezig met uitzoeken hoe we dus bijvoorbeeld slachtoffers moeten benaderen , met welk licht, etc. Maar we moeten eerst dus requirements stellen, om te kijken welke functies we willen. → we denken in feite al te veel vooruit.

To do: Eisen stellen, zodat we ons kunnen focussen. De wiki meer analytisch maken.

Conclusie: De eisen moeten we eerst algemeen opstellen vanuit de users, en vanuit daar kijken op welke eisen en functies we dus willen focussen. (voor ons dus uiterlijk, benadering etc.) Daarna kunnen we dus kijken naar welke functies me moeten uitkijken, wat we moeten uitzoeken in de literatuur etc.

Meeting 3

Requirements:

• Moeten ze nog SMART gedefinieerd worden?
  • Requirement moet inderdaad SMART zijn. We moeten duidelijker specificeren zodat het echt duidelijk is.
  • Lap tekst is goed om onze requirements te onderbouwen. Het is nuttig, maar nog niet heel overzichtelijk als je alleen naar de dikgedrukte delen kijkt.
  • Marges en waarden geven aan requirements, voor bijvoorbeeld requirement van tiny.
• Voor ons hebben we dus het onderscheid gemaakt in requirements van met welke we gaan werken en welke niet.