Τι είναι η ανάλυση απαιτήσεων και η συγκέντρωση στο SDLC;

what is requirement analysis

Αυτό το σεμινάριο εξηγεί τι είναι η ανάλυση απαιτήσεων, τα βήματα ανάλυσης απαιτήσεων, τα παραδείγματα και οι στόχοι της συγκέντρωσης απαιτήσεων στο SDLC:

Η ανάπτυξη λογισμικού είναι μια τεράστια εργασία που δημιουργεί ένα προϊόν λογισμικού που λειτουργεί.

Το προϊόν λογισμικού κατασκευάζεται σύμφωνα με τις απαιτήσεις του πελάτη. Κυρίως, αυτό το προϊόν λογισμικού συμμορφώνεται με αυτό που περίμενε ο τελικός πελάτης / χρήστης, ενώ μερικές φορές αυτό το προϊόν δεν συμμορφώνεται πλήρως με αυτό που περίμενε ο πελάτης / τελικός χρήστης.

Τι θα μάθετε:

• Τι είναι η ανάλυση απαιτήσεων;
  • Στάδια / βήματα ανάλυσης απαιτήσεων
    • # 1) Συγκέντρωση απαιτήσεων
    • # 2) Ανάλυση συγκεντρωμένων απαιτήσεων
    • # 3) Τεκμηρίωση αναλυμένων απαιτήσεων
  • Μετατροπή επιχειρηματικών απαιτήσεων σε απαιτήσεις λογισμικού
  • Κατανόηση περιπτώσεων μη λειτουργικών απαιτήσεων
  • Διαφορά μεταξύ επιχειρηματικών απαιτήσεων και απαιτήσεων λογισμικού
• συμπέρασμα
  • Συνιστώμενη ανάγνωση

Τι είναι η ανάλυση απαιτήσεων;

Ας κατανοήσουμε την Ανάλυση Απαιτήσεων με τη βοήθεια ενός παραδείγματος.

Προσδοκία πελάτη / τελικού χρήστη:

Πελάτης / Τελικός χρήστης λαμβάνει:

Όπως μπορείτε να αναλύσετε από τις παραπάνω εικόνες ότι υπάρχει αναντιστοιχία στο τελικό προϊόν με τις προσδοκίες των πελατών. Αυτό θα μπορούσε να οφείλεται σε μυριάδες λόγους, δηλαδή. λανθασμένη εφαρμογή των απαιτήσεων των πελατών, λανθασμένη σχεδίαση, εσφαλμένη κατανόηση των απαιτήσεων των πελατών από προγραμματιστές και ομάδα ποιότητας κ.λπ.

Ωστόσο, όπως μπορείτε να δείτε, για οποιονδήποτε λόγο για λανθασμένη παράδοση προϊόντων, ο κύριος λόγος πηγαίνει στην απαίτηση. Επομένως, εάν γινόταν σωστή απαίτηση κατανόησης, σύλληψης, εφαρμογής και δοκιμών, θα βοηθούσε στον μετριασμό της εσφαλμένης και ατελούς παράδοσης προϊόντων στον πελάτη / τελικό χρήστη.

Μια καλή παράδοση προϊόντων απαιτεί σωστή συλλογή απαιτήσεων, την αποτελεσματική εξέταση των απαιτήσεων που συγκεντρώνονται και, τέλος, σαφή τεκμηρίωση απαιτήσεων, ως προϋπόθεση. Όλη αυτή η διαδικασία ονομάζεται επίσης ως Ανάλυση απαιτήσεων στον κύκλο ζωής ανάπτυξης λογισμικού (SDLC)

Στάδια / βήματα ανάλυσης απαιτήσεων

Όπως μπορείτε να δείτε, η Ανάλυση Απαιτήσεων είναι η πρώτη δραστηριότητα στο SDLC και ακολουθεί η Λειτουργική Προδιαγραφή και ούτω καθεξής. Η ανάλυση απαιτήσεων είναι ένα ζωτικής σημασίας βήμα στο SDLC καθώς αντιστοιχεί σε δοκιμές αποδοχής που είναι κρίσιμες για την αποδοχή προϊόντων από τους πελάτες.

