Требования к информационной системе в строительстве

Cвязаться с другим человеком;Сделать Звонок
Отправить СМС;1 — Must
2 — Should Скоротать время;Поиграть в казуальную Игру
Посмотреть Фотографии;4 — Would
3 — Could Сохранить визуальную информацию;Сделать Фотографию;2 — Should

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

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

4. Для каждого высокоприоритетного (Must или Should) UC определить контекст применения, конечную цель и результат

Это можно оформить в виде списка или таблицы, например в Notion:

Имя;UC 1.Сделать Звонок Область действия;Мобильный телефон Контекст;Организовать удалённое голосовое взаимодействие с другим человеком Актор;Пользователь мобильного телефона, Внешний абонент Цель;Поговорить с другим человеком (внешним абонентом) по телефонной связи Результат (постусловия);Состоялся телефонный разговор пользователя с желаемым человеком длительностью не менее 3-х секунд

Разработка корпоративных информационных систем — Сергей Зыков

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

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

Как может выглядеть черновик сценария основного потока юскейса:

1. Пользователь даёт команду совершить звонок
2. Система запрашивает номер телефона вызываемого абонента
3. Пользователь сообщает номер абонента
4. Система убеждается в корректности указанного номера телефона
5. Система вызывает абонента с указанным номером телефона
6. Система убеждается, что звонок начался
7. Система передаёт голос собеседников в ходе разговора

Для наглядности можно нарисовать эту линейную последовательность шагов в виде простого процесса в нотациях EPC, BPMN (рис.1), UML activity или sequence, а также блок-схемы алгоритма по ГОСТ 19.701−90.

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

6. Дополнить линейную последовательность основного потока в описании UC расширениями, исключениями и циклами

На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.

Вместо BPMN для отображения логики сценария нашего юскейса можно использовать любую другую нотацию (EPC, UML activity diagram, IDEF3 или даже простого текстового алгоритма).

Челышков П.Д. и Панчуков Н.А. ТИМ в деятельности государственного заказчика: особенности, проблемы

7. Собрать воедино результаты выполнения трёх предыдущих шагов, детально описав каждый UC как алгоритм взаимодействия пользователя с системой

На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:

• Имя
• Приоритет
• Область действия
• Контекст
• Актор
• Цель
• Предусловия
• Результат (постусловие)
• Основной поток
• Расширения или альтернативные потоки
• Бизнес-правила

Имя;Пишется в формате глагол-существительное, которое описывает достижимую цель и объясняет смысл сценария;UC 1. Сделать Звонок Приоритет;Ранг важности относительно других юскейсов, очерёдность реализации;Must Область действия;Это может быть предприятие, несколько информационных систем (ИТ-инфраструктура), проектируемая система или целый программно-аппаратный комплекс;Мобильный телефон Контекст;Окружение, в котором применяется этот UC, условия или бизнес-процесс;Организация удалённого голосового взаимодействия с другим человеком Актор;Действующее лицо, кто-то или что-то вне системы, влияющий на неё или находящийся под её влиянием. Это может быть человек, устройство, другая система или подсистема;Пользователь мобильного телефона, Внешний абонент Цель;Краткое описание, чего актор хочет достигнуть с этим вариантом использования;Поговорить с другим человеком (внешним абонентом) по телефонной связи Предусловия;Условия, которые должны быть выполнены для того, чтобы выполнялся сценарий;• Мобильный телефон включен
• Уровень заряда мобильного телефона достаточен для совершения звонка
• Мобильный телефон доступен для активных действий (не находится в состоянии блокировки) Триггер;Событие, инициирующее выполнение сценария;Пользователь вызвал команду «Позвонить» Результат (постусловия);Новый объект или изменение состояния существующего объекта, который показывает, что актор достиг своей цели;Состоялся телефонный разговор пользователя с внешним абонентом длительностью не менее 3-х секунд Основной поток;Типичный последовательный порядок пронумерованных шагов;1. Пользователь вызвал команду «Позвонить»
2. Система запрашивает номер телефона вызываемого абонента
3. Пользователь вводит данные номера телефона вызываемого абонента
4. …. Расширения;Исключения из шагов основного потока, которые обрабатываются по своим алгоритмам согласно бизнес-логике процесса;4а. Номер телефона некорректен
4а.1 Система убеждается, что введённый номер телефона вызываемого абонента не соответствует шаблону из последовательности цифр от 6 до 11 цифр, содержит буквы или другие символы
2а.2 Система уведомляет пользователя о том, что номер телефона указан некорректно и звонок по нему не может быть совершён
2а.3 Возврат к шагу 2 основного потока Бизнес-правила;Ссылка на организационные и другие регламенты, которые уточняют происхождение данного UC. Например, сроки обработки клиентских заявок, утверждённые внутри компании;Поддерживается связь только двух абонентов

Эту структуру можно представить в текстовом виде или, для наглядности, в виде таблицы. Давайте завершим описание этого юскейса так, как мы делаем это на реальных проектах, то есть полностью опишем happy path и альтернативные сценарии.

