Γιατί πρέπει να κατανοήσετε τις απαιτήσεις λογισμικού ως μηχανικός λογισμικού

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

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

Αυτό το άρθρο δανείζεται σε μεγάλο βαθμό από τον τόμο που είναι ο οδηγός IEEE SWEBOK. Προσπαθεί να αποστάξει μέρος αυτής της γνώσης, επαναπροσδιορίζοντάς την πιο συγκεκριμένα. Σε περίπτωση που αναρωτιέστε, το SWEBOK είναι ένα αρκτικόλεξο για το Σώμα της Γνώσης Τεχνολογίας Λογισμικού που διατηρείται από την IEEE Computer Society.

Εκ των προτέρων, γιατί είναι σημαντικό;

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

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

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

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

Τι είναι οι απαιτήσεις λογισμικού;

Οι απαιτήσεις λογισμικού στην επιφάνεια ακούγονται απλές. Το λογισμικό πρέπει να κάνει το X για το Υ, έτσι ώστε το Ζ. Σκεφτείτε το για αρκετό καιρό σε οποιοδήποτε πρόβλημα που θα μπορούσε να λύσει το λογισμικό (ή σχετικά με το υπάρχον λογισμικό που ήδη επιλύει ένα πρόβλημα) και πιθανότατα θα μπορούσατε να κάνετε ανταλλαγή απόψεων για μεγάλο αριθμό απαιτήσεων. Εύκολο, σωστά;

Όχι, στην πραγματικότητα, για τα περισσότερα εταιρικά λογισμικά.

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

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

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

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

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

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

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

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

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

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

Τι εμπλέκεται στις απαιτήσεις λογισμικού για τον μηχανικό λογισμικού;

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

Περιοχές όπου μπορεί να εμπλακείτε:

  • Elicitation - η συλλογή απαιτήσεων για το λογισμικό
  • Ταξινόμηση - κατηγοριοποίηση της απαίτησης
  • Επικύρωση - επιβεβαίωση της απαίτησης με τα ενδιαφερόμενα μέρη
  • Ανάπτυξη & Εφαρμογή - δημιουργία λογισμικού για την κάλυψη των απαιτήσεων
  • Διαπραγμάτευση - αντιμετώπιση συγκρούσεων συμφερόντων με τα ενδιαφερόμενα μέρη
  • Επαλήθευση - η αξιολόγηση της λειτουργίας λογισμικού ικανοποιεί την απαίτηση

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

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

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

Δεν υπάρχει σύστημα διαχείρισης απαιτήσεων ...

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

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

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

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

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

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

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

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

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

Εκπλήρωση Απαιτήσεων Λογισμικού

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

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

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

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

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

Από πού προέρχονται οι απαιτήσεις λογισμικού;

Υπάρχουν πολλές πηγές στις απαιτήσεις, όπως:

  • Στόχοι (επίσης γνωστοί ως επιχειρηματικό ενδιαφέρον, κρίσιμος παράγοντας επιτυχίας κ.λπ.)
  • Πεδίο γνώσης
  • Ενδιαφερόμενα μέρη
  • Επιχειρηματικοί κανόνες
  • Λειτουργικό περιβάλλον

Εάν ασχολείστε με την αναζήτηση από πηγές, θα πρέπει:

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

Πώς μπορώ να λάβω τις απαιτήσεις λογισμικού;

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

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

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

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

Ταξινόμηση Απαιτήσεων Λογισμικού

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

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

Οι τύποι ταξινόμησης μπορούν να περιλαμβάνουν:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ανάπτυξη & Εφαρμογή Απαιτήσεων Λογισμικού

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

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

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

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

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

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

Η ιστορία του χρήστη

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

Ως, θέλω, έτσι

Ενα παράδειγμα:

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

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

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

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

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

Πριν από την εφαρμογή μιας ιστορίας χρήστη, ελέγξτε:

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

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

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

Στις περισσότερες περιπτώσεις, δεν είναι συνετό να λάβετε μονομερή απόφαση.

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

Επαλήθευση απαιτήσεων λογισμικού

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

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

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

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

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

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

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

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

Με λίγα λόγια

Το καταφέρατε. Kudos σε εσάς!

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

Μπορείτε να διαβάσετε περισσότερα από τα άρθρα μου στο ιστολόγιό μου.

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