Σε αυτό το σεμινάριο, θα εξηγήσουμε πώς γίνεται η ανάλυση απαιτήσεων σε SDLC. Θα δούμε επίσης τα διάφορα στάδια, τα αποτελέσματα, τις προκλήσεις και τα διορθωτικά μέτρα στην ανάλυση των απαιτήσεων.

Η ανάλυση απαιτήσεων ξεκινά με:

1. Συγκέντρωση απαιτήσεων που ονομάζεται επίσης ως εκδήλωση.
2. Αυτό ακολουθείται από ανάλυση τις συλλεγόμενες απαιτήσεις για την κατανόηση της ορθότητας και της σκοπιμότητας της μετατροπής αυτών των απαιτήσεων σε ένα πιθανό προϊόν.
3. Και τελικά, τεκμηρίωση τις απαιτήσεις που συλλέγονται.

# 1) Συγκέντρωση απαιτήσεων

Για να βεβαιωθείτε ότι όλα τα βήματα που αναφέρονται παραπάνω εκτελούνται κατάλληλα, πρέπει να συγκεντρωθούν από τον πελάτη σαφείς, συνοπτικές και σωστές απαιτήσεις. Ο πελάτης θα πρέπει να μπορεί να καθορίζει σωστά τις απαιτήσεις του και ο αναλυτής επιχειρήσεων θα πρέπει να μπορεί να το συλλέγει με τον ίδιο τρόπο που ο πελάτης σκοπεύει να μεταφέρει.

Πολλές φορές δεν είναι δυνατόν η συγκέντρωση απαιτήσεων να γίνεται αποτελεσματικά από επιχειρηματικούς αναλυτές από τον πελάτη. Αυτό μπορεί να οφείλεται στην εξάρτηση από πολλούς ανθρώπους που σχετίζονται με το αναμενόμενο τελικό προϊόν, τα εργαλεία, το περιβάλλον κ.λπ. Επομένως, είναι πάντα καλή ιδέα να συμμετέχετε όλοι οι ενδιαφερόμενοι που θα μπορούσαν να επηρεάσουν ή να επηρεαστούν από το τελικό προϊόν.

Η πιθανή ομάδα ενδιαφερομένων θα μπορούσε να είναι μηχανικοί ποιότητας λογισμικού (τόσο QC όσο και QA), οποιοσδήποτε τρίτος προμηθευτής που θα μπορούσε να παρέχει υποστήριξη στο έργο, τελικός χρήστης για τον οποίο προορίζεται το προϊόν, προγραμματιστές λογισμικού, άλλη ομάδα εντός του οργανισμού που μπορεί να παρέχει μια ενότητα ή πλατφόρμα λογισμικού, βιβλιοθήκες λογισμικού κ.λπ. για την ανάπτυξη προϊόντων.

Παράδειγμα: Σε έναν οργανισμό, αναπτύσσουν ένα προϊόν ADAS (σύστημα κάμερας surround-view για έναν αναγνωρισμένο OEM) που χρειάζεται Στοίβα Autosar και Φορτωτής εκκίνησης δυαδικά αρχεία που λαμβάνονται από άλλο προμηθευτή.

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

Μερικές φορές, είναι καλή ιδέα να δημιουργήσετε ένα πρωτότυπο μοντέλο του προβλεπόμενου προϊόντος και να το δείξετε στον πελάτη. Αυτός είναι ένας εξαιρετικός τρόπος για να μεταφέρετε στους πελάτες ποιο προϊόν περιμένουν και πώς μπορεί να φαίνεται αργότερα. Αυτό βοηθά τον πελάτη να απεικονίσει το προϊόν που περιμένει και τους βοηθά να βρουν σαφείς απαιτήσεις.

Αυτή η δημιουργία πρωτοτύπου εξαρτάται από δύο τύπους προϊόντων:

1. Ένα παρόμοιο προϊόν που ήθελαν οι πελάτες, υπάρχει στον οργανισμό.
2. Νέο προϊόν που θα αναπτυχθεί.

(Εγώ) Στην πρώτη περίπτωση, είναι πιο εύκολο να δείξετε στον πελάτη πώς θα μοιάζει το τελικό προϊόν και πώς θα αναπτυχθεί. Στην αυτοκινητοβιομηχανία ADAS, είναι δυνατό να δείξουμε στους πελάτες ένα άλλο προϊόν που είναι ήδη στην αγορά και αναπτύχθηκε εντός του οργανισμού.