Имя;UC 1.Сделать Звонок Приоритет;Must Область действия;Мобильный телефон Контекст;Организовать удалённое голосовое взаимодействие с другим человеком Актор;Пользователь мобильного телефона, Внешний абонент Цель;Поговорить с другим человеком (внешним абонентом) по телефонной связи Предусловия;• Мобильный телефон включен
• Уровень заряда мобильного телефона достаточен для совершения звонка
• Мобильный телефон доступен для активных действий (не находится в состоянии блокировки) Триггер;Пользователь вызвал команду «Позвонить» Результат (постусловия);Состоялся телефонный разговор пользователя с внешним абонентом длительностью не менее 1-й секунды Основной поток;1. Пользователь вызвал команду «Позвонить»
2. Система запрашивает номер телефона вызываемого абонента
3. Пользователь сообщает номера телефона вызываемого абонента
4. Система убеждается в корректности введённого номера телефона вызываемого абонента
5. Система вызывает абонента по введённому номеру телефона
6. Система дожидается ответа вызываемого абонента
7. Происходит обмен данными, то есть:

nbspnbspnbspnbspnbspnbspb.nbsp Пользователь голосом передаёт данные для внешнего абонента
nbspnbspnbspnbspnbspnbspd.nbspСистема убеждается в том, что пользователь продолжает разговор с внешним абонентом Расширения;4а. Номер телефона некорректен

4а.1 Система убеждается, что введённый номер телефона вызываемого абонента не соответствует шаблону из последовательности цифр от 6 до 11 цифр, содержит буквы или другие символы
2а.2 Система уведомляет пользователя о том, что номер телефона указан некорректно и звонок по нему не может быть совершён
2а.3 Возврат к шагу 2 основного потока

6а. Внешний абонент недоступен для разговора

6а.1 Внешний абонент находится вне зоны действия сети
6а.2 Система уведомляет пользователя о том, что внешний абонент недоступен
6а.3 Система завершает выполнение сценария

6б. Внешний абонент недоступен для разговора

6б.1 Внешний абонент занят
6б.2 Система уведомляет пользователя о том, что внешний абонент занят
6б.3 Система завершает выполнение сценария

7а. Внешний абонент завершил разговор

7а.1 Внешний абонент вызвал команду завершения звонка
7а.2 Система уведомляет пользователя о том, что внешний завершил разговор
7а.3 Система завершает выполнение сценария

7б. Пользователь завершил разговор

7б.1 Пользователь вызвал команду завершения звонка
7б.2 Система уведомляет пользователя о том, что разговор завершён
7б.3 Система завершает выполнение сценария

7в. Пользователь продолжает разговор с внешним абонентом

7в.1 Пользователь продолжает голосом передавать данные для внешнего абонента
7в.2 Возврат к шагу 7 основного потока

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

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

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

Если у клиента есть промо-код на скидку по конкретному курсу, сумма в договоре будет снижена на размер скидки.

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

• FRQ1Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
• FRQ2Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору
• FRQ2Система должна предоставить пользователю с ролью «Клиент» возможность удалить курсы из договора
• FRQ4Система должна предоставить пользователю с ролью «Клиент» оплатить сумму по заключенному договору через шлюз онлайн-оплаты
• FRQ5Система должна предоставить пользователю с ролью «Клиент» снизить сумму по заключенному договору с применением промо-кода на скидку

Шаг 1. Определяем акторов. Судя по требованиям, с системой взаимодействует клиент и шлюз оплаты.

Шаг 2. Сформируем реестр юскейсов. Для этого мы можем, например, представить имеющийся набор функциональных требований в виде UML-диаграммы вариантов использования (UML Use case diagram).

Чтобы составить реестр юскейсов, давайте выделим из ранее представленных юскейсов именно те, что имеют бизнес-ценность для пользователя без привязки к системе.

Клиент;UC1 Заключить договор;FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах

FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору

FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность удалить курсы из договора — Клиент
— Шлюз онлайн-оплаты;UC2 Оплатить договор;FRQ4 Система должна предоставить пользователю с ролью «Клиент» оплатить сумму по заключённому договору через шлюз онлайн-оплаты

FRQ5 Система должна предоставить пользователю с ролью «Клиент» снизить сумму по заключенному договору с применением промо-кода на скидку

При формировании реестра юскейсов для пользователя мобильного телефона мы можем выделить такие функциональные возможности как «Сделать Звонок» и «Отправить СМС». Оба этих юскейса отражают непосредственное взаимодействие актора с системой, направленное на достижение определённой бизнес-цели, это системный юскейс.

Функциональные возможности «Сделать звонок» и «Отправить СМС» относятся к одной потребности пользователя «связаться с другим человеком», которая будет состоять из двух системных юскейсов: «Позвонить Человеку» и «Отправить СМС». Показать эту трассировку (связь) можно с помощью реестра вариантов использования.

Реестр вариантов использования:

— Клиент;Заключить договор;UC1.1 Добавить курс к договору

UC1.2 Удалить курс из договора — Клиент
— Шлюз онлайн-оплаты;Оплатить договор;UC2.1 Оплатить онлайн

UC2.2 Оплатить со скидкой (применить скидку по промо-коду)

Шаг 3. Определить приоритеты системных юскейсов

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

Шаги 4−7. Эти шаги (описать основной поток и расширения для каждого из приоритетных юскейсов) мы представим в виде примера описания одного из юскейсов (UC «Оплатить Договор», см. ниже). По аналогии будет описан и UC «Заключить Договор».

