ТЕМА 4. Стадия предпроектного обследования

ИС:
Формирование концепции
Предпроектная стадия
Информационное обследование
Анализ предметной области
Анализ требований к системе
Основная задача

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

требований к АС
Разработка концепции АС.
Техническое задание.
Эскизный проект.
Технический проект.
Рабочая документация.
Ввод в

действие.
Сопровождение АС

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

Реализация

Внедрение

Эксплуатация

функциональная структура;
технико-экономические характеристики;
материальные и информационные потоки между подразделениями и внутри

них;
методы планирования, учета и управления.

продолжать данный проект?»

и создаются ИС.
Требование – условие или особенность, которой должна удовлетворять

ИС.
Функциональность, необходимая заказчику или пользователю для разрешения проблем (или получения прибыли).
Функциональность, которая должна быть реализована в системе в соответствии с контрактом, стандартом, спецификацией, инструкцией или другим официальным документом.
Ограничение, наложенное заинтересованным лицом (stakeholder).
Требование – это:
условия или возможности, необходимые пользователю для решения проблем или достижения целей;
условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
документированное представление условий или возможностей для пунктов 1 и 2.

IEEE Standard Glossary of Software Engineering Terminology (1990)

решить точно, что же строить. Никакая другая часть концептуальной работы

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

Ф. Брукс

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

предприятии заказов в три раза.

а также способы (сценарии) их решения в системе.
Где описываются:

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

(system requirement specification, SRS)
Пример:
заказ может быть создан, отредактирован, удален

и перемещен с участка на участок.

использования
Надежность
Производительность
Эксплуатационная пригодность (способность к сопровождению)
Интерфейс пользователя,
Аппаратные интерфейсы,

Программные интерфейсы,
Коммуникационные интерфейсы

Требования, выдвигаемые ИС к среде своего функционирования (объем требуемой памяти, требования к выбору операционной системы)

предоставляют их, пока не будут заданы соответствующие вопросы.
Заказчики обычно не

в курсе стоимости улучшения определенных возможностей.
У нетехнических пользователей часто возникают проблемы с пониманием смысла некоторых технических требований.
Некоторые требования являются сложными в измерении, например: «Система должна быть простой для обучения».

аппаратного обеспечения 
Требования документации 
Требования лицензий и юридических норм 

ИС
Способность к аудиту
Способность к локализации

организации (регламенты, положения, уставы, приказы)
Текущая организация деятельности объекта автоматизации
Модели деятельности

(диаграммы бизнес-процессов)
Журналы использования существующих программно-аппаратных систем
Конкурирующие программные продукты
Заинтересованные лица

процесс настройки и сопровождения системы
(хостинговая компания, справочная служба)
бизнес-аналитики, дизайнеры, кодировщики,

тестеры, менеджеры проектов, менеджеры по внедрению

Государственные
органы контроля,
поставщики стандартов
и регламентов

и полезность при эксплуатации
Осуществимость (выполнимость, правдоподобность, реализуемость)
Элементарность и трассируемость

(прослеживаемость)
Независимость от других требований (атомарность),
Независимость от реализации (абстрактность)
Корректность (согласованность, непротиворечивость)
Постоянство (стабильность).

то есть, в нем предусмотрены все необходимые нюансы, особенности и

детали данного требования.
Различают полноту отдельного требования и полноту системы требований.

если оно сходным образом воспринимается всеми заинтересованными лицами.

1 (ясное):
Система не должна принимать пароли менее 8 символов.

Если пользователь вводит менее 8 символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.

система будет распознавать. Но иногда код можно заменить близлежащим городом,

и тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название города.

Требование 2 (ясное):
Система должна идентифицировать аэропорт на основании Кода Аэропорта или Названия Города.

было ли требование реализовано корректно.
Треб.1: Функция поиска должна позволять

пользователю искать заказ на основе Фамилии, Имени, Даты, и т.д.
Треб. 2 Система должна препятствовать одновременному доступу большого числа пользователей.
Треб.3: Код аэропорта должен быть введен.

В требовании нет необходимости, если:
Ни одному заинтересованному лицу требование не

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

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

на естественном языке, который будет понимать команды на русском языке.

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

который дает возможность отследить связь между ним и другими элементами

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

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

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

уровня иерархии и требованиям "родительского" уровня.
Если требование содержит факты, эти

факты должны быть достоверны:
Треб.1: Цена заказа должна включать все соответствующие платежи (включая стоимость пересылки – 200 руб.)
Требование считается корректным, если не существует конфликтов между ним и другими требованиями.

и той же ситуации:
Треб.1(конфл.): Дата должна отображаться в формате ММ/ДД/ГГ.
Треб.1

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

деталей проектирования или реализации.
Требования должны отвечать на вопрос: "что

должна делать система", абстрагируясь от вопроса "как она это должна делать".

пользователей.
Критичность для построения и успешности системы с точки зрения

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

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

встречи;
изучение сопутствующей информации;
согласование плана опроса с группой проектирования.
Проведение опроса.
Завершение.

процессом.
Проведение опроса.
Завершение. Опрос нужно завершать, если:
получен достаточно большой объем

информации;
поступает большой объем неподходящей информации;
информация перестает усваиваться;
эксперт начинает уставать;
с экспертом возник конфликт.

данных.
В анкетах могут использоваться следующие виды вопросов:
Многоальтернативные вопросы.
Рейтинговые вопросы.

Вопросы с ранжированием.

в соответствующей предметной области.
Различают пассивное и активное наблюдение.
Достоинство:

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

организации бизнес-процессы;
большого опыта разработки ИС в схожих предметных областях.
Достоинство: предварительное

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

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

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

Rapid Application Development).
RAD базируется на следующих принципах:
эволюционное прототипирование;
использование CASE-средств,

обладающих возможностями прямого и обратного проектирования и автоматической генерации кода;
высококвалифицированные специалисты;
совмещение живого общения с разработкой в режиме on-line;
жесткие временные рамки.