Министерство образования республики Беларусь

Учреждение образования

«БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ»

Институт информационных технологий

Специальность ПМС

КОНТРОЛЬНАЯ РАБОТА

По дисциплине «МППиУ»

Вариант №5

Тема: «Анализ бизнес-потребностей и составление перечня требований»

Студент 1 курса
Группы № 083871
Власик И.А.

Минск 2021
 План:

1. Легенда компании;
2. Перечень требований к программному продукту со стороны владельца
компании;
3. Перечень требований к программному продукту со стороны
потенциального пользователя;
4. Перечень требований к программному продукту со стороны ИТ-
специалиста компании.
 1. Легенда компании

Автомобильный интернет-портал «abw.by»

История проекта началась в далеком 1995 году с выходом газеты
«Автобизнес» – крупнейшего печатного автомобильного издания Беларуси.
До 2019 года каждый четверг десятки тысяч автолюбителей получали доступ
к актуальным новостям, отзывам и мнениям владельцев популярных марок,
тест-драйвам автомобильных новинок, испытаниям запчастей и аксессуаров,
объявлениям компаний и частных лиц в печатном виде.
Редакция «Автобизнеса» неоднократно получала награды в области
журналистики. Среди наших достижений победа в национальном конкурсе
среди печатных изданий «Золотая литера» в номинации «Лучшая рекламная
газета». Журналисты издания становились победителями ежегодной премии
«Золотое перо» за особые заслуги в области журналистики.
Сегодня весь автомобильный бизнес страны освещается на страницах
нашего интернет-портала – abw.by.
Сайт Автобизнес появился в 2006 году и со временем вырос в
самостоятельный и успешный проект. Портал постоянно дополняется
полезными функциями и сервисами, становится удобнее и современнее.
Сегодня abw.by – это команда из 30-ти увлеченных
единомышленников, влюбленных в автомобили и не представляющих свою
жизнь без них. Каждый день мы делимся тем, что знаем и умеем, с теми,
кому это нужно.
Наш сайт представляет собой информационную площадку,
содержащую несколько тематических разделов:
• Грузоперевозки. Данный сервис предназначен для размещения и
поиска транспорта, свободных грузов и контактной информации как
грузовладельцев, так и грузоперевозчиков, позволяя вам в кратчайшее время
найти удобнейший для себя вариант.
• Каталог автомобилей. Обширный список новейших и раритетных
моделей, их характеристики и фотографиии.
• Новости. Постоянно обновляющаяся база новостей познакомит вас с
актуальными событиями, происходящими как в нашей республике, так и за
ее пределами.
• Статьи. Здесь вы сможете узнать о новинках автомобильной
промышленности, ознакомиться с обзорами и тест-драйвами новых моделей,
найти советы по эксплуатации автомобилей и их обслуживанию.
• Автоинформация. В этом разделе размещается перечень
действующих страховых компаний, автозаправок, автошкол, прокатных
организаций, автостоянок, автосалонов, автосервисов, а также их контактные
данные. Существует возможность оставить свой комментарий, а также
ознакомиться с комментариями других пользователей.
• Отзывы. Лучший способ сформировать мнение о незнакомом
автомобиле - это ознакомиться с отзывами других автовладельцев. В этом
вам поможет наш раздел, в котором собраны отзывы о самых разнообразных
автомобилях. Существует возможность оставить свое мнение о модели.
• Автозапчасти. Размещение частных объявлений о продаже
различных новых и б/у автозапчастей. Удобный поиск и сортировка по
моделям автомобилей также по категориям автозапчастей.
 2. Перечень требований к программному продукту со стороны
владельца компании;

Перед постановкой технического задания (ТЗ) на разработку заказчик

(владелец компании) должен четко понимать, какие задачи будет решать его
сайт и как взаимодействовать с посетителями. На языке разработчиков это
называется «собрать функциональные и бизнес-требования». В таком случае
заказчик сможет точно оценить бюджет и время выполнения, а разработчику
не придется переделывать свою работу.
Функциональные и бизнес-требования решают такие задачи:
-Упрощают взаимодействие между заказчиком и разработчиком. Они
помогают избежать недопонимания, определяют общие термины и роли.
-Сокращают срок реализации проекта. Благодаря четким требованиям
разработка сайта займет меньше времени.
-Экономят бюджет. Когда заказчик понимает что ему нужно, он может
более точно спланировать бюджет. Размытые требования приводят к
неопределенной стоимости разработки, которая впоследствии может
вырасти.
-Выявляют возможные ошибки. Выявление ошибок на начальном этапе
поможет сократить время и деньги на их исправление.
-Помогают предвидеть итоговый результат. С помощью требований
разработчик понимает, что двигается в правильном направлении. Они не
дают увлечься и отойти от первоначальной идеи, выступая некими
границами проекта.
Функциональные требования – это особенности сайта, которые должен
воплотить в жизнь разработчик. Они описывают то, как система будет
работать при выполнении определенных действий пользователя. Например,
как проходит регистрация в личном кабинете, покупка товара или
оформление подписки.
Кроме функциональных требований, есть еще нефункциональные. Это
атрибуты сайта, которые нужны для его устойчивой работы, при этом не
связанные с основным функционалом. Нефункциональных требований очень
много. Вот основные:
-Производительность. Например, скорость загрузки страницы или время
реакции на определенные действия.
-Удобство для пользователя. Насколько интуитивное меню, сколько
времени уходит у пользователя на поиск нужной информации.
-Безопасность. Персональные данные должны быть защищены от
взломов, хакерских атак, вирусов.
-Совместимость. Как сайт смотрится на различных браузерах и
устройствах. Возможно, с экрана телефона часть картинки не видно.
-Локализация. Если компания сотрудничает с иностранными клиентами,
нужно адаптировать сайт под их запросы. Например, перевести контент на
английский язык, добавить другую валюту или часовые пояса.
 Бизнес-требования – это общие задачи, которые должен решать сайт.