Имя;UC 2. Оплатить Договор Область действия;Информационная система управления договорами Контекст;Оплата договора на обучение по выбранным клиентом курсам Актор;Клиент, Шлюз онлайн-оплаты Цель;Оплатить договор на обучение по выбранным клиентом курсам Предусловия;• Клиент заключил договор на обучение по выбранным курсам, то есть курсы добавлены к договору
• Клиент выбрал договор для оплаты Триггер;Подошло время оплаты договора согласно бизнес-правилу BR1
(смотри раздел таблицы «бизнес-правила») Результат (постусловия);Сумма договора на обучение по выбранным курсам перечислена со счёта Клиента на расчётный счёт Учебного центра и данные об этом сохранены в системе Основной поток;1. Клиент вызывает команду «Оплатить договор»
2. Система убеждается, что выбранный договор ещё не оплачен
3. Система отображает Клиенту [Данные договора]

Примечание редакции: здесь [Данные договора] — это ссылка на словарь данных, то есть отдельный блок ТЗ, где описано, что [Данные договора] это

• Номер
• Дата заключения
• Сумма к оплате
• Персональные данные Клиента
• Список курсов к оплате

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

4. Пользователь подтверждает намерение продолжить оплату
5. Система запрашивает у Клиента наличие промо-кода, который даёт скидку на оплату курса
6. Клиент отвечает согласием на вопрос о наличии промо-кода
7. Система предоставляет Клиенту возможность ввести промо-код
8. Клиент вводит промо-код
9. Система проверяет валидность промо-кода
10. Система отображает результаты проверки валидности промо-кода
11. Система пересчитывает Сумму к оплате договора с учётом скидки по промо-коду
12. Система отображает Клиенту Сумму к оплате договора с учётом скидки по промо-коду
13. Клиент подтверждает согласие на оплату договора по представленным [Данным договора]
14. Система изменяет статус Договора на «К оплате»
15. Система формирует для шлюза онлайн-оплаты запрос со всеми параметрами заказа, то есть договора, где сумма списания равна итоговой цене, рассчитанной с учётом скидки по промо-коду, если её удалось применить
16. Система убеждается в доступности шлюза онлайн-оплаты
17. Система отправляет шлюзу онлайн-оплаты запрос со всеми параметрами договора и итоговой суммой списания
18. Система перенаправляет Клиента на шлюз онлайн-оплаты для перевода денег на счёт УЦ
19. Система убеждается в успешной оплате по договору (UC-34 Оплата договора через шлюз оплаты)
20. Система проверяет, был ли применён промо-код курса к оплате
21. Система изменяет статус Договора на «Оплачен»
22. Система сохраняет данные об успешной оплате договора
23. Система уведомляет пользователя об успешном завершении сценария Расширения;2а. Договор уже оплачен

2а.1 Система убеждается, что по данному договору уже произведена оплата
2а.2 Система уведомляет пользователя о том, что по данному договору уже произведена оплата и не может быть отозвана
2а.3 Система завершает выполнение сценария

6а. У Клиента нет промо-кода

6а.1 Пользователь не подтверждает наличие промо-кода
6а.2 Переход к шагу 13 основного потока

9а. Промо-код валиден

9а.1 Система убеждается, что промо-код ещё действителен, то есть его дата валидности ещё не истекла на момент оплаты
9а.2 Система уведомляет пользователя о том, что промо-код валиден и может быть применён к платежу по договору
9а.3 Переход к шагу 10 основного потока

9б Промо-код не валиден (дата истекла)

9б.1 Система убеждается, что промо-код уже не действителен, то есть. его дата валидности истекла на момент оплаты
9б.2 Система уведомляет пользователя о том, что промо-код НЕ валиден и НЕ может быть применён к платежу по договору
9б.3 Система уведомляет пользователя о том, что необходимо ввести существующий промо-код
9б.4 Переход к шагу 6 основного потока

9в. Промо-код не существует

9в.1 Система убеждается, что введенный промо-код отсутствует
9в.2 Система уведомляет пользователя о том, что введённый промо-код не существует и НЕ может быть применён к платежу по договору
9в.3 Система уведомляет пользователя о том, что необходимо ввести существующий промо-код
9в.4 Переход к шагу 6 основного потока

9г. Промо-код уже использован

9г.1 Система убеждается, что статус введённого промо-кода равен «Применён»
9г.2 Система уведомляет пользователя о том, что введённый промо-код уже применён и НЕ может быть применён повторно к платежу по договору
9г.3 Система уведомляет пользователя о том, что необходимо ввести другой промо-код
9в.4 Переход к шагу 6 основного потока

16а. Шлюз онлайн-оплаты недоступен

16а.1 Система убеждается в отсутствии связи со шлюзом онлайн-оплаты
16а.2 Система уведомляет пользователя о том, что в текущий момент шлюз онлайн-оплаты недоступен и необходимо повторить попытку оплаты ещё раз
16а.3 Переход на шаг 16 основного потока

19а. Клиент успешно оплатил заказ на шлюзе онлайн-оплаты

19а.1 Шлюз онлайн-оплаты списывает деньги со счёта клиента
19а.2 Шлюз онлайн-оплаты зачисляет деньги на счёт УЦ
19а.3 Шлюз онлайн-оплаты возвращает Системе статус оплаты по договору «Успешно оплачено»
19а.4 Переход к шагу 20 основного потока

