Рекомендации по подготовке требований к ПО
Структура требований
В основе качественной структуры требований обычно лежит модель, состоящая из двух компонентов:
- требования заинтересованных сторон – организационная модель, модель бизнес-процессов, модель потоков данных, диаграмма состояний и т.п.;
- системные требования – use case модель, дерево целей, и т.п.;
При этом нужно помнить: в структуре требований должно быть место для требований, не попавших в основную модель – таких, как ограничения, нефункциональные требования, исключения и т.д. Сама же структура должна улучшаться в процессе работы.
Качественная структура требований должна помогать решать следующие задачи:
- помогать лучше понять большой объем информации;
- оперативно находить набор требований, относящийся к определенной теме или предмету;
- сокращать количество требований, выявлять пробелы, повторения и противоречия;
- оценить требования (стоимость реализации и риски);
- вносить изменения и повторно использовать часть требований.
Критерии законченного набора требований таковы:
- полнота – все необходимые требования записаны;
- непротиворечивость – не существует требований, противоречащих друг другу;
- отсутствие избыточности – каждое требование сформулировано только один раз (нет повторов);
- модульность – требования близкие друг другу содержатся в одном разделе;
- структурированность – наличие ясной четкой структуры документа с требованиями;
- удовлетворенность – достигнут необходимый уровень покрытия требований связями типа «удовлетворяет» тестируемость: достигнут необходимый уровень покрытия требований тестами.
Рекомендации для разработки требований
- Определите структуру требований, и постоянно улучшайте ее в процессе работы с требованиями.
- Записывайте требования как можно раньше, даже если они далеки от совершенства.
- Как можно раньше определите атрибуты требований.
- Как можно быстрее подготовьте первую версию требований, для того чтобы получить отзывы.
- Улучшайте требования в процессе работы удаляя повторения, преждевременные технические решения и несогласованность.
- Постоянно обсуждайте требования и собирайте замечания, делайте как можно быстрее новые версии требований.
- Демонстрация пользователям гораздо лучше, чем «экспертный» анализ.
- Основные правила для написания требований:
- Используйте простой прямой язык.
- Пишите требования, которые можно проверить.
- Используйте определенную и согласованную терминологию.
- В одном требовании пишите только одно требование.
Критерии текста требований:
- атомарность – каждое требование должно представлять собой один элемент иерархии требований, пригодный для установки связей с ним;
- уникальность – каждое требование должно иметь собственный уникальный идентификатор;
- выполнимость – требование должны быть технически реализуемо в установленные сроки, в рамках выделенного бюджета;
- законность – не должно противоречить применимому законодательству;
- ясность – должно быть понятно сформулировано;
- точность – должно быть точно и лаконично;
- проверяемость – должна существовать возможность проверки реализации каждого конкретного требования;
- абстрактность – не должно навязывать определенные технические решения, характерные для более низких уровней требований (спецификаций).
И напоследок – правила, соблюдение которых позволит избежать формирования некачественных требований:
- избегайте хаоса: необходимо сконцентрироваться на самом важном,
- требование не должно быть похоже на роман;
- избегайте «лазеек», таких как «если это необходимо», поскольку они делают требование бесполезным;
- не помещайте больше одного требования в один параграф (зачастую можно определить, что в одном параграфе больше одного требования по наличию «и»);
- избегайте рассуждений;
- избегайте нечетких слов (обычно, в основном, часто, нормально, типично);
- избегайте использования неопределенных терминов (удобный в использовании, универсальный, гибкий);
- избегайте принятия желаемого за требуемое (100 % надежный, приятный для всех пользователей, безопасный, подходящий для всех платформ, не должен никогда ломаться, обрабатывать все неожиданные сбои, быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем).