Ключевое отличие бизнес-требований от функциональных в том, что они
должны быть понятны руководителю компании, который не знаком с
техническими тонкостями веб-разработки. Бизнес-требования включают:
-Информацию о компании: название, год основания, сфера
деятельности, товарный знак, список клиентов, преимущества перед
конкурентами.
-Данные о целевой аудитории. Нужно примерно представлять, кто будет
посетителем сайта: его пол, возраст, регион проживания, привычки и
увлечения. Еще нужно понимать, зачем людям вообще приходить к вам на
сайт. Например, купить товары, узнать стоимость дизайн-проекта или
почитать новости.
-Цель создания сайта: что вы хотите получить в итоге. Например,
увеличить количество продаж или повысить узнаваемость бренда.
Каждую задачу можно решить несколькими способами, важно
расставить нужные акценты изначально. Например, наша компания
заказывает сайт и целью является подтвердить статусность, акцент при
разработке будет делаться на эргономичность, фирменный стиль клиента и
удобство коммуникации. Если в бизнес-требованиях стоит «получить
прибыль» – в первую очередь важно будет показать заказчику возможности
получения дополнительной прибыли с помощью сайта, хотя одно другому не
мешает.
Что дает описание бизнес требований? Описывает бизнес-идею, без
реализации которой продукт не будет нужен потребителю. Это описание тех
самых проблем и возможностей, для решения или реализации которых
создается продукт.
Например, если мы разрабатываем сайт для автомобильного интернет-
портала, мы можем описать в бизнес-требованиях, какие возможности он
предоставляет. Например, посетителю сайта он обеспечивает возможность
подобрать оптимальный по цене автомобиль или приобрести нужные
автозапчасти, что позволить сэкономить деньги. Также позволяет сэкономить
время, так как можно найти нужную информацию за пару минут, из-за
удобного интерфейса сайта. Наш сервис так же дает возможность самому
пользователю выставлять на продажу автозапчасти, размещать информацию
связанную с автомобилями и т.д.
 3. Перечень требований к программному продукту со стороны
потенциального пользователя;

Следующий вид требований: пользовательские требования.

Пользовательские требования – описывают цели/задачи пользователей
системы, которые должны достигаться/выполняться при помощи
создаваемой программной системы. Например, наш автомобильный
интернет-портал должен позволять регистрироваться пользователям,
совершать покупки, обеспечивать обратную связь.
Удобство пользования сайтом — важнейший элемент, влияющий на
успех проекта. Для того, чтобы страницы сайта были не только полезны, но и
удобны, перед проработкой прототипа страницы (или перед подбором
шаблона), нужно учесть следующие несколько моментов.
-Каждая страница должна выполнять свою роль, то есть побуждать
пользователя совершить какое-либо действие. Нельзя предлагать
пользователю действия нелогичные или опережающие события. Например,
на страницах категорий автомобилей или автозапчастей пользователь
выбирает из большого количества позиций. Нужно дать ему удобный и
понятный фильтр, короткое, но ёмкое описание товаров. Пользователь
должен убедиться в выгодности предложения и совершить главное целевое
действие — положить товар в корзину или купить в один клик.
-Каждый элемент целевого действия (кнопка, ссылка и другие) должен
быть заметным.
-Если цель страницы — донести информацию, то необходимо просто и
понятно сформулировать мысль, предложить пользователю ознакомиться с
дополнительными сведениями, прокомментировать статью и поделиться ею с
другими пользователями.
-На сайте должна быть удобная навигация. Пользователь должен
понимать, на какой странице он находится и как попасть в другие разделы.
-Поля в формах заявок должны содержать подсказки по формату
заполнения и выделять допущенные ошибки.
Контент сайта включает в себя как текст, так и картинки, видео. Все они
должны отвечать следующим требованиям:
-Читабельность (количество ключевых слов не должно мешать
восприятию основной информации на страницах сайта),
-грамотность,
-размер и цвет шрифта (текст должен быть удобен для прочтения),
-уникальность (картинки и текст должны быть уникальными — плагиат
поисковиками не ценится и сайт может попасть в пожизненный бан из-за
него)
 4. Перечень требований к программному продукту со стороны ИТ-
специалиста компании;

Системный аналитик в ИТ-организации — это человек, который