19б. Клиент не оплатил заказ на шлюзе онлайн-оплаты

19б.1 Шлюз онлайн-оплаты возвращает Системе статус оплаты по договору «Не оплачено»
19б.2 Переход к шагу 12 основного потока

20а. К оплате был применён промо-код

20а.1 Система изменяет статус промо-кода на «Применён»
20а.2 Переход к шагу 21 основного потока

20б. К оплате был не применён промо-код

20б.1 Переход к шагу 21 основного потока Бизнес-правила;BR1. Заключенный договор должен быть оплачен в течение 3-х дней после даты заключения, иначе договор расторгается и должен быть заключен заново
BR2. Сумма оплаты по договору может быть уменьшена на размер скидки по промо-коду для конкретного курса
BR3. Скидки не суммируются, то есть. к сумме оплаты по одному договору может быть применён только один промо-код на скидку

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

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

Рассмотренная табличная форма описания UC является не единственной возможной. Бывают ещё и другие форматы, например, таблица в две колонки, юскейс в стиле RUP и так далее.

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

Источник: systems.education

Разработка документации технического проекта на СИБ

В данной статье рассматривается стадия технического проекта, относящаяся к одному из этапов жизненного цикла системы информационной безопасности (СИБ) — этапу «проектирование», который в соответствии с отечественным стандартом ГОСТ 34.601-90 следует сразу за разработкой Технического задания на систему информационной безопасности.

1. Разработка документации технического проекта на СИБ

Жизненный цикл системы информационной безопасности (далее — СИБ) в общем виде состоит из следующих этапов:

• анализ требований к СИБ;
• проектирование;
• реализация;
• внедрение;
• эксплуатация.

В данной статье рассматривается стадия технического проекта, относящаяся к этапу «проектирование» и в соответствии с отечественным стандартом ГОСТ 34.601-90 следует сразу за разработкой Технического задания на систему информационной безопасности.

1.1. Зачем вообще разрабатывать документацию на СИБ

Ответ на этот вопрос следует рассматривать в двух плоскостях: в плоскости владельца информационных ресурсов (для защиты которых и создается СИБ) и в плоскости непосредственного разработчика СИБ.

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

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

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

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

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

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

1.2. Обзор подходов к разработке документации технического проекта

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

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

Для разработки документации стадии технического проекта (ТП) на СИБ используются государственные стандарты и руководящие документы серии 34:

• ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем». В данном стандарте указаны:

• виды и наименование документов стадии ТП;
• комплектность документации;
• принятые обозначения документов;
• правила обозначения СИБ и их частей.

• перечень этапов работ, проводимых на стадии ТП;
• подробное описание работ, проводимых на стадии ТП;
• перечень организаций, участвующих в создании СИБ;

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

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

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

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

• приказ ФСТЭК России от 18 февраля 2013 г. № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
• приказ ФСТЭК России от 11 февраля 2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»
• приказ ФСТЭК России от 14 марта 2014 г. № 31 «Об утверждении требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды;
• методический документ «Меры защиты информации в государственных информационных системах», утвержден ФСТЭК России 11 февраля 2014 г.

Требования к защите информации ограниченного доступа и перечни защитных мер разнятся для ИС разных уровней/классов защищенности. В случае, если информация в организации не относится к защищаемой в соответствии с федеральными законами РФ (например, служебная тайна), то владелец данной информации может воспользоваться подходами, предлагаемыми в данных НПА для построения корпоративной СИБ.

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

• серия государственных стандартов ГОСТ Р ИСО/МЭК 2700X, идентичные международным стандартам ISO/IEC 2700X. Данные стандарты описывают процессный подход PDCA (Plan, Do, Check, Act) к реализации жизненного цикла системы менеджмента информационной безопасности, которая является неотъемлемой частью СИБ;
• NIST SP 800-64 – стандарт Национального Института Стандартов и Технологий США, описывающий жизненный цикл разработки информационных систем;
• NIST SP 800-37 – стандарт Национального Института Стандартов и Технологий США, являющийся руководством по интеграции управления рисками в жизненный цикл разработки информационных систем.

— эксплуатационная документация производителя на средства защиты информации и вспомогательные средства. В данных документах содержится исчерпывающая техническая информация о применяемых при построении СИБ средствах, в том числе напрямую к реализации мер ИБ не относящихся, например, серверах, системах хранения данных, средствах виртуализации и прочих. Общий набор таких документов у разных производителей различен и зависит в том числе от исполнения того или иного средства (аппаратное/программное). Ниже представлен стандартный набор эксплуатационной документации на средства защиты информации, используемый для разработки документов стадии технического проекта:

• общее описание (datasheet);
• руководство администратора (может входить руководство по локальному и централизованному управлению);
• руководство пользователя;
• руководство по быстрой установке и развертыванию (для аппаратного СЗИ);
• руководство оператора;
• руководство по развертыванию в виртуальной инфраструктуре (для программного СЗИ);

— общая информация об имеющихся архитектурах СИБ, лучшие практики в части построения СИБ, руководства по безопасности и интеграции СЗИ друг с другом, сведения о проблемах при взаимодействии тех или иных СЗИ. Примерами таких сведений могут являться следующие документы:

1.3. Разработка технического проекта на СИБ в соответствии с ГОСТ 34

