Учебное пособие ТОАУ Ч.3 (Учебное пособие по ТАУ)

Государственное образовательное учреждение

высшего профессионального образования

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

ПРИБОРОСТРЕНИЯ И ИНФОРМАТИКИ»

Кафедра ИТ-7

«Автоматизированные системы управления

и информационные технологии»

УЧЕБНОЕ ПОСОБИЕ

по дисциплине 1716 «Теоретические основы автоматизированного управления»

по специальности 230102 «Автоматизированные системы обработки информации и управления»

Часть 3

Обсуждена на заседании кафедры

(предметно-методической секции)

«___» _______________ 2007 г.

Протокол № _____

МГУПИ — 2011 г.

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

Требования - это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы.

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

1. Требования к продукту и процессу.

Требования к продукту. В своей основе требования - это то, что формулирует заказчик. Цель, которую он преследует - получить хороший конечный продукт: функциональный и удобный в использовании. Поэтому требования к продукту являются основополагающим классом требований.

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

1. Уровни требований

Обычно выделяют три уровня требований.

На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.

Следующий уровень - уровень требований пользователей (user requirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.

Третий уровень - функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

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

1. Системные требования и требования к программному обеспечению

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

Требования к ПО – требований, направленные исключительно на программные компоненты системы.

1. Функциональные, нефункциональные требования и характеристики продукта

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

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

• Внешние интерфейсы (External Interfaces). Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).

• Атрибуты качества (Quality Attributes): Применимость, Надежность, Производительность, Эксплуатационная пригодность.

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

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

Классификация RUP

В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [2.1].

Акроним FURPS обозначает следующие категории требований:

Functionality (Функциональность)

Usability (Применимость)

Reliability (Надежность)

Performance (Производительность)

Supportability (эксплуатационная пригодность).

Символ "+" расширяет FURPS-модель, добавляя к ней:

ограничения проекта,

требования выполнения,

требования к интерфейсу,

физические требования.

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

требования, указывающие на необходимость согласованности с некоторыми юридическими и нормативными актами;

требования к лицензированию,

требования к документированию.

Методологии и стандарты, регламентирующие работу с требованиями

Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие.

1. Разработки 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.

2. Отечественные ГОСТ:

ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.

ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы

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

Свойства требований

В практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе:

• полнота,

• ясность,

• корректность,

• согласованность,

• верифицируемость,

• необходимость,

• полезность при эксплуатации,

• осуществимость,

• модифицируемость,

• трассируемость,

• упорядоченность по важности и стабильности,

• наличие количественной метрики.

Полнота. Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.

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

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

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

К.Вигерс [3.3] дает следующий совет по повышению ясности документов: "Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям".

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

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

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

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

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

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

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

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

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

Каких требований не должно быть.

Согласно [3.5], спецификация требований не должна содержать деталей проектирования или реализации (кроме известных ограничений). Иными словами, требования должны отвечать на вопрос: "что должна делать система", абстрагируясь от вопроса "как она это должна делать". Стремление принимать детальные проектные решения на этапе анализа требований - одна из типичных "ловушек", типичных для неопытных команд разработчиков. Вариантов реализации всегда больше, чем один, а для принятия взвешенного решения нужна максимально более полная информация.

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

Рабочий поток анализа требований

Анализ требований - один из основных рабочих потоков (workflow) программной инженерии.

Для его обозначения Рабочего потока в англоязычной литературе, как правило, используется понятие "Requirement Process". В отечественной практике, наряду с обобщающим термином "анализ требований", принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как "поток работ", "требования", "работа с требованиями", "определение требований" и т.д., что вносит изрядную путаницу.

SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:

• Requirements Elicitation (Извлечение требований),

• Requirements Analysis (Анализ требований в узком смысле),

• Requirements Specification (Специфицирование требований),

• Requirements Validation (Проверка требований).

RUP предлагает выделить в основном потоке анализа требований такие компоненты, как:

• Analyze the Problem (Анализ проблемы),

• Understand Stakeholder Needs (Понимание потребностей совладельцев),

• Define the System (Определение системы),

• Manage the Scope of the System (Управление контекстом системы),

• Refine the System Definition (Уточнение определения системы).

Обобщая указанные выше декомпозиции схема декомпозиции потока работ "Работа с требованиями" включает:

• Формирование видения;

• Выявление требований;

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

• Расширенный анализ требований (моделирование и прототипирование);

• Документирование требований;

• Проверка требований;

• Управление требованиями;

• Совершенствование процесса работы с требованиями.

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

• добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система;

• дать разработчикам наилучшее понимание требований к системе;

• определить границы системы;

• определить интерфейс пользователя и системы.

Кто создает и использует требования