Виды требований к ПО. Подборка видео

Мы всё чаще и чаще потребляем контент в форме видео, поэтому я собрал подборку полезных видеоматериалов на тему требований к программному обеспечению.

Вся подборка построена на основе размещённых на YouTube видеороликов. Это вебинары, записи лекций и выступлений на профильных конференциях. Подборка разделена на несколько групп, при этом первая группа является вводной, а каждая из последующих посвящена одному конкретному виду требований. За основу была взята классификация по BABOK, но цели строго следовать ей не было.

Очерёдность докладов в каждом разделе выстроена по принципу увеличения усложнения и углубления в вопрос. Дополнительно к каждому видео сформулировано краткое описание содержания. Поэтому в зависимости от своей потребности вы сможете регулировать своё погружение в вопрос.

1.1. Виды требований к ПО и способы их документирования

Доклад для первого и лёгкого знакомства с темой (для новичков). На сквозном примере работы пиццерии рассматриваются основные виды требований к ПО (бизнес-требования, требования заинтересованных сторон, функциональные, нефункциональные, переходные) и способы их документирования. Во второй половине видео вскользь затрагиваются и иные связанные вопросы, как то: пользовательские истории, критерии приёмки, разработка макетов (wireframe).

1.2. Заметки по работе с требованиями | Давайте разбираться

В начале данного небольшого видео частично повторяются мысли из предыдущего, но изложение более ритмичное и с уклоном на работу с требованиями. Начиная с 6 минуты излагаются критерии хороших требований (полнота, ясность, корректность, непротиворечивость пр.) и даются полезные советы по работе с требованиями.

1.3. Требования: хорошие и плохие

На примере учебного реестра требований заинтересованных сторон разбираются типичные упущения, допускаемые при работе с требованиями (упущен стейкхолдер и его требования, использование терминов без пояснений, не раскрыты стадии жизненного цикла сущности и пр.). По мере разбора эти моменты устраняются и учебный документ с требованиями итеративно улучшается, в частности в документе появляются переходные требования. С 30 минуты доклада озвучиваются вопросы повышения качества требований в разрезе трёх аспектов и по ним предлагаются чек-листы.

1.4. Как разработать и описать требования к ПО

Данный доклад в целом решает те же задачи, что и первый доклад в данной группе, однако это уже более методичный и глубокий материал. Повествование строится вокруг сквозного примера (внедрение системы электронного документооборота): от первого контакта с заказчиком и выявления его реальной потребности до приёмки результата. Разбираются такие инструменты аналитика, как контекстная диаграмма, диаграмма вариантов использования UML, матрица действий, диаграмма процесса IDEF0, диаграмма состояний UML и пр., при этом разбор идёт с акцентом на получаемую от этих инструментов ценность и в привязке к примеру. С 45 минуты разбирается пример шаблона документа требований, а с 51 минуты разбирается множество вопросов от зрителей.

1.5. Управление требованиями по ISO/IEEE-29148: обзор действующего стандарта

Разбирается, из чего состоит стандарт ISO/IEC/IEEE-29148:2018, какие вопросы покрывает, чем он выгодно отличается от других стандартов (в том числе от ГОСТ 34), почему его можно считать ёмким сборником хороших практик, а не подробным учебником. В ходе обзора стандарта автор последовательно проходит по документу, проговаривая содержание и давая свои пояснения, что позволяет улучшить понимание контекста и материала. В дополнение к стандарту автор советует обратиться к учебникам International Requirements Engineering Board (IREB). Важно: текст стандарта на английском языке, а в видео местами есть проблемы со звуком.

2.1. Бизнес правила - это не требования! Нужно ли с ними работать

Максимально полное освящение бизнес-правил. В первой половине доклада излагается, что такое БП, каким критериям они должны удовлетворять, почему это не требования к ПО, зачем аналитику на них надо тратить своё время, как они влияют на появление новых требований и как лучше организовать связь между вариантами использования и БП. Также рассматриваются риски, связанные с недостаточной работой с бизнес-правилами. Начиная со времени 1:14 освещаются особенности работы с БП, организованными в виде таблицы решений, а с 1:24 — разбираются две классификации БП (по Карлу Вигерсу и Рональду Россу). Для знакомства со сводом знаний RuleSpeak — метка 1:44, ответы на вопросы зрителей — 1:57.

Из любопытного: согласно приведённым критериям и ответу на вопрос (см. 2:03), требования законодательства не являются бизнес-правилами, т.к. не находятся под юрисдикцией бизнеса. Меж тем у К. Вигерса иное мнение: регуляторные требования и отраслевые стандарты рассматриваются им как бизнес-правила внутри категории "ограничения".

2.2. Делаем качественные требования с помощью таблиц принятия решений