Για παράδειγμα, Ένα σύστημα κάμερας surround που έχει αναπτυχθεί για OEM (GM, Volkswagen, BMW κ.λπ.) και μπορεί να προβληθεί σε άλλο OEM.

Παρακαλώ σημειώστε , δεν είναι συνετό να δείξετε προϊόν / πρωτότυπο προϊόν στον πελάτη που βρίσκεται υπό ανάπτυξη, καθώς ενδέχεται να παραβιάζει τη Συμφωνία μη αποκάλυψης που έχει υπογραφεί με άλλο πελάτη για τον οποίο αναπτύσσεται αυτό το προϊόν. Μπορεί επίσης να οδηγήσει σε περιττή νομική αντιπαράθεση.

Ενα άλλο παράδειγμα θα μπορούσε να είναι αυτό του συστήματος ψυχαγωγίας, που αναπτύχθηκε από τον οργανισμό, και είναι ήδη στην αγορά. Οι επιχειρηματικοί αναλυτές και άλλοι ενδιαφερόμενοι μέσα σε έναν οργανισμό μπορούν να σχεδιάσουν μια επίδειξη εργαστηρίου για τον πελάτη, εμφανίζοντας συστήματα ψυχαγωγίας με απτά HMI, θύρες σύνδεσης συσκευών, sandbox κ.λπ.

Αυτό θα βοηθήσει τον πελάτη να κατανοήσει πώς θα φαίνεται το τελικό προϊόν και να παρέχει τις απαιτήσεις του πολύ πιο ξεκάθαρα.

(ii) Η δεύτερη περίπτωση μπορεί να επιτευχθεί με τη δημιουργία ενός βασικού μοντέλου εργασίας κάνοντας απλή κωδικοποίηση και συναρμολόγηση (τα περισσότερα χαρακτηριστικά εδώ είναι κωδικοποιημένα σε προγράμματα λογισμικού) ή δημιουργώντας ένα διάγραμμα ροής ή ένα διάγραμμα που θα μπορούσε να πείσει τον πελάτη πώς θα φαίνεται το προϊόν.

Σε κάθε περίπτωση, θα ήταν μια ανάσα για τη διαδικασία συλλογής απαιτήσεων καθώς ο πελάτης ξέρει τώρα τι θέλει.

Ο επιχειρηματικός αναλυτής μπορεί τώρα να διοργανώσει επίσημες συναντήσεις ανάκλησης απαιτήσεων, όπου όλοι οι ενδιαφερόμενοι θα μπορούσαν να προσκληθούν και έτσι να σημειώσουν τις διάφορες απαιτήσεις που παρέχονται από τον πελάτη (σε ορισμένες περιπτώσεις, εάν οι ενδιαφερόμενοι είναι περισσότεροι σε αριθμό, θα μπορούσε να διοριστεί ξεχωριστός γραμματέας για να σημειώσει τον πελάτη απαιτήσεις ή ιστορίες χρηστών, έτσι ώστε οι αναλυτές επιχειρήσεων να μπορούν να επικεντρωθούν στην εποπτεία της σύσκεψης).

Οι απαιτήσεις που συλλέγονται μπορούν να έχουν τη μορφή ιστορίες χρηστών (σε ευέλικτη ανάπτυξη), περιπτώσεις χρήσης, έγγραφα φυσικής γλώσσας πελατών, διαγράμματα, διαγράμματα ροής κ.λπ. Οι ιστορίες χρηστών γίνονται δημοφιλείς στον σύγχρονο κύκλο ζωής ανάπτυξης λογισμικού. Οι ιστορίες χρηστών είναι βασικά ένα σύνολο εισροών πελατών στη φυσική τους γλώσσα.

Παράδειγμα συγκέντρωσης απαιτήσεων: Στο σύστημα κάμερας ADAS surround, μια πιθανή ιστορία χρήστη θα μπορούσε να είναι: «Ως χρήστης, θα πρέπει να μπορώ να δω τι υπάρχει στην πίσω όψη του αυτοκινήτου μου».

