Термин	Перевод	Определение
Requirement	Требование	Свойство, которое должен иметь продукт, чтобы представлять какую-то ценность для пользователей
Scrum	Скрам	Итеративный процесс разработки программного обеспечения: для программного продукта создается много последовательных выпусков, в которых постепенно добавляется требуемая функциональность
Increment	Инкремент	Готовая к использованию часть продукта, которая должна быть реализована к завершению спринта
Sprint	Спринт	Короткий временной интервал, в течение которого Scrum-команда выполняет заданный объем работы
Sprint Planning	Планирование Спринта	Встреча Scrum-команды, на которой происходит планирование работы на следующий Sprint
Daily Scrum	Ежедневный Скрам	Встреча, которая длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время
Sprint Review	Обзор Спринта	Встреча, которая проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Scrum-команда, при необходимости, сделала адаптацию Project backlog
Sprint Retrospective	Ретроспектива Спринта	Встреча, которая дает возможность Scrum-команде провести инспекцию своей работы и создать план улучшений на следующий Sprint
Project backlog	Бэклог проекта	Перечень пользовательских историй (user story), упорядоченный по приоритету и порядку реализации
Sprint backlog	Бэклог спринта	Перечень требований, выбранных Scrum-командой из бэклога проекта с учетом приоритета, оценок трудозатрат, ресурсов команды и длительности Спринта

Универсального определения требований нет.

IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:

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

ГОСТ Р ИСО 9000-2015. Системы менеджмента качества. Основные положения и словарь определяет требование как: потребность или ожидание, которое установлено, обычно предполагается, или является обязательным

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

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

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

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

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

Управление требованиями подразумевают все действия, поддерживающие целостность, точность и своевременность соглашения о требованиях:

1. управление изменениями базовой версии требований;
2. поддержание планов проекта актуальными в соответствии с изменяющимися требованиями;
3. управление версиями отдельных требований и документации требований;
4. контроль состояния требований в базовой версии;
5. управление логическими связями между отдельными требованиями и другими материалами для работы с проектом.

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

1. инструменты, приемы и соглашения для управления версиями различных документов требований и отдельных требований;
2. то, как составляется базовая версия требований;
3. статус требований, которые будут использоваться, и лица, которые имеют право изменять их;
4. процедуры контроля за статусом требования;
5. способы, с помощью которых новые требования и изменения существующих требований предлагаются, обрабатываются, обсуждаются и передаются всем заинтересованным лицам;
6. методы анализа влияния предложенного изменения;
7. то, как на планах и обязательствах проекта отразятся изменения требований.

Существует множество методов управления требованиями. Методы управления требованиями прежде всего определяются методологией управления проектом. Далее будет рассмотрено управление требованиями на примере методологии Scrum.

Scrum - методология гибкой разработки ПО, которая делает акцент на качественном контроле процесса разработки.

У каждого Scrum-проекта есть владелец продукта, Scrum-мастер и команда. Проект можно назвать эффективным, когда Scrum-мастер, владелец продукта и команда начинают работать вместе, а не врозь.

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. Sprint ограничен по времени (1-4 недели) и имеет фиксированную продолжительность. По окончанию Sprint’а должна быть получена новая рабочая версия продукта, которую представляют на демо-встречах.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Project Backlog и формирование Sprint Backlog. Каждый Sprint должен иметь цель, которая достигается с помощью выполнения задач из Sprint Backlog.

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint'а.

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

Для управления требованиями Scrum использует собственные методы, о которых будет рассказано далее.

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

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

Еще одна причина - отсутствие тесного взаимодействия с клиентами.

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

Пользовательская история позволяет ответить на 3 вопроса: кто? что? зачем?

Многие пользовательские истории пишутся по следующему шаблону: Я как <роль> хочу <конкретные действия, которые я предпринимаю>, чтобы <цель>.

Пользовательские истории дают Scrum-командам простой способ управлять Бэклогом. В Бэклоге пользовательские истории (элементы Бэклога) упорядочены по приоритету и порядку реализации. Бэклог открыт для редактирования всем участникам Скрам-процесса

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

В планировании Спринта Scrum-команда зачастую проводит оценивает методом Planning Poke. Для оценки методом Planning Poke команда сначала проводит оценку, потом обсуждает задачу. Каждый член команды за отведенное время выбирает одну из карт. На картах обозначены цифры - обычно числа Фибоначчи. После истечения времени все раскрывают карты. Если все карты близки по значениям, команда оценила задачу примерно одинаково и можно на этом закончить. Если нет - каждый член приводит свои аргументы, после чего все повторяется сначала.

1. Лекция 5. Управление требованиями, изменениями, инцидентами
2. Карл И.Вигерс. Разработка требований к программному обеспечению.
3. Э.Стеллман, Д.Грин. Постигая Agile. Ценности, принципы, методологии.
4. Управление требованиями
5. Спринты - Atlassian
6. Словарь терминов Scrum — ScrumTrek
7. Как оценивать задачи по методу Planning Poker