Требования к ПО
Требования к ПО Определяют потребности «заинтересованных сторон», а также тот функционал, которым система должна впоследствии обладать, чтобы удовлетворить эти потребности.
Кому нужны требования?
- Заказчику
- Руководителям проектов
- Аналитикам
- Разработчикам
- Тестировщикам
- Техническим писателям
Почему требования важны?
Ответ на этот вопрос наглядно показан на рисунке ниже. Попросту говоря, требования позволяют говорить на одном языке всем участникам проекта и добиться нужного, устраивающего всех результата.
Все требования делятся на 2 категории в зависимости от того, имеют ли они функциональных характер.
1) Функциональный характер носят такие требования:
- Бизнес-требования
- Пользовательские
- Функциональные
Бизнес-требования определяют высокоуровневые цели организации или заказчика (потребителя) разрабатываемого ПО. В данных требованиях объясняется, почему организации нужна разрабатываемая система.
Пользовательские требования описывают цели и задачи пользователей системы, которые должны достигаться и выполняться при помощи создаваемой системы, а также отвечают на вопросы «кто должен работать?» и «что делать в системе?». Пользовательские требования могут быть оформлены в виде User Story.
Функциональные требования определяют функциональность создаваемой системы для предоставления возможности выполнения пользователям своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
2) Нефункциональный характер имею следующие требования:
- Бизнес-правила (корпоративные стандарты и политики, регламенты, законодательные или нормативные акты и т.д.)
- Системные ограничения (оборудование и ПО)
- Требования к дизайну и юзабилити (навигация, поиск и т.д.)
- Требования к показателям назначения (производительность, устойчивость к сбоям и т.д.)
- Требования к эксплуатации и персоналу (например, обучение персонала должно занимать не более 8 часов)
- Прочие требования и ограничения (автономность, мобильность и т.д.)
Требования должны обладать следующими свойствами:
- Полнота
- Выполнимость
- Недвусмысленность
- Актуальность
- Проверяемость
Важнейшие атрибуты требований:
- ID
- Тип
- Приоритет
- Статус
- Дополнительные атрибуты (итерация, файлы и т.д.)
Таким образом, шаблон пользовательских требований должен иметь формат:
<Пользователь/роль> должен иметь возможность <возможность>
Примеры:
- ПТ-1: Пользователь должен иметь возможность создания текстовых документов
- ПТ-14: Администратор должен иметь возможность настройки компонента
- ПТ-29: Работник ДП должен иметь возможность просмотра журнала движения документов в полном объеме
Шаблон функциональных требований должен соответствовать формату:
<Система/компонент/модуль> должна <описание возможности>
Примеры:
- АК-СТ-75: АК должна предоставлять общую форму выбора адресатов для внешних компонентов для выбора адресатов в их специфических целях
- КРСД-СТ-114: КРСД должен обеспечивать назначение одного получателя на секцию раздела СД
- КИЗ-СТ-102: КИЗ должен обеспечивать задание приоритета задачи (высокий, обычный (по умолчанию) и низкий) при ее создании