Κέρδη:
- Ικανότητα διάκρισης λειτουργικών και μη λειτουργικών απαιτήσεων και γραφής σαφών, μετρήσιμων εκφράσεων απαιτήσεων με την υποστήριξη της τεχνητής νοημοσύνης
- Δυνατότητα χρήσης τεχνητής νοημοσύνης με δομημένες προτροπές για εξαγωγή ιστορίας χρήστη, κριτηρίων αποδοχής και ορίου πεδίου από σημειώσεις συνέντευξης
- Συνήθεια να ελέγχει τις απαιτήσεις που δημιουργούνται από την τεχνητή νοημοσύνη για ασάφεια, αντιφάσεις και κανόνες που λείπουν και να τους επιβεβαιώνουν με τους ενδιαφερόμενους
Η ανάλυση απαιτήσεων είναι το έργο του καθορισμού με πλήρη, σαφή και επαληθεύσιμο τρόπο τι πρέπει να κάνει ένα σύστημα. Είναι ένα από τα στάδια όπου ο ειδικός του MIS παράγει τη μεγαλύτερη αξία. γιατί ένα λάθος εδώ μεγαλώνει εκθετικά στο τέλος του έργου. Υπάρχουν δύο βασικοί τύποι ανάλυσης απαιτήσεων. Η λειτουργική απαίτηση περιγράφει τη δουλειά που πρέπει να κάνει το σύστημα: «Το σύστημα θα πρέπει να στείλει email στον πελάτη όταν επιβεβαιώσει την παραγγελία». Η μη λειτουργική απαίτηση περιγράφει πώς πρέπει να είναι το σύστημα: ιδιότητες όπως απόδοση, ασφάλεια, χρηστικότητα και προσβασιμότητα. "Η οθόνη αναφοράς θα πρέπει να ανοίγει σε λιγότερο από 2 δευτερόλεπτα με μέσο φορτίο" είναι μια μη λειτουργική απαίτηση.
Μια καλή απαίτηση έχει τρία χαρακτηριστικά: είναι σαφής (έχει μια ενιαία ερμηνεία), είναι μετρήσιμη (έχει ελεγχόμενο όριο) και είναι ανιχνεύσιμη (είναι σαφές από ποια επιχειρηματική ανάγκη προέρχεται). "Το σύστημα πρέπει να είναι γρήγορο" δεν πληροί κανένα από αυτά. Το "γρήγορο" είναι υποκειμενικό, δεν μπορεί να μετρηθεί, δεν μπορεί να δοκιμαστεί. Σε αυτό το στάδιο, η τεχνητή νοημοσύνη είναι ένα ισχυρό βοήθημα για τη σύνταξη απαιτήσεων και τη σύλληψη διφορούμενων διατυπώσεων. αλλά μόνο ο ενδιαφερόμενος αποφασίζει ποιος επιχειρηματικός κανόνας είναι πραγματικός.
Ιστορία χρήστη και κριτήρια αποδοχής
Μια κοινή μορφή στη γραφή σύγχρονων απαιτήσεων είναι η ιστορία χρήστη: "Ως [ρόλος], για [σκοπό], θέλω [χαρακτηριστικό]." Παράδειγμα: "Ως αντιπρόσωπος πωλήσεων, θέλω τον υπολογισμό της έκπτωσης από την οθόνη του κινητού, ώστε να μπορώ να κάνω γρήγορες προσφορές στο πεδίο." Η ιστορία είναι σύντομη και προσανατολισμένη στις επιχειρήσεις. Δεν επιβάλλει τεχνική λύση.
Κάθε ιστορία θα πρέπει να έχει κριτήρια αποδοχής: δόκιμες προϋποθέσεις που πρέπει να πληρούνται για να θεωρηθεί η ιστορία «οκ». Ένα μοτίβο που χρησιμοποιείται συχνά είναι το μοτίβο "Δίνεται/Πότε/Τότε": "Δεδομένο: ο πελάτης ανήκει στο τμήμα VIP. Πότε: παραγγελίες άνω των 10.000 TL. Στη συνέχεια: το σύστημα εφαρμόζει έκπτωση 5%. Αυτό το μοτίβο εξαλείφει την ασάφεια γιατί συνδέει ξεκάθαρα την κατάσταση και το αναμενόμενο αποτέλεσμα.
Συμβουλή: Όταν γράφετε μια ιστορία χρήστη στην τεχνητή νοημοσύνη, φροντίστε να πείτε "δημιουργήστε τουλάχιστον 2 κριτήρια αποδοχής στη μορφή Given/When/Then για κάθε ιστορία". Όταν το μοντέλο αναγκάζεται να παράγει σημεία αναφοράς, τα κρυφά κενά στην απαίτηση γίνονται ορατά.
Βήμα προς βήμα: Εξαγωγή απαιτήσεων υποβοηθούμενη από AI
Βήμα 1 — Συλλέξτε ακατέργαστα δεδομένα. Αρχεία κλήσεων, email, υπάρχοντα στιγμιότυπα οθόνης, λίστες παραπόνων. Όσο περισσότερες πραγματικές εισροές, τόσο λιγότερη κατασκευή.
Βήμα 2 — Εξάγετε το πρώτο σύνολο ιστοριών. Δώστε ακατέργαστα στοιχεία στην τεχνητή νοημοσύνη και βάλτε την να παράγει προσχέδια ιστοριών χρηστών. Αυτό το βήμα δεν είναι μια πλήρης λίστα, αλλά ένα πρώτο βήμα.
Βήμα 3 — Προσθέστε κριτήρια αποδοχής. Δημιουργήστε κριτήρια Given/When/Then για κάθε ιστορία. Μια ιστορία για την οποία δεν μπορούν να παραχθούν κριτήρια σημαίνει στην πραγματικότητα ότι δεν είναι επαρκώς καθορισμένη.
Βήμα 4 — Σάρωση για αντιφάσεις και κενά. Ρωτήστε την τεχνητή νοημοσύνη «υπάρχουν αντιφάσεις, επικαλύψεις ή απροσδιόριστες καταστάσεις μεταξύ αυτών των απαιτήσεων;» Ρωτήστε και ελέγξτε το. Φιλτράρετε το αποτέλεσμα ως άνθρωπος.
Βήμα 5 — Δώστε προτεραιότητα και επιβεβαιώστε. Δώστε προτεραιότητα στις ιστορίες με τα ενδιαφερόμενα μέρη με βάση την επιχειρηματική αξία και τον επείγοντα χαρακτήρα. Η απόφαση προτεραιότητας ανήκει στην επιχειρηματική μονάδα και όχι στην τεχνητή νοημοσύνη.
Μην ξεχνάτε τις μη λειτουργικές απαιτήσεις
Τα περισσότερα έργα έχουν δυσκολίες στο πεδίο γιατί ξεχνούν τα μη λειτουργικά ενώ γράφουν τις λειτουργικές απαιτήσεις. Μια αναφορά μπορεί να λειτουργεί "σωστά", αλλά αν χρειαστούν 45 δευτερόλεπτα για να ανοίξει, κανείς δεν θα τη χρησιμοποιήσει. Ο παρακάτω πίνακας δείχνει τύπους μη λειτουργικών απαιτήσεων που συνήθως παραβλέπονται και μετρήσιμα παραδείγματα γραφής.
Είδος
κακή έκφραση
μετρήσιμη έκφραση
Απόδοση
"Πρέπει να είναι γρήγορος"
"Απόκριση ερωτήματος < 2 δευτ. σε μέση φόρτωση"
προσβασιμότητα
«Όλοι πρέπει να μπορούν να το χρησιμοποιούν»
"Συμβατό με WCAG 2.1 AA; πλήρης πλοήγηση με πληκτρολόγιο"
Ασφάλεια
«Θα πρέπει να είναι ασφαλές»
"Τα προσωπικά δεδομένα είναι κρυπτογραφημένα σε κατάσταση ηρεμίας, η πρόσβαση βασίζεται σε ρόλους"
διαθεσιμότητα
«Πρέπει να είναι εύκολο»
"Ο νέος χρήστης ολοκληρώνει την παραγγελία σε 3 βήματα χωρίς εκπαίδευση"
Διαθεσιμότητα/συνέχεια
"Δεν πρέπει να τρακάρει"
"Μηνιαία διάρκεια λειτουργίας ≥ 99,5%"
Three Mini Cases: By the Numbers
Περίπτωση 1 — Η τιμή μιας μη μετρήσιμης ανάγκης. Η οθόνη, η οποία αναπτύχθηκε σε τράπεζα με την απαίτηση «η οθόνη αναφοράς να ανοίγει γρήγορα», άνοιξε σε 22 δευτερόλεπτα υπό φόρτωση πεδίου. Ο προγραμματιστής νόμιζε ότι παρείχε τη λέξη "γρήγορα" στο περιβάλλον του (2 δευτερόλεπτα). Εάν η απαίτηση είχε γραφτεί ως "< 3 δευτερόλεπτα την ώρα αιχμής, πραγματική απόδοση", το πρόβλημα θα είχε εντοπιστεί στη δοκιμή. Η ανάπλαση κόστισε 3 εβδομάδες και μετρήσιμο επιπλέον κόστος.
Περίπτωση 2 — Κενό που καλύπτεται από κριτήρια αποδοχής. Ενώ έγραφε τα κριτήρια αποδοχής για την ιστορία "Το σύστημα εφαρμόζει την έκπτωση" σε ένα έργο ηλεκτρονικού εμπορίου, ο ενδιαφερόμενος παρατήρησε ότι δεν συζητήθηκε καθόλου τι θα συνέβαινε εάν η έκπτωση έρχονταν σε σύγκρουση με το κουπόνι και την έκπτωση VIP. Μια ερώτηση Given/When/Then απέτρεψε το σφάλμα διπλής έκπτωσης πριν από τη μετάδοση. Αυτό το σφάλμα προκάλεσε σοβαρή απώλεια εσόδων σε παρόμοια έργα.
Περίπτωση 3 — Κανόνας κατασκευασμένο από AI. Σε ένα έργο ανθρώπινου δυναμικού, η τεχνητή νοημοσύνη πρόσθεσε την πρόταση «αίτημα άδειας εγκρίνεται αυτόματα εντός 24 ωρών» στο προσχέδιο απαιτήσεων. Καμία τέτοια αυτόματη έγκριση δεν συζητήθηκε στη συνεδρίαση. Το μοντέλο είχε δημιουργήσει έναν κανόνα που φαινόταν «λογικός». Δίπλα σε κάθε απαίτηση, ο ειδικός γράφει «πηγή: ποια συνέντευξη/έγγραφο;» Προσθέτοντας τη στήλη, αφαίρεσε 4 προτάσεις χωρίς πηγή.
Αδύναμη προτροπή / Ισχυρή προτροπή
Αδύναμη προτροπή:
Γράψτε ιστορίες χρηστών για αυτό το έργο.
Ισχυρή προτροπή:
Ο ρόλος σας: Είστε επιχειρησιακός αναλυτής του MIS. Εξάγετε ιστορίες χρηστών από το σημείωμα συνέντευξης παρακάτω. Κανόνες: - Μορφή: "Ως [ρόλος], για [σκοπό], θέλω [χαρακτηριστικό]."- Γράψτε ΤΟΥΛΑΧΙΣΤΟΝ 2 κριτήρια αποδοχής για κάθε ιστορία σε μορφή Given/When/Then.- Προσθέστε μια πρόταση "Πηγή: Ετικέτα: ΚΑΤΑ ΚΑΤΑΣΤΑΣΗ" δίπλα σε κάθε ιστορία; Αυτό δεν είναι σαφές στη σημείωση. τοποθέτηση.- Γράψτε μετρήσιμες μη λειτουργικές απαιτήσεις (απόδοση, ασφάλεια, προσβασιμότητα) σε ξεχωριστή ενότητα. Σημείωμα συνέντευξης:[κείμενο]
Η ισχυρή προτροπή επιβάλλει τη μορφή της ιστορίας, τα κριτήρια αποδοχής, την ιχνηλασιμότητα της πηγής και τις μη λειτουργικές απαιτήσεις ταυτόχρονα. Αυτό διευκολύνει τον έλεγχο της εξόδου.
Τέσσερα αντιγράψιμα πρότυπα
1) Διευκρίνιση απαιτήσεων:
Εξετάστε την απαίτηση παρακάτω. Σημειώστε κάθε πρόταση που είναι ασαφής, ασύγκριτη ή ανοιχτή σε περισσότερες από μία ερμηνείες και γράψτε μια διευκρινιστική ερώτηση για καθεμία. Μην επινοείτε την απάντηση. Απαίτηση: [κείμενο]
2) Σάρωση αντιφάσεων:
Στη λίστα απαιτήσεων παρακάτω, βρείτε στοιχεία που έρχονται σε αντίθεση μεταξύ τους, είναι επαναλαμβανόμενα ή αφήνουν λογικά κενά. Αναφέρετε κάθε εύρημα με αριθμούς στοιχείων και αιτιολόγηση μιας πρότασης. Λίστα: [κείμενο]
3) Δημιουργία κριτηρίων αποδοχής:
Γράψτε τουλάχιστον 4 κριτήρια αποδοχής για την ακόλουθη ιστορία χρήστη σε μορφή Given/When/Then, συμπεριλαμβανομένων περιπτώσεων ορίου και εξαίρεσης. Αναφέρετε επίσης τυχόν σημεία που παραμένουν ασαφή. Ιστορία: [κείμενο]
4) Περίγραμμα πεδίου εφαρμογής:
Σχεδιάστε τα στοιχεία "In Scope" και "Out of Scope" ως πίνακα δύο στηλών σύμφωνα με τις ακόλουθες απαιτήσεις. Επισημάνετε [ΑΠΑΙΤΕΙΤΑΙ ΕΠΙΒΕΒΑΙΩΣΗ] για οποιοδήποτε αντικείμενο δεν είστε σίγουροι. Απαιτήσεις: [κείμενο]
Συνήθη λάθη
- Η σκέψη ότι η λύση είναι ανάγκη. Η "Προσθήκη αναπτυσσόμενου μενού" είναι μια λύση, όχι μια απαίτηση. Η απαίτηση λέει "ο χρήστης πρέπει να μπορεί να επιλέξει τη χώρα από την καθορισμένη λίστα". Η ομάδα πληροφορικής σχεδιάζει τη λύση.
- Παράλειψη μη λειτουργικών. Το να γράψετε απλώς «τι να κάνετε» και να ξεχάσετε το «πώς να είστε» (ταχύτητα, ασφάλεια, προσβασιμότητα) είναι το πιο συνηθισμένο και πιο ακριβό κενό.
- Χρησιμοποιώντας αμέτρητα επίθετα. Λέξεις όπως "γρήγορο, εύκολο, ασφαλές, φιλικό προς το χρήστη" δεν είναι έγκυρες χωρίς όριο.
- Χωρίς να παρατηρήσετε τον κανόνα που έχει δημιουργήσει η AI. Το μοντέλο μπορεί να προσθέσει «λογικούς» αλλά όχι πραγματικά προφορικούς κανόνες. Ζητήστε πόρους για κάθε ανάγκη.
- Αφήνοντας την ιεράρχηση στην AI. Τι να κάνετε πρώτα είναι μια απόφαση επιχειρηματικής αξίας. Η επιχειρηματική μονάδα το δίνει αυτό.
Προσοχή: Η πιο επικίνδυνη πρόταση στην ανάλυση απαιτήσεων είναι "όλοι το γνωρίζουν ήδη". Οι ανείπωτες υποθέσεις δεν μπαίνουν στην τεκμηρίωση, δεν μπαίνουν ποτέ στον κώδικα και εμφανίζονται στο πεδίο. Ρωτήστε την τεχνητή νοημοσύνη "τι υποτίθεται αλλά δεν γράφεται σε αυτήν την απαίτηση;" κάνει ορατές αυτές τις κρυφές υποθέσεις.
Συνοπτικά
Η ανάλυση απαιτήσεων ορίζει τι πρέπει να κάνει το σύστημα με σαφή, μετρήσιμο και ανιχνεύσιμο τρόπο. Οι λειτουργικές απαιτήσεις περιγράφουν την εργασία, οι μη λειτουργικές απαιτήσεις περιγράφουν τις ιδιότητες και το τελευταίο συχνά ξεχνιέται. Η ιστορία χρήστη και τα κριτήρια αποδοχής Given/When/Then είναι ισχυρά εργαλεία που εξαλείφουν την αβεβαιότητα. Η τεχνητή νοημοσύνη επιταχύνει σημαντικά την παραγωγή σεναρίων, κριτηρίων αποδοχής, ανίχνευσης συγκρούσεων και διευκρινιστικών ερωτήσεων. Ωστόσο, η ορθότητα του επιχειρηματικού κανόνα, το πεδίο εφαρμογής και η απόφαση προτεραιότητας και η πηγή κάθε πρότασης είναι ευθύνη του ανθρώπου. Μην οριστικοποιείτε καμία απαίτηση που είναι χωρίς πηγές και μη μετρήσιμη.
Εργασία εφαρμογής
Γράψτε ένα επιχειρηματικό αίτημα μιας παραγράφου για ένα φανταστικό «σύστημα διαδικτυακών ραντεβού» (π.χ. «Οι πελάτες θα πρέπει να μπορούν να κλείνουν ραντεβού ηλεκτρονικά, το προσωπικό θα πρέπει να μπορεί να βλέπει ημερολόγια»). (1) Δημιουργήστε τουλάχιστον 5 ιστορίες χρηστών και 2 κριτήρια αποδοχής για καθεμία με ισχυρή προτροπή από αυτό το αίτημα. (2) Βρείτε τουλάχιστον 2 κρυφά κενά στα κριτήρια που παράγονται από το μοντέλο (π.χ. διπλό ραντεβού ταυτόχρονα, κανόνας ακύρωσης). (3) Συμπεριλάβετε τουλάχιστον 3 μη λειτουργικές απαιτήσεις σε μετρήσιμη μορφή. (4) Προσδιορίστε τουλάχιστον 3 στοιχεία ως "Εκτός πεδίου εφαρμογής". (5) Σημειώστε έναν κανόνα που μπορεί να έχει φτιάξει το μοντέλο και γράψτε πώς θα τον επιβεβαιώνατε.
λίστα ελέγχου
- [ ] Έγραψα τις λειτουργικές και μη λειτουργικές απαιτήσεις ξεχωριστά.
- [ ] Κάθε απαίτηση είναι σαφής, μετρήσιμη και ελεγχόμενη.
- [ ] Κάθε ιστορία έχει κριτήρια αποδοχής Given/When/Then.
- [ ] Μπορώ να εντοπίσω την πηγή (συνομιλία/έγγραφο) κάθε απαίτησης.
- [ ] Σημείωσα τους πιθανούς κανόνες που είχε δημιουργήσει η AI και τους άφησα για επιβεβαίωση.
- [ ] Έκανα την ιεράρχηση προτεραιοτήτων μαζί με την επιχειρηματική μονάδα.