Opstellen software requirements voor een software pakket

[Verwijderd]

Hoi,

Ik moet voor school een opdracht uitvoeren, deze opdracht luid als volgt:

Opstellen van eisen en wensen met betrekking tot een call management systeem als vervanging van het huidige product.
Het idee erachter is dat een bedrijf dit softwarepakket wil gaan vervangen door een extra module te programmeren in het door hun zelf geschreven pakket. Door middel van gebruikers interviews moet ik de eisen en wensen naar boven krijgen.
De aanpak waar ik aan zit te denken:

1. User interviews (naar voren krijgen wat de eisen / wensen zijn van het pakket)
2. Schiften in de de naar voren gekomen eisen / wensen (dmv MoSCoW)
3. Onderverdeling maken in de eisen en wensen (functionele eisen / technische eisen / layout eisen ed.)
4. Eindrapportage

De problemen waar ik een beetje tegen aan loop zijn o.a. het opstellen van de user interviews. Ik kan moeilijk vragen: ,,Wat vind je belangrijk aan het pakket?" Hetl ijkt me dus verstandig om punt 3 al van te voren goed duidelijk te hebben. Ik weet alleen zo snel niet meerdere types eisen. Zijn er mensen die me hiermee opweg kunnen helpen zodat ik goede interview vragen kan gaan opstellen?

Alvast bedankt!

[Cis]

Begin met te vragen waarom ze het huidige pakket willen vervangen. Als je daar secuur in bent, kun je voor een groot gedeelte achterhalen van de basisfunctionaliteit van de nieuwe module moet zijn.

Edit: Antwoorden als "Het werkt niet lekker" zijn natuurlijk geen antwoorden en daar moet je op doorvragen. Als het antwoord is: "Ik moet teveel klikken", weet je dus dat je meer automatisch moet laten doen. Het nieuwe systeem moet dus een soort intuitie krijgen

[ Voor 40% gewijzigd door Cis op 05-09-2006 23:53 ]

[Garyu]

Tsja, een user interview geeft je altijd biased antwoorden, waar je waarschijnlijk nog steeds niet zoveel mee kan. Voor een goede user analyse ben je dan ook aardig wat tijd kwijt.

Daar heb je waarschijnlijk geen tijd voor / zin in, maar wat je bijvoorbeeld kan doen is een paar gebruikers bij elkaar zetten en zelf de discussie leiden. Op die manier kunnen ze elkaar aanvullen.

Interview mensen direct op hun werkplek.

etc.

[MicroWhale]

Het gaat er denk ik meer om dat je uit de user-interviews een proces haalt wat eenduidig is en makkelijk te doorlopen. In dit proces moet de software een begeleidende en ondersteunende functie hebben. Dit hogere abstractienivo is belangrijk bij het opstellen van de nieuwe wensen/eisen.
Als er al een procedure is voor het afhandelen van een telefoontje, dan kan dit een goede leiddraad zijn om mee te beginnen. Welke onderdelen uit deze procedure moeten vastgelegd worden, hoe staan ze met elkaar in relatie en hoe heeft de medewerker ze nodig? Zijn er onderdelen die nu nog niet vastgelegd worden? Zo ja, welke? etc...

[QBiT]

Zoals al eerder gezegd lijkt het me handig om het behapbare stukjes op te delen. Bijvoorbeeld per proces wat met het systeem te maken heeft. Vervolgens vraag je de gebruiker om gewoon te laten zien wat hij bij het betreffende proces precies voor handelingen doet. Dan kan je vragen wat hij/zij makkelijk vind aan deze handelingen, of juist onhandig.

Dan kan je een prototype maken van het systeem. Of wat simpele schermontwerpen. Dan stap je weer naar de gebruiker toe, en vraag je hem wat hij van die procedure vindt. Dit proces kan je natuurlijk een paar keer herhalen.

Daarnaast is het belangrijk om controle vragen te stellen. Ook open vragen zijn erg belangrijk om mensen geen antwoorden in hun mond te leggen.

[Verwijderd]

Ik denk dat ik ga proberen om de methode Volere te gebruiken. Iemand ervaring mee?

