Εβδομάδα 4: Τεχνολογία απαιτήσεων

Σημειώσεις μελέτης βασισμένες στη Διάλεξη 4: «Requirements Engineering». Οι διαφάνειες βρίσκονται στο Moodle.

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

Τι είναι οι απαιτήσεις

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

Γιατί έχουν τόση σημασία

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

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

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

Μια καλή απαίτηση είναι (κατά τον Alan Davis):

Από τις απαιτήσεις του πελάτη στις τεχνικές απαιτήσεις

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

Ποιοι είναι οι ενδιαφερόμενοι

Οι ενδιαφερόμενοι (stakeholders) δεν είναι μόνο ο πελάτης που πληρώνει:

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

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

Δύο τρόποι να συλλέξεις απαιτήσεις, που λειτουργούν καλύτερα μαζί:

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

Ιεράρχηση: η μέθοδος MoSCoW

Συνήθως δεν υπάρχει χρόνος ή προϋπολογισμός για όλα. Μαζί με τον πελάτη αποφασίζεις τι προηγείται, συχνά με τη μέθοδο MoSCoW:

Κατηγοριοποίηση: το ολιστικό μοντέλο

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

Η κύρια απαίτηση (σκοπός)

Ορίζει τον βασικό σκοπό της εφαρμογής, τι κάνει στην ουσία της. Ο σκοπός ενός λογιστικού φύλλου, για παράδειγμα, είναι να αποθηκεύει, να οργανώνει και να αναλύει πληροφορίες σε μορφή πίνακα. Ένα κλασικό παράδειγμα τέτοιου ξεκάθαρου σκοπού έδωσε ο Τζον Κένεντι το 1961: να προσγειωθεί ένας άνθρωπος στη Σελήνη πριν τελειώσει η δεκαετία και να επιστρέψει με ασφάλεια στη Γη.

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

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

Προσοχή: το «η εφαρμογή είναι εύχρηστη» δεν είναι λειτουργική απαίτηση. Δεν είναι κάτι που κάνει το σύστημα, αλλά μια ιδιότητά του.

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

Είναι περιορισμοί: πόσο καλά ή με ποιον τρόπο πρέπει να γίνει κάτι. Δεν ξεκινούν με ρήμα. Χωρίζονται σε τρεις ομάδες:

• Απόδοσης: πόσο καλά εκτελείται μια συγκεκριμένη λειτουργία. Έχουν μια ιδιότητα και μια τιμή-στόχο.
  • Κακό παράδειγμα: «Όλες οι οθόνες εμφανίζονται γρήγορα» (χωρίς στόχο, και δεν αφορά συγκεκριμένη λειτουργία).
  • Καλό παράδειγμα: «Η σελίδα ολοκλήρωσης αγοράς εμφανίζεται σε λιγότερο από 500 ms μετά το πάτημα του κουμπιού παραγγελίας».
• Συστήματος: περιορισμοί για ολόκληρο το σύστημα, όπως διαθεσιμότητα, ασφάλεια, αξιοπιστία, συντηρησιμότητα, διαλειτουργικότητα, επεκτασιμότητα, εμφάνιση και κόστος. Π.χ. «Το σύστημα είναι διαθέσιμο 24 ώρες, 7 ημέρες την εβδομάδα».
• Υλοποίησης: πώς θα κατασκευαστεί, με ποια τεχνολογία. Είναι απαιτήσεις που ορίζουν μια λύση. Π.χ. «Η εφαρμογή θα γραφτεί σε Java», «Η βάση δεδομένων θα είναι SQL Server».

Οι πελάτες συνήθως δεν περιγράφουν λειτουργίες· μιλούν για περιορισμούς («να είναι γρήγορο», «να τρέχει στα Windows»), γιατί τους ενδιαφέρει πόσο καλά γίνεται κάτι, όχι πώς. Γι’ αυτό πρέπει να «βγάλεις» τις λειτουργίες μέσα από περισσότερη συζήτηση μαζί τους.

Πώς γίνεται μετρήσιμη μια ποιότητα

Μια αφηρημένη έννοια όπως «αξιόπιστο» ή «εύχρηστο» πρέπει να γίνει κάτι που μετριέται:

Ένας άλλος τρόπος: FURPS+

Η Hewlett-Packard ανέπτυξε το FURPS:

• Functionality: τι κάνει η εφαρμογή, μαζί με τη σύνδεση με άλλα συστήματα.
• Usability: εμφάνιση, ευκολία χρήσης, πλοήγηση, ανταπόκριση.
• Reliability: διαθεσιμότητα, πόσο συχνά επιτρέπεται να αποτυγχάνει, ακρίβεια.
• Performance: ταχύτητα, μνήμη, αποθηκευτικός χώρος, χωρητικότητα.
• Supportability: πόσο εύκολα συντηρείται, δοκιμάζεται, διορθώνεται και ενημερώνεται.

Το «+» προσθέτει περιορισμούς σχεδίασης, υλοποίησης (π.χ. συμμόρφωση με το ISO 9000), διεπαφής με άλλα συστήματα και φυσικούς περιορισμούς (π.χ. ελάχιστη υπολογιστική ισχύς).

Ερωτήσεις αυτοαξιολόγησης

1. Τι δεν πάει καλά στην απαίτηση «Η αναζήτηση πρέπει να είναι γρήγορη και εύκολη»;

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

2. Σε ποια κατηγορία ανήκει η «Η εφαρμογή θα χρησιμοποιεί βάση δεδομένων MySQL»;

Μη λειτουργική απαίτηση υλοποίησης, γιατί ορίζει με ποια τεχνολογία θα κατασκευαστεί το σύστημα.

3. Γιατί το «Παρέχει υψηλή ασφάλεια» δεν είναι λειτουργική απαίτηση, παρότι έχει ρήμα;

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

4. Ποια είναι η διαφορά ανάμεσα σε μια απαίτηση «Should» και μια «Could» στο MoSCoW;

Και οι δύο δεν είναι απαραίτητες. Η «Should» είναι σημαντική και μπαίνει αν γίνεται· η «Could» είναι απλώς επιθυμητή και είναι η πρώτη που φεύγει όταν πιέζει ο χρόνος ή ο προϋπολογισμός.

---

Πηγές: Διάλεξη 4 του μαθήματος· A. M. Davis, Software Requirements: Objects, Functions and States (2η έκδοση, 1993).