Фундамент — литература

• (PDF) Разработка требований к ПО (Карл Вигерс, 2014). запасная ссылка.
  Фундаментальный труд, очень объёмный, читать выборочно. Периодически продаётся в бумаге, я покупал издание 2018 года.
• (PDF) Сжатая выборка основных мыслей из книги 2016 года издания "Принципы работы с требованиями к программному обеспечению. Унифицированный подход" Дина Леффингуэлла
• (PDF) Разработка и управление требованиями. Практическое руководство пользователя. (Telelogic, 2005). запасная ссылка.
• (PDF) Современные методы описания функциональных требований к системам. (Алистер Коберн, 2002). Советую издание посвежее. В бумаге поймать трудно.

Формальные международные стандарты

• (PDF) ISO 29148-2018. Systems and software engineering — Life cycle processes — Requirements engineering article
.
• (PDF) BABOK version 3 (2015)
• "Мякотка" из BABOK в веб-формате. Всё удобно, но отсутствуют схемы и имеются опечатки.

Статьи

• Про страдательный залог в технической документации (2023). С примерами, о том, что страдательный залог плох тем, что не всегда понятно кто/что должен выполнять то или иное действие.
• Единственный контекст потребителя (Тихомиров Сергей, 2020). Отличная статья о формировании гипотез поведения/проблемы/мотивации/блокеров для определении контекста, о популярных моделях, о составлении правильных вопросов для интервью, о формулировании и маппинге ценностных предложений на цели заказчика.
• A collection of practices and patterns to support software evolution, modernization, maintenance, migration and improvement of software systems. Своего рода свод знаний о паттернах анализа в контексте модернизации систем.
• Проектирование интеграции с веб-сервисом

Практика формирования требований в IT-проектах от А до Я.

• Часть 1. Вводная
• Часть 2. Цели и Потребности
• Часть 3. Функции системы и Границы проекта
• Часть 4. Бизнес процессы, автоматизируемые системой
• Часть 5. Сущности предметной области и немного о стратегиях
• Часть 6. Поведение системы. Совершенстваоние требований
• Часть 7. Передача требований в производство. Заключение

Пара определений

• Транзакция = способ группировки операций чтения / записи в одну логическую единицу, в рамках которой эти операции либо выполняются целиком либо не выполняются с возможностями прерывания и отката.

Помимо негласного стандарта в виде продуктов от Atlassian.

• Для составления BPMN и UML:
  • (бесплатное, требуется регистрация) stormbpmn.com = онлайн-сервис для описания бизнес-процессов и инструкций в BPMN
  • (бесплатное, требуется регистрация) diagrams.net (бывший draw.io) = онлайн-сервис для составления диаграмм UML, BPMN, Archimate и др.;
    Можно скачать Desktop-приложения для
  • (условно-бесплатное) Modelio Open Source = десктоп-приложение UML, BPMN, ArchiMate, SysML. Есть платные плагины и модули.
    Видеообзор работы в Modelio (15 минут)
• Для работы с Требованиями (разработка, управление, трассировка):
  • (очень платное) IBM Rational DOORS
  • (платное)(есть trial на 14 дней) Cradle
  • (платное) DevProm Requirements. Один из функциональных блоков программного продукта Devprom ALM
  • (платный) плагин RMsis для Atlassian JIRA
  • (платный) плагин R4J для Atlassian JIRA
• Для работы и с Требованиями и с Архитектурой:
  • (платный) Enterprise Architect (платный, есть trial на 30 дней) ( и могут установить EA под WINE). В высшей степени могущественный инструмент.
  • (платное) SAP Power Designer.
• Для создания прототипов интерфейсов:
  • (платное)(есть Starter — бесплатный режим) Figma
  • (платное)(есть free trial на 30 дней) Axure RP
