Требования к информационной системе

РефератПомощь в написанииУзнать стоимостьмоей работы

Для демонстрации примера требований с атрибутами воспользуемся методом расстановки приоритетов MoSCoW и рекомендациями RUP. В данном случае воспользуемся набором RUP, который включает следующие атрибуты: Параллельно должна быть начата разработка требований к надежности. Требования к надежности (табл. 8.4) очень важны, поскольку от их точного указания зависит стабильная работа создаваемой И С… Читать ещё >

Требования к информационной системе (реферат, курсовая, диплом, контрольная)

При формировании требований к информационной системе воспользуемся классификацией FURPS+ (см. подпараграф 3.2.3). Данная классификация включает:

• функциональные требования;
• требования к удобству использования;
• требования к надежности;
• требования к производительности;
• требования к поддержке;
• ограничения.

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

• статус (Status):
- — предложенные (Proposed),
- — одобренные (Approved),
- — отклоненные (Rejected),
- — включенные (Incorporated);
• полезность (Benefit):
— критическое (Critical),
— важное (Important),
— полезное (Useful);
• трудоемкость (Effort) — выражается в финансах, человеко-часах и т. п.;
• риск (Risk) — оценивается как Высокий, Средний или Низкий (В, С, Н);
• стабильность (Stability) — оценка вероятности того, что требование будет изменено (В, С, Н).

Далее сформируем спецификацию требований к информационной системе на основе классификации FURPS+ и зададим атрибуты для них на основе набора RUP. Еще раз отметим, что для первичного формирования спецификации требований к ИС, которые готовит бизнесили системный аналитик, было бы достаточно составления простого списка без атрибутов.

Функциональные требования. Применение классификации FURPS+ обычно начинается с формирования функциональных требований. В табл. 8.2 приведены примеры функциональных требований к разрабатываемой информационной системе и их атрибутов.

Таблица 8.2

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

Функциональные требования.	Атрибуты.
Функциональные требования.	Статус.	Полезн.	Труд.	Риск.	Стаб.
Создание нового отправления.	Одобр.	Критич.	10 ч.	Н.	В.
Внесение основных характеристик отправления (наименование, адрес, срочность, габариты).	То же.	То же.	10ч.	Н.	В.
Внесение информации об отправителе (ФИО, номер телефона, e-mail).			10 ч.	Н.	С.
Указание типа отправления (корреспонденция, посылки и упаковки, ценные отправления, опасные отправления).			5 ч.	Н.	В.

Окончание табл. 8.2

Функциональные требования.	Атрибуты.
Функциональные требования.	Статус.	Полези.	Труд.	Риск.	Стаб.
Удаление/внесение изменений в информацию об отправлении.		Важное.	5 ч.	С.	В.
Возможность выбрать адрес отправления и назначения из списка.	Пред; лож.	Полезн.	15 ч.	В.	II.
Возможность внести адрес отправления и назначения вручную.	Одобр.	Критич.	5 ч.	н.	В.
Расчет общей суммы сбора для отправления.	То же.	То же.	7 ч.	н.	В.
Присвоение отправлению индивидуального номера после подтверждения корректности внесенной информации об отправлении.			10 ч.	с.	В.
Составление реестра с указанием количества позиций в отправлении, их наименовании, адресом назначения, датой и временем приема, ФИО принимающего, номером принимающего офиса.			5ч.	В.	С.
Печать сформированного реестра.	Пред; лож.	Полезн.	10 ч.	н.	С.
Автоматическое отправление номера отправления отправителю на телефон, e-mail.	Отклон.	Полезн.	20 000 руб.	в.	Н.
Обновление времени приема при внесении корректировки в информацию об отправлении на этапе приема в случае замечаний со стороны отправителя (старая версия не сохранена).	Одобр.	Важное.	2 ч.	с.	В.
Присвоение отправлению статуса «принят» после подтверждения принимающим сотрудником.	То же.	Важное.	2 ч.	н.	С.
Хранение информации об отправлении.		Критич.	70 000 руб.	с.	В.

После описания функциональных требований начинается разработка нефункциональных требований. В классификации FURPS+ первая группа нефункциональных требований — это требования к удобству использования.

Требования к удобству использования. Требования к удобству использования и их атрибуты приведены в табл. 8.3.

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

Таблица 83

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

Параллельно должна быть начата разработка требований к надежности. Требования к надежности (табл. 8.4) очень важны, поскольку от их точного указания зависит стабильная работа создаваемой И С.

Таблица 8.4

Требования к надежности и их атрибуты.

Требования к надежности.	Атрибуты требования.
Требования к надежности.	Статус.	Полезн.	Труд, ч.	Риск.	Стаб.
Частота сбоев не выше чем 1 раз/мес.	Одобр.	Кригич.		В.	В.
Среднее время устранения сбоя до 1 ч.	Одобр.	Важное.		С.	С.
После сбоя система должна быть восстановлена без потери данных.	Пред; лож.	Критич.		В.	В.
Режим работы И С — 7 дней в неделю (1 ч в день — профилактический перерыв).	Одобр.	То же.		с.	В.
Система должна иметь механизм реализации автоматического дублирования наиболее важных компонентов.	То же.	и.		В.	В.
Система должна обеспечивать резервирование наиболее важных пользовательских данных и возможность их автоматического восстановления.		и.		В.	В.
Система должна иметь механизм уведомления системного администратора о возникновении ошибок.	Пред; лож.	Важное.		н.	С.

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

Требования к производительности. Требования к производительности (табл. 8.5) определяют производительность И С: пропускную способность, скорость обработки информации, пиковую нагрузку и т. п. — в зависимости от контекста использования И С.

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

Таблица 8.5

Требования к 11 ро из вод ител ьности.	Атрибуты требования.
Требования к 11 ро из вод ител ьности.	Статус.	11олезн.	Труд, ч.	Риск.	Стаб.
Время отклика системы на запрос пользователя не должно превышать 1 с.	Одобр.	Критич.		С.	В.
Допустимое количество одновременно работающих вместе пользователей нс должно быть более 500 чел. (при расширении филиальной сети до 3000 чел.).	Обсужд.	Важное.		В.	В.
Время запуска или перезапуска И С не должно превышать 5 мин.	Отклон.	Полезн.		С.	Н.

Далее необходимо сформулировать последние нефункциональные требования — требования к поддержке.

Требования к поддержке. Важность этих требований (табл. 8.6) нельзя недооценивать, поскольку именно от них зависит, какими силами будет поддерживаться ИС (силами заказчика, исполнителя или передана внешним организациям).

Таблица 8.6

Требования к поддержке и их атрибуты

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

И, наконец, необходимо определить ограничения создаваемой ИС. Ограничения. Обратите внимание, что в классификации FURPS+ ограничения рассматриваются в качестве требований, поэтому атрибуты требований применяются без каких-либо доработок или дополнений (табл. 8.7).

Таблица 8.7

Ограничения и их атрибуты

Ограничения.	Атрибуты требования.
Ограничения.	Статус.	11олезн.	Труд, ч.	Риск.	Стаб.
Модуль мобильных устройств должен быть совместим с iOS и Android, а серверная часть должна быть совместима с Windows ХР, Windows 7, Windows 8, Windows 10.	О добр.	Критич.		С.	В.
ИС должна поддерживать документы форматов MS Office 2007, 2010, 2015 версий.	Одобр.	Важное.		II.	С.

Теперь, когда функциональные и нефункциональные требования (включая ограничения) сформированы, можно приступать к следующему этапу проекта.

Показать весь текст

Заполнить форму текущей работой