Бизнес требования к программному обеспечению это

Фундаментальное описание требований к ПО и подходов к их выявлению и сбору от тестировщика Noveo Вадима: пост освещает все аспекты этой области знаний, структурирует информацию и не оставляет ни малейшего шанса недопониманиям и «темным» местам. Приятного прочтения!

Вадим

Вадим


Noveo Test Engineer

Мы с вами как тестировщики каждый день работаем с требованиями. Суть нашей работы — выяснять, соответствует ли разрабатываемая система требованиям заказчика, рынка и отраслевым стандартам. Более того, в наши обязанности входит проверка требований на соответствие критериям качества. В идеальном мире мы с вами были бы просто гарантом качества — судьями, дающими объективную оценку. Но, к сожалению, мир не идеален, и строгое распределение участников проекта на роли чаще всего не представляется возможным. В эпоху повсеместного использования гибких методологий разработки мы с вами должны обладать знаниями, позволяющими выполнять задачи не только контроля качества.

Цели этого поста заключаются в следующем:

  1. Определить, что такое требование, какие типы и уровни требований выделяют.
  2. Понять, какие существуют методы сбора и выявления требований.
  3. Предоставить почву для дальнейшего изучения сферы системного и бизнес-анализа.

Требования

Начнем с требований как таковых:

  • Что они из себя представляют?
  • Какие виды требований выделяются?
  • Как они согласуются?
  • Какие источники требований можно выделить?

Определение требования

Прежде чем погрузиться в теорию разработки требований к ПО, попробуйте, основываясь на своих знаниях и опыте, ответить на вопрос: как вы определяете термин «требование»?

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

Требования к ПО — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы (Ian Sommerville и Pete Sawyer, 1997).

Требования к ПО — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению (ПО), в результате анализа требований (Википедия).

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

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

Как видно выше, устоявшиеся термины не отражают всю полноту понятия «требование к ПО», поэтому также стоит отметить следующее: требования охватывают как видение пользователя, так и внешнее поведение системы, а также представление разработчика о некоторых внутренних характеристиках. Они включают как поведение системы в определенных условиях, так и свойства, которые делают систему полезной и удовлетворяющей конечных пользователей.

Термин «требование» охватывает довольно широкую предметную область. Поэтому возникает вопрос типизации и классификации требований.

Уровни и типы требований

Требования к ПО состоят из трех уровней:

  1. Бизнес-требования.
  2. Пользовательские требования.
  3. Функциональные требования.

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

Бизнес-требования BRQ

Бизнес-требование (business requirements) — высокоуровневая бизнес-цель организации или заказчиков системы.

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

Бизнес-требования — это верхний уровень абстракции требований к системе. Они не относятся напрямую к реализации проекта, а в первую очередь отражают цели бизнеса, абстрагированные от реализации системы. В конечном итоге бизнес-требования формируют документ концепции и границ.

Если кратко, документ содержит определение следующих понятий:

  • Бизнес-возможности, бизнес-проблемы — факты и события, формирующие бизнес-цели, то есть грубо — причины инициации проекта.
  • Бизнес-цели — цели, которые должны быть решены разработкой и вводом в эксплуатацию системы. Являются критериями успеха проекта.
  • Концепция продукта (Vision) — сжато описывает конечный продукт, который достигнет заданных бизнес-целей.
  • Границы проекта (scope) — показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация.

Примеры бизнес-требований:

Сократить время обработки заказа на 50% (цель) — система должна предоставить интерфейс, упрощающий создание заказа (концепция).

Увеличить клиентскую конверсию до 35% (цель) — в системе должны быть представлены механизмы побуждения клиента к заказу (концепция).

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

Источники бизнес-требований (где искать?):

  • Внутренняя документация компании (положения, инструкции, приказы).
  • Документация по предметной области (профильные литература и статьи, исследования).
  • Нормативная документация (законы и иные правовые акты, государственные стандарты).
  • Продукты конкурентов.

Стейкхолдеры (у кого спрашивать?):

  • Инициатор проекта.
  • Руководитель проекта (менеджер проекта).
  • Руководитель структурного подразделения заказчика (коммерческий директор, директор по маркетингу).
  • Бизнес-аналитик.

P.S. Список стейкхолдеров меняется от проекта к проекту, для каждого проекта необходимо отдельно определять список заинтересованных/ответственных лиц. Списки, представленные мной, являются сугубо примерами из моей практики.

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

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

Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователе (Карл Вигерс, «Разработка требований к программному обеспечению»).

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

Пользовательские требования также часто именуются фичами.

Фича (функциональность) — функционально обобщенные части системы, решающие отдельные задачи пользователей или интерпретирующие бизнес-процессы (и их артефакты), которые будут реализованы в рамках системы.

Исходя из вышеописанных определений, пользовательские требования содержат:

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

В конечном итоге пользовательские требования формируют «Документ пользовательских требований». Пользовательские требования могут быть представлены в виде:

  • текстового описания,
  • вариантов использования, сценариев использования (Use Case),
  • пользовательских историй (User Story),
  • диаграммы вариантов использования.

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

Пользователь должен иметь возможность + {тезис}.

Пример пользовательского требования:

Пользователь должен иметь возможность добавить объект в избранное (функциональность).

Источники пользовательских требований требований (где искать?):

  • Анализ и декомпозиция бизнес-требований.
  • Описание бизнес-процессов.
  • Артефакты бизнес-процессов:
  • документы входные/выходные,
  • стандарты,
  • регламенты,
  • обрабатываемые данные,
  • иная информация, используемая и/или производимая в бизнес-процессе.
  • Отраслевые стандарты.
  • Реализованные проекты, проекты конкурентов.

Стейкхолдеры (у кого спрашивать?):

  • Бизнес-аналитик, системный-аналитик.
  • Конечные пользователи — люди, взаимодействующие с системой напрямую.
  • Косвенные пользователи — люди, использующие результаты работы системы, не взаимодействуя с ней напрямую.
  • Представители пользователей.
  • Менеджер проекта.
  • Руководитель структурного подразделения заказчика.

Этот уровень требований напрямую входит в круг обязанностей QA-инженера. В задачи QA на этом уровне входит:

  • Определение соответствия описания требований критериям качества.
  • Анализ требований для проработки сценариев тестирования.
  • При достаточном уровне компетенций в предметной области:
  • определение соответствия требований устоявшимся отраслевым стандартам (например: системе не достаёт фичи, которая в рамках предметной области системы является обязательной);
  • определение соответствия требований с утвержденными бизнес-требованиями. Ответ на вопрос: «Решает ли пользовательское требование бизнес-цели проекта и задачи пользователей?«.

Функциональные требования FRQ

Функциональные требования (functional requirements) — описание требуемого поведения системы в определенных условиях.

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

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

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

Пользователь должен иметь возможность добавить объект в избранное (URQ):

FRQ 1 — Добавить в избранное.

FRQ 2 — Удалить из избранного.

FRQ 3 — Редактирование дополнительных атрибутов.

FRQ 4 — Обращение к объекту из меню избранного.

Источники требований (где искать?):

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

Стейкхолдеры (у кого спрашивать?):

  • Бизнес-Аналитик.
  • Системный аналитик.
  • Архитектор.
  • Менеджер проекта.
  • Разработчики.

