Очень часто при внедрениях от клиента можно услышать фразы типа: «А как этого нет. Это же есть в ….. Я думал, что это само собой понятно. Я без этого не смогу нормально работать. Ваша система …..» Ну и дальше в таком роде. Справедливо ли это?
Наверное нет. Каждая система (в данном случае я говорю про ERP) содержит определенный функционал и может в себе не содержать некоторые «фичи» которые есть в других.
И когда начинается разработка или внедрение клиент должен озвучить все свои «хотелки» иначе существует риск, что что-то не будет реализовано и тогда пиши пропало.
Часть вины за это конечно лежит и на компании которая занимается разработкой или внедрением. Бизнес-аналитик (это человек который занимается сбором и обработкой требований) должен уметь задавать правильные вопросы и читать между строк. Клиент может и не сможет четко описать что он хочет и может ходить вокруг и около того, что ему действительно необходимо.
Стадия сбора требований как правило предшествует стадии разработки и внедрения. И именно на ней формируется scope проекта.
Анализ требований 6. Бизнес-объекты. Бизнес требования. Функциональные требования.
Содержание проекта (Project Scope) Работы, которые необходимо выполнить, чтобы получить продукт, услуги или результат с указанными характеристиками и функциями.
Содержание
1 Что же такое требование? Уровни и типы требований
2 Разработка и управление требованиями2.1 Выявление и сбор требований (elecitation)
2.2 Анализ требований
2.4 Утверждение требований
2.5 Управление требованиями
3 Основные проблемы при работе с требованиями3.1 Недостаточное вовлечение пользователей
3.2 Небрежное планирование
3.3 «Разрастание» требований пользователей
3.4 Двусмысленные требования
3.5 Требования -«бантики»
3.6 Противоречивые требования
Что же такое требование? Уровни и типы требований
Здесь и далее я буду опираться на определения из книги Карла Вигерса и Джоя Битти «Разработка требований к программному обеспечению»
Существует много определений данного понятия мы же остановимся на таком:
Требование — спецификация того, что должно быть реализовано. В них описано поведение системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы.
И давайте дадим определения терминов которые используються при классификации требований.
Словарик бизнес-аналитика
Бизнес-требование — высокоуровневая бизнес-цель организации или заказчиков системы. Оно должно отвечать на вопрос «Что?» и «Зачем?».
Бизнес-правило — политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. Это не требование к ПО, но оно служит источником нескольких типов требований к ПО.
Ограничение — ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта.
Внешнее требование к интерфейсу— описание взаимодействия между ПО и пользователем, другой программной системой или устройством.
Что такое функциональные требования ? Четкая постановка задач разработчику
Характеристика — одна или несколько логически связанных возможностей системы, которая представляет собой ценность для пользователя и описаны рядом функциональных требований.
Функциональное требование — описание требуемого поведения системы в определенных условиях.
Нефункциональное требование — описание свойства или особенности, которыми должна обладать система, или ограничение, которое должно соблюдаться.
Атрибут качества — вид нефункционального требования, описывающего характеристику сервиса или производительности продукта.
Системное требование — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
Пользовательское требование — задача, которую определенные классы пользователей должны иметь возможность выполнять в системе, или требуемый атрибут продукта.
Требования к ПО состоят из трех уровней:
- Бизнес-требования;
- Пользовательские требования;
- Функциональные требования.
Вдобавок к этому выделяют еще нефункциональные требования.
Давайте рассмотрим каждый уровень чуть более детальней.
Бизнес-требования (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 проекта и возникают постоянные переработки, то кому от этого будет хорошо даже если за весь этот банкет платит заказчик. Та что тут говорить, если во многих компаниях даже нет такой позиции как бизнес-аналитик, его роль совмещает в себе проджект менеджер или разработчик.
Инвестиция в качественный сбор и оформление требований может принести следующие выгоды:
- меньше деффектов в требованиях и в готовом продукте;
- меньше ненужных функций;
- меньше расползания границ проекта;
- меньше беспорядка;
- продукты которые делаю то, что нужно.
Источник: biconsult.ru
4.5. Функциональные и нефункциональные требования (Functional and Non-functional Requirements)
Требования к программной системе часто классифицируются как функциональные, нефункциональные и требования предметной области. Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.
- Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
- Нефункциональные требования. Описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и тд.
- Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.
В действительности четкой границы между этими типами требований не существует. Например, пользовательские требования, касающиеся безопасности системы, можно отнести к нефункциональным. Однако при более детальном рассмотрении такое требование можно отнести к функциональным, поскольку оно порождает необходимость включения в систему средства авторизации пользователя. Поэтому, рассматривая далее эти виды требований, мы должны всегда помнить, что данная классификация в значительной степени искусственна. Классический пример (см. рисунок 4.3) высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса. Рисунок 4.3. Уровни требований по Вигерсу
- Группа функциональных требований
- Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.
- Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).
- Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net
Определение функциональных требований на основе моделей бизнес-процесса
Под требованием будем понимать условия или возможности, которым должна удовлетворять система, характеристики АС, необходимые пользователю для удовлетворения своих потребностей или достижения своих целей.
Функциональные требованияк системе определяют, действия системы, которые она должна выполнять. Функциональные требования реализуются через функции системы.
Функция АС это процесс или деятельность, которую выполняет система, подсистема, модуль/компонент.
Выявление функциональных требований на основе описания бизнес-процессов проводится следующим образом [2]. Каждому бизнес-процессу ставится в соответствие подсистема в разрабатываемой системе, каждому шагу бизнес-процесса — функциональное требование. На рис. 3.8. представлен состав бизнес-процессов, а на рис. 3.13 – поток работ процесса «Зачисление студентов в университет».
Как видно из рис. 3.8, автоматизируемыми процессами являются: зачисление студента, перевод студента, отчисление студента, проведение сессии, подготовка отчетов. Как видно из рис. 3.13, шагами бизнес-процесса зачисления студента в университет, подлежащими автоматизации (выделены цветом) являются: формирование списков групп, заполнение личной карточки студента, регистрация выдачи зачётной книжки в журнале.
На основе состава и шагов бизнес-процесса, подлежащих автоматизации, строится матрица трассировки (табл. 3.4, 3.5).
Зависимость подсистем от бизнес-процессов
| № | Бизнес-процесс | Подсистема |
| Зачисление студента | Зачисление студента | |
| Перевод студента | Перевод студента | |
| Отчисление студента | Отчисление студента | |
| Подготовка отчётов | Подготовка отчётов | |
| Проведение сессии | Проведение сессии | |
| Ведение справочников | Ведение справочников | |
| Администрирование системы | Администрирование системы |
: Зависимость функций подсистемы «Зачисление студента» от шагов бизнес-процесса
«Зачисление студента»
| № | Шаг бизнес-процесса | Требование к функции | Функция системы | ТПР по функциям |
| Формирование списков групп | Формирование списков групп | Печать списка групп, отображение списка групп на экране, экспорт списка групп в Excel | Формирование отчётов | |
| Заполнение личной карточки студента | Ведение личных карточек студентов | Добавление личной карточки студента, удаление личной карточки студента, поиск личной карточки студента, печать списка личных карточек студента, редактирование личной карточки студента | Ведение журналов | |
| Регистрация выдачи зачётной книжки | Ведение журнала регистрации выдачи зачетной книжки | Добавление записи в журнал, удаление записи, поиск записи, печать списка записей, редактирование записи | Ведение журналов |
Матрица трассировки позволяет проследить связи бизнес-процессов с реализующими их подсистемами и конкретных шагов бизнес-процессов с функциональными требованиями, а также контролировать полноту и целостность реализации: каждому автоматизируемому бизнес-процессу должна быть поставлена в соответствие подсистема (подсистемы), а подсистема должна реализовывать какой-либо процесс, соответственно.
В матрицах трассировки также следует отображать связи функциональных требований с функциями системы и типовыми проектными решениями (ТПР), используемыми при их реализации.
Где под ТПР понимается [3] комплект технической документации, содержащий проектные решения по части объекта проектирования, включая программные средства и предназначенный для многократного применения в процессе разработки, внедрения и функционирования АСУ с целью уменьшения трудоемкости разработки, сроков и затрат на создание АСУ и ее частей.
Функции и типовые решения определяются архитектором системы на основе функциональных требований и собственного опыта разработки.
Задания для самоконтроля
Тест 3.1. Состав бизнес-процессов
Выбор из одного
| Какова цель использования модели бизнес процессов при создании АС? | модель используется для реорганизации бизнес процессов |
| модель используется для определения подсистем системы | |
| модель используется для документирования целей и процессов организации |
Выбор из одного
| Какая диаграмма используется для построения модели бизнес процессов? | диаграмма функций |
| диаграмма классов | |
| диаграмма деятельности | |
| диаграмма последовательности действий |
Выбор из одного
| Какие элементы диаграммы функций используются для разработки модели бизнес-процессов? | · Бизнес-процесс, · Бизнес- роль. |
| · пакет; · бизнес процесс; · бизнес- роль. | |
| · пакет; · бизнес-процесс; · бизнес- роль; · цель бизнеса; · связи между элементами |
Выбор из одного
| Какие стереотипы связей используются между бизнес процессами ? | · включает; · использует; · наследует; · поддерживает |
| · включает; · расширяет; · наследует; · родитель-потомок | |
| · включает; · расширяет; · родитель-потомок |
Выбор из одного
| Какие стереотипы связей могут использоваться между бизнес- процессами и бизнес-ролью ? | · включает; · использует; · наследует; · поддерживает |
| · взаимодействует; · стереотип, определенный пользователем | |
| · включает; · расширяет; · поддерживает |
Выбор из одного
| Какие стереотипы связей используются между бизнес- процессами и целями, которые он поддерживает? | · включает; · использует; · наследует. |
| · поддерживает; · расширяет. | |
| · поддерживает |
Выбор из одного
| В каких ситуациях используется связь между бизнес процессами со стереотипом > ? | когда один процесс является общим для других процессов |
| когда один процесс является частью другого процесса | |
| когда разные бизнес процессы включает в себя один и тот же бизнес процесс |
Выбор из одного
| В каких ситуациях используется связь между бизнес-процессами со стереотипом > ? | когда один процесс является общим для других процессов |
| при отображении бизнес процессов, которые должны выполняться в исключительных ситуациях или при наступлении определенных условий | |
| когда один процесс наследует свойства другого процесс |
Выбор из одного
| В каких ситуациях используется связь между бизнес-процессами со стереотипом > ? | когда разные бизнес процессы включает в себя один и тот же бизнес процесс |
| когда один бизнес процесс обладает всеми свойствами другого бизнес процесса и возможно какими – то дополнительными свойствами | |
| при отображении бизнес процессов, которые должны выполняться в исключительных ситуациях или при наступлении определенных условий |
Выбор из одного
| Для чего используется элемент заметка? | для описания бизнес процесса |
| для комментариев в модели | |
| для навигации по модели |
Источник: megaobuchalka.ru
