ТЕМА 4. Стадия предпроектного обследования Лекция 9. Анализ требований к ИС. - презентация

1 ТЕМА 4. Стадия предпроектного обследования Лекция 9. Анализ требований к ИС.

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

3 3 Проектирование Стадии ЖЦ по ISO/IEC 15288:2002 Формирование концепции Формирование концепции Разработка Разработка Реализация Реализация Эксплуатация Эксплуатация Поддержка Поддержка Снятие с эксплуатации Снятие с эксплуатации по ГОСТ Формирование требований к АС Разработка концепции АС. Техническое задание. Эскизный проект. Технический проект. Рабочая документация. Ввод в действие. Сопровождение АС Анализ требований Реализация Внедрение Эксплуатация

4 4 Стадия «Формирование концепции» Формирование концепции Сбор материалов для проектирования Изучение объекта проектирования Формирование требований пользователей к ИС Проведение необходимых научно- исследовательских работ ТЭО необходимости разработки ИС Анализ материалов и формирование ТЗ Детальный анализ автоматизируемых БП Разработка и выбор варианта концепции системы Разработка и утверждение технического задания

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

6 6 Основные работы I этапа Основной результат – ответ на вопрос: «Стоит ли продолжать данный проект?»

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

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

9 9 Классификация требований Требования Объект требований Требования к продукту Требования к проекту Уровень требований Бизнес- требования Требования пользователя Функциональные требования Характер требований Внешние интерфейсы Атрибуты качества Системные ограничения Нефункциональные требования

10 10 Бизнес- требования 1.Назначение: Формулировка цели проектирования ИС Формулировка цели проектирования ИС 2.Где описываются: Концепция системы (границы и содержание проекта) Концепция системы (границы и содержание проекта) 3.Пример: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза.

11 11 Требования пользователей 1.Назначение : определяют набор пользовательских задач, которые должна решать ИС, а также способы (сценарии) их решения в системе. определяют набор пользовательских задач, которые должна решать ИС, а также способы (сценарии) их решения в системе. 2.Где описываются: Диаграммы вариантов использования, сценарии взаимодействия, функциональные модели в различных нотациях Диаграммы вариантов использования, сценарии взаимодействия, функциональные модели в различных нотациях 3.Пример : система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение.

12 12 Функциональные Функциональные требования 1.Назначение: определяют способы реализации ИС. определяют способы реализации ИС. 2.Где описываются: системные спецификации (system requirement specification, SRS) системные спецификации (system requirement specification, SRS) 3.Пример: заказ может быть создан, отредактирован, удален и перемещен с участка на участок. заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

13 13 Нефункциональные требования – это требования к характеру поведения системы Нефункциональные требования Внешние интерфейсы Атрибуты качества Системные ограничения Удобство использования Надежность Производительность Эксплуатационная пригодность (способность к сопровождению) Интерфейс пользователя, Аппаратные интерфейсы, Программные интерфейсы, Коммуникационные интерфейсы Требования, выдвигаемые ИС к среде своего функционирования (объем требуемой памяти, требования к выбору операционной системы)

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

15 15 Категории нефункциональных требований 1.Основные: 1.Удобство использования 2.Надежность 3.Производительность 4.Эксплуатационная пригодность 2.Дополнительные: 1.Ограничение на дизайн 2.Требования реализации 2.Требования реализации 3.Требования интерфейса 3.Требования интерфейса 4.Требования аппаратного обеспечения 4.Требования аппаратного обеспечения 5.Требования документации 5.Требования документации 6.Требования лицензий и юридических норм 6.Требования лицензий и юридических норм

16 16 Требование «Удобство использования» ПодкатегорияПример Доступность Функциональность бронирования билета на самолет должна быть доступна с домашней страницы. Эстетичность Поля ввода на одной странице должны быть выровнены вертикально. Соответствие интерфейсу пользователя Пользовательский интерфейс должен соответствовать стандарту IBM Эргономич- ность При открытии диалогового окна курсор должен быть на первом поле ввода Легкость в использовании Среднее время процедуры бронирования должно быть не более двух минут.

17 17 Требование «Надежность» ПодкатегорияПример Работоспособность Система должна быть доступна 99,93% времени. Прочность На каждый неверный ввод данных пользователем система должна реагировать соответствующим сообщением об ошибке Точность Денежные расчеты должны выполняться и храниться с точностью до двух десятых Восстанавливае- мость После восстановления системы из состояния неработоспособности обработка данных должна производиться в том же режиме, что и до сбоя. Корректность После выпуска релиза система может иметь не более чем 20 незначительных ошибок.

18 18 Требование «Производительность» ПодкатегорияПример Скорость обработки данных Система должна обрабатывать 1000 процедур бронирования билетов в минуту. Время ответа Среднее время отображения списка полетов должно быть не более 10 секунд. Время восстановления Среднее время восстановления должно быть менее часа. Время загрузки /выхода Система должна быть работоспособной в течение одной минуты от момента загрузки. Емкость Система должна обслуживать 5000 пользователей одновременно. Использование ресурсов Система должна хранить в БД не более 1 млн. транзакций. При превышении лимита старые транзакции архивируются.