• Для совместной онлайн-работы с коллегами:
  • (условно-бесплатное, требуется регистрация) Lucidchart = online collaborative diagrams. Есть фигуры из нотаций UML и BPMN.
  • (условно-бесплатное, требуется регистрация) Miro = online collaboration whiteboard. Хорош для brainstorm, быстрых набросков.
    Можно скачать Desktop- и мобильные приложения для различных платформ

Бизнес-аналитик

Основные решаемые задачи:

1. определение ключевых заинтересованных лиц проекта (Stakeholders), ожидания которых должны быть удовлетворены;
2. (совместно с Заказчиком) определение Бизнес-требований;
3. определение Бизнес-ограничений, Требований государственных и международных регуляторов
4. (совместно с Ключевым пользователем) выявление Пользовательских требований;
5. (совместно с менеджером проекта) разработка концепции Проекта
6. планирование работ с требованиями в рамках проекта (анализ, верификация, проверка качества)
7. документирование Бизнес и Пользовательских требований
8. Ведение репозитория требований
9. (при необходимости) реверс-инжиниринг бизнес-процессов.

Основные создаваемые артефакты

• описание моделей бизнес-процессов As Is
• описание моделей бизнес-процессов To Be
• описание Бизнес- и Пользовательских требований
• обновления репозитория Требований
• создание Vision (Концепции проекта) / Рамок проекта / Соглашения о границах проекта

Системный аналитик

Специалист, который на основе Бизнес- и Пользовательских требований проектирует техническое решение и разрабатывает функциональные (какие функции должны быть релизованы в разрабатываемом ПО) и нефункциональные требования.

Основные решаемые задачи

1. (совместно с Системным архитектором) определение границ Системы (разрабатываемого ПО) и контекста её работы
2. анализ Бизнес-требований и Пользовательских требований, определение Ограничений
3. участие в разработке Проектного решения
4. декомпозиция Бизнес-сценариев на Системные сценарии
5. создание сценариев использования (use case)
6. разработка Функциональных и неФункциональных требований, реализующих Системные сценарии
7. разработка Пользовательских требований в границах Системы
8. документирование Требований
9. Ведение репозитория требований

Основные создаваемые артефакты

• Техническое задание / Спецификация на изменение ПО (SRS)
• описание Проектного решения
• описание Пользовательских требований уровня Системы
• обновления репозитория Требований

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

Портрет аналитика

• (опционально) возможные занимаемые ранее позиции работы Бизнес-аналитиком / Системным аналитиком / UX-проектировщиком / Системным архитектором
• Коммуникативные навыки:
  • Умение устанавливать контакт с незнакомыми людьми;
  • Умение слушать собеседника и держать в голове цель переговоров;
  • Навыки ведения переговоров с бизнес-заказчиком ИТ-доработок;
  • Умение аргументированно отстаивать свою позицию;
  • (опционально) навыки ведения презентаций.
• Системный анализ. Навыки определения контекста системы, анализа предметной области, структурной декомпозиции объектов предметной области.
• иметь представление о жизненном цикле ПО. Ориентация в ключевых методологиях разработки: Waterfall, RUP, Agile, Kanban, для гос. заказчиков — ГОСТ 19 и 34;
• навыки разработки моделей предметной области в нотациях Archimate, BPMN, UML.
• знание языка UML, умение разрабатывать диаграммы предметной области (use cases, activity, state, sequence diagrams)
• навыки работы с БД, знание SQL (PL-SQL), из нереляционных — MongoDB (негласный стандарт)
• знание типов интеграции IT-систем, конкретных технологий в этих типах, наиболее известных протоколов и форматов передачи данных. Навыки разработки технических заданий на интеграцию ИТ-систем. Желательно знакомство с понятием сервис-ориентированной архитектуры.
• владение векторными графическими редакторами типа Archi, Visio, diagrams.net, gliffy, Modelio;
• (опционально) навыки работы с системами управления требованиями (Rational RequisitePro, DOORS, Jira+ Confluence)
• (опционально) владение инструментами проектирования/моделирования, самое востребованное на рынке: Archi, Sparx Enterprise Architect и Rational Rose;