Нефункциональные требования NFRQ

Нефункциональное требование (non-functional requirements) — описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.

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

  1. Выявляются и формулируются на всех уровнях иерархии требований.
  2. Напрямую или косвенно влияют на формирование каждого уровня требований.

Совет: Чаще всего нефункциональные требования отвечают на вопрос «Как? Каким образом?».

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

С точки зрения разработки функциональный скоуп проекта не является уникальным:

  • смотреть контент,
  • предлагать ротацию контента на основе алгоритмов,
  • создавать контент.

Все эти фичи так или иначе были представлены в других проектах. Ключом успеха проекта в данном случае является его UI/UX. А UI/UX сам по себе не отвечает за функции системы, а отвечает за то, каким образом будут реализованы эти функции.

SRS

В конечном итоге все требования консолидируются в одном документе «Спецификации требований к системе». Выше вы можете видеть структуру документа SRS. Ни в коем случае нельзя воспринимать её как жесткий стандарт (хотя таковой имеется: ISO/IEC/IEEE 29148:2011). Я предлагаю вам использовать эту структуру как чек-лист для определения полноты описания системы. Стоит отметить, что внутренние стандарты документирования и полноты требований меняются от проекта к проекту, но набор типов требований всегда будет идентичен. Кто-то опускает бизнес-требования, для кого-то пользовательские требования тождественны функциональным. В конечном итоге все требования — лишь абстракция, и каждая команда подбирает под себя удовлетворительный уровень детализации этой абстракции.

Выявление требований

Выявление требований — итеративный процесс, состоящий из следующих этапов:

  1. Подготовка к выявлению.
  2. Выявление.
  3. Утверждение результатов.

Подготовка к выявлению требований

В процессе подготовки к выявлению требований необходимо ответить на следующие вопросы:

1. Что необходимо выяснить? — Анализируем имеющуюся информацию о системе:

а. Анализ текущего описания требований к системе.

b. Анализ текущей реализации системы.

c. Выявление недостающих и/или недостаточно описанных требований.

2. У кого? Где? — Определить источник требований:

а. Собрать список доступных источников, таких как:.

i. Документация.

ii. Артефакты бизнес-процессов и/или текущей реализации системы.

b. Определить список стейкхолдеров, которые могут выступать источником требований к системе.

3. Каким образом? — Выбрать оптимальный метод выявления требований.

Выявление требований. Интервью

Самый популярный и, возможно, эффективный метод выявления требований. Представляет из себя беседу с заказчиком.

Подготовка к интервью

Подготовка к интервью состоит из следующих этапов:

1. Собрать информацию о собеседнике(ах):

а. Роль в проекте?

b. За какие вопросы ответственен?

2. Подготовить вопросы:

a. Сформулировать проблематику интервью.

b. Сформулировать вопросы.

c. Подготовить дополнительные вопросы.

3. Определить тайминг встречи.

a. Нужно стараться уложиться в один час. Чаще всего человек начинает терять концентрацию после 40 минут непрерывной беседы.

b. Для каждого вопроса определить необходимое время на обсуждение.

c. Если вы не успеете задать все вопросы в рамках одной встречи, назначьте несколько встреч.

4. Согласовать календарь встреч.

a. Если предполагается несколько встреч — то не обходимо составить график встреч.

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

От себя рекомендую подготовить файл с вопросами и планом интервью. Для примера — вот шаблон, который использую я:

Протокол интервью

Проект:{}

Дата проведения:{}

Интервьюер: {Кто проводит интервью}

Интервьюируемый:{Кому задаём вопросы}

Проблематика:{Тема интервью}

Вопрос № 1:

Тайминг вопроса:

Текст вопроса:

Таймкод:

Ответы на вопрос:

Стейкхолдер 1 —

Стейкхолдер 2 —

Проведение Интервью

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

1. Всегда ведем запись встречи.

a. Спрашиваем собеседника, не против ли он вести запись разговора.

b. Включаем запись после согласия собеседника.

2. Small talk для разрядки.

a. Как настроение?

b. Как погода?

c. И т.д. и т.п.

d. Но не затягиваем, пара вопросов из вежливости, не более.

3. Начинаем с объявления проблематики.

4. Стараемся следовать плану встречи. Вопросы задаём последовательно.

5. Желательно в плане указываем тайм-код, в какую минуту разговора задан вопрос, чтобы упростить дальнейшую обработку протокола.

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

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

a. Например: Я правильно вас понял, что необходимо реализовать функционал следующим образом {Тезис}?

Обработка результатов Интервью

После проведения интервью необходимо письменно зафиксировать полученную информацию. Рекомендую делать это сразу после интервью. Итак:

1. Заполняем протокол встречи.

a. Читать краткий протокол встречи намного проще, чем смотреть часовую запись в поисках ответов.

2. Направляем участникам встречи результаты в формате «Вопрос — Зафиксированное решение».

b. Это необходимо для получения от заказчика письменного утверждения результатов встречи.

Плюсы и минусы метода

Плюсы метода:

  • Наиболее эффективный способ метод сбора требований.
  • Меньшая вероятность недопонимания между собеседниками.
  • Большая вероятность выявления «скрытых» требований.

Минусы метода:

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

Выявление требований. Анкетирование

Метод анкетирования подразумевает создание анкеты (списка вопросов) и её рассылку большому количеству опрашиваемых.

Подготовка

Подготовка к анкетированию состоит из следующих этапов:

1. Собрать контакты опрашиваемых стейкхолдеров.

2. Подтвердить готовность стейкхолдеров участвовать.

3. Подготовить анкету:

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

b. Задавать можно как открытые, так и закрытые вопросы.

c. Но лично я рекомендую предоставлять опрашиваемым варианты ответа даже в формате открытого вопроса. То есть обозначаем проблематику, предлагаем варианты решения, а также оставляем за опрашиваемым возможность раскрыть свою позицию. По сути аналог варианта «Другое» в опроснике.

Проведение

  1. Рассылаем анкету опрашиваемым.
  2. Контролируем сроки опроса (должен быть внутренний дедлайн).
  3. Ответы, по мере поступления, консолидируем в одном документе (каналы связи с опрашиваемыми могут быть разными, но место хранения требований всегда должно быть одно).

Обработка результатов

  1. Анализируем ответы.
  2. Фиксируем требования.
  3. Утверждаем требования с ответственными лицами.

Плюсы и минусы метода

Плюсы:

  • Большой охват опрашиваемых.
  • Сравнительно небольшие временные затраты.
  • Возможность повторного использования анкеты (бриф на стандартизированный проект).

Минусы:

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

Выявление требований. Мозговой штурм

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

Подготовка

1. Формулируем проблематику:

а. Необходима краткая и емкая формулировка, которая оставит поле для размышления экспертов.

b. Проблематика озвучивается экспертам заранее, чтобы у них было время «на подумать».

2. Подготавливаем дополнительные материалы для отработки идей — например, макеты системы.

3. Формируем группу экспертов.

4. Согласовываем дату и время.

Проведение

1. Ведем запись-протокол. Уведомляем участников о том, что ведется запись.

2. Озвучиваем регламент встречи:

a. Тема,

b. Тайминги,

c. Правила.

3. Эксперты озвучивают идеи по очереди.

