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

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

פיתוח ותחזוקה של כל סוגי האתרים:

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

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 2062 השירותים
מפרט דרישות תוכנה ליישומי אינטרנט
בינוני
~2-3 ימים

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אתר חברה B2B ADVANCE
    פיתוח אתר חברה B2B ADVANCE
    1502
  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1344
  • פיתוח אתר עבור BELFINGROUP
    פיתוח אתר עבור BELFINGROUP
    1052
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1306
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1049
  • פיתוח אתר לחברת FIXPER
    פיתוח אתר לחברת FIXPER
    1033

תארו לעצמכם: צוות פיתוח משקיע שלושה חודשים בבניית תכונות, רק כדי לגלות בשלב הקבלה שהלקוח התכוון למשהו שונה לחלוטין. ללא מסמך מפרט דרישות תוכנה מפורט (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 () => {
    // ...
  });
});
  1. הערות על החלטות מפתח בקוד:
// 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 דרישות פונקציונליות הוא שלושה עד ארבעה שבועות. זה כולל ניתוח תהליכים עסקיים, ראיונות מובנים, כתיבה, שני סבבי סקירה ואישור סופי. העלות מחושבת באופן אישי – צרו קשר להערכת פרויקט. קבלו ייעוץ מומחה.