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

features functional requirements

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

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

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

Τι θα μάθετε:

• Λειτουργικές απαιτήσεις και μη λειτουργικές απαιτήσεις
  • Λειτουργικές απαιτήσεις
    • Τύποι λειτουργικών απαιτήσεων
  • Επιχειρηματικές απαιτήσεις Vs Λειτουργικές απαιτήσεις
  • Μη λειτουργική απαίτηση
    • Τύποι μη λειτουργικών απαιτήσεων
  • Απόκτηση μη λειτουργικών απαιτήσεων από λειτουργικές απαιτήσεις
• Λειτουργικές Vs Μη λειτουργικές απαιτήσεις
• συμπέρασμα
  • Συνιστώμενη ανάγνωση

Λειτουργικές απαιτήσεις και μη λειτουργικές απαιτήσεις

Λειτουργικές απαιτήσεις

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

Παράδειγμα: Σε ένα έργο Automotive ADAS, μια λειτουργική απαίτηση συστήματος surround-view θα μπορούσε να είναι «Η πίσω κάμερα θα πρέπει να εντοπίσει μια απειλή ή ένα αντικείμενο». Οι μη λειτουργικές απαιτήσεις εδώ θα μπορούσαν να είναι «πόσο γρήγορα πρέπει να εμφανίζεται η ειδοποίηση σε έναν χρήστη όταν εντοπίζεται απειλή από αισθητήρες κάμερας».

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

τι να ανοίξετε αρχεία bin

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

Τύποι λειτουργικών απαιτήσεων

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

# 1) Διαλειτουργικότητα: Η απαίτηση περιγράφει εάν ένα σύστημα λογισμικού είναι διαλειτουργικό σε διαφορετικά συστήματα.

Παράδειγμα: Για τη λειτουργική απαίτηση Bluetooth στο σύστημα Infotainment αυτοκινήτου, όταν ο χρήστης συνδέει ένα Bluetooth με Android με δυνατότητα Bluetooth σε ένα σύστημα ψυχαγωγίας που βασίζεται σε QNX, θα πρέπει να μπορούμε να μεταφέρουμε τον Τηλεφωνικό κατάλογο στο σύστημα ψυχαγωγίας ή να μεταδίδουμε μουσική από τη Τηλεφωνική μας συσκευή στο σύστημα ψυχαγωγίας.

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

Αλλο παράδειγμα προέρχεται από συστήματα υπηρεσιών email όπως το Gmail. Το Gmail επιτρέπει την εισαγωγή μηνυμάτων ηλεκτρονικού ταχυδρομείου από άλλο διακομιστή ανταλλαγής αλληλογραφίας, όπως το Yahoo.com ή το Rediffmail.com. Αυτό είναι δυνατό λόγω της διαλειτουργικότητας μεταξύ των διακομιστών email.

# 2) Ασφάλεια: Η λειτουργική Η απαίτηση περιγράφει την πτυχή ασφάλειας των απαιτήσεων λογισμικού.

Παράδειγμα: Υπηρεσίες που βασίζονται στην ασφάλεια στον κυβερνοχώρο στο σύστημα με βάση την κάμερα ADAS surround-view που χρησιμοποιεί το Controller Area Network (CAN) που προστατεύει το σύστημα από την απειλή ασφαλείας.

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

# 3) Ακρίβεια: Η ακρίβεια ορίζει ότι τα δεδομένα που εισάγονται στο σύστημα υπολογίζονται σωστά και χρησιμοποιούνται από το σύστημα και ότι η έξοδος είναι σωστή.

Παράδειγμα: Στο Δίκτυο Περιοχής Ελεγκτή, όταν μια τιμή σήματος CAN μεταδίδεται μέσω διαύλου CAN από ένα ECU (π.χ. μονάδα ABS, μονάδα HVAC, μονάδα συμπλέγματος οργάνων, κ.λπ.), ένα άλλο ECU θα είναι σε θέση να προσδιορίσει εάν τα δεδομένα που αποστέλλονται είναι σωστά ή όχι μέσω ελέγχου CRC.

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

