Λύσεις Visure


Υποστήριξη
Εγγραφείτε
Είσοδος
Ξεκινήστε δωρεάν δοκιμή

Τι είναι Προδιαγραφές Απαιτήσεων: Ορισμός, Καλύτερα Εργαλεία & Τεχνικές | Οδηγός

Πίνακας περιεχομένων

Τι είναι Προδιαγραφές Απαιτήσεων: Ορισμός, Καλύτερα Εργαλεία & Τεχνικές | Οδηγός

Η προδιαγραφή απαιτήσεων είναι ένα κρίσιμο μέρος της διαδικασίας Τεχνολογίας Απαιτήσεων. Είναι η τρίτη φάση, μετά το Requirements Capture and Analysis. Ο στόχος είναι να δημιουργήσετε ένα έγγραφο, ή Προδιαγραφή Απαιτήσεων, με το αντίστοιχο επίπεδο λεπτομέρειας. Αυτό το έγγραφο θα περιέχει όλες τις απαιτήσεις που πρέπει να επιβάλλονται στον σχεδιασμό και την επαλήθευση του προϊόντος. Θα περιέχει επίσης άλλες σχετικές πληροφορίες απαραίτητες για το σχεδιασμό, την επαλήθευση και τη συντήρηση του προϊόντος.

Τι είναι η προδιαγραφή απαιτήσεων;

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

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

Τι είναι η Απαίτηση Συστήματος;

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

Τι είναι η Απαίτηση Χρήστη;

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

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

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

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

  • Διεπαφής χρήστη
  • Αξιοπιστία 
  • Ασφάλεια
  • επίδοση
  • Συντήρηση
  • Πρότυπα 

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

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

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

Ποια είναι τα οφέλη από την ύπαρξη προδιαγραφής απαιτήσεων;

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

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

Πρότυπα για τις απαιτήσεις γραφής;

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

Για να επιτευχθεί αυτό, ακολουθούν ορισμένες αρχές που πρέπει να έχετε υπόψη κατά τη σύνταξη των απαιτήσεων. Περιλαμβάνουν:

  • Κάθε απαίτηση πρέπει να έχει τη μορφή πλήρους πρότασης. Δεν πρέπει να χρησιμοποιούνται κουκκίδες, ακρωνύμια, συντομογραφίες ή τσιτάτα. Προσπαθήστε να κάνετε σύντομες, άμεσες και ολοκληρωμένες προτάσεις. 
  • Βεβαιωθείτε ότι κάθε απαίτηση έχει ένα σωστό θέμα, κατηγόρημα και ρήμα. Το θέμα θα ήταν ο τύπος χρήστη ή το σύστημα για το οποίο μιλάμε. Το κατηγόρημα θα ήταν οι συνθήκες ή οι ενέργειες ή τα επιθυμητά αποτελέσματα που αναμένουμε. Πρέπει να χρησιμοποιούμε λέξεις όπως «θα», «θα» και «πρέπει» για να εκφράσουμε κάποιο είδος αναγκαιότητας και λέξεις όπως «μπορεί» για να εκφράσουμε την προαιρετικότητα στην απαίτηση. 
  • Κάθε απαίτηση πρέπει να εξηγεί αποτελεσματικά το τελικό αποτέλεσμα που επιθυμούμε από το σύστημα. 
  • Επίσης, η απαίτηση πρέπει να περιγράφει την ποιότητα που περιμένουμε από το σύστημα. Βοηθά όταν μετράμε το τελικό αποτέλεσμα και βλέπουμε αν η απαίτηση εφαρμόζεται σωστά ή όχι.

Τύποι Προδιαγραφών Απαιτήσεων:

Υπάρχουν πολλά είδη προδιαγραφών απαιτήσεων. Περιλαμβάνουν Προδιαγραφές λειτουργικών απαιτήσεων (FRS), Προδιαγραφές Απαιτήσεων Απόδοσης (PRS), Προδιαγραφές Απαιτήσεων Διαμόρφωσης (CRF), Προδιαγραφές Απαιτήσεων Επιχειρήσεων (BRS), Προδιαγραφές Απαίτησης Αξιοπιστίας (RRF), Προδιαγραφές Απαιτήσεων Συμβατότητας (CRS) και Προδιαγραφές Απαιτήσεων Λογισμικού (CRS) ).

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

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

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

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

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

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

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

