МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РФ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ОБРАЗОВАНИЯ
«КАЗАНСКИЙ (ПРИВОЛЖСКИЙ) ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
НАБЕРЕЖНОЧЕЛНИНСКИЙ ИНСТИТУТ (ФИЛИАЛ)
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

Утверждаю
Заведующий кафедрой ИС

___________________Р.А. Валиев

___________________г.

КУРСОВОЙ ПРОЕКТ
по дисциплине:
«Проектирование и архитектура программных систем»
на тему:
«Проектирование требований на разработку архитектуры программных
систем»
Вариант: « Проектирование сервиса для организации спортивных
мероприятий на CMS WordPress»

Автор: Оценка: ________________________

студент группы 2171121
Руководитель: к.т.н.
____________ Ы.Кулмамедов доцент кафедры ИС

____________ Ш.А. Хамадеев

Дата защиты: г.

Набережные Челны
2020
КАЗАНСКИЙ (ПРИВОЛЖСКИЙ) ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ
 НАБЕРЕЖНОЧЕЛНИНСКИЙ ИНСТИТУТ (ФИЛИАЛ)
КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ (ИС)

Утверждаю
Заведующий кафедрой ИС

___________________Р.А. Валиев

___________________г.

ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ

Студент: Ы.Кулмамедов

1 Тема
«Проектирование требований на разработку архитектуры программных
систем»
2 Срок представления к защите __________г.
3 Исходные данные
Для организаторов спортивных мероприятий и спортсменов требуется
автоматизированная система, сервис, комплекс программных средств. В
данном случае непосредственно сайт, необходимый для эффективной
организации сервисного обслуживания в ходе массовых спортивных
мероприятий.
4 Перечень подлежащих разработке вопросов
Описание бизнес-требований к системе, разработка модели данных,
моделирование бизнес-процессов, разработка пользовательских требований,
разработка функциональных требований, разработка нефункциональных
требований.
Задание выдано _________г. __________ Ш.А. Хамадеев

Задание принято _________ г. __________ Ы.Кулмамедов

2
 Содержание

ВВЕДЕНИЕ..............................................................................................................5

1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ....................................................7

2 РАЗРАБОТКА МОДЕЛИ ДАННЫХ..........................................................12

3 МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ.........................................15

4 РАЗРАБОТКА ПОЛЬЗОВАТЕЛЬСКИХ ТРЕБОВАНИЙ.......................17

5 РАЗРАБОТКА ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ.........................22

6 РАЗРАБОТКА НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ...................24

ЗАКЛЮЧЕНИЕ.....................................................................................................27

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ............................................29

3
 ВВЕДЕНИЕ

Сегодня невозможно представить организацию крупных спортивных

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

4
 Предметом исследования является веб- приложение для регистрации
участников соревнований.
Целью данного проекта является повышение эффективности
управления организацией массовых спортивных мероприятий за счет
создания веб-приложения.
Для достижения поставленной цели требуется решить следующие
задачи:
- описать бизнес-требования к системе;
- разработать модель данных;
- смоделировать бизнес-процессы;
- разработать пользовательские требования;
- разработать функциональные требования;
- разработать нефункциональные требования.
Структура проекта определена предметом, целью, задачами
исследования.
Состав работы включает в себя:
- введение, где раскрывается актуальность темы, её объект
исследования, предмет исследования, цель, задачи исследования;
- основную часть, включающую в себя 6 разделов: описание
бизнес-требований, разработка модели данных, моделирование бизнес-
процессов, разработка пользовательских требований, разработка
функциональных требований, разработка нефункциональных требований;
- заключение, где подводятся результаты исследования и
формируются выводы по выбранной теме, и список использованных
источников.
Разделы основной части тесно связаны между собой и раскрывают
потребности проекта, бизнес-цели, риски, модель данных предметной
области, модель бизнес-процессов, список задач, которые пользователям
необходимо будет выполнять посредством системы, функции, которые

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

6
 1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Бизнес-требования
1.1.1 Исходные данные

Для организаторов спортивных мероприятий и спортсменов

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

