Объяснение

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

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

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

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

От видения к SRS

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

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

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

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

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

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

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

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

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

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

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

1 Общее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 Стандарты

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

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

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

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

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

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

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

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

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

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

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

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

• OSI или SNA
• UNIX**
• SAA
• PS/2* с OS/2* EE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 Числа

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 Защита

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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