4. Эксперты должны озвучивать любые идеи, касающиеся проблематики.

5. Каждая идея фиксируется и обсуждается.

6. В некоторых источниках утверждается, что нужен полный запрет на критику. На мой взгляд, это приводит только к сбору сырых идей, без их отработки. «В споре рождается истина».

7. Коллективное комбинирование собранных идей.

Обработка результатов

  1. Анализируем идеи.
  2. Формализуем и описываем (то есть готовим развернутое описание).
  3. Утверждаем идеи с ответственными.

Плюсы и минусы метода

Плюсы:

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

Минусы:

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

Другие методы выявления требований

  • Анализ документации — изучение и анализ существующей документации, которая напрямую или косвенно касается разрабатываемой системы.
  • Анализ системных интерфейсов, API и базы данных — анализ систем, которые будут взаимодействовать с разрабатываемой системой.
  • Анализ пользовательского интерфейса — анализ интерфейсов, функционально похожих (или идентичных) на разрабатываемую систему (отраслевые стандарты UI/UX). Также к этому относится анализ интерфейсов систем, входящих в IT-экосистему заказчика.
  • Моделирование процессов, поведения системы и пользователей — моделирование процессов и схем данных помогает структурировать и упорядочивать информацию о проекте.
  • Повторное использование требований — многие элементы систем имеют стандарты исполнения. Например: регистрация — авторизация пользователей.
  • Вовлечение представителя заказчика в команду разработки — вовлечение заказчика в работу над проектом является одним из постулатов Agile. В целом наличие представителя заказчика в команде разработки экономит уйму времени на коммуникации.
  • Презентации, демо и т.п. — представление требований/реализации системы заказчику. Данный способ помогает уточнить требования, а также выявить скрытые и/или избыточные требования. Пример: демонстрация мокапов будущей системы пользователям.
  • Работа в «Поле» (наблюдение) — наблюдение за деятельностью и процессами будущих пользователей.
  • Обучение — процесс, в котором заказчик или любой другой человек из организации заказчика, знающий процесс, обучает аналитика по принципу «учитель — ученик».

Очевидный факт:

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

Материалы для самостоятельного изучения

Блоки знаний:

  • Бизнес-анализ — раздел знаний, отвечающий за описание и формализацию бизнес-процессов. Прежде чем интерпретировать бизнес-процессы в виде ПО, необходимо их «правильно» описать и формализовать.
  • Моделирование бизнес-процессов — изучение различных нотаций описания бизнес-процессов. Неразрывно связан с бизнес-анализом.
  • Системный-анализ — раздел знаний, отвечающий за анализ процессов непосредственно в самом ПО.
  • Моделирование систем — изучение нотаций описания систем ПО. Неразрывно связан с системным анализом.
  • Документирование требований — изучение различных сред документирования информации о проекте и системе.
  • Управление требованиями (согласование, управление изменениями, трассировка требований) — отдельный процесс в системе знаний об анализе в ИТ. Является одним из самых сложных процессов на долгосрочных проектах с большим количеством итераций.
  • Прототипирование — изучение различных инструментов для моделирования интерфейсов и архитектуры ПО. Например: Figma для верстки макетов интерфейсов.

Книги:

  • Вигерс, Карл: Разработка требований к программному обеспечению. 3-е издание, дополненное / Карл Вигерс, Джой Битти. — Санкт-Петербург : БХВ-Петербург, 2019. — 736 с.
  • Ильяхов М., Сарычева Л. Пиши, сокращай. Как создавать сильный текст — 2017.
  • Гэртнер, Маркус: ATDD — разработка программного обеспечения через приемочные тесты. — ДМК-Пресс, 2013. — ISBN 978-5-457-42706-8.
  • Gojko Adzic, David Evans — Fifty Quick Ideas to Improve Your User Stories — 2014.
  • Майкл Мескон, Майкл Альберт, Франклин Хедоури — Основы менеджмента
  • Хоп, Грегор Шаблоны интеграции корпоративных приложений (Signature Series) / Грегор Хоп, Бобби Вульф. — Москва : Вильямс, 2019. — 672 с.
  • Кон, Майк Пользовательские истории. Гибкая разработка программного обеспечения / Майк Кон. — Москва : Вильямс, 2018. — 256 с.
  • Паттон, Джефф Пользовательские истории. Искусство гибкой разработки ПО / Джефф Паттон — Санкт-Петербург : Питер, 2019. — 288 с.
  • Cockburn, Alistair Writing Effective Use Cases / Alistair Cockburn. — Addison-Wesley, 2001.
  • USE-CASE 2.0
  • Фаулер, Мартин UML. Основы. Краткое руководство по стандартному языку объектного моделирования / Мартин Фаулер. — Москва : Символ-Плюс, 2018. — 192 с.
  • Гойко, Аджич Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке / Аджич Гойко. — Москва : Альпина Паблишер, 2017. — 86 с.
  • Коберн, Алистер Быстрая разработка программного обеспечения/ Алистер Коберн. — Москва: Лори, 2002. — 336 с.
  • Корнипаев, Илья Требования для программного обеспечения: рекомендации по сбору и документированию / Илья Корнипаев. — Книга по требованию, 2013. — 118 с. Книга
  • Ми, Роберт Шаблоны корпоративных приложений / Роберт Ми, Мартин Фаулер. — Москва : Вильямс, 2018. — 544 с.
  • Мартин, Роберт Чистая архитектура. Искусство разработки программного обеспечения / Роберт Мартин. — Санкт-Петербург : Питер, 2018. — 352 с.
  • BABOK 3.0
  • SWEBOK 3.0
Источник

ГЕОРГИЙ САВЕЛЬЕВ

Как разработать
Бизнес-требования

Модель выявления требований

Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.

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

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

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

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

В наглядном виде модель выявления требований представлена на схеме:

Модель выявления требований

Почему важно выявлять и документировать
бизнес-требования?

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

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

Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.

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

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Программа переподготовки

«Business Analyst Bootcamp»

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