# 4) Συμμόρφωση: Οι λειτουργικές απαιτήσεις συμμόρφωσης επιβεβαιώνουν ότι το ανεπτυγμένο σύστημα συμμορφώνεται με τα βιομηχανικά πρότυπα.

Παράδειγμα: Εάν οι λειτουργίες προφίλ Bluetooth (π.χ. ροή ήχου μέσω A2DP, Τηλεφωνική κλήση μέσω HFP) είναι συμβατές με τις εκδόσεις προφίλ κυκλοφορίας Bluetooth SIG.

Αλλο παράδειγμα μπορεί να είναι αυτό του παιχνιδιού της Apple Car στο σύστημα ψυχαγωγίας αυτοκινήτου. Η εφαρμογή στο infotainment λαμβάνει ένα πιστοποιητικό από μήλο εάν όλες οι προϋποθέσεις που αναφέρονται στον ιστότοπο της Apple πληρούνται από συσκευές Car Play τρίτων (infotainment σε αυτήν την περίπτωση).

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

Παράδειγμα φόρμας απαίτησης:

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

Ακολουθούν μερικά χαρακτηριστικά που πρέπει να ληφθούν υπόψη:

1. Τύπος αντικειμένου: Αυτό το χαρακτηριστικό εξηγεί ποια ενότητα του εγγράφου απαίτησης είναι μέρος αυτού του χαρακτηριστικού. Θα μπορούσαν να είναι Επικεφαλίδα, Επεξήγηση, Απαίτηση κ.λπ. Συνήθως η ενότητα 'Απαίτηση' θεωρείται για την εφαρμογή και τη δοκιμή ενώ οι ενότητες επικεφαλίδας και επεξηγήσεων χρησιμοποιούνται ως υποστηρικτικές περιγραφές για απαιτήσεις για καλύτερη κατανόηση.
2. Υπεύθυνο άτομο: Ένας συγγραφέας που έχει τεκμηριώσει την απαίτηση στο εργαλείο διαχείρισης απαιτήσεων.
3. Όνομα έργου / συστήματος: Το Έργο για το οποίο ισχύει η απαίτηση, για παράδειγμα, 'Συστήματα Infotainment για XYZ OEM (Original Equipment Manufacturer) μια αυτοκινητοβιομηχανία ή μια εφαρμογή Ιστού για την ABC banking limited company'.
4. Αριθμός έκδοσης απαιτήσεων: Αυτό το πεδίο / χαρακτηριστικό ειδοποιεί τον αριθμό έκδοσης της απαίτησης εάν η απαίτηση έχει υποστεί πολλαπλές τροποποιήσεις λόγω ενημερώσεων πελατών ή αλλαγών στη σχεδίαση συστήματος.
5. Αναγνωριστικό απαίτησης: Αυτό το χαρακτηριστικό αναφέρει το μοναδικό αναγνωριστικό απαίτησης. Το Αναγνωριστικό Απαίτησης χρησιμοποιείται για την εύκολη παρακολούθηση των απαιτήσεων στη βάση δεδομένων και επίσης για την αποτελεσματική χαρτογράφηση των απαιτήσεων στον κώδικα. Μπορεί επίσης να χρησιμοποιηθεί για να παρέχει αναφορά σε απαιτήσεις κατά την καταγραφή ελαττωμάτων σε εργαλεία εντοπισμού σφαλμάτων.
6. Περιγραφή απαιτήσεων: Αυτό το χαρακτηριστικό είναι ένα από τα πιο σημαντικά χαρακτηριστικά που εξηγούν την απαίτηση. Διαβάζοντας αυτό το χαρακτηριστικό, ένας μηχανικός θα μπορούσε να κατανοήσει την απαίτηση.
7. Κατάσταση απαίτησης: Το χαρακτηριστικό κατάστασης απαίτησης αναφέρει σχετικά με την κατάσταση μιας απαίτησης στο εργαλείο διαχείρισης απαιτήσεων, δηλαδή εάν είναι αποδεκτό, σε αναμονή, απορρίπτεται ή διαγράφεται το έργο.
8. Σχόλια: Αυτό το χαρακτηριστικό παρέχει στον Υπεύθυνο άτομο ή διαχειριστή απαίτησης την επιλογή τεκμηρίωσης τυχόν σχολίων σχετικά με την απαίτηση. Παράδειγμα: ένα πιθανό σχόλιο για μια λειτουργική απαίτηση θα μπορούσε να είναι «εξάρτηση από ένα πακέτο λογισμικού τρίτου μέρους για την εφαρμογή της απαίτησης».