19 19 Требование «Эксплуатационная пригодность» Тестируемость Тестируемость Приспособляемость Приспособляемость Совместимость Совместимость Способность к обновлению Способность к обновлению Расширяемость Расширяемость Переносимость Переносимость Возможность многократного применения Возможность многократного применения Взаимодействие с другими ИС Взаимодействие с другими ИС Способность к аудиту Способность к аудиту Способность к локализации Способность к локализации

20 20 Дополнительные требования Требования реализации Требования интерфейса Требования документации Язык программирования Язык программирования Используемая база данных. Используемая база данных. Сторонние компоненты. Сторонние компоненты. Ограничения на ресурсы: память, дисковое пространство. Ограничения на ресурсы: память, дисковое пространство. Стандарты кодирования. Стандарты кодирования. Пользовательский интерфейс. Пользовательский интерфейс. Интерфейс аппаратного обеспечения. Интерфейс аппаратного обеспечения. Интерфейс программного обеспечения. Интерфейс программного обеспечения. Интерфейс коммуникаций. Интерфейс коммуникаций. Распечатанная документация. Распечатанная документация. Документация, доступная на СD. Документация, доступная на СD. Документация, доступная он-лайн. Документация, доступная он-лайн.

21 21 Источники требований Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения) Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения) Нормативное обеспечение организации (регламенты, положения, уставы, приказы) Нормативное обеспечение организации (регламенты, положения, уставы, приказы) Текущая организация деятельности объекта автоматизации Текущая организация деятельности объекта автоматизации Модели деятельности (диаграммы бизнес- процессов) Модели деятельности (диаграммы бизнес- процессов) Журналы использования существующих программно-аппаратных систем Журналы использования существующих программно-аппаратных систем Конкурирующие программные продукты Конкурирующие программные продукты Заинтересованные лица Заинтересованные лица

22 22 Заинтересованные лица Stakeholder Активные участники проекта Обладатели знаний Руководство Остальные участники проекта Контроли- рующие организации эксперты предметной области, авторы документов, собственники сайтов Лица, вовлеченные в процесс настройки и сопровождения системы (хостинговая компания, справочная служба) бизнес-аналитики, дизайнеры, кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению Государственные органы контроля, поставщики стандартов и регламентов

23 23 Использование требований при разработке ИС Заинтересованное лицо Область использования требований Системный аналитик Постановка задачи, определение рамок проекта Представитель заказчика Постановка задачи, определение рамок проекта, контроль работы исполнителей, приемка результатов работы ПроектировщикРазработка архитектуры, проектирование подсистем ПрограммистРазработка программного кода ТестировщикСоставление планов тестирования, тестовых сценариев Менеджер проектаПланирование и контроль исполнения работ

24 24 Свойства требований 1.Полнота 2.Ясность (краткость, простота, точность, недвусмысленность) 3.Верифицируемость (тестируемость, возможность проверки) 4.Необходимость и полезность при эксплуатации 5.Осуществимость (выполнимость, правдоподобность, реализуемость) 6.Элементарность и трассируемость (прослеживаемость) 7.Независимость от других требований (атомарность), 8.Независимость от реализации (абстрактность) 9.Корректность (согласованность, непротиворечивость) 10.Постоянство (стабильность).

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

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

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

28 28 Требование 2 (неясное): Иногда пользователь будет вводить Код Аэропорта, который система будет распознавать. Но иногда код можно заменить близлежащим городом, и тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название города. Требование 2 (ясное): Система должна идентифицировать аэропорт на основании Кода Аэропорта или Названия Города.

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

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

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

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

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

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

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

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

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

38 38 Методы сбора требований Интервью Интервью Анкетирование Анкетирование Наблюдение Наблюдение Самостоятельное описание требований Самостоятельное описание требований Совместные семинары Совместные семинары Прототипирование Прототипирование

39 39 Интервью 1.Подготовка – планирование процесса опроса и выработка стратегии управления этим процессом. выбор нужного собеседника; выбор нужного собеседника; договоренность о встрече; договоренность о встрече; формирование предварительной программы встречи; формирование предварительной программы встречи; изучение сопутствующей информации; изучение сопутствующей информации; согласование плана опроса с группой проектирования. согласование плана опроса с группой проектирования. 2.Проведение опроса. 3.Завершение.

40 40 Интервью 1.Подготовка – планирование процесса опроса и выработка стратегии управления этим процессом. 2.Проведение опроса. 3.Завершение. Опрос нужно завершать, если: получен достаточно большой объем информации; получен достаточно большой объем информации; поступает большой объем неподходящей информации; поступает большой объем неподходящей информации; информация перестает усваиваться; информация перестает усваиваться; эксперт начинает уставать; эксперт начинает уставать; с экспертом возник конфликт. с экспертом возник конфликт.

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

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

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

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

45 45 Прототипирование Прототипирование является ключевым компонентом технологии быстрой разработки приложений (RAD – Rapid Application Development). Прототипирование является ключевым компонентом технологии быстрой разработки приложений (RAD – Rapid Application Development). RAD базируется на следующих принципах: RAD базируется на следующих принципах: эволюционное прототипирование; эволюционное прототипирование; использование CASE-средств, обладающих возможностями прямого и обратного проектирования и автоматической генерации кода; использование CASE-средств, обладающих возможностями прямого и обратного проектирования и автоматической генерации кода; высококвалифицированные специалисты; высококвалифицированные специалисты; совмещение живого общения с разработкой в режиме on-line; совмещение живого общения с разработкой в режиме on-line; жесткие временные рамки. жесткие временные рамки.