Шаблон Концепции проекта / системы

1. НАИМЕНОВАНИЕ СИСТЕМЫ ИЛИ ЗАКАЗЧИКА
НАИМЕНОВАНИЕ ПОДСИСТЕМЫ/РАБОТ/ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ/СИСТЕМЫ
Концепция создания/развития/модернизации системы
Москва, 20__ г.

2. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
АННОТАЦИЯ
В аннотации приводятся общие сведения о контексте выполнения работ (контракт,
проект), дается краткий обзор содержимого документа.
Конфиденциальный документ <Наименование организации-исполнителя>. Любая информация,
представленная в настоящем документе и имеющая отношения к сотрудничеству сторон, хозяйственно-
коммерческой деятельности или техническим возможностям <Наименование организации-исполнителя>, а также к
изделиям, услугам, фактическим и аналитическим данным, заключениям и материалам, кроме информации,
которая в соответствии с действующим законодательством и иными правовыми актами Российской Федерации не
может быть отнесена к конфиденциальной информации, является конфиденциальной. Не разрешается копирование
и распространение информации без письменного разрешения <Наименование организации-исполнителя>.
Стр. 2 из 12

3. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
СОДЕРЖАНИЕ
1. ВВЕДЕНИЕ 4
1.1. НАЗНАЧЕНИЕ ДОКУМЕНТА 4
1.2. ЦЕЛИ И НАЗНАЧЕНИЕ СИСТЕМЫ 4
1.3. ТЕРМИНОЛОГИЯ И ОБОЗНАЧЕНИЯ 4
1.4. ССЫЛКИ 4
2. ОПИСАНИЕ ОБЪЕКТА АВТОМАТИЗАЦИИ 5
2.1. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 5
2.2. ХАРАКТЕРИСТИКА ПОЛЬЗОВАТЕЛЕЙ 5
2.3. ПОЛЬЗОВАТЕЛЬСКОЕ ОКРУЖЕНИЕ 6
2.4. КЛЮЧЕВЫЕ ПОТРЕБНОСТИ ПОЛЬЗОВАТЕЛЕЙ 6
2.5. АЛЬТЕРНАТИВНЫЕ ВАРИАНТЫ 6
3. ПРЕДЛАГАЕМОЕ РЕШЕНИЕ 8
3.1. ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ 8
3.2. ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ СИСТЕМЫ 8
3.3. АРХИТЕКТУРНЫЕ ОСОБЕННОСТИ 9
3.4. ПРОЧИЕ ТРЕБОВАНИЯ К СИСТЕМЕ 9
3.5. СУЩЕСТВУЮЩИЕ ОГРАНИЧЕНИЯ 9
4. СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ СИСТЕМЫ 10
5. ПЛАН МЕРОПРИЯТИЙ ПО СОЗДАНИЮ СИСТЕМЫ 11
ПРИЛОЖЕНИЕ A
НАЗВАНИЕ ПРИЛОЖЕНИЯ 12
Стр. 3 из 12

4. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
1. ВВЕДЕНИЕ
1.1. Назначение документа
Настоящий документ определяет цели создания системы, содержит описание
потребностей заинтересованных лиц и основных характеристик создаваемого продукта.
1.2. Цели и назначение системы
В этом разделе формулируется основная цель создания (разработки) системы и
описывается назначение (т.е. способы использования системы). Указывается название
создаваемой системы; если концепция относится к новой версии системы, указывается номер
версии.
Приводится общее описание того, что создаваемая система будет делать (возможно, и
чего она не будет делать), а также общее описание того, как она будет использоваться, т.е. кто и
какой целью будет ее использовать, каких целей при этом достигнет, какие выгоды получит.
При формулировке целей системы следует иметь в виду, что на их основе будут
формулироваться критерии успеха проекта (подробнее см. раздел «План мероприятий по
созданию системы»), поэтому формулировки целей рекомендуется делать предельно четкими и
допускающими непосредственную проверку по итогам создания системы.
1.3. Терминология и обозначения
Приводится список специфических для данной системы (предметной области) терминов
с пояснением их смысла и набор аббревиатур, используемых в данном документе.
АИС – автоматизированная информационная система.
1.4. Ссылки
Если ниже в документе для обоснования используются ссылки на те или иные
нормативные документы, правовые или законодательные акты, источники информации, то в
данном разделе приводится список этих источников информации. Если этот список достаточно
большого объема, то рекомендуется вынести его в приложение, а здесь дать ссылку на это
приложение.
Стр. 4 из 12

5. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
2. ОПИСАНИЕ ОБЪЕКТА АВТОМАТИЗАЦИИ
В данном разделе приводится характеристика пользователей системы и других
заинтересованных лиц, описание их потребностей и ожиданий от создания системы. Если
предполагается использование системы не на одном объекте, а, например, как территориально-
распределенной системы, то, возможно, заголовок раздела следует изменить на что-то типа
«Характеристика пользователей системы».
2.1. Характеристика объекта автоматизации
В данном разделе приводится высокоуровневое описание объекта автоматизации
(организации Заказчика) с адресацией к тем причинам, которые побуждают Заказчика к
выполнению данного проекта. Например, для бизнес-заказчиков это может быть описание
позиционирования на рынке, доли рынка, трендов, доходов-расходов и т.п. факторов, которые в
совокупности образуют побудительные причины для выполнения проектов. Для
государственных заказчиков это могут быть политические причины (например, федеральная
программа).
В любом случае рекомендуется описать:
• текущую ситуацию;
• желаемую ситуацию;
• как создаваемый продукт может помочь достижению этой желаемой ситуации.
2.2. Характеристика пользователей
Описываются категории пользователей системы. Степень детализации может быть
различной, например, может быть градация пользователей по уровню квалификации («эксперт-
новичок»), либо деление в соответствии с организационно-должностной структурой их
организации, либо иным способом.
Для каждой категории пользователей рекомендуется указать следующие
характеристики:
• основные обязанности;
• документы и артефакты, производимые пользователем, и для чего (кого) он их
производит;
• какие факторы влияют на эффективность работы пользователя с положительной либо
отрицательной стороны;
• какие проблемы мешают пользователю;
• критерии достижения пользователем успеха в своей деятельности;
• типовой уровень квалификации пользователей.
Стр. 5 из 12

6. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
Все приведенные характеристики необходимо описывать в преломлении целей и
назначения проекта, т.е. если активности пользователя не имеют отношения к целям проекта, то
их незачем здесь описывать.
2.3. Пользовательское окружение
В этом разделе описывается, в каких условиях пользователи осуществляют ту
деятельность, которая была описана в предыдущем разделе.
Рекомендуется ответить на следующие вопросы:
• какова сложность и длительность типовых задач пользователя? сколько человек
вовлечено в их выполнение? сколько времени уходит у них на выполнение
операций?
• какие операционные системы, СУБД, средства безопасности используются? какие
предполагаются к использованию в будущем?
• какие еще приложения применяются пользователями в своей работе? требуется ли
интеграция создаваемой системы с ними и в чем она будет состоять?
• прочие специфические ограничения (например, использование мобильных устройств
и т.п.).
При описании характеристик пользовательского окружения необходимо удерживаться в
рамках здравого смысла и не описывать те характеристики, которые заведомо не имеют
отношения к данному проекту.
2.4. Ключевые потребности пользователей
Описываются основные потребности пользователей или их проблемы. Важно показать,
как именно пользователи понимают свои потребности или проблемы.
Для каждой потребности (проблемы) приводится описание:
• В чем состоит потребность (проблема)?
• Как сейчас решается этот вопрос?
• Какое решение проблемы в будущем ожидают пользователи?
В этом разделе важно провести приоретизацию описанных потребностей (проблем), как
минимум, на два уровня: какие проблемы, с точки зрения пользователей, должны быть
решены, а какие – хорошо бы, чтобы были решены.
2.5. Альтернативные варианты
Приводится описание альтернативных вариантов, рассматриваемых пользователей по
отношению к создаваемому решению. Альтернативами могут быть приобретение аналогичного
продукта у конкурентов, самостоятельная разработка пользователями собственного решения,
некий воркэраунд либо просто «оставить все как есть».
Стр. 6 из 12

7. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
Для каждой альтернативы описываются ее сильные и слабые стороны, приводятся
сравнительные характеристики, если это возможно.
Важно! Указанная информация приводится с позиций пользователя, т.е. как именно
пользователи оценивают достоинства и недостатки имеющихся альтернатив.
Стр. 7 из 12

8. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
3. ПРЕДЛАГАЕМОЕ РЕШЕНИЕ
В данном разделе приводится высокоуровневое описание возможностей создаваемой
системы, показывается, каким образом будут удовлетворены описанные выше потребности
пользователей.
3.1. Общее описание системы
Формулируется описание назначения системы. Хорошая формулировка назначения
системы должна содержать указания на следующие вопросы:
• для кого создается система;
• какие основные потребности заинтересованных лиц она удовлетворяет;
• основная причина создания или приобретения системы (ключевая выгода от создания
системы);
• основные отличия от аналогичных или конкурирующих продуктов.
3.2. Функциональные возможности системы
В этом разделе перечисляются основные функциональные возможности системы с
адресацией к ключевым потребностям пользователей и других заинтересованных лиц. Т.е.
указывается, какие возможности в системе будут реализованы для удовлетворения конкретных
потребностей заинтересованных лиц.
Форма представления может быть любой (гладкий текст, таблица, иерархическое
представление потребностей/возможностей, матрица трассировки и т.п.), – главное, чтобы это
описание было максимально простым, наглядным и понятным при первом прочтении
неподготовленному пользователю.
Важно! Необходимо уделить особое внимание формулировке функциональной
возможности: она должна быть достаточно краткой и точной (не более 1-2 предложений),
формулироваться на языке пользователей (предметной области). Рекомендуется для системы
любого уровня сложности ограничиться эмпирическим количеством 25-50 ключевых
возможностей верхнего уровня. Если выявлено большее количество ключевых возможностей,
рекомендуется провести декомпозицию на несколько подсистем, и каждую описывать
отдельно.
Подробное описание функциональных возможностей системы с требуемой детализацией
рекомендуется выносить в спецификацию требований к системе, а в данном документе
ограничиться высокоуровневым перечислением..
Рекомендуется сопроводить описание каждой функциональной возможности набором
дополнительных характеристик (по необходимости):
• статус (предложена, утверждена, реализована);
Стр. 8 из 12

9. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
• приоритет (критическая, важная, полезная);
• трудоемкость реализации;
• риски;
• стабильность;
• целевая версия;
• причина реализации.
Если необходимо, можно включить в документ описание характеристик
функциональных возможностей с описанием смысла этих характеристик и их возможных
значений (например, в приложении).
3.3. Архитектурные особенности
Описывается предполагаемый способ интеграции создаваемой системы в
существующую инфраструктуру пользователей. При необходимости приводятся поясняющие
диаграммы, схемы, графики и т.п. Основной критерий – наглядность и понятность описания.
Указываются целевая ОС, поддерживаемые СУБД, другие необходимые элементы
программно-технической инфраструктуры.
3.4. Прочие требования к системе
Описываются, если есть, нефункциональные требования пользователей:
• соответствие создаваемой системы стандартам, соглашениям и т.п.;
• совместимость с различными операционными системами, конфигурациями,
периферийными устройствами, требования к использованию памяти и другие
системные требования;
• требования к документированию (состав пользовательской документации,
эксплуатационной документации, нормативно-методической документации, online
help и проч.);
• требования по надежности;
• требования по безопасности;
• требования к развертыванию и обновлению версий и т.п.
3.5. Существующие ограничения
Описание выявленных ограничений, влияющих на разрабатываемую систему
(организационные, технические, политические и т.д.)
Сюда не рекомендуется включать технологические ограничения, связанные с процессом
разработки, если только они не формулируются Заказчиком в явном виде.
Стр. 9 из 12

10. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
4. СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ СИСТЕМЫ
Данный раздел является необязательным.
Он может включаться для повышения наглядности описания способов использования
системы, либо, если некоторые сценарии использования важны для понимания требований к
архитектуре системы.
Рекомендуется, если этот раздел присутствует, приводить высокоуровневые сценарии
использования, показывающие использование пользователями системы основных
возможностей системы для реализации своих ключевых потребностей либо выполнение
наиболее типовых (массовых) операций.
Стр. 10 из 12

11. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
5. ПЛАН МЕРОПРИЯТИЙ ПО СОЗДАНИЮ СИСТЕМЫ
В этом разделе приводится список основных мероприятий, направленных на создание и
ввод в эксплуатацию системы. Особенное внимание следует уделить мероприятиям, в которые
так или иначе оказывается вовлечен Заказчик, его представители или пользователи системы:
создание и работа совместных комиссий, выработка и утверждение нормативных и
организационно-распорядительных документов, проведение опытной эксплуатации системы и
проч.
Если есть какие-либо календарные соображения относительно создания системы, то они
приводятся здесь (основные этапы, их сроки). Если систему предполагается создавать в
несколько итераций (версий), то рекомендуется кратко описать предполагаемое количество
версий, функции, которые будут (и не будут) реализованы в каждой версии, сроки выпуска
версий и т.п.
Рекомендуется по каждому этапу и для системы в целом сформулировать критерии
успеха проекта. Идеально, если формулировка критериев успеха будет соответствовать
формулировкам целей системы, указанным в соответствующем разделе документа. Однако, при
формулировке критериев успеха необходимо следить, чтобы эти критерии были однозначно
проверяемыми (в идеале, измеримыми), что при формулировке целей достичь не всегда
удается.
Стр. 11 из 12

12. <Наименование системы или Заказчика>. Концепция создания/развития/модернизации системы
ПРИЛОЖЕНИЕ A
НАЗВАНИЕ ПРИЛОЖЕНИЯ
Примеры возможных приложений:
• список документов и источников информации;
• планы, графики, схемы, чертежи;
• вспомогательная информация, направленная на пояснение используемых терминов,
методов и проч., например, Характеристики функциональных возможностей системы
или Основные положения методологии разработки проектов RUP;
• перечень прилагаемых электронных и иных материалов.
Важное замечание! Общий объем документа не должен превышать 10-20 страниц, в
зависимости от сложности системы и объема имеющейся информации. Документ должен
содержать предельно четкую информацию, должен читаться «одним махом» и давать
неподготовленному читателю цельное представление о том, какую систему предполагается
создать.
Стр. 12 из 12