Τι είναι η μη λειτουργική απαίτηση στη Μηχανική Λογισμικού;

Με: Τσαρλς Μουρ Τσαρλς Μουρ
Hours Ενημερώθηκε

⚡ Έξυπνη Σύνοψη

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

  • 📘 Ορισμός: Μια Μη Λειτουργική Απαίτηση, ή NFR, περιγράφει την απόδοση ενός συστήματος σε όλους τους τομείς: απόδοση, ασφάλεια, χρηστικότητα, αξιοπιστία και φορητότητα.
  • 🗂️ Κοινοί τύποι: Χρηστικότητα, ασφάλεια, αξιοπιστία, επεκτασιμότητα, χωρητικότητα, διαθεσιμότητα, συντηρησιμότητα και κανονιστική συμμόρφωση είναι οι κατηγορίες ομάδων. tracκ πιο συχνά.
  • 📊 Μοντέλο FURPS+: Το FURPS+ ομαδοποιεί τα NFR σε λειτουργικότητα, χρηστικότητα, αξιοπιστία, απόδοση, υποστηριξιμότητα και περιορισμούς σχεδιασμού ή διεπαφής.
  • 🎯 Δηλώσεις που μπορούν να ελεγχθούν: Αντικαταστήστε τις λέξεις «γρήγορο» ή «ασφαλές» με αριθμητικά όρια και μεθόδους επαλήθευσης, ώστε το NFR να μπορεί να δοκιμαστεί και να γίνει αποδεκτό.
  • 🆚 Λειτουργική Αντίθεση: Οι λειτουργικές απαιτήσεις δηλώνουν τι κάνει το σύστημα, ενώ οι μη λειτουργικές απαιτήσεις δηλώνουν πόσο καλά το κάνει υπό πραγματικές συνθήκες.
  • ✅ Επιχειρηματικό αντίκτυπο: Τα ελλείποντα NFR αποτελούν την κύρια αιτία συμβάντων παραγωγής, κανονιστικών ευρημάτων και δαπανηρής ανακατασκευής αρχιτεκτονικής σε προχωρημένο στάδιο.
Περισσότερα

Μη Λειτουργική Απαίτηση στη Μηχανική Λογισμικού

Τι είναι μια μη λειτουργική απαίτηση;

A Μη λειτουργική απαίτηση (NFR) καθορίζει ένα χαρακτηριστικό ποιότητας ενός συστήματος λογισμικού. Τα NFR κρίνουν το σύστημα με βάση την ανταπόκριση, τη χρηστικότητα, την ασφάλεια, τη φορητότητα και άλλα χαρακτηριστικά ποιότητας που είναι κρίσιμα για την επιτυχία. Ένα συνηθισμένο παράδειγμα μη λειτουργικής απαίτησης είναι, "Πόσο γρήγορα φορτώνει ο ιστότοπος;" Η μη εκπλήρωση των μη λειτουργικών απαιτήσεων παράγει συστήματα που αφήνουν τους χρήστες απογοητευμένους.

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

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

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

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

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

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

Παραδείγματα μη λειτουργικών απαιτήσεων

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

  1. Οι χρήστες πρέπει να αλλάξουν τον αρχικό κωδικό πρόσβασης μετά την πρώτη επιτυχημένη σύνδεση και ο αρχικός κωδικός πρόσβασης δεν πρέπει ποτέ να επαναχρησιμοποιηθεί.
  2. Δεν επιτρέπεται στους εργαζομένους να ενημερώνουν τις πληροφορίες μισθού τους και οποιαδήποτε τέτοια προσπάθεια πρέπει να αναφέρεται στον διαχειριστή ασφαλείας.
  3. Κάθε ανεπιτυχής προσπάθεια πρόσβασης σε ένα στοιχείο δεδομένων από έναν χρήστη θα καταγράφεται σε ένα ίχνος ελέγχου.
  4. Ο ιστότοπος θα υποστηρίζει 20 εκατομμύρια ταυτόχρονους χρήστες χωρίς να μειώνεται ο χρόνος απόκρισης.
  5. Το λογισμικό θα πρέπει να είναι φορητό, έτσι ώστε η μετάβαση από το ένα λειτουργικό σύστημα στο άλλο να μην δημιουργεί προβλήματα.
  6. Το απόρρητο των πληροφοριών, η εξαγωγή περιορισμένων τεχνολογιών και τα δικαιώματα πνευματικής ιδιοκτησίας θα υπόκεινται σε έλεγχο.

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

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

