Πάβελ Μολιάνοφ

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

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

Το άρθρο θα είναι χρήσιμο:

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

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

Τι είναι η τεχνική προδιαγραφή και γιατί χρειάζεται;

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

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

Υπάρχουν πολλά οφέλη από τις τεχνικές προδιαγραφές. Είναι διαφορετικό για κάθε πλευρά.

Οφέλη για τον πελάτη:

• Καταλάβετε για τι πληρώνει χρήματα και πώς θα είναι ο ιστότοπος.Μπορείτε να δείτε αμέσως τη δομή, να καταλάβετε τι θα λειτουργήσει και πώς. Μάθετε αν όλα σας ταιριάζουν. Εάν όχι, δεν είναι πρόβλημα να το αλλάξετε πριν ξεκινήσει η ανάπτυξη.
• Δείτε την ικανότητα του ερμηνευτή.Εάν οι όροι αναφοράς είναι σαφείς και ακριβείς, η εμπιστοσύνη στον προγραμματιστή αυξάνεται. Αν γράφει χυλός, ίσως πρέπει να τρέξεις και να μην κοιτάς πίσω.
• Ασφαλιστείτε για την ανεντιμότητα του ερμηνευτή.Όταν ο ιστότοπος είναι έτοιμος, μπορεί να ελεγχθεί σύμφωνα με τις τεχνικές προδιαγραφές. Υπάρχουν ασυνέπειες; Ο προγραμματιστής είναι υποχρεωμένος να τα διορθώσει. Εάν συνεργάζεστε επίσημα και έχετε συνάψει συμφωνία, μπορείτε να το αναγκάσετε ακόμη και μέσω των δικαστηρίων.
• Απλοποιήστε την αντικατάσταση των καλλιτεχνών.Εάν ο πελάτης και ο προγραμματιστής μάλωναν και τράπηκαν σε φυγή, η δημιουργία του ιστότοπου μπορεί να πάρει πολύ χρόνο. Όταν υπάρχει μια λεπτομερής τεχνική προδιαγραφή, μπορεί να μεταφερθεί σε μια νέα ομάδα - θα εμπλακούν στη δουλειά πολλές φορές πιο γρήγορα.
• Μάθετε το κόστος ανάπτυξης ενός σύνθετου προϊόντος.Είναι αδύνατο να εκτιμηθεί άμεσα ο ακριβής χρόνος και το κόστος ανάπτυξης μιας πολύπλοκης υπηρεσίας Ιστού. Πρώτα πρέπει να καταλάβετε πώς θα λειτουργεί η υπηρεσία και ποιες λειτουργίες θα έχει. Για αυτό πρέπει να προετοιμάσετε τις τεχνικές προδιαγραφές.

Οφέλη για τον ερμηνευτή:

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

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

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

Οι όροι εντολής συντάσσονται από τον ερμηνευτή

Γενικά, ο καθένας μπορεί να συντάξει τεχνικές προδιαγραφές. "Χρειαζόμαστε έναν ιστότοπο επαγγελματικής κάρτας για μια οδοντιατρική κλινική" - αυτό είναι ήδη μια τεχνική εργασία. Θα εκπληρώσει όμως τις λειτουργίες του; Μετά βίας.

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

Αυτό δεν σημαίνει ότι ο πελάτης εξαφανίζεται και εμφανίζεται στο τέλος να γράφει: «Zbs, εγκρίνω». Θα πρέπει επίσης να συμμετέχει στη διαδικασία:

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

Γράψε καθαρά και με ακρίβεια

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

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

Κοίτα. Κάποιος θεώρησε ότι αυτό το σχέδιο ήταν όμορφο και το επέτρεψε να χρησιμοποιηθεί στον ιστότοπό του:

Το ίδιο συμβαίνει με ασαφείς διατυπώσεις που δεν σημαίνουν τίποτα από μόνες τους:

• Ο πελάτης πρέπει να αρέσει στον ιστότοπο.Κι αν έχει κακή διάθεση;
• Ο ιστότοπος πρέπει να είναι βολικός.Τι σημαίνει? Βολικό για τι;
• Ο χώρος πρέπει να αντέχει μεγάλα φορτία. 10 χιλιάδες επισκέπτες; Ή 10 εκατομμύρια;
• Υψηλής ποιότητας περιεχόμενο ειδικών.Λοιπόν, καταλαβαίνεις την ιδέα.

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

• Ο ιστότοπος πρέπει να φορτώσει γρήγορα → Οποιαδήποτε σελίδα στον ιστότοπο πρέπει να έχει περισσότερους από 80 πόντους στο Google PageSpeed ​​Insights.
• Βαρέα φορτία→ 50 χιλιάδες επισκέπτες ταυτόχρονα.
• Η κύρια σελίδα εμφανίζει μια λίστα άρθρων → Η κύρια σελίδα εμφανίζει μια λίστα με τα τελευταία 6 δημοσιευμένα άρθρα.
• Μινιμαλιστική φιλική προς το χρήστη διεπαφή συνδρομής → πεδίο "Αφήστε το e-mail σας" και κουμπί "Εγγραφή" → *σχεδιασμένο σκίτσο*.

Τακτοποιήσαμε τη διατύπωση, ας περάσουμε στη δομή.

Δώστε γενικές πληροφορίες

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

Αξίζει επίσης να υποδείξετε τον σκοπό του ιστότοπου και να περιγράψετε τη λειτουργικότητά του με λίγα λόγια - για να μην καταλήξετε σε ένα ηλεκτρονικό κατάστημα αντί για ένα ιστολόγιο.

