Д. Богданов, М. Максимов. Нефункциональные требования. Все то, что вы хотели узнать...

• Приветствие и представление канала "Системный подход".  

• Обсуждение важности системного мышления и практики его применения.  

• Личный опыт автора с нефункциональными требованиями.  

• Важность нефункциональных требований в проектах.  

• Проблемы, возникающие при их отсутствии или неправильном определении.  

• Представление спикеров: Михаил Максимов и Денис Богданов.  

• Обсуждение теоретической части и интерактивной игры.  

• Примеры кейсов и их анализ.  

• Процесс работы с нефункциональными требованиями и взаимодействие с другими ролями.  

• Примеры сбоев в сервисах: Госуслуги, Rutube, IKEA.  

• Важность понимания нагрузок и условий сбоев.  

• Необходимость проработки нефункциональных требований для обеспечения надежности и безопасности.  

• Проблемы, связанные с резонансными сбоями в госсекторе.  

• Влияние на безопасность и регулирующие органы.  

• Важность коммуникации с другими ролями для проработки нефункциональных требований.  

• Проблемы аналитиков с проработкой нефункциональных требований.  

• Недостаточная осведомленность и сложность работы с НФТ.  

• Причины, по которым НФТ часто пропускаются и получают мало внимания.  

• Аналитики часто избегают работы с нефункциональными требованиями НФТ из-за страха дополнительной работы.  

• Основная причина - нехватка уверенности и компетенций.  

• Если НФТ не прорабатывать с самого начала, никто потом не займется этим.  

• НФТ требуют дополнительного времени и ресурсов.  

• Важно, чтобы менеджмент проекта понимал необходимость НФТ.  

• НФТ определяют ключевые свойства системы, которые можно тестировать и отслеживать.  

• НФТ могут быть декомпозированы на несколько уровней.  

• На верхнем уровне НФТ могут быть полезны для всей системы.  

• На более детальном уровне НФТ могут быть полезны для конкретных функциональностей.  

• В компании по перевозкам ключевой функциональностью может быть оформление посылок.  

• Важно, чтобы система быстро реагировала на сигналы и позволяла вносить данные в удобном виде.  

• НФТ можно измерять по всем функциональностям, но это не всегда целесообразно.  

• НФТ и бизнес-правила - разные сущности.  

• НФТ предъявляются к системе или продукту, а бизнес-правила регулируют деятельность предприятия.  

• Бизнес-правила могут быть внешними или внутренними, но влияют на НФТ.  

• Бизнес-правила могут диктоваться законодательством или внутренними регламентами.  

• НФТ могут быть следствием новых бизнес-правил, таких как хранение данных.  

• Бизнес-правила влияют на пиковые нагрузки и другие аспекты системы.  

• Бизнес-правила могут быть внутренними или внешними, но влияют на НФТ.  

• Примеры: доставка еды 24/7, обработка обращений клиентов.  

• Бизнес-правила могут диктоваться рынком или быть частью конкурентного преимущества.  

• Бизнес-правила могут быть сложно уловимыми и эфемерными.  

• Требования заинтересованных сторон могут включать бизнес-правила, но не всегда явно их называют.  

• Примеры: время доставки, упаковка товара.  

• НФТ привязаны к продукту или системе, а бизнес-правила могут существовать без привязки.  

• НФТ и бизнес-правила — разные категории требований.  

• НФТ и переходные требования — разные категории.  

• Переходные требования имеют короткий срок жизни и связаны с организационно-техническими мероприятиями.  

• Примеры переходных требований: импорт данных, настройка справочников, обучение.  

• НФТ не всегда являются ограничениями.  

• Ограничения могут быть связаны с НФТ, но не наоборот.  

• Бизнес-правила фиксируются на этапе предварительного исследования.  

• Переходные требования фиксируются в проектной документации.  

• НФТ фиксируются в технических заданиях и проектной документации.  

• Атрибуты качества — это воплощенные НФТ.  

• Важно учитывать НФТ на ранних стадиях разработки системы.  

• Атрибуты качества должны храниться централизованно для легкого доступа и проверки.  

• НФТ можно классифицировать по различным параметрам качества.  

• Существуют стандарты и модели для классификации НФТ.  

• Пример классификации: разделение НФТ на четыре категории: производительность, удобство использования, дизайн и документация.  

• Способность системы отвечать на сигналы в заданное время.  

• Важность дифференциации функций по степени важности и критичности.  

• Разделение требований к производительности по категориям.  

• Учет условий работы пользователей и их восприятия.  

• Важность взаимодействия системного аналитика, бизнес-аналитика и дизайнера.  

• Влияние интерфейса на здоровье пользователей.  

• Ролевые модели доступов к данным и функциям.  

• Важность координации с техническими специалистами.  

• Прокачка навыков в области безопасности.  

• Возможность наращивания мощности системы.  

• Учет увеличения количества пользователей и запросов.  

