Требования к системе

ТЕМА 4.
Стадия предпроектного
обследования
Лекция 10.
Свойства требований.
Методы сбора требований.

Строжайшее и единственное правило
построения систем программного
обеспечения (ПО) - решить точно, что же
строить. Никакая другая часть
концептуальной работы не является такой
трудной, как выяснение деталей технических
требований, в том числе и взаимодействие с
людьми, с механизмами и с иными системами
ПО. Никакая другая часть работы так не
портит результат, если она выполнена
плохо. Ошибки никакого другого этапа
работы не исправляются так трудно.
Ф. Брукс
2
Свойства требований
Полнота
Ясность (краткость, простота, точность,
недвусмысленность)
3. Верифицируемость (тестируемость, возможность проверки)
4. Необходимость и полезность при эксплуатации
5. Осуществимость (выполнимость, правдоподобность,
реализуемость)
6. Элементарность и трассируемость (прослеживаемость)
7. Независимость от других требований (атомарность),
8. Независимость от реализации (абстрактность)
9. Корректность (согласованность, непротиворечивость)
10. Постоянство (стабильность).
1.
2.
3


Полнота требования означает, что текст
требования не требует дополнительной
детализации, то есть, в нем предусмотрены
все необходимые нюансы, особенности и
детали данного требования.
Различают полноту отдельного требования и
полноту системы требований.
4


Ясность – недвусмысленность,
определенность, однозначность
спецификаций.
Требование обладает свойством ясности,
если оно сходным образом воспринимается
всеми заинтересованными лицами.
5
Требование 1 (неясное):
Система не должна принимать слишком
длинные пароли.
Требование 1 (ясное):
Система не должна принимать пароли
более 15 символов. Если пользователь
вводит более 15 символов при выборе
пароля, сообщение об ошибке должно
информировать пользователя о
необходимом исправлении пароля.
6
Требование 2 (неясное):
Иногда пользователь будет вводить Код
Аэропорта, который система будет
распознавать. Но иногда код можно
заменить близлежащим городом, и тогда
пользователю не нужно знать код
аэропорта, т.к. система будет понимать
название города.
Требование 2 (ясное):
Система должна идентифицировать
аэропорт на основании Кода Аэропорта
или Названия Города.
7

Верифицируемость – пригодность к
проверке. Тестировщики должны иметь
возможность проверить, было ли
требование реализовано корректно.
Треб.1: Функция поиска должна позволять
пользователю искать заказ на основе
Фамилии, Имени, Даты, и т.д.
 Треб. 2 Система должна препятствовать
одновременному доступу большого числа
пользователей.
 Треб.3: Код аэропорта должен быть введен.

8


Необходимым считается требование, невыполнение
которого угрожает работоспособности или
эффективности ИС.
В требовании нет необходимости, если:

Ни одному заинтересованному лицу требование не
нужно.


Удаление требования не повлияет на систему, т.к. оно не
предоставляет никакой новой информации:


Пример. Пользователь должен иметь возможность просмотра
карты аэропорта.
Пример. Все требования, указанные в документе Концепция,
должны быть реализованы и протестированы.
Полезность при эксплуатации – требование,
выполнение которого повышает эргономические
качества продукта.
9

Осуществимость (выполнимость)
Требование должно быть выполнимо в рамках
существующих ограничений, таких как время,
деньги и доступные ресурсы.
 Пример: Система должна иметь интерфейс на
естественном языке, который будет понимать
команды на русском языке.

Выполнимость требования
определяется разумным
балансом между степенью
необходимости и требуемыми
ресурсами.
10

Требование считается элементарным, если
оно содержит только один трассируемый
элемент, который дает возможность
отследить связь между ним и другими
элементами информационной системы.

Пример: Система должна предоставлять
возможность бронировать рейс, покупать
билет, бронировать номер в гостинице,
бронировать машину, а также предоставлять
информацию о развлечениях.
11

Требование является независимым, если для
его понимания не нужно знать другие
требования.
Пример Треб.1: Список доступных рейсов
должен включать номер рейса, время
отправления и время прибытия для каждого
отрезка пути.
Треб.2: Он должен быть отсортирован по ценам.


Требования должны быть независимыми от
реализации

Пример: Информация должна храниться в
текстовом файле.
12

Корректность – согласованность,
непротиворечивость. Требования не должны
противоречить требованиям своего уровня
иерархии и требованиям "родительского"
уровня.
Если требование содержит факты, эти факты
должны быть достоверны:
 Треб.1: Цена заказа должна включать все
соответствующие платежи (включая стоимость
пересылки – 200 руб.)


Требование считается корректным, если не
существует конфликтов между ним и другими
требованиями.
13

Прямые конфликты возникают, когда ожидается
различное поведение системы в одной и той же
ситуации:



Треб.1(конфл.): Дата должна отображаться в формате
ММ/ДД/ГГ.
Треб.1 (конфл.): Дата должна отображаться в формате
ДД/ММ/ГГ.
Косвенный конфликт возникает, когда требования
описывают разную функциональность, но выполнить
оба этих требования одновременно невозможно:


Треб.1: Система должна иметь интерфейс на
естественном языке.
Треб.2: Система должна быть разработана в течение
трех месяцев.
14
Каких требований не должно быть


Спецификация требований не должна
содержать деталей проектирования или
реализации.
Требования должны отвечать на вопрос:
"что должна делать система",
абстрагируясь от вопроса "как она это
должна делать".
15
Стандарты, регламентирующие
работу с требованиями
1. Разработки IEEE:





IEEE 1362 "Concept of Operations Document".
IEEE 1233 "Guide for Developing System Requirements
Specifications".
IEEE Standard 830-1998, "IEEE Recommended Practice for Software
Requirements Specifications"
IEEE Standard Glossary of Software Engineering Terminology/IEEE
Std 610.12-1990
IEEE Guide to the Software Engineering Body of Knowledge (1) SWEBOK®, 2004.
2. Отечественные ГОСТ:



ГОСТ 34.602-89. Информационная технология. Техническое
задание на создание автоматизированной системы
ГОСТ 34.601-90. Информационная технология.
Автоматизированные системы. Стадии создания.
РД 50 34.698-90 «Автоматизированные системы. Требования к
содержанию документов»
16
Классификация требований по
ГОСТ 34.602-89
Требования
Требования
к системе
Функциональные
требования
по подсистемам
Требования к
функциям,
выполняемым
системой
Требования
к времени
реализации
функций
Требования к
видам
обеспечения
Требования
к качеству
реализации
функций
Перечень и
критерии отказов
функции
17
Требования к системе







требования к структуре системы
требования к режимам
функционирования системы;
требования к персоналу
требования к надежности
требования к безопасности;
требования к эргономике и
технической эстетике;
требования к
транспортабельности (для
подвижных АС);






требования к эксплуатации,
техническому обслуживанию,
ремонту и хранению
компонентов системы;
требования к защите информации
от несанкционированного
доступа;
требования к сохранности
информации при авариях;
требования к защите от влияния
внешних воздействий;
требования к патентной чистоте;
требования к стандартизации и
унификации
18
IEEE 830-1998 Recommended Practice for
Software Requirements Specifications
(рекомендуемые методы спецификации требований к ПО)


Описывает структуру документов для фиксации требований к ПО.
Определяет характеристики, которыми должен обладать правильно
составленный набор требований.








Корректность или адекватность (соответствие реальным потребностям).
Недвусмысленность (однозначность понимания).
Полнота (отражение всех выделенных потребностей и всех возможных
ситуаций, в которых придется работать системе).
Непротиворечивость (согласованность между различными элементами).
Упорядоченность по важности и стабильности.
Проверяемость (выполнение каждого требования нужно уметь проверять
некоторым достаточно эффективным способом — непроверяемые
требования должны быть удалены из рассмотрения или сведены к
проверяемым вариантам).
Модифицируемость (оформление в удобных для внесения изменений
структуре и стилях).
Прослеживаемость в ходе разработки (возможность увязать требование с
подсистемами, модулями и операциями, ответственными за его
выполнение, и с тестами, проверяющими его выполнение).
19
IEEE 1233-1998, 2002 Guide for Developing
System Requirements Specifications


(руководство по разработке спецификаций требований к
системам).
Описывает правила построения требований для
программно-аппаратных систем в целом.
Выделяет следующие необходимые свойства набора
требований:









Однократное упоминание отдельных требований.
Отсутствие пересечений между требованиями.
Явное указание связей между требованиями.
Полнота.
Непротиворечивость.
Определение ограничений, области действия и контекста для
каждого требования.
Модифицируемость.
Конфигурируемость, удобство поддержки.
Подходящий для определения системы уровень абстракции.
20
IEEE 1233-1998, 2002 Guide for Developing
System Requirements Specifications
(руководство по разработке спецификаций требований к
системам).

Предписывает определять следующие атрибуты
для каждого требования:







Уникальный идентификатор.
Приоритет, важность реализации с точки зрения
пользователей.
Критичность для построения и успешности системы с
точки зрения аналитиков.
Осуществимость с точки зрения готовности
пользователей к новой функции, имеющихся
технологий и стоимости реализации.
Риски высокой стоимости, последствий использования
для окружающей среды и пользователей, конфликтов
со стандартами и законодательством.
Источник (кто предложил это требование).
Тип требования.
21
Методы сбора требований






Интервью
Анкетирование
Наблюдение
Самостоятельное описание требований
Совместные семинары
Прототипирование
22
Интервью
1. Подготовка – планирование процесса
опроса и выработка стратегии управления
этим процессом.





выбор нужного собеседника;
договоренность о встрече;
формирование предварительной программы
встречи;
изучение сопутствующей информации;
согласование плана опроса с группой
проектирования.
2. Проведение опроса.
3. Завершение.
23
Интервью
1. Подготовка – планирование процесса
опроса и выработка стратегии управления
этим процессом.
2. Проведение опроса.
3. Завершение. Опрос нужно завершать, если:





получен достаточно большой объем
информации;
поступает большой объем неподходящей
информации;
информация перестает усваиваться;
эксперт начинает уставать;
с экспертом возник конфликт.
24
Анкетирование



Преимущество: наименее затратный способ
извлечения информации.
Недостаток: наименее эффективный способ
сбора данных.
В анкетах могут использоваться следующие
виды вопросов:
Многоальтернативные вопросы.
 Рейтинговые вопросы.
 Вопросы с ранжированием.

25
Наблюдение




Применяется для непосредственного сбора
сведений о параметрах, признаках и объектах
в соответствующей предметной области.
Различают пассивное и активное
наблюдение.
Достоинство: сбор информации, которую
невозможно получить путем опроса или
изучения документации.
Недостаток: наблюдатель «вносит помехи» в
результаты измерений.
26
Самостоятельное описание
требований

Используется при наличии:




хорошо структурированной документации, описывающей
устоявшиеся в организации бизнес-процессы;
большого опыта разработки ИС в схожих предметных
областях.
Достоинство: предварительное формирование
требований происходит в удобном для аналитика
режиме.
Недостаток: возможность пропуска важной
информации, связанной с выполнением бизнеспроцессов в реальной жизни и не вошедшей в
документы.
27
Совместные семинары



Групповое обсуждение по методу
«мозгового штурма» проводится с целью
обобщения и обсуждения важных для
решения проблем вопросов.
Недостаток: одна из наиболее затратных
стратегий сбора данных.
Достоинства: быстрота принятия решений,
снижение количества ошибок, выработка
нетривиальных идей.
28
Прототипирование


Прототипирование является ключевым
компонентом технологии быстрой разработки
приложений (RAD – Rapid Application
Development).
RAD базируется на следующих принципах:





эволюционное прототипирование;
использование CASE-средств, обладающих
возможностями прямого и обратного проектирования и
автоматической генерации кода;
высококвалифицированные специалисты;
совмещение живого общения с разработкой в режиме
on-line;
жесткие временные рамки.
29
SWOT


Stregths, Weaknesses, Opportunities, Threats)
(сильные стороны, слабые стороны,
возможности, угрозы)
Этапы SWOT-анализа:
1) определение уникального характера организации, ее
миссии;
2) определение внутренних сильных и слабых сторон
организации по отдельным направлениям
деятельности;
3) определение внешних возможностей и угроз;
4) определение практических приоритетных целей на
среднесрочный период.
Пример SWOT-таблицы
ВНЕШНЯЯ СРЕДА
ВНУТРЕННЯЯ СРЕДА
Возможности
(Opportunities)


Регионы России, где
господствуют местные
авиаперевозки
Увеличение потребности в
авиаперевозках в мире
Сильные стороны
(Strengths)


Угрозы (Threats)



Низкая покупательная
способность населения
России
Рост цен на традиционных
курортах
Конкуренция со стороны
западных
Географическое положение
Разветвленная
инфраструктура
Слабые стороны
(Weaknesses)



Отсутствие единой
информационной системы
Старый авиапарк
Необходимость ликвидации
рабочих мест в связи с
переходом на новый
авиапарк
ISA (Information Systems Architecture )
Респонденты
1.
2.
3.
4.
5.
Метод «5х6»
Ответственный за ИТ у
заказчика ИС – определяет
границы ИС;
Представитель высшего
руководства заказчика ИС –
определяет соответствие ИС
задачам данной организации;
Ответственный
представитель исполнителя
(проектировщик) – определяет
физическую модель системы, ее
основные компоненты;
Представитель исполнителя
(конструктор) – обеспечивает
предложения по детализации
технологических решений;
Поставщик (субподрядчик) –
поставляет компоненты
системы.
1.
2.
3.
4.
5.
6.
Вопросы
Почему объект существует?
(Мотивация существования
организации).
Кто работает с объектом? (Кто будут
пользователи?)
Что представляет собой объект
автоматизации? (С какими данными
будет работать ИС?)
Как функционирует объект
автоматизации? (Какие бизнеспроцессы присутствуют, какие
задачи решаются?)
Где расположен объект
автоматизации? (Компоненты ИС и
их размещение)
Когда с объектом что-либо
происходит? (Изменение данных,
распределение событий и состояний
во времени)
Схема Захмана
Зачем Мотивация Цели организации и базовые правила, по
которым она работает.
Кто
Люди
Персонал, подразделения и другие
элементы орг.структуры, связи между ними
Что
Данные
Сущности и данные, с которыми имеет
дело организация.
Как
Функции
Выполняемые функции и операции над
данными.
Где
Место
Географическое распределение элементов
организации и связи между ее частями
Когда Время
Временные характеристики и ограничения
на деятельность организации, значимые
для ее деятельности события.