Εξηγήστε τους δύσκολους όρους

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

Περιγράψτε τα εργαλεία και τις απαιτήσεις φιλοξενίας

Φανταστείτε ότι ξοδέψατε 2 μήνες για να δημιουργήσετε έναν υπέροχο ιστότοπο. Κάθε στάδιο συντονίστηκε με τον πελάτη - ήταν ευχαριστημένος. Και τώρα ήρθε η ώρα να παραδώσουμε το έργο. Εμφανίζετε τον πίνακα διαχείρισης και ο πελάτης φωνάζει: «Τι είναι αυτό; Modex;! Νόμιζα ότι θα το έκανες στο WordPress!»

Για να αποφύγετε τέτοια προβλήματα, περιγράψτε τα εργαλεία, τους κινητήρες και τις βιβλιοθήκες που χρησιμοποιούνται. Ταυτόχρονα, αναφέρετε τις απαιτήσεις φιλοξενίας σας. Ποτέ δεν ξέρεις, θα το κάνεις σε PHP - και ο πελάτης έχει διακομιστή στο .NET.

Καταγράψτε τις απαιτήσεις για τη λειτουργία του ιστότοπου

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

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

Καθορίστε τη δομή του ιστότοπου

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

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

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

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

Εξηγήστε τι θα υπάρχει σε κάθε σελίδα

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

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

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

Περιγράψτε τα σενάρια χρήσης του ιστότοπου

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

• Ενέργεια χρήστη.
• Απόκριση ιστότοπου.
• Αποτέλεσμα.

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

Διαβάστε περισσότερα για τις περιπτώσεις χρήσης στη Wikipedia.

Προσδιορίστε ποιος είναι υπεύθυνος για το περιεχόμενο

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

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

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

Περιγράψτε το σχέδιο (αν μπορείτε)

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

Γράψε για όμορφα και μοντέρνος σχεδιασμόςΔεν χρειάζεται. Δεν σημαίνει τίποτα, δεν έχει δύναμη και γενικά ουφ.

Αντί για συμπέρασμα: η δομή των όρων αναφοράς

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

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

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

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

Σχόλια προγραμματιστή

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

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

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

Οι μεγάλοι πελάτες συχνά ζητούν πολύ λεπτομερείς τεχνικές προδιαγραφές, οι οποίες περιγράφουν κάθε κουμπί. Στις μικρές εταιρείες, αντίθετα, δεν αρέσουν τα προσεγμένα έγγραφα 100 σελίδων. Είναι μια μεγάλη ανάγνωση και είναι εύκολο να χάσετε κάτι σημαντικό. Πιο συχνά κάνουμε συνοπτικές τεχνικές προδιαγραφές 10–15 σελίδων.

Δηλώνουμε:

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

Οι 2 τελευταίες ενότητες είναι οι πιο σημαντικές. Είναι αυτοί που παρέχουν μια κατανόηση για το πώς θα είναι ο ιστότοπος και πώς θα λειτουργεί.

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

Τι είναι η τεχνική προδιαγραφή; Πώς να το κάνετε και σε τι χρησιμεύει; Παραδείγματα, δείγματα, συμβουλές και συστάσεις.

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

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

Τι είναι η τεχνική προδιαγραφή

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

Τμήμα σχεδιασμού

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

Γιατί χρειάζεστε τεχνικές προδιαγραφές;

• Για να αναθέσετε εργασίες σε εκτελεστές.
• Για να περιγράψετε λεπτομερώς τι θέλετε να πάρετε στο τέλος.
• Να συμφωνήσουμε για τη σειρά εργασίας.
• Να αξιολογεί και να αποδέχεται την εργασία μετά την υλοποίηση.
• Προς...(προσθέστε τις επιλογές σας στα σχόλια).

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

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

Στην πραγματικότητα πρόκειται για ένα σοβαρό έγγραφο που συντάσσεται από τον πελάτη και τον ανάδοχο. Στο βαθμό που προβλέπονται ποινές και υποχρεώσεις των μερών. Υπάρχει ένας αριθμός GOST, διαβάστε περισσότερα στο Habré.

Ανάπτυξη τεχνικών προδιαγραφών

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

Το να έχεις μούσι είναι προαιρετικό

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

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

Τι περιλαμβάνει η τεχνική προδιαγραφή;

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

1. Περιγραφή του έργου/εργασίας. Γράφουμε εν συντομία ποιο είναι το έργο ή η εργασία που πρέπει να ολοκληρωθεί.
2. Σκοπός και στόχοι. Ποιοι είναι οι στόχοι για το έργο;
3. Απαιτήσεις. Σχεδιασμός, λειτουργίες, τεχνολογίες που χρειάζονται.
4. Περιγραφή της δουλειάς. Τι, πότε και πώς θα γίνει.
5. Διαδικασία ελέγχου και αποδοχής. Πώς θα γίνει αποδεκτό το έργο, τι μπορεί να θεωρηθεί ολοκληρωμένο.
6. Εφαρμογές. Σκίτσα, σκίτσα, πρωτότυπα.

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

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

Παραδείγματα τεχνικών προδιαγραφών

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

