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

МСПИСТ

17.03.2017 г.

Лекция 4

Анализ требований�и бизнес-анализ

Процесс анализа требований

© Ю.A. Маглинец

2

Предприятие

(организационная

система, ОС)

Анализ ПО

(бизнес-анализ)

Анализ

требований

АИС

Моделирует

Определяет

Представляет исходные данные для

Помогает осуществить

Анализ требований (Requirements)

• Что такое техническое задание (ТЗ) и для чего оно существует?
• Кто пишет ТЗ?
• Как ТЗ влияет на планирование и выполнение проекта?
• Как ТЗ влияет на формальную приемку проекта?
• Что такое требование к системе?
• Какие бывают виды требований?

Введение

© Ю.A. Маглинец

3

«Качели» �( Brian Lawrence Meek , Patricia Heath)

«Качели» �( Brian Lawrence Meek , Patricia Heath)

«Качели» �( Brian Lawrence Meek , Patricia Heath)

Основные области SWEBOK

SWEBOK – область знаний «Требования к ПО»

SWEBOK – область знаний «Требования к ПО»

Основы требований

• Определение требований
• Требования к продукту и процессу
• Функциональные и нефункциональные требования
• Независимые свойства
• Требования с количественной оценкой
• Системные требования и программные требования.

Основы требований

• Определение требований
• Требования к продукту и процессу
• Функциональные и нефункциональные требования
• Независимые свойства
• Требования с количественной оценкой
• Системные требования и программные требования.

Требование к АИС

• Требование – это условие или возможность, которой должна соответствовать система
• Требования – это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы

Понятие и классиификация требований.

© Ю.A. Маглинец

12

Определение IEEE

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;

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

3. Документированное представление условий или возможностей для пунктов 1 и 2.

Понятие и классиификация требований.

© Ю.A. Маглинец

13

Как и кем используются требования?

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

Процесс анализа требований

© Ю.A. Маглинец

14

Основы требований

• Определение требований
• Требования к продукту и процессу
• Функциональные и нефункциональные требования
• Независимые свойства
• Требования с количественной оценкой
• Системные требования и программные требования.

Основы требований

• Определение требований
• Требования к продукту и процессу
• Функциональные и нефункциональные требования
• Независимые свойства
• Требования с количественной оценкой
• Системные требования и программные требования.

Группировка функциональных требований

Понятие и классиификация требований.

© Ю.A. Маглинец

17

Пример бизнес-требования

система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза

Понятие и классиификация требований.

© Ю.A. Маглинец

18

Классификация по уровню

Понятие и классиификация требований.

© Ю.A. Маглинец

19

Пример требования пользователя

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

Введение

© Ю.A. Маглинец

20

Классификация по уровню

Понятие и классиификация требований.

© Ю.A. Маглинец

21

Пример функциональных требований

(или просто функций) по работе с электронным заказом:

• заказ может быть
• создан,
• отредактирован,
• удалён и
• перемещён с участка на участок

Введение

© Ю.A. Маглинец

22

Конфликты между требованиями разных уровней

​

​

Введение

© Ю.A. Маглинец

23

Классификация К.Вигерса

Понятие и классиификация требований.

© Ю.A. Маглинец

24

Модель FURPS+ (R.Grady, Hewlett-Packard, 1992)

Понятие и классиификация требований.

© Ю.A. Маглинец

25

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

Модель FURPS

• Functionality, функциональность
• Usability, удобство использования
• Reliability, надежность
• Performance, производительность
• Supportability, пригодность к эксплуатации и поддержке.

Введение

© Ю.A. Маглинец

26

Модель FURPS+ (ограничения)

• Ограничения проектирования, design,
• Ограничения разработки, implementation,
• Ограничения на интерфейсы, interface,
• Физические ограничения, physical.

Введение

© Ю.A. Маглинец

27

FURPS+ Функциональность (1)

• Журналирование, аuditing — инструменты отслеживания действий пользователей и системы путем записи в журнал безопасности конкретных типов событий;
• Лицензирование, licensing — средства для отслеживания, приобретения, установки и контроля над использованием лицензий;
• Локализация, localization — средства поддержки различных естественных языков.

Введение

© Ю.A. Маглинец

28

FURPS+ Функциональность (2)

• Почта, mail — службы отправки и получения сообщений
• Помощь, online help — возможность оказывать поддержку пользователей в реальном времени
• Печать, printing — средства для печати документов
• Отчетность, reporting — инструменты создания и получения отчетов.

Введение

© Ю.A. Маглинец

29

FURPS+ Функциональность (3)

• Безопасность, security — средства защиты доступа к определенным ресурсам информации
• Управление системой, system management — инструменты, позволяющие управлять приложениями в распределенной среде
• Технологический процесс, workflow — поддержка документооборота, включая процессы проверки, визирования и утверждения.

Введение

© Ю.A. Маглинец

30

FURPS+ Удобство использования

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

​

Введение

© Ю.A. Маглинец

31

FURPS+ Надежность (1)

• сбои:
• допустимая частота/периодичность сбоев,
• среднее время сбоев и их серьезность,
• возможность восстановления системы после сбоев, в т.ч. возможность предварительного резервного копирования данных,

Введение

© Ю.A. Маглинец

32

FURPS+ Надежность(2)

• предсказуемость поведения,
• время готовности системы к работе, режим работы или время доступности системы (например, «Система должна быть доступна 24 часа в сутки 7 дней в неделю»),
• точность вычислений.

Введение

© Ю.A. Маглинец

33

FURPS+ Производительность (1)

• скорость работы,
• время отклика системы,
• пропускная способность, включая:
• общее и допустимое количество одновременно работающих пользователей,
• количество пользовательских запросов,
• число обращений системы к БД и
• объем запрашиваемых/передаваемых данных в единицу времени,

Введение

© Ю.A. Маглинец

34

FURPS+ Производительность(2)

• время, необходимое на восстановление — скорость восстановления,
• время, необходимое для запуска и завершения работы — скорость запуска и завершения,
• потребление ресурсов.

Введение

© Ю.A. Маглинец

35

FURPS+ Пригодность к поддержке – возможности: (1)

• тестирования,
• расширения — наращивания дополнительного функционала системы,
• масштабирования — тиражирования, например, в филиалах/подразделениях организации,
• адаптации/приспособления к использованию в заданной среде, в т.ч. путем предварительной настройки, …>

Введение

© Ю.A. Маглинец

36

FURPS+ Пригодность к поддержке – возможности: (2)

• конфигурирования — оперативной, регулярной настройки, переопределения параметров,
• совместимости,
• сопровождения, поддержки работоспособности: исправление ошибок, обновление данных, частота архивации и резервного копирования, …>

​

Введение

© Ю.A. Маглинец

37

FURPS+ Пригодность к поддержке – возможности: (3)

• сервисного обслуживания и ремонта, их удобство,
• установки,
• локализации (например, «Продукт будет поддерживать несколько естественных языков»),
• портативность,
• соответствие международным стандартам.

Введение

© Ю.A. Маглинец

38

FURPS+ �Ограничения проектирования

​

• ограничения на технологии (например, «Хранение необходимо реализовать с помощью реляционной БД»),
• процесс («RUP»),
• средства разработки («диаграммы должны создаваться в MS Visio, документация — в MS Word»),
• прочие.

Введение

© Ю.A. Маглинец

39

FURPS + �Ограничения реализации

• стандарты разработки,
• стандарты качества ПО, в т.ч. кода,
• языки программирования,
• средства разработки («В качестве СУБД должна быть использована Oracle 10g»),
• ресурсные ограничения,
• лицензионные ограничения,
• ограничения на техническое (аппаратное) обеспечение,
• прочие.

Введение

© Ю.A. Маглинец

40

FURPS + �Ограничения интерфейсов

​

• форматы данных,
• протоколы взаимодействия,
• внешние системы,
• прочие.

Введение

© Ю.A. Маглинец

41

FURPS + �Физические ограничения,

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

Введение

© Ю.A. Маглинец

42

Основы требований

• Определение требований
• Требования к продукту и процессу
• Функциональные и нефункциональные требования
• Независимые свойства
• Требования с количественной оценкой
• Системные требования и программные требования.

Требования с количественной оценкой

• требования, поддающиеся количественному определению/измерению,
• например, система должна обеспечить пропускную способность
• “столько-то запросов в секунду”.

Основы требований

• Определение требований
• Требования к продукту и процессу
• Функциональные и нефункциональные требования
• Независимые свойства
• Требования с количественной оценкой
• Системные требования и требования к программному обеспечению.

Системные требования (System Requirements)

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

​

Документы IEEE

• IEEE 1362 “Concept of Operations Document”.
• IEEE 1233 «Guide for Developing System Requirements Specifications».
• IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»
• IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
• IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.

Понятие и классиификация требований.

© Ю.A. Маглинец

47

ГОСТ РФ

• ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
• ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
• ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Понятие и классиификация требований.

© Ю.A. Маглинец

48

Дополнительная литература

• Карл Вигерс. Разработка требований к программному обеспечению

​

Введение

© Ю.A. Маглинец

49

Введение

© Ю.A. Маглинец

50