Кратко.

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

Подробно.

У RUP и у Стандарта управления проектами (PMI, PMBoK) предусмотрено множество документов, которые призваны помочь сделать проект/продукт, но это не значит что в первом случае надо обложится всевозможными UML-диаграммами, а во втором — планами на каждый возможный чих.

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

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

Критерии приёмки:

1. соответствие того, что выдает продукт, тому что записано в качестве выхода для системного сценария использования.
2. отработка всех системных сценариев в симфонии (целостность выполнения бизнес-сценария).

С Заказчиком и Бизнес-Пользователями мы проверяем, что система выполняет нормальный вариант эксплуатации предусмотренный указанными выше системными сценариями и поддерживает новый бизнес-процесс (бизнес-сценарий).

Системные сценарии не описывают, что должно происходить при "ненормальной" эксплуатации, ничего не говорят о тестах эмулирующих эксплуатацию под промышленной нагрузкой, регрессионных тестах.
Поэтому создание полной тестовой документации, включая план тестирования, я считаю факультативной задачей. Если система относится к критически важным для бизнеса или есть экономика которая оправдывает высокое качество и покрытие тестированием, то тогда имеет смысл расширять документацию.

Бизнес-процесс = совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого Продукта/Услуги.
В качестве графического описания деятельности применяются нотации (блок-схемы) бизнес-процессов.

Виды Бизнес-процессов:

• Управляющие — управляют функционированием системы.
  Примеры: Корпоративное управление и Стратегический менеджмент.
• Операционные — составляют основной бизнес компании и создают основной поток доходов.
  Примеры: Снабжение, Производство, Маркетинг, Продажи и Взыскание долгов.
• Поддерживающие — обслуживают основной бизнес.
  Примеры: Бухгалтерский учет, Подбор персонала, Техническая поддержка, административно-хозяйственный отдел.

Базовые процессы в компаниях

1. Процесс обеспечения доступности товара.
   Результат: появление Продукта, обеспечение возможности предоставления Услуги.
2. Процесс по организации сбытовой деятельности.
   Результат: Продукт уходит Клиенту, оказание Услуги.
3. Процесс по управлению продуктами.
   Результат: выпуск Продуктов и оказание Услуг, которые востребованы.
4. Процесс по управлению качеством.
   Результат: отсутствие возврата Продукта от Клиента, жалоб на качество Услуг.

Источники информации о БП в компании

Часто приходится сталкиваться с тем, что бизнес-процессы в компании не описаны, либо описаны плохо, либо описание давно не актуально, неизвестно как конкретно и какие ИС задействованы в них и т.д.
Тогда аналитику для обретения понимания что происходит, кто и что задействовано — приходится заниматься обратной инженерией (реверс-инжиниринг, reverse engineering) бизнес-процессов.
Для этого необходимо обращаться к:

• регламентам
• должностным инструкциям
• корпоративным Базам Знаний
• людям — непосредственным исполнителям Ролей в БП

Разработка бизнес-процессов

В очень общем виде:

1. Создание любого процесса начинается с указания цели, которую необходимо достигнуть этим процессом.
2. Затем должно быть что получаем в него на вход, чего ожидаем на выходе.
3. Только затем определяем исполнителей и их действия со взаимосвязями.
4. Важно посчитать себестоимость исполнения экземпляра процесса.

Анализ бизнес-процессов

1. убедиться, что работа не дублируется
2. убедиться, что место работы и место принятия решения единственные (т.е. заявка и решение не курсируют по всему зданию, и чтобы купить стул вахтеру не нужна подпись гендира), и одинаковые задачи решаются одинаковым способом
3. убедиться, что за контроль и исполнение отвечают разные люди, не связанные друг с другом
4. убедиться, что за каждое движение и актив хоть кто-то отвечает, чтобы при успехе самый наглый не говорил "Я!", а при провале "Они!"
5. обеспечить полную загрузку персонала, лишних сократить или отправить расширять бутылочное горлышко
6. разобраться, какие процессы создают ценность, а какие ни денег не приносят, ни другим отделам не помогают, а "так исторически повелось"
7. разобраться, какие процессы (например, часть информационных) можно переложить на автоматические системы