Θα μπορούσαν να υπάρχουν πολλά 'Γιατί,' ερωτήσεις που τίθενται σε κάθε ιστορία χρήστη, η οποία θα βοηθήσει τον πελάτη να παρέχει πιο λεπτομερείς πληροφορίες σχετικά με την απαίτηση.

Στην παραπάνω ιστορία χρήστη, εάν ένας πελάτης λέει 'Ως χρήστης, θα πρέπει να μπορώ να δω τι υπάρχει στην πίσω όψη του αυτοκινήτου μου', θέτοντας μια ερώτηση 'Γιατί 'Θα μπορούσε να δώσει' Ως χρήστης, θα πρέπει να μπορώ να δω τι υπάρχει στην πίσω όψη του αυτοκινήτου μου, ώστε να μπορώ να σταθμεύσω το αυτοκίνητό μου με ασφάλεια '.

Κάνοντας την ερώτηση 'Γιατί' βοηθά επίσης στη δημιουργία αντικειμενικών και ατομικών απαιτήσεων από τεράστιες δηλώσεις φυσικής γλώσσας που δίνονται από τον πελάτη. Αυτό μπορεί εύκολα να εφαρμοστεί αργότερα στον κώδικα.

c και c ++ διαφορά

Ένας άλλος τρόπος συλλογής της απαίτησης είναι με τη μορφή περιπτώσεις χρήσης . Η περίπτωση χρήσης είναι μια προσέγγιση βήμα προς βήμα για την επίτευξη ενός συγκεκριμένου αποτελέσματος. Αυτό δεν λέει πώς θα λειτουργήσει το λογισμικό στην είσοδο του χρήστη, αλλά λέει, τι αναμένεται από τις εισόδους του χρήστη.

Παράδειγμα:

# 2) Ανάλυση συγκεντρωμένων απαιτήσεων

Μετά τη συγκέντρωση των απαιτήσεων, ξεκινά η ανάλυση των απαιτήσεων. Σε αυτό το στάδιο, διάφοροι ενδιαφερόμενοι κάθονται και κάνουν μια συνεδρία ανταλλαγής ιδεών. Αναλύουν τις απαιτήσεις που συγκεντρώθηκαν και αναζητούν σκοπιμότητα για την εφαρμογή τους. Συζητούν ο ένας με τον άλλον και διευκρινίζεται οποιαδήποτε ασάφεια.

Αυτό το βήμα είναι σημαντικό στη διαδικασία ανάλυσης απαιτήσεων για τους ακόλουθους βασικούς λόγους:

(Εγώ) Ο πελάτης μπορεί να παρέχει ορισμένες απαιτήσεις που θα ήταν αδύνατο να εφαρμοστούν λόγω διαφόρων εξαρτήσεων.

Παράδειγμα: Οι πελάτεςμπορεί να ζητήσει να περιβάλλει το σύστημα κάμερας με μια λειτουργία κάμερας οπισθοπορείας που θα σας βοηθήσει στάθμευση το αυτοκίνητο. Ο πελάτης μπορεί επίσης να ζητήσει το Τροχόσπιτο Hitch χαρακτηριστικό που χρησιμοποιεί επίσης πίσω κάμερα για να λειτουργήσει.

Εάν ο πελάτης δηλώνει μια απαίτηση για την κάμερα οπισθοπορείας στάθμευση βοήθεια πρέπει να λειτουργεί ανά πάσα στιγμή χωρίς εξαίρεση, τότε το Τροχόσπιτο η λειτουργία δεν θα λειτουργούσε ποτέ και το αντίστροφο.

(ii) Ένας επιχειρησιακός αναλυτής μπορεί να έχει καταλάβει την απαίτηση από το πελάτης διαφορετικά από το πώς ένα προγραμματιστής θα είχε ερμηνεύσει.

Δεδομένου ότι οι προγραμματιστές πιστεύουν ως τεχνικοί εμπειρογνώμονες, είναι πάντα πιθανό οι απαιτήσεις των πελατών να μετατρέπονται λανθασμένα σε λειτουργικές προδιαγραφές οι οποίες αργότερα θα γίνονται λανθασμένα σε έγγραφα αρχιτεκτονικής και σχεδιασμού και στη συνέχεια σε κώδικα. Ο αντίκτυπος είναι εκθετικός και επομένως πρέπει να ελεγχθεί.

