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

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

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

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

___________________Р.А. Валиев

___________________г.

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

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

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

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

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

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

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

___________________Р.А. Валиев

___________________г.

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

Студент: А.А. Ганиев

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

Задание принято 8.12.2020 г. __________ А.А. Ганиев

2
 Содержание

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

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

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

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

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

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

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

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

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

3
 ВВЕДЕНИЕ

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

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

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

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

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

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

Для частной медицинской клиники и ее клиентов требуется

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

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

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

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

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

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

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

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

С помощью сайта были успешно оказаны 10 услуг.

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

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

- Реализацию на PhpStorm
- Возможность пользователя зарегистрироваться/авторизоваться,
таким образом, получив доступ ко всем возможностям сервиса
1.2 Бизнес риски

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

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

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

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

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

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

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

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

8
 1.9 MVP

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

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

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

участников.
Версия 2: расширение возможностей сервиса.

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 – Существительные и глаголы

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

Рисунок 2.2 – ER модель проекта медицинской клиники

13
 Разработка атрибутов модели

Атрибутами сущности «Статус заявки» является состояние заявки

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

14
 Рисунок 1.3 – ER модель проекта медицинского клиники с атрибутами

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

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

Для частной медицинской клиники и ее клиентов требуется сервис,

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

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

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

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

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

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

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

Рисунок 4.1 – Диаграмма вариантов использования

2. Спецификации для каждого варианта использования
18
 Таблица 4.1 Вариант использования: «Регистрация пациента»
UC-1. Регистрация пациента
Определение/ Операция предназначена для возможности регистрации
Ценность пациента
Пользователь Пациент
Предусловие Пациент записан на сайте
Основной 1. Пациент вводит данные.
сценарий 2. Сайт сохраняет информацию.
Альтернативные 1а. Пациент не ввел данные.
пути 1а.1. Сайт просит ввести данные.
Результат Пациент ввел данные

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

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

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

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

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

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

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

UC-7. Получить уведомление
Определение/ Операция предназначена для информирования

20
Ценность Пациента от сайта
Пользователь Пациент
Предусловие Пациент открыл сайт и разрешил отправлять
уведомления
Основной 1. Сайт уведомил Пациента об акциях и предложениях
сценарий сервиса.
2. Пациент заходит на сайт и интересуется с
предложениями.
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
верный
21
FR3 Пополнить счет
Система должна предоставить пользователю
FR-3.1
возможность создать запись
FR-3.2 Система должна предоставить форму оплаты
Система должна предоставить пользователю
FR-3.3
возможность отменить запись
FR4 Создание записи
Система должна предоставить пользователю
FR-4.1
возможность выбора врача
Система должна предоставить пользователю
FR-4.2
возможность выбора услуги
Система должна предоставить пользователю
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 Дизайн и интерфейс сайта должен быть гибким
22
1.2 Интерфейсы к ПО
Таблица 6.2 – Требования к пользовательским интерфейсам
SI-1 PhpStorm
SI-2 Система должна обеспечивать интеграцию с базой данных
SI-3 Система должна обеспечивать интеграцию с приложением
SI-4 Система должна обеспечивать интеграцию с конфигурацией

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

Таблица 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 Требования к производительности

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

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

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

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

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

Таблица 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 Сайт должен соответствовать Конституции и УК РФ

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

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

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

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

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

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.

28