Προδιαγραφές Απαιτήσεων Λογισμικού έναντι Προδιαγραφών Απαιτήσεων Επιχειρήσεων:

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

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

Προδιαγραφές Επιχειρηματικών Απαιτήσεων (BRS)Προδιαγραφή Απαιτήσεων Λογισμικού (SRS)
Είναι ένα επίσημο έγγραφο που περιγράφει τις διάφορες απαιτήσεις που παρέχονται από τον πελάτη/τα ενδιαφερόμενα μέρη.Καθορίζει τις λειτουργικές και μη λειτουργικές απαιτήσεις που υπάρχουν στο λογισμικό. 
Προέρχεται από τις απαιτήσεις και τις αλληλεπιδράσεις του πελάτη.Προέρχεται από την Προδιαγραφή Επιχειρηματικών Απαιτήσεων (BRS).
Δημιουργείται από επιχειρηματικό αναλυτή.Δημιουργείται από έναν αναλυτή συστήματος ή έναν αρχιτέκτονα συστημάτων ή έναν αναλυτή επιχειρήσεων. 
Περιγράφει τις λειτουργικές προδιαγραφές του λογισμικού σε πολύ υψηλό επίπεδο.Περιγράφει τόσο τις τεχνικές όσο και τις λειτουργικές προδιαγραφές του λογισμικού επίσης σε υψηλό επίπεδο.
Ασχολείται με τις επιχειρηματικές απαιτήσεις.Ασχολείται με τους πόρους που παρέχει η εταιρεία.
Καθορίζει τις ανάγκες του πελάτη. Το έγγραφο χρησιμοποιείται από την αρχή μέχρι το τέλος του έργου.Περιγράφει πώς λειτουργεί η επιχείρηση κατά τη χρήση του λογισμικού ή της εφαρμογής.
Δεν περιλαμβάνονται πίνακες και θήκες χρήσης.Περιλαμβάνονται πίνακες και θήκες χρήσης.

Χαρακτηριστικά ενός εγγράφου προδιαγραφής απαιτήσεων λογισμικού:

  • Ακριβής – Ο στόχος ενός εγγράφου SRS είναι να είναι απλό στην κατανόηση. Τίποτα δεν πρέπει να είναι ασαφές, επομένως δεν υπάρχουν διαφωνίες μεταξύ των ενδιαφερομένων.
  • Μετρήσιμα – Οι απαιτήσεις στο έγγραφό σας SRS πρέπει να είναι μετρήσιμες, επομένως το τελικό προϊόν μπορεί να επικυρωθεί και να πιστοποιηθεί ως προς τις απαιτήσεις.
  • Πλήρης – Το έγγραφο SRS θα πρέπει να περιλαμβάνει αρκετές πληροφορίες για την ομάδα ανάπτυξης και τους δοκιμαστές σας για να ολοκληρώσουν το προϊόν και να διασφαλίσουν ότι πληροί τις απαιτήσεις του χρήστη χωρίς σφάλματα.
  • Εφικτός – Οι απαιτήσεις πρέπει να αντικατοπτρίζουν την πραγματική κατάσταση των πραγμάτων, συμπεριλαμβανομένου του κόστους, του χρονοδιαγράμματος και της τεχνολογίας. Δεν θα πρέπει να εξαρτώνται από μελλοντικές τεχνολογικές εξελίξεις.
  • Ευέλικτο – Επειδή οι συνθήκες ενδέχεται να αλλάξουν στον χώρο εργασίας, το έγγραφό σας SRS θα πρέπει να είναι αρκετά προσαρμόσιμο ώστε να δέχεται αλλαγές. Μην συμπεριλαμβάνετε περιττό υλικό σε πολλές ενότητες που θα πρέπει να ενημερώνονται κάθε φορά που υπάρχει μετατόπιση.
  • Βεβαιώσιμος – Όλοι στην ομάδα ανάπτυξης θα πρέπει να έχουν πρόσβαση στο έγγραφο, ώστε να μπορούν να αναφέρονται σε αυτό όσο συχνά απαιτείται. Επειδή οι απαιτήσεις πρέπει να είναι σαφείς, τα μέλη της ομάδας δεν θέλουν περισσότερες πληροφορίες. Θα πρέπει να είναι όλα προσβάσιμα στο έγγραφο SRS.
  • Συνεπής – Οι απαιτήσεις πρέπει να είναι συμβατές. Δεν πρέπει να υπάρχει αντίφαση μεταξύ τμημάτων του εγγράφου απαίτησής σας. Το έγγραφο θα πρέπει να είναι δομημένο με συνέπεια και η ορολογία να χρησιμοποιείται με τον ίδιο τρόπο σε όλη τη διάρκεια.
  • Χωρίς περιορισμούς υλοποίησης – Γενικά, ένα έγγραφο SRS θα πρέπει να είναι αρκετά λεπτομερές για να ολοκληρώσει τη δουλειά, αλλά όχι τόσο συγκεκριμένο ώστε να σταματήσει την ανάπτυξη. Ένα μεγάλο μέρος της ανάπτυξης βασίζεται σε υπηρεσίες τρίτων που οι προγραμματιστές δεν έχουν κανέναν έλεγχο.
  • Ακριβής – Οι απαιτήσεις που καθορίζονται στα έγγραφα πρέπει να είναι πολύ ακριβείς για να αποφευχθεί κάθε είδους σύγχυση. Δεν πρέπει να έχουν κενά, ασάφειες, υποκειμενικότητα, υπερθετικά ή συγκρίσεις.

