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