Ένα πιθανό διορθωτικό μέτρο θα μπορούσε να είναι ακολουθώντας μια ευέλικτη μέθοδο ανάπτυξης λογισμικού, μετά από περιπτώσεις χρήσης που παρέχει ο πελάτης κ.λπ.

# 3) Τεκμηρίωση αναλυμένων απαιτήσεων

Μόλις ολοκληρωθεί η ανάλυση των απαιτήσεων, αρχίζει η τεκμηρίωση των απαιτήσεων. Διάφοροι τύποι απαιτήσεων βγαίνουν από την ανάλυση των απαιτήσεων.

Μερικά από αυτά είναι:

(Εγώ) Προδιαγραφή απαιτήσεων πελατών.

(ii) Απαίτηση αρχιτεκτονικής λογισμικού.

Παράδειγμα:

(iii) Απαίτηση σχεδιασμού λογισμικού.

Παράδειγμα:

(iv) Προδιαγραφές λειτουργικών απαιτήσεων (προέρχεται απευθείας από τις προδιαγραφές του πελάτη.)

Παράδειγμα: 'Όταν ο χρήστης πατήσει το εικονίδιο Bluetooth στο Infotainment HMI, θα πρέπει να εμφανίζεται η οθόνη Bluetooth'

(v) Μη λειτουργικές προδιαγραφές απαιτήσεων (π.χ. απόδοση, πίεση, φορτίο κ.λπ.).

Παράδειγμα: 'Θα πρέπει να είναι δυνατή η σύζευξη 15 συσκευών Bluetooth με σύστημα ψυχαγωγίας χωρίς υποβάθμιση της απόδοσης του συστήματος'.

(εμείς) Απαιτήσεις διεπαφής χρήστη.

Παράδειγμα: 'Στην οθόνη Tuner FM, πρέπει να παρέχεται ένα κουμπί για την επιλογή διαφορετικών σταθμών'

Οι παραπάνω απαιτήσεις καταγράφονται και τεκμηριώνονται σε εργαλεία διαχείρισης απαιτήσεων, όπως IBM DOORS, HP QC. Μερικές φορές οι οργανισμοί έχουν τα ειδικά σχεδιασμένα εργαλεία διαχείρισης απαιτήσεων για τη μείωση του κόστους.

Ας εξετάσουμε τώρα τη διαδικασία μετατροπής Επιχειρηματικές απαιτήσεις προς την Απαιτήσεις λογισμικού (λειτουργικό και μη λειτουργικό).

Μετατροπή επιχειρηματικών απαιτήσεων σε απαιτήσεις λογισμικού

Οι επιχειρηματικές απαιτήσεις, όπως συζητήθηκαν παραπάνω είναι απαιτήσεις υψηλού επιπέδου που μιλούν για το τι θέλει ο τελικός χρήστης από μια καθορισμένη ενέργεια στο σύστημα λογισμικού. Δεν είναι δυνατή η ανάπτυξη ολόκληρου του συστήματος λογισμικού βάσει αυτών των απαιτήσεων, καθώς δεν αναφέρεται λεπτομερής περιγραφή του τρόπου με τον οποίο θα εφαρμοστεί το σύστημα λογισμικού ή το στοιχείο.

Έτσι, οι επιχειρηματικές απαιτήσεις πρέπει να αναλυθούν σε πιο λεπτομερείς απαιτήσεις λογισμικού που θα αναλυθούν περαιτέρω σε λειτουργικές και μη λειτουργικές απαιτήσεις.

Για να γίνει αυτό, θα μπορούσαν να ακολουθηθούν τα ακόλουθα βήματα:

1. Αναλύστε τις απαιτήσεις υψηλού επιπέδου για τις αναλυτικές ιστορίες χρηστών.
2. Δημιουργία ενός διαγράμματος ροής για τον καθορισμό της ροής των δραστηριοτήτων.
3. Παροχή της συνθήκης που δικαιολογεί τις παράγωγες ιστορίες χρηστών.
4. Διαγράμματα Wireframe για να εξηγήσουν τη ροή εργασίας των αντικειμένων.
5. Ορισμός μη λειτουργικών απαιτήσεων από τις επιχειρηματικές απαιτήσεις.

Ας ξεκινήσουμε, λαμβάνοντας ένα παράδειγμα συστήματος Automotive Infotainment.