Оптимизация бизнес-процессов

1. Минимизация участников БП
2. Типизация БП
3. Упрощение БП
4. Сокращение времени протекания БП
5. Обеспечение параллельности БП
6. Исключение излишнего контроля в БП
7. Минимизация участия руководства в БП
8. Сокращение стоимости БП
9. Реинжиниринг БП (фундаментальная реорганизация с целью повышения эффективности)

Требование (requirement) = утверждение (statement), которое выражает нужды (needs) и связанные с ними обстоятельства (conditions) и ограничения (constraints).

Атрибуты требования

Идентификатор, Имя, Требование, Приоритет, Причина приоритета, Статус, Источник и т.д.

Модель зрелости требований (RMM, requirements maturity model)

0. Отсутствуют (Unwritten / Chaos)
   • Не документируются
   • Разработка решения идёт на основе предположений и интерпретаций
   • Нет инструкций, процессов
   • Нет общего однозначного опнимания о том, как должно работать решение
1. Пишутся (Written)
   • хранятся в востанавливаемом хранилище
   • по-прежнему требования понимаются по-разному
   • отражают текущее понимание решения
   • есть Knowledge base
2. Организованы (Organized)
   • ведутся в едином синтаксисе, легкочитаемом и понятном формате (содержание, заголовки, шрифт)
   • отвечают критериям качества
   • внедрена ролевая модель доступа к требованиям
   • версионируются
3. Структурированы (Structured)
   • имеют продуманную структуру, написаны по шаблонам, отвечающим потребностям вашего проекта/решения
   • поделены по уровням (user, business, system,..) и типам (functional, non-functional,..)
   • имеют полезные для вас атрибуты (ID, приоритет, источник, ссылки на связанные материалы,...)
4. Прослеживаемы / трассируемы (Traced)

   Т.е. уложены в таблицы трассировки или снабжены кросс-ссылками или имеют связи в системах управления требования на связанные и зависимые требования и другие сущности (архитектурные компоненты системы, бизнес-процессы, тест-кейсы, экранные формы).

   В конечном счёте каждое бизнес- и пользовательское требование должно иметь связь с функциональным/нефункциональным. Если, например, у какого-либо бизнес-требования нет никаких связей с функциональными/нефункциональными требованиями, то, видимо, мы про него забыли и не придумали как его реализовать в продукте.

5. Интегрированы (Integrated)

   Интегрированы в систему управления требованиями или даже в код, т.е. настолько сильно сросшиеся с проектом/продуктом, что изменение требований чуть ли не сразу ведёт к изменению самого продукта.
   Очень редко попадающийся уровень.

Модель процессов по работе с Требованиями

В самом общем виде:

(скачать модель в .archimate)

скачать схему в формате diagrams.net (бывший draw.io)

Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается Продукт/Услуга (зачем вообще нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль).
Основное их содержание — бизнес-цели организации или клиента.
Результатом выявления требований на этом уровне является общее видение (vision and scope) — документ, который, как правило, представлен простым текстом и таблицами. Здесь нет детализации поведения системы и иных технических характеристик, но вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п.

Несколько простых примеров бизнес-требований:

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

Пользовательские требования (user requirements) описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя). Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объёма работ, стоимости проекта, времени разработки и т.д. Пользовательские требования оформляются в виде вариантов использования (use cases), пользовательских историй (user stories), пользовательских сценариев (user scenarios).
Несколько простых примеров пользовательских требований:

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

