Συλλογή των απαιτήσεων λογισμικού για τους αρχίζοντας επιχειρησιακούς αναλυτές

Ταχυδρομημένος στις 8 Μαρτίου 2007 στις 9:21 AM

Η εργασία ως επιχειρησιακός αναλυτής για τα τελευταία 4 έτη μου έχει διδάξει μερικά πράγματα για τη συλλογή του χρήστη και απαιτήσεις λογισμικού ότι σκέφτηκα θα μοιραζόμουν! Υπάρχουν μερικά πράγματα που πρέπει να κάνετε και να λάβετε υπόψη όταν προσπαθείτε να σχεδιάσετε ένα σύστημα ή μια εφαρμογή για ένα ιδιαίτερο σύνολο χρηστών:

1. Τι ο χρήστης ρωτά για μπορεί να μην είναι ακριβώς αυτό που θέλουν! Μπορούν να σας ζητήσουν για να κάνουν το Χ, το Υ, και το Ζ επειδή αυτός θα καταστήσει τα πράγματα πολύ ευκολότερα, αλλά εάν προχωράτε ακριβώς και κάνετε αυτό τυφλά, περισσότερο από πιθανώς θα διαπιστώσετε ότι αργότερα οι χρήστες θα παραπονεθούν και θα πουν ότι δεν το λειτουργεί με τον καλύτερο δυνατό τρόπο ή τον τρόπο «εάν». Προκειμένου να υπολογιστεί τι οι χρήστες χρειάζονται ΠΡΑΓΜΑΤΙΚΑ, πρέπει να καθίσετε με τους και ΝΑ ΠΡΟΣΕΞΕΤΕ ενώ λειτουργούν. Οι συνεδριάσεις είναι μεγάλες και θα προσπαθήσουν να θυμηθούν πώς κάνουν τα πράγματα (50% της ουσίας δεν θα θυμηθούν ότι) και σας δίνουν κάποια στρεβλωμένη άποψη της εργασίας τους. Όχι ότι κάνουν αυτό στο σκοπό, αλλά μόλις πάτε καθίστε και δείτε πώς οι άνθρωποι εργάζονται, θα βρείτε ότι υπάρχουν τόνοι μικρού λίγα, αλλά importants τα βήματα που δεν σκέφτηκαν άξιζαν! Μόλις δείτε τη ροή με τα μάτια σας, κατόπιν καθίστε με το καθένα και διοργανώνει μια συνεδρίαση για αυτό που θέλουν και ΓΙΑΤΙ.

2. Πάντα ρωτήστε ΓΙΑΤΙ οι άνθρωποι κάνουν τα πράγματα ο τρόπος που είναι… συνήθως εσείς θα διαπιστώσουν ότι μερικά προβλήματα μπορούν ακριβώς να λυθούν με στην αφήγηση σε κάποιου για να το κάνουν ένας άλλος τρόπος! Κάποιος άλλος ειπωμένο πρόσωπο Χ για να το κάνουν αυτός ο τρόπος και τόσο τώρα συνεχίζουν ακριβώς το ότι τρόπος ακόμα κι αν η διαδικασία μπορεί να είχε αλλάξει! Οι άνθρωποι δεν επιθυμούν να αλλάξουν, ακόμα κι αν είναι καλοί για τους! Όταν αρχίζετε γιατί, οι άνθρωποι θα αρχίσουν να σκέφτονται πραγματικά για το και μπορούν να υπολογίσουν για τους ότι σπαταλούν το χρόνο ή το κάνουν με έναν περίπλοκο τρόπο που δεν είναι απαραίτητος.

3. Πάντα προσπαθήστε να πάρετε μια γενική άποψη πρώτος! Οι άνθρωποι θα αρχίσουν αμέσως να λένε σε σας για αυτό το πρόβλημα με αυτό το ιδιαίτερο χαρακτηριστικό γνώρισμα ή αυτό το βήμα στη διαδικασία, κ.λπ., κ.λπ., αλλά θέλετε κατανοείτε αρχικά σαφής της ολόκληρης διαδικασίας από έναν υψηλότερου επιπέδου. Εάν πάρετε δεξιά στις λεπτομέρειες, θα καταλήξετε το λογισμικό ή μια διαδικασία ότι η δύναμη είναι υπερβολικά περίπλοκη! Είναι καταπληκτικό πόσες φορές έχω εξετάσει τις διαδικασίες και έχω καθορίσει ότι το ολόκληρο βήμα μπορεί να αποβληθεί!!! Πάντα προσπαθήστε να πάρετε τη ΜΕΓΑΛΗ ΠΡΟΟΠΤΙΚΗ!

4. Σιγουρευτείτε στο έγγραφο όλα, έτσι οι άνθρωποι δεν σκέφτονται ότι σπαταλάτε το χρόνο. 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