Разработка документов стадии технического проекта на СИБ осуществляется чаще всего интеграторами данных услуг и реализуется преимущественно в соответствии со следующим планом:

— определение перечня разрабатываемых документов – данные сведения указываются в техническом задании на СИБ. В некоторых случаях разработчик документов по согласованию с Заказчиком может расширить или сократить данный перечень, если возможность этого предусмотрена в ТЗ;

— разработка шаблонов документов стадии ТП – используется структура в соответствии с РД 50-34.698-90 и ГОСТ 2.106 (для некоторых документов), оформление в соответствии с ГОСТ 2.105-95;

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

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

— согласование разработанной документации и представленных в ней решений с Заказчиком системы.

При разработке документации технического проекта чаще всего не требуется разрабатывать полный перечень документов, указанный в ГОСТ 34.201-89, так как данный стандарт морально устарел и часть документов не учитывают тенденции разработки и технологии современных информационных систем. Минимальный комплект документов, необходимый для описания системы информационной безопасности, следующий:

• ведомость технического проекта;
• пояснительная записка к техническому проекту;
• схема функциональной структуры;
• схема структурная комплекса технических средств;
• схема организационной структуры;
• ведомость покупных изделий.

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

• схема автоматизации;
• описание автоматизируемых функций;
• описание информационного обеспечения системы;
• описание комплекса технических средств;
• описание программного обеспечения;
• описание организационной структуры.

Необходимо отметить, что ГОСТ 34.201-89 допускает расширение номенклатуры документов стадии ТП, однако на практике означенных документов хватает с избытком.

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

Ведомость технического проекта

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

Пояснительная записка к техническому проекту

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

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

Схема функциональной структуры

Данный документ описывает логическую структуру СИБ, а именно:

• логические подсистемы и компоненты, входящие в состав СИБ;
• функции, реализуемые средствами подсистем и компонентов;
• информационные связи между логическими элементами СИБ и типы сообщений при обмене.

Схема структурная комплекса технических средств

Данный документ включает в себя описание следующих элементов СИБ:

• технических средств в составе логических подсистем и компонентов СИБ;
• каналов связи и обмена между техническими средствами с указанием транспортных протоколов.

Схема организационной структуры

Данный документ описывает организационную структуру организации в части управления СИБ, а именно:

• подразделения и ответственных лиц организации, участвующих в функционировании СИБ;
• выполняемые функции и связи между подразделениями и ответственными лицами.

Ведомость покупных изделий

Данный документ включает в себя перечень всех программных и технических средств, а также лицензий, используемых при создании СИБ. Разрабатывается в соответствии с ГОСТ 2.106.

Примечание. Здесь также стоит отметить, что руководящий документ РД 50-34.698-90 допускает дополнение любого документа стадии ТП (включение разделов и сведений, отличных от предложенных), объединение разделов, а также исключение некоторых отдельных разделов. Решения об этом принимаются разработчиком документов стадии ТП и основываются на особенностях создаваемой СИБ.

1.4. Правила разработки документации

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

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

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

Пояснительная записка к техническому проекту:

• разработка документа осуществляется в среде Microsoft Word, после окончания разработки рекомендуется для удобства конвертировать документ в формат PDF;
• термины и сокращения должны быть едиными в пределах всех разделов документа;
• рекомендуется избегать явных повторений и ненужного увеличения объема документа;
• технические решения необходимо описывать как можно более подробно с указанием:

• архитектуры и используемых технологий;
• мест размещения программных и технических средств в инфраструктуре организации;
• используемых средств защиты информации с описанием их характеристик, реализуемых функций, сведений о сертификации;
• основных настроек средств защиты информации в части механизмов защиты, адресации, маршрутизации, взаимодействия со смежными системами и средствами и прочего;
• средств управления, методов доступа к ним и местах их установки;
• схемы (структурная, функциональная, организационная):

• разрабатывать схемы в среде Microsoft Visio;
• после разработки вставлять схемы в документ при помощи диалога «Специальная вставка» в формате EMF (метафайл Windows);
• разрабатывать отдельные схемы на систему, подсистемы и компоненты подсистем;
• оформление схем делать однотипным, с использованием одинаковых элементов, сокращений, иконок, стилей текста и прочего.

1.5. Ресурсы, помогающие при разработке документации

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

Тип ресурса Информация Примеры ресурсов

Интернет-порталы федеральных органов исполнительной власти	Нормативные документы, методические рекомендации, реестры (в том числе сертифицированных СЗИ), базы данных (в том числе БД уязвимостей и угроз)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
Интернет-порталы производителей СЗИ, дистрибьюторов решений в области ИБ	Описание решений по ИБ, эксплуатационная документация по СЗИ, аналитические материалы и статьи	securitycode.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/

1.6. Примеры документов стадии технического проекта

Для понимания требований к содержанию документации стадии ТП далее представлены примеры наполнения основных документов (разделов документов).

1.6.1. Пояснительная записка к техническому проекту

Пояснительная записка — достаточно объемный документ, поэтому здесь приводится пример содержания раздела «Основные технические решения» в части одной из подсистем СИБ — подсистемы анализа защищенности.

Подсистема анализа защищенности СИБ

Структура и состав подсистемы

