Какие знаешь артефакты требований?

Question

claude-haiku-4.5 · Accepted Answer

## Артефакты требований в разработке ПО

**Артефакты требований** — это документы и модели, которые используются для описания, анализа и коммуникации того, что должно быть построено. Они служат основой для разработки и тестирования, обеспечивая понимание между заинтересованными сторонами.

### 1. User Stories (Пользовательские истории)

**Определение:** Краткое описание функции с точки зрения конечного пользователя.

**Формат:**
```
Как [тип пользователя]
Я хочу [выполнить действие]
Чтобы [получить выгоду]
```

**Пример:**
```
Как зарегистрированный пользователь
Я хочу видеть историю своих заказов
Чтобы отследить прошлые покупки и переделать похожие заказы

Acceptance Criteria:
- История содержит все заказы за последние 2 года
- Каждый заказ показывает дату, сумму и статус
- Я могу отсортировать по дате
- Я могу нажать на заказ и увидеть детали
```

**Преимущества:**
- Простота и понятность
- Фокус на ценность для пользователя
- Легко приоритизировать
- Подходит для Agile методологии

### 2. Acceptance Criteria (Критерии приёмки)

**Определение:** Конкретные условия, которые должны быть выполнены для того, чтобы задача считалась завершённой.

**Форматы:**

**Given-When-Then (BDD стиль):**
```
Given (Дано) пользователь авторизован
When (Когда) он кликает на кнопку "История заказов"
Then (Тогда) он видит список всех своих заказов
```

**Простые критерии:**
```
- [x] Кнопка "Скачать отчёт" видна на странице
- [x] При клике генерируется PDF файл
- [x] PDF содержит все данные из таблицы
- [x] Файл скачивается за менее чем 5 секунд
- [x] Формат PDF корректный на всех браузерах
```

### 3. Requirements Document (Документ требований)

**Типы:**

#### Functional Requirements (Функциональные требования)

Описывают что система должна делать:

```
Платеж:
1. Система должна принимать платежи через Stripe
2. Система должна поддерживать:
   - Кредитные карты (Visa, MasterCard, AmEx)
   - Apple Pay
   - Google Pay
3. При успешной транзакции пользователь получает email подтверждение
4. При ошибке платежа показывается сообщение об ошибке
5. Система должна повторить попытку платежа 3 раза перед отказом
```

#### Non-Functional Requirements (Нефункциональные требования)

Описывают как система должна себя вести:

```
Производительность:
- Страница должна загружаться менее чем за 3 секунды
- API должна обработать 1000 запросов в секунду
- База данных должна сохранять запросы менее чем за 100ms

Надёжность:
- Uptime >= 99.9%
- RTO (Recovery Time Objective) = 1 час
- RPO (Recovery Point Objective) = 15 минут

Безопасность:
- Все данные должны передаваться через HTTPS
- Пароли хэшируются с использованием bcrypt
- SQL injection должна быть невозможна
- XSS должна быть невозможна

Удобство использования:
- Интерфейс должен быть понятен пользователям без обучения
- Время выполнения основных операций <= 5 кликов
- Приложение должно быть мобильным
```

### 4. Use Cases (Сценарии использования)

**Определение:** Описание взаимодействия между актором (пользователем) и системой для достижения конкретной цели.

**Структура:**
```
Имя: "Размещение заказа"
Актор: Покупатель
Предусловие: Пользователь авторизован, корзина не пуста
Основной сценарий:
  1. Пользователь кликает на "Оформить заказ"
  2. Система показывает форму доставки
  3. Пользователь заполняет адрес доставки
  4. Система проверяет адрес
  5. Система показывает варианты доставки и стоимость
  6. Пользователь выбирает способ доставки
  7. Система показывает форму оплаты
  8. Пользователь заполняет данные карты
  9. Система обрабатывает платёж
  10. Система показывает подтверждение заказа

Альтернативные сценарии:
  3a. Адрес некорректен:
      3a1. Система показывает ошибку
      3a2. Пользователь исправляет адрес (вернуться к шагу 3)
  
  9a. Платёж отклонен:
      9a1. Система показывает ошибку
      9a2. Пользователь вводит другую карту (вернуться к шагу 7)

Постусловие: Заказ создан, email отправлен, товары зарезервированы
```

