Требования к программным продуктам

IEEE Standard Glossary of Software Engineering Terminology определяет требования как:

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

Какие требования бывают

Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.

Бизнес-требования(business requirements)

Бизнес-требования(business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements)

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements)

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Системные требования (system requirements)

Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Бизнес-правила (business rules)

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.

Нефункциональные требования

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

Характеристика продукта (feature)

Характеристика продукта (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта.

Какими характеристиками должны обладать хорошие требования?

Характеристики качества превосходных требований:

— Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

— Корректность. Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.

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

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

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

— Однозначность. Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.

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

Какими характеристиками должны обладать спецификации требований?

Набор требований, составляющий спецификацию, должен отвечать характеристикам:

— Полнота. Никакие требования или необходимые данные не должны быть пропущены.

— Согласованность. Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Несогласованность документов следует устранить до начала процесса разработки. Вы не всегда знаете, какое именно положение некорректно (если какое-то некорректно), пока не выполните исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен.

— Способность к модификации. Необходимо обеспечить возможность переработки требований, если понадобится, и поддерживать историю изменений для каждого положения. Для этого все они должны быть уникально помечены и обозначены, чтобы вы могли ссылаться на них однозначно. Каждое требование должно быть записано в спецификации только единожды. Иначе вы легко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные утверждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и указатель. Сохранение спецификации в базе данных коммерческого инструмента управления требованиями сделает их пригодными для повторного использования.

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

Шаблон спецификации требований к ПО

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

Шаблон спецификации требований

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

1. Введение
1.1 Назначение
1.2 Соглашения, принятые в документах
1.3 Границы проекта
1.4 Ссылки
2. Общее описание
2.1 Общий взгляд на продукт
2.2 Классы и характеристики пользователей
2.3 Операционная среда
2.4 Ограничения дизайна и реализации
2.5 Предположения и зависимости
3. Функции системы
3.x Функция системы X
3.x.1 Описание
3.x.2 Функциональные требования
4. Требования к данным
4.1 Логическая модель данных
4.2 Словарь данных
4.3 Отчеты
4.4 Получение, целостность, хранение и утилизация данных
5. Требования к внешним интерфейсам
5.1 Пользовательские интерфейсы
5.2 Интерфейсы ПО
5.3 Интерфейсы оборудования
5.4 Коммуникационные интерфейсы
6. Атрибуты качества
6.1 Удобство использования
6.2 Производительность
6.3 Безопасность
6.4 Техника безопасности
6.x [Другие]
7. Требования по интернационализации и локализации
8. Остальные требования
Приложение A. Словарь терминов
Приложение Б. Модели анализа

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

Внимание! Вы можете внедрять материал с помощью ссылки в другие документы, а не дублировать его в спецификации требований к ПО. Для этого можно использовать гиперссылки в качестве ссылок для отслеживания связей, определенных в средстве управления требованиями. С гиперссылками связан тот риск, что они могут «ломаться» при изменении иерархии папок, где хранятся документы.

Описание разделов шаблона спецификации требований

1. Введение
Введение представляет собой обзор, помогающий читателям разобраться в структуре и принципе использования спецификации требований к ПО.

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

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

1.3 Границы проекта
Кратко опишите ПО и его назначение. Покажите, как связан продукт с пользователями или корпоративными целями, а также с бизнес-целями и стратегиями. Если имеется отдельный документ о концепции и границах проекта, не повторяйте его содержимое, а просто сошлитесь на него. Если спецификацию требований к ПО предполагается разрабатывать постепенно, она должна содержать собственное положение о концепции и границах продукта в качестве подраздела долгосрочной стратегической концепции. Можно предоставить высокоуровневую сводку главной функциональности выпуска или функций, которые он должен выполнять.

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

2. Общее описание
В этом разделе представлен общий обзор продукта и среды, в которой он будет применяться, предполагаемая пользовательская аудитория, а также известные ограничения, предположения и зависимости.

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

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

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

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

2.5 Предположения и зависимости
Предположение (assumption) — это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного. Проблемы возможны в том случае, если предположение неверны, устарели, не находятся в совместном использовании или изменяются, поэтому определенные предположения можно отнести к группе рисков проекта. Один читатель спецификации требований к ПО может считать, что продукт будут соответствовать особому стандарту пользовательского интерфейса, тогда как другой предположит нечто совершенно иное. Разработчик может думать, что определенный набор функций написан специально для этого приложения, бизнес-аналитик — что он будет взят из предыдущего проекта, а менеджер проекта — что предполагается приобрести коммерческую библиотеку функций. Включаемые здесь предположения относятся к системной функциональности; предположения относящиеся к бизнесу представлены в документе концепции и границ проекта. Определите все зависимости проекта или создаваемой системы от внешних факторов или компонентов вне ее контроля. Например, до установки продукта может требоваться установить Microsoft .NET Framework 4.5 или более позднюю версию — это зависимость.

3. Функции системы
Приведенный здесь шаблон структурирован по функциям системы — это еще один способ систематизации функциональных требований. Другие методы классификации — по функциональным областям, рабочим потокам, вариантам использования, режимам работы, классам пользователей, стимулам и реакциям. Возможны также иерархические комбинации этих элементов, например варианты использования внутри классов пользователей. Не существует единственно правильного метода организации; выберите тот, при котором пользователям будет легче понять предполагаемые возможности продукта.
Опишем схему функций на примере.

3.x Функция системы X
Опишите название особенности несколькими словами, например «3.1 Проверка правописания». Так же назовите подразделы с 3.x.1 по 3.x.3 для каждой функции системы.

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

3.x.2 Функциональные требования
Перечислите по пунктам конкретные функциональные требования, которые связаны с этой функцией. Именно эти функции ПО нужно реализовать, чтобы пользователь мог использовать сервисы этой функции или реализовать вариант использования. Опишите, как продукт должен реагировать на ожидаемые ошибки, неправильный ввод информации или неверные действия. Присвойте каждому функциональному требованию уникальное имя. При использовании средства управления требованиями можно создать много атрибутов для каждого функционального требования, таких как основание, источник и состояние.

4. Требования к данным
Ценность информационных систем заключается в том, что они предоставляют возможность манипулировать данными. Используйте этот раздел шаблона для описания различных аспектов данных, которые будет потреблять система в качестве входной информации, как-то обрабатывать и возвращать в виде выходной информации.

4.1 Логическая модель данных
Модель данных это визуальное представление объектов и наборов данных, которые будет обрабатывать система, а также отношений между ними. Существует много видов нотации для моделирования данных, в том числе диаграммы отношений «сущность–связь» и диаграммы классов UML. Можно включить модель данных для бизнес-операций, выполняемых системой или логическое представление данных, с которыми будет работать система. Это не то же самое, что модель данных реализации, которая реализуется в виде дизайна базы данных.

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

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

4.4 Получение, целостность, хранение и утилизация данных
Если это важно, опишите, как получают и обслуживают данные. Например, при открытии канала номенклатуры данных может требоваться первым делом выполнить начальный дамп всей номенклатуры данных в принимающую систему, а после этого использовать каналы для передачи только изменений. Укажите все требования, относящиеся к защите целостности данных системы. Укажите все процедуры, которые могут потребоваться, например резервное копирование, создание контрольных точек, зеркальное отображение или проверка корректности данных. Укажите политики, которые должна применять система для хранения или утилизации данных, в том числе временных данных, метаданных, остаточных данных (таких как удаленные записи), данных в кеше, локальных копий, архивов и промежуточных архивов.

5. Требования к внешним интерфейсам
В этом разделе указывается информация, которая гарантирует, что система будет правильно взаимодействовать с пользователями и компонентам внешнего оборудования и ПО. Выработка согласия по внешнему и внутреннему интерфейсу системы признано оптимальным приемом в области разработки ПО (Brown, 1996). В сложной системе с множеством подкомпонентов следует использовать раздельные спецификации для интерфейсов или спецификацию системной архитектуры. В документацию по интерфейсу можно включить ссылки на материал из других документов. Например, ссылка может указать на руководство по работе с устройством, где перечислены коды ошибок, которые устройство может отправить программе.

Войны интерфейсов
Две команды разработчиков ПО объединились для создания флагманского продукта компании A. Datum Corporation. Команда, отвечающая за базу знаний, создала сложное ядро анализа на C++, а команда, отвечающая за приложения, реализовала пользовательский интерфейс на Java. Подсистемы взаимодействовали между собой посредством API. К сожалению, команда, отвечающая за базу знаний, периодически модифицировала API, в результате чего систему не удавалось собрать и запустить на выполнение должным образом. Команде, отвечающей за приложения, требовалось несколько часов, чтобы распознать все проблемы и определить основную причину — изменение API. Эти изменения не согласовывались, не доводились до сведения всех заинтересованных в проекте лиц и не были скоординированы с соответствующими модификациями в коде на Java. Изменение интерфейса обязательно требует уведомления об этом людей, группы или системы на другой стороне этого интерфейса. Интерфейс скрепляет компоненты вашей системы — включая пользователей, поэтому необходимо документировать детали интерфейса и синхронизировать модификации в процессе управления изменениями в проекте.

5.1 Пользовательские интерфейсы
Опишите логические характеристики каждого пользовательского интерфейса, который необходим системе. Некоторые особенные характеристики пользовательских интерфейсов могут упоминаться в разделе «6.1 Удобство использования». Некоторые из них перечислены здесь:
• ссылки на стандарты графического интерфейса пользователей или стилевые рекомендации для семейства продуктов, которые необходимо соблюдать;
• стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем, последовательностей полей вкладок, часто используемых элементов управления, графики фирменного стиля, уведомления о зарегистрированных товарных знаках и о конфиденциальности и т.п.;
• размер и конфигурация экрана или ограничения разрешения;
• стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки;
• сочетания клавиш;
• стандарты отображения и текста сообщений;
• стандарты проверки данных (такие как ограничения на вводимые значения и когда нужно проверять содержимое полей);
• стандарты конфигурации интерфейса для упрощения локализации ПО;
• специальные возможности для пользователей с проблемами со зрением, различением цвета и другими ограничениями.

5.2 Интерфейсы ПО
Опишите связи продукта и других компонентов ПО (идентифицированные по имени и версии), в том числе другие приложения, базы данных, операционные системы, средства, библиотеки, веб-сайты и интегрированные серийные компоненты. Укажите назначение, форматы и содержимое сообщений, данных и контрольных значений, обмен которыми происходит между компонентами ПО. Опишите соответствия между входными и выходными данными между системами и все преобразования, которые должны происходить с данными при перемещении между системами. Опишите службы, необходимые внешним компонентам ПО, и природу взаимодействия между компонентами. Определите данные, которыми будут обмениваться и к которым будут иметь общий доступ компоненты ПО. Определите нефункциональные требования, влияющие на интерфейс, такие как уровни обслуживания для времени и частоты отклика или меры и ограничения безопасности. Часть этой информации может быть определена как требования к данным в разделе 4 или как требования к взаимодействию в разделе «6. Атрибуты качества».

5.3 Интерфейсы оборудования
Опишите характеристики каждого интерфейса между компонентами ПО и оборудования системы. В описание могут входить типы поддерживаемых устройств, взаимодействия данных и элементов управлений между ПО и оборудованием, а также протоколы взаимодействия, которые будут использоваться. Перечислите входные и выходные данные, их формат, разрешенные значения или их диапазоны, а также все временные характеристики, о которых должны знать разработчики. Если такой информации очень много, лучше создать отдельный документ спецификации интерфейса.

5.4 Коммуникационные интерфейсы
Укажите требования для любых функций взаимодействия, которые будут использоваться продуктом, включая электронную почту, веб-браузер, сетевые протоколы и электронные формы. Определите соответствующие форматы сообщений. Опишите особенности безопасности взаимодействия или шифрования, скорости передачи данных и механизмов согласования и синхронизации. Укажите все ограничения этих интерфейсов, например допустимость тех или иных типов вложений в сообщениях электронной почты.

6. Атрибуты качества
В этом разделе описываются нефункциональные требования помимо ограничений, описанных в разделе 2.4, и требований к внешним интерфейсам, описанным в разделе 5. Эти характеристики должны быть точно определены и поддаваться проверке и измерению. Укажите относительные приоритеты различных атрибутов, например приоритет простоты использования над легкостью изучения или приоритет безопасности над производительностью. Необходимые степени качества удается гораздо эффективнее описать с помощью подробных нотаций спецификации, таких, как Planguage, чем с помощью простых описательных утверждений.

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

6.2 Производительность
Укажите конкретные требования к производительности для различных системных операций. Если у различных функциональных требований или функций имеются разные требования к производительности, то следует указывать задачи, связанные с производительностью, там же, в разделе соответствующих функциональных требований, а не включать их все в этот раздел.

6.3 Безопасность
Укажите все требования, касающиеся безопасности или конфиденциальности, которые ограничивают доступ или возможности использования продукта. Это может быть физическая безопасность, а также защита данных или ПО. Источником требований к безопасности, как правило, являются бизнес-правила, поэтому определите политики или положения, касающиеся защиты или конфиденциальности, которым продукт должен соответствовать. Если они задокументированы и хранилище бизнес-правил, просто сошлитесь на них.

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

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

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

8. [Остальные требования]
Определите все другие требования, которые еще не были описаны в спецификации требований к ПО. Примером могут служить юридические, законодательные или финансовые требования и требования стандартов, требования к установке, конфигурированию, запуску и остановке продукта, а также к журналированию, мониторингу и контрольному следую. Вместо того чтобы сливать всю эту информацию в один раздел, добавьте любые новые разделы к шаблону вашего проекта. Пропустите этот раздел, если все необходимые требования уже расписаны в других разделах. В этот раздел можно включить требования к переходу, которые необходимы для миграции с предыдущей системы на новую, если они относятся к создаваемому ПО (например, программы преобразования данных), в противном случае их можно включить в план управления проектом (например, разработка обучающих материалов или поставка).

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

Приложение Б. Модели анализа
В этом необязательном разделе описывается, а точнее напоминается, о таких моделях анализа, как диаграммы потоков данных, деревья функций, диаграммы переходов состояния и диаграммы «сущность-связь». Часто читателю удобнее, когда определенные модели внедрены в соответствующие разделы спецификации, а не собраны скопом в конце.

Требования к продукту пример

Спецификация требований к программному обеспечению (SRS) описывает комплекс всех требований, связанных с проектом. При наличии плана управления требованиями следует свериться с ним для определения правильного расположения и организации требований. Например, может оказаться желательным иметь отдельные SRS для описания полных требований к программному обеспечению для каждой возможности в определенном выпуске продукта. Это может включать несколько вариантов использования из системной модели вариантов использования для описания функциональных требований для этой возможности, а также соответствующего набора подробных требований, содержащихся в вспомогательных спецификациях.

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

Документ или пакет?

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

От видения к SRS

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

Нам требуется уже набор, или пакет, артефактов, который полностью описывает наблюдаемое поведение системы, то есть пакет, указывающий, какие возможности предоставляет система и как они реализуются. Это и называется пакетом SRS.

Динамический артефакт

Пакет SRS — это не застывший фолиант, напечатанный ради совместимости с ISO 9000 и затем поставленный на полку. Это живой объект, с которым работают разработчики проекта. Он служит основой для коммуникации между разными группами — между самими разработчиками, а также разработчиками и пользователями или заинтересованными лицами. Формально или неформально, он представляет своего рода договор между сторонами, если что-либо не отражено в пакете SRS, то разработчики не должны над этим работать. А если что-либо отражено в пакете SRS, то они полностью отвечают за реализацию этой функциональности.

Стандартный документ руководителя проекта

SRS служит стандартным документом для руководителя проекта. Руководитель проекта обычно не имеет времени и возможностей для чтения кода, созданного разработчиками и сравнения его с документом Видение. Вместо этого в обсуждениях с коллективом проекта он опирается на пакет SRS.

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

Определение функциональных требований

Определение нефункциональных требований

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

1.1 Предположения и нерешенные вопросы

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

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

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

Все нерешенные вопросы, которые могут помешать успешному ходу проекта

Эти вопросы следует обсуждать с заказчиком в конце каждого этапа. Также следует обсудить предположения, и тоже в конца этапа, хотя заказчик не всегда будет готов обсуждать менее значимые проблемы.

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

1.2 Расположение организации заказчика

Отразите в документе расположение учреждений заказчика.

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

2 Заданные условия

2.1 Заранее выбранные пакеты приложений?

Указана ли в требованиях необходимость использования каких-либо пакетов приложений? Если в проекте необходимо использовать один из стандартных пакетов программного обеспечения, который задает логику программного обеспечения и организацию данных, это является одним из важных исходных положений. Некоторые пакеты программного обеспечения допускают гибкость и обеспечивают широкие возможности настройки, другие же этого не допускают. Набор пакетов может повлиять на выбор следующих компонентов:

• Тип рабочих станций
• Методы соединения
• Тип процессора и запоминающего устройства с прямым доступом (DASD)
• Программа управления системой
• Организация, размещение данных и управление
• Язык программирования
• Пакетные интерфейсы
• Взаимосвязь процессов и данных
• Бизнес-логика
• Проект пользовательского интерфейса
• Параметры производительности и обеспечения готовности
• Архитектура и форматы печати (например, PostScript, PCL, IPDT)
• Поддержка национальных языков (NLS)

Важно понимать, как выбор того или иного пакета влияет на проекты. Если в число заданных условий входит тот или иной пакет, вам потребуются навыки работы с ним. Для этого можно привлечь:

• поставщика пакета
• внешних консультантов
• специально обученных участников коллектива

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

2.2 Прочие заданные условия

Отразите в документе все прочие заданные условия, которые могут ограничить варианты проекта.

Это позволяет отразить все особые требования, не относящиеся к уже рассмотренным задачам, которые могут повлиять на проектные решения, а именно:

• применение существующих процессоров или версий операционной системы
• применение существующего парка рабочих станций
• применение существующего сетевого оборудования
• применение существующих практик управления системами
• применение специфической модели, например: ‘необходимо использовать в проекте модель клиент-сервер с четким разграничением логики презентации, бизнеса и доступа к данным и описанием их интерфейсов’.

Повлияют ли эти заданные условия на новую систему? Если система будет работать на существующем процессоре, в операционной системе или сети, повлияют ли на нее особенности существующей платформы и нагрузки?

Какая доля ресурсов сети и процессоров уже занята существующими задачами?

Какие механизмы защиты используются задачами? Примите во внимание эти данные и сравните их с требованиями новой системы.

Каковы параметры обеспечения готовности существующей системы?

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

2.3 Специальное аппаратное обеспечение

Указана ли в требованиях необходимость использования какого-либо специального аппаратного обеспечения?

Это может быть отражено в общих терминах (система должна поддерживать высокоскоростной графопостроитель) или в более конкретных (поддержка банкоматов корпорации Panda). Задокументируйте следующее:

• Предварительные требования к аппаратному и программному обеспечению
• Поставщики и их службы поддержки
• Поддержка национальных языков (NLS)
• Криптография

2.4 Существующие данные

Указана ли в требованиях необходимость использования существующих данных? Если да, отразите это в проекте системы. Задокументируйте следующее:

• В каких системах расположены данные
• Структура данных — простой файл или база данных
• Объем данных
• Пользователи и системы, работающие с этими данными
• Замечания по готовности (например, периоды недоступности данных из-за обслуживания базы данных или пакетных задач)
• Возможность копирования или перемещения данных

3.1 Техническая архитектура / стратегический план

Имеет ли клиент техническую архитектуру, стратегический план ИТ или эквивалентный набор стандартов?

Техническая архитектура может быть сведена к следующему:

• Техническая платформа предприятия
• Техническая инфраструктура предприятия
• Технологическая архитектура

В технической архитектуре могут быть указаны следующие моменты:

• Число и возможность использования вычислительных центров
• Сетевая инфраструктура глобальной сети предприятия (WAN)
• Локальные сети подразделений (LAN)
• Развитость служб клиент-серверной инфраструктуры (промежуточное программное обеспечение)

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

• Методы разработки новых приложений
• Принятый набор поддерживаемых продуктов, например:

· аппаратное обеспечение
· программное обеспечение управления системой
· прикладное программное обеспечение общего назначения, например, офисное
· справочная служба
· правила защиты

• Архитектура подсистемы печати

Это список может быть очень обширным, а его элементы могут быть регламентированы очень строго или вообще не регламентированы.

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

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

Задокументируйте степень открытости клиента (то есть независимость от поставщика и возможность взаимодействия). Если есть техническая архитектура, то ваш проект почти всегда должен будет ей отвечать. Прочитайте ее описание и отметьте все правила, которые повлияют на проектирование системы.

3.2 Сетевая архитектура

Имеется ли у клиента архитектура сети, которой должна отвечать эта система? Архитектура сети — это общий набор правил взаимодействия в сети и общая транспортная инфраструктура. В нее могут входить определение магистральной сети, включая концентраторы и каналы. Если такая архитектура имеется, то необходимо изучить ее и сформулировать следующее:

Замечания по физической топологии (то есть является ли сеть районной или городской, и много ли к ней подключено устройств).

Какие функции соединения поддерживаются текущей инфраструктурой сети.

Какие стандарты связи (SNA, OSI, TCP/IP) применяются для поддержки этих функций.

Какие поддерживаются интерфейсы программирования.

Все определения архитектуры сети, относящиеся к связи между клиентами и сервером, или уровни модели базовой системы:

• Доступ к данным серверов баз данных в сети должен осуществляться клиентами по протоколу какой-либо конкретной базы данных.
• Логика презентации должна быть реализована в клиенте, а логика доступа к данным — только не центральном хосте.

3.3 Стратегии соединений

Есть ли у клиента заданные стратегии соединений?

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

Задокументируйте все стратегии относительно следующих факторов:

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

3.4 Прочие стратегии

Есть ли у клиента другие правила, стратегии или стандарты, не отраженные в его требованиях? Например:

• Интерфейс системы должен разрабатываться на принципах объектно-ориентированного программирования и поддерживать операции перетаскивания мышью.
• Все новые системы должны строиться в модели клиент-сервер.
• Все новые системы должны строиться на открытых стандартах
• Стандарты и правила для поддержки национальных языков (NLS), особенно, если применяются операции с текстом, читаемым справа налево.
• Стратегия защиты, включающая управление ролями и стандарты для идентификации пользователей, прав доступа и защиты данных.
• Стандарты обмена данными между приложениями (такие как UNEDIFACT или VISA), которые могут подразумевать применение специального оборудования для связи или защиты.

Если есть и другие стратегии, их необходимо понять и иметь к ним доступ, чтобы проектирование осуществлялось в соответствии со стандартами на всех этапах процесса проектирования. Если применяется готовое программное решение, оно также может подразумевать применение определенных стандартов.

Разрешается ли пользователям или отделам добавлять и/или разрабатывать собственные программы:

• на рабочих станциях
• на серверах (особенно в связи с использованием дисковой памяти)

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

4.1 Единицы измерения

Вместе с разработчиками добейтесь того, чтобы выделить в бизнес-процессе структурные единицы, такие как бизнес-процессы меньшего масштаба или транзакции.

Цель этого состоит в том, чтобы добиться возможности количественно оценивать факторы процесса.

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

Деловой «процесс», например, обработка заказа, обычно выполняет «приложение» (термин из информационных технологий) или несколько приложений. Внутри каждого «приложения» обычно выполняется много «транзакций», например, запрос наличия на складе, составление письма для заказчика.

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

4.2 Количественные показатели

Для каждой из сущностей из пункта 4.1 задокументируйте количественные показатели, например:

• Сколько пользователей будет работать с каждым бизнес-процессом или приложением в среднем и в моменты пиковой нагрузки
• Когда возникает пиковая нагрузка (ежедневно, еженедельно, ежемесячно и т.д.)
• С какой скоростью должны обрабатываться транзакции в среднем и в моменты пиковой нагрузки
• Число элементов данных и экземпляров в каждой группе и их количественные показатели.

4.3 Критерии производительности бизнес-процесса

Клиент может задать критерии производительности для каких-либо бизнес-процессов. Однако необходимо также задокументировать целевые показатели производительности для системных процессов (например, резервного копирования) и разработки приложения. Для каждой категории укажите следующее:

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

5 Обеспечение готовности

5.1 Советы по обеспечению готовности

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

1. Определите фактических пользователей системы, их бизнес-процессы и часы выполнения этих бизнес-процессов
2. Оцените влияние доступности или недоступности службы на способность пользователей выполнять свои бизнес-задачи
3. Определите требования по обеспечению готовности, непосредственно отражающие то, что необходимо пользователям для выполнения своих бизнес-задач.
4. Учтите, что если уже выбран программный пакет решения, то его структура и проект могут сильно повлиять на параметры готовности приложения, с которым работают пользователи. Если пакет не был спроектирован для непрерывной работы, до с этим могут быть большие сложности, особенно в периоды обслуживания и пакетных операций.

При формулировке требований примите во внимание следующее:

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

• Формулировка «Система должна работать 24 часа в сутки, чтобы пользователи в США и Китае могли работать» оставляет проектировщику гораздо меньше вариантов, чем формулировка «Пользователи из Нью-Йорка должны иметь возможность выполнять транзакции со своими данными с 7 до 19 часов по времени Нью-Йорка, и пользователи из Гонконга должны иметь возможность выполнять транзакции со своими данными с 7 до 19 часов по времени Гонконга». Во втором варианте у проектировщика появляется возможность спланировать обслуживание одного из компонентов системы в отведенные для этого часы, в то время как компонент для другого часового пояса будет продолжать работать.
• В приложении банкомата может быть очень важным обеспечить возможность выдачи денег в 3 часа утра в понедельник, но возможность получения в это время справки об остатке на счете может быть менее важной.
• Разделите желательные и обязательные требования по обеспечению готовности. Например: «Банкомат ДОЛЖЕН круглосуточно принимать депозиты и выдавать наличные. ЖЕЛАТЕЛЬНО, чтобы банкомат мог выдавать сведения об остатке на счете круглосуточно, однако допустимы кратковременные периоды недоступности этой функции, которые ДОЛЖНЫ длиться не более 10 минут и иметь место только от 3:00 до 4:00 утра».
• Если влияние какого-либо требования на способность пользователей выполнять свои бизнес-задачи не прослеживается явно, то скорее всего это требование не стоит относить к требованиям по обеспечению готовности системы.
• Требования по обеспечению готовности, которые лишь косвенным образом влияют на возможности пользователей (например, «Контрольная система сообщений должна работать непрерывно»), не будут столь же критичны, как те, которые влияют непосредственно («Банкоматы должны уметь выполнять то-то и то-то»).

5.2 Запланированное рабочее время

Для каждого из бизнес-процессов и групп пользователей, которые с ними работают, определите часы, в которые пользователи должны иметь возможность работать с процессом. Сделайте это и для процессов, которые не связаны прямо с группами пользователей.

Если группы пользователей относятся к разным часовым поясам (как Нью-Йорк и Гонконг), считайте их разными группами пользователей.

Также примите во внимание выходные дни и праздники, когда приложение не будет в работе. Проектировщик может запланировать расширенное обслуживание на такие дни. Какие изменения в рабочем времени можно предположить в течение времени жизни приложения?

На рабочее время системы может влиять также рабочее время других систем, с которыми она взаимодействует.

Какие изменения в часах обслуживания можно предположить в течение времени жизни приложения?

5.3 Стоимость простоя системы

Оцените влияние на бизнес, финансовые потери и риски, связанные с отказом системы в запланированное рабочее время.

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

• Краткие периоды недоступности системы или замедленный ответ в рабочее время. Определите, что такое «краткие периоды» и «замедленный ответ» для этого конкретного приложения (см. «Критерии производительности бизнес-процесса»)
• Различные более длительные периоды отказа в указанные часы (минута, несколько минут, полчаса, час, три часа и т.д.)
• Более длительные периоды (смена, день, несколько дней) .
• Сделайте это и для процессов, которые не связаны прямо с группами пользователей (например, суточный клиринг чеков).

При оценке влияния различных отказов определите резервные процедуры и их способность снизить потери от простоя.

Постарайтесь оценить это влияние количественно (потеря рабочего времени персоналом, простой оборудования, потери в текущем бизнес-процессе, вероятные потери в будущем из-за неудовлетворенности заказчика, проценты, штрафы и пр.) .

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

Как в течение времени эксплуатации системы будет меняться влияние отключения системы на сумму убытков?

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

• Рабочая функция 1 Чтение и обновление записи об ассортименте.
• Запасная функция 1 Ввод записи об ассортименте и постановке ее в очередь для будущего обновления.
• Рабочая функция 2 Чтение текущего остатка на счете заказчика.
• Запасная функция 2 Чтение остатка на счете заказчика из другого источника, возможно, не самых последних данных.
• Рабочая функция 3 Обновление дневника в компьютере.
• Запасная функция 3 Обновление печатной копии дневника.

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

Если система перестала работать в рабочее время, то влияние отказа будет зависеть от его длительности и прочих условий. Некоторые неисправности могут почти не повлиять на работу (кратковременные, во время малой загрузки, влияющие на небольшую группу пользователей, или для которых предусмотрены резервные процедуры). Более длительные отключения или произошедшие в горячее время дня могут оказать более существенное влияние.

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

5.4 Критерии готовности и восстановления

Определите Критерии готовности и восстановления, которые должны быть применимы к «штатным» ситуациям.

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

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

• Процент отказов, восстановленных в течение заданного времени
• Максимальное время в течение недели/месяца/года, когда пользователь не может выполнять какие-либо функции

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

Не следует указывать недопустимо строгие критерии готовности, так как это может заметно повысить стоимость реализации. Вообще говоря, если какой-либо из вариантов отказа системы не приводит к заметным убыткам или рискам, то скорее всего этот вариант можно не учитывать при определении условий для критериев готовности.

Если в течение времени эксплуатации системы возможно смещение рабочих часов или изменение рисков, связанных с простоем системы, то в критериях обеспечения готовности нужно отразить, как они будут меняться соответственно.

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

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

5.5 Восстановление после аварии

Рассмотрите «форс-мажорные» ситуации, такие как длительный выход из строя всего компьютерного оборудования. Если они возможны, каковы должны быть критерии восстановления?

Учтите, что средства восстановления после аварии требуются не для всех бизнес-процессов. Выделите только критические процессы, для которых такое восстановление необходимо. Даже среди этих процессов не все функции одинаково существенны.

• Как быстро должна быть восстановлена работа? Отсчитывается ли это время с момента аварии или с момента принятия решения о переносе работы в другое место?
• При каких условиях организация может перенести работу в другой офис, вместо восстановления локального?
• Насколько могут отличаться данные в другом офисе от текущих для продолжения работы (должны точно совпадать, могут устаревать на несколько минут или даже на день)?
• Когда должна быть восстановлена работа в удаленном офисе?
• В какой момент времени?
• Каковы приоритеты в удаленном офисе для этого набора приложений в сравнении с прочими бизнес-приложениями, работающими на том же оборудовании?

Обратите внимание, что критерии могут быть разными в зависимости от части системы или типа аварии.

Какие изменения в требованиях к восстановлению после аварии ожидаются в течение времени эксплуатации приложения?

5.6 Прочие замечания по обеспечению готовности

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

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

a. Выполнять запросы, но не обновлять при этом данные?

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

2. При отказах, приводящих к необходимости восстановления данных, что будет важнее:

c. Восстановить работу как можно скорее, даже если при этом данные будут не самыми свежими? Или

d. Восстановить текущее состояние данных, даже если при этом система будет выключена дольше?

3. Должны ли запросы пользователей «приниматься в обработку» на время отказа, или пользователь сможет потом повторить запрос после восстановления работы?

4. Есть ли прочие факторы, которые могут повлиять на доступность системы (например, бизнес-правило, указывающее, что процесс A не может быть доступным пользователям, если недоступен процесс B)?

Могут ли эти факторы изменяться со временем?

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

6.1 Требования по защите

1. Определите данные, которые необходимо защищать

2. Определите виды угроз, которым могут быть подвержены данные:

• Случайное повреждение или уничтожение
• Намеренное повреждение или уничтожение
• Промышленный шпионаж
• Мошенничество
• Взлом
• Вирусы

1. Определите угрозы физическим данным:

• Кража компонентов
• Несанкционированный доступ к оборудованию
• Физическая безопасность пользователей

2. Определите людей, которые могут быть источником опасности:

• Персонал центра данных
• Прочие специалисты ИТ (например, разработчики)
• Прочие сотрудники организации
• Посторонние личности

3. Определите все особые меры безопасности, особенно в связи со следующими аспектами:

• Доступ к системе
• Шифрование данных
• Возможность аудита

4. Есть ли какие-либо общие положения, например, акты о свободе информации, которые могут повлиять на проектирование защиты системы?

5. В состав некоторых программных пакетов включены собственные средства защиты. Если в число заданных входит тот или иной пакет, вам потребуются знания о его средствах защиты.

При определении и формулировке требований по защите используйте следующие подходы:

1. Перечислите объекты, физические и логические, для которых требуется защита.

2. Определите степень открытости объекта. Например:

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

Обратите внимание, что разные объекты могут быть подвержены разным опасностям.

3. Определите все угрозы, связанные со средой. Например:

• Недовольные сотрудники
• Неправомочные сотрудники
• Открытые терминальные сеансы в общедоступных местах
• Хакеры
• Подслушивающие устройства
• Потеря оборудования (например, утеря ноутбука)

4. Для каждого объекта определите угрозы и свяжите их с разными возможностями доступа.

Для некоторых объектов требования по защите могут включать также условия фиксированного расположения (жесткий диск) и мобильного использования.

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

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

• Секретная военная система
• Система обращения денег
• Система, в которой хранится конфиденциальная личная информация

Если к защите системы предъявляются особые требования, то к проектированию этих аспектов может потребоваться привлечь специалиста в области защиты.

7 Удобство работы

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

Требования удобства работы должны определяться по минимуму функций, предоставляемых системой для работы. Не следует исходить из того, что в принципе может сделать система. Другими словами, требования удобства работы — это не максималистская цель. Они должны обеспечивать минимальный уровень удобства работы. Конечно, после того, как эта цель достигнута, можно продолжать улучшать удобство работы.

Для достижения этой цели лучше всего сравнить систему с имеющимися альтернативами. Будет разумно ожидать от системы, что она будет существенно удобнее в работе, чем ее альтернативы. Эти альтернативы могут быть следующими:

• Существующие ручные процедуры.
• Действующие системы.
• Конкурирующие продукты.
• Ранние версии системы.

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

Ниже приведены примеры общих требований удобства работы:

• Максимальное время выполнения — сколько будет тратить времени обученный пользователь на выполнение типичной задачи.
• Максимальное число ошибок — сколько ошибок будет допускать обученный пользователь при выполнении типичной задачи.
  Учитывать следует только неисправимые ошибки, которые влекут негативные последствия для организации, например, упущенная выгода, поломка оборудования. Если ошибку можно исправить, то она повлияет только на измеренное время выполнения.
• Время обучения — сколько времени требуется пользователю, чтобы научиться выполнять задачу быстрее, чем за указанное максимальное время.

Ниже приведен пример требований удобства работы для варианта использования обработки входящих почтовых сообщений.

• Пользователь должен уметь управлять почтовыми сообщениями одним щелчком мыши.
• Пользователь должен уметь просматривать почтовые сообщения одним нажатием клавиши.
• Пользователю не должны мешать в работе приходящие почтовые сообщения.

© Copyright IBM Corp. 1987, 2006. Все права защищены..