אנו מספקים אפליקציות מובייל במפתח מוכן וכתבנו למעלה מ-50 מפרטים טכניים. נקודת הכאב הנפוצה ביותר? דרישות מעורפלות. הצהרה כמו 'האפליקציה צריכה להיות מהירה וידידותית למשתמש' אינה נותנת למפתח בסיס להעריך מאמץ, ו-QA אינו יכול לבנות תוכנית בדיקות. פרטים קונקרטיים כמו 'רשימת ההזמנות חייבת להיטען תוך 2 שניות ברשת 4G עם 100 משתמשים במקביל' מספקים קו בסיס. מפרט מוגדר היטב מפחית חריגות תקציב ב-20–30% על ידי צמצום שאלות הבהרה במהלך הפיתוח. הנה מה לכלול כדי להימנע מעבודה חוזרת.
מה חייב להיות במפרט הטכני
מפרט טוב פותר שלוש בעיות: הוא מאפשר למפתח להעריך מאמץ, נותן ללקוח קריטריוני קבלה, ומשמש כבסיס לתוכנית הבדיקות של QA. אם המסמך אינו מכסה לפחות אחד מאלה, הוא לא שלם.
דרישות פונקציונליות לא צריכות להיות 'המשתמש יכול להתחבר'. היו ספציפיים:
- אימות באמצעות אימייל + סיסמה, Google Sign-In (
google_sign_in/ GoogleSignIn SDK), Apple Sign-In (חובה ל-iOS אם קיימים התחברויות חברתיות אחרות — לפי הנחיות סקירת חנות האפליקציות סעיף 4.8). - אחסון סשן: JWT ב-
flutter_secure_storage/ iOS Keychain / Android Keystore, זמן חיים של טוקן גישה 15 דקות, טוקן רענון 30 יום. - התנהגות פקיעת טוקן: רענון שקט באמצעות interceptor, אין להכריח את המשתמש לחזור למסך התחברות בכל כניסה.
רמת פירוט זו מבטלת עשרות בקשות הבהרה במהלך הפיתוח.
דרישות לא-פונקציונליות קריטיות
דרישות לא-פונקציונליות (NFR) מוזנחות לעיתים קרובות, אך יש להן השפעה ישירה על חוויית המשתמש. טבלת דוגמה:
| פרמטר | דרישת דוגמה |
|---|---|
| ביצועים | הפעלה קרה ≤ 3 שניות ב-iPhone XR ו-Pixel 5 |
| פסק זמן רשת | פסק זמן חיבור 10 שניות, פסק זמן קבלה 30 שניות |
| מצב לא מקוון | 50 הרשומות האחרונות זמינות ללא אינטרנט |
| גודל אפליקציה | IPA ≤ 50 MB לפני הורדת משאבים (App Thinning) |
| גרסאות מערכת הפעלה נתמכות | iOS 15+, Android 8.0+ (API 26+) |
| לוקליזציה | ru, en חובה; de, fr בגרסה הבאה |
| נגישות | תמיכה ב-Dynamic Type (iOS) ובקנה מידה של גופן (Android) |
ללא NFR, מפתחים יישמו מה שהכי קל להם, לא מה שהמשתמש צריך.
כיצד לתאר מסך במפרט הטכני
כל מסך מתואר באמצעות סיפור משתמש (Как [роль], я хочу [действие], чтобы [цель]) + קישור ל-wireframe או Figma + התנהגות מפורטת. לא 'מסך פרופיל', אלא:
מסך 'עריכת פרופיל': המשתמש יכול לשנות שם (חובה, 2–50 תווים), תמונת פרופיל (בחירה מהגלריה או מצלמה, חיתוך 1:1, מקסימום 5 MB), מספר טלפון (אימות באמצעות SMS OTP). שינויים נשמרים בלחיצה על כפתור 'שמור'. אם אין שינויים, הכפתור מושבת. במקרה של שגיאת רשת, הצגת toast עם הודעת שגיאה; השינויים לא אובדים.
דוגמה מלאה: 'רשימת ההזמנות נטענת מה-API עם פגינציה (20 פריטים לעמוד). תומכת ב-pull-to-refresh. מצב ריק מציג placeholder עם כפתור 'צור הזמנה'. במקרה של שגיאת רשת, הצגת כפתור ניסיון חוזר והודעה. בזמן עדכון נתונים, הצגת skeleton loader.'
השוואה בין מפרט טכני גרוע לטוב
| היבט | דוגמה גרועה | דוגמה טובה |
|---|---|---|
| מסך | 'מסך פרופיל' | תיאור התנהגות מלא עם אימות |
| ביצועים | 'מהיר' | 'הפעלה קרה < 3 שניות, זמן תגובת API < 1 שנייה' |
| מצב לא מקוון | 'עובד ללא אינטרנט' | '50 הרשומות האחרונות זמינות במצב לא מקוון' |
| אימות | 'התחברות חברתית' | 'Google Sign-In, Apple Sign-In, אימייל+סיסמה עם JWT' |
מפרט נכון מפחית את מספר מחזורי התיקונים פי 3 בהשוואה למפרט מעורפל.
אילו חוזי API ותלויות יש לנעול
המפרט צריך לרשום תלויות חיצוניות:
- APIs ו-SDKs של צד שלישי עם גרסאות מדויקות (Firebase, Stripe, Google Maps).
- פורמט תקשורת עם השרת: REST, GraphQL, או WebSocket; סכמת הרשאות (Bearer JWT, API Key, OAuth 2.0).
- אם השרת מפותח במקביל, ספקו חוזה OpenAPI 3.0 מינימלי לצוות המובייל.
מה לא לכלול
פרטי מימוש הם באחריות המפתח. המפרט מתאר מה צריך לעבוד, לא איך. 'להשתמש ב-Flutter' מקובל. 'להשתמש ב-BLoC לניהול מצב' הוא החלטה טכנית שיש לדון בה בנפרד.
התהליך שלנו ולוחות זמנים
- ראיון לקוח — איסוף דרישות עסקיות, תפקידים, עדיפויות.
- ניתוח תחרותי — לימוד דפוסי UX של מובילי התעשייה.
- כתיבת המסמך — דרישות פונקציונליות, NFR, מסכים, תלויות API.
- סקירה ואיטרציה — חידוד מקרי קצה עם הלקוח.
מפרט מלא לוקח 2–3 ימים לאפליקציה עם עד 20 מסכים. למוצרים מורכבים (מרקטפלייס, פינטק) — 4–6 ימים. העלות מחושבת באופן אישי לאחר הערכת היקף.
מה כוללת העבודה שלנו
אנו מספקים מפרט טכני המכסה את כל השלבים: דרישות פונקציונליות ולא-פונקציונליות, סיפורי משתמש, חוזי API, סכמות wireframe. התוצאה היא מסמך מוכן ב-Markdown או Google Docs. אנו גם מייעצים לגבי פרשנות דרישות לפלטפורמת המובייל. הניסיון שלנו: למעלה מ-5 שנים ו-50+ פרויקטים, המבטיחים הסרת עמימות בשלב ההערכה.
במקרה אחרון עבור לקוח משלוחים, המפרט הטכני שלנו הפחית את זמן הפיתוח ב-30% וביטל נקודות מחלוקת. צרו קשר כדי לקבל ייעוץ לפרויקט שלכם וללמוד כיצד נוכל לעזור לכם לנסח מפרט טכני ברור לפיתוח המובייל שלכם.