אנו מפתחים מפרטים טכניים לאתרים שמונעים חוסר שביעות רצון של לקוחות. כמהנדסים עם ניסיון של עשור, הכנו למעלה מ-50 מפרטים טכניים לחנויות מקוונות, שירותים ופורטלים. תלונת לקוח נפוצה: 'זה לא מה שרציתי.' זה קורה בגלל מפרט גרוע. הגישה שלנו: ניתוח מפורט, דרישות פורמליות, וניהול גרסאות ב-Git. מפרט טכני טוב הוא כלי תקשורת בין הלקוח, המפתחים והבודקים. הוא מגדיר מה ייבנה, איך זה נראה, ואיך זה נבדק. ללא מפרט טכני, פרויקט נכנס לכאוס. השירותים שלנו לכתיבת מפרט טכני מתחילים ב-$1,500 לפרויקטים פשוטים ויכולים להגיע ל-$5,000 לפלטפורמות מסחר אלקטרוני מורכבות, וחוסכים לכם אלפים בעלויות עבודה חוזרת. צרו קשר לבדיקת הפרויקט שלכם — נהפוך משאלות כאוטיות לתיעוד ברור.
מטרת המפרט הטכני
הטעות העיקרית במפרט טכני היא תיאור הממשק במקום ההתנהגות. 'כפתור כחול בפינה הימנית' אינו מפרט טכני. אבל 'כאשר לוחצים על הכפתור "ביצוע הזמנה", המערכת יוצרת הזמנה עם סטטוס טיוטה, שומרת את המוצר, שולחת אימייל אישור ומפנה אל /orders/{id}' — זה מפרט טכני.
מפרט טכני איכותי חוסך תקציב. הוא מבטל אי-בהירות ומפחית את הסיכון לעבודה חוזרת. שימוש במפרט טכני מפורט מקצר את זמן הפיתוח בעד פי 2 בהשוואה לדרישות אד-הוק.
מאפייני מפרט טכני איכותי
מפרט טכני טוב כולל:
- קריטריונים מדידים (LCP < 2.5 שניות, המרה > 3%),
- ניסוח חד-משמעי — כל מפתח מבין אותו באותו אופן,
- תיאור התנהגות, לא ממשק,
- שמירה ב-Git עם ניהול גרסאות ודיון באמצעות Pull Request.
מפרט טכני גרוע הוא אוסף של צילומי מסך וביטויים כמו 'תעשו את זה יפה'. הוא מבטיח עבודה חוזרת, שעולה פי 3–5 יותר.
למה Git עדיף לאחסון מפרט טכני
Markdown + Git מציע יתרונות על פני Word:
השוואה בין Word ל-Git
| קריטריון | Word | Git (Markdown) |
|---|---|---|
| ניהול גרסאות | ידני (v1, v2) | אוטומטי (commits) |
| שיתוף פעולה | התנגשויות מיזוג | מיזוג ללא בעיות |
| דיון | הערות מוטבעות | Pull Request עם היסטוריה |
| סימון | ויזואלי | מבוסס טקסט, קריא בכל עורך |
מפרט טכני ב-Git נוח פי 10 לניהול גרסאות. זו הגישה שלנו.
רכיבי מפרט טכני למסחר אלקטרוני
מטרה ויעדי מערכת
מתאר את ההקשר: למי זה מיועד, איזו בעיה עסקית זה פותר, קריטריוני הצלחה (המרה >= 3%, זמן טעינה מתחת ל-2 שניות).
תפקידי משתמש והרשאות
דוגמה למטריצת גישה:
| פעולה | אורח | לקוח | מנהל | אדמין |
|---|---|---|---|---|
| עיון בקטלוג | ✓ | ✓ | ✓ | ✓ |
| הוספה לסל | ✓ | ✓ | — | — |
| ביצוע הזמנה | ✗ | ✓ | — | — |
| ניהול הזמנות | ✗ | שלו | כל | כל |
| ניהול מוצרים | ✗ | ✗ | ✓ | ✓ |
| ניהול משתמשים | ✗ | ✗ | ✗ | ✓ |
דרישות פונקציונליות
כל דרישה בפורמט: מזהה, תיאור, תנאים מוקדמים, תוצאה, חריגים. FR-001: רישום משתמש
- תנאים מוקדמים: המשתמש לא מאומת, האימייל לא רשום.
- תרחיש: הזנת אימייל, סיסמה, שם; אימות; יצירת חשבון עם סטטוס 'לא מאושר'; שליחת אימייל עם קישור (TTL 24 שעות).
- חריגים: האימייל כבר בשימוש → שגיאה; אימייל לא תקין → שגיאה; כשל בשליחה → תור ניסיונות חוזרים.
- תוצאה: רשומה בטבלת משתמשים, רשומה בתור האימיילים.
דרישות לא-פונקציונליות
- ביצועים: אחוזון 95 של API < 300 אלפיות השנייה ב-100 בקשות בשנייה; FCP < 1.5 שניות, LCP < 2.5 שניות; חבילת JS < 150 KB בדחיסת gzip.
- אמינות: זמינות 99.5%, שחזור < 15 דקות, גיבויים יומיים עם שמירה ל-30 יום.
- אבטחה: JWT (TTL שעה + רענון 30 יום), bcrypt (עלות 12), הגבלת קצב, HTTPS, HSTS, שאילתות פרמטריות, CSP.
אינטגרציות
- תשלום: YooKassa (API v3: כרטיס, SBP, YooMoney), webhook עם HMAC-SHA256.
- משלוחים: CDEK (חישוב, יצירת תעודת משלוח, מעקב).
- אימייל: SendGrid (טרנזקציונלי: אישור, שחזור, עדכוני סטטוס).
- אנליטיקה: Yandex.Metrica + GA4 עם מסחר אלקטרוני.
סכמת נתונים
users (1) ─── (N) orders
orders (1) ─── (N) order_items
order_items (N) ─── (1) products
products (N) ─── (1) categories
products (1) ─── (N) product_images
users (1) ─── (1) carts
carts (1) ─── (N) cart_itemsסביבות ופריסה
- פיתוח: Docker Compose מקומית
- סטייג'ינג: שרת סטייג'ינג לבדיקות לפני שחרור
- ייצור: שרת חי
- CI/CD: develop → פריסה אוטומטית לסטייג'ינג, main → פריסה ידנית לייצור עם הרצת בדיקות חובה
- ניטור: UptimeRobot (כל דקה), Sentry (שגיאות), Grafana + Prometheus (מדדים)
קריטריוני קבלה
- עימוד (20 מוצרים לעמוד)
- סינון לפי קטגוריה, מחיר, זמינות
- מיון לפי מחיר, חדשנות, פופולריות
- חיפוש טקסט מלא מ-3 תווים
- כרטיס מוצר: תמונה, תיאור, מחיר, כפתור 'הוסף לסל'
- פירורי לחם עם מיקרודאטה של BreadcrumbList
- LCP < 2.5 שניות במובייל (Lighthouse)
- הוספת מוצר שאינו קיים מחזירה 404
לוח זמנים להכנת מפרט טכני
לאתר מסחר אלקטרוני בינוני (50–100 מסכים), כתיבת מפרט טכני אורכת 2–3 שבועות. זה כולל ראיונות אנליטיים, כתיבת תרחישים, דרישות לא-פונקציונליות וסקירה טכנית. העלות מחושבת באופן אישי — תלויה במורכבות ובמספר האינטגרציות.
טעויות אופייניות בכתיבת מפרט טכני
- תיאור הממשק במקום ההתנהגות
- דילוג על דרישות לא-פונקציונליות
- שימוש בביטויים מעורפלים ללא מספרים
- אי-ציון חריגים ומקרי קצה
- שמירת המפרט ב-Word ללא ניהול גרסאות
מה כלול בעבודה
- בדיקה מלאה של המצב הנוכחי (אם קיים אב-טיפוס או תיעוד קודם)
- ראיונות עם עובדי מפתח של הלקוח (עד 5 אנשים)
- גיבוש דרישות פונקציונליות ולא-פונקציונליות
- תיאור אינטגרציות וסכמת נתונים
- יצירת מטריצת תפקידים והרשאות
- הסכמה ותיעוד קריטריוני קבלה
- ניהול גרסאות ב-Git עם היסטוריית שינויים
- סקירה סופית עם צוות הפיתוח
אנו מבטיחים שקיפות בכל שלב. הזמינו מפרט טכני — אנו מתחילים בבדיקה. קבלו ייעוץ לפרויקט שלכם.