Ένα παράδειγμα ενός από τους όρους αναφοράς μου για την ενημέρωση της εφαρμογής Smart TV. Εργασίες για πιο σύνθετα και σύνθετα προϊόντα συντάχθηκαν με τη βοήθεια συναδέλφων από το τεχνικό τμήμα. Μη διστάσετε να ζητήσετε βοήθεια από τους συμπαίκτες σας, βάλτε τους στη διαδικασία όσο πιο συχνά γίνεται. Και μην ξεχάσετε να δώσετε σχόλια! Δεν υπάρχει τίποτα χειρότερο από το να βάζεις προσπάθεια και χρόνο σε κάτι χωρίς να γνωρίζεις τα αποτελέσματα. Πείτε μας πώς οι συμβουλές του ατόμου ήταν χρήσιμες στη δουλειά σας, διαφορετικά, είναι ένα μονόπλευρο παιχνίδι.

Όροι αναφοράς για την ανάπτυξη ηλεκτρονικού καταστήματος

Όροι αναφοράς για την ανάπτυξη μιας εφαρμογής για κινητά

Όροι αναφοράς για τον ιστότοπο

Όροι αναφοράς για υπηρεσίες/ενημερώσεις

Εάν χρειάζεστε περισσότερα δείγματα, απλώς το Google.

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

Έτσι πρέπει να είναι

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

Για παράδειγμα, για την εργασία "Κουμπί "Μου αρέσει στον ιστότοπο":

1. Περιγραφή: πρέπει να δημιουργήσετε ένα κουμπί "Μου αρέσει" στον ιστότοπό μας.
2. Σκοπός και στόχοι: συμμετοχή των χρηστών, έκδοση/βαθμολόγηση υλικού με βάση τον αριθμό των likes.
3. Απαιτήσεις: η ακόλουθη σχεδίαση (παράδειγμα: σύνδεσμος σε κάτι παρόμοιο), λειτουργικότητα (οποιοσδήποτε χρήστης μπορεί να βαθμολογήσει την εικόνα και να της αρέσει, το σύστημα του ιστότοπου λαμβάνει υπόψη τον αριθμό των "μου αρέσει" και αλλάζει την παραγωγή των υλικών), τεχνολογία (διατίθεται σε επιτραπέζιους υπολογιστές και εκδόσεις του ιστότοπου για κινητές συσκευές).
4. Περιγραφή εργασίας: σχεδιάστε 3 επιλογές για διατάξεις κουμπιών (ημερομηνία ετοιμότητας: 10/01/17), αναπτύξτε ένα σύστημα διανομής υλικών με βάση τα likes (ημερομηνία: 14/10/17), δοκιμή λειτουργίας (ημερομηνία: 16/10/17 ), κυκλοφορία (ημερομηνία: 17/10/17)
5. Αποδοχή εργασίας: ο χρήστης πατάει το κουμπί like, το σύστημα μετράει το κλικ και αλλάζει η παράδοση των υλικών.
6. Εφαρμογές: σκίτσα, σκίτσα, παραδείγματα έργων όπου λειτουργεί παρόμοια λειτουργία.

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

Ορίστε

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

Πώς να γράψετε μια τεχνική προδιαγραφή για ένα πρόγραμμα σύμφωνα με το GOST 19.201-78;

Δημιουργήθηκε στις 15/02/2010 15:50:53

Σημείωση με ημερομηνία 11 Ιουνίου 2014 - Αγαπητοί κυρίες και κύριοι! Πιθανώς, κάθε δεύτερο ή τρίτο των τεχνικών προδιαγραφών σας για προγράμματα, που με τον ένα ή τον άλλο τρόπο κατέληξαν στα χέρια του συγγραφέα, περιέχει αυθεντικά κείμενα από αυτό το άρθρο. Αυτό είναι υπέροχο και πολύ ωραίο, αλλά πρέπει να λάβετε υπόψη το γεγονός ότι έχει περάσει σχεδόν μια δεκαετία από το πρώτο άρθρο και σε αυτό το διάστημα έχουν αλλάξει πολλά, ειδικά στο κομμάτι. Φυσικά, δεν μπορείτε να σβήσετε τις λέξεις από το τραγούδι, αλλά να είστε δημιουργικοί και να δημιουργήσετε μερικές πιο μοντέρνες διασκευές. Και μην ξεχνάτε ότι αυτό δεν είναι ένα έγγραφο "".

Τεχνικές προδιαγραφές σύμφωνα με τα φύλλα μορφής 11 και 12 σύμφωνα με το GOST 2.301-68, κατά κανόνα, χωρίς τη συμπλήρωση του φύλλου. Οι αριθμοί φύλλων (σελίδων) τοποθετούνται στο επάνω μέρος του φύλλου παραπάνω [από την ρήτρα 1.1 του GOST 19.201-78]

Φύλλο Έγκρισης και Εξώφυλλο

Φύλλο και τίτλος σελίδαςκαταρτίστηκε σύμφωνα με το GOST 19.104-78.

Τα μέρη πληροφοριών, το φύλλο εγγραφής αλλαγής ενδέχεται να μην περιλαμβάνονται στο έγγραφο [από την ρήτρα 1.2 του GOST 19.201-78]

Αυτή η ευκαιρία πρέπει να αξιοποιηθεί. Λιγότερες λέξεις - λιγότερες ερωτήσεις.

Αλλαγές και προσθήκες

Για να κάνετε ή να προσθέσετε προσθήκες στις τεχνικές προδιαγραφές σε επόμενες, ή να εκδώσετε μια προσθήκη σε αυτές. και οι προσθήκες στις τεχνικές προδιαγραφές πραγματοποιούνται με την ίδια σειρά που ορίζεται για τις τεχνικές προδιαγραφές [από την ενότητα 1.3 του GOST 19.201-78]

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