Подсистема анализа защищенности (ПАЗ) предназначена для проведения систематического контроля состояния защищенности автоматизированных рабочих мест (АРМ) персонала и серверов организации. Основой ПАЗ являются программное средство «Test» производства компании ООО «Информационная безопасность». СЗИ Test имеет сертификат ФСТЭК России на соответствие техническим условиям (ТУ) по безопасности информации и по 4-му уровню контроля отсутствия недекларированных возможностей.

В состав ПАЗ входят следующие компоненты:

• сервер управления Test Server;
• консоль управления Test Console.

Примечание: далее в документ включается структурная схема комплекса технических средств ПАЗ и (или) его функциональная схема.

Описание компонентов подсистемы представлено в таблице ниже.

Компонент Описание

Сервер управления Test Server	Обеспечивает управление задачами сканирования, выполняет функции контроля состояния защищенности АРМ и серверов организации. Параметры сканирования задаются администратором ИБ на сервере управления Test Server. Вся собранная информация о результатах сканирования сохраняется в хранилище сервера Test Server на базе системы управления базами данных Microsoft SQL Server 2008
Консоль управления Test Console	Позволяет администратору ИБ подключаться к серверу Test Server, просматривать и изменять его конфигурацию, создавать и модифицировать задачи на проведение сканирований, просматривать информацию о ходе выполнения задач и результаты их выполнения. Консоль управления устанавливается на АРМ администратора ИБ

Обеспечение функций

ПАЗ обеспечивает выполнение следующих функций:

• реализация проактивной защиты АРМ и серверов организации с помощью мониторинга состояния ИБ;
• автоматизация процессов контроля соответствия внутренним политикам и определенным стандартам безопасности;
• снижение затрат на аудит и контроль защищенности, подготовку отчетов по состоянию;
• автоматизация процессов инвентаризации ресурсов, управления уязвимостями, контроля соответствия политикам безопасности и контроля изменений.

Решение по комплексу технических и программных средств

Перечень используемого программно-технического обеспечения ПАЗ приведен в таблице ниже.

Компонент Техническое средство Программное обеспечение

Test Server	Физический сервер	ОС Windows 2008 R2 Standard Edition x64, ПО Microsoft SQL Server 2008 R2, ПО Test Server
АРМ администратора	Персональный компьютер	ПО Microsoft .NET Framework 3.5 SP1, ПО Test Console

Сервер управления ПАЗ

Технические средства

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

Программное обеспечение Технические требования CPU RAM, МБ

Microsoft Windows Server 2008 R2	3000 МГц, 4 ядра	8192
Microsoft SQL Server 2008 R2
ПО Test Server

Программные средства

ОС сервера управления

Установка ОС Windows 2008 R2 на сервер управления производится штатным образом с загрузочного дистрибутива.

Управление ОС сервера управления осуществляется как локально с консоли, так и по протоколу RDP.

СУБД сервера управления

Установка БД Microsoft SQL Server 2008 R2 осуществляется под учетной записью с правами локального администратора посредством стандартного мастера установки из дистрибутива, поставляемого разработчиком продукта.

ПО Test Server

Установка ПО Test Server на сервер управления осуществляется с помощью стандартного мастера установки.

Первоначальная настройка и последующее управление ПО Test Server в штатном режиме осуществляются с помощью консоли управления Test Console, установленной на АРМ администратора ИБ.

АРМ администратора ИБ

Технические средства

В качестве платформы используется существующий АРМ сотрудника подразделения организации, ответственного за обеспечение ИБ, под управлением ОС семейства Microsoft Windows.

Технические средства АРМ администратора ИБ должны обладать следующими характеристиками аппаратной конфигурации (рекомендуется не менее):

• CPU 2 ГГц;
• RAM 4 ГБ;
• HDD 80 ГБ.

Программные средства

ПО Test Console

АРМ администратора ИБ, на которое выполняется установка ПО Test Console, должно функционировать под управлением одной из следующих ОС:

• Microsoft Windows 7, 32- и 64-битные;
• Microsoft Windows 8/8.1, 32- и 64-битные.

Кроме того, для корректной работы ПО консоли управления Test Console на АРМ администратора ИБ должно быть установлено ПО Microsoft .NET Framework версии 3.5 SP1 или выше, а настройки безопасности используемой ОС должны разрешать доступ к серверу Test Server.

Установка ПО Test Console на АРМ администратора ПАЗ осуществляется с помощью стандартного мастера установки ПО Test Server с выбранной опцией установки консоли управления Test Console и прочими настройками по умолчанию.

Взаимодействие со смежными системами

Для ПАЗ смежными являются:

• средства подсистемы межсетевого экранирования;
• службы каталога Active Directory;
• АРМ и серверы организации.

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

Для обеспечения возможности получения обновлений базы знаний и модулей ПО Test для сканера Test Server необходимо обеспечить доступ к веб-серверу обновлений компании ООО «Информационная безопасность» update.com по порту 443/tcp.

При сканировании в режиме PenTest взаимодействие сканера Test Server и АРМ и серверов организации осуществляется по протоколу IP. При сканировании в режиме Audit и Compliance используются протоколы удаленного управления WMI, RPC и т. п. Для сканирования узлов на устройствах с функциями межсетевого экрана необходимо разрешить соединения от сервера Test Server к сканируемым узлам по протоколу IP. Соответственно, для сервера Test Server необходимо обеспечить доступ к сетевым портам сканируемых узлов по соответствующим протоколам удаленного управления.