πώς να εφαρμόσετε μια ουρά στο java

Η απαίτηση της επιχείρησης λέει, 'Ο τελικός χρήστης θα πρέπει να έχει πρόσβαση στο πλαίσιο widget πλοήγησης από το σύστημα Infotainment HMI και θα πρέπει να μπορεί να ορίζει τη διεύθυνση προορισμού'.

Έτσι, τα παραπάνω βήματα μπορούν να εφαρμοστούν ως:

# 1) Αναλύστε τις επιχειρηματικές απαιτήσεις υψηλού επιπέδου για λεπτομερείς ιστορίες χρηστών.

Ας μετατρέψουμε αυτήν την απαίτηση επιχείρησης σε ιστορία χρηστών υψηλού επιπέδου, ' Ως χρήστης, θα πρέπει να έχω πρόσβαση στο πλαίσιο widget Πλοήγηση, ώστε να μπορώ να εισαγάγω τη διεύθυνση προορισμού '. Αυτή η ιστορία χρήστη λέει τι χρειάζεται ο τελικός χρήστης. Θα προσπαθήσουμε να καθορίσουμε τον τρόπο εφαρμογής αυτής της απαίτησης.

Ας ξεκινήσουμε ζητώντας πιθανές ερωτήσεις σε αυτήν την ιστορία χρήστη, δηλαδή.

1. Ποιοι είναι οι χρήστες;
2. Πώς μπορώ να έχω πρόσβαση στην Πλοήγηση, στο πλοίο (από κάρτα SD) ή στο SmartPhone;
3. Τι είδους καταχωρήσεις προορισμού μπορώ να εισαγάγω;
4. Πρέπει να μου επιτραπεί να εισέλθω στον προορισμό ακόμα και όταν το αυτοκίνητο βρίσκεται στο χώρο στάθμευσης;

Αυτές είναι πιο λεπτομερείς ιστορίες χρηστών επιπέδου που προέρχονται από ιστορίες χρηστών υψηλού επιπέδου και θα μας βοηθούσαν να λάβουμε περισσότερες πληροφορίες σχετικά με τις επιχειρηματικές μας απαιτήσεις.

Σε αυτό το σημείο, μπορούμε να πάρουμε μία από τις δευτερεύουσες ιστορίες των χρηστών και να αρχίσουμε να αναρωτιόμαστε. Ας πάρουμε (αρ. 3):

1. Μπορώ να καταχωρίσω καταχωρίσεις προορισμού όπως Geo Συντεταγμένες, Ταχυδρομική Διεύθυνση, μέσω Αναγνώρισης Ομιλίας κ.λπ.;
2. Χρειάζομαι GPS για είσοδο σε γεωγραφικές συντεταγμένες;
3. Μπορώ να εισαγάγω την τρέχουσα διεύθυνση προορισμού αναζητώντας από το ιστορικό των διευθύνσεων;

# 2) Δημιουργία διαγράμματος ροής για τον καθορισμό της ροής δραστηριοτήτων.

Τώρα μπορούμε να δούμε ότι η απαίτηση της επιχείρησης κατανέμεται σε πολύ λεπτομερείς περιπτώσεις χρήσης που μπορούν να επισημανθούν στο διάγραμμα ροής όπως παρακάτω:

# 3) Παροχή συνθηκών που δικαιολογούν παράγωγες ιστορίες χρηστών.

Μπορούμε να δούμε ότι αναλυτικότερες πληροφορίες εμφανίζονται λόγω της αποσύνθεσης της επιχειρηματικής απαίτησης υψηλού επιπέδου σε λεπτομερείς ιστορίες χρηστών χαμηλού επιπέδου και στο διάγραμμα ροής. Από αυτό το διάγραμμα ροής, μπορούμε να λάβουμε τις τεχνικές λεπτομέρειες που απαιτούνται για την εφαρμογή, δηλαδή.

• Ο χρόνος φόρτωσης οθόνης για την εμφάνιση της καταχώρησης προορισμού πρέπει να είναι 1 δευτερόλεπτο.
• Το πληκτρολόγιο εισόδου προορισμού πρέπει να έχει αλφαριθμητικούς χαρακτήρες και ειδικά σύμβολα.
• Το κουμπί ενεργοποίησης / απενεργοποίησης GPS πρέπει να υπάρχει στην οθόνη εισαγωγής προορισμού πλοήγησης.