Βασικά στοιχεία ενός SRS:

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

  • Οδηγοί επιχειρήσεων – Οι λόγοι για τους οποίους ο πελάτης θέλει να δημιουργήσει ένα σύστημα περιγράφονται σε αυτήν την ενότητα. Αυτή η ενότητα περιλαμβάνει περαιτέρω τα προβλήματα που αντιμετωπίζει ο πελάτης με το τρέχον σύστημα και τις ευκαιρίες που θα παρέχει το νέο σύστημα.
  • Επιχειρηματικό Μοντέλο – Το επιχειρηματικό μοντέλο που καλείται να υποστηρίξει το σύστημα συζητείται σε αυτήν την ενότητα. Περιλαμβάνει επίσης διάφορες άλλες λεπτομέρειες, όπως το οργανωτικό και επιχειρηματικό πλαίσιο, τις κύριες επιχειρηματικές λειτουργίες και τα διαγράμματα ροής διεργασιών του συστήματος.
  • Λειτουργικές και Απαιτήσεις Συστήματος – Αυτή η ενότητα περιγράφει συνήθως τις απαιτήσεις που είναι οργανωμένες σε ιεραρχική δομή. Οι λειτουργικές απαιτήσεις βρίσκονται στο ανώτατο επίπεδο και οι λεπτομερείς απαιτήσεις συστήματος παρατίθενται ως υποστοιχεία.
  • Περιπτώσεις χρήσης συστήματος – Αυτή η ενότητα αποτελείται από ένα διάγραμμα περιπτώσεων χρήσης της Ενοποιημένης Γλώσσας Μοντελοποίησης (UML) που εξηγεί όλες τις βασικές εξωτερικές οντότητες που θα αλληλεπιδρούν με το σύστημα και τις διαφορετικές περιπτώσεις χρήσης που θα πρέπει να εκτελέσουν.
  • Τεχνικές απαιτήσεις – Αυτή η ενότητα συζητά όλες τις μη λειτουργικές απαιτήσεις που συνθέτουν το τεχνικό περιβάλλον και τους τεχνικούς περιορισμούς στους οποίους θα λειτουργεί το λογισμικό.  
  • Ποιότητες Συστήματος – Σε αυτήν την ενότητα, ορίζονται οι πολυάριθμες ιδιότητες του συστήματος, όπως η αξιοπιστία, η δυνατότητα συντήρησης, η ασφάλεια, η επεκτασιμότητα, η διαθεσιμότητα και η συντηρησιμότητα.
  • Περιορισμοί και Υποθέσεις – Αυτή η ενότητα περιγράφει όλους τους περιορισμούς που επιβάλλονται στη σχεδίαση του συστήματος από την πλευρά του πελάτη. Οι διάφορες υποθέσεις της ομάδας μηχανικών σχετικά με το τι να περιμένουμε κατά την ανάπτυξη συζητούνται επίσης εδώ.
  • Κριτήρια αποδοχής – Λεπτομέρειες σχετικά με όλες τις προϋποθέσεις που πρέπει να πληρούνται πριν από την παράδοση του συστήματος στους τελικούς πελάτες συζητούνται σε αυτήν την ενότητα.