[Piels]

Zoals QBit zegt, maak eens een prototype en ga daarna weer terug naar de gebruiker.
Het zogenaamde waterfall model.

Maar het belangrijkste is gewoon dat je erachter ziet te komen wat de gebruikers willen en waarom. Het opstellen van requirements is vooral bedoelt om de grenzen van het te ontwikkelen product af te bakenen.
Doe je dit niet goed, kun je achteraf voor verrassingen te komen staan. Terwijl als je je requirements goed opstelt dan weet je precies wat er wel en wat er niet in het te ontwikkelen product komt.

Maar het opstellen van de eisen aan de hand van MoSCoW is een goede aanpak.

[Verwijderd]

MoSCoW en waterval is niet echt een lekkere combinatie. MosCoW wordt veel gebruikt bij ontwikkelmethodes als DSDM die een heel andere insteek hebben als de waterval methode. De watervalmethode is een methode voor softwareontwikkeling,waarin de ontwikkeling regelmatig vloeiend naar beneden loopt.

Bij DSMD zijn alleen de duur van het project en de te gebruiken resources worden vastgelegd. Dit betekent dus dat juist de specificaties die gerealiseerd zullen gaan worden, in het verloop van het project kunnen variëren. In het begin van het project worden op globaal niveau zowel de functionele- als de niet-functionele specificaties ingedeeld op prioriteiten (MoSCoW). Tijdens de ontwikkeling komen steeds meer gedetailleerde specificaties boven water. Deze gedetailleerde specificaties worden vervolgens ook weer op basis van prioriteiten ingedeeld.

[BikkelZ]

Je kunt ook bij users testen of zij ook de gaten zien die jij ziet in het huidige systeem, en wat hun idee is bij jouw ideeën, nadat je ze eigenlijk eerst hun eigen visie hebt laten geven zonder sturing. Mensen zijn natuurlijk wel geneigd heel erg kortzichtig te zijn met sommige dingen omdat het nou eenmaal geen Informatici zijn, dus je moet wel weten wat je gaat vragen.

Want ik heb meegemaakt dat iemand die continu liep te schelden dat data x in excelsheet y wel aangepast was en in excelsheet z niet aangepast was, maar desondanks bij hoog en laag beweerde geen behoefte te hebben aan een centraal systeem. Want het probleem lag niet in het huidige systeem, maar in die eikels die niet wisten hoe ze het moesten gebruiken.

Maar aan de andere kant kan het gebeurend dat als je ze een denkbeeldige toekomst voorschetst, dat dan de radertjes gaan draaien en ze met je mee gaan denken, en met dingen aankomen waar jij niet aan gedacht had.

[Verwijderd]

Een methode die goed werkt om de eisen van gebruikers vast te leggen is de zogenaamde Use Cases. Het eerste dat je doet zijn de mensen en systemen bepalen die iets met het systeem doen, die noem je de 'actors'. Bij een pin-automaat zijn dat bijvoorbeeld:

- Rekeninghouder
- Brinkxs (of hoe heet die club die het geld bijvuld)
- Het rekeningsysteem van de bank

Vervolgens beschrijf je de use cases. Iedere use case is één duidelijke actie die een gebruiker met het systeem doet, en iets nuttigs voor de gebruiker bezorgt. Dus in het voorbeeld zoiets als:

Rekeninghouder:
- Geld opnemen
- Bedrag op rekeing bekijken
- Pinpas activeren

Brinkxs:
- Geld bijvullen

Dat soort dingen. Let op: strikt genomen is je aanmelden (met je pinpas) geen use case, omdat je daarmee nog niks nuttigs voor de gebruiker behaalt. Hij doet dit alleen omdat hij een van die andere zaken wil bereiken. Als het je goed uitkomt om zoiets er toch bij te zetten: break the rules!

Zoek er maar eens iets over op. De tekeningen die je gebruikt om het e.e.a. te modelleren heten UML, of Unified Modelling Language.

In je interviews kun je dan vragen: welke dingen wil je met het systeem voor elkaar krijgen, welk probleem heb je nu, dat het systeem moet oplossen?