Οι παραπάνω πληροφορίες ικανοποιούν τις ιστορίες των χρηστών και καθιστούν δυνατή τη διακριτική και μετρήσιμη δοκιμή της απαίτησης, αποφεύγοντας οποιαδήποτε σύγχυση με την απαίτηση, ενώ εφαρμόζεται ως χαρακτηριστικά.

# 4) Διαγράμματα Wireframe για να εξηγήσετε τη ροή εργασίας των αντικειμένων.

Από την παραπάνω περίπτωση χρήσης, θα αντλήσουμε ένα διάγραμμα wireframe που θα κάνει το περιβάλλον χρήστη πιο καθαρό.

# 5) Καθορισμός μη λειτουργικών απαιτήσεων από τις επιχειρησιακές απαιτήσεις.

Είναι επιτακτική ανάγκη οι λεπτομερείς απαιτήσεις λογισμικού να προέρχονται από επιχειρηματικές απαιτήσεις υψηλού επιπέδου, αλλά πολλές φορές εντοπίζονται μόνο λειτουργικές απαιτήσεις που αναφέρουν πώς ένα σύστημα θα συμπεριφέρεται σε μια συγκεκριμένη είσοδο / ενέργεια ενός χρήστη.

Ωστόσο, οι λειτουργικές απαιτήσεις δεν αποσαφηνίζουν την απόδοση των συστημάτων και άλλες ποιοτικές παραμέτρους, όπως διαθεσιμότητα, αξιοπιστία κ.λπ.

Παραδείγματα:

α) Θα πάρουμε το παράδειγμα του παραπάνω συστήματος ψυχαγωγίας αυτοκινήτων.

Εάν ο οδηγός (τελικός χρήστης) του αυτοκινήτου παίζει μουσική από USB και βρίσκεται σε εξέλιξη η καθοδήγηση πλοήγησης, λαμβάνει επίσης μια εισερχόμενη κλήση μέσω Bluetooth σε λειτουργία ανοιχτής ακρόασης και, στη συνέχεια, η φόρτωση της CPU και της κατανάλωσης RAM αυξάνεται στο μέγιστο επίπεδο καθώς πολλές διαδικασίες τρέχει στο παρασκήνιο.

Σε αυτό το σημείο, εάν το πρόγραμμα οδήγησης πατήσει μια διεπαφή οθόνης αφής συστήματος ψυχαγωγίας για να απορρίψει τις εισερχόμενες κλήσεις μέσω SMS αυτόματης απάντησης (με τον ίδιο τρόπο που κάνουμε στα κινητά τηλέφωνά μας), το σύστημα θα πρέπει να μπορεί να εκτελεί αυτήν την εργασία και δεν πρέπει να κολλάει ή να συντρίβει. Αυτή είναι η απόδοση του συστήματος όταν το φορτίο είναι υψηλό και δοκιμάζουμε τη διαθεσιμότητα και την αξιοπιστία.

β) Μια άλλη περίπτωση είναι το σενάριο του άγχους.

Ας πάρουμε ένα παράδειγμα, το σύστημα ψυχαγωγίας λαμβάνει πλάτη με πλάτη SMS (ίσως 20 SMS εντός 10 δευτερολέπτων) μέσω συνδεδεμένου τηλεφώνου Bluetooth. Το σύστημα Infotainment θα πρέπει να μπορεί να χειρίζεται όλα τα εισερχόμενα SMS και σε καμία περίπτωση δεν πρέπει να χάσει καμία από τις εισερχόμενες ειδοποιήσεις SMS στο Infotainment HMI.

Τα παραπάνω παραδείγματα είναι περιπτώσεις μη λειτουργικών απαιτήσεων που δεν μπορούσαν να δοκιμαστούν μόνο μέσω λειτουργικών απαιτήσεων. Αν και μερικές φορές, οι πελάτες λείπουν να παρέχουν αυτές τις μη λειτουργικές απαιτήσεις. Είναι ευθύνη του οργανισμού να τους παρέχει αυτές τις πληροφορίες, όταν ένα προϊόν παραδίδεται στον πελάτη.

