Анализ требований к информационным системам

Специфицирование требований
Введение
Лекция № 1

Специфицирование требований
Свойства АИС
Основаны на методологии управления
Множественный доступ к данным
Средства корпоративного решения задач
Дружественный графический интерфейс
Оперативная обработка информации
Средства аутентификации и авторизации
Значительные объёмы данных
Стандартизация языков и протоколов обмена

Специфицирование требований
Определение АИС
АИС – это программно-аппаратная система, предназначенная для автоматизации целенаправленной деятельности конечных пользователей, обеспечивающую, в соответствие с заложенной в неё логикой обработки, возможность получения, модификации и хранения информации.

Специфицирование требований
Определение ИС
ИС в широком смысле – это взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи ин­формации в интересах достижения поставленной цели.

Специфицирование требований
Классификация по масштабу

Специфицирование требований
Требования к КИС
централизация данных в единой базе (в основе – всегда промышленная СУБД),
близкий к реальному времени режим работы,
сохранение общей модели управления для предприятий разных отраслей,
поддержка территориально-распределенных структур,
работа на широком круге аппаратно-программных платформ и СУБД.

Специфицирование требований
Классификация по архитектуре

Специфицирование требований
Классификация по характеру использования информации

Специфицирование требований
Классификация по системе представления данных

Специфицирование требований
Классификация по поддерживаемым стандартам управления и технологиям коммуникации
CALS
ERPII
Workflow
OLAP
Project
Management

Специфицирование требований
Классификация по степени автоматизации

Специфицирование требований
Требования – понятие и классификация
Лекция № 2

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

Специфицирование требований
Определение IEEE
1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3. Документированное представление условий или возможностей для пунктов 1 и 2

Специфицирование требований
Классификация по предмету

Специфицирование требований
Классификация по уровню

Специфицирование требований
Классификация 3

Специфицирование требований
Классификация К.Вигерса

Специфицирование требований
Модель FURPS+

Специфицирование требований
Документы 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.

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

Специфицирование требований
Свойства требований
Лекция № 3

Специфицирование требований
Свойства требований
ванность
Полнота
Ясность
Коррект-
ность
Согласо-
ванность
Полезность
Трассируе-
мость
Упорядо-
ченность
Наличие ко-
личествен-
ной метрики
Верифици-
руемость
Необходи-
мось
Осущест-
вимость
Модифи-
цируемость

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

Специфицирование требований
Ясность
Синонимы:
недвусмысленность,
определённость,
однозначность спецификаций.
Требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы

Специфицирование требований
Корректность
Свойство корректности задаёт дихотомию: требование либо корректно, либо нет.
Корректное требование –
непротиворечивое,
обеспечивающее требуемую точность,
обеспечивающее связь с источниками

Специфицирование требований
Согласованность
Вертикальная согласованность:
непротиворечивость требованиям родительского уровня иерархии.
Горизонтальная согласованность:
непротиворечивость требованиям своего уровня иерархии.

Специфицирование требований
Верифицируемость
Верифицируемость означает пригодность к проверке.
Основано на:
ясности,
полноте,
трассируемости.

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

Специфицирование требований
Осуществимость (выполнимость)
Выполнимость требования определяется комбинацией следующих факторов:
технической возможностью осуществления;
разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами.

Специфицирование требований
Треугольник компромиссов

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

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

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

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

Специфицирование требований
Процесс анализа требований
Лекция № 4

Специфицирование требований
SWEBOK: Requirement Process
Requirements Elicitation (Извлечение требований)
Requirements Analysis (Анализ требований в узком смысле)
Requirements Specification (Специфицирование требований)
Requirements Validation (Проверка требований)

Специфицирование требований
RUP: Requirements
Analyze the Problem (Анализ проблемы)
Understand Stakeholder Needs (Понимание потребностей совладельцев)
Define the System (Определение системы)
Manage the Scope of the System (Управление контекстом системы)
Refine the System Definition (Уточнение определения системы)

Специфицирование требований
Работа с требованиями (построение лекционного курса)
Формирование видения
Выявление требований
Классификация и спецификация требований
Расширенный анализ требований (моделирование и прототипирование)
Документирование требований
Проверка требований
Управление требованиями
Совершенствование процесса работы с требованиями

Специфицирование требований
Хорошо проработанные требования позволяют:
Выработать общее понимание между Заказчиком и Разработчиком
Определить рамки проекта
Определить финансовые и временные характеристики проекта
Обезопасить Заказчика от риска получить продукт, в котором он не сможет работать
Обезопасить Разработчика от риска попасть в ситуацию неконтролируемого размытия границ

Специфицирование требований
RUP: Цели потока Requirements
Добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система
Дать разработчикам наилучшее понимание требований к системе
Определить границы системы
Определить интерфейс пользователя и системы

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

Специфицирование требований
Фазы процесса MSF
Envisioning (выработка концепции)
Planning (планирование)
Developing (разработка)
Stabilizing (стабилизация)
Deploying (внедрение).

Специфицирование требований
Envisioning

Специфицирование требований
Planning

Специфицирование требований
Developing

Специфицирование требований
Deploying

Специфицирование требований
Контекст задачи
анализа требований
Лекция № 5

Специфицирование требований
Предприятие
(организационная
система, ОС)
Анализ ПО
(бизнес-анализ)
Анализ
требований
АИС
Моделирует
Определяет
Представляет исходные данные для
Помогает осуществить
Анализ требований
и бизнес-анализ

Специфицирование требований
Предприятие
(организационная
система, ОС)
Модель
бизнес-анализа
М(ОС)
Модель
анализа требований
М(АИС)
Аналити-
ческая модель
М’(АИС)
Проектная
модель
М’’(АИС)
Модель
реализации М’’’(АИС)
АИС
моде-
лирует
моделирует
зависит от
зависит от
зависит от
зависит от
зависит от
моделирует
моделирует
моделирует
моделирует

Специфицирование требований
Методологии бизнес-анализа

Специфицирование требований
Модели для улучшения ОС
SWOT
VCM
BPR
BSC
CPI/TQM/
ISO9000

Специфицирование требований
Модели общего назначения
IDEF1
IDEF3
IDEF5
SADT
DFD

Специфицирование требований
Модели для автоматизации
ISA
BSP
ARIS
RUP

Специфицирование требований
Модели организации (ARIS)
Организаци-
онная
Функцио-
нальная
Входов/
выходов
Информаци-
онная
Процессов
управления
Целей
организации
Средств
производства
Человеческих
ресурсов
Территори-
альная

Специфицирование требований
Архитектура программной системы (RUP)
Представление
процессов
Логическое
представление
Физическое
представление
Представление
реализации
Представление
прецедентов

Специфицирование требований
Деловое
моделирование
Зависимости между АТ и др. потоками работ (RUP)
Управление
средой
Управление
проектом
Анализ
требований
Испытание
Анализ и
проектирование

Специфицирование требований
Выявление требований
Лекция № 6

Специфицирование требований
Источники требований

Специфицирование требований
Стратегии выявления требований

Специфицирование требований
Интервью

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

Специфицирование требований
Совместные семинары

Специфицирование требований
Мозговой штурм
Правила мозгового штурма предполагают полную раскрепощённость и свободу мнений, даже самых вычурных и на первый взгляд «бредовых». Первое правило мозгового штурма – «полный запрет на любую критику». Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию.
Затем, на втором этапе, все высказанные мнения тщательным образом обсуждаются, заведомо неприемлемые варианты отсеиваются, формируются коллективные предложения.

Специфицирование требований
Участники JAD-совещания
Ведущий – специалист в области межличностных коммуникаций. Должен ориентироваться в предметной области, но не обязательно хорошо ориентироваться в проблемах IT.
Секретарь – стенографист встречи. Фиксирует её результаты на компьютере. Возможно применение CASE-средств.
Заказчики – пользователи или руководители, основные участники, формирующие, обсуждающие требования и принимающие решения.
Разработчики – аналитики и другие участники проектной команды. Работают в большей части в пассивном режиме с целью наилучшего понимания проблемной области.

Специфицирование требований
Разъясняющие встречи
“Разъясняющие встречи” или “запланированный мозговой штурм” – термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п.

Специфицирование требований
Выявление через прототипы.
Принципы RAD-метода
Эволюционное прототипирование;
CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;
Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;
Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;
Жёсткие временные рамки, как противоядие от «расползания границ» проекта: если команда не укладывается в срок – функционал сужается.

Специфицирование требований
Формирование видения
Лекция № 7

Специфицирование требований
Видение / Рамки
Концепция
Границы
Видение
Рамки
Образ
Контекст

Специфицирование требований
ГОСТ 34.601-90

Специфицирование требований
RUP

Специфицирование требований
RUP – шаблон
для формулировки проблемы

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

Специфицирование требований
Классификация ограничений

Специфицирование требований
Шаблон документа «Vision» RUP
Введение
Позиционирование
Описания совладельцев и пользователей
Краткий обзор изделия
Возможности продукта
Ограничения
Показатели качества
Старшинство и приоритеты
Другие требования к изделию
Требования к документации
Приложение.

Специфицирование требований
Vision / Scope (MSF)
Согласно белой книге MSF, на фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения.
Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду.
Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования.

Специфицирование требований
MSF – envisioning phase
Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка vision/scope document.
Видение (vision) – это ничем не ограничиваемое представление о том, каким должно быть решение
Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.

Специфицирование требований
Шаблон документа «Vision/Scope» MSF
Бизнес-преимущества
1.1. Описание преимуществ
1.2. Формулировка видения
1.3. Анализ выгод
Концепция решения
2.1. Цели, задачи, предположения и ограничения
2.2. Анализ применимости
2.3. Требования
Рамки
3.1. Список характеристик/функций
3.2. Вне рамок
3.3. Стратегия подготовки релизов
3.4. Критерии применимости
3.5. Эксплуатационные критерии
Стратегии проектирования решения
4.1. Стратегия проектирования архитектуры
4.2. Стратегия технического проектирования

Специфицирование требований
Классификация и специфицирование требований
Лекция № 8

Специфицирование требований
Требования совладельцев
Результатом выявления требований, является реестр требований.
Требования совладельцев обычно оформляются в простой письменной форме, без какой-либо особой регламентации.
Пример оформления требования к программе электронной почты – «Система должна позволять набирать текст сообщения с возможностью форматирования текста и вставки смайликов».

Специфицирование требований
Акторы и варианты использования
Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования, предложенный И.Якобсоном.
Прежде, чем приступить собственно к специфицированию требований в форме вариантов использования, RUP рекомендует выявить реестр акторов (actors) и вариантов использования (use cases).

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

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

Специфицирование требований
Глоссарий
Служит основой для единообразного понимания описаний требований Заказчиком и Разработчиком.
Является отправной точкой для построения более развёрнутых моделей проблемной области, которые, на стадии реализации информационной системы, ложатся в основу объектной модели (для объектно-ориентированных приложений) и модели данных (для генерации схемы базы данных).
Оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области. Термин обычно выделяют полужирным кеглем.
Иногда проблемную область целесообразно сегментировать на ряд «подобластей» (subject areas). Тогда каждой из них в глоссарии выделяется отдельный параграф.

Специфицирование требований
Спецификации прецедента
Свободный
формат
Полный
формат
Таблица
в три
колонки
Язык
описания
алгоритма
Стиль
RUP
Таблица
в две
колонки
Псевдокод
Диаграмма
активности UML
Другие
графические
модели

Специфицирование требований
Полный формат
Название
Контекст использования
Область действия
Уровень
Основное действующее лицо
Участники и интересы
Предусловие
Минимальные гарантии
Гарантии успеха
Триггер
Основной сценарий
Расширения
Список изменений в технологии и данных
Вспомогательная информация

Специфицирование требований
Таблица в 2 колонки

Специфицирование требований
Таблица в 3 колонки

Специфицирование требований
Формат RUP
Наименования и краткое описание
Поток событий
2.1. Основной поток
2.2. Альтернативные потоки
Специальные требования
Предусловия
Постусловия
Точки расширения

Специфицирование требований
Спецификация нефункцио- нальных требований
Описание нефункциональных требований обычно осуществляется в форме, близкой к свободному формату описания варианта использования.
RUP рекомендует концентрировать нефункциональные требования в документе, описывающем вариант использования во всех случаях, когда это возможно.
В случае, если нефункциональные требования носят общий характер, они выносятся в документ «Дополнительная спецификация».