На примере кейса представлена работа с бизнес-правилами, имеющими сложную структуру и логику. Объясняется, почему эффективнее будет построить такую работу с помощью таблицы решений. Также даётся базовое представление о нотации Decision Model and Notation (DMN) и реализации в ней таблиц решений.

2.3. Расширение нотации BPMN: использование совместно с DMN (управл.решения) и CMMN (кейс-менеджмент)

Доклад начинается с экскурса в историю возникновения процессного подхода, затрагиваются границы его применимости. Далее на примере кейса рассматриваются принципы работы с нотациями DMN и CMMN, которые позволяют описать соответственно управленческие решения и недетерминированные решения, принимаемые пользователем по собственному усмотрению пользователя.

3.1. Зачем нужны бизнес требования?

В видео за неполные 6 минут даётся определение БТ, объясняется их важность и место, занимаемое в иерархии требований.

3.2. Четыре друга бизнес-требований

Всë в том же формате пятиминутки рассказывается о сопутствующих бизнес-требованиям понятиях: доменная модель, глоссарий, бизнес-ограничения, бизнес-правила и метрики.

4.1. Пользовательские требования

Лекционный материал, правда не самый гладкий в изложении. Даются общие сведения, а далее разбираются подходы к представлению пользовательских требований в форме вариантов использования (Use Case) и пользовательских историй (Use Story), их сходства и различия. При рассмотрении историй также затрагивается вопрос создания критериев приëмки (Acceptance Criteria). Начиная с 48 минуты затрагиваются родственные темы (CRUD-анализ, CRUDLSHAX, концепция Use Case 2.0 А. Якобсона, диаграммы вариантов использования UML), после чего разбираются более детальные примеры.

4.2. Идеальный USE CASE: как описать сценарий, чтобы его не вернули на доработку

Рассматриваются только варианты использования: что это, зачем, 10 типов ошибок, которые допускают начинающие аналитики при написании вариантов использования.

4.3. User Stories Full Study: внутри и снаружи

Подробно разбираются пользовательские истории: из чего состоят, как их лучше создавать, почему они должны удовлетворять критериям INVEST, как соотносятся с критериями приёмки. INVEST разбирается достаточно подробно, в ходе этого даётся представление о других связанных подходах (например, о модели IRACIS и спайках/spike), что позволяет их взять на заметку для дальнейшего изучения. С 19 минуты затрагиваются вопросы представления НФТ и требований к бэк-энду в форме историй. Начиная с 24 минуты доклад уходит больше в тему работы по Agile, для базового знакомства это может быть избыточным и можно пропустить, перейдя на 31 минуту на секцию вопросов и ответов.

4.4. Разбивка пользовательских историй

Рассматривается, что такое пользовательская история, в каких случаях еë стоит дробить на части, какие есть подходы к дроблению, когда следует остановить дробление, а также в каких случаях дробить истории не рекомендуется. Для большей пользы данное видео лучше смотреть после изучения основ работы с фреймворком User Story.

4.5. User & Job story в разработке продуктов

Короткое видео, в котором с точки зрения дизайнера рассматривается работа с постановками задач в соответствии с фреймворками User Story и Job Story. Автор знакомит с этими форматами, сравнивает их и объясняет, для каких ситуаций стоит предпочесть Job Story, а в каких ситуациях, по мнению автора, вовсе не стоит пытаться уместить постановку в рамки историй. Стоит отметить, что несмотря на то, что Job Story пока ещё не пользуется большой популярностью среди команд разработки и продакт-менеджеров, знакомство с ним позволяет посмотреть на задачи под другим ракурсом.

4.6. User Story и Job Story: в чем разница и когда они нужны?

В данном видео разбирается работа с Job Story на более глубоком уровне, чем в предыдущем. На примерах показывается, что в ряде случаев анализ с позиции персоны/роли непоказателен и сужает обзор, и в таких случаях следует держать фокус на проблемной ситуации (контексте) и решаемой клиентами задаче. В докладе много внимания уделено проведению интервью клиентов и интерпретации полученных ответов по фреймворку Jobs To Be Done (JTBD).

Можно рекомендовать данное видео, если есть желание копнуть глубже в сторону маркетинга и управления продуктом. Также есть интересная статья на эту же тему: ссылка.

4.7. Пользовательские требования — ключ к успешному продукту

Излагается точка зрения, что для многих типов проектов не стоит с заказчиками согласовывать бизнес-требования и системные (под последними автор понимает требования, которые обычно относят к области ФТ и НФТ), а оптимальным будет согласовывать именно пользовательские (требования заинтересованных сторон) с той или иной детализацией. В качестве форматов для требований рассматриваются пользовательские истории (User Story) и варианты использования (Use Case). Также высказывается мысль, что сегодня ChatGPT способен неплохо генерировать функциональные требования, поэтому если придерживаться излагаемых в докладе принципов, никакой ChatGPT аналитика не заменит.