Κατανόηση περιπτώσεων μη λειτουργικών απαιτήσεων

Ο παρακάτω πίνακας εξηγεί μη λειτουργικές απαιτήσεις:

Οι μη λειτουργικές απαιτήσεις, σε αντίθεση με τις λειτουργικές απαιτήσεις, χρειάζονται πλήρη κύκλο ζωής ενός έργου για υλοποίηση, καθώς υλοποιούνται σταδιακά σε αντίστοιχα Agile Sprints ή σε διαφορετικές επαναλήψεις.

Έτσι, έτσι αντλούμε τις Απαιτήσεις Λογισμικού από Επιχειρηματικές Απαιτήσεις.

Διαφορά μεταξύ επιχειρηματικών απαιτήσεων και απαιτήσεων λογισμικού

Έχουμε δει παραπάνω πώς να αντλήσουμε απαιτήσεις λογισμικού από υψηλού επιπέδου επιχειρηματικές απαιτήσεις. Οι απαιτήσεις λογισμικού επιτρέπουν στον προγραμματιστή και τον μηχανικό δοκιμών να αναπτύξει το σύστημα και να το δοκιμάσει αποτελεσματικά. Γνωρίζουμε λοιπόν ότι οι επιχειρησιακές απαιτήσεις είναι απαιτήσεις φυσικής γλώσσας πελατών υψηλού επιπέδου, ενώ οι απαιτήσεις λογισμικού είναι λεπτομερείς απαιτήσεις χαμηλού επιπέδου που βοηθούν στην εφαρμογή του συστήματος λογισμικού.

Ας εξετάσουμε τη λεπτομερή διαφορά μεταξύ των δύο τύπων απαιτήσεων.

συμπέρασμα

Η ανάλυση απαιτήσεων είναι η ραχοκοκαλιά οποιουδήποτε μοντέλου SDLC.

Ένα πρόβλημα που χάθηκε κατά την ανάλυση των απαιτήσεων και πιάστηκε στη δοκιμή μονάδας θα μπορούσε να κοστίσει δεκάδες χιλιάδες δολάρια για έναν οργανισμό και αυτό το κόστος θα μπορούσε να οδηγήσει σε εκατομμύρια δολάρια εάν προέρχεται από την αγορά ως επιστροφή κλήσης (το 2017, ο κατασκευαστής αερόσακων χρεώθηκε στις ΗΠΑ, Takata a πρόστιμο 1 δισεκατομμυρίου δολαρίων λόγω εκρήξεων αερόσακων).

Ο οργανισμός θα καταλήξει να εκτελεί καθήκοντα ελέγχου ζημιών όπως ανάλυση ριζικών αιτιών, να προετοιμάζει 5 γιατί έγγραφα, ανάλυση δέντρων σφαλμάτων, έγγραφο 8D κ.λπ. αντί να επικεντρώνεται στην ανάπτυξη και την ποιότητα του λογισμικού.

Στις χειρότερες περιπτώσεις, ο οργανισμός θα παρασυρθεί σε νομικές αγωγές που θα υποβληθούν από τον πελάτη εάν η επηρεαζόμενη δυνατότητα σχετίζεται με την ασφάλεια / ασφάλεια, όπως πρόσβαση ασφαλείας, αερόσακος, ABS (σύστημα πέδησης κατά της κλειδαριάς) κ.λπ.

Συνιστώμενη ανάγνωση

• SDLC (Κύκλος Ζωής Ανάπτυξης Λογισμικού) Φάσεις, Μεθοδολογίες, Διαδικασίες και Μοντέλα
• Χαρακτηριστικά λειτουργικών απαιτήσεων και μη λειτουργικών απαιτήσεων
• Πώς να δοκιμάσετε τις προδιαγραφές λογισμικού (SRS);
• 5 Θανατηφόρα λάθη στη διαχείριση απαιτήσεων και πώς να τα ξεπεράσουμε
• Πώς να δοκιμάσετε μια εφαρμογή χωρίς απαιτήσεις;
• Μέτρα για SSDLC (Κύκλος ζωής ασφαλούς ανάπτυξης λογισμικού)
• Spiral Model - Τι είναι το SDLC Spiral Model;
• Τι είναι το μοντέλο SDLC Waterfall;