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

1.

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

2.

Анализ требований
– часть процесса разработки программного
обеспечения, включающая в себя сбор
требований к программному обеспечению
(ПО), их систематизацию, выявление
взаимосвязей, а также документирование.

3.

Этапы анализа требований
Сбор требований – общение с клиентами и
пользователями, чтобы определить, каковы их
требования; анализ предметной области.
Анализ требований – определение, являются ли
собранные требования неясными, неполными,
неоднозначными или противоречащими;
решение этих проблем; выявление взаимосвязи
требований.
Документирование требований – требования
могут быть задокументированы в различных
формах, таких как простое описание, сценарии
использования, пользовательские истории, или
спецификации процессов.

4.

Типовая структура требований
«Система должна … /утверждение о
необходимом функциональном поведении
системы/»
или
«Система должна позволять … /утверждение
о возможности, предоставляемой
пользователю или внешней системе/»

5.

Классификация требований
1) функциональные требования;
2) нефункциональные требования.

6.

Функциональные требования
объясняют, что должно быть сделано;
идентифицируют задачи или действия,
которые должны быть выполнены;
определяют действия, которые система
должна быть способной выполнить, связь
входа/выхода в поведении системы.

7.

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

8.

Виды нефункциональных
требований
1. Ограничения – условия, ограничивающие
выбор возможных решений по реализации
отдельных требований или их наборов. Они
существенно ограничивают выбор средств,
инструментов и стратегий при разработке
внешнего вида и структуры (в т.ч.
архитектуры) продукта или системы.
Например: «При аутентификации
пользователя должны использоваться
биометрические методы идентификации».

9.

Виды нефункциональных
требований
2. Бизнес-правила – политика,
руководящие принципы или положения,
которые определяют или ограничивают
некоторые аспекты бизнеса, в т.ч. правила,
определяющие состав и правила выполнения
определенных бизнес-процессов.
Например: «Если оплата по счету не поступила
в течение 15 дней, заказ считается
отменённым».

10.

Виды нефункциональных
требований
3. Внешние интерфейсы – описание аспектов
взаимодействия с другими системами и
операционной средой (требования к API продукта
или системы, требования к API других систем, с
которыми осуществляется интеграция).
Например: «Обеспечить запись в журнал
параметров модулей программы: сканера, ядра,
антивирусных баз (информация должна
заноситься в журнал при запуске программы и
при обновлении модулей)»

11.

Виды нефункциональных
требований
4. Предложения по реализации –
предложения, оценивающие возможность
использования определенных технологических и
архитектурных решений.
5. Предложения по тестированию
разрабатываемого ПО – дополнения к
требованиям, указывающие, каким образом то
или иное требование должно быть
протестировано.
6. Юридические требования – требования к
лицензированию, патентной чистоте и т.д.

12.

Определение
нефункциональных требований
Роли по определению нефункциональных требований:
Пользователи – дают оценки значений параметров,
которые используются для определения
нефункциональных требований.
Системный аналитик – собирает, анализирует и
документирует и систематизирует нефункциональные
требования.
Системный архитектор, ключевые разработчики –
участвуют в определении и анализе нефункциональных
требований и проверяют их на реализуемость.
Группа тестирования – участвует в определении и
анализе нефункциональных требований и разрабатывает
сценарии тестирования для проверки нефункциональных
требований.

13.

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

14.

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

15.

Характеристики качества с
точки зрения влияния на
архитектуру системы
первая группа (runtime) – это атрибуты,
относящиеся ко времени работы приложения
или системы;
вторая группа (design time) определяет
ключевые аспекты проектирования
приложения или системы.

16.

Группа runtime
Доступность – атрибут качества,
определяющий время непрерывной работы
приложения или системы.
Надежность – требование, описывающее
поведение приложения или системы в
нештатных ситуациях.
Требования к времени хранения
данных (например, использование БД в
качестве постоянного хранилища данных,
продолжительность хранения данных)
Масштабируемость — требования к
горизонтальному и/или вертикальному
масштабированию приложения или системы.

17.

Группа runtime
Требования к удобству использования
системы и требования к удобству и простоте
поддержки.
Требования к безопасности: разграничение
доступа, работа с приватными данными и
снижение рисков от внешних атак.
Требования к конфигурируемости.
Требования к производительности
решения, определяемые в терминах количества
одновременно работающих пользователей,
обслуживаемых транзакций, времени реакции и
т.д.
Ограничения, накладываемые на объем
доступной памяти, процессорного времени,
дискового пространства и т.д.

18.

Группа design time
требования к повторному использованию
реализации или компонентов приложения
или системы;
требования к расширяемости;
требования к переносимости;
требования к взаимодействию между
компонентами решения, между внешними
компонентами, использование стандартных
протоколов и технологий взаимодействия.

19.

Группа design time
Требования к поддержке системы или
приложения.
Требования к модульности приложения или
системы.
Требования к возможности тестирования.
Требования к возможности и простоте
локализации.