Введение
Сложно себе представить выбор автомобиля или телевизора без того чтобы мы не подумали про надежность, гарантированный срок работы, разрешение экрана, размеры, удобство использования. И если с функциями мы более-менее чувствуем себя уверено — то вот за качество мы переживаем. Мы тщательно проверяем надежность, мы нюхаем, щупаем, проверяем насколько нам удобно сидеть, насколько все четко видно. Мы интересуем
В случае с разработкой или выбором программных решений у нас получается немного иначе. Есть несколько “потребительских” моделей поведения по отношению к нефункциональным требованиям:
- Мы беспечны и чрезвычайно упрощаем — все должно работать (как никто не знает). При отсутствии четкого критерия кто-то другой определит как конкретно и что значит все. Представьте что в качестве надежности работы выберут “Запорожец”.
- Мы считаем что это вопрос программистов и игнорируем — вот они и сами решают насколько качественное решение они успеют сделать в угоду функциям. Может получится очень крутая функциональность, с очень точными расчетами — но которая очень медленно работает. Представьте что для повышения надежности автомеханик решит сделать обвесок из бетонных плит у вашей машины.
- Мы копируем не понимая что пишем — находим большой документ из какого-то проекта NASA и копируем отличный перечень требований к софту. Что тут думать? У них же очень классные требования к качеству! Окей. И получаем вместо небольшого внутреннего сайта звездолет имперского флота способный справится с миллионами запросов в секунду. Да, и это будет долго и дорого. А так круто!
Ловушки Формулировок
- Избыточная генерализация. Требование по принципу “работать вообще” или “работать всегда” ни выполнимо, ни конкретно.
- Абсолютная неконкретность. Пример — интерфейс должен быть красивым.
- Непостоянность во времени. Пример — наш интерфейс должен быть как у Приложения А.
- Избыточное качество. Яркий пример — добавление “девяток” к показателю надежности. А ведь каждая дополнительная девятка — это еще и дополнительный “нолик” к цене проекта.
Очевидные требования
Сегодня часть нефункциональных требований становятся очевидными и не требующими дополнительных спецификаций. Чем более сложны платформы вы используете — тем больше очевидных требований вы получаете.
Что значит очевидное требование:
- Известная характеристика технологии — .NET Core или Java работает на известных платформах
- Известная характеристика платформы — например, в платформе SharePoint есть поиск, есть хранение документов, есть авторизация доступа, есть механизм управления доступом на уровне записи
- Все решения данного класса по умолчанию поддерживают данную характеристику. Нет обратных примеров
- Наследуемые требования из проекта / программы — если вы выполняете дочерний проект и четко указано что он должен соответствовать его требованиям определенного проекта — вы можете не дублировать требования.
- Наследуемые требования из стандарта — это может быть стандарт на который вы ссылаетесь в документе.
Что пишем
- Текст требования — полная формулировка требований
- Категория требования — группа требований. Может быть определена подразделом требований
- Важность — оценка важности требования для бизнеса.
- Допустимые границы — для требования работающих в рамках
- Уточнение измерения требования — каким образом мы можем измерить и рассчитать целевой показатель