Σύνθεση ενοτήτων τεχνικών προδιαγραφών

Οι όροι αναφοράς πρέπει να περιέχουν τα ακόλουθα:

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

Ανάλογα με τα χαρακτηριστικά του προγράμματος ή του προϊόντος λογισμικού, είναι δυνατή η αποσαφήνιση του περιεχομένου των ενοτήτων, η εισαγωγή νέων ενοτήτων ή ο συνδυασμός μεμονωμένων [από την ενότητα 1.4 του GOST 19.201-78]

Τυχόν χειρισμοί με τομές είναι αυστηρά σύμφωνα με τη σελ.

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

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

Εισαγωγή

Στην ενότητα "Εισαγωγή", υποδείξτε μια σύντομη περιγραφή του πεδίου εφαρμογής ή του αντικειμένου στο οποίο χρησιμοποιείται το πρόγραμμα ή το προϊόν λογισμικού [από την ενότητα 2.1 του GOST 19.201-78]

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

Όνομα προγράμματος

Το όνομα του προγράμματος είναι "Επεξεργαστής κειμένου για εργασία με αρχεία rtf".

Σύντομη περιγραφή του πεδίου εφαρμογής

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

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

Λόγοι ανάπτυξης

Η ενότητα «Βάση ανάπτυξης» πρέπει να αναφέρει:

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

[από την ρήτρα 2.2 του GOST 19.201-78]

Βάση για ανάπτυξη

Βάση για την ανάπτυξη είναι η Συμφωνία (επιστολή κ.λπ.) Αρ. 666 με ημερομηνία 32 Μαρτίου 2004 (εισερχόμενη Αρ. τέτοια και τέτοια από τέτοια και τέτοια). Η συμφωνία εγκρίθηκε από τον Διευθυντή της FSUE "Spetstyazhmontazhstroyselkhozavtomatika" Ivanov Petr Ivanovich, εφεξής καλούμενος ως Πελάτης, και εγκρίθηκε από τον Γενικό Διευθυντή της OJSC "Supersoft" Blyumkins Ivan Aronovich, εφεξής καλούμενος ως Ανάδοχος, για τέτοια και τέτοια Μάρτιος 2004.

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

Όνομα και σύμβολο του θέματος ανάπτυξης

Το όνομα του θέματος ανάπτυξης είναι «Ανάπτυξη επεξεργαστής κειμένουγια εργασία με αρχεία rtf." Σύμβολο του θέματος ανάπτυξης (κωδικός θέματος) – “RTF-007”

Σκοπός ανάπτυξης

Στην ενότητα "Σκοπός ανάπτυξης" πρέπει επίσης να αναφέρεται ο λειτουργικός σκοπός ή [από την ενότητα 2.3 του GOST 19.201-78]

Λειτουργικός σκοπός

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

Η υποενότητα θα πρέπει να υποδεικνύει τον «μεγαλωμένο» λειτουργικό σκοπό του προγράμματος. Λεπτομέρειες – λίστα λειτουργιών κ.λπ. - θα δοθεί παρακάτω στις σχετικές ενότητες.

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

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

Ας χρησιμοποιήσουμε μια επίσημη προσέγγιση:

Λειτουργικός σκοπός

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

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

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

Η ενότητα "Απαιτήσεις για ένα πρόγραμμα ή προϊόν λογισμικού" πρέπει να περιέχει τις ακόλουθες υποενότητες:

• απαιτήσεις για λειτουργικά χαρακτηριστικά·
• απαιτήσεις να?
• απαιτήσεις για σύνθεση και παραμέτρους·
• απαιτήσεις για και?
• απαιτήσεις για και?
• απαιτήσεις για και?
• ειδικές απαιτήσεις.

[από την ρήτρα 2.4 του GOST 19.201-78]

Εάν υπάρχουν πρότυπα που περιέχουν γενικές (τεχνικές) απαιτήσεις για το πρόγραμμα ή, για παράδειγμα, "GOST 12345-67. Αυτοματοποιημένα συστήματα πληροφοριών και μετρήσεων. Γενικές (τεχνικές) απαιτήσεις», η ανάπτυξη τεχνικών προδιαγραφών απλοποιείται σημαντικά. Τα περισσότερα από τα περιεχόμενα του καθορισμένου προτύπου απλώς ξαναγράφονται στις τεχνικές προδιαγραφές.

Απαιτήσεις για τη σύνθεση των λειτουργιών που εκτελούνται

Το πρόγραμμα πρέπει να παρέχει τη δυνατότητα να εκτελεί τις ακόλουθες λειτουργίες:

• λειτουργίες για τη δημιουργία νέου (κενού) αρχείου.
• λειτουργίες για το άνοιγμα (φόρτωση) ενός υπάρχοντος αρχείου.
• λειτουργίες για την επεξεργασία ενός ανοιχτού (εφεξής καλούμενου τρέχοντος) αρχείου εισάγοντας τα περιεχόμενα του αρχείου χρησιμοποιώντας τυπικά.
• λειτουργίες για την επεξεργασία του τρέχοντος αρχείου χρησιμοποιώντας?
• Λειτουργίες αρχείου πηγής.
• λειτουργίες για την αποθήκευση ενός αρχείου με όνομα διαφορετικό από το αρχικό.
• λειτουργίες για την αποστολή των περιεχομένων του τρέχοντος αρχείου μέσω e-mailχρησιμοποιώντας ένα εξωτερικό πρόγραμμα αλληλογραφίας πελάτη.
• λειτουργίες για την εμφάνιση διαδικτυακών πληροφοριών (συμβουλές).
• λειτουργίες?
• λειτουργίες για την εμφάνιση του ονόματος προγράμματος, της έκδοσης του προγράμματος, των πνευματικών δικαιωμάτων και των σχολίων προγραμματιστή.

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

