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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16 Стандарты, регламентирующие работу с требованиями 1.Разработки IEEE: IEEE 1362 "Concept of Operations Document". IEEE 1362 "Concept of Operations Document". IEEE 1233 "Guide for Developing System Requirements Specifications". IEEE 1233 "Guide for Developing System Requirements Specifications". IEEE Standard , "IEEE Recommended Practice for Software Requirements Specifications" IEEE Standard , "IEEE Recommended Practice for Software Requirements Specifications" IEEE Standard Glossary of Software Engineering Terminology/IEEE Std IEEE Standard Glossary of Software Engineering Terminology/IEEE Std IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, Отечественные ГОСТ: ГОСТ Информационная технология. Техническое задание на создание автоматизированной системы ГОСТ Информационная технология. Техническое задание на создание автоматизированной системы ГОСТ Информационная технология. Автоматизированные системы. Стадии создания. ГОСТ Информационная технология. Автоматизированные системы. Стадии создания. РД «Автоматизированные системы. Требования к содержанию документов» РД «Автоматизированные системы. Требования к содержанию документов»

17 Классификация требований по ГОСТ Требования к системе Требования к функциям, выполняемым системой Функциональные требования по подсистемам Требования к времени реализации функций Требования к качеству реализации функций Перечень и критерии отказов функции Требования к видам обеспечения

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

19 IEEE Recommended Practice for Software Requirements Specifications (рекомендуемые методы спецификации IEEE Recommended Practice for Software Requirements Specifications (рекомендуемые методы спецификации требований к ПО) Описывает структуру документов для фиксации требований к ПО. Описывает структуру документов для фиксации требований к ПО. Определяет характеристики, которыми должен обладать правильно составленный набор требований. Определяет характеристики, которыми должен обладать правильно составленный набор требований. Корректность или адекватность (соответствие реальным потребностям). Корректность или адекватность (соответствие реальным потребностям). Недвусмысленность (однозначность понимания). Недвусмысленность (однозначность понимания). Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, в которых придется работать системе). Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, в которых придется работать системе). Непротиворечивость (согласованность между различными элементами). Непротиворечивость (согласованность между различными элементами). Упорядоченность по важности и стабильности. Упорядоченность по важности и стабильности. Проверяемость (выполнение каждого требования нужно уметь проверять некоторым достаточно эффективным способом непроверяемые требования должны быть удалены из рассмотрения или сведены к проверяемым вариантам). Проверяемость (выполнение каждого требования нужно уметь проверять некоторым достаточно эффективным способом непроверяемые требования должны быть удалены из рассмотрения или сведены к проверяемым вариантам). Модифицируемость (оформление в удобных для внесения изменений структуре и стилях). Модифицируемость (оформление в удобных для внесения изменений структуре и стилях). Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами, модулями и операциями, ответственными за его выполнение, и с тестами, проверяющими его выполнение). Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами, модулями и операциями, ответственными за его выполнение, и с тестами, проверяющими его выполнение).

20 IEEE , 2002 Guide for Developing System Requirements Specifications (руководство по разработке спецификаций требований к системам). Описывает правила построения требований для программно-аппаратных систем в целом. Описывает правила построения требований для программно-аппаратных систем в целом. Выделяет следующие необходимые свойства набора требований: Выделяет следующие необходимые свойства набора требований: Однократное упоминание отдельных требований. Однократное упоминание отдельных требований. Отсутствие пересечений между требованиями. Отсутствие пересечений между требованиями. Явное указание связей между требованиями. Явное указание связей между требованиями. Полнота. Полнота. Непротиворечивость. Непротиворечивость. Определение ограничений, области действия и контекста для каждого требования. Определение ограничений, области действия и контекста для каждого требования. Модифицируемость. Модифицируемость. Конфигурируемость, удобство поддержки. Конфигурируемость, удобство поддержки. Подходящий для определения системы уровень абстракции. Подходящий для определения системы уровень абстракции.

21 IEEE , 2002 Guide for Developing System Requirements Specifications (руководство по разработке спецификаций требований к системам). Предписывает определять следующие атрибуты для каждого требования: Предписывает определять следующие атрибуты для каждого требования: Уникальный идентификатор. Уникальный идентификатор. Приоритет, важность реализации с точки зрения пользователей. Приоритет, важность реализации с точки зрения пользователей. Критичность для построения и успешности системы с точки зрения аналитиков. Критичность для построения и успешности системы с точки зрения аналитиков. Осуществимость с точки зрения готовности пользователей к новой функции, имеющихся технологий и стоимости реализации. Осуществимость с точки зрения готовности пользователей к новой функции, имеющихся технологий и стоимости реализации. Риски высокой стоимости, последствий использования для окружающей среды и пользователей, конфликтов со стандартами и законодательством. Риски высокой стоимости, последствий использования для окружающей среды и пользователей, конфликтов со стандартами и законодательством. Источник (кто предложил это требование). Источник (кто предложил это требование). Тип требования. Тип требования.

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

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

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

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

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

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

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

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

SWOT Stregths, Weaknesses, Opportunities, Threats) (сильные стороны, слабые стороны, возможности, угрозы) Этапы SWOT-анализа: 1) 1)определение уникального характера организации, ее миссии; 2) 2)определение внутренних сильных и слабых сторон организации по отдельным направлениям деятельности; 3) 3)определение внешних возможностей и угроз; 4) 4)определение практических приоритетных целей на среднесрочный период.

Пример SWOT-таблицы ВНЕШНЯЯ СРЕДАВНУТРЕННЯЯ СРЕДА Возможности (Opportunities) Сильные стороны (Strengths) Регионы России, где господствуют местные авиаперевозки Увеличение потребности в авиаперевозках в мире Географическое положение Разветвленная инфраструктура Угрозы (Threats)Слабые стороны (Weaknesses) Низкая покупательная способность населения России Рост цен на традиционных курортах Конкуренция со стороны западных авиаперевозчиков Отсутствие единой информационной системы Старый авиапарк Необходимость ликвидации рабочих мест в связи с переходом на новый авиапарк Неэффективная эксплуатация некоторых линий

ISA (Information Systems Architecture ) Ответственный за ИТ у заказчика ИС – определяет границы ИС; Представитель высшего руководства заказчика ИС – определяет соответствие ИС задачам данной организации; Ответственный представитель исполнителя (проектировщик) – определяет физическую модель системы, ее основные компоненты; Представитель исполнителя (конструктор) – обеспечивает предложения по детализации технологических решений; Поставщик (субподрядчик) – поставляет компоненты системы. 1. Почему объект существует? (Мотивация существования организации). 2. Кто работает с объектом? (Кто будут пользователи?) 3. Что представляет собой объект автоматизации? (С какими данными будет работать ИС?) 4. Как функционирует объект автоматизации? (Какие бизнес- процессы присутствуют, какие задачи решаются?) 5. Где расположен объект автоматизации? (Компоненты ИС и их размещение) 6. Когда с объектом что-либо происходит? (Изменение данных, распределение событий и состояний во времени) РеспондентыВопросы Метод «5х6»

Схема Захмана ЗачемМотивацияЦели организации и базовые правила, по которым она работает. КтоЛюдиПерсонал, подразделения и другие элементы орг.структуры, связи между ними ЧтоДанныеСущности и данные, с которыми имеет дело организация. КакФункцииВыполняемые функции и операции над данными. ГдеМестоГеографическое распределение элементов организации и связи между ее частями КогдаВремяВременные характеристики и ограничения на деятельность организации, значимые для ее деятельности события.