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

Для понимания, что описывает аналитик на этапе ТЗ необходимо понимание структурной модели информационной системы. Существуют разные способы классификации требований по уровням. Мы будем использовать следующую классификацию по уровням требований:

Бизнес. Что, с помощью внедрения ИС, хочет достичь сама организация. Какие цели и ограничения, но не у системы, а у бизнеса.
Пользовательский. Чтобы реализовать цели бизнеса, должны быть реализованы возможности для пользователей, выполнение которых не противоречит бизнесу. Данные требования идут к организации процесса.
Функциональный. Требования пользовательского уровня к возможностям и действиям должны реализоваться через определения требований функционального уровня системы, подсистемы и компонентам.

На этапе предпроектного обследования работа ведется на первом и втором уровне, а на этапе ТЗ на третьем, т.е. какие возможности предоставляет система пользователям.

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

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

Пример хорошего требования: Система должна позволять пользователю с ролью покупатель создавать заказ со следующими атрибутами: …(маркированный список атрибутов).

Характеристики качественных требований.

Нижеперечисленные характеристики распространяются на любой способ формулировки требований. Основными способами являются: классический через функциональные требования и сценарии вариантов использования(ВИ)/Use Case(UC). * Единичность и атомарность относятся только к классическому виду.

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

Сворачиваемый список подробного описания характеристик.

Способы группировки требований.

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

Способы группировки требований по стандарту IEEE 830-1993:

По фичам. Из плюсов - очень логично, при изменении уровня доступа изменения коснутся малого объема документа. Из минусов: у фичи нечетко определены границы. Правила роли более устойчивы.
По ролям. Используется чаще. Из плюсов: понятно какой пользователь что делает. Из минусов: разные пользователи могут делать одну и ту же работу, соответственно придется описывать несколько раз.
По этапам реализации (1, 2, 3..)
По режимам работы системы
По объектам
Другие

Чаще всего используют 1 или 2 тип классификации.

Способы кодирования, кодирование необходимо для отслеживания требований:

С помощью автоматической нумерации. Минус: при редактировании нумерация сдвигается.
С использованием буквенно-цифровых кодов, например FR-001, FR-001/01 или FR_ORD-001.05. Минусы: при пропуске требования, необходимо поместить его в самый конец, несмотря на логику процесса. Сложность в поиске нужного требования, необходим список всех сокращений.
С использованием смысловых алиасов, например Заказ.Создание. Смысловой алиас - краткое содержание требования, в котором указывается роль, объект и совершаемое действие.

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

Канонический формат ФТ (Иногда проще формулировать требование через отрицание.)
- Система должна позволять пользователю роль действие объект действия
- Система должна действие объект действия
Канонический формат ФТ (требования к интеграции)
- Система должна передавать в смежную систему название системы объект обмена
- Система должна получать из смежной системы название системы объект обмена

Способы проверки полноты ФТ к ПО/системе:

Привязка к шагам БП. Проверка связи ФТ с шагами БП.
Трассировка. Трассировка до пользовательских и бизнес-требований
Моделирование. Графическое представление требований
Проверка данных. Проверка ситуаций с пограничными значениями данных, закон сохранения данных
Проверка условий. Проверка сложной логики с условиями И, ИЛИ, НЕ и т.д.
Проверка по CRUDL(Create, Read, Update, Delete, List | Создание, Просмотр, Обновление, Удаление, Просмотр Списка). Проверка действий над сущностями.

Существуют требования, которые не звучат по CRUDL, например, требования по авторизации, являющееся функциональным требованием.

Характеристики качественных требований

<aside> 💡 Видео: Как обеспечить полноту требований?

</aside>

Use Case’ы

Описанных выше артефактов необходимо и достаточно для функционально-логической модели ИС. Но существует и другой способ задания ФТ, который минует проблемы проверки полноты требований из-за их атомарности и единичности. Чтобы понять, записали ли мы все действия, необходимые пользователю для совершения какой-либо операции, необходимо “нанизывать” ФТ, словно бусинки на ниточку. В добавок требуется дополнительный контроль их связанности. Логика UC заключается в представлении одним связанным блоком небольшой истории пользователя и его взаимодействия.

Untitled

Реестр UC

Способы перехода от бизнес UC к системным UC:

Детализация бизнес UC на основании знания предметной области;
Анализ бизнес-процессов;
Применение модели данных.

МС для реестра UC:

Таблица со следующими полями:
- Название UC, или другими словами алиас, показывающий цель UC
- Код UC, для простоты поиска
- Участник UC. UC желательно делать двусторонними, где одна из сторон ИС.
- Автор UC. Кто описывал.
- Приоритет UC. Для дальнейшего описания и разработки.

Системный UC

Шаблоны для системных UC бывают разные. В учебном проекте представлен линейный. Существует вариант разделения потоков на шаги пользователя и шаги системы. Шаблон - это элемент МС.

Условия применения:

Предусловия - это условие, отражающее логические правила, которым должен удовлетворять сеанс пользователя;