Поскольку ПАЗ при сканировании в режимах Audit и Compliance использует для анализа протоколы удаленного управления, то средства сканирования ПО Test должны проходить аутентификацию и авторизацию на сканируемом узле. В ПАЗ для сканирования узлов в режимах Audit и Compliance в каждом из типов узлов (АРМ, сервер, прикладные системы, СУБД и т. п.) используются учетные записи c административными привилегиями.

Все регистрируемые события информационной безопасности хранятся в СУБД Microsoft SQL. Данные события посредством специальных коннекторов могут отправляться в подсистему мониторинга событий ИБ.

Эксплуатация и обслуживание ПАЗ

Пользователи подсистемы

Эксплуатация и обслуживание средств ПАЗ осуществляется сотрудниками организации с функциональной ролью «администратор ИБ».

Под администратором ИБ понимается специалист, в задачи которого входит:

• определение параметров сканирования узлов организации;
• настройка и запуск задач на сканирование;
• анализ результатов сканирования на предмет наличия в информационных системах уязвимостей, ошибок конфигурации или несоответствий требованиям технических стандартов;
• контроль устранения уязвимостей;
• формирование стандартов и требований, которые предъявляются к обеспечению безопасности АРМ и серверов организации.

Режимы эксплуатации системы

Штатный режим эксплуатации

В штатном режиме эксплуатации ПАЗ функционирует 24 часа в сутки 7 дней в неделю.

В штатном режиме работы администратор ИБ выполняет:

• плановое и внеплановое сканирования узлов;
• генерацию отчетов;
• обновление баз знаний и модулей ПО Test.

Аварийный режим эксплуатации

При нарушении работоспособности средств ПАЗ функционирование подсистемы нарушается. Нарушение работоспособности средств ПАЗ не влияет на функционирование АРМ и серверов организации.

1.6.2. Схема функциональной структуры

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

Пример общей функциональной схемы СИБ представлен на рисунке ниже.

1.6.3. Схема структурная комплекса технических средств

Структурная схема комплекса технических средств может разрабатываться как для всей СИБ, так и для ее частей — подсистем и компонентов. Целесообразность разработки схем для частей СИБ определяется масштабом системы и требуемой детализацией.

Пример структурной схемы комплекса технических средств СИБ представлен на рисунке ниже.

1.6.4. Схема организационной структуры

Пример схемы организационной структуры СИБ приведен на рисунке ниже.

Источник: safe-surf.ru

Разработка технического задания. Разработка технического задания на создание ИС. Источники информации для формирования технического задания. Примеры заполнения разделов документа

Для АС Кадры определены следующие режимы функционирования:

• Нормальный режим функционирования;
• Аварийный режим функционирования.

Основным режимом функционирования АС является нормальный режим.

Источник — документация заказчика (положение об агентстве)

В нормальном режиме функционирования системы:

• клиентское программное обеспечение и технические средства пользователей и администратора системы обеспечивают возможность функционирования в течение рабочего дня (с 09:00 до 18:00) пять дней в неделю;
• серверное программное обеспечение и технические средства северов обеспечивают возможность круглосуточного функционирования, с перерывами на обслуживание;
• исправно работает оборудование, составляющее комплекс технических средств;
• исправно функционирует системное, базовое и прикладное программное обеспечение системы.

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

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

В случае перехода системы в аварийный режим необходимо:

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

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

18.4.1.1.5. Требования по диагностированию системы

АС Кадры должна предоставлять инструменты диагностирования основных процессов системы, трассировки и мониторинга процесса выполнения программы.

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

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

Источник — опыт, документация на системы диагностики, ITIL, MOF

18.4.1.1.6. Перспективы развития, модернизации системы

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

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

Источник — документация заказчика (стратегия развития)

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

Для эксплуатации АС Кадры определены следующие роли:

• Системный администратор;
• Администратор баз данных ;
• Администратор информационной безопасности;
• Пользователь.

Источник — опыт, документация на программные и технические средства

Основными обязанностями системного администратора являются:

• Модернизация, настройка и мониторинг работоспособности комплекса технических средств (серверов, рабочих станций);
• Установка, модернизация, настройка и мониторинг работоспособности системного и базового программного обеспечения;
• Установка, настройка и мониторинг прикладного программного обеспечения;
• Ведение учетных записей пользователей системы.

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

Основными обязанностями администратора баз данных являются:

• Установка, модернизация, настройка параметров программного обеспечения СУБД;
• Оптимизация прикладных баз данных по времени отклика, скорости доступа к данным;
• Разработка, управление и реализация эффективной политики доступа к информации, хранящейся в прикладных базах данных.

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

Основными обязанностями администратора информационной безопасности являются:

• Разработка, управление и реализация эффективной политики информационной безопасности системы ;
• Управление правами доступа пользователей к функциям системы;
• Осуществление мониторинга информационной безопасности.

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

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

Роли системного администратора, администратора баз данных и администратора информационной безопасности могут быть совмещены в роль.

Рекомендуемая численность для эксплуатации АС Кадры:

• Администратор — 1 штатная единица;
• Пользователь — число штатных единиц определяется структурой предприятия.

18.4.1.3. Показатели назначения

АС Кадры должны обеспечивать возможность исторического хранения данных с глубиной не менее 10 лет.

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