Απαιτήσεις για την οργάνωση δεδομένων εισόδου

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

Οτιδήποτε άλλο, αλλά με την επέκταση rtf, δεν πρέπει να ανοίγει.

Τα αρχεία http://domain.net/file.rtf ή ftp://domain.net/file.rtf δεν πρέπει να ανοίγουν. Αν σύστημα αρχείωνμορφοποιημένα ως FAT32, αρχεία από τοπικό ή αφαιρούμενο αρχείο μορφοποιημένα, για παράδειγμα, σε μορφή ext3, δεν πρέπει να ανοίγουν.

Απαιτήσεις για την οργάνωση δεδομένων εξόδου

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

Απαιτήσεις χρονισμού

Δεν υπάρχουν απαιτήσεις για τα χρονικά χαρακτηριστικά του προγράμματος.

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

Απαιτήσεις αξιοπιστίας

Η υποενότητα "Απαιτήσεις αξιοπιστίας" πρέπει να αναφέρει τις απαιτήσεις για τη διασφάλιση της λειτουργίας (υποστήριξη, έλεγχος πληροφοριών εισόδου και εξόδου, μετά, κ.λπ.) [από την ενότητα 2.4.2 του GOST 19.201-78]

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

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

Απαιτήσεις για την εξασφάλιση αξιόπιστης (σταθερής) λειτουργίας του προγράμματος

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

• οργάνωση αδιάκοπη παροχή ενέργειαςτεχνικά μέσα·
• χρήση λογισμικού·
• τακτική εφαρμογή των συστάσεων του Υπουργείου Εργασίας και Κοινωνικής Ανάπτυξης της Ρωσικής Ομοσπονδίας, που ορίζονται στο ψήφισμα της 23ης Ιουλίου 1998 «Σχετικά με την έγκριση των διαβιομηχανικών προτύπων χρόνου για εργασίες υπηρεσίαΥπολογιστές και εξοπλισμός γραφείου και υποστήριξη λογισμικού».
• τακτική συμμόρφωση με τις απαιτήσεις του GOST 51188-98. Προστασία πληροφοριών. Λογισμικό δοκιμής για διαθεσιμότητα.

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

Είναι δυνατή μια πιο ανθρώπινη προσέγγιση. Αξιοπιστία (ενός συστήματος, σύμφωνα με το ίδιο GOST) μπορεί να θεωρηθεί η απόδοση μιας συγκεκριμένης i-ης συνάρτησης κατά τη διάρκεια ενός συγκεκριμένου χρονικού διαστήματος. Προτείνουμε στον πελάτη να λάβει υπόψη του τον ακόλουθο δείκτη ως κριτήριο για την αξιόπιστη λειτουργία του προγράμματος: ο πελάτης ανοίγει και κλείνει το αρχείο 100 φορές μέσα σε μία ώρα. Εάν το πρόγραμμα δεν ανταποκριθεί εντός του καθορισμένου χρονικού διαστήματος, θεωρείται ολοκληρωμένο.

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

Δεν υπάρχουν απαιτήσεις για την εξασφάλιση αξιόπιστης (σταθερής) λειτουργίας του προγράμματος.

Χρόνος αποκατάστασης μετά από αποτυχία

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

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

Βλάβες λόγω εσφαλμένων ενεργειών του χειριστή

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

όροι χρήσης

Η υποενότητα «Συνθήκες λειτουργίας» πρέπει να αναφέρει (σχετική υγρασία κ.λπ. για επιλεγμένους τύπους) υπό την οποία πρέπει να διασφαλίζονται τα καθορισμένα χαρακτηριστικά, καθώς και ο απαιτούμενος αριθμός προσωπικού [από την ενότητα 2.4.3 του GOST 19.201-78]

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

Κλιματικές συνθήκες λειτουργίας

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

Το πρόγραμμα θα λειτουργεί τέλεια από + 5 έως + 35 °C με σχετική υγρασία 90% και ατμοσφαιρική πίεση 462 mmHg, αφού τέτοιες συνθήκες αντιστοιχούν περίπου στις συνθήκες λειτουργίας των σύγχρονων μη βιομηχανικών υπολογιστών. Αλλά μόλις οι τεχνικές προδιαγραφές περιέχουν λεπτομέρειες και η εργασία εγκριθεί, ο πελάτης έχει μια εξαιρετική ευκαιρία να αναγκάσει τον ανάδοχο να εκτελέσει πλήρως τις εργασίες με έξοδα του αναδόχου.

Πριν από πολλά χρόνια, ο συγγραφέας του άρθρου, λόγω της νιότης του και της αδάμαστης επιθυμίας του να υπερασπιστεί τη θέση του (κυρίως στις τεχνικές προδιαγραφές), «έπεσε στην κλιματική αλλαγή» και «έπεσε συγκεκριμένα» (όπως, σύμφωνα με τον Πούτιν , το λέει η πεφωτισμένη διανόηση), αρκετά cool hardware. Ο συγγραφέας του άρθρου έμαθε αμέσως τι σημαίνει να "δείχνεις τη μητέρα του Kuzka" και "πού περνούν το χειμώνα οι καραβίδες". Ο Θεός να μην σας πιάσει η κλιματική αλλαγή!