Ένα στιγμιότυπο από τις ΠΟΡΤΕΣ

Απόκτηση λειτουργικών απαιτήσεων από επιχειρηματικές απαιτήσεις

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

Επιχειρηματικές απαιτήσεις Vs Λειτουργικές απαιτήσεις

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

Μη λειτουργική απαίτηση

Η μη λειτουργική απαίτηση λέει για το «τι πρέπει να είναι ένα σύστημα» και όχι «τι πρέπει να κάνει ένα σύστημα» (λειτουργική απαίτηση). Προέρχονται ως επί το πλείστον από λειτουργικές απαιτήσεις που βασίζονται σε στοιχεία του πελάτη και άλλων ενδιαφερομένων. Οι μη λειτουργικές λεπτομέρειες εφαρμογής απαιτούνται στο έγγραφο Αρχιτεκτονικής συστήματος.

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

URPS (Χρηστικότητα, αξιοπιστία, απόδοση και υποστήριξη) από ΦΟΥΡΠΑ Τα χαρακτηριστικά ποιότητας (λειτουργικότητα, ευχρηστία, αξιοπιστία, απόδοση και υποστήριξη) που χρησιμοποιούνται ευρέως στη βιομηχανία πληροφορικής για τη μέτρηση της ποιότητας ενός προγραμματιστή λογισμικού, καλύπτονται όλα σε μη λειτουργικές απαιτήσεις. Εκτός αυτού, υπάρχουν και άλλα χαρακτηριστικά ποιότητας (λεπτομέρειες στην επόμενη ενότητα).

Η Wikipedia αποκαλεί τη μη λειτουργική απαίτηση ως «ilities» μερικές φορές, λόγω της παρουσίας διαφόρων ποιοτικών χαρακτηριστικών όπως η φορητότητα και η σταθερότητα.

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

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

# 1) Απόδοση:

Ένας τύπος χαρακτηριστικού απόδοσης μη λειτουργικής απαίτησης μετρά την απόδοση του συστήματος. Παράδειγμα: Στο σύστημα AD View surround, «η οπίσθια όψη της κάμερας θα πρέπει να εμφανίζεται εντός 2 δευτερολέπτων από την έναρξη της ανάφλεξης του αυτοκινήτου».

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

Να θυμάστε ότι η μέτρηση απόδοσης του συστήματος διαφέρει από τη μέτρηση φορτίου. Κατά τη διάρκεια της δοκιμής φόρτωσης, φορτώνουμε τη CPU του συστήματος και τη μνήμη RAM και ελέγχουμε την απόδοση του συστήματος. Στην περίπτωση απόδοσης, δοκιμάζουμε την απόδοση του συστήματος σε κανονικές συνθήκες φορτίου / τάσης.

# 2) Ευχρηστία :

Η χρηστικότητα μετρά τη χρηστικότητα του συστήματος λογισμικού που αναπτύσσεται.

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

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

# 3) Συντηρησιμότητα :

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

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