Какие бывают бизнес-требования?

Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.

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

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

      Ниже приведены примеры бизнес-требований по видам критичных активностей.

      Вид БТ: Значимые характеристики продуктов или услуг

      Примеры БТ:

      • Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
      • Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая ее.
      • Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.

      Вид БТ: Распознавание и обработка событий

      Примеры БТ:

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

      Вид БТ: Принятие решений

      Примеры БТ:

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

      Вид БТ: Сбор, обработка, хранение и предоставление информации

      Примеры БТ:

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

      Вид БТ: Обеспечение возможности выполнения действий

      Примеры БТ:

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

      Вид БТ: Предотвращение возможности выполнения действий

      Пример БТ:

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

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

      Требование, заданное с позиции «Система должна делать…», задает конкретное направление действиям разработчика, а также дает некоторые ограничения — в отличие от формулировки требований с позиции «Система не должна…»

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

      Признаки проблем в бизнес-требованих

      Можно выделить несколько типичных признаков проблем с бизнес-требованиями.

      • Неконкретность (слишком абстрактная формулировка)
      • Невозможность проверки (нет понимания, что является индикатором выполнения требования)
      • «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
      • Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
      • Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
      • Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
      • Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
      • Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
      • Привязка к конкретному решению, в том числе — конкретный бизнес-процесс

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

      Работа с «магическими» числами

      Чтобы проверить требование на наличие данной проблемы, можно определить чувствительность (столбец «чуть-чуть» в таблице) требования и его границы (столбец «гораздо» в таблице).

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

      Для тестирования бизнес-требований на «магические числа» можно использовать модель, представленную на рисунке.

      Любое число (разместим его в центральном круге) проверяется на чувствительность (на рисунке это столбец «чуть-чуть»). Что будет, если число будет немного больше? Есть ли какие-то последствия в таком случае для системы, стейкхолдеров? А если число будет чуть-чуть меньше?

      Затем мы задаем вопросы, пытаясь выявить реальные границы требования. Что, если число будет значительно больше? На что это повлияет? А если влияние достаточно серьезно, то нельзя ли предложить дополнительный способ обойти проблему? Границы обозначены в модели как столбец «гораздо».

      Расмотрим пример требования, которое содержит «магическое» число:

      “

      Требование: Сократить среднее время обработки заявки до 14 минут

      Проверим это требование на чувствительность. Для этого зададим вопросы:

      1. Что будет, если время обработки заявки будет не 14, а 12 минут?
      2. Что, если увеличить до 14,5 мин? Насколько это критично?

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

      Проверим границы требования, ответив на вопросы:

      1. Может быть, целесообразно сократить время обработки до 0 минут, т. е. не обрабатывать заявки и перевести клиента на самообслуживание?
      2. Что будет, если одна заявка будет обрабатываться день? Это плохо? Как это скажется на бизнесе?

      Данный тест помогает понять, является ли число «магическим». Если число связанно с какими-то объективными процессами (например, требованиями законодательства),
      то мы можем определить его чувствительность и границы, а значит появление этого числа в требованиях вполне обосновано.

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

      Попробуем переформулировать требование на примере:

      “

      Исходное требование:
      Оповестить надлежащих стейкхолдер не позднее 5 минут, после наступления события.

      Новое требование:
      Задержка в оповещении не должна приводить к задержке выполнения определенного действия получателем этого сообщения.

      То есть задержка не должна ни на что влиять. Таким образом, мы достигаем некоторой гибкости относительно временных затрат.

      Примеры некорректных бизнес-требований

      1. Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?
      2. Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
      3. Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
      4. Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
      5. Внедрить ERP — Кому и зачем это нужно? В чем проблема?

        Типовые ловушки аналитика

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

        • Формальность — «пишу, потому что надо здесь что-то написать».
        • Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
        • Превращение в аудит — выясняем все обо всем «на всякий случай».
        • Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.

        Что можно сделать с каждой из этих ловушек?

        Как документируются бизнес-требования?

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

        1. Монолитно

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

        2. Дробно

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

        Ниже будет приведен шаблон для каждого из этих видов документирования.

        Где документируются бизнес-требования?

        Стандартом ISO предполагается, что бизнес требования будут отражены монолитно в Спецификации требований стейкхолдеров (StRS). Для этого предусмотрен отдельный раздел Introduction, который включает в себя Business Purpose (цели), Business Scope (границы), Business Overview (обзор бизнеса).

        В ГОСТе 34.602−89 предполагается, что бизнес-требования будут описаны также, монолитом, в техническом задании на создание автоматизированной системы. в разделе Назначение и цели создания системы и Характеристика объектов автоматизации.

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

        В Agile бизнес-требования могут быть отражены по-разному. Это не формализовано, нет стандарта документов и способов описания.

        Шаблон монолитного описания БТ

        Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:

        • Контекст.
        • Описание возможности.
        • Бизнес-цели.
        • Метрики успешности.
        • Образ результата (Vision).
        • Деловые риски.
        • Предположения и зависимости бизнеса.

        Советы Вигерса по описанию БТ

        • Сокращайте шаблон в соответствии с потребностями.
        • Заполняйте не сверху вниз, а по мере поступления информации.
        • Пустой раздел — признак его ненужности или необходимости дополнительного изучения.
        • Не повторяйте то, что уже описано в другом месте — сошлитесь на имеющееся описание.
        • Исходите из возможности повторного использования БТ в других проектах.
        • Выявляйте конфликты, противоречия и выносите на обсуждение.
        • Проводите повторное рассмотрение БТ при каждой смене лиц, принимающих решения, чтобы убедиться, что понимание БТ не изменилось

          Шаблон дробного описания БТ

          Ниже представлен авторский шаблон дробного описания бизнес-требований. Он состоит из нескольких ключевых элементов:
          1. Заголовок, который включает в себя:

          • Уникальный идентификатор.
          • Краткое описание.

          2. Определение, развернутое объяснение, что из себя представляет БТ.
          3. Источник, откуда это требование взялось.
          4. Зависимости, если они есть между другими требованиями.
          5. Обоснование, краткое пояснение мотивации.
          6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.

            Шаблон дробного описания БТ

            Как документировать —
            объединять или дробить?

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

            1. Нет нужды документировать, если:

            • Узко-технический проект небольшого объема.
            • Всем все понятно и вряд ли кому-то когда-то что-то будет непонятно.

            2. Объединяем, если:

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

            3. Дробим, если:

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

            Что делать с отсутствующими или плохими БТ?

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

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

            Полученную информацию необходимо задокументировать одним из нескольких способов:
            1. Создать отдельный документ. Например, «Каталог целей» с дробным документированием бизнес-требований, на которые будем ссылаться.

            2. Добавить комментарии к уже существующим требованиям, поясняя откуда оно взялось.

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

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

            Программа переподготовки

            «Business Analyst Bootcamp»

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

            • Что делать, если, помимо ТЗ, есть еще и пользовательские требования?

              Зачастую пользовательские требования объединяются с бизнес-требованиями, т.к. объем БТ не очень большой, если они правильно определены, а значит делить эти требования на 2 отдельных документа нецелесообразно.
              Во избежание возможного недопонимания, в названии документа можно явно указать «Требования бизнеса и пользователей».

            • Вопрос:

              Имеет ли смысл создание промежуточных документов таких как VSD (Vsion & ScopeDocument) и BRD (Business Requirement Document)?

              С точки зрения Agile практик, бизнес-требования — это епархия Product Owner. Следовательно, работать нужно так, как удобно, и не создавать лишних документов для соблюдения формального протокола. Чем документов меньше, чем они компактнее и проще, тем эффективнее.

            • Должны ли в описание БТ быть включены требования к описанию «хотелок» в части User Interface?

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

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

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

            • Должен ли аналитик просматривать баги проекта и принимать решения о их важности?

              Иногда аналитик должен просматривать баги, а иногда — нет. Зависит от договоренностей в рамках проекта и распределения ролей в команде.

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

            • Должен ли аналитик проводить тестирование и валидацию продукта?

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

            • Что является объектом требований вида «Должна собираться информация о недоступности банкомата» — к чему это бизнес требование? К организации? Подразделению? К бизнес-процессу?

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

            • Что делать с функциями, если они не мапятся на конкретное БТ или мапятся сразу на два (при этом функция должна быть в скоупе)?

              Важно понимать, для чего мы делаем трассировку. В данном случае мы делаем трассировку, чтобы понять — БТ выполняется или нет?
              Нам не важно замапить все на все. Если мы делаем трассировку к модулям, это не значит, что нам надо оттрасировать каждую функцию и каждое требование. Достаточно понимать, данное требование — оно выполнено или нет? Если понимания достигнуто, то дальше можно не трассировать. Если мы пытаемся оттрасировать в другую сторону и видим какую-то висячую функцию, то это не значит, что у нас не должно быть никаких висячих функций, которые мы не можем замапить на какую-то функцию.
              Стоит помнить, что трассировка — это инструмент, а не цель.

            Георгий Савельев

            Эксперт по бизнес-анализу, член Международного института бизнес-анализа (IIBA), первый CBAP в России. Соавтор BABOK v.3. Вице-президент IIBA Russian Chapter.

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

            Участвовал в реализации более 50 проектов по разработке, внедрению и совершенствованию программного обеспечения.

            С 1990 года занимается проведением тренингов и деловых игр для руководителей и специалистов. Автор статей по бизнес-анализу.

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

            Участник профессиональных ассоциаций IASA, ABPMP Russian Chapter.

            Подписаться на новые статьи

            Источник

            Print Friendly, PDF & Email

            Очень часто при внедрениях от клиента можно услышать фразы типа: «А как этого нет. Это же есть в ….. Я думал, что это само собой понятно. Я без этого не смогу нормально работать. Ваша система …..» Ну и дальше в таком роде. Справедливо ли это? Наверное нет. Каждая система (в данном случае я говорю про ERP) содержит определенный функционал и может в себе не содержать некоторые «фичи» которые есть в других.

            И когда начинается разработка или внедрение клиент должен озвучить все свои «хотелки» иначе существует риск, что что-то не будет реализовано и тогда пиши пропало.

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

            Стадия сбора требований как правило предшествует стадии разработки и внедрения. И именно на ней формируется scope проекта.

            Содержание проекта (Project Scope) Работы, которые необходимо выполнить, чтобы получить продукт, услуги или результат с указанными характеристиками и функциями.

            Что же такое требование? Уровни и типы требований

             Здесь и далее я буду опираться на определения из книги Карла Вигерса и Джоя Битти «Разработка требований к программному обеспечению» 

            Существует много определений данного понятия мы же остановимся на таком:

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

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

            Словарик бизнес-аналитика

            Бизнес-требование — высокоуровневая бизнес-цель организации или заказчиков системы. Оно должно отвечать на вопрос «Что?» и «Зачем?».

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

            Ограничение — ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта.

            Внешнее требование к интерфейсу — описание взаимодействия между ПО и пользователем, другой программной системой или устройством.

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

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

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

            Атрибут качества — вид нефункционального требования, описывающего характеристику сервиса или производительности продукта.

            Системное требование — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования

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

            Требования к ПО состоят из трех уровней:

            • Бизнес-требования;
            • Пользовательские требования;
            • Функциональные требования.

            Вдобавок к этому выделяют еще нефункциональные требования.

            Давайте рассмотрим каждый уровень чуть более детальней.

            Уровни требований

            Сплошные линии означают «содержатся в «, а пунктирные — «являются отправной точкой» или «влияют на»

            Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые она планирует достичь с ее помощью. Как правило их высказывают те, кто финансирует проект. Пример бизнес-требования: «Есть необходимость вести учет взаиморасчетов с контрагентами в разрезе договоров».

            Пользовательские требования (user requirements) описывают цели и задачи, которые пользователь должен иметь возможность выполнять с помощью продукта. Они описывают то, что пользователь должен иметь возможность делать с системой. Это по сути user stories и сценарии. Например: «Я как пользователь системы хочу иметь возможность быстро посмотреть остатки конкретного товара на складе и посмотреть историю его перемещений»

            Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Такие требования описывают в форме традиционных утверждений со словами должен или должна. Например — «система должна в момент проведения в системе документов по взаиморасчетам с контрагентами (инвойс, банковская выписка) дать возможность указать договор по которому ведутся взаиморасчеты» или «система должна давать возможность пользователю выбрать место хранения при закупке товара, куда он будет оприходован» или «должна быть возможность указать в карточке сотрудника дату его рождения и система за 2 дня до его наступления должна высылать директору по персоналу об этом уведомление».

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

            Системные требования (system requirements) описывают требования к продукту, которые содержит многие компоненты или подсистемы (например рабочее место кассира, которое оборудовано сканером считывания штрих-кодов, весами, принтером и т.д.).

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

            Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым»

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

            «API метод должен возвращать список ресторанов в короткой форме: id, название, адрес»

            Это функциональное требование, оно описывает поведение системы.

            «API метод должен отдавать данные не более чем за 200ms на 95 перцентиле и не более чем за 500ms на 99 перцентиле.»

            А это уже нефункциональное требование, которое описывает определённый атрибут качества – performance.

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

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

            Выявление и сбор требований (elecitation)

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

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

            Анализ требований

            Этот этап подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основными действиями на этом этапе будут:

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

            Документирование

            Представление и хранение знаний о требованиях определенным способом. Например в письменные требования, диаграмы пригодные для дальнейшего использования.

            Утверждение требований

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

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

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

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

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

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

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

            Основные проблемы при работе с требованиями

            Выявление требований непростой процесс. Проблему усугубляет то, что заказчик может говорить о чем угодно, но только не о том, что ему действительно нужно. Основное следствие проблем с требованиями — переделка того, что вы думаете что уже готово (на это расходуется от 30 до 50% общего бюджета разработки). С ростом объема переделок растет и растрата ресурсов и разочарования.

            Создание более качественных требований это инвестиции, а не затраты.

            Недостаточное вовлечение пользователей

            Заказчики зачастую не понимают всю важность этапа сбора требований и обеспечения их качества. Это влечет за собой обнаружение ошибок в требованиях на поздних стадиях проекта ну и соответственно к задержке завершения проекта.

            Еще существует риск того, что бизнес-аналитик может не понять и неправильно задокументировать бизнес-требования или потребности клиента. Иногда бизнес-аналитик может идти по пути определения «идеальных» бизнес-требований, которые реализуют разработчики. Но потом этим решением не пользуются.

            Небрежное планирование

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

            «Разрастание» требований пользователей

            В процессе разработки требований scope проекта может разрастаться невиданными темпами и соответственно это увеличивает бюджет проекта и его сроки завершения. Менеджер проекта должен предусмотреть «буферы планирования». Если на проекте применяются гибкие методологии его ведения, то новые требования помещаются в резерв (беклог). Такие изменения могут быть важны, но они всегда имеют свою цену.

            Двусмысленные требования

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

            Требования -«бантики»

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

            Противоречивые требования

            Бывает, что какие-то конкретные два или более требования противоречат друг другу. Иногда “совсем”, что никак нельзя совместить. Иногда всё-таки можно предусмотреть “разные режимы”, в каждом из которых одно требование удовлетворяется, а другое при этом оказывается недоступно. Или решить какую-то из задач другим способом — тогда противоречие исчезнет.

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

            Выводы

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

            Инвестиция в качественный сбор и оформление требований может принести следующие выгоды:

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

            1. Бизнес-требования

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

            1.1 Исходные данные

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

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

            1.2 Возможности бизнеса

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

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

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

            1.3 Бизнес-цели

            Суммирует важные преимущества бизнеса, предоставляемые продуктом, в количественном и измеряемом виде. Банальности («стать компанией мирового класса») и нечетко сформулированные улучшения («обеспечить высокий уровень сервиса для клиентов») нельзя считать ни полезными, ни поддающимися проверке. В табл. 5-1 приведены примеры и финансовых и нефинансовых целей (Wiegers, 2007).

            Табл. 5-1. Примеры финансовых и нефинансовых бизнес-целей

            Финансовые цели Нефинансовые цели
            Освоить X% рынка за Y месяцев Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска продукта
            Увеличить долю рынка в стране W с X% до Y% за Z месяцев Увеличить производительность обработки транзакций на X% и снизить уровень ошибок данных до величины не более Y%
            Достигнуть объема продаж X единиц или дохода в Y долларов за Z месяцев Разработать надежную платформу для семейства связанных продуктов
            Получить X% прибыли по инвестициям в течение Y месяцев Разработать специальную базовую технологическую основу для организации
            Достигнуть положительного потока денежных средств по этому продукту в течение Y месяцев Добиться признания продукта лучшим по на- дежности в опубликованных обзорах продуктов к определенной дате
            Сэкономить X долларов в год, которые в настоящий момент расходуются на обслуживание унаследованной системы Обеспечение выполнения определенных нормативов регулирующих органов
            Уменьшить затраты на поддержку с X до Y долларов за Z месяцев Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единице товара в течение Z месяцев после выпуска продукта
            Увеличить валовую маржу для существующего бизнеса с X до Y% в течение одного года Уменьшить время выполнения заявки до X часов на Y% звонков в службу поддержки

            Организации обычно предпринимают проект для решения задачи или использования имеющейся возможности. Модель бизнес-целей отображает иерархию связанных бизнес-проблем и измеряемых бизнес-целей (Beatty и Chen, 2012). Проблемы описывают, что не позволяет организации достичь требуемых ориентиров в настоящее время, тогда как бизнес-цели определяют способы измерения достижения этих ориентиров. Задачи и цели взаимосвязаны: понимание одной раскрывают суть второй.

            Имея набор бизнес-целей, задайтесь вопросом: «Что мешает нам достичь этот ориентир?», чтобы определить более подробную бизнес-задачу. Или можно вернуться назад, задав вопрос: «Почему нам вообще важен этот ориентир?», чтобы лучше понять бизнес-задачу или возможность верхнего уровня. При наличии бизнес-задачи спросите себя: «Как определить, что задача решена?», чтобы определить измеряемую цель. Процесс выполняется итеративно путем передвижения по иерархии задач и целей, пока не получится список функций, которые позволят решить задачи для достижения целей.

            Разговор между бизнес-аналитиком и куратором, одним из топ-менеджеров компании, с целью определить бизнес-задачи и цели может выглядеть, как показано на рис. 5-4. Это иллюстрация к проекту системы Chemical Tracking System в компании Contoso Pharmaceuticals, описанной в главе 2. На основе ответов топ-менеджера компании бизнес-аналитик может сформулировать бизнес-цели для Chemical Tracking System, как показано на рис. 5-5.

            Рис. 5-4. Пример разговора между аналитиком и куратором проекта

            1.4 Критерии успеха

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

            Рис. 5-5. Пример модели бизнес-целей для системы контроля химикатов

            Бизнес-цели иногда невозможно измерить, пока не завершиться проект. В других случаях достижение бизнес-целей может зависеть от других проектов. Но все равно важно оценить успех конкретного проекта. Критерии успеха указывают, находится ли проект на пути достижения бизнес-целей. Эти критерии могут определяться во время тестирования или сразу после выпуска продукта. Для системы контроля химикатов одним из критериев может быть Бизнес-цель 3 на рис. 5-5:

            «Сократить время заказа химикатов до 10 минут в 80% заказов», потому что среднее время заказа можно измерить во время тестирования или после выпуска. Другой критерий успеха может быть связан с Бизнес-целью 2 с временем, намного более ранним, чем год после выпуска, например: «Отслеживать 60% контейнеров промышленных химикатов и 50% специализированных химикатов через четыре месяца».

            Внимание! Внимательно выбирайте критерии успеха. Убедитесь, что они оценивают то, что важно для бизнеса, а не просто то, что легко оценить. Критерий «Сократить затраты на производство продукта на 20%» легко оценить. Его также легко реализовать путем увольнения сотрудников или сокращения инвестиций в инновации. Но это могут быть не те результаты, которые подразумевались в целях.

            1.5 Положение о концепции

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

            • Для [целевая аудитория покупателей];
            • Который [положение о потребностях или возможностях];
            • Эта (этот) [имя продукта];
            • Является [категория продукта];
            • Который(ая) [основные функции, ключевое преимущество, основная
            • причина [для покупки или использования];
            • В отличие от [основной конкурирующий продукт, текущая система или текущий бизнес-процесс];
            • Наш продукт [положение об основном отличии и преимуществе нового
              продукта].

            Вот как выглядит положение о концепции системы контроля химикатов Chemical Tracking System в Contoso Pharmaceuticals, о которой говорилось в главе 2; ключевые слова выделены полужирным:

            Для ученых, которым нужно запрашивать контейнеры с химикатом, данная система Chemical Tracking System является информационной системой, которая обеспечит единую точку доступа к складу химикатов и к поставщикам. Система будет знать местоположение каждого контейнера с химикатом в компании, количество химиката в контейнерах и полную историю перемещения и использования каждого контейнера. Эта система сэкономит компании 25% затрат на химикаты в первый год работы, позволив полностью использовать уже полученные химикаты, утилизировать меньшее количество частично израсходованных или просроченных химикатов и применять единую стандартную систему приобретения химикатов. В отличие от действующих сейчас ручных механизмов заказов химикатов наш продукт будет генерировать все отчеты, необходимые для регулирующих органов, в которых требуются сведения об использовании, хранении и утилизации химикатов.

            Разработка концепции продукта

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

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

            1.6 Бизнес-риски

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

            1.7 Предположения и зависимости

            Предположение (assumption) — это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного.

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

            Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный документ о концепции и границах. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, то избежите возможной путаницы и ухудшения ситуации в будущем.

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

            Источник

            На чтение 4 мин Просмотров 772 Опубликовано 29.03.2022

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

            Содержание

            1. Что такое BRS (спецификация бизнес-требований)?
            2. Что такое SRS (спецификация требований к программному обеспечению)?
            3. Разница между BRS и SRS

            Что такое BRS (спецификация бизнес-требований)?

            Спецификация бизнес-требований, или BRS, представляет собой документ, в котором описывается, как выполнять бизнес-требования в более широком масштабе. Одним из наиболее общепринятых документов спецификации является документ BRS. Это очень важно, и BRS обычно составляется в начале жизненного цикла продукта, чтобы обозначить ключевые цели продукта или потребности, которые клиент хочет удовлетворить с помощью конкретного программного обеспечения или продуктов. Бизнес-аналитик обычно создает его на основе спецификаций других заинтересованных сторон и после всестороннего изучения организации-клиента. Заказчик обычно просматривает окончательную версию документа, чтобы убедиться, что ожидания всех заинтересованных сторон оправдаются.

            Особенности БРС:

            1. Это список всех требований, которые запросил клиент.
            2. Он включает в себя цель продукта, пользователей, общий объем работ, все упомянутые возможности и функции, а также критерии удобства использования и производительности.
            3. Варианты использования, а также диаграммы и таблицы не включены в этот тип статьи.
            4. Высшее и среднее руководство, инвесторы в продукты и бизнес-аналитики являются основными пользователями BRS.

            Обложки BRS:

            1. Цель проекта.
            2. Особенности и функциональные возможности продукта.
            3. Требования к удобству использования.
            4. Пользователи продукта.
            5. Масштабы проекта.
            6. Требования к производительности.

            Что такое SRS (спецификация требований к программному обеспечению)?

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

            Особенности СРС:

            1. В SRS включены как функциональные, так и нефункциональные критерии, а также варианты использования.
            2. Безупречный документ SRS включает в себя то, как программное обеспечение будет взаимодействовать с другим программным обеспечением или когда оно будет встроено в аппаратное обеспечение, но также учитывает будущих пользователей и то, как они будут взаимодействовать с программным обеспечением.
            3. Он также включает ссылки на таблицы и диаграммы, которые помогут вам понять все особенности продукта.
            4. Документ SRS держит членов команды из всех отделов на одной странице и гарантирует выполнение всех требований.
            5. Этот документ также помогает сократить затраты и время на разработку программного обеспечения.

            Обложки СРС:

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

            Разница между BRS и SRS

            S № SRS (спецификации системных требований) BRS (спецификации бизнес-требований)
            1. Спецификация требований к программному обеспечению дает высокоуровневое описание функциональных и технических требований к программному обеспечению. Спецификация бизнес-требований дает высокоуровневое описание функциональных требований к программному обеспечению.
            2. Документ СГД получен из БРС. Документ BRS получается в соответствии с требованиями клиента.
            3. Системный аналитик — это тот, кто его создал. Он также известен как Спецификации требований пользователя. Бизнес-аналитики всегда его создают.
            4. Документ SRS описывает пошаговую последовательность всех рабочих характеристик для каждого модуля и подмодулей. Документ BRS включает в себя то, что именно хочет клиент. и команда следит за документом от начала до конца.
            5. SRS охватывает все функциональные и нефункциональные требования. BRS охватывает все типы требований.
            6. Отчет о подключениях пользователей готовится в SRS. BRS определяет, как клиенты взаимодействуют с системой с помощью вариантов использования.
            7. Это официальный документ, в котором подробно изложены требования клиента (письменно, устно). Нетехническое выражение используется для описания требований клиента.
            8. Документ BRS охватывал будущие возможности продукта, а также стратегии развития организации. Объем продукта не указан в документе SRS.
            9. Документ BRS может содержать или не содержать ссылки на рисунки и таблицы. Документ SRS всегда содержит ссылки на рисунки и таблицы.
            10. В документе SRS никого со стороны клиента не указано. В документе BRS перечислены пользовательская база и аналогичные заинтересованные стороны со стороны клиента.

            Источник

            Contents

            • 1 Сбор требований
            • 2 Выжимка по процессу формирования требований
              • 2.1 Схема процесса разработки с уровнями требований
              • 2.2 Формирование и анализ требований
              • 2.3 Аттестация требований
              • 2.4 Подготовка к интервью по сбору требований у заказчика
            • 3 Классификация и описание требований на пути от бизнеса к технической реализации
              • 3.1 Компания — Бизнес-требования
              • 3.2 Заказчик — Документ требований заинтересованных лиц
              • 3.3 Пользователь — Требования пользователя
                • 3.3.1 Проблемы при формировании пользовательских требований
              • 3.4 Системные требования
              • 3.5 Функциональные требования
              • 3.6 Нефункциональных требований
              • 3.7 Требования предметной области
              • 3.8 Требования к продукту
              • 3.9 Организационные требования
              • 3.10 Требования к интеграции
                • 3.10.1 Интеграция через ESB
                • 3.10.2 Интеграция точка-точка
                • 3.10.3 Интеграция данных
              • 3.11 Требования к пользовательскому интерфейсу
            • 4 Управление требованиями
              • 4.1 Классификация изменяемых требований
              • 4.2 Процесс управления изменениями
            • 5 Кто читает документацию
            • 6 Как правильно сформулировать и контролировать цель проекта?
            • 7 Документы процесса разработки и управления требованиями (по Вигерсу)
              • 7.1 Документы процесса разработки требований
              • 7.2 Документы процесса управления требованиями
              • 7.3 Пример дорожной карты совершенствования процессов работы с требованиями
            • 8 Документ по управлению требованиями

            Бизнес-анализ — это структурированное изучение проблемы, имеющей отношение к бизнесу. Бизнес-анализ проводится, чтобы лучше понять проблему, а затем оценить, что требуется для ее устранения.
            Бизнес-кейс/коммерческое предложение. Коммерческая цель или выгода является причиной выполнения проекта и может официально фиксироваться в документе, называющемся бизнес-кейсом, или коммерческим предложением. Этот документ обычно включает финансовые показатели (например, прирост выручки, снижение издержек и т.п.) или другие параметры (например, повышение уровня обслуживания потребителей, повышение мотивированности персонала и т.д.).

            Сбор требований

            Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
            Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
            Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:

            • обязательными, т.е. без них проект будет считаться незавершенным, а заказчик останется неудовлетворенным. Если готовый продукт не соответствует всем обязательным требованиям, это — провал;
            • желательными. Эти требования не обязательны, но важны для заказчика, поэтому их стараются соблюдать, за исключением тех случаев, когда они влекут за собой неприемлемое увеличение стоимости или продолжительности проекта;
            • необязательными — это те требования, без которых заказчик вполне может обойтись и которые удовлетворяются только по возможности.

            Выжимка по процессу формирования требований

            Функциональные требования — это требования к системе.
            Бизнес-требования — эквивалентно бизнес-целям.
            Между ними — Пользовательские требования, User Requirements.
            Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.

            Бизнес-процессы — самое начало работы.
            Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
            1. Бизнес-моделирование
            2. Выявление требований
            3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
            4. Реализация
            5. Тестирование
            6. Опытно-промышленная эксплуатация
            7. Support и развитие системы

            Совсем упрощенно:
            1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
            2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
            3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
            4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

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

            Например:
            «Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

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

            Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

            Важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.

            Схема процесса разработки с уровнями требований

            requirement_management

            Формирование и анализ требований

            Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
            Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
            Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
            Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.
            Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
            Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

            Аттестация требований

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

            Подготовка к интервью по сбору требований у заказчика

            interview_requirements

            Классификация и описание требований на пути от бизнеса к технической реализации

            Компания — Бизнес-требования

            Источники: Топ-менеджмент компании
            Документ: Бизнес-требования (обоснование потребностей инициативы)
            Ответственный: Менеджер проекта

            Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:

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

            Контекст — это то, что стало причиной создания системы, какая ситуация была в компании, какая проблема и как пришли к тому, что систему надо делать.

            Заказчик — Документ требований заинтересованных лиц

            Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

            • Бизнес-назначение
            • Бизнес-рамки
            • Обзор бизнеса
            • Заинтересованные лица
            • Организационная среда
            • Цели и результаты
            • Бизнес-модель
            • Информационная среда
            • Бизнес-процессы
            • Политики и правила
            • Ограничения деятельности
            • Организационная структура
            • Концепция использования системы
            • Сценарии эксплуатации
            • Проектные ограничения

            Пользователь — Требования пользователя

            Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
            Источники: Пользователь
            Документ: Пользовательские требования/Требования к ПО
            Ответственный: Системный аналитик

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

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

            Отсутствие чёткости изложения. Иногда нелегко изложить какую-либо мысль естественным языком чётко и недвусмысленно, не сделав при этом текст многословным и трудно читаемым.
            Смешение требований. В пользовательских требованиях отсутствует чёткое разделение на функциональные требования, на системные цели и проектную информацию.
            Объединение требований. Несколько различных требований к системе могут описываться как единое пользовательское требование.

            Системные требования

            Системные требования описывают свойства и методы всех объектов системы. Программирование – это разработка и реализация структур данных и алгоритмов. Для разработки системы программисту необходимо знать структуры данных, необходимые для реализации системы, и алгоритмы (бизнес-правила/процедуры/пакеты обработки данных), которые ими манипулируют. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО.
            Системные требования — это более детализированное описание пользовательских требований.
            Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы. Спецификация требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.

            Функциональные требования

            Функциональные требования — это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

            Стандартные формы для специфицирования функциональных требований:

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

            Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

            Нефункциональных требований

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

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

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

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

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

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

            Требования к продукту

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

            Организационные требования

            Организационные требования отображают политику и организационные процедуры заказчика и разработчика ПО. Включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.

            Требования к интеграции

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

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

            Интеграция через ESB

            Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
            Основными функциями ESB являются:

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

            Интеграция точка-точка

            Интеграция приложений напрямую, является методом интеграции, при котором взаимодействие между системами происходит без применения универсального централизованного посредника, такого, как сервисная шина предприятия (ESB).

            Интеграция данных

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

            Задачи интеграции данных:

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

            Интеграция ETL
            Интеграция ETL характеризуется следующим сценарием:
            На платформе ETL пишется процесс, который
            1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
            2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
            3) Загружает данные в таблицы БД 2й системы.

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

            Требования к пользовательскому интерфейсу

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

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

            К первой группе можно отнести следующие типы требований:

            • Требования к размещению элементов управления на экранных формах
            • Требования к содержанию и оформлению выводимых сообщений
            • Требования к форматам ввода

            Ко второй группе относятся следующие типы требований:

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

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

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

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

            Классификация изменяемых требований

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

            Процесс управления изменениями

            Анализ проблем изменения спецификации. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определённые предложения относительно изменений в требованиях.
            Анализ осуществимости и расчёт их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.
            Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде.

            Кто читает документацию

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

            Как правильно сформулировать и контролировать цель проекта?

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

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

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

            Если вы выбрали реалистичные KPI для своих целей, но не видите признаков прогресса по истечении разумного времени, нужно провести расследование:

            • Правильно ли были проанализированы проблемы и выявлены их первопричины?
            • Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
            • Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
            • Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
            • Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
            • Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?

            Документы процесса разработки и управления требованиями (по Вигерсу)

            Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
            Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.requirements_management_process_documents

            Документы процесса разработки требований

            • Процесс разработки требований описывает, как определить и классифицировать заинтересованных в проекте лиц в предметной области, а также как планировать действия по выявлению требований. Кроме того, здесь перечислены различные документы, касающиеся требований, модели, которые, как ожидается, будут созданы при выполнении проекта. Процесс разработки требований также определяет особенности анализа и проверки требований.
            • Процедура назначения требований описывает, как назначать высокоуровневые требованиям к продукту конкретным подсистемам при разработке систем, состоящих из программных и аппаратных компонентов или множественных программных подсистем.
            • Процедура назначения приоритетов требований описывает приемы и инструменты, используемые для определения приоритетов требований и динамической корректировки содержимого резерва в проекте.
            • Шаблон документа о концепции и границах проекта помогает куратору проекта и бизнес-аналитику осмысливать бизнес-цели, метрики успех, концепцию продукта и другие элементы бизнес-требований.
            • Шаблон вариантов использования задает стандартный формат для описания задач, которые пользователям необходимо выполнять с помощью программы.
            • Шаблон спецификации требований к ПО представляет собой структурированный, последовательный способ организации функциональных и нефункциональных требований. Подумайте о возможности применения более чем одного шаблона, чтобы учесть различные типы и масштабы проектов, выполняемые вашей организацией.
            • Контрольный список рецензирования требований. Официальное рецензирование документов, содержащих требования, — мощное средство повышения качества ПО. В списке рецензирования описано много типичных ошибок, присутствующих в документах требований, что позволяет рецензенту сосредоточиться на стандартных проблемных областях.

            Документы процесса управления требованиями

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

            Пример дорожной карты совершенствования процессов работы с требованиями

            roadmap_process_improvement_work_requirements

            Документ по управлению требованиями

            4.9
            9
            Голоса

            Рейтинг статьи

            Источник

            Вывод: чем конкретнее требование, тем лучше.

            Теперь давайте подробно разберемся с каждым из этих требований, начиная с уровня Atomic.

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

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

            Однозначно идентифицировано
            Точно так же следующее требование к качеству – это проверка на однозначную идентификацию, здесь у нас есть два отдельных требования, но у них обоих одинаковый ID # 1. Итак, если мы ссылаемся на наше требование со ссылкой на ID #, но неясно, на какое именно требование мы ссылаемся, поскольку оба имеют одинаковый ID # 1. Таким образом, зачисления на курс за счет выделение с помощью уникальных идентификаторов должно иметь два требования: 1.1 id – это зачисление на курсы бакалавриата, а 1.2 id – зачисление на курсы последипломного образования.

            Полный
            Все требования должны быть выполнены в полном объеме. Например, здесь неверное требование гласит, что «профессор-пользователь войдет в систему, указав свое имя пользователя, пароль и другую соответствующую информацию». Здесь другая важная информация не ясна, поэтому другая важная информация должна быть изложена в хорошем требовании, чтобы сделать требование полным.

            Последовательный и однозначный
            Далее, каждое требование должно быть последовательным и недвусмысленным, поэтому здесь, например, у нас есть требования: «У студента будут либо курсы бакалавриата, либо курсы последипломного образования, но не оба сразу». Это одно требование, но есть еще одно требование, которое гласит: «Некоторые курсы будут быть открытыми как для студентов, так и для аспирантов».

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

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

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

            Теперь, когда мы преобразуем бизнес-требования в требования к архитектуре и дизайну или преобразуем требования к архитектуре и дизайну в требования системной интеграции, необходима прослеживаемость. Это означает, что мы должны быть в состоянии взять все бизнес-требования и сопоставить их с одним или несколькими требованиями к архитектуре и дизайну программного обеспечения. Итак, вот пример неверного требования, в котором говорится: «Сохранять информацию о студенте — сопоставлена с идентификатором требования BRD?». Пример идентификатора требования здесь не приводится.

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

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

            Приоритет

            Источник

            Понравилась статья? Поделить с друзьями:
          1. Бизнес план ремонт телефонов планшетов ноутбуков
          2. Бизнес факультеты в москве государственных вузов
          3. Бизнес план репетитора английского языка образец
          4. Бизнес центр stone савеловская стоун савеловская
          5. Бизнес план репетитора для социального контракта