Σημείωση από 02/10/2011 - Κατά ειρωνικό τρόπο, οι ειδικοί της "Τεχνικής Τεκμηρίωσης" πριν από λίγο καιρό "μπήκαν ξανά στον έλεγχο του κλίματος", ή μάλλον, ανέπτυξαν ένα πρόγραμμα και μεθοδολογία δοκιμών για την επίδραση εξωτερικών παραγόντων και στη συνέχεια το ετοίμασαν , ανακαλύπτοντας ένα άλλο. Δεν είναι άδικο που λένε ότι η ιστορία εξελίσσεται με ανοδική πορεία...

Απαιτήσεις για είδη υπηρεσιών

Το πρόγραμμα δεν απαιτεί κανένα είδος δοκιμής.

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

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

Απαιτήσεις για τον αριθμό και τα προσόντα του προσωπικού

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

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

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

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

Το προσωπικό πρέπει να είναι πιστοποιημένο για την ομάδα προσόντων II στην ηλεκτρική ασφάλεια (για εργασία με εξοπλισμό γραφείου).

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

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

Απαιτήσεις για τη σύνθεση και τις παραμέτρους των τεχνικών μέσων

Στην υποενότητα "Απαιτήσεις για τη σύνθεση και τις παραμέτρους των τεχνικών μέσων" αναφέρετε την απαιτούμενη σύνθεση αναφέροντας την κύρια τεχνικά χαρακτηριστικά[από την παράγραφο 2.4.4 GOST 19.201-78]

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

Το υλικό πρέπει να περιλαμβάνει συμβατό με IBM Προσωπικός υπολογιστής(Η/Υ), συμπεριλαμβανομένων:

• Επεξεργαστής Pentium-1000 με συχνότητα ρολογιού 10 GHz, όχι λιγότερο.
• μητρική πλακέτα με FSB, GHz - 5, όχι λιγότερο.
• Χωρητικότητα RAM, TB - 10, όχι λιγότερο.
• και ούτω καθεξής…

Απαιτήσεις για πληροφορίες και συμβατότητα λογισμικού

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

Εάν είναι απαραίτητο, θα πρέπει να παρέχεται [από την ενότητα 2.4.5 του GOST 19.201-78]

Απαιτήσεις για δομές πληροφοριών και μεθόδους λύσης

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

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

Απαιτήσεις για πηγαίους κώδικεςκαι γλώσσες προγραμματισμού

Οι πηγαίοι κώδικες του προγράμματος πρέπει να υλοποιηθούν σε C++. Το περιβάλλον Borland C++ Buider θα πρέπει να χρησιμοποιείται ως ολοκληρωμένο πρόγραμμα.

Απαιτήσεις για το λογισμικό που χρησιμοποιείται από το πρόγραμμα

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

Απαιτήσεις για την προστασία πληροφοριών και προγραμμάτων

Δεν υπάρχουν απαιτήσεις προγράμματος.

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

Απαιτήσεις επισήμανσης και συσκευασίας

Στην υποενότητα "Απαιτήσεις για τη σήμανση και τη συσκευασία", γενικά, αναφέρονται οι απαιτήσεις για τη σήμανση, οι επιλογές και οι μέθοδοι συσκευασίας [από την ενότητα 2.4.6 του GOST 19.201-78]

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

Απαίτηση επισήμανσης

Το προϊόν λογισμικού πρέπει να φέρει την ονομασία της εταιρείας προγραμματισμού, τον τύπο (όνομα), τον αριθμό έκδοσης, τον αριθμό σειράς, την ημερομηνία κατασκευής και τον αριθμό Gosstandart της Ρωσίας (εάν υπάρχει). Η σήμανση πρέπει να εφαρμόζεται στο προϊόν λογισμικού με τη μορφή αυτοκόλλητου, κατασκευασμένου με εκτύπωση, λαμβάνοντας υπόψη τις απαιτήσεις του GOST 9181-74.

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

Απαιτήσεις συσκευασίας

Το προϊόν λογισμικού πρέπει να συσκευάζεται σε δοχεία συσκευασίας ().

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

Συνθήκες συσκευασίας

Η συσκευασία του προϊόντος λογισμικού πρέπει να πραγματοποιείται σε κλειστούς αεριζόμενους χώρους σε θερμοκρασία από + 15 έως + 40 ° C και σχετική υγρασία όχι μεγαλύτερη από 80% απουσία επιθετικών ακαθαρσιών στο περιβάλλον.

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

Διαδικασία συσκευασίας

Τα προϊόντα λογισμικού που προετοιμάζονται για συσκευασία τοποθετούνται σε δοχεία, τα οποία είναι κουτιά από κυματοειδές χαρτόνι (GOST 7376-89 ή GOST 7933-89) σύμφωνα με τα σχέδια του κατασκευαστή της συσκευασίας.

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

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

πρέπει να τοποθετηθεί σε συσκευασία καταναλωτή μαζί με το προϊόν λογισμικού.

Μια λίστα συσκευασίας και μια λίστα συσκευασίας τοποθετούνται στο επάνω στρώμα του υλικού απορρόφησης κραδασμών.

