В функциональных требованиях описываем требования к бизнес-функциям. Нужно выделить бизнес-функции и по каждой бизнес-функции описать, как ее обрабатывает система.
Или нужно выделить бизнес-объекты, описать их атрибуты, функции и состояния
Сценарии вариантов использования
Основное в функциональных требованиях. Когда пишем функциональные требования в виде сценариев вариантов использования?
Диаграммы состояний объектов
Если в Системе используются объекты, которые изменяют свое состояние в процессе жизненного цикла, для каждого такого объекта в ТЗ должна быть указана Диаграмма состояния, которая сопровождается условиями (событиями) перехода объекта из одного состояние в другое.
Сверка выполненных операций (частный случай)
Если между системами разных организаций совершается обмен операций, и результат обмена связан с финансовыми операциями, необходимо проводить сверку операций проведенных за период. В качестве даты следует использовать «дату операции», которая должна указываться в операции обмена.
4. Функциональные требования, тикеты, JIRA (Курс бизнес-аналитик с нуля)
Учет часовых поясов
Для систем, которые работают в разных часовых поясах.
История про начислени бонуса
Абонент совершил платеж. Система начисления бонусов прислала уведомление, что если он совершит еще платёж на 700 рублей, то ему автоматом начистится бонус в 700, причем акция действительна до конца месяца. А был уже поздний вечер 31 октября. Абонент побежал к терминалу и совершил платеж на 700 рублей. Успел, на часах было 22:00.
Но ВПС, через которую оплатил абонент, некорректно проставляла часовые пояса. После приведения времени ВПС к московскому, оказалось, что время платежа 01:00 следующего месяца, и акция уже не действует. Абонент, соответственно, обратился с жалобой в клиентскую службу оператора.
Групповые операции
Есть сообщение о платеже и его обработка в ПЦ и есть сообщение, в котором указано несколько платежей — пакет платежей.
Есть сообщение на отмену платежа и есть пакет платежей на отмену.
Группировка типовых операций в пакет. К пакету добавляется заголовок, который может содержать данные по элементам (их количество, сумма платежей элементов, период с, период по и т.п.).
Как должен обрабатываться пакет? Обработано все или ничего или допускаем частичную обработку элементов?
Какие дополнительные статусы у пакета по сравнению со статусами элемента пакета? Появляется статус частично обработан?
В групповой операции можно разделять запросы на выполнение операции и, если они корректны (проходят входной контроль), сформированные на их основе команды на выполнение операции.
Когда формировать ответ: при обработке заголовка или при обработке всего сообщения (включая тело)? Когда отпускать Клиента?
Источник: www.sites.google.com
Функциональные и нефункциональные требования
Требования к программной системе часто классифицируются как:
Что такое функциональные требования ? Четкая постановка задач разработчику
Функциональные требования – это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
Нефункциональные требования описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Требования предметной области характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не функциональными.
Нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надёжность, время ответа или размер системы. Кроме того, нефункциональные требования могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе.
Многие функциональные требования относятся к системе в целом, а не к отдельным её средствам. Это означает, что они более значимы и критичны, чем отдельные функциональные требования. Ошибка, допущенная в функциональном требовании, может снизить качество системы, ошибка в нефункциональных требованиях может сделать систему неработоспособной.
Вместе с тем нефункциональные требования могут относиться не только к самой программной системе: одни могут относиться к технологическому процессу создания ПО, другие – содержать перечень стандартов качества, накладываемых на процесс разработки.
Нефункциональные требования отображают пользовательские требования: при этом они основываются на бюджетных ограничениях, учитывают организационные возможности компании-разработчика и возможность взаимодействия разрабатываемой системы с другими программными и вычислительными системами, а также такие внешние факторы, как правила техники безопасности, законодательство о защите интеллектуальной собственности и т.п.
Все нефункциональные требования делятся на три большие группы:
Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся требования к производительности системы, объёму необходимой памяти, надёжности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации.
Организационные требования. Отображают политику и организационные процедуры заказчика и разработчика ПО. Они включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.
Внешние требования. Учитывают факторы, внешние по отношению к разрабатываемой системе и процессу её разработки. Они включают требования, определяющие взаимодействие данной системы с другими системами, юридические требования, следование которым гарантирует, что система будет разрабатываться и функционировать в рамках существующего законодательства, а также этические требования. Последние должны гарантировать, что система будет приемлемой для пользователей или заказчика.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Проверка и контроль требований в бизнес-анализе. Часть 4
Данная статья – продолжение нашей большой статьи по бизнес-анализу. Чтобы читать сначала, пожалуйста, перейдите по этой ссылке.
Способы проверки требований заинтересованных сторон
Проверка требований, собранных от заинтересованных сторон, необходима для успешного обеспечения ожидаемых результатов, соответствующих потребностям. Процесс валидации и верификации должен выполняться на различных этапах жизненного цикла проекта. Бизнес-аналитик всегда должен заранее решить, кому и как следует подтверждать требования.
Бизнес-аналитики, собирающие требования от заинтересованных сторон, достаточно близки к пониманию контекста бизнеса и пониманию движущих сил и потребностей организации. Процесс проверки может включать в себя регулярные встречи с несколькими экспертами, на которых рассматриваются и обсуждаются требования, чтобы, в конечном счете, получить одобрение требований от заказчика и спонсора.
Вы можете начать процесс проверки на ранних этапах, когда вы повторно проговариваете или повторяете требование, обращаясь к заинтересованной стороне, чтобы получить разъяснения, правильно ли вы зафиксировали требование. Это можно сделать несколькими способами:
- Перефразирование, когда вы воспроизводите услышанное в ответ, а заинтересованное лицо проверяет сказанное.
- Фиксация требований в письменном виде и отправка их заинтересованной стороне для проверки и правок.
- Получение согласия от заинтересованной стороны и, возможно, от их начальства.
Требования фиксируются и затем классифицируются на бизнес-требования, пользовательские требования, функциональные и нефункциональные требования и, наконец, переходные требования. Это называется структурой декомпозиции требований, и она фиксирует, как требования низкого уровня согласовываются с требованиями бизнеса и заинтересованных сторон. Это также гарантирует, что сложности в требованиях будут идентифицированы и разъяснены в контексте всего объема проекта .
Следующим этапом является определение приоритета требований и того, как они наилучшим образом соответствуют достижению целей проекта, ожидаемым результатам, решению заявленных вопросов и проблем или реализации новых возможностей. Эти требования затем можно разделить на три категории: обязательные, важные или желательные. Разделение требований на эти три категории поможет вам определить, какие из них наиболее важные.
Заключительный этап процесса проверки – убедиться, что требования проходят тест SMART. Являются ли они конкретными, измеримыми, достижимыми, реалистичными и отслеживаемыми, и написаны ли они на языке, который будет понятен каждому?
Убедитесь, что собранные требования совпадают с первоначальными целями проекта, анализируя каждый элемент и учитывая приоритетность вашего проекта в портфеле проектов, уделяя особое внимание взаимодействию или конфликтам между потребностями бизнеса и пользователями и, наконец, анализируя любые несвязанные задачи, запросы об их истинной мотивации.
Неспособность уловить суть и специфику каких-либо требований по отдельности может не оказать серьезного воздействия. Хотя, когда эти требования объединены, проверены и согласованы, они представляют истинные потребности проекта. Только после этого пакет требований готов для окончательного утверждения спонсором и заказчиком.
Методы проверки соблюдения требований
Как показывает практика, если бизнес-аналитик использует один метод проверки требований, то, чаще всего, это приводит к провалу проекта. Чем более конкретный и измеримый список требований, тем больше шансов удовлетворить запросы заинтересованных сторон, клиентов и спонсоров после завершения проекта .
Во-первых, у вас есть два метода, связанных с подходами к проверке документации: экспертная проверка и формальная проверка. Методика экспертной оценки – менее формальный подход.
Начните с определения квалифицированного кадра, кого-то, кто не участвовал в сборе требований, чтобы прокомментировать свое понимание того, что требования пытаются передать. Он делает это, просто обводя слова, которые не имеют смысла или требуют пояснения.
Затем он возвращает список бизнес-аналитику для исправлений, где уже заинтересованная сторона совершенствует требования для лучшего его понимания. На самом деле цель здесь – выявить улучшения, а не строгое подтверждение. Методика формальной проверки завершается после того, как пакет требований прошел проверку и первый раунд экспертной оценки.
Формальная проверка – это дисциплинированный подход, включающий экспертов в предметной области, модератора, делопроизводителей и сборщиков требований. Эти люди необходимы, поскольку вы, абзац за абзацем, просматриваете всю документацию, подтверждая, что каждое требование будет достигать цели проекта, имеет определенные критерии выхода, и что документ готов к переходу, к следующему методу: фиксации критериев приемки.
Критерии приемки – это методика определения «Готовы ли мы?» и «Как мы это узнаем?». Чем более конкретные требования предъявляются, тем больше возможностей для предварительного определения измеримых критериев успеха.
Применение метода критериев приемки допустимо, когда:
- критерии завершения связаны с бизнес-требованиями высокого уровня;
- требования поддаются количественной оценке, и они ясны;
- матрица отслеживания была применена в отношении того, кто и когда запросил требование;
- у вас есть критерии завершения, подписанные спонсором и клиентами.
Выполняя эти неформальные и формальные проверки, убедитесь, что у вас есть процесс для управления выводами проверки, такими как запросы на изменение и управление проблемами. Цель здесь состоит в том, чтобы пакет требований был задокументирован, проверен с заранее определенными критериями успеха и подписан как спонсором, так и заказчиком.
Виды документации, которые необходимо подготовить перед проектом
Правильная документация позволяет людям правильно и эффективно выполнять свою работу. С другой стороны, отсутствие документации или плохо написанная документация, могут нанести ущерб бизнес-подразделению.
Начнем с руководства по процедурам. Его цель – объяснить, как процесс должен функционировать. Кто что делает, когда, в какой последовательности и в соответствии с руководящими стандартами? Данное руководство становится единственным источником истины о том, как новые процессы принесут текущие выгоды и результаты.
Руководства по процедурам должны быть удобными для чтения, с большим количеством пробелов, содержать детали, но не быть сложными, использовать комбинацию текста и диаграмм и предоставлять полную информацию для данной процедуры.
При написании или обновлении руководства по процедурам обращайтесь к исходным требованиям, чтобы обеспечить соответствие цели решения. Но имейте в виду, что в автономном режиме могут происходить очень важные процессы, которые необходимо идентифицировать и задокументировать.
Вероятно, вам потребуется провести семинары с ключевыми заинтересованными сторонами, чтобы получить необходимую информацию для заполнения руководства по процедурам. Оно, как правило, более подробное по сравнению с любой другой документацией. С учетом сказанного вам нужно написать его в общих чертах, чтобы руководство можно было использовать для всех предполагаемых пользователей.
Еще один ключевой комплект документации, который необходимо подготовить – это учебные материалы. Учебные материалы обычно фокусируют то, как пользователь будет взаимодействовать с новым продуктом. Однако учебные материалы также потребуются для новых бизнес-процессов или поддержки внедрения нового продукта проекта.
Важно то, как организованы материалы, поскольку вы хотите, чтобы пользователь мог быстро усвоить представленную информацию. Учебные материалы должны быть основаны на требованиях. Их необходимо проверить на предмет содержания, точности и ясности инструкций.
Учебные материалы должны быть удобными для чтения с большим количеством пробелов, включать, возможно, несколько демонстраций или образцы результатов, предоставлять достаточно деталей и контекста, использовать комбинацию текста и диаграмм с конкретными примерами и, наконец, подробно описывать источники дополнительной поддержки.
Как бизнес-аналитик, вы играете ключевую роль в создании переходного материала от проектной группы, владеющей продуктом, к бизнесу. Созданная вами документация позволяет бизнесу взять на себя ответственность за будущие продукты проекта.
Критерии приемлемости в бизнес-анализе
Критерии приемлемости – это как финишная черта вашего проекта . Они определяют момент, когда вы можете заявить об успехе и работать над тем, чтобы бизнес полностью использовал продукты вашего проекта. Конечно, это должно быть сделано в рамках определенных ограничений в финансировании и ресурсах.
Ваши критерии приемлемости должны быть разработаны совместно с вашими ключевыми заинтересованными сторонами. И они должны быть конкретными, чтобы вы могли четко определить, когда вы достигли бизнес-целей. Кроме того, критерии приемлемости также имеют следующие характеристики:
Во-первых, они отражают конкретные бизнес-результаты, определенные на ранней стадии проекта. Надежные критерии приемлемости являются частью матрицы отслеживания, которую мы обсуждали в предыдущей статье. Их можно отследить от первоначального желаемого результата через требования до того, как они будут протестированы. Критерии приемлемости определяют фиксированную финишную черту, которую все должны видеть и стремиться к ней.
Во-вторых, критерии приемлемости отражают желания и ожидания ваших заинтересованных сторон. Как бизнес-аналитик, вы должны находиться в постоянном контакте с ключевыми заинтересованными сторонами, сообщая о прогрессе в достижении результатов проекта. Критерии приемлемости могут быть составлены заранее, но их следует постоянно пересматривать и уточнять по мере продвижения проекта.
В-третьих, критерии приемлемости устанавливают или усиливают приоритеты проекта. Большинство проектов предназначены для достижения нескольких бизнес-результатов, однако на самом деле они все являются приоритетными. Поэтому данные критерии уравновешивают несколько целей проекта и помогают проектной команде создавать процессы и инструменты, которые соответствуют целостным целям всех ваших заинтересованных сторон и спонсора.
В-четвертых, критерии приемлемости включают особенности того, как они будут измеряться. Делать предположение, что все заинтересованные стороны будут применять один и тот же подход к измерению – очень опасно. Ваши критерии приемлемости должны включать точные процессы, с помощью которых будет измеряться успех: какие бизнес-процессы будут измеряться, какая единица измерения будет использоваться, и какая конкретная цель должна быть достигнута.
Помните, что критерии приемлемости могут меняться по мере изменения бизнес-стратегии. Поэтому в более длительных проектах не забывайте периодически проверять критерии приемлемости. Таким образом, вы всегда будете на правильном пути и будете приближаться к финишной черте.
Для продолжения чтения, перейдите, пожалуйста, на статью «Оценка результатов проекта в бизнес-анализе. Часть 5»
Источник: www.your-mentor.ru