• для операций навигации по экранным формам системы — не более 5 сек;
• для операций формирования справок и выписок — не более 10 сек.

Время формирования аналитических отчетов определяется их сложностью и может занимать продолжительное время.

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

Источник — ОФМ, IDEF3, регламенты (анкеты) пользователей

18.4.1.4. Требования к надежности

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

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

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

Источник — опыт эксплуатации ИС

18.4.1.5. Требования к безопасности

Все внешние элементы технических средств системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.

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

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

Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003 г.).

Источник — документация на технические средства, нормы и правила эксплуатации

18.4.1.6. Требования к эргономике и технической эстетике

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

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

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

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

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

Источник — опыт, эргономика, инженерная психология

18.4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

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

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

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

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

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

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

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

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

Источник — опыт, документация на программные и технические средства

18.4.1.8. Требования к защите информации от несанкционированного доступа

ИС должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего руководящего документа Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем» 1992 г.

Компоненты подсистемы защиты от НСД должны обеспечивать:

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

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

Уровень защищённости от несанкционированного доступа средств вычислительной техники, обрабатывающих конфиденциальную информацию, должен соответствовать требованиям к классу защищённости 6 согласно требованиям действующего руководящего документа Гостехкомиссии России «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации».

Защищённая часть системы должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов; количество символов не соответствует длине пароля).

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

Защищённая часть системы должна использовать многоуровневую систему защиты. Защищённая часть системы должна быть отделена от незащищённой части системы межсетевым экраном.

Источник — опыт, ведомственные документы заказчика

18.4.1.9. Требования по сохранности информации при авариях

Программное обеспечение АС Кадры должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации автоматического и (или) ручного резервного копирования данных системы средствами системного и базового программного обеспечения (ОС, СУБД), входящего в состав программно технического комплекса Заказчика.

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

18.4.1.10. Требования к защите от влияния внешних воздействий

18.4.1.11. Требования к патентной чистоте

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

Источник: intuit.ru

Формирование требований и классификация требований

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

Сбор требований

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

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

Выжимка по процессу формирования требований

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

Бизнес-процессы — самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы

Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

Типовая структура требований выглядит как «Система должна … /утверждение о необходимом функциональном поведении системы/» или «система должна позволять … /утверждение о возможности, предоставляемой пользователю или внешней системе/.

Например:
«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

Пример различий между пользовательскими и функциональными требованиями:
Пользовательское: «Система должна выводить отчеты на печать»
Функциональное: «Система должна обеспечивать вывод отчетов на печать, обеспечивать возможность выбора и настройки локального или сетевого принтера, выбора ориентации бумаги».

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

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

Схема процесса разработки с уровнями требований

Формирование и анализ требований

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

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

Классификация и описание требований на пути от бизнеса к технической реализации

Компания — Бизнес-требования

Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:

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

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

Заказчик — Документ требований заинтересованных лиц

• Бизнес-назначение
• Бизнес-рамки
• Обзор бизнеса
• Заинтересованные лица
• Организационная среда
• Цели и результаты
• Бизнес-модель
• Информационная среда
• Бизнес-процессы
• Политики и правила
• Ограничения деятельности
• Организационная структура
• Концепция использования системы
• Сценарии эксплуатации
• Проектные ограничения

Пользователь — Требования пользователя

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

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

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

Системные требования

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

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

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

Стандартные формы для специфицирования функциональных требований:

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

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

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

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

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

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

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

Требования предметной области

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

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

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

Организационные требования

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

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:

• Физическое размещение сервисов.
• Размещение адаптеров к информационным системам.
• Предоставление канала для взаимодействия информационных систем.
• Обеспечение независимости от адресов, протоколов и интерфейсов при взаимодействии систем.
• Трансформация данных при взаимодействии.
• Маршрутизация сообщений.
• Обеспечение инфраструктурной функциональности, включая мониторинг, логирование, безопасность, и т. д.

Интеграция точка-точка

Интеграция приложений напрямую, является методом интеграции, при котором взаимодействие между системами происходит без применения универсального централизованного посредника, такого, как сервисная шина предприятия (ESB).

Интеграция данных

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

Задачи интеграции данных:

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

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

Файловый обмен
Файловый обмен характеризуется следующим сценарием:
1) Приложение, которому требуется передать данные другому приложению, сохра¬няет их в файле.
2) Разрабатывается интеграционное решение, которое преобразует формат файла в формат, требуемый другим приложением. (В частном случае для этого дорабатывается одна из интегрируемых систем)
3) Приложение которому нужны данные, загружает подготовленный файл.

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

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

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

К первой группе можно отнести следующие типы требований:

• Требования к размещению элементов управления на экранных формах
• Требования к содержанию и оформлению выводимых сообщений
• Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

• Требования к реакции системы на ввод пользователя
• Требования к времени отклика на команды пользователя

Управление требованиями

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

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

Классификация изменяемых требований

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

Процесс управления изменениями

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

Кто читает документацию

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

Как правильно сформулировать и контролировать цель проекта?

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

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

Если вы выбрали реалистичные KPI для своих целей, но не видите признаков прогресса по истечении разумного времени, нужно провести расследование:

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

Документы процесса разработки и управления требованиями (по Вигерсу)

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

Источник: analytics.infozone.pro