Проверка требований
Контекст задачи
Одной из главных проблем в инженерии требований является то, что требования часто содержат ошибки: двусмысленности, противоречия, непроверяемость, пробелы. Эти ошибки, обнаруженные на поздних этапах разработки, приводят к переделкам, срыву сроков и увеличению бюджета.
Валидация требований — это процесс проверки того, что требования правильно описывают то, что нужно заказчику, и не содержат ошибок. В отличие от верификации (проверка соответствия документа стандартам), валидация отвечает на вопрос: «Те ли требования мы записали?».
Особую ценность имеет перекрёстная проверка (peer review) — когда один студент проверяет спецификацию, разработанную другим. Это позволяет:
- увидеть требования «свежим взглядом»;
- выявить ошибки, которые автор не замечает;
- развить навыки конструктивной критики и коммуникации.
Формулировка
Проведите валидацию требований к программному продукту, используя комплекс методов системного анализа. Работа выполняется в два этапа: индивидуальный анализ и перекрёстная проверка.
Подсказки
Стоп-слова в требованиях SWOT-анализ
А. Индивидуальный анализ (самопроверка)
Проверьте свою спецификацию требований (разработанную ранее или выданную преподавателем) по следующим методам:
А1. Чек-лист базовая проверка
| Характеристика | № | Вопрос для проверки | Статус (✓/✗) | Комментарий |
|---|---|---|---|---|
| Необходимость | 1.1 | Можно ли удалить требование без потери основной функциональности? | ||
| Недвусмысленность | 2.1 | Можно ли понять требование по-разному? | ||
| 2.2 | Есть ли субъективные оценки (удобный, быстрый)? | |||
| 2.3 | Есть ли неопределённые количества (несколько, много)? | |||
| 2.4 | Есть ли сравнения без эталона (лучше, быстрее)? | |||
| 2.5 | Есть ли маркеры необязательности (может, иногда)? | |||
| Согласованность | 3.1 | Одинаковые ли термины используются везде? | ||
| Четкость, краткость | 5.1 | Можно ли выразить требование короче? | ||
| 5.3 | Есть ли в требовании лишние пояснения? | |||
| Выполнимость | 6.1 | Реалистично ли требование технически? | ||
| 6.2 | Укладывается ли в бюджет/сроки/ресурсы? | |||
| 6.3 | Есть ли сверхобобщения (всегда, никогда)? | |||
| Трассируемость | 7.1 | Можно ли определить источник требования? | ||
| Проверяемость | 8.1 | Можно ли написать тест для этого требования? |
А2. Проверка на атомарность
Каждое требование должно описывать одно действие или одно свойство.
| ID требования | Исходная формулировка | Атомарное разбиение | Нарушена ли атомарность? |
|---|---|---|---|
| ФР | «Создавать, редактировать и удалять задачи» | 1. Создавать задачи 2. Редактировать задачи 3. Удалять задачи |
Да (три действия) |
| … | … | … | … |
Правило: Если в требовании есть союзы «и», «или», запятые — проверьте, не нарушена ли атомарность.
А3. Проверка на непротиворечивость
Требования не должны логически противоречить друг другу.
| Пара требований | Противоречие? | Обоснование |
|---|---|---|
| НФР 1 и НФР 2 | Да / Нет | «Система должна быть быстрой» и «Система должна шифровать все данные» — шифрование замедляет работу |
| … | … | … |
Виды противоречий:
- Логическое: А и не А одновременно
- Количественное: «< 1 секунды» и «> 5 секунд»
- Качественное: «Цветной интерфейс» и «Чёрно-белый интерфейс»
А4. Проверка на полноту
В спецификации не должно быть пропущенных разделов или непокрытых сценариев.
| Проверяемый аспект | Покрыт? (✓/✗) | Что отсутствует? |
|---|---|---|
| Все ли роли пользователей описаны? | ||
| Все ли крайние случаи учтены? | ||
| Есть ли требования к обработке ошибок? | ||
| Описано ли поведение системы при сбоях? |
А5. Проверка на практическую реализуемость
Конфликт отличается от противоречия тем, что требования логически не противоречат, но не могут быть одновременно реализованы из-за ограничений по ресурсам, времени или технологии.
| Конфликтующие требования | Причина конфликта | Возможное разрешение |
|---|---|---|
| «Дёшево» и «Быстро» | Бюджетное ограничение | Выбрать приоритет |
| «Поддержка 1000 пользователей» и «Работа на Raspberry Pi» | Аппаратное ограничение | Изменить платформу или требования |
Различие между противоречием и конфликтом:
- Противоречие: требования исключают друг друга по смыслу (логическая ошибка)
- Конфликт: требования могут сосуществовать, но не в рамках заданных ограничений (практическая проблема)
А6. SWOT-анализ спецификации
Оцените спецификацию в целом по четырём квадрантам:
| Квадрант | Вопрос | Ответ (применительно к вашей спецификации) |
|---|---|---|
| Strengths (Сильные стороны) | Что в требованиях сделано хорошо? | |
| Weaknesses (Слабые стороны) | Что отсутствует или плохо сформулировано? | |
| Opportunities (Возможности) | Какие скрытые возможности дают требования? | |
| Threats (Угрозы) | Какие риски не учтены? |
Б. Перекрёстная проверка (Peer Review)
Формат работы: Студенты работают в парах. Каждый проверяет спецификацию другого студента.
Б1. Распределение ролей
| Роль | Задача |
|---|---|
| Автор | Предоставляет свою спецификацию для проверки |
| Рецензент | Проводит валидацию чужой спецификации, оформляет отчёт |
Б2. Шпаргалка для рецензента
Сводная таблица: характеристика требований → вопросы для проверки → стоп-слова/маркеры
| Характеристика | Ключевые вопросы | Стоп-слова / маркеры нарушений |
|---|---|---|
| Необходимость | • Можно ли удалить это требование без потери основной функциональности? • Зачем оно? Какая бизнес-ценность? |
желательно, можно было бы, хорошо бы, было бы неплохо, в идеале, необязательно |
| Недвусмысленность | • Можно ли понять требование по-разному? • Все ли термины определены однозначно? |
удобный, быстрый, лёгкий, красивый, современный, надёжный, эффективный; несколько, много, мало, достаточно, немало; лучше, хуже, быстрее, медленнее; может, иногда, обычно, часто, возможно, как правило |
| Согласованность | • Не противоречит ли это требование другим? • Нет ли конфликта по ресурсам с другими требованиями? |
противоречащие пары (например, «цветной» и «чёрно-белый»); разная терминология для одной сущности; количественные расхождения; конфликт «дёшево vs быстро» |
| Полнота | • Всё ли описано? • Определены ли входы, выходы, обработка ошибок? |
ничего, ничто, никакой, пустой, отсутствует, и т.д., и прочее; незаполненные разделы, нет уникального идентификатора |
| Четкость, краткость | • Коротко и ясно ли сформулировано? • Можно ли выразить короче? |
союзы «и», «или», запятые (признак множественности действий); «для того чтобы», «в целях», «с целью» (лишние обороты); пассивный залог |
| Выполнимость | • Можно ли реализовать в рамках заданных ограничений? • Реалистично ли технически? |
всегда, никогда, любой, каждый, все, абсолютно, полностью; несуществующие технологии, утопичные обещания |
| Трассируемость | • Откуда взялось это требование? • Куда оно ведёт (дизайн, тесты)? |
нет уникального идентификатора (ФР-01, НФР-02); нет источника (кто попросил, какой use case); изолированное требование без связей |
| Проверяемость | • Можно ли проверить выполнение требования объективным способом? • Можно ли написать тест? |
субъективные оценки (красивый, удобный); нет конкретных метрик (секунды, проценты, количество); результат проверки зависит от человека |
Б3. Шаблон отчёта о ревью
```markdown Рецензент: [ФИО] Автор спецификации: [ФИО] Дата проверки: [дата]
Результаты проверки
1. Атомарность
[Список требований, нарушающих атомарность, с предложением разбиения]
2. Непротиворечивость
[Пары противоречивых требований с обоснованием]
3. Полнота
[Что отсутствует в спецификации, какие сценарии не покрыты]
4. Реализуемость
[Пары конфликтующих требований с указанием причины конфликта]
Итоговое заключение
Общая оценка качества спецификации: (отлично / хорошо / требует доработки / неудовлетворительно)
Основные рекомендации автору:
- …
- …
- …
Вопросы автору (если есть):
- …