анализирует требования к предлагаемой системе и обеспечивает правильное
и правильное оформление и документирование требований. Роль аналитика
начинается на этапе анализа программного обеспечения SDLC. Аналитик
обязан убедиться, что разработанное программное обеспечение
соответствует требованиям клиента.
Системные аналитики имеют следующие обязанности:
-Анализ и понимание требований предполагаемого программного
обеспечения.
-Понимание того, как проект будет способствовать достижению целей
организации.
-Определить источники требований.
-Проверка требований.
-Разработать и внедрить план управления требованиями.
-Документация по бизнес, техническим, технологическим и
технологическим требованиям.
-Координация с клиентами для определения приоритетности требований
и устранения и неоднозначности.
-Завершение критериев приемки с клиентом и другими
заинтересованными сторонами.
-Содержит наиболее детализированное описание функций продукта,
которые должны быть реализованными.
Конечным документом, содержащим все требования уровня разработки
является Спецификация требований (software requirements specification, SRS).
Часто это объемный документ, содержащий сотни страниц.
К уровню разработки относятся следующие типы требований:
Функциональные требования (functional requirements) — описывают
что должна и что не должна делать система.
Одними из наиболее значимых требований, предъявляемых при выборе
информационных систем, являются требования к функциональности.
Разрабатываемая информационная системы должна обладать
следующими свойствами:
- адаптивность - означает приспосабливаемость системы к условиям
конкретной предметной области. Необходимо, поскольку может
использоваться совместно с другими информационными системами.
- структурность - определяет наличие установленных связей и
отношений между элементами внутри системы, распределение элементов
системы по уровням и иерархиям.
 - целостность - означает то, что все элементы системы функционируют
как единое целое.
Разрабатываемая информационная система должна предоставлять
следующие возможности:
- следить за состоянием документа на любой его стадии;
- получать исчерпывающую информацию о документе;
- хранить данные о документах
Кроме того информационная система должна обеспечивать
возможности по ведению базы данных о клиентах и основных
предоставляемых услугах.
Список проверок должен быть отсортирован по конечной дате
выполнения (deadline) заказа.
Никакая личная информация пользователя (логин, пароль, номера
телефонов, и тд.) не должна отображаться в отчетах.
Нефункциональные требования (non-functional requirements) —
описывают свойства системы при реализации своего поведения. (По сути это
более техническое и детальное описание атрибутов качества)
Приложение должно поддерживать работу с мобильных устройств
(минимальная ширина экрана – 320 px).
Обьем используемой оперативной памяти не должен превышать 256
Мб.
Как показывает практика, не функциональных требований часто
больше, чем функциональных, по-этому их можно разбивать на подгруппы.
Не функциональные требования
Основными подгруппами являются:
Ограничения (limitations) — факторы, которые ограничивают выбор
способов и средств реализации продукта.
Приложение должно работать в последних версиях браузеров Chrome,
Firefox, Safari.
Приложение должно работать на Raspberry PI 3b+.
Требования к интерфейсам (external interfaces requirements) —
особенности взаимодействия системы с другими системами
Весь трафик между браузером и сервером должен быть зашифрован
(HTTPS соединение).
Отправка письма с отчетом на почту аналитиков должно выполняться
согласно RFC3207 (SMTP over TLS).
Требования к данным (data requirements) — описывают структуры
данных, описания баз данных, особенности их использования.
Все данные системы должны храниться в БД под управлением СУБД
MySQL.
Осталось определиться с тем, что такое “качественные” требования, и
какими свойствами они должны обладать, чтоб с ними было проще работать
в дальнейшем.
Требования к производительности
 Также можно выделить следующие требования по поводу
производительности информационной системы:
Разрабатываемая система должна быть довольна, производительна и не
занимать много системных ресурсов. Ее использование не должно приводить
к замене уже имеющихся аппаратных устройств, а именно системного блока
компьютера. Время отклика работы программы должно быть минимальным
исходя из возможностей компьютерной техники, поскольку работа с
операционными документами производиться постоянно и является
необходимым условием функционирования любой организации.
Поскольку разрабатывается информационная система работа, которой
предполагается в нескольких отделах отделения, ресурсы системы должны
быть доступны, но в тоже время защищены от не санкционированного
доступа.
Требования возможности сопровождения
Можно выделить следующие требования по поводу возможности
сопровождения информационной системы:
Разрабатываемая информационная система должна быть адаптивной,
поскольку в организации возможно использование нескольких программных
продуктов на одной машине для выполнения различных обязанностей
сотрудников. Поэтому информационная система не должна конфликтовать с
программными продуктами сторонних разработчиков.
Также немало важным свойством информационной системы должно
быть ее расширение. Должна иметься возможность дальнейшего расширения
функциональности информационной системы, поскольку реализация
полноценного программного продукта решающего все проблемы бумажного
документооборота в рамках дипломного проекта практически невозможно.
Конфигурирование информационной системы должно быть
минимальным и касаться довольно стандартных вещей, в основном вида или
отражаемых документов. Но данное требование относиться больше как к
дополнительным пожеланиям, нежели как обязательное требование.