Потенциальный участник соревнований (спортсмен, пользователь веб-

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

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

- Существенное упрощение системы взаимодействия организаторов и

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

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

Расширение базы участников соревнований. Получить 5000

регистраций в течение года
Масштаб: Казань, Уфа, Самара
Способ измерения: количество регистраций
Показатели в прошлом: 0 (2019, продукт не существует)

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

С помощью сайта были совершены 10 успешных спортивных

соревнований, с регистрацией более 15 участников

1.5 Видение решения

Решение представляет собой веб-сайт и предполагает:

- Реализацию на CMS WordPress
- Возможность пользователя зарегистрироваться/авторизоваться,

таким образом, получив доступ ко всем возможностям сервиса

1.2 Бизнес риски

- Появление конкурентов в этой сфере

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

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

- Пилотный проект (около 20-30 участников)

- Мобильная верстка не предусматривается

1.8 Рамки и ограничения проекта

1.8.1 Основные функции

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

8
 - Оплата выставленного счета
- Управление балансом (например, пополнение баланса)
- Просмотр истории заявок
- Администрирование
- Интеграция с конфигуратором

1.9 MVP

- Регистрация/авторизация
- Управление балансом
- Базовые функции администратора

1.10 Прочие версии продукта

Версия 1: реферальная программа, программа лояльности, база

участников.
Версия 2: расширение возможностей сервиса: например, создание
информационного интерфейса TV-трансляции.

1.11 Бизнес-контекст

1.11.1 Стейкхолдеры

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

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

10
 1.12 Приоритеты проекта

Функции: все функции MVP должны быть выполнены

Качество: критическая функциональность должна работать без
ошибок. Пользователи должны полностью доверять данным системы.
Срок: версия MVP должны быть запущена через 3 месяца.
Допустимая задержка не более 3 недель.
Расходы: 5 500 000 рублей на разработку, 800 000 рублей на
продвижение и продажи
Персонал: предполагаемый персонал: руководитель проекта, 4
разработчика, 1 тестировщик, 1 интегратор с учетными системами, 1
специалист тех. поддержки, 2 специалиста по продажам.

1.13 Варианты использования

Администратор
- Следить за правильной работой сервиса
Разработчики сервисов других интеграций
- Контролировать работу интеграций с веб-сервисом
Разработчик базы конфигурации
- Проверять интеграцию базы конфигурации с веб-сервисом
Незарегистрированный пользователь
- Регистрация на сайте
- Просмотр информации и услуг на сайте
Зарегистрированный пользователь
- Авторизация
- Просмотр информации и услуг на сайте
- Редактирование личных данных
- Выбор роли и соревнования
- Оплата страховых взносов
Руководитель

11
 - Получать отчеты
Диспетчер
- Отвечать на звонки
- Контролировать заявки (мониторинг)

1.14 Пользовательские сценарии

Цель пользователя: изучить предложение, сравнить его с другими,

зарегистрироваться (создать заявку) и непосредственно принять участие в
спортивном мероприятии.
Роль: покупатель услуги; организатор/участник мероприятия
Ценность: сервис используют спортсмены или организаторы
спортивных мероприятий, которые хотят комфортно сэкономить, удобно,
быстро и недорого организовать или принять участие в данных
мероприятиях.
Отношение: заинтересованность, недоверие к сервису

2 Разработка модели данных

1. Выделение существительных и глаголов

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

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

Рисунок 2.1 – Существительные и глаголы

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

Рисунок 2.2 – ER модель проекта организации спортивных

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

13
 Атрибутами сущности «Координаты» является место проведения
мероприятия (рисунок 2.4).
Атрибутами сущности «Мероприятия» является Номер мероприятия.
Номер мероприятия должен быть уникальным у каждого мероприятия.
Атрибутами сущности «Пользователь» являются ФИО, номер
телефона, почта, баланс, логин и пароль. Уникальными должны быть связка
полей ФИО, номер телефона, логин и пароль.
Атрибутами сущности «Тариф» являются Наименование, Стоимость.
Атрибутом сущности «Дополнительная информация» является
Примечания к заявке.

Рисунок 1.3 – ER модель проекта организации спортивных

мероприятий с атрибутами

14
 3 МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

3.1 Описание предметной области

Для организации спортивных мероприятий и регистрации участников

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

Для предоставления данной услуги – организации спортивных

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

Рисунок 3.1 – Анализ процесса в табличном виде

15
3.3 Диаграмма процессов BPMN 2

Рисунок 3.2 – Диаграмма процессов BPMN 2

16
4. Разработка пользовательских требований

1. Выявленные потенциальные акторы и варианты использования

согласно анализу бизнес-требований, бизнес-процессов (BPMN2
модели процессов) и анализу модели данных (ER-модели):
1.1Пользователь системы
Варианты использования:
1. Авторизация;
2. Проверить баланс;
3. Создать заявку;
4. Регистрация на мероприятие;
5. Оплата;
6. Отменить заявку;
7. Получить уведомление.

17
 Рисунок 4.1 – Диаграмма вариантов использования
2. Спецификации для каждого варианта использования

Таблица 4.1 Вариант использования: «Авторизация»

UC-1. Авторизация
Определение/ Операция предназначена для авторизации на сайте
Ценность
Пользователь Пользователь
Предусловие Пользователь зашел на сайт
18
Основной 1. Пользователь вводит логин и пароль.
сценарий 2. Сайт проверяет правильность введенных данных.
3. Пользователь заходит в личный кабинет.
Альтернативные 2а. Пользователь ввел неверные данные при
пути авторизации.
2а.1. Сайт отображает сообщение об ошибке.
2а.2. Работа возобновляется с шага 1.
Результат Пользователь получил доступ в личный кабинет.

Таблица 4.2 Вариант использования: «Проверить баланс»

UC-2. Проверить баланс
Определение/ Операция предназначена для возможности регистрации
Ценность на мероприятие
Пользователь Пользователь
Предусловие Пользователь авторизован на сайте
Основной 1. Пользователь заходит в личный кабинет.
сценарий 2. Сайт показывает баланс.
Альтернативные 2а. На счету недостаточно денег.
пути 2а.1. Сайт просит пополнить баланс.
Результат На счету достаточно денег для регистрации на
мероприятие

Таблица 4.3 Вариант использования: «Создать заявку»

UC-3. Создать заявку
Определение/ Операция предназначена для создания спортивного
Ценность мероприятия
Пользователь Организатор
Предусловие Организатор авторизован на сайте
Основной 1. Организатор открыл сайт.
сценарий 2. Организатор регистрируется на сайте.
3. Сайт отображает доступные даты для создания
заявки.
4. Организатор создает мероприятие.
5. Сайт создает информацию о мероприятии.
6. Организатор оплачивает тариф на сайте.
19
 7. Сайт показывает состояние заявки.
8. Организатор видит состояние заявки.
Альтернативные 3а. Организатор отказывается создавать мероприятие.
пути 3а1. Сайт завершает выполнение операции.
Результат Заявка создана

Таблица 4.4 Вариант использования: «Регистрация на мероприятие»

UC-4. Регистрация на мероприятие
Определение/ Операция предназначена для регистрации на
Ценность спортивное мероприятие
Пользователь Пользователь
Предусловие Пользователь авторизован на сайте
Основной 1. Пользователь открыл сайт.
сценарий 2. Сайт отображает доступные мероприятия.
3. Пользователь выбирает подходящее мероприятие.
4. Сайт показывает информацию о мероприятии.
5. Пользователь регистрируется на данное
мероприятие.
6. Сайт показывает состояние заявки.
7. Пользователь видит состояние заявки.
Альтернативные 3а. Пользователь отказывается выбирать мероприятие.
пути 3а1. Сайт завершает выполнение операции.
Результат Заявка создана

Таблица 4.5 Вариант использования: «Оплата»

UC-5. Оплата
Определение/ Операция предназначена для оплаты созданной заявки
Ценность
Пользователь Организатор
Предусловие Организатор создал заявку
Основной 1. Организатор создал заявку.
сценарий 2. Сайт показывает сумму оплаты.
3. Организатор оплачивает заявку.
4. Сайт показывает статус заявки и чек.
5. Организатор может сохранить чек.
20
Альтернативные 4а. Оплата не прошла.
пути 5а.1. Сайт выдаёт сообщение организатору об ошибке.
5а.2. Организатор обращается в службу поддержки.
Результат Оплата прошла

Таблица 4.6 Вариант использования: «Отменить заявку»

UC-6. Отменить заявку
Определение/ Операция предназначена для удаления заявки
Ценность
Пользователь Организатор
Предусловие Организатор создал заявку
Основной 1. Организатор заходит на сайт.
сценарий 2. Сайт показывает активные заявки.
3. Организатор открывает активную заявку.
4. Сайт показывает статус заявки.
5. Организатор отказывается от созданной заявки.
Альтернативные 5а. Сайт выдает ошибку.
пути 5а.1. Организатор звонит в службу поддержки.
5б. Если до начала мероприятия остался 1 день, то сайт
не даст отмену заявки.
5б.1. Сайт просит завершения заявки.
5б.2. Организатор завершает заявку.
Результат Заявка отменена

Таблица 4.7 Вариант использования: «Получить уведомление»

UC-7. Получить уведомление
Определение/ Операция предназначена для информирования
Ценность Организатора и Пользователя от сайта
Пользователь Организатор/Пользователь
Предусловие Организатор/Пользователь открыли сайт и разрешили
отправлять уведомления
Основной 1. Сайт уведомил Организатор/Пользователь об акциях
сценарий и предложениях сервиса.
2. Организатор заходит на сайт и интересуется с
предложениями.
21
 3. Организатор решает создать мероприятие.
Альтернативные 3а. Организатор отказывается от создания заявки.
пути
Результат Организатор/Пользователь информирован об акциях и
предложениях

5 РАЗРАБОТКА ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

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

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

Идентификатор Функции/требования
FR1 Регистрация
FR-1.1 Система должна предоставить форму регистрации
Система должна предупредить пользователя, что
FR-1.2
пользователь с такими данными уже существует
Система должна предоставить пользователю логин и
FR-1.3
пароль
FR2 Авторизация
FR-2.1 Система должна предоставить форму авторизации
Система должна предупредить, что пользователя с
FR-2.2
таким логином и паролем не существует
Система должна предупредить, что пароль и логин не
FR-2.3
верный
FR3 Пополнить счет
Система должна предоставить пользователю
FR-3.1
возможность создать заявку
FR-3.2 Система должна предоставить форму оплаты
Система должна предоставить пользователю
FR-3.3
возможность отменить заявку
FR4 Создание заявки
Система должна предоставить пользователю
FR-4.1
возможность выбора роли (участник/организатор)
Система должна предоставить пользователю
FR-4.2
возможность выбора мероприятия

22
 Система должна предоставить пользователю
FR-4.3 возможность выбора мероприятия из списка доступных
ему
Система должна предоставить пользователю
FR-4.4
возможность проверки баланса
FR5 История заявок
Система должна позволять вывести на экран
FR-5.1
пользователя список осуществленных заявок
FR6 Стандартные функциональные требования
Система должна позволять вывести оформленную
FR-6.1
заявку на печать

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

1. Требования к внешним интерфейсам:

1.1 Пользовательские интерфейсы

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

Система должна обеспечивать ссылки на основные HTML страницы

UI-1 определенного пользователя ("Регистрация", "Авторизация",
"Домашняя страница", "Мероприятия" и др)
Список мероприятий должен иметь сортировку по дате и
UI-2
фильтрацию по количеству участников
UI-3 Система должна позволять вывести оформленную заявку на печать
На всех формах сайта должны отображаться отклонения от
UI-4
плановых значений
UI-5 Дизайн и интерфейс сайта должен быть гибким

1.2 Интерфейсы к ПО
Таблица 6.2 – Требования к пользовательским интерфейсам
SI-1 CMS WordPress
SI-2 Система должна обеспечивать интеграцию с базой данных
SI-3 Система должна обеспечивать интеграцию с приложением
SI-4 Система должна обеспечивать интеграцию с конфигурацией

1.3 Коммуникационные интерфейсы

23
 Таблица 6.3 – Требования к коммуникационным интерфейсам
CI-1 Сайт должен отправлять организатору письмо с логином и паролем
Сайт должен отправлять организатору письмо-уведомление об
CI-2
успешной созданной заявке

2.1 Требования к атрибутам качества

Таблица 6.4 - Требования к атрибутам качества

Сайт должен предоставлять доступ к пользовательским функциям

QU-1
24/7
LOC-1 Сайт должен иметь поддержку русского языка
LOC-2 Сайт должен иметь поддержку английского языка

2.2 Требования к удобству использования

Таблица 6.5 - Требования к удобству использования
Сайт должен ограничивать пользователя, если он ввел не
USE-1
правильные данные
USE-2 Сайт должен выводить результаты операции
USE-3 Сайт должен предоставить авто заполнение, там где это возможно
Сайт должен позволить пользователю создать заявку с
USE-4
минимальным количеством действий

2.3 Требования к производительности

Таблица 6.6 - Требования к производительности

Система должна выдерживать и выполнять все запросы

PER-1
пользователя в максимально короткое время
Все веб-страницы, генерируемые системой, должны полностью
PER-2 загружаться не более чем за 3 секунды после запроса их по
интернет-подключению со скоростью 20 Мбит/сек

PER-3 Система должна проверять более 100 бронирований в секунду

2.4 Требования к безопасности

24
 Таблица 6.7 - Требования к безопасности

Пользователи для выполнения всех операций системы обязательно

SEC-1
должен быть авторизованным в системе
Все сетевые транзакции, включающие финансовую или
SEC-2 поддающуюся учету личную информацию, должны быть
зашифрованы

2.5 Требования к надежности

Таблица 6.8 - Требования к надежности
При возникновении ошибок системы, в том числе обработки
REL-1 данных, должно быть сформировано уведомление для
администратора систем
Сайт должен автоматически повторно отправлять письмо
REL-2
пользователю
REL-3 Сайт должен хранить данные в течении 4 лет
REL-4 Сайт должен делать резервную копию данных

3.1 Бизнес-правила
Таблица 6.9 - Бизнес-правила
BR-1 Сайт должен размещать на главной странице список мероприятий
Сайт должен отказать в создании мероприятия, если у организатора
BR-2
на балансе недостаточно средств
BR-3 Сайт должен соответствовать Конституции и УК РФ

25
26
 ЗАКЛЮЧЕНИЕ

В ходе выполнения курсового проекта:

- были описаны бизнес-требования к системе;
- разработана модель данных;
- смоделированы бизнес-процессы;
- разработаны пользовательские требования;
- разработаны функциональные требования;
- разработаны нефункциональные требования.
При анализе бизнес-требований была выявлена потребность, которая
инициализирует проект по разработке необходимой информационной
системы. В данном разделе было дано высокоуровневое описание ситуации,
бизнес-цели, различные критерии успеха, риски, функции проекта,
ограничения проекта, заинтересованные лица и приоритеты проекта.
В разделе «Разработка модели данных» была создана модель данных
предметной области, необходимая для формирования единого языка общения
между участниками проекта.
В разделе «Моделирование бизнес-процессов» была разработана
BPMN 2 модель процессов TO-BE, включающая в себя «сквозной процесс».
В разделе «Разработка пользовательских требований» были
сформированы описания задач, которые пользователь сможет выполнять
посредством информационной системы.
На основании выявленных пользовательских требований была
определена необходимая функциональность информационной системы,
описанная в разделе “Разработка функциональных требований”.
В разделе “Разработка нефункциональных требований” были
определены требования, которые задают системе поведение при выполнении
функциональных требований.

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

28
 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1 Вигерс К., Битти Д. Разработка требований к программному

обеспечению. 3-е изд., дополненное / Пер. с англ. — М.: Издательство
«Русская редакция»; СПб.: БХВ-Петербург, 2014. — 736 стр.: ил.
2 Арлоу Д., Нейштадт И. UML 2 и Унифицированный процесс.
Практический объектно-ориентированный анализ и проектирование, 2е
издание. – Пер. с англ. – СПб: СимволПлюс, 2007. – 624 с., ил.
3 ГОСТ 7.32-2001. Система стандартов по информации,
библиотечному и издательскому делу. Отчет о научно-исследовательской
работе. Структура и правила оформления. – Введ. 2002–07–01. – М.:
Стандартинформ, 2006. – 22 с.
4 Хамадеев Ш.А. Методология моделирования бизнес-процессов
BPMN2. Учебно-методическое пособие по дисциплине «Проектирование
АСОИУ». – Набережные Челны: ИПЦ НЧИ К(П)ФУ, 2017. – 36 с.
5 Хамадеев Ш.А. Методология описания пользовательских
требований. Учебно-методическое пособие по дисциплине «Проектирование
АСОИУ». – Набережные Челны: ИПЦ НЧИ К(П)ФУ, 2017. – 28 с.
6 Справочник по символу BPMN 2.0. Описание всех символов
BPMN 2.0 с примерами. Режим доступа: https://camundarus.ru/bpmn/reference/.
7 Руководство для начинающих по использованию BPMN в
повседневной работе. Режим доступа: https://www.microsoft.com/ru-
ru/microsoft-365/business-insights-ideas/resources/the-guide-to-using-bpmn-in-
your-business.
8 Нотация BPMN 2.0: ключевые элементы и описание. Режим
доступа: https://www.comindware.com/ru/blog-нотация-bpmn-2-0-элементы-и-
описание/.
9 Лекция 2: Понятие требования. Классификации требований.
Режим доступа: https://intuit.ru/studies/courses/2188/174/lecture/4714?page=2.

29