Οι συσκευασίες καταναλωτή πρέπει να καλύπτονται με κολλητική ταινία 6-70 σύμφωνα με το GOST 18251-87.

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

Το κουτί παλετών πρέπει να περιέχει έγγραφα αποστολής, συμπεριλαμβανομένης μιας λίστας συσκευασίας σύμφωνα με το GOST 25565-88.

Οι διαστάσεις του χώρου φορτίου δεν πρέπει να υπερβαίνουν τα 1250 820 1180 mm.

Καθαρό βάρος - όχι περισσότερο από 200 κιλά.

ΜΙΚΤΟ Βάρος - όχι περισσότερο από 220 κιλά.

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

Απαιτήσεις μεταφοράς και αποθήκευσης

Στην υποενότητα "Απαιτήσεις μεταφοράς και αποθήκευσης" πρέπει να αναφέρονται οι συνθήκες, τοποθεσίες, συνθήκες αποθήκευσης, συνθήκες αποθήκευσης, σε διάφορες συνθήκες [από την ενότητα 2.4.7 του GOST 19.201-78]

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

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

Συνθήκες μεταφοράς και αποθήκευσης

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

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

• θερμοκρασία περιβάλλοντος αέρα, °C - από συν 5 έως συν 50.
• , kPa - τέτοια και τέτοια.
• η σχετική υγρασία αέρα στους 25 °C είναι τέτοια και τέτοια.

Ειδικές απαιτήσεις

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

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

Απαιτήσεις για τεκμηρίωση λογισμικού

Η ενότητα "Απαιτήσεις για τεκμηρίωση λογισμικού" θα πρέπει να υποδεικνύει την προκαταρκτική σύνθεση και, εάν είναι απαραίτητο, τις ειδικές απαιτήσεις για αυτήν [από την ρήτρα 2.5a του GOST 19.201-78]

Προκαταρκτική σύνθεση τεκμηρίωσης προγράμματος

Η τεκμηρίωση λογισμικού θα πρέπει να περιλαμβάνει:

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

Επιτρέπεται ο συνδυασμός ορισμένων τύπων επιχειρησιακών εγγράφων (με εξαίρεση τα και). Η ανάγκη αναφέρεται στο. Στο συγχωνευμένο έγγραφο εκχωρείται επίσης ο προσδιορισμός ενός από τα συγχωνευμένα έγγραφα. Τα συγχωνευμένα έγγραφα πρέπει να περιέχουν πληροφορίες που πρέπει να περιλαμβάνονται σε κάθε συγχωνευμένο έγγραφο [από την ρήτρα 2.6 του GOST 19.101-77]

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

Τεχνικοί και οικονομικοί δείκτες

Η ενότητα "Τεχνικοί και οικονομικοί δείκτες" πρέπει να αναφέρει: κατά προσέγγιση οικονομική, εκτιμώμενη ετήσια ανάγκη, οικονομικά πλεονεκτήματα της ανάπτυξης σε σύγκριση με τα καλύτερα εγχώρια και ξένα δείγματα ή ανάλογα [από την παράγραφο 2.5 του GOST 19.201-78]

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

Ας υποθέσουμε ότι ένας πελάτης εξοπλίζει δώδεκα σταθμούς εργασίας με το πρόγραμμα. Ο ανάδοχος ζήτησε 1000 $ για την ανάπτυξη. Ο πελάτης θα μπορούσε να εγκαταστήσει ένα προϊόν λογισμικού τρίτου κατασκευαστή στους σταθμούς εργασίας, με κόστος 500 $ για το κιτ διανομής και 100 $ για την άδεια χρήσης για κάθε ΧΩΡΟΣ ΕΡΓΑΣΙΑΣ.

Οικονομικά οφέλη της ανάπτυξης

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

Στο στάδιο «Τεχνικός (και Λεπτομερής) Σχεδιασμός», πρέπει να ολοκληρωθούν τα ακόλουθα στάδια εργασίας:

• ανάπτυξη προγράμματος·
• ανάπτυξη της τεκμηρίωσης του προγράμματος·
• δοκιμή του προγράμματος.

Στο στάδιο «Υλοποίηση» πρέπει να ολοκληρωθεί το στάδιο ανάπτυξης «Προετοιμασία και μεταφορά του προγράμματος».

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

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

Στο στάδιο ανάπτυξης του προγράμματος, πρέπει να γίνει εργασία για (κωδικοποίηση) και.

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

Κατά τη φάση δοκιμής του προγράμματος, πρέπει να εκτελεστούν οι ακόλουθοι τύποι εργασιών:

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

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

Διαδικασία ελέγχου και αποδοχής

Η ενότητα "Διαδικασία ελέγχου και αποδοχής" πρέπει να αναφέρει τους τύπους και τις γενικές απαιτήσεις για την αποδοχή της εργασίας [από την ρήτρα 2.7 του GOST 19.201-78]

αριθμός θέσεων εργασίας		ανάπτυξη	οικονομικά οφέλη

Είδη δοκιμών

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

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

Η πρόοδος των δοκιμών αποδοχής τεκμηριώνεται από τον πελάτη και τον ανάδοχο.

Γενικές απαιτήσεις για αποδοχή εργασίας

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

Εφαρμογές

Στα παραρτήματα των τεχνικών προδιαγραφών, εάν χρειάζεται, αναφέρονται τα εξής:

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

[από την ρήτρα 2.8 του GOST 19.201-78]