Παράμετροι Λειτουργική Απαίτηση Μη λειτουργική απαίτηση
Τι είναι; Ρήμα Γνωρίσματα
Απαίτηση Είναι υποχρεωτικό Είναι μη υποχρεωτικό
Τύπος σύλληψης Αποτυπώνεται σε περίπτωση χρήσης. Αποτυπώνεται ως χαρακτηριστικό ποιότητας.
Τελικό αποτέλεσμα Χαρακτηριστικό προϊόντος Ιδιότητες προϊόντος
Καταγραφή Εύκολη αποτύπωση Δύσκολο να αποτυπωθεί
Σκοπός Σας βοηθά να επαληθεύσετε τη λειτουργικότητα του λογισμικού. Σας βοηθά να επαληθεύσετε την απόδοση του λογισμικού.
Περιοχή εστίασης Εστίαση στις απαιτήσεις των χρηστών Επικεντρώνεται στις προσδοκίες του χρήστη.
Απόδειξη με έγγραφα Περιγράψτε τι κάνει το προϊόν Περιγράφει πώς λειτουργεί το προϊόν
Είδος δοκιμής Λειτουργική δοκιμή όπως Σύστημα, Ενσωμάτωση, Ολοκληρωμένες δοκιμές, δοκιμές API, κ.λπ. Μη λειτουργικές δοκιμές όπως επιδόσεις, άγχος, χρηστικότητα, δοκιμές ασφάλειας κ.λπ.
Εκτέλεση δοκιμής Η εκτέλεση δοκιμής γίνεται πριν από τη μη λειτουργική δοκιμή. Μετά τη λειτουργική δοκιμή
Πληροφορίες προϊόντος Χαρακτηριστικά Προϊόντος Ιδιότητες προϊόντων

ΣΧΕΤΙΚΑ ΑΡΘΡΑ

Πλεονεκτήματα των Μη Λειτουργικών Απαιτήσεων

Τα κύρια οφέλη του Μη λειτουργική δοκιμή είναι:

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

Μειονεκτήματα Μη Λειτουργικών Απαιτήσεων

Τα συνηθισμένα μειονεκτήματα των μη λειτουργικών απαιτήσεων είναι:

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

Μοντέλο FURPS+ για την Ταξινόμηση Μη Λειτουργικών Απαιτήσεων

Το FURPS+ είναι η πιο ευρέως χρησιμοποιούμενη ταξινόμηση για μη λειτουργικές απαιτήσεις. Αρχικά αναπτύχθηκε στην Hewlett-Packard και ομαδοποιεί τα χαρακτηριστικά ποιότητας σε πέντε κύριες κατηγορίες συν πρόσθετους περιορισμούς που σημειώνονται με το σύμβολο "+". Το μοντέλο βοηθά τους Επιχειρηματικούς Αναλυτές να αποφύγουν την παράλειψη μιας ολόκληρης κατηγορίας απαιτήσεων.

  • λειτουργικότητα: Δυνατότητα, ασφάλεια και επαναχρησιμοποίηση που ξεπερνούν τη βασική λίστα χαρακτηριστικών.
  • Ευχρηστία: Ανθρώπινοι παράγοντες, αισθητική, συνέπεια, τεκμηρίωση και ανταπόκριση στην εμπειρία χρήστη.
  • Αξιοπιστία: Διαθεσιμότητα, μέσος χρόνος μεταξύ βλαβών, δυνατότητα ανάρρωσης, προβλεψιμότητα και ακρίβεια.
  • Απόδοση: Ταχύτητα, απόδοση, χωρητικότητα, επεκτασιμότητα και κατανάλωση πόρων υπό φόρτο.
  • Υποστηρισιμότητα: Δυνατότητα δοκιμής, ευελιξία, δυνατότητα εγκατάστασης, δυνατότητα τοπικοποίησης και δυνατότητα συντήρησης του παραδοτέου συστήματος.
  • Συν (+): Σχεδιασμός, υλοποίηση, διεπαφή και φυσικοί περιορισμοί, όπως απαιτούμενες πλατφόρμες, πρότυπα ή υλικό.

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