Παράδειγμα: Αναπτύσσεται ένα σύστημα λογισμικού που έχει τον υψηλό αριθμό νεκρών κωδικών (κωδικοί που δεν χρησιμοποιούνται από άλλες λειτουργίες ή λειτουργικές μονάδες), πολύ περίπλοκος λόγω υπερβολικής χρήσης της κατάστασης if / else, ένθετων βρόχων κ.λπ. ή εάν το σύστημα είναι τεράστιο με κώδικες που εκτελούνται σε πολλές εκατομμύρια γραμμές κωδικών και χωρίς κατάλληλα σχόλια. Ένα τέτοιο σύστημα έχει χαμηλή δυνατότητα συντήρησης.

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

# 4) Αξιοπιστία :

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

Παράδειγμα: Αμοιβαία αποκλειστικές δυνατότητες όπως η κάμερα οπισθοπορείας και το Trailer στο σύστημα κάμερας surround ADAS θα πρέπει να λειτουργούν αξιόπιστα στο σύστημα χωρίς παρεμβολές μεταξύ τους. Όταν ένας χρήστης καλεί τη λειτουργία Trailer, η οπίσθια όψη δεν πρέπει να παρεμβαίνει και το αντίστροφο, καθώς και οι δύο λειτουργίες έχουν πρόσβαση στην πίσω κάμερα του αυτοκινήτου.

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

# 5) Φορητότητα:

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

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

Ας πάρουμε ένα άλλο παράδειγμα από το WhatsApp. Είναι δυνατή η εγκατάσταση και η χρήση της υπηρεσίας ανταλλαγής μηνυμάτων σε IOS, Android, Windows, Tablet, φορητό υπολογιστή και τηλέφωνο.

# 6) Υποστήριξη:

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

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

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

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

# 7) Προσαρμοστικότητα:

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

Παράδειγμα: Το σύστημα αντιμπλοκαρίσματος πέδησης στο αυτοκίνητο πρέπει να λειτουργεί σύμφωνα με το πρότυπο σε όλες τις καιρικές συνθήκες (ζεστό ή κρύο). Αλλο παράδειγμα θα μπορούσε να είναι αυτό ενός λειτουργικού συστήματος Android. Χρησιμοποιείται σε διαφορετικούς τύπους συσκευών, δηλαδή. Smartphone, υπολογιστές tablet και συστήματα ψυχαγωγίας και είναι εξαιρετικά προσαρμόσιμα.

Εκτός από τις 7 μη λειτουργικές απαιτήσεις που αναφέρονται παραπάνω, έχουμε πολλές άλλες όπως:

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

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

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

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

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

# 1) Συλλογή μη λειτουργικών απαιτήσεων:

πώς να βρείτε κλειδί ασφαλείας στο δρομολογητή

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

# 2) Κατηγοριοποίηση μη λειτουργικών απαιτήσεων:

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

Στην παρακάτω εικόνα μπορείτε να δείτε τα πιθανά χαρακτηριστικά ποιότητας που προσδιορίζονται από τις απαντήσεις.

Λειτουργικές Vs Μη λειτουργικές απαιτήσεις

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

συμπέρασμα

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

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

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

• Πώς να δοκιμάσετε τις προδιαγραφές λογισμικού (SRS);
• Λειτουργική δοκιμή εναντίον μη λειτουργική δοκιμή
• Πώς να δοκιμάσετε μια εφαρμογή χωρίς απαιτήσεις;
• Τι είναι η ανάλυση απαιτήσεων και η συγκέντρωση στο SDLC;
• 5 Θανατηφόρα λάθη στη διαχείριση απαιτήσεων και πώς να τα ξεπεράσουμε
• Χαρακτηριστικά λειτουργικών απαιτήσεων και μη λειτουργικών απαιτήσεων
• Τρόπος δημιουργίας απαιτήσεων Πίνακας ιχνηλασιμότητας (RTM): Παράδειγμα και πρότυπο δείγματος
• Top 20+ Εργαλεία διαχείρισης καλύτερων απαιτήσεων (Ο πλήρης κατάλογος)