Αν υπάρχει, γιατί να μην το φέρεις. Και φροντίστε να δημοσιεύσετε μια λίστα με GOST βάσει των οποίων θα πρέπει να πραγματοποιηθεί η ανάπτυξη. Για παράδειγμα:

• GOST 19.201-78. Τεχνικές προδιαγραφές, απαιτήσεις για περιεχόμενο και σχεδιασμό.
• και ούτω καθεξής..

συμπεράσματα

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

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

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

• GOST 19.201-78 Ενιαίο σύστημα τεκμηρίωσης προγράμματος. Τεχνικό έργο. Απαιτήσεις για περιεχόμενο και σχεδιασμό

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

Τι είναι η τεχνική προδιαγραφή

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

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

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

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

Τρόπος σύνταξης τεχνικών προδιαγραφών: δομή τεχνικών προδιαγραφών για έναν ιστότοπο

Πριν ξεκινήσεις:

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

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

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

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

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

Περιγράψτε τον ιστότοπο

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

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

Μιλήστε μας για τη δομή

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

• Σχέδιο
• Τραπέζι
• Λίστα

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

Παράδειγμα απλούστερη δομήμε τη μορφή μπλοκ διαγράμματος

Περιγράψτε τι θα υπάρχει σε κάθε σελίδα

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

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

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

Σετ σχεδιαστικές απαιτήσεις

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

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

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

Περιγράψτε τις απαιτήσεις για εργαλεία, κώδικα, φιλοξενία, τομέα

Αυτό είναι απαραίτητο για να γνωρίζετε εκ των προτέρων με ποια εργαλεία μπορείτε να εργαστείτε και με ποια όχι. Περιγράψτε σε ξεχωριστό μπλοκ:

• Σε ποιον ιστότοπο θα πρέπει να βρίσκεται ο ιστότοπος - WordPress, Joomla, Modex κ.λπ.
• Ποια γλώσσα προγραμματισμού μπορεί να χρησιμοποιηθεί - PHP, JavaScript, HTML, άλλα
• Σε ποιο hosting και σε ποια ζώνη τομέα θα πρέπει να βρίσκεται ο ιστότοπος; Ονομα τομέαμπορεί να χρησιμοποιηθεί
• Ποια πλατφόρμα λογισμικού μπορεί να χρησιμοποιηθεί - .NET, OpenGL, DirectX
• Και ούτω καθεξής

Εάν ο πελάτης δεν καταλαβαίνει τίποτα σχετικά με τους όρους που χρησιμοποιούνται, εξηγήστε τη διαφορά μεταξύ WordPress και Modex, PHP από HTML, τομέα σε zone.ru από τομέα σε zone.com. Μαζί, καταρτίστε τις απαιτήσεις έτσι ώστε να ταιριάζουν στον πελάτη.

Καθορίστε τις απαιτήσεις λειτουργίας του ιστότοπου

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

• Η ταχύτητα φόρτωσης του ιστότοπου που είναι αποδεκτή από εσάς ή η τυπική τιμή είναι 1–5 δευτερόλεπτα
• Συμβατότητα μεταξύ προγραμμάτων περιήγησης - προσδιορίστε σε ποια προγράμματα περιήγησης θα πρέπει να ανοίγει ο ιστότοπος
• Απόκριση - καθορίστε τα μεγέθη οθόνης στα οποία θα πρέπει να προσαρμοστεί ο σχεδιασμός και τις συσκευές που χρησιμοποιούνται
• Αντοχή σε φορτία - πόσα άτομα πρέπει να βρίσκονται στον ιστότοπο ταυτόχρονα για να μην "κατέβει"
• Αντίσταση σε επιθέσεις χάκερ και dDos: ο ιστότοπος πρέπει να αντέχει σε μικρές επιθέσεις

Καταγράψτε τα σενάρια λειτουργίας του ιστότοπου

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

Ένα παράδειγμα του απλούστερου σεναρίου για έναν ιστότοπο

Μάθετε ποιος παράγει το περιεχόμενο.

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

• - όχι λιγότερο από 95% σύμφωνα με τα Advego, Text.ru, Content.Watch
• Ναυτία (spaminess) - όχι περισσότερο από 10% σύμφωνα με το Advego ή 65% σύμφωνα με το Text.ru
• Πόντοι σύμφωνα με το Glavred - τουλάχιστον 6,5 ή 7 πόντοι

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

Καθορίστε προθεσμίες

Αυτό συχνά ξεχνιέται. Οι περισσότερες τεχνικές εργασίες πρέπει να καθορίζουν προθεσμίες, διαφορετικά η ανάπτυξη μπορεί να διαρκέσει αρκετούς μήνες, έξι μήνες ή χρόνια. Μην χρησιμοποιείτε λανθασμένη διατύπωση - για παράδειγμα, "σε ένα μήνα". Γράφω την ακριβή ημερομηνία: 1 Δεκεμβρίου 2018, για παράδειγμα.

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

Θυμηθείτε: κάθε τεχνική προδιαγραφή πρέπει να περιέχει πολλά κύρια μπλοκ:

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

Παράδειγμα κατάρτισης τεχνικών προδιαγραφών για λογισμικό

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

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

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

• Σύνδεσμος
• Τίτλος άρθρου
• Η κύρια παράγραφος

Εάν υπάρχουν περισσότερες από 10 αντιστοιχίες, πρέπει να τις χωρίσετε σε σελίδες - 10 σε κάθε μία.

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

Προθεσμίες: έως 15 Σεπτεμβρίου 2018.

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