← Назад к вопросам
Что записать в техническое задание при противоречии требований?
2.0 Middle🔥 251 комментариев
#User Story и Use Case#Требования и их анализ
Комментарии (1)
🐱
claude-haiku-4.5PrepBro AI29 мар. 2026 г.(ред.)
Ответ сгенерирован нейросетью и может содержать ошибки
Что записать в техническое задание при противоречии требований?
Краткий ответ
Никогда не скрывай противоречие в TZ. Документируй его явно с решением или вариантами.
Типы противоречий
1. Функциональные противоречия
"Система должна быть offline-first"
VS
"Система должна всегда синхронизировать в реальном времени"
2. Производительность vs Функциональность
"Response < 100ms"
VS
"Поддержка 1M records с complex filtering"
3. Security vs Usability
"Максимальная безопасность"
VS
"Пользователи не хотят вводить пароль каждый раз"
4. Scope vs Budget
"Нужно 20 features"
VS
"Бюджет на 5 features"
5. Scope vs Timeline
"Все features важны"
VS
"Нужно launch через месяц"
Case 1: Противоречие в Performance
Реальный пример:
OLD requirement (from Product Manager):
FR-001: "System must export 100k records in < 5 seconds"
NEW requirement (from Client):
FR-002: "Export must include full text search, filters, and sorting"
FR-003: "System must support filtering by 50+ fields"
The problem:
Export 100k records with full-text search on 50 fields
Theoretically possible but requires heavy optimization
On normal hardware: 15-30 seconds (violates 5-second requirement)
Что писать в TZ:
═══════════════════════════════════════════════════════════════
REQUIREMENT CONFLICT LOG
═══════════════════════════════════════════════════════════════
Conflict #1: Export Performance vs Functionality
Conflicting Requirements:
FR-001: "Export 100k records in < 5 seconds" (Product Manager)
FR-002: "Include full-text search capability" (Client)
FR-003: "Support 50+ filter fields" (Client)
Technical Analysis:
- Full-text search on large dataset = index overhead
- 50+ filter fields = complex query optimization
- Export 100k: normally 2-3 seconds
- With full-text search: add 3-5 seconds minimum
- With 50+ filter fields: add 2-3 seconds minimum
- Total realistic time: 7-11 seconds
Conclusion: Cannot achieve 5-second target with all features
Options:
Option A: Reduce to 5 filter fields (most important)
+ Pros: Can achieve 5-second target
- Cons: Client loses filtering capability
- Impact: Scope reduction
Option B: Extend deadline to 15 seconds
+ Pros: Can include all features
- Cons: Slightly slower UX
- Impact: None (reasonable for complex operation)
Option C: Two-stage export
+ Stage 1: Quick export without full-text search (5 sec)
+ Stage 2: Full export with all filters (async, 20 sec)
+ Pros: Fast preview + comprehensive export
- Cons: More complex implementation
- Impact: +10 hours development
Option D: Server optimization (caching, indexing)
+ Pros: Achieve 5-second target with all features
- Cons: Significant optimization effort, risk of bugs
- Impact: +50 hours development
RECOMMENDATION:
Option B: Extend deadline to 15 seconds
Reasoning: "This is reasonable for complex operation with 50 filters.
Most users will export < 10k records (< 5 sec anyway).
Occasional 100k export taking 15 sec is acceptable."
Decision Status: PENDING (awaiting client sign-off)
Signed off by:
Product Manager: _______ Date: _______
Client: _______ Date: _______
В TZ напишешь:
FR-001 (MODIFIED): "Export functionality"
Base requirement: Export up to 100,000 records
With features: Full-text search, 50+ filter fields, sorting
Performance target: 15 seconds (for full dataset)
Special cases:
- Exporting < 10k records: < 5 seconds
- Exporting 10k-50k records: 5-10 seconds
- Exporting 50k-100k records: 10-15 seconds
Rationale: See REQUIREMENT CONFLICT LOG - Option B approved
Case 2: Противоречие между Business и Technical
Пример:
Business requirement:
"Support ALL users simultaneously accessing system"
(meaning: unlimited concurrent users)
Technical constraints:
"Server can handle max 1000 concurrent connections"
(limit of database connection pool)
Как задокументировать:
═══════════════════════════════════════════════════════════════
REQUIREMENT CONFLICT LOG
═══════════════════════════════════════════════════════════════
Conflict #2: Unlimited Users vs Technical Limits
Conflicting Statements:
Business: "System must support all users simultaneously"
Technical: "Max 1000 concurrent connections per server"
Clarifications:
1. What does "all users" mean?
Definition: "How many total users in the system?"
Answer: "Currently 5000 users"
Question: "How many simultaneously peak?"
Answer: "Peak: 500 concurrent (during business hours)"
→ NOT all 5000 at same time!
→ Peak is 500 concurrent
2. What is acceptable failure mode?
Option A: System rejects login ("Too many users")
Option B: System degrades performance
Option C: System queues requests
Client choice: Option A is OK
3. What is acceptable load?
Technology: Current database = 1000 connections
But we need: System scales to 5000 concurrent
Solution: Implement connection pooling, caching
Timeline: 3 weeks additional
Cost: +$20k
OR
Accept limit: Max 500 concurrent users
No additional cost
Document as limitation
RESOLUTION:
Accepted constraint: Max 500 concurrent users
Beyond that: System returns error 503 (Service Unavailable)
Monitoring: Alert when > 400 concurrent
Future upgrade: Move to cloud scaling (phase 2)
В TZ запишешь:
NFREQ-SCALABILITY-001 (CLARIFIED):
"System supports up to 500 concurrent users simultaneously.
Current user base: 5,000
Peak concurrent: ~500 (acceptable)
Beyond 500 concurrent users:
- System returns 503 error
- Monitoring alerts at 400 concurrent
- Plan for phase 2: upgrade to cloud for unlimited scale
Rationale: See REQUIREMENT CONFLICT LOG #2"
Case 3: Когда противоречие невозможно разрешить
Ситуация:
Client хочет:
1. Maximum security (offline encryption, no data in cloud)
2. Real-time synchronization across devices
3. Zero maintenance (fully managed service)
Proблема:
You can't have all three:
- Max security + offline = no real-time sync possible
- Real-time sync = data must be in cloud = less secure
- Fully managed = less control = less security
Как документировать такой case:
═══════════════════════════════════════════════════════════════
REQUIREMENT CONFLICT LOG - CRITICAL
═══════════════════════════════════════════════════════════════
Conflict #3: Contradictory Goals
Requested:
1. FR-001: "Maximum security - offline encryption"
2. FR-002: "Real-time sync across all devices"
3. FR-003: "Zero maintenance, fully managed service"
Analysis:
These three requirements are mutually exclusive.
Trade-off Matrix:
Security Real-time Managed
Option A: High Low No (Offline, client-managed)
Option B: Medium High Yes (Cloud-based, managed)
Option C: Low High Yes (Cloud, minimal encryption)
Client must choose ONE primary requirement:
If PRIMARY = Security:
→ Choose Option A (offline, client-managed)
→ Accept: No real-time sync, user must manage keys
→ Cost: Lower, risk: data loss if user loses device
If PRIMARY = Real-time:
→ Choose Option B (cloud-based, managed)
→ Accept: Data stored in cloud, medium security
→ Cost: Medium, risk: cloud breach
If PRIMARY = Zero Maintenance:
→ Choose Option C (cloud, minimal encryption)
→ Accept: Less privacy, fully managed
→ Cost: Low, risk: low security
REQUIRED: Client decision before we proceed
This decision affects entire architecture
В TZ пишешь:
⚠️ CRITICAL: DESIGN DECISION REQUIRED
Client must choose primary requirement:
A) Offline encryption (max security)
→ No real-time sync
→ User-managed security keys
→ Timeline: 4 months
→ Cost: $200k
B) Cloud-managed real-time sync (medium security)
→ All devices sync in real-time
→ Server-side encryption
→ Timeline: 3 months
→ Cost: $150k
C) No encryption (fastest, cheapest)
→ Real-time sync everywhere
→ Fully managed service
→ Timeline: 2 months
→ Cost: $100k
WE CANNOT DELIVER ALL THREE.
Client decision required: Sign A, B, or C
Best Practices
1. Документируй противоречие, не скрывай
❌ Плохо:
TZ просто описывает требования
Разработчик видит противоречие при разработке
Слишком поздно, нужна переделка
✓ Хорошо:
TZ содержит раздел "Known Conflicts"
Противоречие resolved перед разработкой
No surprises, smooth delivery
2. Анализируй impact
Для каждого противоречия:
- Что это означает? (clarify)
- Какие варианты решения? (options)
- Какой impact каждого? (cost/time/quality)
- Что рекомендуешь? (my recommendation)
3. Получи sign-off
Не продолжай разработку пока:
☑ Противоречие задокументировано
☑ Все стороны согласны с решением
☑ Решение подписано
☑ TZ обновлён с решением
4. Используй clear format
Структура конфликта:
- What: Что противоречит?
- Why: Почему это проблема?
- Impact: Какой impact на проект?
- Options: Какие есть варианты?
- Recommendation: Что я предлагаю?
- Status: Разрешено или pending?
Пример полного документа
═══════════════════════════════════════════════════════════════
TECHNICAL SPECIFICATION (ТЗ)
Project: Payment System
Version: 2.0
Date: 2026-04-15
═══════════════════════════════════════════════════════════════
... (обычное содержание ТЗ)
───────────────────────────────────────────────────────────────
APPENDIX A: REQUIREMENT CONFLICTS & RESOLUTIONS
───────────────────────────────────────────────────────────────
Conflict #1: Payment Processing Speed vs Features
Status: RESOLVED
Resolution: Option B (extend deadline to 15 sec)
Signed: PM ✓, Client ✓
Conflict #2: Unlimited Concurrent Users vs Server Limits
Status: RESOLVED
Resolution: Cap at 500 concurrent users
Signed: CTO ✓, PM ✓, Client ✓
Conflict #3: Security vs Real-time Sync vs Managed Service
Status: PENDING
Action required: Client chooses primary requirement
Deadline: 2026-04-20
───────────────────────────────────────────────────────────────
Вывод
Противоречия в требованиях — это нормально.
Но скрывать их в TZ — это ошибка.
Вместо того:
- Выяви противоречие
- Задокументируй явно
- Анализируй варианты
- Рекомендуй решение
- Получи sign-off
- Обнови TZ с решением
Этот процесс:
- Экономит недели разработки
- Избегает surprises
- Держит всех aligned
- Защищает проект
Как System Analyst, моя работа — выявлять эти противоречия до разработки, не во время разработки.