# БИБЛИОТЕКА ..Курсы ..Redmine Системная инженерия Стейкхолдеры Управление Критическая цепь Linux Информация Социальные связи Саморазвитие Логика, интеллект Политэкономия Сумма технологии АНАЛИТИКА ..Ресурсы ..ПО для Аналитика ..Кто аналитики? ..Бизнес-процесс ..Требования ..Уровни и типы ..Источники Нотации Архитектура РАЗРАБОТКА ..Ресурсы ..Цикл разработки ПО ..Waterfall ..RUP ..Agile ..Kanban ..Continuous Integration git Frontend HTTP/REST Apache web-server Регулярные выражения Javascript Perl ТЕСТИРОВАНИЕ ..Ресурсы ..QA и QC ..Цикл тестирования ..1 Тест-анализ ..2 Тест план ..3 Тест-дизайн и покрытие ..Уровни тестирования ..Виды тестирования ..Баг-репорт ..Шаблоны документов XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН БАЗЫ ДАННЫХ SQL MongoDB
Эта страница:
Почерпнуть мудрость ПО для Аналитика Аналитики - кто? О документации Бизнес-процесс Требования Уровни и типы требований Свойства качественных требований Источники требований Трассировка Управление требованиями Use case (вариант использования) User story (пользовательские истории) GAP-анализ
Ещё в этом разделе:
АНАЛИТИКА Нотации Архитектура
Другие разделы:
# АНАЛИТИКА MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА ТЕСТИРОВАНИЕ
Аналитика
Если заказчик любимый - делаем то, что ему нужно.
Если заказчик нормальный - делаем то, что он хочет.
А если заказчик мерзкий - делаем то, что он написал в ТЗ.
Почерпнуть мудрость

Фундамент - книги

Разное

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

Проектирование системы для управления производством IT-продуктов.

Производство информационных систем.

( скачать схему в XML )
ПО для Аналитика
  • Для рисования BPMN и UML:
  • Для работы с Требованиями (разработка, управление, трассировка):
  • Для работы и с Требованиями и с Архитектурой:
    • Enterprise Architect (проприетарное, есть trial на 30 дней) ( и могут установить EA под WINE). В высшей степени могущественный инструмент, но недешёвый.
Аналитики - кто?

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

Главные задачи:

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

Основной документ на выходе -- описание бизнес-процессов As Is (обязательно) и To Be (при необходимости).

Кто чаще всего становится бизнес-аналитиком: люди с экономическим образованием

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

Главные задачи:

  • сбор, анализ, формализация и согласование Требований к системе. Другими словами, управление требованиями на протяжении всего их жизненного цикла.
  • создание сценариев использования (use case)
  • создание концепции о том, как будут решаться проблемы Заказачика, согласовывать эту концепцию, предоставлять её Системному Архитектору, который будет разрабатывать системную архитектуру.

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

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

Аналитику крайне полезно иметь представление о

  • жизненном цикле ПО;
  • ключевых методологиях разработки: Waterfall, RUP, что-то из Agile (лучше бы Scrum), Kanban, для гос. заказчиков -- ГОСТ 19 и 34;
  • основах системного анализа - Карл Вигерс отлично подойдет (PDF Карл Вигерс. Разработка требований к ПО. 2014 г.);
  • графических нотациях: BPMN / UML / Aris / IDEF0 / IDEF3;
  • векторных графических редакторах типа Visio, draw.io, gliffy, Modelio;
  • инструментах проектирования/моделирования, самое востребованное на рынке: Sparx Enterprise Architect и Rational Rose;

О документации

Кратко

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

Длинно

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

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

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

Вот моё представление о базовой документации:

  1. В основе всего лежит один документ, который описывает текущую реализацию бизнес-процесса в контексте использования ИС.
    В карточке описания бизнес-процесса указывается, на каких функциональных модулях системы он построен.
  2. Как только бизнес хочет начать работать по-другому, мы перепроектируем бизнес-процесс и указываем какие его участки на что меняем.
    К этому привязываются изменения в функциональных модулях.
  3. Если другой бизнес-процесс пытается использовать для себя функциональный модуль, то Реестр ТЗ подсказывает какие бизнес-процессы уже на нём сидят.
  4. В итоге для бизнеса всё сводится к трём документам:
    - Документ версии 1.0
    - Вносимые изменения,
    - Документ версии 1.1.
    И такая же картина с технической стороны для функциональных модулей (подсистем).

Весь список "бумажек" нужный для разработки и доработки:

  1. Реестр ТЗ.
  2. Бизнес-часть ТЗ: описание бизнес-сценария и его системных сценариев использования.
    Бизнес-сценарий и системные сценарии использования по сути и есть сценарии приёмо-сдаточных испытаний.
    Это на 50% готовые приёмочные тесты.
  3. Дополнение к бизнес-части ТЗ: указание что на что меняем в бизнес-сценарии и системных сценариях.
    Как правило, после выполнения работ и подготовки обновленной версии ТЗ "выкидывается".
  4. Техническая часть ТЗ: раскладка системных сценариев на сущности системы.
  5. Дополнение к технической части ТЗ.

Куда отнести критерии приёмки?

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

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

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

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

Бизнес-процесс

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

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

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

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

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

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

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

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

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

Уровни и типы требований
(скачать схему в XML)

Бизнес-требования (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.
  • Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную.
  • Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц.

Спецификация требований (software requirements specification, SRS) объединяет в себе описание всех требований уровня продукта и может представлять собой весьма объёмный документ (сотни и тысячи страниц).
Пример SRS (2013)

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

Свойства качественных требований
  • Завершённость (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). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных).
    Проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию.

TBD

Источники требований

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

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

TBD

Управление требованиями

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

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

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

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

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

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

TBD

Use case (вариант использования)

Определения

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 (пользовательские истории)

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

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

As a <type of user>, I want <some goal> so that <some reason>.
Как <роль пользователя>, я <что-то хочу получить> <с такой-то целью>.
Примеры:

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

GAP-анализ

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

TBD