Weekly notes: Difference between revisions
(Created page with ''''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 co…') |
No edit summary |
||
Line 21: | Line 21: | ||
Kiezen wat haalbaar is in 7 weken. | 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. |
Revision as of 11:19, 25 February 2019
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.