• Быстрое подключение новых ресурсов и пределы масштабируемости.  

• Время восстановления и безотказная работа системы.  

• Совместимость с общесистемным и сетевым ПО.  

• Интеграция с внешними сервисами и поддержка совместимости.  

• Грамотное подведение данных о доступности системы.  

• Важность коммуникации и осмысленного подхода.  

• Особенности хранения данных и специфические требования.  

• Различие между нефункциональными требованиями и требованиями к видам обеспечения.  

• Требования к аппаратному, программному обеспечению и безопасности.  

• Требования, направленные вовне системы, и их влияние на окружение.  

• Концептуальная целостность важна для соответствия UI-киту и дизайн-системе.  

• Ремонтопригодность зависит от архитектуры системы и возможности внесения изменений.  

• Сложность системы может тормозить развитие бизнес-функций.  

• Повторное использование компонентов и технологий важно для мультипродуктовых компаний.  

• Документация и автотесты помогают ускорить тестирование и поддержку системы.  

• Требования к скорости тестирования важны для своевременного выпуска функциональности.  

• Игра состоит из нескольких тактов, каждый из которых представляет отдельную ситуацию.  

• Участники могут писать свои версии в чате трансляции.  

• Вопросы и ответы обсуждаются в режиме реального времени.  

• Автоматизация формы увеличила скорость обработки, но изменила интерфейс.  

• Удобство использования и время заполнения стали ключевыми требованиями.  

• Увеличение ошибок и замедление работы операционистов стали последствиями.  

• Недовольство пользователей может привести к саботажу и нагрузке на поддержку.  

• Примеры из практики показывают, что неудобные формы могут привести к массовым увольнениям и убыткам.  

• Репутационные риски и снижение числа клиентов также могут быть последствиями.  

• Ошибки операционистки могут быть привычкой.  

• Для избежания ошибок рекомендуется проводить анализ и наблюдение за работой операционистов.  

• Важно учитывать пользовательские привычки и подходы.  

• Доступ к отчету не был ограничен, что могло привести к блокировке функциональности.  

• Служба безопасности могла заинтересоваться системой и потребовать переделки.  

• Возможные последствия: утечка данных, нарушение коммерческой тайны, судебные разбирательства.  

• Проблемы с коммуникациями могут привести к задержкам и штрафам.  

• Важно подключать службу безопасности на раннем этапе для предотвращения проблем.  

• Требования к безопасности должны быть проговорены до начала разработки.  

• Отчет был большим и высоконагруженным, но требования к производительности не были уточнены.  

• Возможные последствия: задержки в производстве, конфликты внутри команды, штрафы.  

• Важно прорабатывать юзер стори и учитывать нагрузку на систему.  

• Аналитик подключился к проекту в середине, когда команда уже пыталась ускорить процесс.  

• Выяснилось, что отчет не нужен мгновенно, и процесс был выстроен с учетом возможных сбоев.  

• Непроработанные требования привели к необходимости переделывать работу.  

• Не стоит задавать универсальные требования ко всей системе.  

• Требования нужно прорабатывать для конкретных элементов системы.  

• Пример с налоговыми отчетами, которые можно запускать в ночное время.  

• Уточнение требований по хранению данных транспортных накладных.  

• Проработка ежегодного прироста данных и бюджета на хранение.  

• Использование более дешевых носителей для хранения данных.  

• Нефункциональные требования влияют на технологическую архитектуру.  

• Пример выбора более дешевого носителя для хранения данных.  

• Важность взаимодействия аналитика и архитектора на этапе сбора требований.  

• Задача: создать небольшую систему для заметок, расходов и доходов.  

• Проблема: интеграция с другими системами компании.  

• Решение: ресеч дизайн для оптимального взаимодействия.  

• Планировали небольшую систему, но она оказалась большой.  

• Много пользователей и данных, что привело к проблемам с интеграцией.  

• Версия: система не соответствовала ожиданиям по количеству пользователей.  

• Проблема: совместимость и функциональные требования.  

• Версия: интеграция с критичными сервисами для личных финансов.  

• Вопрос: необходимость использования сторонних сервисов.  

• История: система была тестовой, а не масштабируемой.  

• Проблема: отсутствие требований к масштабируемости и совместимости.  

• Вопрос: концептуальная целостность и ремонтопригодность.  

• Задача: отображение информации с фитнес-часов в мобильном приложении.  

• Проблема: жалобы пользователей после релиза.  

• Версия: проблемы с дизайном и концептуальной целостностью.  

• Тестирование: правильное, но на малоподвижных пользователях.  

• Проблема: не учли пользователей с большим количеством шагов.  

• Версия: неправильная фокус-группа и тестирование.  

• Проблема: медленное обновление данных и технические мощности устройств.  

• Версия: изменения в продукте и процессе разработки.  

• Вопрос: как изменились процессы разработки?  

