[Перевод] Нефункциональные требования в качестве пользовательских историй
Распространенной проблемой при написании пользовательских историй является то, как справиться с нефункциональными требованиями к продукту. Это требования, которые касаются не конкретной функциональности («Как пользователь текстового процессора, я хочу вставить таблицу в свой документ»), а скорее атрибута или характеристики системы. К таким случаям относятся надежность, доступность, переносимость, масштабируемость, удобство использования (удобность), возможность технической поддержки (ремонтопригодность). А также безопасность, производительность, надежность и так далее.
Возвращаясь в «темные века», я вспомнил, как впервые прочитал о «нефункциональных требованиях». Этот термин поставил меня в тупик. Если оно нефункционально, то почему это должно меня волновать? Я уверен, что автор той книги уже через страницу разъяснил суть, но данный термин всегда казался мне странным. Я предпочитаю считать нефункциональные требования «ограничениями», которые мы накладываем на систему. Когда владелец продукта говорит: «Эта система должна адекватно работать при 100 000 одновременных пользователей», он накладывает ограничения на команду разработчиков.
Владелец продукта фактически говорит: «Разрабатывайте это программное обеспечение как угодно, пока у вас не будет 100 000 одновременных пользователей». Каждое ограничение, которое мы накладываем на систему, немного сужает возможности выбора при проектировании; название «ограничения», вместо «нефункциональные требования» способствует тому, что мы будем всегда помнить об этом. К счастью, ограничения/нефункциональные требования могут быть легко обработаны в виде пользовательских историй. Вот пара примеров:
Как пользователь, я хочу иметь возможность запускать ваш продукт на всех версиях Windows, начиная с Windows 95.
Как технический директор, я хочу, чтобы система использовала существующую базу данных заказов, а не создавала новую, чтобы не было необходимости поддерживать еще одну.
Как пользователь, я хочу, чтобы сайт был доступен в 99,999 процентах случаев, когда я пытаюсь зайти на него, чтобы не испытывать разочарования и не искать другой.
Как человек, который говорит на латинском языке, в какой‑то момент я должен иметь возможность воспользоваться вашей программой
Как пользователь, я хочу, чтобы инструкции по навигации были лучшими в 90 процентах случаев и обоснованными в 99 процентах случаев.
Как вы можете видеть из этих примеров, мне легко удалось придерживаться шаблона «Как… , я хочу, чтобы…», который я предпочитаю для большинства пользовательских историй. Это происходит по нескольким причинам, но здесь хотелось бы подробнее остановиться только на одной из них. Рассмотрим пример, когда технический директор заставляет команду использовать существующую базу данных заказов. (Это была реальная ситуация; команда рассматривала возможность создания второй базы данных заказов, которая будет синхронизироваться ночью. Технический директор узнал об этом и сказал: «Нет!»).
Если бы мы написали это требование просто: «Должен использовать существующую базу данных заказов», то вполне возможно, что через несколько месяцев уже и не вспомнили, почему должны быть ограничены таким образом. Спросив у владельца продукта, обеспокоит ли ее использование дополнительной базы данных, мы получили ответ о том, что все нормально и она не возражает. А могли бы совершить ошибку, ограничив себя, используя только одну базу.
Использование чьих либо пожеланий со стороны может быть очень полезным. Но вы должны быть осторожны, чтобы не увлечься этим шаблоном. Это всего лишь инструмент для размышлений. Попытка вписать ограничение в данный шаблон — хорошее упражнение, поскольку оно помогает убедиться, что вы понимаете, кто чего хочет и с какой целью. Но в том случае, если в конечном итоге вы вдруг сформулируете запутанное утверждение — отбросьте шаблон. Если вы не можете найти способ выразить суть ограничения, просто опишите его так, как вам кажется естественным и оно будет понятно окружающим.
Нефункциональные требования часто вызывают трудности у аналитика при работе с ними, а еще больше проблем они могут вызвать в случае их некачественной проработки. Поговорим об этом на открытом вебинаре завтра, а также:
обсудим актуальные проблемы в области работы с НФТ;
сформируем базовую структуру подходов и методов в области работы с НФТ;
получим представление о том, где можно взять шаблоны для формулировок требований и какие источники в отрытом доступе стоит посмотреть при изучении данной темы.
В результате вебинара мы структурируем представление об НФТ и получим список источников для дальнейшего более глубокого изучения. Записаться можно на странице онлайн‑курса «Системный аналитик. Advanced».