### 5. Диаграммы (Visual Artifacts)

#### Use Case Diagrams
```
          ┌─────────────┐
          │   User      │
          └──────┬──────┘
                 │
         ┌───────┼───────┐
         │       │       │
    ┌────▼───┐ ┌─┴──┐ ┌──┴────┐
    │ Browse  │ │Add │ │Checkout│
    │Products │ │Cart│ │        │
    └────────┘ └────┘ └──┬─────┘
                         │
                    ┌────▼─────┐
                    │PaymentGW  │
                    └───────────┘
```

#### Flow Diagrams (Flowcharts)
```
┌─────────────┐
│   START     │
└──────┬──────┘
       │
       ▼
┌──────────────────┐
│ User clicks Add  │
│ to Cart          │
└──────┬───────────┘
       │
       ▼
   ┌───────┐
   │Item in│───No──┐
   │stock? │       │
   └───┬───┘       │
       │Yes        │
       ▼           ▼
  ┌────────┐   ┌──────────┐
  │Add item│   │Show Error│
  └────┬───┘   └──────────┘
       │
       ▼
┌──────────────┐
│Update Cart   │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   SUCCESS    │
└──────────────┘
```

#### State Diagrams
```
          New
          │
          ▼
    ┌─────────────┐
    │ Submitted   │
    └─────┬───────┘
          │
          ▼
    ┌─────────────┐
    │ Confirmed   │
    └─────┬───────┘
          │
          ▼
    ┌─────────────┐
    │ Shipped     │
    └─────┬───────┘
          │
          ▼
    ┌─────────────┐
    │ Delivered   │
    └─────────────┘
```

### 6. Product Requirements Document (PRD)

**Определение:** Комплексный документ, описывающий видение, цели и требования продукта.

**Структура:**
```
1. Executive Summary
   - Обзор продукта
   - Основные преимущества
   - Целевая аудитория

2. Vision & Goals
   - Видение продукта
   - Бизнес-цели
   - Метрики успеха

3. Market Analysis
   - Анализ конкурентов
   - Рыночная возможность
   - Целевой сегмент

4. Features
   - Core features
   - Nice-to-have features
   - Excluded features (Scope)

5. User Personas & Journeys
   - Описание типичных пользователей
   - Их goals и painpoints
   - Пути взаимодействия с продуктом

6. Wireframes & Mockups
   - Низкоуровневые наброски
   - Детальные дизайны
   - Прототипы

7. Requirements
   - Функциональные требования
   - Нефункциональные требования
   - Constraints и Assumptions

8. Success Metrics
   - KPIs
   - Analytics
   - Measurement plan
```

### 7. Data Models & Schemas

**ER Diagram (Entity Relationship):**
```
┌──────────┐         ┌──────────┐
│  Users   │─────────│  Orders  │
├──────────┤         ├──────────┤
│ id (PK)  │1      * │ id (PK)  │
│ email    │         │ user_id  │
│ name     │         │ date     │
│ phone    │         │ total    │
└──────────┘         └──────────┘
                           │
                           │ 1    *
                           ├───────┐
                           │       │
                      ┌────▼──┐ ┌─┴────────┐
                      │Items  │ │Shipment  │
                      ├───────┤ ├──────────┤
                      │ id    │ │ id       │
                      │order_ │ │ order_id │
                      │product│ │ status   │
                      └───────┘ └──────────┘
```

### 8. Mock-ups & Wireframes

**Low-fidelity:**
- Быстрые наброски
- Чёрно-белые
- Фокус на layout

**High-fidelity:**
- Детальные дизайны
- Цвета, типография
- Близко к финальному виду
- Инструменты: Figma, Adobe XD, Sketch