• Высокая частота обновлений привела к повышенному потреблению заряда аккумулятора.  

• Пользователи с телефонами не всех моделей могли поддерживать приложение.  

• Данные долго обрабатывались, особенно при беге, когда телефон далеко.  

• Вопрос о хранении данных и безопасности.  

• Проблема оказалась в производительности и окружении, в котором запускалась форма.  

• Добавление виджета привело к выкатыванию функциональности из имеющихся слеев и атрибутов качества.  

• Приложение для школы с возможностью автоматизации уроков.  

• Жалобы на совместимость с другим ПО и оборудованием.  

• Проблемы с оборудованием в школах привели к провалу проекта.  

• Команда закупила проекторы и организовала отдельное помещение для тестирования.  

• Внесены изменения в дизайн системы для работы на плохом оборудовании.  

• Важно определить путь работы: разработка новой системы или доработка существующей.  

• При разработке новой системы нужно учитывать все возможные параметры и рантаймволите.  

• При доработке существующей системы важно не нарушать действующие НФТ и иметь внятные спецификации.  

• НФТ рождаются на этапе проработки уточненных требований.  

• Аналитик должен взаимодействовать с архитекторами и специалистами для описания НФТ.  

• Взаимодействие должно быть направлено на создание НФТ, а не просто на их создание.  

• Аналитик не может проработать все нефункциональные требования самостоятельно.  

• Он должен инициировать процесс и привлекать специалистов для качественной проработки НФТ.  

• Менеджер может помочь формализацией процесса для снижения рисков.  

• Введение контрольных точек для фиксации непроработанных областей.  

• Использование шаблонов артефактов для учета НФТ.  

• Важно понимать последствия отсутствия НФТ и их влияние на проект.  

• Вопросы должны быть конкретными и понятными для заказчика.  

• Чек-лист для вопросов поможет избежать непонимания.  

• Разделение зон ответственности между аналитиком, архитектором и другими специалистами.  

• Дизайнеры и специалисты службы поддержки могут быть полезны для удобства использования.  

• НФТ должны проверяться на оправданность, реализуемость и стоимость реализации.  

• Важно избегать ненужных НФТ и проверять их на полноту.  

• Использование Confluence и Sparx для управления требованиями.  

• Возможность использования Excel для трассировки и ведения требований.  

• Российские аналоги Confluence, такие как Яндекс Вики, и система Дэф Про.  

• Продукт "К мастеру" позволяет строить матрицы и работать со списками.  

• Подходит для базовых кейсов, но не для корпоративного уровня.  

• Рекомендуется для интереса, но не как корпоративное решение.  

• Важно регламентировать процесс и формализовать базовые пункты.  

• Аналитик должен предъявлять требования, которые команда должна реализовывать.  

• Без прописанного процесса и ответственности добиться чего-то сложно.  

• Контейнеризация упрощает работу на уровне технологической архитектуры.  

• НФТ прорастают из контекста и требуют проработки.  

• Контейнеризация не снижает важность НФТ.  

• Бизнес-правила могут существовать без автоматизации.  

• Чек-листы помогают задавать правильные вопросы для формулировки НФТ.  

• Чек-лист будет в отдельном видео.  

• Использование языков программирования и готовых модулей — это ограничения.  

• Форс-мажоры нужно учитывать, но не стоит закладывать больше, чем можно переварить.  

• Важно системно работать и учитывать предсказуемые нагрузки.  

• Заказчик должен обеспечить специалиста для согласования НФТ.  

• Если заказчик не обладает достаточной экспертизой, нужен эксперт для подтверждения технической адекватности.  

• Автоматизация помогает уменьшить количество заказчиков, не понимающих НФТ.  

• Отчетность включает как функциональные, так и нефункциональные требования.  

• Функциональные требования определяют, что система должна делать, например, выдавать отчет.  

• Нефункциональные требования касаются производительности и безопасности, например, формирование отчета за три секунды.  

• Требования к интеграции могут быть как функциональными, так и нефункциональными.  

• Интеграция включает производительность, безопасность и технологии.  

• Функциональные требования определяют, для чего нужна интеграция, например, передача данных между системами.  

• Рекомендуется посетить курс по системному анализу для более глубокого понимания требований.  

• Опыт и выступления на конференциях помогают лучше понять, как решать задачи.  

• Книги по социологии и маркетинговым исследованиям могут быть полезны для аналитиков.  

• Пример успешного кейса: доклад о разработке приложения для оплаты в самолете.  

• Доклад показывает, как разрабатывались и тестировались решения, включая итерации и исправления.  

• Важно видеть процесс разработки и проектирования, чтобы лучше понимать требования.  

• Обсуждение продолжается в чате, но спор о том, что является функциональным требованием, а что нет, завершен.  

• Благодарность участникам вебинара и приглашение на канал для продолжения обсуждения.  

• Завершение вебинара с надеждой на будущие встречи и интересные события.