Δομή ενός SRS:

1. Εισαγωγή -

Η εισαγωγή εξηγεί τη σημασία του SRS γενικά, το πεδίο εφαρμογής του για την ομάδα σας και τη δομή του.

1.1. Σκοπός

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

Κρατήστε αυτή την ενότητα σύντομη: 1-2 παράγραφοι είναι αρκετές.

1.2. Κοινό στο οποίο απευθύνεται

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

1.3. Προβλεπόμενη χρήση

Περιγράψτε σε ποιες περιπτώσεις η ομάδα σας θα χρησιμοποιήσει το SRS. Συνήθως, χρησιμοποιείται στις ακόλουθες περιπτώσεις:

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

1.4. Πεδίο Εφαρμογής

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

Αυτή η ενότητα πρέπει να περιγράφει:

  • Όλοι οι τύποι χρηστών που αναμένεται να συνεργαστούν με το σύστημα
  • Όλα τα βασικά μέρη της αρχιτεκτονικής

1.5 Ορισμοί και Ακρωνύμια

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

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

2. Συνολική περιγραφή

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

2.1 Ανάγκες χρήστη

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

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

2.2 Υποθέσεις και εξαρτήσεις

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

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

3. Λειτουργίες και απαιτήσεις συστήματος

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

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

Οι λειτουργικές απαιτήσεις αναφέρονται σε μια λίστα λειτουργιών που θα εκτελεστούν σε ένα σύστημα. Αυτά τα κριτήρια αφορούν το «τι θα δημιουργηθεί;» αντί «πώς» και «πότε».

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

3.2 Απαιτήσεις εξωτερικής διεπαφής

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

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

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

  • διεπαφή χρήστη
  • Διεπαφή λογισμικού
  • Διεπαφή υλικού
  • Διεπαφή επικοινωνίας

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

3.3 Απαιτήσεις συστήματος

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

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

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

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

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

Απαιτήσεις Visure Πλατφόρμα ALM:

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

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

Συμπέρασμα:

Η προδιαγραφή απαιτήσεων είναι ένα έγγραφο που περιγράφει τις συγκεκριμένες ανάγκες ενός έργου ή ενός συστήματος. Η προδιαγραφή των απαιτήσεων είναι σημαντική γιατί χρησιμεύει ως βάση για όλες τις μελλοντικές εργασίες στο έργο. Η προδιαγραφή απαιτήσεων λογισμικού (SRS) είναι διαφορετική από την προδιαγραφή επιχειρηματικών απαιτήσεων (BRS), αν και σχετίζονται. Το SRS εστιάζει στο τι πρέπει να κάνει το σύστημα, ενώ το BRS εστιάζει στο γιατί το σύστημα χρειάζεται και πώς θα χρησιμοποιηθεί. Η δομή ενός εγγράφου απαιτήσεων λογισμικού μπορεί να ποικίλλει, αλλά θα πρέπει πάντα να περιλαμβάνει ενότητες σχετικά με το σκοπό, το εύρος, τις λειτουργίες, τα χαρακτηριστικά, τους περιορισμούς, τις υποθέσεις και τις εξαρτήσεις. Απαιτήσεις Visure Η πλατφόρμα ALM σάς βοηθά να δημιουργείτε και να διαχειρίζεστε το SRS σας με ευκολία. Ζητήστε μια δωρεάν δοκιμή 30 ημερών στην πλατφόρμα Visure Requirements ALM για να δείτε πώς το εργαλείο μας μπορεί να βοηθήσει τα έργα σας να λειτουργούν πιο ομαλά.

Μην ξεχάσετε να μοιραστείτε αυτήν την ανάρτηση!

Λογισμικό IBM Rational Doors
Η Κορυφαία