Лекционный материал, является продолжением лекции о пользовательских требованиях (см. выше). Первые 16 минут посвящены функциональным требованиям: что это, их место в иерархии требований по классификации К. Вигерса, связь ФТ с пользовательскими требованиями. В этом же видео начиная с 17 минуты идёт изложение материала по нефункциональным требованиям, с 47 — по бизнес-правилам (здесь они рассматриваются как часть НФТ) и иным связанным вопросам (например, классификация НФТ по FURPS+ и RUP). Но я бы предложил для изучения данных тем отдать предпочтение отдельным материалам из соответствующих групп либо скомбинировать с ними, чтобы, не упустить делали.

6.1. Нефункциональные требования. Как не упустить качество продукта

Хороший доклад для погружения в проблематику. Здесь в доступной форме рассказывается о сложностях работы с НФТ сквозь призму опыта бизнес-аналитика, о возможных источниках выявления НФТ, а также при разборе сквозного учебного примера приводится ряд конкретных формулировок для наиболее популярных видов НФТ (примеры, как надо и как не надо формулировать требования). Из всех категорий НФТ рассматриваются в основном атрибуты качества.

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

Широкий обзор видов НФТ и важности учёта оных. Также разбирается несколько заблуждений относительно того, что относится к НФТ. С 48 минуты в форме игры разбирается 7 кейсов из практики вида: НФТ не были предъявлены, и к чему это привело. Вкупе с обсуждением спикеров это позволяет перенять опыт, не проживая его внутри рассмотренных проектов.

6.3. Разбираемся с нефункциональными требованиями на примерах

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

6.4. Как задавать нефункциональные требования к качеству ПО в цифрах

Рассмотрение способа, как можно задавать требования к качеству. В докладе предлагается авторский подход к заданию НФТ в зависимости от класса системы. Автор исходит из того, что для каждого класса систем существует типовой набор пар: <показатель/НФТ; уровень качества>, который на основе эмпирических данных превращается уже в конкретные цифры (проценты, секунды, TPS и пр.). Отдельное достоинство доклада в том, что в нём освещается такая редко упоминаемая категория, как атрибуты качества использования (см. Human Factors Requirements в ISO/IEC/IEEE-29148:2018): скорость работы, точность, утомляемость и пр. Статья в развитие темы: ссылка.

6.5. Нефункциональные требования: как их определять

Приводится большой обзор существующих моделей классификации требований с упором на качество ПО (ГОСТ 34, ISO 9126, FURPS+ и пр.). Если удалось ознакомиться с представленными выше материалами, то можно начать просмотр видео с 31 минуты, т.к. с этого момента начинается изложение вопросов, связанных с заданием значений атрибутов качества (как определить допустимые границы, от чего может зависеть, с кем их стоит обсудить, профиль качества для системы vs модуля/подсистемы и пр.).

6.6. Платежи на борту самолёта

Разбор кейса компании "ЮMoney" об осуществлении платежей на борту самолёта. Лёгкое видео, где в динамике показывается развитие казалось бы уже разработанной архитектурной концепции в ответ на введение в рассмотрение того или иного аспекта качества (сохранность данных, безопасность и пр.).

7.1. Чек-лист для описания требований к интеграции

Видео посвящено требования к интеграциям.

Вначале рассматриваются 3 принципиальные этапа интеграционного анализа (концепция, проектирование, техническая детализация). После этого доклад выстраивается вокруг вопросов, на которые стоит отметить при работе над интеграционным проектом (получается чек-лист). Это: тип взаимодействия, расписание запуска, кто инициирует, где забирать данные, как интерпретировать пустое содержание, через какое время повторить попытку при неудаче, сколько есть попыток и пр. В ходе изложения основной упор делается на файловом обмене и веб-сервисах, однако многое применимо и к иным способам взаимодействия. Представленная информация будет также актуальной тем, кто занимается миграцией данных.

7.2. Проектирование пользовательских интерфейсов

Видео посвящено требования к пользовательскому интерфейсу (UI).

UI рассматривается в контексте удовлетворения потребностей пользователей со стороны ПО, причём по аналогии с пирамидой Маслоу: вначале закрывается потребность в функциональности (ФТ), потом в атрибутах качества (НФТ), а далее на первый план выходят ощущения и восприятие интерфейса (UX/UI). Вся лекция строится вокруг этой идеи, в частности, рассматривается метод персон (персонажей, Personas) для определения подходящих интерфейсов ПО для разных групп пользователей. С 23 минуты рассматриваются разные подходы к дизайну (human-centered, activity-centered, data-driven), типы информационных структур интерфейса и слегка затрагивается тема Customer Journey Map (CJM). С 58 минуты рассматриваются подходы к прототипированию интерфейсов (storyboarding, бумажные прототипы, wireframe/макеты, mockup и др.) и вопросы исследования продукта (A/B-тестирование, Usability-тестирование и др.).