### 9. API Specifications (OpenAPI/Swagger)

```yaml
openapi: 3.0.0
info:
  title: Shop API
  version: 1.0.0

paths:
  /api/v1/orders:
    post:
      summary: Create order
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                items:
                  type: array
                  items:
                    $ref: '#/components/schemas/OrderItem'
      responses:
        '201':
          description: Order created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Order'
        '400':
          description: Validation error
```

### 10. Acceptance Test Cases

```
Тест-кейс: Успешное размещение заказа
ID: TC_001
Данные:
  - Email: test@example.com
  - Пароль: password123
  - Товар: iPhone 15
  - Количество: 1
  - Адрес: ул. Пушкина, д. 1

Шаги:
1. Логин в систему (test@example.com)
2. Поиск товара "iPhone 15"
3. Клик на товар
4. Клик на "Add to Cart"
5. Клик на "Checkout"
6. Заполнение адреса доставки
7. Выбор способа доставки
8. Ввод данных карты
9. Клик на "Place Order"

Ожидаемый результат:
- Заказ успешно создан
- На экране отображается номер заказа
- На email отправлено подтверждение
- Товар исчезает из каталога (нет в наличии)
```

### Сравнение артефактов

| Артефакт | Деталь | Аудитория | Когда создавать |
|----------|--------|-----------|----------|
| User Story | Низкая | Разработчик, PO | Планирование спринта |
| Acceptance Criteria | Высокая | QA, Dev | Начало разработки |
| Requirements Doc | Высокая | Все stakeholders | Начало проекта |
| Use Case | Средняя | Аналитик, Dev | Фаза анализа |
| Wireframe | Средняя | Designer, Stakeholders | Фаза дизайна |
| API Spec | Высокая | Backend, Frontend Dev | До реализации API |
| Test Cases | Высокая | QA | Фаза тестирования |

### Best Practices

1. **SMART критерии** — Specific, Measurable, Achievable, Relevant, Time-bound
2. **Понятность** — используй язык заинтересованных сторон
3. **Полнота** — охватывай все аспекты требования
4. **Отслеживаемость** — каждое требование должно быть отслеживаемо
5. **Приоритизация** — не все требования равнозначны
6. **Версионирование** — отслеживай изменения требований
7. **Валидация** — согласуй требования со всеми stakeholders
8. **Недвусмысленность** — избегай интерпретаций

### Заключение

Артефакты требований — это основа успешной разработки ПО. Они обеспечивают:
- Ясное понимание между всеми сторонами
- Снижение переделок и рисков
- Быструю разработку и тестирование
- Документацию для будущих изменений

Выбор правильного артефакта для каждого этапа проекта критичен для успеха.

Артефакт	Деталь	Аудитория	Когда создавать
User Story	Низкая	Разработчик, PO	Планирование спринта
Acceptance Criteria	Высокая	QA, Dev	Начало разработки
Requirements Doc	Высокая	Все stakeholders	Начало проекта
Use Case	Средняя	Аналитик, Dev	Фаза анализа
Wireframe	Средняя	Designer, Stakeholders	Фаза дизайна
API Spec	Высокая	Backend, Frontend Dev	До реализации API
Test Cases	Высокая	QA	Фаза тестирования

Какие знаешь артефакты требований?

Комментарии (1)

Артефакты требований в разработке ПО

1. User Stories (Пользовательские истории)

2. Acceptance Criteria (Критерии приёмки)

3. Requirements Document (Документ требований)

Functional Requirements (Функциональные требования)

Non-Functional Requirements (Нефункциональные требования)

4. Use Cases (Сценарии использования)

5. Диаграммы (Visual Artifacts)

Use Case Diagrams

Flow Diagrams (Flowcharts)

State Diagrams

6. Product Requirements Document (PRD)

7. Data Models & Schemas

8. Mock-ups & Wireframes

9. API Specifications (OpenAPI/Swagger)

10. Acceptance Test Cases

Сравнение артефактов

Best Practices

Заключение