תארו לעצמכם: צוות פיתוח משקיע שלושה חודשים בבניית תכונות, רק כדי לגלות בשלב הקבלה שהלקוח התכוון למשהו שונה לחלוטין. ללא מסמך מפרט דרישות תוכנה מפורט (SRS), פערים כאלה הם הנורמה. אנחנו יודעים זאת ממקור ראשון: אחרי שנים של עבודה על פרויקטי ווב, ראינו עשרות מקרים שבהם היעדר דרישות ברורות האריך את לוחות הזמנים ב-40% או יותר. SRS הוא חלק מרכזי בתיעוד התוכנה שחוסך כסף ועצבים. הוא הופך את "אני רוצה את זה כמו גוגל" למאפיינים טכניים מדידים המובנים גם למפתח וגם ללקוח. בלעדיו, הסיכון לעבודות חוזרות גדל פי 2–3 והתקציב גדל ב-30–50%.
למה SRS הוא הדרך היחידה להימנע מעבודות חוזרות
מפרט דרישות הוא מקור האמת היחיד לצוות. הוא מסנכרן את הציפיות של הלקוח, המפתחים וה-QA, ומבטל אי-הבנות. התוצאה: פחות עבודות חוזרות, תקציב יציב ולוחות זמנים צפויים. ניהול דרישות הוא תהליך הליבה שלנו, ששוכלל לאורך שנים.
איך לסווג דרישות נכון
הדרישות מתחלקות לשלוש קטגוריות, וחשוב לא לבלבל ביניהן:
- פונקציונליות (FR) – מה המערכת עושה. דוגמה: "המשתמש יכול לאפס סיסמה באמצעות דוא"ל."
- לא פונקציונליות (NFR) – מאפייני התנהגות המערכת. דוגמה: "עמוד ההתחברות חייב להגיב תוך 200ms תחת 500 משתמשים בו-זמנית."
- אילוצים – תנאים חיצוניים שלא ניתן לשנות. למשל: "אינטגרציה רק עם שערי תשלום רוסיים" או "פריסה לרשת סגורה ללא גישה לאינטרנט."
הפורמט הטוב ביותר לדרישות פונקציונליות הוא סיפור משתמש + קריטריוני קבלה + פרטים טכניים. גישה זו חוסכת חצי מהזמן הנדרש לכתיבת בדיקות בהשוואה לטבלאות מסורתיות ומשפרת את הבנת הדרישות ב-30%.
איך SRS חוסך בתקציב
SRS מפורט מפחית את עלויות העבודות החוזרות בעד 40%. לקוח אחד חסך 11–16 אלף דולר בכך שהזמין SRS לפני תחילת הפיתוח. פרויקט אחר נמנע מעבודות חוזרות בשווי 7.2–10 אלף דולר. לפי הסטטיסטיקות שלנו, מפרט מלא מפחית את מספר הבאגים במהלך הפיתוח ב-25% ומקצר את זמן בדיקות הרגרסיה ב-30%. זו דרך ישירה לתקציב וללוח זמנים צפויים. גלו כמה הפרויקט שלכם יכול לחסוך – צרו קשר.
דוגמה: דרישה פונקציונלית FR-047
## FR-047: Двухфакторная аутентификация (TOTP)
**Как** зарегистрированный пользователь, **Я хочу** включить 2FA через приложение-аутентификатор, **Чтобы** защитить аккаунт от несанкционированного доступа.
### Acceptance Criteria
**Включение 2FA:**
- AC-047-1: При переходе в настройки безопасности отображается раздел "Двухфакторная аутентификация"
- AC-047-2: При нажатии "Включить" система генерирует TOTP-секрет (RFC 6238, SHA-1, 6 цифр, 30 сек.)
- AC-047-3: QR-код для Google Authenticator / Authy отображается корректно
- AC-047-4: После ввода первого верного кода 2FA активируется
- AC-047-5: Система выдаёт 10 одноразовых резервных кодов (8 символов, a-z0-9)
**Вход с 2FA:**
- AC-047-6: После ввода верного пароля появляется форма ввода кода
- AC-047-7: Код принимается с допуском ±1 временного окна (90 сек. назад или вперёд)
- AC-047-8: Неверный код — ошибка, счётчик попыток (+1), лимит 5 попыток
- AC-047-9: Резервный код принимается как 2FA, после использования инвалидируется
**Отключение:**
- AC-047-10: Для отключения 2FA требуется текущий пароль + валидный 2FA-код
### Технические детали
**API:**
POST /api/auth/2fa/setup → { secret, qr_url, backup_codes } POST /api/auth/2fa/verify Body: { code } → { enabled: true } POST /api/auth/2fa/disable Body: { password, code } POST /api/auth/2fa/challenge Body: { code | backup_code } → { token }
**Хранение:**
- `totp_secret` шифруется AES-256-GCM перед сохранением в БД
- Ключ шифрования — из KMS, не хранится в коде
- `backup_codes` — bcrypt-хэши, не plaintext
**Миграция БД:**
```sql
ALTER TABLE users ADD COLUMN totp_secret_enc TEXT,
ADD COLUMN totp_enabled BOOLEAN NOT NULL DEFAULT FALSE,
ADD COLUMN totp_verified_at TIMESTAMPTZ;
CREATE TABLE totp_backup_codes (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
code_hash TEXT NOT NULL,
used_at TIMESTAMPTZ,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
```דרישות קשורות: FR-001 (רישום), FR-002 (התחברות), NFR-SEC-003 תלויות: ספריית ## FR-047: Двухфакторная аутентификация (TOTP) **Как** зарегистрированный пользователь, **Я хочу** включить 2FA через приложение-аутентификатор, **Чтобы** защитить аккаунт от несанкционированного доступа. ### Acceptance Criteria **Включение 2FA:** - AC-047-1: При переходе в настройки безопасности отображается раздел "Двухфакторная аутентификация" - AC-047-2: При нажатии "Включить" система генерирует TOTP-секрет (RFC 6238, SHA-1, 6 цифр, 30 сек.) - AC-047-3: QR-код для Google Authenticator / Authy отображается корректно - AC-047-4: После ввода первого верного кода 2FA активируется - AC-047-5: Система выдаёт 10 одноразовых резервных кодов (8 символов, a-z0-9) **Вход с 2FA:** - AC-047-6: После ввода верного пароля появляется форма ввода кода - AC-047-7: Код принимается с допуском ±1 временного окна (90 сек. назад или вперёд) - AC-047-8: Неверный код — ошибка, счётчик попыток (+1), лимит 5 попыток - AC-047-9: Резервный код принимается как 2FA, после использования инвалидируется **Отключение:** - AC-047-10: Для отключения 2FA требуется текущий пароль + валидный 2FA-код ### Технические детали **API:** או שווה ערך התומכת ב-RFC 6238
</details>
## Нефункциональные требования: как их делать измеримыми
Неизмеримые NFR бесполезны: «система должна быть быстрой» — невозможно проверить. Все NFR должны иметь конкретную метрику, условие измерения и источник данных.
| Метрика | Целевое значение | Условие измерения |
|---------|-----------------|-------------------|
| P50 latency | < 50ms | Нагрузка 100 rps, 4 ядра CPU |
| P95 latency | < 200ms | То же |
| P99 latency | < 500ms | То же |
| Error rate | < 0.1% | Нагрузка 100 rps, 10 минут |
| Throughput | ≥ 200 rps | До деградации P95 > 500ms |
**Инструмент проверки:** k6 (сценарий в `tests/load/api-baseline.js`)
**Частота проверки:** Перед каждым релизом в staging
Ещё пример — доступность: uptime ≥99.5% в месяц (простой ≤3.65 ч), плановые окна — 30 минут в 02:00–04:00 МСК с уведомлением за 48 ч. RTO ≤30 мин, RPO ≤1 час. Проверка — UptimeRobot каждую минуту из 3 регионов.
Мы используем чеклист безопасности при описании NFR.
## Почему трассируемость требований — не роскошь?
SRS ценен, когда по любому фрагменту кода можно сказать: «это реализует FR-047». Трассируемость требований ускоряет поиск ошибок в 3 раза по сравнению с разрозненной документацией. Она достигается через:
1. Именование тестов по идентификаторам требований:
```typescript
describe('FR-047: TOTP 2FA', () => {
it('AC-047-7: принимает код с допуском ±1 окна', async () => {
// ...
});
it('AC-047-8: блокирует после 5 неверных попыток', async () => {
// ...
});
});
- הערות על החלטות מפתח בקוד:
// NFR-SEC-001: ротация refresh token при каждом использовании
async function refreshAccessToken(refreshToken: string) {
const session = await validateAndInvalidateRefreshToken(refreshToken);
const newRefreshToken = await createRefreshToken(session.userId);
const accessToken = createAccessToken(session.userId);
return { accessToken, refreshToken: newRefreshToken };
}קישור דרישות לקוד מקצר את זמן חיפוש הבאגים ומפשט את הסקירות. בניסיון שלנו, זה מקצר את זמן בדיקות הרגרסיה ב-25%.
איך להבחין בין מפרט טוב למפרט גרוע
SRS טוב עובר סקירה של שלוש קבוצות: הלקוח בודק את חוקי העסק, המפתחים בודקים את ההיתכנות, וה-QA בודקים את היכולת לאימות. בעיות אופייניות של מפרט גרוע:
| בעיה | דוגמה | פתרון |
|---|---|---|
| עמימות | "העלאת מספר קבצים" – כמה? באיזה גודל? | ציינו מגבלות: מקסימום 10 קבצים, עד 5 MB כל אחד |
| סתירות | במקום אחד מיון לפי תאריך, במקום אחר לפי פופולריות | בצעו סבב סקירה ואחדו לכלל יחיד |
| תרחישים חסרים | המסלול הרגיל מתואר אך לא שגיאות | הוסיפו תרחישים חלופיים: כשל שרת, קלט לא תקין |
אנחנו מבטיחים שכל פריט ב-SRS שלנו ניתן לאימות וליישום.
מה כולל שירות יצירת ה-SRS שלנו
- מסמך SRS ב-Markdown או ב-Confluence עם תיאור מלא של דרישות פונקציונליות ולא פונקציונליות.
- מטריצת עקיבות ממוספרת.
- גרף תלויות דרישות.
- סקירת מסמך בהשתתפות מפתחים ובודקים.
- ייעוץ להבהרת דרישות בכל השלבים.
למהנדסים המוסמכים שלנו יש ניסיון רב בפיתוח ווב והם סיפקו למעלה מ-50 מסמכי SRS לפרויקטים ברמות מורכבות שונות. במהלך השנים צברנו בסיס של תבניות ופתרונות מוכנים שמאיץ את יצירת ה-SRS ב-20%.
השוואת גישות לתיעוד דרישות
| גישה | מהירות כתיבה | הבנה ללקוח | שלמות למפתח |
|---|---|---|---|
| סיפור משתמש + AC | בינונית | גבוהה | גבוהה |
| תרחיש שימוש | גבוהה | בינונית | בינונית |
| מפרט טכני מסורתי | גבוהה | נמוכה | נמוכה |
לוח זמנים ועלות
לוח הזמנים לכתיבת SRS לאפליקציה עם 40–60 דרישות פונקציונליות הוא שלושה עד ארבעה שבועות. זה כולל ניתוח תהליכים עסקיים, ראיונות מובנים, כתיבה, שני סבבי סקירה ואישור סופי. העלות מחושבת באופן אישי – צרו קשר להערכת פרויקט. קבלו ייעוץ מומחה.







