SRS
Λίστα ιστολογίων

Προδιαγραφή απαιτήσεων λογισμικού (SRS): Συμβουλές και πρότυπο

Blog | 6 λεπτό διάβασμα
Γράφτηκε από τον διαχειριστή

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

Προδιαγραφή απαιτήσεων λογισμικού (SRS): Συμβουλές και πρότυπο

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

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

Τι είναι το SRS;

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

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

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

Οφέλη από τη σύνταξη ενός εγγράφου SRS

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

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

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

Όλα τα άλλα έγγραφα - τόσο τεχνικά όσο και επιχειρηματικά - μπορούν να βασίζονται στο SRS για να εγγυηθεί τη συνέπεια και την ακρίβειά του.

Συστατικά ενός SRS

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

  1. Εισαγωγή
    1. Σκοπός
    2. ακροατήριο
    3. Προβλεπόμενη χρήση
    4. Έκταση
    5. Ακρωνύμια και ορισμοί
  2. Γενική περιγραφή
    1. Ανάγκες του χρήστη
    2. Εξαρτήσεις και υπόθεση
  3. Απαιτήσεις και χαρακτηριστικά συστήματος
    1. Λειτουργικές απαιτήσεις
    2. Απαιτήσεις εξωτερικής διεπαφής
    3. Χαρακτηριστικά του συστήματος
    4. Μη λειτουργικές απαιτήσεις

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

εξαγωγή σε λέξη στην καρτέλα

Πώς να γράψετε ένα καλό SRS;

Ένα καλό SRS πρέπει να πληροί πολλά βασικά χαρακτηριστικά. Θα έπρεπε να είναι:

  • Σωστός: Είναι σημαντικό να διασφαλιστεί ότι το SRS αντικατοπτρίζει πάντα τη λειτουργικότητα και τις προδιαγραφές του προϊόντος.
  • Ξεκάθαρος: Είναι καλύτερο να είσαι υπερβολικά συγκεκριμένος παρά διφορούμενος. Το SRS δεν είναι λογοτεχνικό αριστούργημα, οπότε ακόμη και οι πιο βασικοί στυλιστικοί κανόνες μπορούν να αγνοηθούν στο όνομα της σαφήνειας.
  • Πλήρης: Ποτέ δεν είναι καλή ιδέα να παραλείψετε οποιαδήποτε δυνατότητα που ζητά ο πελάτης.
  • Συνεπής: Όλα τα ακρωνύμια και οι ορισμοί πρέπει να χρησιμοποιούνται με συνεπή τρόπο σε όλο το SRS.
  • Κατατάχθηκε για σπουδαιότητα και / ή σταθερότητα: Ο χρόνος είναι συχνά ένας σπάνιος πόρος κατά τη διαδικασία ανάπτυξης, οπότε η κατάταξη των απαιτήσεων ανάλογα με τη σημασία και τη σταθερότητά τους είναι καλή ιδέα.
  • Βεβαιώσιμος: Πρέπει να υπάρχει μέθοδος επαλήθευσης για κάθε απαίτηση.
  • Τροποποιήσιμη: Οι αλλαγές στις απαιτήσεις πρέπει να γίνονται με συστηματικό τρόπο, και αυτές αντίκτυπο σε άλλες απαιτήσεις πρέπει να ληφθεί υπόψη.
  • Ανιχνεύσιμος: Όλες οι απαιτήσεις πρέπει να είναι ανιχνεύσιμες από την προέλευσή τους.
Τρόπος αξιολόγησης των συλλεγόμενων πληροφοριών

Πώς μπορεί το λογισμικό RM να βοηθήσει στη σύνταξη εγγράφων SRS

Είναι απολύτως δυνατό να γράψετε ένα καλό έγγραφο SRS στο Microsoft Word, στα Έγγραφα Google ή σε οποιονδήποτε άλλο επεξεργαστή κειμένου. Το πρόβλημα με αυτήν την προσέγγιση είναι ότι μπορεί να είναι βασανιστικό και χρονοβόρο. Το γεγονός είναι ότι ακόμη και σχετικά απλά σχέδια ανάπτυξης λογισμικού μπορεί να είναι βαρύ απαίτησης. Όταν αλλάζουν οι απαιτήσεις, το όρια της λέξης επεξεργαστές όπως το Microsoft Word αποκαλύπτονται γρήγορα.

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

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

Ανάλυση απαιτήσεων με το ταμπλό του Visure

Συμπέρασμα

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


Άλλα σχετικά άρθρα:

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

Μοιραστείτε στο Twitter
Share on Facebook
Μοιραστείτε στοlinkin
Μοιραστείτε το
Μοιραστείτε με email
Κορυφή