ניסיון בכתיבת המפרט הטכני המושלם. תנאי ההתייחסות

השאלה "האם יש צורך בכלל לערוך מפרט טכני (TOR)?" עלול להתעורר רק למי שמעולם לא הזמין פיתוח אתר אינטרנט בחייו, שכן הצורך בכך מתעורר לאחר ההתקשרות הראשונה בין הלקוח לקבלן.

מפרט טכני הוא מסמך המתאר את הפרויקט העתידי בפירוט ובאופן מלא. ככל שהוא יהיה מפורט יותר, כך הרעיון ייושם בצורה מדויקת יותר ויצוצו פחות קונפליקטים ומצבים שנויים במחלוקת במהלך ביצוע הפרויקט, כי בהחלט ניתן לעשות כל דבר בדרכים שונות. ניתן להפנות אליו אם משהו לא הושלם או נעשה בצורה שגויה או נעשו שגיאות אחרות. לפני תחילת העבודה, הלקוח בדרך כלל מתאר את הפרויקט העתידי בצורה מופשטת או ממלא בריף, והקבלן מגבש את כל הדרישות והרצונות הללו, ובמידת הצורך מציע התאמות. במקביל, הלקוח צריך לוודא שכל ה"רצונות" שלו נרשמים במפרט.

אם נכרת הסכם עם סטודיו אינטרנט או פרילנסר לפיתוח אתר, הרי שהמשימה הטכנית מגיעה לרוב כנספח אליו. ובמצבים שנויים במחלוקת, הם מודרכים לפי מה שכתוב שם.

ממה מורכב המפרט הטכני?

נניח שבמסגרת פרויקט צריך לגבש מפרט טכני לפיתוח אתר אינטרנט לסטודיו לקופירייטינג פרו. אילו נקודות היא צריכה להכיל?

מידע כללי (תיאור)

להלן הדברים הבאים:

מידע על החברה. מידע כללי על הסטודיו, מה הוא עושה. זה יהיה רעיון טוב לספק רשימה של השירותים הניתנים. כאן תוכלו להוסיף את הכתובת של האתר העתידי ופרטים ליצירת קשר.

שלבים ותזמון הפרויקט. נקודה חשובה מאוד: ככלל, לוח זמנים לכל שלבי העבודה נקבע בסוף. חלק זה נותן הבנה של מה ייעשה ומתי. לדוגמה (עם תאריכים):

• שלב ההכנה;
• פיתוח קונספט האתר;
• לְעַצֵב;
• יצירת פריסת עיצוב;
• פיתוח עיצוב עמודים;
• מַעֲרָך;
• תִכנוּת;
• מילוי בתוכן;
• אופטימיזציה של SEO;
• בּוֹחֵן;
• לְהַשִׁיק.

ייתכן שלבים מסוימים, למשל, קידום קידום אתרים, לא קיימים. תלוי במטרות וביעדים של הלקוח וביכולות הקבלן.

מטרה ומטרות

כאן מנוסח אילו פונקציות יבצע האתר ולמי הוא מיועד.

מטרת האתר. אילו מטרות יש להשיג על ידי יצירת אתר אינטרנט? למה זה נחוץ, אילו בעיות זה פותר?

• פרסום ומשיכת לקוחות חדשים;
• תמיכת לקוחות ושותפים;
• הדגמה של עבודה שהושלמה;
• היכרות עם רשימת השירותים;
• יצירה ושמירה על תדמית החברה.

אולי יש לתאר ביתר פירוט כמה נקודות. לדוגמה, אם משימת האתר היא גם ליידע את המבקרים, אז עדיף להסביר במה בדיוק מדובר.

קהל יעד. מי ישתמש באתר, עבור מי הוא נוצר?

• מנהלי אתרים, בלוגרים;
• בעלי חנויות מקוונות;
• בעלי פורטלי מידע;
• אולפני פרסום;
• נציגי חברות וחברות נוכחים במרחב המקוון.

דרישות

סעיף גדול וחשוב ביותר, שלוקח בחשבון כמה שיותר היבטי עיצוב ופיתוח, כי הלקוח יצטרך לשלם תוספת עבור פונקציונליות שאינה מצוינת במפרט הטכני.

סוּג. לאיזו קטגוריה שייך משאב האינטרנט?

• דף נחיתה;
• אתר כרטיסי ביקור;
• אתר תאגידי;
• פורטל מידע;
• חנות מקוונת.

דרישות רישום. הם יכולים להיות מהסוג הבא:

• האתר צריך להיות מינימליסטי ויחד עם זאת לשקף את סוג הפעילות של החברה.
• צבעי יסוד: ירוק ולבן, לפי ספר המותג או לפי שיקול דעת המעצב.
• לא ניתן להשתמש באנימציה, חלונות קופצים, רכיבי פלאש או עודפי עיצוב בעיצוב.
• לא ניתן להשתמש בגופני Serif (ניתן להשתמש בסטנדרטים: Verdana, Arial, Tahoma וכו'). גודל הגופן אמור להבטיח קריאה מרבית (12-16 נקודות).

באשר לדרישות העיצוב, ניתן להשתמש בגישות שונות. אם הלקוח עצמו יודע בדיוק מה הוא רוצה לקבל, אז הוא מתאר את רצונותיו בפירוט, נותן דוגמאות לאתרים שהוא אוהב ונותן פרטים נוספים. אבל לפעמים קורה שהוא עצמו לא יודע בדיוק איך הכל צריך להיראות, במקרה הזה הם בדרך כלל יוצאים מהמשימות שהעיצוב חייב לפתור. הקבלן מפתח קונספטים, מציע פתרונות, מגן על הרעיון שלו ומתאים אותו בהתאם להערות הלקוח. האפשרות השנייה יקרה יותר ודורשת יותר כישורים מהקבלן.

דרישות שפה. אילו דוברי שפה יוכלו לגשת למשאב? אילו גרסאות שפה של האתר צריכות להיות?

• רוּסִי;
• אַנגְלִית;
• אֶסְפֵּרַנְטוֹ.

דרישות תאימות. מאילו מכשירים ומאילו דפדפנים האתר ייפתח בצורה נכונה? לאחרונה חלה מגמה של פריסה אדפטיבית, כאשר הדף מוצג בצורה נכונה בכל מכשיר בכל יחס רוחב-גובה ורזולוציית מסך. כאן אתה יכול לרשום את הדפדפנים שהמשאב בהחלט צריך להיות תואם. בדרך כלל, אתרים מוצגים זהה בכל הדפדפנים המודרניים יש רק בעיות עם גרסאות ישנות יותר של Internet Explorer.

דרישות CMS. יכולות ניהול האתר קובעות אילו בלוקים ניתן לערוך ולהגדיר דרך לוח הבקרה, מבלי להפריע לקוד או לערוך ישירות את מסד הנתונים, אלא באמצעות ממשק ויזואלי נוח. לדוגמה, ניתן לנסח זאת כך:

• יכולת לשנות תוכן בדפי האתר;
• יכולת ניהול דפים (הוספה, שינוי שמות, מחיקה וכו');
• יכולת לערוך את מבנה האתר ופריטי התפריט;
• פונקציות עיבוד גרפי אוטומטי (יצירת תצוגות מקדימות, טרנספורמציה לגודל נתון וכו');
• יכולת כתיבת מטא תגיות ייחודיות;

כמו בתתי סעיפים אחרים, עליך לתאר את כל הדרישות והרצונות.

לרוב ללקוח יש כבר ניסיון בעבודה עם אחד מה-CMS הפופולריים, אז מומלץ לחפש קבלנים למנוע ספציפי. כמו כן, בבחירת מערכת CMS, עדיף לא להסתפק בפתרונות בכתב עצמי, כי בעתיד זה יהיה תלוי במבצע. מנועים בכתב עצמי, לדעתי, מוצדקים רק בפרויקטים גדולים מאוד שבהם נדרשת פונקציונליות ספציפית או אופטימיזציה של עומסים גדולים.

מבנה וניווט. אילו סעיפים, תת-סעיפים ודפים בודדים יכיל הפרויקט?

• עמוד הבית
• שירותים

• קופירייטינג
• שִׁכתוּב
• קופירייטינג SEO
• הַגָהָה
• תַעֲתוּק
• ניהול תוכן
• שיווק תוכן

• תִיק
• אודותינו
• אנשי קשר

תנו תיאור קצר של כל עמוד ותנו הגדרות. לדוגמה, מה הכוונה בדף "צור קשר"? האם זה צריך להכיל כתובת, טלפון ומייל בצורת טקסט? או שצריך להיות שם טופס משוב? או אולי אתה צריך להטמיע את הקוד של Yandex Maps? או שעמוד צור קשר צריך להכיל את כל האמור לעיל, בתוספת קישורים לנציגים ברשתות החברתיות?

רצוי להכין את התוכן או לפחות לשרטט אותו לפני תחילת העבודה מול הקבלן. זה יקדם תקשורת יעילה יותר.

דרישות נוספות. כל מה שלא כלול בחלקים אחרים של הסעיף.

תיאור קטעי האתר

בשלב זה יש פרטים. בדרך כלל מתואר התוכן של כל הדפים הייחודיים: אילו אלמנטים יהיו שם, איך המשתמש יקיים איתם אינטראקציה.

עמוד הבית. ניסוח הבעיה יכול להיות כדלקמן.

החלק העיקרי של הדף הראשי צריך להיות מעוצב כדף נחיתה. האלמנטים הבאים צריכים להיות ממוקמים עליו מלמעלה למטה:

• כותרת - לוגו, שם חברה;
• תפריט ניווט;
• מידע על מבצעים והנחות;
• כפתור הזמנה;
• טקסט פרסומי;
• בלוק עם חמש העבודות הטובות ביותר וקישור למדור תיק העבודות;

ברוב הארגונים הגדולים, יחסי משתמש-IT תוך חברה הם בלתי נמנעים, במיוחד בעת יצירת יישומי עבודה שהמשתמש זקוק להם באופן שוטף. המורכבות של מערכת יחסים זו יכולה לנבוע מגורמים רבים, אך לרוב מדובר באי הבנה שנוצרת מכיוון שהצדדים מדברים "שפות" שונות בטרמינולוגיה שונה. המשתמש מבין מה הוא רוצה, אבל לא יכול לנסח את זה מומחה ה-IT מבין את המשתמש, אבל חושש שהתוצאה תצא אחרת ממה שהראשון רואה. לרוב, הבעיה מתחילה בעובדה שהמשתמש אינו מוכן לדיאלוג: הוא דורש "שזה יעבוד", "לדיווח בלחצן אחד", "שיוצג תוך דקה", "לדייטים". לא להופיע באקסל", וכן הלאה. יחד עם זאת, כלל לא מעניין אותו איך זה נעשה ואילו מנגנונים עובדים. המשתמש אינו מגיב להצהרות על העומס על השרת, מבקש לצייר דיאגרמה של התוצאה הרצויה או לדון בפתרונות מתוך אמונה שאיש מקצוע אמיתי יטפל בהכל. התוצאות של אי הבנה שכזו פוגעות בתהליך הייצור כולו: מועדים לפתרון בעיות מתעכבים, נוצרות שגיאות ופערים במערכות שהמשתמש צריך, סובל שרת עמוס בפעולות לא נכונות ומהירות העבודה יורדת.

אחת הדרכים לפתור קונפליקט כזה היא כתיבת מטלת פרויקט – מפרט טכני, הכרוך בהצהרה מלאה ומדויקת של דרישות הלקוח הפנימי ומהווה מעין הוראה למומחה IT. עם זאת, לא כל משתמש מסוגל להביע את מחשבותיו בצורה מוכשרת ומובנת.
אתן כמה טיפים לכתיבת משימה נכונה למשתמש, עליה ניתן לעבוד ומהווה בסיס לקשר בין מזמין הפתרון למומחה.

1. לפני עריכת מפרט טכני, המשתמש חייב להבין מה בדיוק הוא רוצה לקבל. עליך לקבוע את מטרת המשימה, את תכונות המפתח של התוצאה הרצויה, לצייר (לכתוב, ליצור טבלה) לעצמך את הפלט הרצוי של העבודה.

2. איסוף תיעוד, לפיה אתה מבצע עבודה שעבורה יש צורך באפליקציה (תוכנית). קראו אותו בעיון, בעיפרון, שימו לב לתכונות ולדקויות.

3. צריך להבין אילו פרמטרים יש להגדיר בקלט, מהי תדירות העבודה עם התוכנית הרצויה (דוח, אפליקציה, שירות), כמה נתונים בערך יתקבלו כפלט והאם יש צורך בכולם (לדוגמה, אם אתה צריך את כמות ההכנסות ממכירות של חמש קטגוריות של מוצרים בקטגוריות ללא שמות, אינך צריך לדרוש יצירת דוח בן מיליון שורות המציג כל מכירה עם מאפיינים מפורטים). לא כל מומחה זקוק למידע המפורט ביותר, שעיבודו יוצר עומס משמעותי על מערכות המחשוב.

4. תאר בפירוט את המידע הנדרש, ציינו את תכונותיו, החריגים ואת רמת הפירוט הנדרשת. כדאי לחשוב על כל הדברים הקטנים: פורמט מספר, עיגול, שברים, שיעורים וכו'.

6. דון במשימה הכתובה עם המבצע הישיר, נסה לפתור את כל השאלות, תוך הקשבה היטב לדעתו של בן השיח. אל תשכח שאתה מכיר את תחום הפעילות שלך טוב יותר ורק אתה יכול להסביר בדיוק איזה כלי אתה צריך כדי לעבוד בצורה יעילה. מומחה IT מכיר את העסק שלו ואינו נדרש לדעת את הניואנסים של העבודה של כל מחלקה בארגון.

7. העברה משימה לעבודה תוך זמן סבירלפני היישום הסופי, כדי שתהיה הזדמנות לבדוק את התוצאה ולתקן שגיאות אפשריות.

8. אם הכפופים לך ישתמשו גם באפליקציה שיצרת, נסה להשתמש בה בעצמך להסביר את תכונות העבודה עם האפליקציה- זה יחסוך ממומחה IT את הצורך להסביר את אותו הדבר מאה פעמים.

9. זכרו שהמטלה שלכם תשמש עבורכם אסמכתא – תמיד תוכלו להסתכל בתיאור המידע בה ולזכור דרישה שנשכחה.

כמובן, רק היכולת לכתוב מפרט טכני לא תבטל את כל הבעיות, אבל היא תאפשר ליחסים עם מחלקת ה-IT לעבור לרמה רצינית של שיתוף פעולה, תאפשר למשתמש להגביר את האוריינות הטכנית שלו ולקבל את מה שהוא צריך, וכן להציל את מומחה ה-IT ממספר בעיות ושאלות מיותרות.

תנאי ההתייחסות "TOR" הוא מסמך שנלקח כבסיס לפיתוח של כל פרויקט. ולא משנה כמה מורכבת או גדולה המשימה, היא תמיד צריכה להיות מלווה במפרט טכני ברור ומובן. קודם כל, הלקוח צריך את זה כדי לקבל בדיוק את מה שהוא רצה לראות. אבל רצוי שהמבצע תמיד ידרוש משימה ברורה על מנת להבין מה הם רוצים ממנו. אנשים רבים מתעלמים מהעובדה של כתיבת מפרט טכני מפורט, אשר מוביל לאחר מכן לאי הבנות, מחלוקות, סכסוכים ומריבות.

אנו ממליצים לקרוא:

אני, כותב המאמר הזה, הצלחתי בחיי להיות גם לקוח של כמה פרויקטים גדולים בשווי עשרות אלפי דולרים וגם מבצע הזמנות לא פחות יקרות. לפני שהגעתי לרמה רצינית, הייתי צריך לקרוא שוב מאות "מפרט טכני" ולחבר כמה עשרות מההסברים שלי עבור המבצע. בכל פעם המפרט הטכני הלך והתבהר, מה שאפשר להשיג את הגרסה הסופית של העבודה כפי שדמיינתי. במאמר זה אני רוצה לדבר על איך לכתוב מפרט טכני, למה לשים לב קודם. אספר לכם גם מדוע רצוי ללקוח ולקבלן לא לעבוד על מילה טובה אלא לתעד הכל.

מדוע הלקוח צריך מפרט טכני?

יש לך, כלקוח, מושג לגבי הגרסה הסופית של ההזמנה שלך. רק החיים הם דבר כזה שכל אדם יכול לפרש את אותן המילים בצורה שונה. בשל כך, מתעוררות לא פעם בעיות, במיוחד בקרב לקוחות ומבצעים. הראשון לא הסביר הכל, השני לא הבין את זה נכון, והתוצאה שונה לחלוטין ממה שכולם חשבו. מפרט טכני הוא מסמך לפיו תקבל את העבודה שבוצעה. ואם נעשה משהו לא נכון, משהו לא סוכם, משהו לא הושלם במלואו, אז תמיד תוכל להצביע על פריט מהמפרט הטכני ולבסס את טענתך לסיום הפרויקט שהוגש. אם אין מפרט טכני, אז זה יהיה כמעט בלתי אפשרי להוכיח שאמרת, כתבת, הזכרת את זה. אפשר לומר שהמפרט הטכני הוא סוג של אב טיפוס של הסכם שירות. אם אתה עובד על פרויקט גדול, אז תנאי ההתייחסות צריכים להיות תוספת לחוזה הראשי. בעת החתימה על תעודת הקבלה לעבודה שהושלמה יש להשוות הכל לכמות העבודה שצוינה בהצהרת העבודה המקורית.

אנו ממליצים לקרוא:

למה המבצע צריך מפרט טכני?

קודם כל, זה המדריך שלך למה שצריך לעשות. לעתים קרובות לקוחות מעלים משהו במהלך תהליך הפיתוח, ומנסים להכריח אותך לבצע משימות מיותרות. רוצה לעבוד בחינם? אני בטוח שלא. נא להבהיר כי הסכום שעליו הוסכם כבר בתחילת הדרך נוגע אך ורק להיקף העבודה המפורט בתנאי ההתייחסות. כל דבר נוסף משולם בנפרד. כמו כן, עם מסירת הפרויקט, תוכל לדווח על המשימות שהוטלו על ביצוען. לא פעם נתקלתי ברגעים שבהם הלקוח לא רצה לקבל את העבודה, בטענה שהיא לא הושלמה לחלוטין. אבל כשהועלה המפרט הטכני הראשוני, התברר שאף אחד לא קבע את המשימות המדוברות כלל. שוב אני מדגיש - אל תעבדו בלי מפרט טכני, כי דעת הלקוח יכולה להשתנות לעתים קרובות יותר מאשר מזג האוויר, ותצטרכו לעשות הכל מחדש עשרות פעמים, בזבוז זמן, ובלי לקבל על כך תשלום נוסף.

היכן להתחיל לערוך מפרט טכני מוכשר

אז בואו נעבור לנושא המרכזי של מאמר זה. לאחר מכן, נדבר על איך לערוך מפרט טכני ולאילו נקודות אתה בהחלט צריך לשים לב. כפי שאתה מבין, כל TK הוא ייחודי, ואני לא אוכל לכסות את כל ההיבטים. לכן, אציין רק את הנקודות העיקריות שצריכות להיות בכל משימה, ללא קשר לפרויקט ולתחום הפעילות של הלקוח.

• הוראות כלליות של המפרט הטכני

אם יש לכם פרויקט מורכב מבחינה טכנית, או פרויקט מאוד ספציפי, אז במונחים כלליים חייב להיות מילון מונחים - מילון של מונחים והגדרות. כמובן שטוב מאוד אם הלקוח והקבלן מבינים אחד את השני ומבינים טרמינולוגיה ספציפית ללא בעיות. אבל זה לא תמיד המקרה, לכן, עדיף לרשום את המשמעות של מילים, ביטויים, ייעודים מסוימים. אולי כדאי להסביר כמה מהביטויים שלך במילון המונחים. נניח שאתה משתמש בביטוי מסוים, ומפרש אותו קצת אחרת. כדי למנוע בלבול, מיד לשים הכל במקומו.

אנו ממליצים לקרוא:

היה לי מקרה שבו חוסר הבנה של התנאים הוביל להחמצת מועד של יותר מחודש. כתוצאה מכך נגרמו ללקוח הפסדים מסוימים, אך הבעיה הייתה בצדו בלבד. לכן, אל תאפשר חילוקי דעות. החליטו על טרמינולוגיה לפני תחילת הפרויקט.

• מטרות הפרויקט

הכרחי שתנאי ההתייחסות יצוינו מהן מטרות הפרויקט שלכם, מדוע הוא נוצר, כיצד הוא יעבוד ומה צריכה להיות התוצאה הסופית. גם אם הקבלן עובד על חלק קטן מהפרויקט, עליו להבין היטב את המבנה, המשימות, המטרות והפתרונות הטכניים שלו. בשביל מה? לא תמיד הקבלן יכול לקבל ייעוץ והבהרות מהלקוח, ואין טעם לבקש פרשנות לכמה דברים קטנים אם אפשר לפנות אל המטרות, להבין למה נועד הפרויקט ולעשות את העבודה על בסיס על זה.

תן לי לתת לך דוגמה. לאחרונה פיתחנו פרויקט אינטרנט גדול והזמנו עיצוב. למעצב נאמר על מה יעסוק האתר, אילו פונקציות יהיו לו, מה עליו לעשות וכיצד האתר יעזור לאנשים. באופן כללי, הם לעסו הכל עד הפרט הקטן ביותר, ולא רק את מה שנוגע לעיצוב. כתוצאה מכך, קיבלנו פריסה שלא דרשה כמעט שינויים, כמו גם תריסר רעיונות איך לשפר את האתר, מה להוסיף, איך להפוך אותו לאטרקטיבי יותר.

• דרישות פונקציונליות

ניתן לחלק את כל דרישות הלקוח לשני סוגים: פונקציונלי ומיוחד. דרישות פונקציונליות הן אותן אפשרויות יישום שאתה רוצה לראות בעצמך. אם ניקח דוגמה של אתר אינטרנט, אז אתה חייב לספק לקבלן דוגמאות לפתרונות פונקציונליים מפרויקטים אחרים שאתה אוהב ושתרצה לראות אצלך. לדוגמה, הם ראו אלמנט שהם אוהבים מבחינה טכנית, תיארו אותו ומיד נתנו קישור כדי שאדם יוכל להבין בבירור במה מדובר ויוכל לקחת אותו כבסיס.

אנו ממליצים לקרוא:

דרישות מיוחדות הן דרישות שבעזרתן יש למלא את המשימות שהוקצו. אם ניקח שוב את פיתוח האתר כבסיס, תוכלו לציין את שפת התכנות, פרמטרי פריסה מיוחדים, קידוד, שימוש בסגנונות מסוימים וכל מה שתרצו לראות. אם אין דרישות כאלה, אז תן לקבלן להחליט באופן עצמאי במה וכיצד הוא ישתמש בעת ביצוע המפרט הטכני שלך.

• מועדים

יש לציין את מועדי ההשלמה בתקנון. קח תמיד עם מרווח קטן כדי שמהירות הביצוע לא תשפיע על האיכות. לא בכל מקרה חייב להיות מועד ברור, ומתוארות סנקציות בגין אי עמידה בלוחות זמנים אלו. על הקבלן להבין שלא מדובר רק בנקודה בתנאי ההתייחסות, אלא בהתקנה של ממש, ואם לא תושלם הוא מסתכן בסנקציות כספיות או אחרות.

• דיווח

אם הפרויקט גדול ודורש מספר חודשים לסיום, אז חלק את העבודה לשלבים וקבע מסגרות זמן ברורות לכל אחד. לאחר השלמת שלב מסוים, דרשו דיווח על העבודה שהושלמה. זה ישמור על המבצע בכושר טוב, כך שהוא לא יסתובב כמה חודשים, אוכל ושותה את התשלום מראש, ואז יעשה הכל במהירות מסחררת תוך שבוע.

כמו כן חייב להיות דיווח על העבודה שבוצעה בפועל. מה נעשה, כמה זמן הושקע בזה, באילו קשיים נתקל המבצע וכו'.

• אַחֲרָיוּת

אם תערכו חוזה אזי יהיה בו סעיף לגבי אחריות. אם אתם מוגבלים רק למפרט הטכני, אז כדאי לתאר שם שהקבלן אחראי להחמצת מועדים, אי מסירת הפרויקט, חשיפת ניואנסים של העבודה לצדדים שלישיים, דבר הגורר לכם הפסדים. איזה מהם? ראשית, בהתאם לחוק, אבל אתה יכול גם לקבוע קנסות וסנקציות משלך.

אנו ממליצים לקרוא:

ובסוף מאמר זה, ברצוני לתת כמה עצות המבוססות על הניסיון שלי בניסוח וקבלת מטלות טכניות.

1. המפרט הטכני חייב להיות מפורט. אל תפחדו לתאר כל אלמנט, כל פריט, כל כפתור. כתוב הכל, הכל, בפירוט רב ככל האפשר. אל תפחד להיראות קפדן. עדיף לחזור על משהו מספר פעמים וללעוס אותו מאשר לסיים אותו מאוחר יותר, לשלם תוספת ולשנות אותו. המשימה הטכנית האחרונה שכתבתי נגעה בפיתוח אתר אינטרנט. זה היה פרויקט מידע גדול. תחילה פיתחנו עיצוב, ולאחר מכן, על בסיסו, תיארתי משימה פונקציונלית למתכנתים. אז, כל המפרטים התבררו כגופן של 54 עמודים A4 11. תנאי ההתייחסות הגיעו כתוספת לחוזה הראשי, שגם הוא היה בן 7 עמודים. אבל אני רוצה לומר שגם במפרט טכני מפורט כל כך לא יכולתי לקחת הכל בחשבון, כי במהלך תהליך הפיתוח נחתמו עוד שלושה הסכמים נוספים, איתם עשיתי התאמות מסוימות לגרסה המקורית של המשימה.
2. המפרט הטכני חייב להיות ברור. אין צורך במים. הכל לעניין. אם אתה כותב על המועד האחרון, אז נתון ספציפי, אם על הפונקציונליות, אז רשימה של פתרונות פונקציונליים שאתה צריך וכו '.
3. המפרט הטכני שלך אינו דוגמה, אלא רק אחת מהאפשרויות האפשריות להשלמת משימות. למען האמת, אני לא מומחה לתכנות. כן, אני יכול לחשוב דרך מבנה הפרויקט, הפונקציונליות שלו, כמה פתרונות טכניים, אבל תמיד, כשאני מכין את הגרסה הסופית של המפרט הטכני, אני מתייעץ עם המבצעים. הם יכולים לראות משהו, להביע את דעתם ולהציע את הפתרון האופטימלי ליישום.

זה כנראה כל מה שרציתי לומר במאמר הזה. עריכת מפרט טכני אינו כל כך קשה אם אתה מבין בבירור מה אתה רוצה מהקבלן. אתה יכול לקרוא שוב את העצה שלי ולהחיל אותה במקרה הספציפי שלך. בהצלחה!

במסמך " תנאי ההתייחסות" (ראשי ת"ז) מכיל את המידע הבא: מטרת התכנית והיקף התכנית, דרישות טכניות, טכנו-כלכליות ומיוחדות לתכנית, שלבי הכרחי ותנאי פיתוח, סוגי מבחנים.

על פי GOST, תקן זה (הוצא מחדש בנובמבר 1987) קובע את הנוהל לבנייה והכנה של מפרטים טכניים לפיתוח תוכנית או מוצר תוכנה עבור מחשבים, מתחמים ומערכות, ללא קשר למטרה והיקפם.
עליך להיות זהיר וזהיר במיוחד בעת יצירתו, כי... לעתים קרובות מפרט טכני המנוסח במיומנות (ובמיומנות) קובע את הצלחת העבודה כולה. המפרט הטכני הוא המוסכם עם הלקוח, אשר בדרך כלל שואף להציג כמה שיותר דרישות סותרות ומנופחות. המשימה של ההוצאה לפועל היא, להיפך, להקל על חייו. אבל אחרי שהוצבו חתימות משני הצדדים, זה מאוחר מדי להשמיע משהו מחדש.

הוראות כלליות

תנאי ההתייחסות מנוסחים על גיליונות בפורמט A4 ו/או A3, ככלל, ללא מילוי שדות הגיליון. מספרי גיליון (עמוד) ממוקמים בחלק העליון של הגיליון מעל הטקסט.
כדי לבצע שינויים ותוספות לרקע הטכני בשלבים הבאים של פיתוח תוכנה או מוצר תוכנה, יוצאת תוספת לו. תיאום ואישור תוספות למפרט הטכני מתבצע באותו אופן שנקבע למפרט הטכני.
תנאי ההתייחסות חייבים להכיל את הסעיפים הבאים:

• שם והיקף היישום;
• בסיס לפיתוח;
• מטרת הפיתוח;
• דרישות טכניות לתוכנית או למוצר תוכנה;
• אינדיקטורים טכניים וכלכליים;
• שלבים ושלבי התפתחות;
• הליך בקרה וקבלה;
• יישומים.

בהתאם למאפייני התוכנית או מוצר התוכנה, ניתן להבהיר את תוכן הסעיפים, להציג קטעים חדשים או לשלב קטעים בודדים.

סעיף: שם והיקף

במדור שם והיקףציין את השם, תיאור קצר של היקף היישום של התוכנה או מוצר התוכנה והאובייקט שבו נעשה שימוש בתוכנה או במוצר התוכנה.

בסעיף בסיס לפיתוח יש לציין את הדברים הבאים:

• מסמכים שעל בסיסם מתבצע הפיתוח;
• הארגון שאישר מסמך זה ותאריך אישורו;
• שם ו(או) סמל של נושא הפיתוח.

למשל, ביחס לפרטי התהליך החינוכי, הבסיס עשוי להיות מטלה לעיצוב הקורס, הזמנה מהמכון מיום __.__. עבור N ___., חוזה __.__. עבור N ___. וכו'.

סעיף: מטרת הפיתוח

במדור מטרת הפיתוחיש לציין את המטרה התפקודית והתפעולית של התוכנית או מוצר התוכנה. אתה יכול להגביל את עצמך כאן לביטוי אחד או שניים. העיקר הוא להגדיר בבירור למה מיועדת התוכנית הזו.

לדוגמה: התוכנית היא הליבה של תחנת עבודה אוטומטית (AWS) עבור מפתח מערכות בקרה אוטומטית ליניארית רציפה (ACS), המאפשרת למשתמש לפתור בעיות של ניתוח מודלים פשוטים.

פֶּרֶק: דרישות טכניות לתוכנית או למוצר תוכנה

סעיף זה צריך להכיל את תת הסעיפים הבאים:

• דרישות למאפיינים פונקציונליים;
• דרישות אמינות;
• תנאי שימוש;
• דרישות להרכב ולפרמטרים של אמצעים טכניים;
• דרישות לתאימות מידע ותוכנה;
• דרישות תיוג ואריזה;
• דרישות להובלה ואחסון;
• דרישות מיוחדות.

במילים אחרות, כאן מתחילים הפרטים הספציפיים. מתאר מה התוכנית צריכה לעשות ואיך היא צריכה להיראות.

סעיף: דרישות למאפיינים פונקציונליים.

כאן יש לציין את הדרישות להרכב הפונקציות שבוצעו, ארגון נתוני הקלט והפלט, מאפייני התזמון וכו'.

לְדוּגמָה : התוכנית צריכה לאפשר ... לחשב ... לבנות ... ליצור ...

נתוני קלט: קובץ טקסט עם נתון...

נתוני פלט: מידע גרפי וטקסט - תוצאות ניתוח מערכת...; קבצי טקסט - דוחות על ... אבחון של מצב המערכת והודעות על כל השגיאות שהתרחשו.

דרישות אמינות. יש לציין את הדרישות להבטחת פעולה אמינה (הבטחת פעולה יציבה, ניטור מידע קלט ופלט, זמן התאוששות לאחר תקלה וכו').

קשה "לנחש" משהו כאן. התרחיש הטוב ביותר הוא שהתוכנית שלך עובדת רק עם נתונים נכונים לחלוטין. בדרך כלל הלקוח לא מסכים לכך, אבל אתה יכול לנסות.

לדוגמה: על התוכנית לעבוד עם מטריצה ​​מורחבת נתונה של אירועים של הגרף הנבדק בהתאם לאלגוריתם ההפעלה, לייצר הודעות שגיאה כאשר הנתונים הראשוניים מצוינים באופן שגוי ולתמוך במצב אינטראקטיבי במסגרת היכולות הניתנות למשתמש.

תנאי שימוש. יש לציין את תנאי ההפעלה (טמפרטורת הסביבה, לחות יחסית וכו' עבור סוגי אמצעי אחסון נבחרים) שבהם יש להבטיח את המאפיינים שצוינו, כמו גם את סוג השירות, המספר הנדרש וכישורי הצוות.

בדרך כלל אין קשיים בנקודה זו. למרבה הצער, הסעיף בדבר המקצועיות של המשתמש על ידי הלקוח משתמע בהכרח. זו, כמובן, סיבה נוספת למצוא פגם בתוכנית שלך. עם זאת, כאן אנו יכולים להגביל את עצמנו לביטויים כמו "תנאי ההפעלה של התוכנית תואמים לתנאי ההפעלה של מחשבי IBM ומחשבי PC התואמים להם", "התוכנית צריכה להיות מיועדת למשתמש לא מקצועי". וכו'

דרישות להרכב ולפרמטרים של אמצעים טכניים. ציין את ההרכב הנדרש של אמצעים טכניים עם ציון המאפיינים הטכניים שלהם.

העיקר כאן הוא לא לשכוח כלום ולספק הכל, מצד אחד (אחרת הם יגלשו איזה IBM PC/XT עם צג מונוכרום ובלי עכבר), ומצד שני לא כדי להגזים עם דרישות מוגברות, אחרת הלקוח ימצא קבלן גמיש יותר.

לדוגמה: חייב להיות לך מחשב IBM PC - תואם מחשב עם מתאם גרפי EGA (VGA). שטח הדיסק הנדרש הוא לפחות 600 KB, כמות ה-RAM הפנוי היא לפחות 400 KB. רצוי להחזיק מנהל התקן EMS ומניפולטור מסוג עכבר.

דרישות למידע ותאימות תוכנה. התכונות זהות לאלו בפסקה הקודמת. כאן יש לציין את הדרישות למבני מידע בקלט ופלט ושיטות פתרון, קודי מקור ושפות תכנות. במידת הצורך, יש להבטיח הגנה על מידע ותכניות.

לדוגמה: התוכנית חייבת לעבוד באופן אוטונומי תחת גירסת MS DOS OS לא נמוכה מ-3.3. שפת התכנות הבסיסית היא Turbo Pascal 6.0.

דרישות תיוג ואריזה ודרישות הובלה ואחסון הן די אקזוטיות. באופן כללי, זה מצביע על הדרישות לסימון מוצר תוכנה, אפשרויות אריזה ושיטות. ודרישות ההובלה והאחסון חייבות לציין עבור מוצר התוכנה תנאי שינוע, מקומות אחסון, תנאי אחסון, תנאי אחסון, תקופות אחסון בתנאים שונים.

דרישות מיוחדות הן דבר חשוב מאוד. עדיף להימנע מהם במידת האפשר. ותכריז על זה מיד.

לדוגמא: אין דרישות מיוחדות למאפייני התזמון של התוכנית. אין דרישות מיוחדות למאפיינים הקיבוליים של התוכנית.

אינדיקטורים טכניים וכלכליים. הנקודה הקשה ביותר למתכנת לא תמיד קיימת. זה נחוץ בעיקר כאשר המטרה שלך היא להצדיק את האפקטיביות העצומה והחשיבות של העבודה המתבצעת. פריט זה בדרך כלל עובד טוב מאוד עבור הלקוח. לכל הפחות, זו ההצדקה הטובה ביותר לתזמון ולכמויות הכספיות של הפיתוח.

סעיף זה צריך לציין: יעילות כלכלית משוערת, צורך שנתי משוער (לדוגמה: מספר הפניות הצפוי למתחם כולו בשנה - 365 מפגשי עבודה), יתרונות כלכליים של הפיתוח בהשוואה למיטב המדגמים המקומיים והזרים או אנלוגים.

כמו כן, רצוי לספק הגדרה הן של העלות המשוערת של פיתוח התוכנית והן הגדרה של מורכבות התכנות.

שלבי ושלבי הפיתוח (על כך נדון ביתר פירוט להלן) קובעים את שלבי הפיתוח הדרושים, שלבי ותכני העבודה (רשימת מסמכי התוכנית שיש לפתח, להסכים ולאשר), וכן, כלל, מועדי פיתוח וקביעת המבצעים.

השלבים הסטנדרטיים מתוארים כאן. העיקר הוא לקבוע נכון את העיתוי. במידת האפשר, נסו לחלק את השלבים באופן שווה על פני מועדים (וסכומים). זכרו שלא כל הפרויקטים מגיעים לשלב הסופי. וצריכים להיות דוחות לכל שלב. זכרו גם שפרויקט העבודה ייקח הכי הרבה זמן. אם לא תמלא את התיעוד בזמן, זכותו המלאה של הלקוח שלא לקבל את העבודה כלל עם כל ההשלכות הנובעות מכך.

השלבים והשלבים העיקריים והחיוניים הם תנאי ההתייחסות עצמם, התכנון המקדים, עיצובים טכניים ועבודה.

עיצוב טיוטת. בשלב זה מפתחים בפירוט את המבנים של נתוני הקלט והפלט, ונקבעת צורת הצגתם. תיאור כללי של האלגוריתם, האלגוריתם עצמו ומבנה התוכנית נמצאים בפיתוח. תכנית פעולה לפיתוח ויישום התכנית בפיתוח.

פרויקט טכני. מכיל אלגוריתם מפותח לפתרון הבעיה וכן שיטות לניטור מידע ראשוני. כאן מפתחים כלים לעיבוד שגיאות והוצאת הודעות אבחון, נקבעים טפסים להצגת נתונים ראשוניים ותצורת אמצעים טכניים.

טיוטה עובדת. בשלב זה מתבצעים תכנות וניפוי באגים של התכנית, פיתוח מסמכי תכנית, תוכניות ושיטות בדיקה. דוגמאות לבדיקות וניפוי באגים מוכנות. התיעוד והחומר הגרפי מסתיימים. בדרך כלל מצוין כי במהלך פיתוח התוכנית יש להכין את התיעוד הבא:

טקסט התוכנית;

תיאור התוכנית;

תוכנית מבחן ומתודולוגיה;

תיאור היישום;

מדריך למשתמש.

אלו דרישות סטנדרטיות. אם הלקוח מסכים שלא ניתן להציג את כל הרשימה הזו, פירוש הדבר שכוונותיו לגביך ועבור המוצר שלך אינן רציניות.

ייתכן שאין חומר גרפי. במיוחד כשאתה לא מתכוון לדווח על תוצאות העבודה שלך. אבל עבור פרויקטים רציניים פריט זה נדרש.

לדוגמא: במהלך פיתוח התוכנית יש להכין את החומר הגרפי הבא:

אינדיקטורים טכניים וכלכליים;

מבנה התוכנית;

פורמט להצגת נתוני קלט של תוכנית;

דיאגרמת אלגוריתם כללית (2 גיליונות);
אלגוריתמים חישוביים אובאסיים;
דוגמה לאופן הפעולה של התוכנית.

הסעיף נוהל בקרה וקבלה צריך לציין את סוגי המבחנים והדרישות הכלליות לקבלת עבודה. במידת האפשר, אזי בפסקה זו ציין כי "השליטה והקבלה של הפיתוח מתבצעת באמצעות ציוד שסופק על ידי הלקוח", אחרת ייתכן שתידרש להביא את הציוד איתך.

לדוגמא: בקרה וקבלה של פיתוח מתבצעות על בסיס בדיקות בדיקות וניפוי דוגמאות. זה בודק את הביצוע של כל פונקציות התוכנית.
בנספחים למפרט הטכני, במידת הצורך, מופיעים הדברים הבאים:
רשימת מחקרים ועבודות אחרות המצדיקות את הפיתוח;

דיאגרמות אלגוריתמים, טבלאות, תיאורים, נימוקים, חישובים ומסמכים אחרים שניתן להשתמש בהם במהלך הפיתוח;

מקורות פיתוח אחרים.

פיתוח (ולא רק), הכנה מעשית של מפרטים טכניים. ב Oרובם כְּבָר מוכן לשימוש אלמנטים לוגיים של מפרטים טכניים ניתנים בסוף המאמר. עדכון מיום 20 ביוני 2018.

איך כותבים מפרט טכני?!

נוצר 02/05/2005 11:41:19

העולם שלך ריק...

מי ישתתף בצערך?

"איך לכתוב מפרט טכני?!" - מפי מה שנקרא "סופר טכני" טירון, להלן סופר טכני. הנה זה - המחיר הנורא של קריסת האיחוד ומעבר ההשכלה הגבוהה הרוסית למערכת חינוך דו-שלבית.

נחזור לשאלה. כאשר "פריסה" מתברר:

• השאלה הראשונה היא "למה זה נחוץ";
• השאלה השנייה היא מה צריך להיות המבנה של סעיפי "מפרט טכני";
• שאלה שלישית - מהן הדרכים להכין טקסטים לתוכן של סעיפים של מפרט טכני?

השלישי הוא הקשה ביותר. תשובות לשאלות אלו יופיעו במהלך המצגת.

מטרות ומטרות המאמר

מטרת המאמר היא להקל על החיים לטכנאים חדשים לגמרי.

מטרות המאמר:

• לתת תשובות לשאלות שנשאלו;
• להראות את ההכנה המעשית המינימלית הנדרשת של טקסטים של מפרט טכני;
• תן הזדמנות לטכנאי מתחיל:
  • להגדיל את הדירוג שלך;
  • או סוף סוף לאבד את עצמך בעיני הבוס הגדול.

כַּתָבָה

כל מה שיוצר אי פעם, מיוצר וייוצר מחולק (בתנאי, כמובן) ל:

המוצר הראשון () אולי היה גרזן אבן. או רסיס חרס (מעשה ידי אדם) שמאפשר לגרוף קצת מים בנחל.

מוצר התוכנה הראשון שיושם על "מדיום חומרה" היה, אולי, "תא נגינה" עם דיסק מסתובב מכוסה יתדות. היתדות פגעו במזלג מכוון מסוים בזמן מסוים. כך, התברר שהמנגינה מתוכנתת, "מחובעת" על מתכת - מוצר תוכנה אמיתי, לא רק זה, אלא תוצרת בית. אתה יכול לראות את הנס הנפלא הזה במוזיאון הפוליטכני של מוסקבה.

המערכת האוטומטית הראשונה הייתה כנראה טחנת הרוח. שלפתי את הפקק - ה"להבים" מסתובבים, אבני הריחיים טוחנות. "לחיצה על כפתור אחד" - 100% אוטומציה.

סיפור מצמרר

ואז המלך () הורה - לבנות טחנה, ואחת שתעבוד מכוח הרוח, קרירה יותר מזו של מלך אנגליה (ה"רצונות" של הלקוח), וכדי שתהיה קנאה בכל הבורגנות (המקבילה להתפתחות המודרנית של המדע ולא נחותה מדרישות דומות, בהשוואה למיטב האנלוגים המקומיים והזרים המודרניים).

השומרים גררו את משרתו של הריבון, בעל מלאכה מקומי (), והשליכו אותו לרגלי האב-הצאר. בעל המלאכה היכה את מצחו ברצפת האבן - אז כמובן! נעשה הכל, הוד מלכותך, ללא תנאי, מדויק, בזמן ובמלוא!

הגיע הזמן, המלך הגיע לטחנה (עובד). הוא מסתכל ונדהם - הכנפיים מסתובבות, אבני הריחיים טוחנות, הקמח נשפך לשקיות מעצמו! (עמידה מלאה בדרישות לפונקציות (משימות) המבוצעות על ידי המערכת). כן, קח את זה והכנס את היד שלך לתיק... (שלא סופק וגם לא, כי לא היו דברים כאלה).

המלך הפך לסגול - נו, הטחנה המסריחה הזו טוחנת קמח בצורה מגונה?! (היוצר אי עמידה בדרישות של GOST 7045-90 קמח אפייה שיפון.). השומרים תפסו את האיש והכו את ראשו הקטן והפרוע בגרזן אבן. ולפטי שם קץ לחייו לצלילי ה"רקוויאם" של מוצרט מתוך הג'וקבוקס...

מסקנות

בימי קדם היה מעט שוויון ביחסים בין הצדדים, הלקוח והקבלן (היזם). משהו, כמובן, הסדיר את מערכת היחסים. אולי הוכנו מסמכי קליפת ליבנה - אבות טיפוס של אמנות מודרניות. לא סביר שהסכמים כאלה יכולים לקחת בחשבון הכל, אפילו את איכות הטחינה. ולא היו מקובלים, במובן הרחב, כל היבטי היחסים בין הלקוח לקבלן.

הוצאו צווים וצווים - "באוניברסיטת מוסקבה, הסטודנטים חייבים לשבת על קש, לפוצץ את אפם באגרופם ולנגב את אפם בצרור קש. ומי שמפר את הכללים האלה נקרע ללא רחם במוטות" (או משהו כזה).

גם עכשיו אין שוויון - מי שמשלם קורא למנגינה. והלקוח משלם.

הערה מתאריך 05/10/2014 - אבל לא הכל כל כך עצוב אם אתה פועל בחוכמה, אתה יכול בקלות לכופף כל לקוח, ראה א.

מצב נוכחי

והם מצאו משהו שעשה טנק...

מהסדרה "בדיחות צבא"

עייפים מהפקרות של "הלקוח", התאספו המוציאים לפועל (המפתחים) (ברבע האחרון של המאה העשרים), התארגנו "" ועשו טנק - על המבנה ו(ליתר דיוק) של מסמך שנקרא "מפרט טכני" ". יש לציין שצוותי המחברים כללו, ככלל, אנשים שהיו יודעים קרוא וכתוב מבחינה טכנית, מתחשבים ומביטים אל העתיד הרחוק.

אולי הכל היה שונה, אבל הטנק, בסך הכל, יצא טוב - מה שאושר הן על ידי נציגי GOSSTANDART והן ביקורות של מפתחים מנוסים.

מפרט טכני ומטרתו

עבור ה-Big Boss, שמקיים אינטראקציה ישירה עם הלקוח, המפרט הטכני מאפשר לו להימנע מגורלו של בעל המלאכה (הדבר הוזכר מספר פעמים בעבר).

עבור טכנאי טכני קטן שעובד עבור ביג בוס, פיתוח המפרט הטכני הוא:

• אמצעי להרוויח כסף עבור "משהו לאכול";
• דרך להראות ש-techpis אינו יצור רועד, אלא יש לו את הזכות - דרך לצמוח בעיני ביג בוס.

האמירה הקיצונית היא חרב פיפיות. הו, אתה חכם, אתה יכול לעשות את זה? אז עדיין יש לך עבודה לעשות. ונעלה את המשכורת. איזה יום.

בכל מקרה, היכולת לפתח בצורה מוכשרת מפרטים טכניים (במיוחד מיומנות) היא אינדיקטור לכישוריו הגבוהים של היזם.

אנו מאמינים שהשאלה הראשונה (לקירוב ראשון) סגורה.

תקני GOST למפרט טכני

שיח הוא אוסף של ענפים הגדלים מנקודה אחת.

חוכמה צבאית

לאחר עבודה קשה (וסבל), פורסמו לפחות ארבעה מסמכים, התואמים לחלוקה מאוד קונבנציונלית של תוצרי הפעילות האנושית:

הערות:

1. ישנם GOSTs מקומיים אחרים המכילים דרישות לתוכן ולפורמט של מסמך "מפרט טכני". עובדה זו נובעת מהספציפיות שלה. ארבעת המפורטים היו ונשארו עבור רוב תחומי הנושא;
2. תנאי ההתייחסות היו ונשארו המסמך היסודי, עצם "נקודת המשען" שממנו הכל צומח.

מה משותף לחלקי המסמכים המפורטים לעיל? כל מפרט טכני חייב להכיל סעיפים המשקפים מידע:

• מה צריך לעשות;
• למה, לאיזו מטרה יש לעשות זאת;
• איפה, באיזה תחום יישום, על איזה אובייקט זה צריך לְהַחלִיטמשימות ו לְמַלֵאתפקידיו;
• אילו דרישות יוטלו על כך;
• איזו עבודה תידרש לשם כך;
• מהו הליך ביצוע וקבלה ומסירת עבודה ללקוח;
• כיצד יש לבצע את העבודה;
• ולבסוף, על בסיס אילו מסמכים רגולטוריים וטכניים יש לבצע את העבודה?

זהו המבנה הכללי של סעיפי המפרט הטכני. אנו רואים בשאלה השנייה סגורה.

היה צורך לפתח מפרט טכני למוצר - אנו משתמשים ב- GOST 2.114-95, שכן GOST 15.001 הוא עקומת חיים, וקטעי המפרט הטכני (באופן כללי) תואמים את הסעיפים של המפרט הטכני. במידת הצורך, פתח את GOST 34.602-89. ב- GOST 19.201-78.

אנו נציג את המינימום ההכרחי של טכניקות מעשיות המאפשרות אפילו לטכנאי המתחיל ביותר להתחיל מיד לפתח את התוכן של סעיפי המפרט הטכני ולהשיג תוצאות מקובלות (הפרד אלמנטים מבניים מוכנים של המפרט הטכני בהתאם ל-GOST 34.602-89 ניתן למצוא ב"מרתף" של מאמר זה).

טכניקות מעשיות

שיטות פרקטיות לפיתוח מפרטים טכניים הרוויחו ממש קשה בהתבסס על חווית האינטראקציה עם הלקוח, הן הכותב עצמו והן חבריו הבכירים, שבשבילם אני משתחווה להם, כבוד ומכבד (גם עכשיו וגם לנצח, ולתמיד. אמן).

הטכניקה הראשונה היא ליצור מסמך עם מבנה מקטע GOST. אם על הבוס מוטלת המשימה לפתח מפרט טכני, נניח עבור מערכת אוטומטית, GOST 34.602-89 מוריד כקובץ, ואז פשוט נפתח בוורד ובפורמט נקודות.

גרסאות אלקטרוניות של GOSTs המאוחסנות בדרך כלל מתאימות לגרסאות הרשמיות. תמיד אפשר לבדוק נקודות מפוקפקות בהשוואה, אם אתה לא עצלן כמובן.

הערה מ-25 בדצמבר 2011 - Rostekhregulirovaniya (protect.gost.ru) החלה לאחרונה לפרסם גרסאות רשמיות של תקני GOST, אם כי לא בפורמט הניתן לעריכה...

פירוט

פירוט היא אחת הטכניקות הבסיסיות. יש אנשים שמעדיפים מונח מדעי השאול מהבורגנות - פירוק. נדבר על פירוט המבנה של חלקים של GOSTs עבור מפרטים טכניים.

בואו נזכור את ההורה - "עד שלא תסדר הכל, "שום דבר לא יסתדר לך (אמא)" או "שום דבר לא יסתדר לך (אבא)." גם אמא וגם אבא, כמובן, צדקו ונשארו עד אין סוף. אי אפשר לפתור בעיה פיזיקה פשוטה עד שווקטורי הכוח מפוזרים לאורך הצירים. אי אפשר לקחת אינטגרל משולש עד שהאינטגרלים מעל dx, dy ו-dz נלקחים בתורם. למעט המקרה שבו "האינטגרל כל כך פשוט שאתה יכול לקחת אותו גם בלי dx."

ציטוט שנבחר באקראי מ- GOST 34.602-89:

למערכת ניתנות דרישות לשימוש במערכת של שפות אינטראקציה ואמצעים טכניים של המערכת וכן דרישות לפענוח, שפות, אמצעי תיאור (של אובייקט אוטומציה) ודרכי ארגון [מ. סעיף 2.6.3.3 של GOST 34.602-89]

אֲחוֹרִי Oרובו, נכון? נצטרך לנקות את המזבלה הזו. כָּך, מְפוֹרָשׁעל ידי פיצול, נוצרות סעיפי משנה נוספים של המפרט הטכני (אפשר וצריך לעשות זאת).

4.3.2.1 דרישות לתמיכה לשונית במערכת

4.3.2.1.1 דרישות לשימוש במערכת שפת תכנות ברמה גבוהה

(טקסט של דרישה)

4.3.2.1.2 דרישות לשפות של אינטראקציה בין משתמשים ואמצעים טכניים של המערכת

(טקסט של דרישה)

4.3.2.1.3 דרישות קידוד נתונים

(טקסט של דרישה)

4.3.2.1.4 דרישות פענוח נתונים

(טקסט של דרישה)

4.3.2.1.5 דרישות לשפות קלט/פלט נתונים

(טקסט של דרישה)

4.3.2.1.6 דרישות לשפות מניפולציה של נתונים

(טקסט של דרישה)

4.3.2.1.7 דרישות לאמצעי תיאור אזור הנושא (אובייקט אוטומציה)

(טקסט של דרישה)

4.3.2.1.8 דרישות לשיטות ארגון דיאלוג

(טקסט של דרישה)

האם נפח המפרט הטכני גדל? האם כדאי לחסוך בנייר? יש עוד חוכמה צבאית אחת, לא משנה עד כמה היא נשמעת גסה ומעורפלת: "יותר נייר - נקי יותר z@@@@tsa." האם הדרישות לתמיכה הלשונית מתבהרות?

הערה - המונחים "מובנות" ו"מובנות" מופיעים בכמה GOSTs בו-זמנית. הנה התמצית - "המכלול של משהו שמאפיין את ההוצאה של מאמץ אנושי להבין את הרעיון ההגיוני של משהו זה."

לאחר הפיכת הטקסט הרציף לספירה (סעיפים, פסקאות משנה), לקח למחבר פחות זמן (ומאמץ) להבין (לפחות לזכור) את המבנה ההגיוני של המפרט הטכני, שכן פסקאות המשנה הפכו ל"גלויות" בבירור.

פירוט, פירוט ועוד פירוט. לרמה מקובלת (אטומית).

בניית תבנית של ביטויים

כדאי לקחת בחשבון את העובדה שכל שאלה (שמוצגת נכון) מכילה מחצית מהתשובה. נניח שיש צורך לנסח את הטקסט של סעיף המשנה "דרישות לשימוש במערכת". כָּך:

4.3.2.1 דרישות לשימוש במערכת שפת תכנות ברמה גבוהה

במערכת צריך לִהיוֹת (בְּדִיוּק צריך- זהו!) נעשה שימוש בשפות התכנות הבאות ברמה גבוהה:

• שפת C++;
• שפת פסקל;
• וכו'

למי שלא הרגיש איך לבנות ביטוי, תרשים של בנייתו מוצג בצד שמאל.

4.1.2 דרישות למספר וכישורים של אנשי המערכת ואופן פעולתם

(כדי להיות מפורט יותר, אנו יוצרים סעיפים משנה 4.1.2.1, 4.1.2.2 ו-4.1.2.3)

(אנו מנסחים נכון את הנוסח של פסקת המשנה - אנו עונים על השאלה באילו דרישות מספר העובדים צריך לעמוד)

מספר כוח אדם צריך לעמוד בדרישות :

• להספיק ליישום של מערכות אוטומטיות () בכל אופני פעולת המערכת;

4.1.2.2 דרישות לכשירות כוח אדם

כישורי כוח אדם צריך לְסַפֵּק תפקוד יעיל של מערכות טכניות ומערכתיות בכל מצבי ההפעלה של המערכת"

בהחלטות על כישורי כוח אדם, ניתן יהיה לציין כי על סמך הניסיון של למעלה ממאה מערכות דומות שפותחו בעבר, על כוח האדם להיות בעל השכלה של שלוש שנים לפחות בבית ספר פרוכי. הצהרה זו תשמח את הלקוח. ניתן יהיה לנצל כוח עבודה זול במיוחד. אבל עוד על כך במאמרים הבאים.

4.1.2.3 דרישות לשעות העבודה של כוח אדם

לוח העבודה של הצוות הוא שלוש משמרות מסביב לשעון.

כמו כן, נקבע בסעיף המשנה נוהל הכשרת כוח אדם, מעקב אחר ידע ומיומנויות. אף מילה על ההרכב. וזה נכון. הרכב הצוות, חלוקתו למבצעי (), תיקון וכו', נקבע בעת תכנון המערכת. למרות שאף אחד לא יכול לאסור על הוספת דרישות לצוות לתנאי ההתייחסות. כנראה לא שווה את זה.

פשוט, אבל בטוב טעם. תרגול טהור, ללא שקיעה עמוקה בדקויות לשוניות. פירוט בתוספת דרישות ספציפיות של המפרט הטכני.

פורמליזציה בעת הכנת הטקסט של המפרט הטכני

אולי מאתיים אפשרויות

אחת ממאתיים אפשרויות לפענוח הקיצור "VDV"

נחזור לדוגמא מתת-הסעיף הקודם של המאמר.

4.1.2.1 דרישות כוח אדם

מספר העובדים חייב לעמוד בדרישות:

• להספיק ליישם מערכות אוטומטיות בכל אופני פעולת המערכת;
• להבטיח העסקה מלאה של כוח אדם בעת יישום פונקציות מערכת אוטומטיות וכו'.

האטריות שלמות, אבל רשמית הכל נכון. מומלץ להשתמש אם אי אפשר לציין פריט כלשהו מהמפרט הטכני. אם ביג בוס אינו שם, אתה יכול לבקש ממנו בנימוס להבהיר את דרישות הלקוח לגבי פריט זה ולספק מידע מדויק יותר. זוהי זכותו של מומחה טכני שאינו בקשר ישיר עם הלקוח.

אתה יכול להוסיף - "מספר כוח האדם מצוין עבור "הפרויקט הטכני"". ביג בוס יתפלא מידע כזה של הטכנאי (גם אם הוא עצמו לא יודע דבר) מבחינת שלבים ומערכות אוטומטיות. ואם תציע לבוס בעל פה להוסיף (מאוחר יותר) את המשפט לפרויקט - "בהתבסס על הניסיון של יותר ממאה מערכות דומות שפותחו בעבר, מספר הצוות צריך להיות 10 יחידות במשרה מלאה" - הבוס להיות מופתע במקום. אתה יכול להכין בבטחה הזמנה למינוי מומחה טכני לתפקיד מנתח מערכות (שגם הוא אינו כלול בסיווג הכל רוסי). או חכה שהם יתנו לך עבודה נוספת, כי אתה כל כך חכם.

הערה מיום 17/04/2018 - גם ל-OKPDTR אין תפקיד של פקיד טכני. והמיקום של מערם הטקסט נשאר מהימים ההם

חותמות ואיחוד בעת הכנת הטקסט של מפרטים טכניים

אתן נשים יפות

ואני - בלי קישוט

אבל בכל זאת, גברים

עוזבים אותך...

יו. ריבצ'ינסקי, "שתי אחיות"

הטקסט של המפרט הטכני מושג באמצעות חותמות. קודם כל, כדאי ללמוד אמת פשוטה - אף פעם, בשום מסמך לֹא אתה צריך לקרוא לאל ספייד .

נניח שממיר אנרגיה אוניברסלי לאנרגיה של המוח האנושי נמצא בפיתוח (קיומו של המוח האנושי מוטל בספק. האם זה סביר לתלות את עבודת יצירת ממיר כזה על הצוואר? אבל רפלקסים קיימים באופן אובייקטיבי). עליך מיד, בקטע "שם מוצר", לקרוא לממיר הזה מוצר:

שם המוצר - ממיר אנרגיית קרינת השמש לאנרגיה של המוח האנושי ( לְקַדֵם לפי הטקסט - מוצר ).

ובטקסט - מוצר, מוצר, מוצר...

כך גם לגבי מוצרי תוכנה ומערכות אוטומטיות. שם AS - מערכת אוטומטית להפצת גס לבהמות ( לְקַדֵם לפי הטקסט - מערכת ).

ובטקסט - מערכת, מערכת, מערכת... תכנית, תכנית, תכנית...

התוצאה היא שהשגנו והרגנו שתי ציפורים במכה אחת. לא יהיה צורך להטות ולצרף חבורה שלמה של מילים, ויהיה קל יותר לקרוא את המשימה הטכנית הבנויה כך.

הערה מיום 5 בפברואר 2010 - כאשר פיתוח אוטומטי של תיעוד טכני באמצעות מקור יחיד, מקובלת גם האפשרות עם כל מיני גזרות וצימודים וגם בלעדיהם. לדוגמה, אתה יכול ליצור משתנה פעם אחת<ЗАО «Заказчик»>ולהכניס לספריית המסמכים הנדרשת נושאים - זה לפעמים יותר נוח.

להלן רשימות טיפוסיות של בולים ששימשו במשך זמן רב ומוצלח בפיתוח מפרטים טכניים (לפי חלקים עיקריים, מודגשים בהדגשה):

• מטרת המערכת - מערכת מְיוּעָד עֲבוּר פתרון הבעיות הבאות:
  • משימותכזה וכזה (ראשון);
  • משימותפלוני (שני);
  • וְכֵן הָלְאָה.
• מטרות ליצירת המערכת - מטרות יצירת מערכת הם :
  • לְהַגדִילמְהִירוּת...;
  • קידוםדִיוּק...;
  • לְהַקְטִיןעלויות...;
  • יְרִידָהצְרִיכָה...;
  • הַשׁבָּחָהאינדיקטורים...;
  • וְכֵן הָלְאָה.

כל מטרה תמיד מרמזת חִיוּבִי דִינָמִיקָה , שינוי באינדיקטורים כלשהם לטובה. לדוגמה, המטרה היא להגביר את רווחתו של העם הסובייטי כולו (אך לא קומוניזם: הקומוניזם הוא המטרה!). המטרה היא להגביר את שביעות רצון הלקוחות. החריגים הם:

• עשיית רווח (בהקשר של מפרטים טכניים);
• חתימה על ידי הלקוח.

יש גם טריקים שהם לא כאלה. דוגמה מהתרגול של אחד הטכנאים הנכבדים ביותר (הוא נתן דוגמה בעצמו, ללא כל כפייה, באחד מהפורומים של הטכפיס) - " מאפשר... תוכנית מבצע... תוכנית עושה...". אדוני היקר, כותב טכני! אין עדיין תוכנית, היא עדיין לא פותחה, לא, לא, לא, לא נמסרה ללקוח, אז היא עדיין לא מאפשרת, עושה או עושה כלום. איזה מין הרגל סובייטי בלתי מנוצח של משאלת לב זה?!

• דרישות לפונקציות (משימות) המבוצעות על ידי המערכת - מערכת צריךהמפורטים להלן פונקציות:
  • V בְּתוֹךרֵאשִׁית משימות- ביצוע תפקיד כזה ואחר, תפקיד כזה ואחר;
  • V בְּתוֹךשְׁנִיָה משימות- ביצוע פונקציה כזו או אחרת וכו'.

אם פונקציה (כמו תהליך), אז בדיוק לְסַפֵּק אפשרות לביצוע הפונקציה שצוינה. המשתמש יכול להסיר את הפקק - הטחנה תתחיל לטחון קמח. אך ייתכן שהמשתמש לא יסיר את הפקק. IN נָקוּבבמקרה זה, הטחנה (המערכת) תהיה במצב המתנה (לא פעיל).

אם פונקציה (כמו תהליך), אז המערכת חייבת לְסַפֵּק הוֹצָאָה לְפוֹעַל פונקציות. הפונקציה האוטומטית מופעלת על ידי תוכנת המערכת (ללא השתתפות כוח אדם) לפי לוח זמנים נתון וממזגת את מסד הנתונים ל.

לגבי היקף המשימות. משימות מוחלטים, והפונקציות מתבצעים. אֶל לְהַחלִיטמשימה, היא הכרחית לְבַצֵעַסדרה של פונקציות, נהלים או פעולות. במילים אחרות, המשימה היא אלמנט מבני גדול יותר, בניגוד להמצאות.

ב- GOST 34.003-90 זה מוקדם, המשימה היא, כביכול, חלק מהפונקציה. וזה מוזר: גם בבית הספר כולם פתרו בעיות, חישבו בתוכם את הערכים של פונקציות שונות... ותארו לעצמכם כמה פראית תישמע ההכרזה: "מטרת המפלגה והממשלה היא לשפר את הרווחה של כל העם הסובייטי. כדי להשיג את המטרה, המפלגה מציבה לעצמה פוּנקצִיָהלספק לכל משפחה דירה נפרדת עד שנת 2xxx”... (אגב, ניקיון בתים ודירות לבד זה כבר לא אופנתי ואין זמן במיוחד - יש חברות ניקיון לזה). לפיכך, הפונקציה היא חלק מהמשימה, ולא להיפך. גם אם בניגוד ל-GOST הקדוש 34.003-90.

אז, דוגמה.

IN בְּתוֹך משימות (אוֹ עֲבוּר פתרון בעיות ) תוכנת מערכת צריך לֶאֱכוֹף המפורטים להלן פונקציות:

• אוטומטיפונקציות
• פונקציה אוטומטית למיון רשומות בטבלאות מסד נתונים;
• פונקציות אוֹטוֹמָטִי גיבוי מסד הנתונים.

ומתוך הסעיף הקודם:

• צריך לִהיוֹת ...;
• צריך לעמוד בדרישות ..

כתוצאה מהשימוש בחותמות, הטקסט של המפרט הטכני הופך למאוחד ומפורמל. אַף לֹא אֶחָד הַשׁבָּחָה . וגם הלקוח אָדָם לא ילך לשום מקום מכם, בנות-מהנדסות טכניות יקרות, שכן דרישות המפרט הטכני יהיו עבורו שָׁקוּף.

רשימות ומספור חלקים

רשימות (רשימות תבליט או ממוספרות) מתאימות מאוד בעת הכנת טקסט של מפרט טכני. אדם נורמלי מסוגל לתפוס (לזכור ולשחזר במדויק) משלושה עד תשעה אלמנטים של הרשימה. מעל תשע זה סימן לגאונות.

ב, אולי, יש להפחית את מספר הרכיבים ברשימה. במפרט הטכני - אופציונלי. יש לזכור שתנאי ההתייחסות עם מסמכים רבים אחרים התפתחו בשלבים ובשלבים שונים של יצירת מערכת (או כל דבר אחר).

מקרה ראשון.

"IN בְּתוֹך משימות (אוֹ עֲבוּר פתרון בעיות צריך להבטיח את אפשרות ההגשמה המפורטים להלן פונקציות:

• אוטומטי פונקציות הוספת רשומות לטבלאות מסד נתונים;
• פונקציה אוטומטית למחיקת רשומות מטבלאות מסד נתונים;

מקרה שני.

« 4.3.2.1 IN בְּתוֹך משימות (אוֹ עֲבוּר פתרון בעיות ) תוכנת מערכת תחזוקת מסדי נתונים צריך להבטיח את אפשרות ההגשמה המפורטים להלן פונקציות:

1. אוטומטי פונקציות הוספת רשומות לטבלאות מסד נתונים;
2. פונקציה אוטומטית למחיקת רשומות מטבלאות מסד נתונים;
3. פונקציה אוטומטית למיון רשומות בטבלאות מסד נתונים...;"

נראה שההבדלים קטנים. אֲבָל!

במקרה הראשון, במסמך "תוכנית בדיקה ומתודולוגיה", תצטרך לכתוב "שיטה לבדיקת יישום המערכת של הפונקציה האוטומטית של הוספת רשומות לטבלאות מסד נתונים."

במקרה השני, זו רק "שיטה לבדיקת יישום סעיף 4.3.2.1(1) של המפרט הטכני".

במקרה הראשון - "התמלאו הדרישות של המפרט הטכני ליישום הפונקציה האוטומטית של הוספת רשומות לטבלאות מסד נתונים." במקרה השני, "מתקיימות הדרישות של סעיף 4.3.2.1(1) למפרט הטכני". האם יש הבדל?

באשר למספר רב-שכבתי של סעיפים, תתי-סעיפים, סעיפים ותתי-סעיפים, בפועל דרישות אלו הן חובה ברוב המוחלט של המקרים.

הרשימות צריכות להיות "ממוספרות" לא במספרים, אלא באותיות:

א) לתפקד כך וכך;

השאלה היא עקרונית, שכן המפרט הטכני למפעל (תוספת למפרט הטכני), לפני הגשתו לאישור, חייב להיבדק על ידי שירות הארגון שפיתח את המפרט הטכני ובמידת הצורך כפוף ל[מפסקה 8 לנספח. 1 GOST 34.602-89]. הרי אם המפרט הטכני יפתח בצורה עקומה (בצורה ובמהות), המסמכים העיצוביים והתפעוליים יהיו עקומים.

קצת על. אם המפרט הטכני מכיל תת-סעיף "תמיכה מטרולוגית...", אזי יש לבצע את הבדיקה המטרולוגית במלואה. אם הסעיף המשנה שצוין נעדר, הבדיקה המטרולוגית מצטמצמת לבדיקת קיצורים בהתאם ל- GOST 8.417. וזה הכל.

הקישור "מידע כללי, מטרה והרכב" במפרט הטכני

השילוב של "מידע כללי, מטרה והרכב" הראה את עצמו כמצוין לא רק בפיתוח מפרט טכני. הקישור מתאים לכל טקסט עיון בעל אופי תיאורי.

דוגמה - דרישות למספר הרמות ומידת הריכוזיות של המערכת. זהו Oאתה יכול לכתוב ל נָקוּבתת סעיף של המפרט הטכני?

כל אדם יתחיל להסתכל באופן רפלקסיבי בסעיפים של GOST למפרט טכני, מנסה למצוא לפחות רמז כלשהו. בעל ניסיון יזכור מיד את פר.

2.1 מטרת המערכת

חבר שמלחם ישירות או מקים שם משהו תמיד יוכל להגיד לטכנאי למה נוצרת המערכת. בסמכותך, כמובן. מהנדס המערכות או הבוס יגידו לך יותר. בוא נגיד

המערכת חייבת לספק פתרון (היכולת לפתור) את הבעיות הבאות:

1. משימות של איסוף נתונים מכמה, למשל, חיישנים;
2. משימות עיבוד, אחסון, תצוגה וכו' במרכז האיסוף.

זהו. קצת דמיון, והקטע מוכן:

המערכת חייבת להיות בעלת מבנה היררכי ולכלול את רמות ההיררכיה הבאות:

1. רמה 1 - רָמָה איסוף נתונים ;
2. רמה 2 - רָמָה איחוד נתונים (עיבוד מרכזי, אחסון וכו').

שוב, גם ארנבות - וגם במקום. הן רמות ההיררכיה מפורטות והן מידת הריכוזיות. מה הלאה?

2.1.1 רמת איסוף הנתונים

2.1.1.1 מידע כללי

קצת מידע כללי. אתה יכול, למשל, לכתוב שהמפלס מאופיין בחלוקה טריטוריאלית - כל מים יצליחו אם הם מתאימים בערך.

2.1.2.2 מטרה

רמת איסוף נתונים מְיוּעָד(חותמת נוספת):

1. להעביר נתונים מחיישנים מסוימים לרמת הקונסולידציה לפי בקשת (יוזמה) של האחרון;
2. עבור רישום העברת נתונים ביומן האירועים (ואם לפי GOST, אז ב);
3. למשהו אחר.

2.1.2.3 הרכב

שכבת איסוף הנתונים צריכה לכלול:

1. חיישנים כאלה ואחרים;
2. כמה חיישנים אחרים.

מהי הנוחות בשימוש בקישור "מידע כללי, מטרה והרכב"? ואדם מסיים באופן לא רצוני משימה טכנית מובנית היטב - דמוי עץ והיררכית.

2.2.2.3.1 חיישנים כאלה ואחרים

2.2.2.3.1.1 מידע כללי (על חיישנים כאלה ואחרים)

2.2.2.3.1.2 מטרה (של חיישנים כאלה ואחרים)

2.2.2.3.1.3 הרכב (של חיישנים כאלה ואחרים)

העיקר לעצור בזמן.

אַזהָרָה

במהלך הפיתוח והעניין הגדול ביותר הם הבאים:

• קודם כל - . שכן כזה הוא;
• , למשל ו;
• , למשל;
• וכן, למשל;
• מספר אחרים.

אתה לא צריך להיסחף יותר מדי עם GOSTs "נושאיים" כאלה, המכילים דרישות מאוד ספציפיות למתחילים היא "ערוצי תקשורת חייבים לעמוד בדרישות של GOST כך וכך." זו טעות גורלית. ידוע כי הקבלה וההספקה של עבודה ליצירת מערכת, מוצר או מוצר תוכנה קודמת תמיד ליישום.

נניח שביג בוס, שנדהם מהידע המעמיק של המפרט הטכני, בטח בו, לא קרא דבר ושרבט מאשר בעמוד השער של המפרט הטכני (תחת APPROVED, בפינה הימנית העליונה של עמוד השער). הלקוח, בחיוך שפל, הניח בזהירות את שלו (תחת APPROVED, בפינה השמאלית העליונה). הכל, המפרט הטכני ולהיכלל בו, או שזה אפשרי רק בהסכם נוסף עם הלקוח. כאן נכנס המידע הטכני.

הגיע הזמן לבדוק את המערכת (תוכנית, מוצר) לעמידה בדרישות המפרט הטכני. הלקוח, כמובן, ידרוש להראות כי ערוצי התקשורת עומדים בדרישות של GOST כאלה ואחרים.

מה לעשות? זה לא כל כך נורא אם אתה עוסק בערוצי תקשורת, מוכן לספק את זה לביג בוס. הבוס יתרץ את עצמו בפני הלקוח והמידע הטכני ימשיך לחיות (עד הפנצ'ר הבא). אבל הטעם הרע בנשמתו של ביג בוס יישאר לנצח. אין צורך לצפות לקידום.

זה ממש אסון אם אין תעודות. הבוס יצטרך לשלם כסף (שלא נקבע בתקציב) לרשות על מנת לקבל את התעודה הנכספת, להציגה ללקוח ולסגור את העבודה. ייתכן שהטכנאים לא יוכלו לסלוח על טעות כזו.

בקיצור, אתה צריך לכתוב משהו כזה, באנגלית פשוטה:

"אפשר להשתמש (לשמש) את הדברים הבאים כערוצי תקשורת:

1. ערוצי תקשורת -;
2. ערוצים של מפעילי סלולר;
3. ערוצים של מפעילי לוויין;
4. קווי טלפון ציבוריים מוחלפים;
5. מתקן הלקוח;
6. וְכֵן הָלְאָה"

בשום פנים ואופן אין לציין את שער החלפת הנתונים של ערוץ התקשורת, כלומר. פרטים. אם ערוץ התקשורת מיושם על בסיס Ethernet, והמפרט הטכני מצביע בבירור על שער חליפין של לפחות 1200 bps, ללקוח יש זכות מלאה לאלץ את הקבלן לבצע בדיקות מלאות. אפילו במצב כל כך אבסורדי בעליל.

מַסְקָנָה

אז בואו נזכור שוב את נקודות המפתח:

1. הכנת מפרטים טכניים על ידי ייבוא ​​גרסה אלקטרונית של ה-GOST הנדרש;
2. פירוט - פירוק חלקים גדולים של מפרטים טכניים לתתי סעיפים קצרים ופשוטים;
3. בניית תבנית של משפטים בסעיפים (תתי סעיפים וכו') של המפרט הטכני כך ש"התשובה מכילה חצי מהשאלה";
4. פורמליזציה של התוכן של אותם סעיפים שבהם אי אפשר (או) לתת פרטים ספציפיים;
5. שימוש בחותמות;
6. שימוש ברשימות (רשימות תבליט או ממוספרות);
7. יישום הקישור "מידע כללי, מטרה והרכב";
8. שימוש מינימלי ב-GOSTs "נומטיים".

לסיכום, נוכל לתת מספר טיפים נוספים:

• למצוא את "הדג" של המפרט הטכני ולאחר הבנה ביקורתית, לשאול את התוכן של הסעיפים המתאימים (אך לא מהמשאב הידוע procurement.gov.ru - יש שם שטויות מוחלטות);
• להשתמש במסמכים;
• אל תהססו לשאול שאלות.

אתה יכול להזמין Technical Documentation LLC במייל. דוא"ל admin@tdocs. su (ללא רווחים), טל. 8-910-468-09-28 או בטופס.

זכויות יוצרים © Technical Documentation LLC 2018. שאלו את החומרים שלנו עם ברק! בעת שכפול חומרי פורטל, יש צורך להתקין היפר קישור פעיל למקור - הדף עם פרסום זה באתר.