Het verzamelen van softwareeisen ten aanzien van beginnende bedrijfsanalisten

Gepost op 8 Maart, 2007 in 9:21 am

Het werken als BedrijfsAnalist voor de laatste 4 jaar heeft me een paar dingen over het verzamelen van gebruiker onderwezen en softwarevereisten dat ik dacht zou ik delen! Er zijn een paar dingen u in mening moet doen en houden wanneer u probeert om een systeem of een toepassing voor een bepaalde reeks gebruikers te ontwerpen:

1. Wat de gebruiker vraagt om kan niet zijn precies wat zij willen! Zij kunnen u vragen om X, Y te doen, en indien Z omdat dat dingen een gemakkelijker zal maken, maar als u enkel doorgaat en dat blind doet, zal u vinden meer dan waarschijnlijk dat later op de gebruikers zal klagen en zal zeggen dat het op de best mogelijke manier of de manier het „niet werkt“. om te berekenen wat de gebruikers WERKELIJK nodig hebben moet u met hen gaan zitten en LETTEN op terwijl zij werken. De vergaderingen zijn groot en zij zullen proberen om te herinneren hoe zij doen dingen (50% van het materiaal dat zij zich niet zij zal herinneren) en geven u één of andere scheefgetrokken mening van hun werk. Niet dat zij dit op doel doen, maar zodra u gaat ga zitten en zie hoe de mensen werken, zult u vinden er ton van klein weinig is, maar importants de stappen geen die zij dachten waren vermeldend de moeite waard! Zodra u de stroom met uw eigen ogen ziet, dan ga zitten met iedereen en hebben een vergadering over wat zij willen en WAAROM.

2. Vraag altijd WAAROM de mensen dingen de manier doen zij… u zijn zullen vinden gewoonlijk dat sommige problemen enkel kunnen worden opgelost door iemand te vertellen om het te doen een andere manier! Iemand anders vertelde Persoon X om het te doen deze manier en zo nu houden zij enkel doend het dat manier alhoewel het proces kan veranderd zijn! De mensen houden niet van te veranderen, zelfs als het voor hen goed is! Wanneer u begint te vragen waarom, de mensen eigenlijk over het zullen beginnen te denken en voor zich kunnen berekenen dat zij tijd verspillen of het op een ingewikkelde manier doen die niet noodzakelijk is.

3. Probeer altijd om een algemene mening eerste te krijgen! De mensen zullen onmiddellijk u over dit probleem met deze bepaalde eigenschap beginnen te vertellen of deze stap in het proces, enz., enz., maar u wilt aan eerst krijgt een duidelijk inzicht in het volledige proces van een hoger niveau. Als u net in de details wordt, zult u omhoog beëindigen makend software of een proces die overdreven zouden kunnen worden gecompliceerd! Het is verbazend hoeveel keer ik processen heb bekeken en bepaald dat de volledige stap kan worden overbodig gemaakt!!! Probeer altijd om het GROTE PERSPECTIEF te krijgen!

4. Zorg aan document alles ervoor, zodat denken de mensen niet u tijd verspilt. If you’re spending a lot of time with the people who actually do the work (which you should), then make sure you write everything down because you don’t want your boss to think you’re not getting anything done! It’ll also be easier to convince others that your solution is the best solution if you have lots of supporting evidence on paper.

5. Get sign off from all the top people, plus the users! If management wants it one way and users want it another way, those issues need to be resolved quickly and jointly! Don’t ever say you’ll do one thing before making sure it’s ok with the boss. Otherwise you’ll have to backtrack on your promise and people will get annoyed!

6. Lastly, but MOST IMPORTANTLY, TEST TEST TEST!!! Write out test scripts and test cycles. Don’t have to do anything fancy, use Excel to write it out. One column for the particular feature or function you are testing, one column for the expected outcome, one column for the inputs and one column for the expected outputs. You should always have expected inputs and outputs. And try to use varied data sets, small sets, large sets, and sets you know will cause errors (but hope to catch).

Hope this helps!

If you enjoyed this post, make sure you subscribe to my RSS feed!

» Filed Under IT Job Stuff