Πώς να γράψετε δοκιμαστικές μη λειτουργικές απαιτήσεις

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

  1. Προσδιορίστε το χαρακτηριστικό ποιότητας. Αντιστοιχίστε το ζήτημα σε μια κατηγορία FURPS+, ώστε η ομάδα να γνωρίζει εάν πρόκειται για απαίτηση απόδοσης, χρηστικότητας, ασφάλειας ή αξιοπιστίας.
  2. Επιλέξτε μια μέτρηση. Κάθε NFR χρειάζεται μια μονάδα — χιλιοστά του δευτερολέπτου, αιτήματα ανά δευτερόλεπτο, ταυτόχρονους χρήστες, ποσοστό χρόνου λειτουργίας ή ένα πρότυπο συμμόρφωσης όπως το ISO 27001.
  3. Ορίστε ένα αριθμητικό όριο. Αντικαταστήστε τη φράση «γρήγορο» με «κάτω από 400 χιλιοστά του δευτερολέπτου στο 95ο εκατοστημόριο». Αντικαταστήστε τη φράση «υψηλής διαθεσιμότητας» με τη φράση «99.9 τοις εκατό μηνιαίος χρόνος λειτουργίας».
  4. Περιγράψτε την κατάσταση. Αναφέρετε το φορτίο, το περιβάλλον ή το τμήμα χρήστη στο οποίο ισχύει το όριο, όπως «κατά τη διάρκεια των αιχμών πωλήσεων με 10,000 ταυτόχρονους χρήστες».
  5. Ορίστε τη μέθοδο επαλήθευσης. Σημειώστε τον τύπο δοκιμής — δοκιμή φόρτωσης, δοκιμή διείσδυσης, πείραμα χάους, έλεγχος προσβασιμότητας — και το εργαλείο που θα επιβεβαιώσει το όριο.
  6. Εφαρμόστε τον έλεγχο SMART. Επιβεβαιώστε ότι η απαίτηση είναι Συγκεκριμένη, Μετρήσιμη, Εφικτή, Σχετική και Χρονικά Προσδιορισμένη πριν εισέλθει στο ανεκτέλεστο υπόλοιπο.

Παράδειγμα αναδιατύπωσης: Η φράση «Το σύστημα θα είναι γρήγορο» γίνεται «Η σελίδα ολοκλήρωσης αγοράς θα αποκρίνεται σε λιγότερο από 500 χιλιοστά του δευτερολέπτου στο 95ο εκατοστημόριο με 5,000 ταυτόχρονους χρήστες, επαληθευμένοι από JMeter "φόρτωση δοκιμής κάθε έκδοσης." Η αναθεωρημένη δήλωση επιτρέπει στους προγραμματιστές να τη σχεδιάζουν, στους δοκιμαστές να την επαληθεύουν και στους κατόχους προϊόντων να την αποδέχονται χωρίς διαφωνίες.

Συχνές Ερωτήσεις

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

Το Copilot και το GPT μετατρέπουν τις αόριστες δηλώσεις ποιότητας σε μετρήσιμα NFR με μετρήσεις, κατώφλια, συνθήκες και μεθόδους επαλήθευσης. Οι Επιχειρηματικοί Αναλυτές εξετάζουν κάθε προσχέδιο σε σχέση με τις κατηγορίες FURPS+ και το πλαίσιο SMART πριν το αποδεχτούν στο ανεκτέλεστο έργο.

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

Η επεκτασιμότητα, η διαθεσιμότητα, η καθυστέρηση, η ελαστικότητα και η οικονομική αποδοτικότητα κυριαρχούν στα NFRs cloud. Οι ομάδες επίσης tracη παρατηρησιμότητα k, οι στόχοι αποκατάστασης από καταστροφές όπως το RPO και το RTO, και η συμμόρφωση σε πολλαπλές περιοχές, επειδή καθορίζουν τις περισσότερες αποφάσεις για την αρχιτεκτονική cloud.

Επιλέξτε μια μέτρηση με μια μονάδα, ορίστε ένα αριθμητικό όριο, περιγράψτε την συνθήκη υπό την οποία ισχύει και ονομάστε τη μέθοδο επαλήθευσης. Για παράδειγμα, χρόνος απόκρισης κάτω από 400 χιλιοστά του δευτερολέπτου στο 95ο εκατοστημόριο με 5,000 χρήστες, επαληθευμένος από JMeter.

Η κρυπτογράφηση δεδομένων σε κατάσταση αδράνειας και μεταφοράς, η ισχύς ελέγχου ταυτότητας, η εξουσιοδότηση βάσει ρόλων, η καταγραφή ελέγχου, το χρονικό όριο λήξης περιόδου λειτουργίας και η συμμόρφωση με πρότυπα όπως το ISO 27001, το PCI DSS και το GDPR είναι τα NFR ασφαλείας που τεκμηριώνουν οι περισσότερες ομάδες.

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

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

Συνοψίστε αυτήν την ανάρτηση με: