- •Классификация информационных систем по степени автоматизации
- •Классификация информационных систем по характеру использования информации
- •5. Ввод в действие,
- •Лекция 2 Документальная поддержка процесса проектирования ис согласно гост 34.602- 89
- •Лекция 3
- •Этапы анализа и моделирование предметной
- •Области внедрения ис
- •Понятие бизнес-модель компании
- •Построение бизнес-модели компании начинается с описания модели взаимодействия с внешней средой по закону единства и борьбы противоположностей, то есть с определения миссии компании.
- •Лекция 4 методы динамического описания предметной области ис
- •Лекция 5 методология моделирования предметной области
- •Объектная структура
- •Функциональная структура
- •Структура управления
- •Организационная структура
- •Техническая структура
- •Сравнение существующих подходов
- •Лекция 6 информационное обеспечение ис
- •Внемашинное информационное обеспечение Основные понятия классификации технико-экономической информации
- •Кодирование технико-экономической информации
- •Понятие унифицированной системы документации
- •Внутримашинное информационное обеспечение
- •Проектирование экранных форм электронных документов
- •Информационная база и способы ее организации
- •Лекция 7 типовое проектирование ис
- •Лекция 8 моделирование информационного обеспечения
- •Лекция 9 спецификация требований к информационным системам
- •Функциональные, нефункциональные требования и характеристики продукта
- •Методологии и стандарты, регламентирующие работу с требованиями
- •Лекция 10 документирование требований к информационным системам
- •Документирование требований в соответствие с гост
- •Документирование требований в rup
- •Документирование требований в msf
- •Лекция 11 способы повышения качества требований
- •Свойства требований
- •Лекция 12 акторы и варианты использования
- •Спецификация варианта использования
- •Свободный формат
- •Табличные представления варианта использования
- •Выбор формы описания варианта использования
- •Модели uml, поясняющие функциональность системы Диаграмма вариантов использования
- •Диаграмма действий
- •Диаграмма состояний
- •Альтернативные языки моделирования Диаграмма потоков данных (dfd диаграмма)
- •Другие виды моделей
Функциональные, нефункциональные требования и характеристики продукта
Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Функциональные требования записываются, как правило, при посредстве предписывающих правил: "система должна позволять кладовщику формировать приходные и расходные накладные". Другим способом являются так называемые варианты использования (uses cases) - популярный и весьма продуктивный способ представления требований.
Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. Сегодня выделяют следующие основные группы нефункциональных требований:
Внешние интерфейсы (External Interfaces),
Атрибуты качества (Quality Attributes),
Ограничения (Constraints).
Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).
Основные атрибуты качества:
Применимость,
Надежность,
Производительность,
Эксплуатационная пригодность.
Классификация RUP
В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990.
Акроним FURPS обозначает следующие категории требований:
Functionality (Функциональность)
Usability (Применимость)
Reliability (Надежность)
Performance (Производительность)
Supportability (эксплуатационная пригодность).
Символ "+" расширяет FURPS-модель, добавляя к ней:
ограничения проекта,
требования выполнения,
требования к интерфейсу,
физические требования.
Кроме того, в спецификациях RUP выделяются такие категории требований, как
требования, указывающие на необходимость согласованности с некоторыми юридическими и нормативными актами;
требования к лицензированию,
требования к документированию.
Методологии и стандарты, регламентирующие работу с требованиями
Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие:
ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
Лекция 10 документирование требований к информационным системам
Чтобы требования, выявленные и описанные приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде документа. В отечественной практике для этого обычно используется документ "Техническое задание", ТЗ, в западной - "Software Requirements Specification", SRS (спецификация программных требований). По сути это - один и тот же документ, поэтому далее по тексту будем употреблять термин "ТЗ", рассматривая различные шаблоны его построения - как на основе российских ГОСТ, так и западных методологий и стандартов.
