Разработка требований к информационной системе
Лабораторная работа, 27 Октября 2013, автор: пользователь скрыл имя
Описание работы
Цель работы:
Составить и проанализировать требования к информационной системе, оформить техническое задание на разработку программного обеспечения.
Файлы: 1 файл
Лабораторная работа2.docx
— 167.39 Кб (Скачать файл)Лабораторная работа №2. «Разработка требований к информационной системе»
1. Цель работы:
Составить и проанализировать требования к информационной системе, оформить техническое задание на разработку программного обеспечения.
2. Методические указания
Лабораторная работа направлена на ознакомление с процессом разработки требований к информационной системе и составления технического задания на разработку программного обеспечения, получение навыков по использованию основных методов формирования и анализа требований.
Требования к результатам выполнения лабораторногопрактикума:
- наличие диаграммы идентификации точек зрения и диаграммы иерархии точек зрения;
- наличие пользовательских требований, четко описывающих будущий функционал системы;
- наличие системных требований, включающих требования к структуре, программному интерфейсу, технологиям разработки, общие требования к системе (надежность, масштабируемость, распределённость, модульность, безопасность, открытость, удобство пользования и т.д.);
- наличие составленного технического задания.
При составлении и оформлении отчета следует придерживаться рекомендаций.
3. Теоретические сведения
Общие сведения о требованиях к информационным системам
Проблемы, которые приходится
решать специалистам в процессе создания
программного обеспечения, очень сложны.
Природа этих проблем не всегда ясна,
особенно если разрабатываемая программная
система инновационная. В частности,
трудно чётко описать те действия,
которые должна выполнять система.
Описание функциональных возможностей
и ограничений, накладываемых на
систему, называется требованиями к
этой системе, а сам процесс формирования,
анализа, документирования и проверки
этих функциональных возможностей и
ограничений – разработкой
Требования подразделяются на пользовательские и системные. Пользовательские требования – это описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё. Системные требования – это описание особенностей системы (архитектура системы, требования к параметрам оборудования и т.д.), необходимых для эффективной реализации требований пользователя.
Разработка требований
Разработка требований — это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований. Различают четыре основных этапа процесса разработки требований:
- анализ технической осуществимости создания системы,
- формирование и анализ требований,
- специфицирование требований и создание соответствующей документации,
- аттестация этих требований.
На рис.1 показаны взаимосвязи
между этими этапами и
Рис. 1. Процесс разработки требований
Но поскольку в процессе разработки системы в силу разнообразных причин требования могут меняться, управление требованиями, т.е. процесс управления изменениями системных требований, является необходимой составной частью деятельности по их разработке.
Формирование и анализ требований
Следующим этапом процесса разработки требований является формирование (определение) и анализ требований.
Обобщенная модель процесса формирования и анализа требований показана на рис.2. Каждая организация использует собственный вариант этой модели, зависящий от “местных факторов”: опыта работы коллектива разработчиков, типа разрабатываемой системы, используемых стандартов и т.д.
Рис. 2. Процесс формирования и анализа требований
Процесс формирования и анализа требований проходит через ряд этапов.
- Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
- Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
- Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
- Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия различного рода.
- Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
- Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.
Процесс формирования и анализа
требований циклический, с обратной
связью от одного этапа к другому.
Цикл начинается с анализа предметной
области и заканчивается
Рассмотрим три основных подхода к формированию требований: метод, основанный на множестве опорных точек зрения, сценарии и этнографический метод.
Опорные точки зрения
Подход с использованием различных опорных точек зрения к разработке требований признает различные (опорные) точки зрения на проблему и использует их в качестве основы построения и организации как процесса формирования требований, так и непосредственно самих требований.
Различные методы предлагают разные трактовки выражения "точка зрения". Точки зрения можно трактовать следующим образом.
- Как источник информации о системных данных. В этом случае на основе опорных точек зрения строится модель создания и использования данных в системе. В процессе формирования требований отбираются все такие точки зрения (и на их основе определяются данные), которые будут созданы или использованы при работе системы, а также способы обработки этих данных.
- Как структура представлений. В этом случае точки зрения рассматриваются как особая часть модели системы. Например, на основе различных точек зрения могут разрабатываться модели "сущность-связь", модели конечного автомата и т.д.
- Как получатели системных сервисов. В этом случае точки зрения являются внешними (относительно системы) получателями системных сервисов. Точки зрения помогают определить данные, необходимые для выполнения системных сервисов или их управления.
Наиболее эффективным подходом к анализу таких систем является использование внешних опорных точек зрения. На основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition — определение требований на основе точек зрения) для формирования и анализа требований. Основные этапы метода VORD показаны на рис. 3.:
- Идентификация точек зрения, получающих системные сервисы, и идентификация сервисов, соответствующих каждой точке зрения.
- Структурирование точек зрения — создание иерархии сгруппированных точек зрения. Общесистемные сервисы предоставляются более высоким уровням иерархии и наследуются точками зрения низшего уровня.
- Документирование опорных точек зрения, которое заключается в точном описании идентифицированных точек зрения и сервисов.
- Отображение системы точек зрения, которая показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрения.
Рис. 3. Метод VORD
Пример. Рассмотрим использование метода VORD на первых трёх шагах анализа требований для системы поддержки заказа и учета товаров в бакалейной лавке. В бакалейной лавке для каждого товара фиксируется место хранения (определенная полка), количество товара и его поставщик. Система поддержки заказа и учёта товаров должна обеспечивать добавление информации о новом товаре, изменение или удаление информации об имеющемся товаре, хранение (добавление, изменение и удаление) информации о поставщиках, включающей в себя название фирмы, её адрес и телефон. При помощи системы составляются заказы поставщикам. Каждый заказ может содержать несколько позиций, в каждой позиции указываются наименование товара и его количество в заказе. Система по требованию пользователя формирует и выдает на печать следующую справочную информацию:
- список всех товаров;
- список товаров, имеющихся в наличии;
- список товаров, количество которых необходимо пополнить;
- список товаров, поставляемых данным поставщиком.
Первым шагом в формировании
требований является идентификация
опорных точек зрения. Во всех методах
формирования требований, основанных
на использовании точек зрения, начальная
идентификация является наиболее трудной
задачей. Один из подходов к идентификации
точек зрения — метод "мозговой
атаки", когда определяются потенциальные
системные сервисы и
Следующей стадией процесса формирования требований будет идентификация опорных точек зрения (на рис. 4 показаны в виде темных круговых областей) и сервисов (показаны в виде затененных областей). Сервисы должны соответствовать опорным точкам зрения. Но могут быть сервисы, которые не поставлены им в соответствие. Это означает, что на начальном этапе "мозговой атаки" некоторые опорные точки зрения не были идентифицированы.
Рис. 4. Диаграмма идентификации точек зрения
В таблице 1 показано распределение
сервисов для некоторых
Таблица 1 - Сервисы, соотнесенные с точками зрения
клиент |
покупатель |
постоянный покупатель |
товар |
поставщик |
продавец |
администратор |
Проверка наличия товара |
Занесение в список постоянных клиентов |
Получение скидки |
Прием товара |
Занесение в базу данных (название, адрес, телефон и т.д.) |
Продажа товара |
Доступ к базе данных |
Покупка товара |
Получение информацию о новых поступлениях |
Занесение в базу данных (данные о поставщике, кол-ве, месте хранения и.д.) |
Печать чека |
Проверка статистики | ||
Получение чека |
Назначение цены |
Доступ к каталогу |
Переопределение цены | |||
Заказ товара |
Переопределение цены |
Проверка наличия товара |
Оформление заказа поставщику | |||
Занесение покупателя и суммы покупки в базу данных |
«Покупаемый» или « |
Оформление заказа покупателю |
Печать заказа |
Информация, извлеченная из точек зрения, используется для заполнения форм шаблонов точек зрения и организации точек зрения в иерархию наследования. Это позволяет увидеть общие точки зрения и повторно использовать информацию в иерархии наследования. Сервисы, данные и управляющая информация наследуются подмножеством точек зрения. На рис. 5 показана часть иерархии точек зрения для системы поддержки заказа и учета товаров.
Рис. 5. Иерархия точек зрения
Аттестация требований
Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибки в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения ее в эксплуатацию. Стоимость внесения в систему изменений, необходимых для устранения ошибок в требованиях, намного выше, чем исправление ошибок проектирования или кодирования. Причина в том, что изменение требований обычно влечет за собой значительные изменения в системе, после внесения которых она должна пройти повторное тестирование.