Бизнес-правила (business rules) описывают особенности принятых в предметной области (и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д.
Несколько простых примеров бизнес-правил:

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

Атрибуты качества (quality attributes) расширяют собой нефункциональные требования и на уровне пользовательских требований могут быть представлены в виде описания ключевых для проекта показателей качества (свойств продукта, не связанных с функциональностью, но являющихся важными для достижения целей создания продукта — производительность, масштабируемость, восстанавливаемость). Атрибутов качества очень много, но для любого проекта реально важными является лишь некоторое их подмножество.
Несколько простых примеров атрибутов качества:

• Максимальное время готовности системы к выполнению новой команды после отмены предыдущей не может превышать одну секунду.
• Внесённые в текст статьи изменения не должны быть утеряны при нарушении соединения между клиентом и сервером.
• Приложение должно поддерживать добавление произвольного количества неиероглифических языков интерфейса.

Функциональные требования (functional requirements) описывают поведение системы, т.е. её действия (вычисления, преобразования, проверки, обработку и т.д.) В контексте проектирования функциональные требования в основном влияют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: "приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции").
Несколько простых примеров функциональных требований:

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

Нефункциональные требования (non-functional requirements) описывают свойства системы (удобство использования, безопасность, надёжность, расширяемость и т.д.), которыми она должна обладать при реализации своего поведения. Здесь приводится более техническое и детальное описание атрибутов качества. В контексте проектирования нефункциональные требования в основном влияют на архитектуру системы.
Несколько простых примеров нефункциональных требований:

• При одновременной непрерывной работе с системой 1000 пользователей, минимальное время между возникновением сбоев должно быть более или равно 100 часов.
• Ни при каких условиях общий объём используемой приложением памяти не может превышать 2 ГБ.
• Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне от 5 до 15 пунктов.

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

Ограничения (limitations, constraints) представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта.
Несколько простых примеров ограничений:

• Все элементы интерфейса должны отображаться без прокрутки при разрешениях экрана от 800x600 до 1920x1080.
• Не допускается использование Flash при реализации клиентской части приложения.
• Приложение должно сохранять способность реализовывать функции с уровнем важности "критический" при отсутствии у клиента поддержки JavaScript

Требования к внешним интерфейсам (external interfaces requirements) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой.
Несколько простых примеров требований к внешним интерфейсам (внешнему взаимодействию):

• Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в формате JSON.
• Протоколирование событий должно вестись в журнале событий операционной системы.
• Соединение с почтовым сервером должно выполняться согласно RFC3207 ("SMTP over TLS").

Требования к данным (data requirements) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования.
Несколько простых примеров требований к данным:

• Все данные системы, за исключением пользовательских документов, должны храниться в БД под управлением СУБД MySQL, пользовательские документы должны храниться в БД под управлением СУБД MongoDB.
• Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную.
• Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц.

Поскольку требований может быть очень много, а их приходится не только единожды написать и согласовать между собой, но и постоянно обновлять, работу проектной команды по управлению требованиями значительно облегчают соответствующие инструментальные средства — requirements management tools.

Требования к ПО

Требование к ПО (Software Requirements) = описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи.
Спецификации этих требований (Software Requirements Specification, SRS) детализируют требования к ПО до уровня, достаточного для разработки ПО для удовлетворения этих требований.
Пример SRS (2013)

• Завершённость (completeness). Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям "это и так всем понятно".
• Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.
• Непротиворечивость, последовательность (consistency) — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
• Недвусмысленность (unambiguousness, clearness) — требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз.
• Выполнимость (feasibility) — требование должно быть технологически выполнимым и реализуемым в рамках бюджета и сроков разработки проекта.
• Обязательность, нужность (obligatoriness) и актуальность (up-to-date).
  Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но "не очень важное", для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность
• Прослеживаемость (traceability) — бывает вертикальной (vertical traceability) и горизонтальной (horizontal traceability).
  Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д.
  Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями (requirements management tool) и/или матрицы прослеживаемости (traceability matrix).
• Модифицируемость (modifiability) — характеризует простоту внесения изменений в отдельные требования и в набор требований.
  Можно говорить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а её изменение не приводит к нарушению иных описанных в этом перечне свойств.
• Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования
• Корректность (correctness) и проверяемость (verifiability). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных).
  Проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию.

Требования начинают свою жизнь на стороне заказчика.
Сбор (gathering) и выявление (elicitation) требований осуществляются с помощью следующих основных техник.

Интервью	Работа с фокусными группами	Анкетирование
Семинары и мозговой штурм	Наблюдение	Прототипирование
Анализ документов	Моделирование процессов и взаимодействий	Самостоятельное описание

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

   1. Каковы ваши основные обязанности?
   2. Что и для кого вы в основном производите?
   3. Почему существует эта проблема?
   4. Как она решается сейчас?
   5. Как заказчик(пользователь) хотел бы её решать?
   6. Кто такие пользователи?
   7. Какое у них образование?
   8. Имеют ли пользователи опыт работы с данным типом приложений?
   9. Какой, по-вашему, должна быть производительность?
   10. Существуют ли другие вопросы, которые мне следовало бы вам задать?
   Темы (направления для) вопросов для уже более-менее опытного пользователя перед разработкой нового сервиса(продукта)

   1. Каким продуктом пользуетесь сейчас, что в нём самое крутое, а что совсем не нравится
   2. Цели — для чего вам нужен такой продукт.
   3. Данные: какие данные вы хотите чтобы мы сохраняли, сколько их надо хранить, нужен ли поиск по данным, нужны ли как-то фильтровать данные, нужно ли их преобразовывать (м.б. шифрование), нужно ли куда-то их передавать.
   4. Функции: какой оптимальный use case для работы с таким продуктом, какие основные функции.
   5. Ограничения: должны ли быть какие-то особенные ограничения для пользователя или по данным (маскирование, например).
