Ανάλυση Απαιτήσεων Λογισμικού με Παράδειγμα
Τσαρλς Μουρ
⚡ Έξυπνη Σύνοψη
Η ανάλυση απαιτήσεων λογισμικού διαχωρίζει τις ανάγκες των ενδιαφερόμενων μερών σε λειτουργικές και μη λειτουργικές δηλώσεις, τις κατατάσσει σε επιχειρηματικό, αρχιτεκτονικό και συστημικό επίπεδο και στη συνέχεια ελέγχει την καθεμία με βάση τα ποιοτικά χαρακτηριστικά για να εγγυηθεί μια ελέγξιμη, tracεφικτή, ιεραρχημένη προδιαγραφή.
Μια απαίτηση λογισμικού είναι μια λειτουργική ή μη λειτουργική ανάγκη που πρέπει να υλοποιηθεί στο σύστημα. Λειτουργική σημαίνει παροχή συγκεκριμένης υπηρεσίας στον χρήστη.
Για παράδειγμα, στο πλαίσιο μιας τραπεζικής εφαρμογής, η λειτουργική απαίτηση είναι ότι όταν ένας πελάτης επιλέγει «Προβολή Υπολοίπου», θα πρέπει να μπορεί να βλέπει το τελευταίο υπόλοιπο του λογαριασμού του.
Μια απαίτηση λογισμικού μπορεί επίσης να είναι μη λειτουργική, όπως μια απαίτηση απόδοσης. Για παράδειγμα, μια μη λειτουργική απαίτηση μπορεί να ορίζει ότι κάθε σελίδα του συστήματος θα πρέπει να φορτώνει για τους χρήστες εντός 5 δευτερολέπτων.
Βασικά λοιπόν η απαίτηση λογισμικού είναι α
- Λειτουργικό ή
- Μη λειτουργικο
ανάγκη που πρέπει να ενσωματωθεί στο σύστημα. Οι απαιτήσεις λογισμικού συνήθως εκφράζονται ως δηλώσεις.
Είδη Απαιτήσεων
Επιχειρηματικές απαιτήσειςΑυτές είναι απαιτήσεις υψηλού επιπέδου που ελήφθησαν από την επιχειρηματική περίπτωση του έργου. Για παράδειγμα, ένα σύστημα υπηρεσιών κινητής τραπεζικής παρέχει τραπεζικές υπηρεσίες στη Νοτιοανατολική Ασία. Η επιχειρηματική απαίτηση που αποφασίστηκε για την Ινδία είναι η σύνοψη λογαριασμού και η μεταφορά χρημάτων, ενώ για την Κίνα είναι η σύνοψη λογαριασμού και η πληρωμή λογαριασμών.
| Χώρα | Εταιρεία παροχής τραπεζικών λειτουργιών ή υπηρεσιών |
|---|---|
| India | Περίληψη λογαριασμού και μεταφορά χρημάτων |
| Κίνα | Περίληψη λογαριασμού και Bill Πληρωμή |
Archiτεχνολογίες και απαιτήσεις σχεδιασμούΑυτές οι απαιτήσεις είναι πιο λεπτομερείς από τις επιχειρηματικές απαιτήσεις και καθοδηγούν την αρχιτεκτονική λύσης. Καθορίζουν τον συνολικό σχεδιασμό που απαιτείται για την εφαρμογή της επιχειρηματικής απαίτησης. Για έναν εκπαιδευτικό οργανισμό, οι τυπικές περιπτώσεις χρήσης αρχιτεκτονικής και σχεδιασμού περιλαμβάνουν τη σύνδεση, τις λεπτομέρειες του μαθήματος και την εγγραφή. Η απαίτηση θα είναι όπως φαίνεται παρακάτω.
| Περίπτωση τραπεζικής χρήσης | Απαίτηση |
|---|---|
| Bill Πληρωμή | Αυτή η περίπτωση χρήσης περιγράφει πώς ένας πελάτης μπορεί να συνδεθεί στο net banking και να χρησιμοποιήσει το Bill Δυνατότητα Πληρωμής. Ο πελάτης μπορεί να δει έναν πίνακα ελέγχου με τους εκκρεμείς λογαριασμούς για τους εγγεγραμμένους δικαιούχους. Ο πελάτης μπορεί να προσθέσει, να τροποποιήσει και να διαγράψει μια λεπτομέρεια δικαιούχου. Ο πελάτης μπορεί να διαμορφώσει ειδοποιήσεις SMS και email για διαφορετικές ενέργειες χρέωσης. Ο πελάτης μπορεί να δει ένα ιστορικό προηγούμενων πληρωμένων λογαριασμών. Οι παράγοντες που ξεκινούν αυτήν την περίπτωση χρήσης είναι πελάτες τράπεζας ή προσωπικό υποστήριξης. |
Απαιτήσεις συστήματος και ενοποίησηςΣτο χαμηλότερο επίπεδο, έχουμε απαιτήσεις συστήματος και ενσωμάτωσης. Παρέχει μια λεπτομερή περιγραφή κάθε απαίτησης. Μπορεί να καταγραφεί ως ιστορίες χρηστών γραμμένες σε καθημερινή επιχειρηματική γλώσσα. Οι απαιτήσεις περιέχουν άφθονες λεπτομέρειες, ώστε οι προγραμματιστές να μπορούν να ξεκινήσουν τον προγραμματισμό. Bill Το παρακάτω παράδειγμα ενότητας πληρωμών δείχνει την απαίτηση για την προσθήκη ενός εκδότη λογαριασμού.
| Bill Πληρωμή | απαιτήσεις |
|---|---|
| Πρόσθεση Billers | Όνομα παρόχου κοινής ωφέλειας, Αριθμός πελάτη σχέσης, Αυτόματες πληρωμές – Ναι/Όχι, Πληρωμή ολόκληρου Bill – Ναι/Όχι, Όριο αυτόματης πληρωμής – Μην πληρώσετε εάν Bill υπερβαίνει το καθορισμένο ποσό |
Μερικές φορές, για ένα έργο, ενδέχεται να μην λάβετε καμία απαίτηση ή έγγραφο για να εργαστείτε. Ακόμα και τότε, υπάρχουν άλλες πηγές πληροφοριών απαιτήσεων στις οποίες μπορείτε να βασιστείτε για να βασίσετε το λογισμικό ή τον σχεδιασμό δοκιμών σας. Οι άλλες πηγές απαιτήσεων στις οποίες μπορείτε να βασιστείτε παρατίθενται παρακάτω.
Άλλες Πηγές Απαιτήσεων
- Μεταφορά γνώσεων από συναδέλφους ή υπαλλήλους που ήδη εργάζονται σε αυτό το έργο
- Συζητήστε το έργο με τον Επιχειρηματικό Αναλυτή, τον υπεύθυνο προϊόντος, τον επικεφαλής του έργου και τους προγραμματιστές
- Ανάλυση της προηγούμενης έκδοσης του συστήματος που έχει ήδη υλοποιηθεί
- Ανάλυση παλαιότερων εγγράφων απαιτήσεων από το έργο
- Revπροβολή προηγούμενων αναφορών σφαλμάτων. Ορισμένες αναφορές σφαλμάτων μετατρέπονται σε αιτήματα βελτίωσης που ενδέχεται να εφαρμοστούν στην τρέχουσα έκδοση
- Ελέγξτε τον οδηγό εγκατάστασης, εάν υπάρχει, για να δείτε ποιες εγκαταστάσεις απαιτούνται
- Αναλύστε τον τομέα ή τη γνώση του κλάδου που προσπαθεί να εφαρμόσει η ομάδα
Όποια πηγή απαιτήσεων κι αν χρησιμοποιήσετε, καταγράψτε τις σε κοινή μορφή και ζητήστε την εξέτασή τους από έμπειρα μέλη της ομάδας.
Πώς να αναλύσετε τις απαιτήσεις
Σκεφτείτε το παράδειγμα ενός εκπαιδευτικού συστήματος λογισμικού όπου ένας φοιτητής μπορεί να εγγραφεί σε διαφορετικά μαθήματα.
Ας μελετήσουμε πώς να αναλύσουμε τις απαιτήσεις. Κάθε απαίτηση πρέπει να διατηρεί ένα σύνολο τυπικών χαρακτηριστικών ποιότητας, τα οποία περιλαμβάνουν τα ακόλουθα:
- Atomic
- Μοναδικά αναγνωρισμένο
- Πλήρης
- Συνεπής και μονοσήμαντη
- Tracικανός
- Προτεραιότητα
- Δοκιμάσιμος
Ο παρακάτω πίνακας απεικονίζει κάθε χαρακτηριστικό με τρεις στήλες:
- Η πρώτη στήλη υποδεικνύει - "Ποιότητα απαίτησης"
- Η δεύτερη στήλη δείχνει - "κακή απαίτηση με κάποιο πρόβλημα"
- Η τρίτη στήλη δείχνει την ίδια απαίτηση «μετατροπή σε καλή απαίτηση».
| Απαίτηση Ποιότητα | Παράδειγμα κακής απαίτησης | Παράδειγμα καλής απαίτησης |
|---|---|---|
| Atomic | Οι φοιτητές θα μπορούν να εγγραφούν σε προπτυχιακά και μεταπτυχιακά μαθήματα | Οι φοιτητές θα μπορούν να εγγραφούν σε προπτυχιακά μαθήματα. Οι φοιτητές θα μπορούν να εγγραφούν σε μεταπτυχιακά μαθήματα. |
| Μοναδικά αναγνωρισμένο | 1- Οι φοιτητές θα μπορούν να εγγραφούν σε προπτυχιακά μαθήματα. 1- Οι φοιτητές θα μπορούν να εγγραφούν σε μεταπτυχιακά μαθήματα. | Εγγραφή σε μαθήματα. Οι φοιτητές θα μπορούν να εγγραφούν σε προπτυχιακά μαθήματα. Οι φοιτητές θα μπορούν να εγγραφούν σε μεταπτυχιακά μαθήματα. |
| Πλήρης | Ένας χρήστης καθηγητής θα συνδεθεί στο σύστημα παρέχοντας το όνομα χρήστη, τον κωδικό πρόσβασής του και άλλες σχετικές πληροφορίες | Ένας χρήστης καθηγητής θα συνδεθεί στο σύστημα παρέχοντας το όνομα χρήστη, τον κωδικό πρόσβασης και τον κωδικό τμήματός του |
| Συνεπής και μονοσήμαντη | Ένας φοιτητής θα έχει είτε προπτυχιακά είτε μεταπτυχιακά αλλά όχι και τα δύο. Ορισμένα μαθήματα θα είναι ανοιχτά τόσο για προπτυχιακούς όσο και για μεταπτυχιακούς | Ένας φοιτητής θα έχει είτε προπτυχιακό είτε μεταπτυχιακό αλλά όχι και τα δύο |
| Tracικανός | Διατήρηση των πληροφοριών των μαθητών που αντιστοιχίζονται στο BRD req.ID; | Διατήρηση πληροφοριών μαθητή-Αντιστοιχισμένη στο BRD req ID 4.1 |
| Προτεραιότητα | Εγγεγραμμένος φοιτητής-Προτεραιότητα 1. Διατήρηση πληροφοριών χρήστη-Προτεραιότητα 1. Εγγραφή μαθημάτων-Προτεραιότητα 1. Προβολή προφορικού δελτίου-Προτεραιότητα 1 | Εγγραφή Φοιτητή-Προτεραιότητα 1. Διατήρηση Στοιχείων Χρήστη-Προτεραιότητα 2. Εγγραφή Μαθημάτων-Προτεραιότητα 1. Προβολή Κάρτας Αναφοράς-Προτεραιότητα3 |
| Δοκιμάσιμος | Κάθε σελίδα του συστήματος θα φορτώνεται σε ένα αποδεκτό χρονικό πλαίσιο | Οι σελίδες εγγραφής μαθητών και εγγραφής μαθημάτων του συστήματος θα φορτωθούν εντός 5 δευτερολέπτων |
Ας κατανοήσουμε λεπτομερέστερα κάθε ένα από αυτά τα χαρακτηριστικά, ξεκινώντας από Atomπαγο
Atomic
Κάθε απαίτηση θα πρέπει να είναι ατομική, που σημαίνει ότι πρέπει να βρίσκεται στο χαμηλότερο επίπεδο λεπτομέρειας και δεν μπορεί να αναλυθεί περαιτέρω σε στοιχεία. Τα ακόλουθα παραδείγματα συγκρίνουν τις ατομικές και τις μη ατομικές απαιτήσεις.
Συνεχίζοντας με το παράδειγμα του συστήματος στον τομέα της εκπαίδευσης: Εδώ, η κακή απαίτηση είναι «Οι φοιτητές θα μπορούν να εγγραφούν σε προπτυχιακά και μεταπτυχιακά μαθήματα». Αυτή είναι μια κακή απαίτηση επειδή δεν είναι ατομική — συνδυάζει δύο διαφορετικές οντότητες, προπτυχιακά και μεταπτυχιακά μαθήματα. Η αντίστοιχη καλή απαίτηση τη χωρίζει σε δύο απαιτήσεις. Η μία απαίτηση καλύπτει την εγγραφή σε προπτυχιακά μαθήματα και η άλλη καλύπτει την εγγραφή σε μεταπτυχιακά μαθήματα.
Μοναδικά Προσδιορισμένο
Το επόμενο χαρακτηριστικό ποιότητας είναι η μοναδική αναγνώριση. Στο κακό παράδειγμα, δύο ξεχωριστές απαιτήσεις μοιράζονται το ίδιο ID#1. Εάν μια ομάδα αναφέρει μια απαίτηση με το ID της, καθίσταται ασαφές ποιο από τα δύο εννοείται. Η καλή απαίτηση τις ανασυντάσσει στην Ενότητα 1 — Εγγραφή σε Μαθήματα, με τις υποαπαιτήσεις 1.1 (εγγραφή σε προπτυχιακά μαθήματα) και 1.2 (εγγραφή σε μεταπτυχιακά μαθήματα).
Πλήρης
Κάθε απαίτηση θα πρέπει να είναι πλήρης. Για παράδειγμα, εδώ η λανθασμένη απαίτηση αναφέρει ότι «ένας χρήστης καθηγητής θα συνδεθεί στο σύστημα παρέχοντας το όνομα χρήστη, τον κωδικό πρόσβασής του και άλλες σχετικές πληροφορίες». Η φράση «Άλλες σχετικές πληροφορίες» είναι ασαφής. Μια πλήρης απαίτηση παραθέτει τα ακριβή πεδία, όπως τον κωδικό τμήματος, που πρέπει να παρέχει ο καθηγητής.
Συνεπής και μονοσήμαντη
Κάθε απαίτηση θα πρέπει να είναι συνεπής και σαφής. Στο κακό παράδειγμα, μια απαίτηση αναφέρει «Ένας φοιτητής θα έχει είτε προπτυχιακά είτε μεταπτυχιακά μαθήματα, αλλά όχι και τα δύο», ενώ μια άλλη αναφέρει «Ορισμένα μαθήματα θα είναι ανοιχτά τόσο σε προπτυχιακούς όσο και σε μεταπτυχιακούς φοιτητές».
Η πρώτη απαίτηση υποδηλώνει ότι τα μαθήματα χωρίζονται σε δύο αποκλειστικές κατηγορίες, αλλά η δεύτερη απαίτηση την αντιφάσκει, ανοίγοντας ορισμένα μαθήματα και στις δύο ομάδες.
Η καλή απαίτηση επιλύει τη σύγκρουση δηλώνοντας σαφώς ότι κάθε μάθημα χαρακτηρίζεται είτε ως προπτυχιακό είτε ως μεταπτυχιακό και ένας φοιτητής μπορεί να εγγραφεί μόνο σε μαθήματα μίας κατηγορίας.
Tracικανός
Κάθε απαίτηση πρέπει να είναι tracεφικτό επειδή υπάρχουν απαιτήσεις σε πολλαπλά επίπεδα: επιχειρηματικό, αρχιτεκτονικό και σχεδιαστικό, και σύστημα και ολοκλήρωση.
Όταν μετατρέπετε μια επιχειρηματική απαίτηση σε αρχιτεκτονικές και σχεδιαστικές απαιτήσεις ή τις αρχιτεκτονικές και σχεδιαστικές απαιτήσεις σε απαιτήσεις συστήματος και ολοκλήρωσης, tracΗ δυνατότητα εφαρμογής πρέπει να διατηρείται. Κάθε επιχειρηματική απαίτηση θα πρέπει να αντιστοιχεί σε μία ή περισσότερες αρχιτεκτονικές και σχεδιαστικές απαιτήσεις. Στο κακό παράδειγμα "Διατήρηση πληροφοριών φοιτητή – αντιστοιχισμένη στο αναγνωριστικό απαίτησης BRD;", το αναγνωριστικό απαίτησης λείπει.
Η καλή απαίτηση καταγράφει την ίδια δήλωση, αλλά αντιστοιχεί ρητά στο αναγνωριστικό απαίτησης BRD 4.1. Κάθε απαίτηση πρέπει να φέρει ένα tracχάρτης ικανότηταςpingΟι απαιτήσεις συστήματος και ενσωμάτωσης θα πρέπει επίσης να αντιστοιχίζονται στον κώδικα που τις υλοποιεί και στις δοκιμαστικές περιπτώσεις που τις επαληθεύουν.
TracΣυνεπώς, η δυνατότητα εκτέλεσης εργασιών από άκρο σε άκρο σε όλο το έργο.
Προτεραιότητα
Κάθε απαίτηση πρέπει να ιεραρχηθεί κατά προτεραιότητα, ώστε η ομάδα να γνωρίζει τι να εφαρμόσει πρώτα και τι μπορεί να περιμένει. Στο κακό παράδειγμα, οι επιλογές Εγγραφή Φοιτητή, Διατήρηση Πληροφοριών Χρήστη, Εγγραφή Μαθημάτων και Προβολή Κάρτας Αναφοράς έχουν όλα οριστεί σε Προτεραιότητα 1. Δεν μπορούν όλα να έχουν Προτεραιότητα 1, επομένως οι απαιτήσεις πρέπει να κατατάσσονται ρεαλιστικά. Το καλό παράδειγμα δίνει στις επιλογές Εγγραφή Φοιτητή και Εγγραφή Μαθημάτων την υψηλότερη Προτεραιότητα 1, Διατήρηση Πληροφοριών Χρήστη Προτεραιότητα 2 και Προβολή Κάρτας Αναφοράς Προτεραιότητα 3.
Δοκιμάσιμος
Κάθε απαίτηση θα πρέπει να είναι ελέγξιμη. Το κακό παράδειγμα, «κάθε σελίδα του συστήματος θα φορτώσει σε ένα αποδεκτό χρονικό πλαίσιο», δεν είναι ελέγξιμο για δύο λόγους. Πρώτον, «κάθε σελίδα» μπορεί να σημαίνει δεκάδες σελίδες, κάτι που επιβαρύνει την προσπάθεια δοκιμών. Δεύτερον, το «αποδεκτό χρονικό πλαίσιο» είναι απροσδιόριστο — αποδεκτό από ποιον και έναντι ποιου σημείου αναφοράς; Η καλή απαίτηση διορθώνει και τα δύο προβλήματα ονομάζοντας τις συγκεκριμένες σελίδες («σελίδες εγγραφής φοιτητών και μαθημάτων εγγραφής») και θέτοντας έναν μετρήσιμο στόχο 5 δευτερολέπτων.
