Α)
Δυσκολευόμαστε λίγο με το περιεχόμενο του StRS των τραπεζών. Το πρόβλημα προκύπτει κυρίως γιατί δεν προσφέρουμε κάποια υπηρεσία προς τις τράπεζες αλλά μας παρέχουν εκείνες.
Εμείς υποθέτουμε για την εμπλοκή μας με την τράπεζα τα εξής:
1) Το σύστημα μας στέλνει requests στο σύστημα της τράπεζας για να πραγματοποιηθούν οι συναλλαγές μεταξύ των λειτουργών των διοδίων.
>> Είστε ελεύθεροι να κάνετε υποθέσεις, αλλά: το σύστημά μας στέλνει αιτήματα συναλλαγών; αντίστοιχα το σύστημα της εφορίας στέλνει στις τράπεζες ενημέρωση ότι κάποιος χρωστάει; Πώς σας ακούγεται αυτό;
2) Η τράπεζα μας ενημερώνει με κάποιο μήνυμα/response για το αν επιτεύχθηκε ή όχι η συναλλαγή.
>> Εξαρτάται. Βλ. παραπάνω ή παρακάτω.
Πιο συγκεκριμένα ως business process ίσως να θεωρούσαμε το (2) γιατί το σύστημα της τράπεζας αλληλεπιδρά με το δικό μας, αλλά όχι το (1). Θα ήταν σωστό να συμπεριλάβουμε και το (1) στα business processes;
>> Γενικά σκέφτεστε σε αδιέξοδη κατεύθυνση, με την έννοια ότι το παιδεύετε να "γράψετε κάτι". Είναι αρκετά απλούστερο. Το σύστημά μας ενημερώνει μόνο τους οφειλέτες, αυτό είναι υποχρεωτικό. Η τράπεζα περιμένει από τους οφειλέτες την πληρωμή, τους δίνει μια απόδειξη την οποία αυτοί καταθέτουν σε μας. Μπορεί την τράπεζα να την ενδιαφέρει να ενημερώνεται αυτόματα από το σύστημά μας για τις οφειλές, μόνο από όσους λειτουργούς δρόμων το επιλέξουν, για να τους πουλήσει κάποιο σχετικό προϊόν ή να συμψηφίσει πληρωμές με άλλες δικές τους οφειλές προς την τράπεζα. Μπορεί στη συνέχεια η τράπεζα να αναλάβει να καλεί μια δική μας υπηρεσία για να μας ενημερώσει για την πληρωμή. Ή να μας προσφέρει μια υπηρεσία που να την καλούμε εμείς, ώστε να επαληθεύουμε έναν "κωδικό πληρωμής" που μπορεί (=ενδέχεται) να μας δίνει ο λειτουργός του αυτοκινητόδρομου. Γενικά μπορούμε να σκεφτούμε πολλά, αλλά η ιδέα ειδικά με τις τράπεζες, είναι να είναι απλή η εμπλοκή τους οπότε έχουν λίγα να γράψουμε στο StRS.
Β) Για κάθε χρήστη/άλλο σύστημα που αλληλεπιδρά με το δικό μας σύστημα θα πρέπει να έχουμε τουλάχιστον ένα use case; Χρειάζεται δηλαδή να φτιάξουμε ένα use case μονάχα για την αλληλεπίδραση (2); Ταυτόχρονα όμως αυτό το use case δεν θα εμπεριέχει κάποια λειτουργική απαίτηση που υπάρχει για το σύστημα μας (π.χ. δεν υπάρχει λειτουργική απαίτηση για την λήψη της επιβεβαίωσης).
>> Ναι, έχει νόημα ένα use case τουλάχιστον ανά stakeholder. Λειτουργική απαίτηση δεν περιλαμβάνεται, στο πνεύμα της απλότητας που προανέφερα. Μπορείτε να την προσθέσετε, αλλά επαναλαμβάνω τη συμβουλή να το κρατήσετε απλό.
Γ) Στην παράγραφο έκθεση απαιτήσεων χρηστών, ποιες θα μπορούσαν να ήταν οι απαιτήσεις από το σύστημα της τράπεζας αφού αυτό είναι ανεξάρτητο από εμάς.(Θέλουμε να πούμε πως κυρίως εμείς έχουμε απαιτήσεις από το σύστημα της τράπεζας)
>> Αυτές που θα προκύψουν από τις παραδοχές που θα κάνετε σύμφωνα με τα παραπάνω. Το πιο απλό είναι η τράπεζα να μπορεί να καλεί μια δική μας υπηρεσία για να μας ενημερώνει για την πληρωμή. Ή μια άλλη για να επιβεβαιώνει τον κωδικό οφειλής. Μόλις ανέφερα 2.
Δ) Στους δείκτες ποιότητας από όσο καταλαβαίνουμε βάζουμε δείκτες ποιότητας που αφορούν το σύστημα μας και όχι π.χ. το σύστημα της τράπεζας, σωστά;
>> Σωστά. Υπάρχει άλλη ερώτηση και απάντηση για δείκτες ποιότητας. Βάζουμε δείκτες που αφορούν το σύστημά μας και ενδιαφέρουν την τράπεζα.