2. Работа с фокусными группами. Может выступать как вариант "расширенного интервью", где источником информации является не одно лицо, а группа лиц (как правило, представляющих собой целевую аудиторию, и/или обладающих важной для проекта информацией, и/или уполномоченных принимать важные для проекта решения).
3. Анкетирование. Этот вариант выявления требований вызывает много споров, т.к. при неверной реализации может привести к нулевому результату при объёмных затратах. В то же время при правильной организации анкетирование позволяет автоматически собрать и обработать огромное количество ответов от огромного количества респондентов. Ключевым фактором успеха является правильное составление анкеты, правильный выбор аудитории и правильное преподнесение анкеты.
4. Семинары и мозговой штурм. Семинары позволяют группе людей очень быстро обменяться информацией (и наглядно продемонстрировать те или иные идеи), а также хорошо сочетаются с интервью, анкетированием, прототипированием и моделированием — в том числе для обсуждения результатов и формирования выводов и решений. Мозговой штурм может проводиться и как часть семинара, и как отдельный вид деятельности. Он позволяет за минимальное время сгенери ровать большое количество идей, которые в дальнейшем можно не спеша рассмотреть с точки зрения их использования для развития проекта.
5. Наблюдение. Может выражаться как в буквальном наблюдении за некими процессами, так и во включении проектного специалиста в эти процессы в качестве участника. С одной стороны, наблюдение позволяет увидеть то, о чём (по совершенно различным соображениям) могут умолчать интервьюируемые, анкетируемые и представители фокусных групп, но с другой — отнимает очень много времени и чаще всего позволяет увидеть лишь часть процессов.
6. Прототипирование. Состоит в демонстрации и обсуждении промежуточных версий продукта (например, дизайн страниц сайта может быть сначала представлен в виде картинок, и лишь затем свёрстан). Это один из лучших путей поиска единого понимания и уточнения требований, однако он может привести к серьёзным дополнительным затратам при отсутствии специальных инструментов (позволяющих быстро создавать прототипы) и слишком раннем применении (когда требования ещё не стабильны, и высока вероятность создания прототипа, имеющего мало общего с тем, что хотел заказчик).
7. Анализ документов. Хорошо работает тогда, когда эксперты в предметной области (временно) недоступны, а также в предметных областях, имеющих общепринятую устоявшуюся регламентирующую документацию. Также к этой технике относится и просто изучение документов, регламентирующих бизнес-процессы в предметной области заказчика или в конкретной организации, что позволяет приобрести необходимые для лучшего понимания сути проекта знания.
8. Моделирование процессов и взаимодействий. Может применяться как к "бизнес-процессам и взаимодействиям" (например: "договор на закупку формируется отделом закупок, визируется бухгалтерией и юридическим отделом..."), так и к "техническим процессам и взаимодействиям" (например: "платёжное поручение генерируется модулем "Бухгалтерия", шифруется модулем "Безопасность" и передаётся на сохранение в модуль "Хранилище"). Данная техника требует высокой квалификации специалиста по бизнес-анализу, т.к. сопряжена с обработкой большого объёма сложной (и часто плохо структурированной) информации.
9. Самостоятельное описание. Является не столько техникой выявления требований, сколько техникой их фиксации и формализации. Очень сложно (и даже нельзя!) пытаться самому "придумать требования за заказчика", но в спокойной обстановке можно самостоятельно обработать собранную информацию и аккуратно оформить её для дальнейшего обсуждения и уточнения.

Requirements traceability = трассируемость требований = прослеживаемость требований = отслеживаемость связей требований.

Трассировка помогает понимать связи требовний, понимать откуда вообще в системе та или иная функциональность или системное ограничение, какой бизнес-цели они служат.

Например, установление сквозной связи между:

• Потребности клиента — Требования — Основные элементы Системы
• Потребности клиента — Бизнес-требования — user stories и use case Системы — Тесты

Для чего нужно:

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

скачать схему в формате diagrams.net (бывший draw.io)

определяет, основание для -->
Цель, нужда, интерес	Требования и их Спецификации	Спецификация требований к ПО (SRS)	Компоненты ПО
увеличение дохода: привлечение новых Клиентов сокращение потерь потенциальных Клиентов увеличение количества Продуктов/Услуг улучшение качества Продуктов/Услуг ... сокращение издержек: оптимизация бизнес-процессов по продаже Продуктов оптимизация бизнес-процессов предоставления Услуг ... ...	Бизнес-требования (BR) и Спецификация (BRS) Стейкхолдерские требования (StR) и Спецификация (StRS) Пользовательские требования (UR) Системные требования (SR) и Спецификация (SyRS) Ограничения (Constraints) интерфейсы связанных систем законы доступный бюджет, сроки используемая технологическая платформа возможности пользователя/оператора ... ...	интерфейсы функции дизайн/юзабилити производительность логическая структура БД соответствие стандартам надёжность доступность безопасность ремонтопригодность кроссплатформенность Ограничения проектирования/разработки: интерфейсы связанных систем используемая программная платформа, фреймворк, ЯП	Данные (сущности), хранящиеся в: БД файлах оперативной памяти Формы GUI веб-страницы окна desktop-приложения ... Событийные процедуры для форм GUI Вспомогательные триггеры постобработки хранимые процедуры workflow-компоненты ... Интерфейсы веб-сервисы ... Периодические задания JOBы в БД SSIS-пакет вызовы пакетов в ORACLE ... *nix — crontable Windows — планировщик заданий ... отчёты подсистема управления правами

Тест-кейсы можно увязать к Компонентам ПО, как объектам самого низкого уровня Системы — архитектурного слоя Software. Ниже только физический.

Управление требованиями = принятие управленческий решений о:

1. Приоритетах требований
2. Рамках продукта (какие требования включать, какие — нет), оно же — scope management из того же PMBOK, включая сортировку входящих внешних требований — какие требования из других проектов включать, а какие — нет.
3. Рамках итерации
4. Чего проект требует от других проектов — исходящие требования

Эти решения принимает Менеджер, и даже если выдвигает часть из них Аналитик — всё равно несёт ответственность за них Менеджер.
То, что физически в учётной системе атрибуты Приоритет, Релиз, Итерация, Источник, Потребитель проставляет, например, Аналитик, ещё не делает его "управленцем требований", он тут просто учётчик, оператор БД.

Также, технически, под гриф "управления требованиями" попадают:

5. Управление статусом требований
6. Управление внутренними трассировками требований
7. Управление трассировками требований на другие артефакты проекта

С этими атрибутами, действительно, Менеджеру возиться не интересно и он может доверять всю эту работу Аналитику.
Но если посмотреть на жизненный цикл требований и на трассировки, то станет понятно, что Аналитик отвечает только за часть переходов и за внутренние трассировки, а за переходы типа "разработано --> протестировано" и за трассировки требований на тесты, например, отвечает уже Тестировщик.

Есть мнение, что управление требованиями — это не задача аналитика.
Прежде всего потому, что управление — это управление, а разработка — это разработка:

TBD

Определения

Use case = последовательность действий в диалоге между Актором и Компонентом/Системой с получением значимого результата, где Актором может быть пользователь или что-то, что может обмениваться информацией с Системой.

Юзкейс = текст,
описывающий сценарий
взаимодействия Актора с Системой,
приводящий
к значимому (для кого-то) результату.

Простейшие примеры диаграмм вариантов использований

Простейший пример варианта использования

UC1. Регистрация пассажира на рейс.

Базовая часть Use Case
Система	Система регистрации пассажира на рейс
Основное действующее лицо	Пассажир
Цель	Зарегистрироваться на рейс
Триггер	Пассажир решает зарегистрироваться на рейс и заходит на страницу регистрации сайта
Результат	Информация о регистрации пассажира сохранена. У пассажира есть посадочный талон.

Основной поток событий
№ шага	Действующее лицо	Шаг	Комментарий
1	Система	Запрашивает фамилию и код бронирования
2	Пассажир	Вводит фамилию и код бронирования	Код бронирования: 7 символов, заглавные латинские и цифры. Например: MTDTC1
3	Система	Проверяет, что приобретен билет на этот рейс на имя этого Пассажира
4	Система	Сохраняет информацию о регистрации Пассажира на рейс
5	Система	Подтверждает Пассажиру, что он зарегистрирован на рейс
6	Система	Выводит для печати посадочный талон
7	Пассажир	Отправляет посадочный талон на печать

На самом деле большую часть реального полного Use Case составляет не основной поток, а альтернативные потоки, которые позволяют задавать ветвления потока, циклы и обрабатывать "неправильные" события. Подробнее — читать в книге Ivar Jacobson. Use-case 2.0 (к сожалению уже нельзя скачать книгу открыто просто так, нужно заполнять форму).

Use Case для руководителя проекта

Сам по себе Use Case — это естественный способ описывать диалог, он понятен человеку без подготовки, Use Case обычно не содержит деталей реализации и пишется на языке целей пользователей.
Поэтому Use Case удобно согласовывать с Заказчиком как "единицу поставки": элемент планирования работы над системой и сдачи проекта.

Use Case для тестировщика

Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (test case), так как они описывают в каком контексте должно производиться каждое действие пользователя.
Use Case, по умолчанию, являются тестируемыми требованиями так как в них всегда указана цель, которой нужно достигнуть и какие шаги надо для этого воспроизвести.

Use Case для Аналитика и Продукт-Менеджера

Для аналитика и менеджера продукта, как наиболее частых авторов, Use Case это отличный инструмент:

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

Ограничения метода

Use Case не обеспечивают полноту всех функциональных требований, если в систему должна быть заложена сложная бизнес-логика, т.е. обработка информации в системе зависит не только и не столько от действий пользователей, сколько от внутренних правил взаимодействия объектов.

Пользовательские истории (user story) = способ описания Требований к разрабатываемой Cистеме, сформулированных как одно или более предложений на повседневном или деловом языке пользователя.
Пользовательские истории используются гибкими методологиями разработки ПО для спецификации требований (вместе с приёмочными испытаниями). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой.
Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.

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

Примеры: