Перед проектированием информационной системы необходимо определиться с предъявляемыми к ней требованиям. Можно выделить следующие группы требований: к функциональности, к эргономичности, к надежности, к производительности, к сопровождению.
Функциональные требования
Одними из наиболее значимых требований, предъявляемых при выборе информационных систем, являются требования к функциональности. Разрабатываемая информационная системы должна обладать следующими свойствами:
Адаптивность - означает приспосабливаемость системы к условиям конкретной предметной области. Необходимо, поскольку может использоваться совместно с другими информационными системами.
Структурность - определяет наличие установленных связей и отношений между элементами внутри системы, распределение элементов системы по уровням и иерархиям.
Целостность - означает то, что все элементы системы функционируют как единое целое.
Разрабатываемая информационная система должна предоставлять следующие возможности:
Следить за состоянием документа на любой его стадии;
Получать исчерпывающую информацию о документе;
Хранить данные о документах
Кроме того информационная система должна обеспечивать возможности по ведению базы данных о клиентах и основных предоставляемых услугах.
Кроме того к функциональным требованиям можно отнести и требования по безопасности. Разрабатываемая информационная система должна быть хорошо защищена от воздействия извне.
Для обеспечения безопасности можно использовать как аппаратные, так и программные средства защиты информации.
Требования к удобству использования
Другими важными требованиями, предъявляемые к информационным системам, являются требования по эргономичности.
Под эргономичностью на сегодняшний день подразумевают общую степень удобства предмета, экономию времени и энергии при использовании предмета.
К разрабатываемой информационной системе можно предъявить несколько видов требований по эргономичности.
По поводу человеческого фактора.
Система не должна быть ориентирована на профессионального пользователя, поскольку пользователями в основном будут являться сотрудники отделов организации, чья специфика деятельности, далека от информационных технологий. Данным сотрудникам вовсе не обязательно знать работу компьютера в совершенстве. Кроме того разрабатываемая система должна максимально упрощать процессы обработки документации и работа с ней не должна вызывать сложностей. Интерфейс программного продукта необходимо сделать максимально удобным и попытаться достичь такого результата, чтобы он понимался интуитивно.
По поводу справочной системы.
Наличие подробной справочной системы вовсе необязательно, поскольку из-за потока документации у сотрудников вовсе не будет возможности изучать справку по работе с программой. Но в тоже время она необходима, поскольку пользователь может забыть некоторые аспекты работы с программой. Рекомендуется создать руководство пользователя.
По поводу документации.
Из документации по программному продукту необходимым является только инструкция пользователю. Остальная документация просто не будет использоваться при работе с программным продуктом.
Требования к надежности
Любая информационная система должна быть надежной. Необходимо достичь таких результатов, чтобы сбои случались крайне редко и при этом не приводили к повреждению базы данных или не работоспособности других клиентских приложений. Связана такая необходимость опять-таки со спецификой организации.
В случае если все-таки сбой произошел, информационная система, после сбоя должна самостоятельно восстановиться с минимальной потерей данных, причем в довольно сжатые сроки, поскольку поток клиентов может быть довольно велик. Для восстановления работы системы должно хватать ее перезапуска, но никак не переустановке всей системы. Кроме того сбой в работе информационной системы не должен повлиять на работы сторонних программных продуктов.
Работа разрабатываемой информационной системы должна быть довольно предсказуема.
Требования к производительности
Также можно выделить следующие требования по поводу производительности информационной системы:
Разрабатываемая система должна быть довольна, производительна и не занимать много системных ресурсов. Ее использование не должно приводить к замене уже имеющихся аппаратных устройств, а именно системного блока компьютера. Время отклика работы программы должно быть минимальным исходя из возможностей компьютерной техники, поскольку работа с операционными документами производиться постоянно и является необходимым условием функционирования любой организации.
Поскольку разрабатывается информационная система работа, которой предполагается в нескольких отделах отделения, ресурсы системы должны быть доступны, но в тоже время защищены от не санкционированного доступа.
Требования возможности сопровождения
Можно выделить следующие требования по поводу возможности сопровождения информационной системы:
Разрабатываемая информационная система должна быть адаптивной, поскольку в организации возможно использование нескольких программных продуктов на одной машине для выполнения различных обязанностей сотрудников. Поэтому информационная система не должна конфликтовать с программными продуктами сторонних разработчиков.
Также немало важным свойством информационной системы должно быть ее расширение. Должна иметься возможность дальнейшего расширения функциональности информационной системы, поскольку реализация полноценного программного продукта решающего все проблемы бумажного документооборота в рамках дипломного проекта практически невозможно.
Конфигурирование информационной системы должно быть минимальным и касаться довольно стандартных вещей, в основном вида или отражаемых документов. Но данное требование относиться больше как к дополнительным пожеланиям, нежели как обязательное требование.
Выводы
В результате анализа существующих программных средств были отражены положительные стороны, использования программных средств. Разработка нового программного продукта позволит фирме не только полностью адаптировать программный продукт под деятельность фирмы (а не наоборот как это часто бывает при внедрении автоматизированных систем), но и снизить затраты связанные с приобретением программного продукта. Все разработчики программных продуктов не продают права на использования, а как бы сдают в аренду, что накладывает обязательства на приобретение ежегодной лицензии. В случае если турфирма не слишком большая это довольно скромная сумма порядка 6 тысяч рублей, но в случае если необходимо устанавливать данный программный продукт на множество компьютеров, тогда эта сумма значительно возрастает даже с учетом предоставляемых скидок. Таким образом, для средних и крупных турфирм рекомендуется разработка собственных программных продуктов в области туризма.
Требования к программной системе часто классифицируются как функциональные, нефункциональные и требования предметной области.
Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.
Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
Нефункциональные требования. Описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и тд.
Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.
В действительности четкой границы между этими типами требований не существует. Например, пользовательские требования, касающиеся безопасности системы, можно отнести к нефункциональным. Однако при более детальном рассмотрении такое требование можно отнести к функциональным, поскольку оно порождает необходимость включения в систему средства авторизации пользователя. Поэтому, рассматривая далее эти виды требований, мы должны всегда помнить, что данная классификация в значительной степени искусственна.
Классический пример (см. рисунок 4.3) высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса.
Рисунок 4.3. Уровни требований по Вигерсу
Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.
Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases) .
Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей .
Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Группа функциональных требований
Группа нефункциональных требований (Non-Functional Requirements)
Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы , например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.
ФУНКЦИОНАЛЬНЫЕ И ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ 3
3. Обозначения и сокращения 3
4.ЦЕЛИ, ОБЪЕМ И РЕЗУЛЬТАТ СОЗДАНИЯ СИСТЕМЫ 3
5.ОБЩИЕ СВЕДЕНИЯ 5
6.ТРЕБОВАНИЯ К СИСТЕМЕ 7
7.ТРЕБОВАНИЯ К НСИ 13
8.ТРЕБОВАНИЯ К МЕТОДОЛОГИЧЕСКОМУ ОБЕСПЕЧЕНИЮ 14
9.ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ 14
10.ТРЕБОВАНИЯ К ПЕРЕНОСУ ИСТОРИЧЕСКИХ ДАННЫХ 15
11.ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ 16
12.ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РАБОТ 16
Функциональные требования к подсистеме «Бюджетирование» 18
1.ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ 18
Функциональные требования к подсистеме «Казначейство» 27
Функциональные требования к подсистеме «ТОИР» 36
Функциональные требования к подсистеме «Кадровый учет» 67
Функциональные требования к подсистеме «Расчет заработной платы» 81
Функциональные требования к подсистеме «Регламентированный учет» 91
Функциональные требования к подсистеме «Продажи» 112
Функциональные требования к подсистеме «Управление договорами» 116
Функциональные требования к подсистеме «Инвестиции» 128
Функциональные требования к подсистеме «МТО и склад» 142
Функциональные требования к подсистеме «Охрана труда» 152
Функциональные требования к подсистеме «Управление автотранспортом» 160
Функциональные требования к подсистеме «Делопроизводство» 168
Функциональные требования к подсистеме «Производство» 175
Функциональные требования к подсистеме «ОРЭМ» 181
Общие требования к корпоративной автоматизированной системе управления
1.ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ
2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
| Тонкий клиент | Клиентское приложение системы 1С.Предприятие 8. Тонкий клиент имеет ограниченную функциональность, предназначен для отображения данных пользователю. Вся работа с базой данных, объектными данными, исполнение запросов – выполняется на стороне сервера. Тонкий клиент получает готовые данные, подготовленные для отображения, и передает серверу данные, введенные пользователем, для дальнейшей обработки. |
| Сервер приложений | Основной компонент платформы 1С.Предприятие 8, обеспечивающий взаимодействие между пользователями и системой управления базами данных. Наличие сервера приложений (кластера) позволяет обеспечить бесперебойную, отказоустойчивую, конкурентную работу большого количества пользователей с крупными информационными базами. |
3. Обозначения и сокращения
| АСУТП | Автоматизированная система управления технологическим процессом |
| БДДС | Бюджет движения денежных средств |
| БДР | Бюджет доходов и расходов |
| ИТ | Информационные технологии |
| ИС | Информационная система |
| КАСУ | Комплексная автоматизированная система управления АО «КРЫМТЭЦ» |
| МТО | Материально-техническое обеспечение |
| МТР | Материально-технические ресурсы |
| НСИ | Нормативно-справочная информация |
| СУБД | Система управления базами данных |
| ТОИР | Техническое обслуживание и ремонт |
| ТЭП | Технико-экономические показатели |
| ФТТ | Функционально-технические требования к системе |
Значительной популярностью при разработке автоматизированных систем в настоящее время в России пользуется универсальный язык моделирования (Unified Modeling Language - UML). Несмотря на безусловные плюсы, использование UML сопряжено с рядом трудностей методического характера, на которые мы хотели бы обратить внимание читателя. Прежде всего, в UML вводится собственный понятийный аппарат, в рамках которого традиционные термины и понятия, связанные с созданием автоматизированных систем и используемые в течение десятилетий, заменяются на термины и понятия, не нашедшие пока в полной мере отражения в международных и отечественных стандартах в области информационных технологий.
Особенно это касается базового элемента языка UML "Use Case", который трактуется отечественными переводчиками как "вариант использования", "прецедент". При этом контекст, в котором переводится термин, не учитывается. Несмотря на то, что понятие активно используется уже довольно давно - путаницы возникает все больше и больше. Так, участники некоторых Интернет- форумов дошли до того, что сравнивают "Use Case" с техническим заданием. По мнению авторов, все это обусловлено стандартным описанием UML, не связанным с процессом разработки автоматизированных систем (АС), а также упущенной возможностью при переводе оригинала такое сопоставление произвести. К тому же существующие современные методики создания программных систем от ведущих мировых производителей, основанных на использовании UML и других нотациях, к сожалению, большинству отечественных разработчиков в оригинале просто не доступны.
Как печальный итог, использование терминов и понятий UML, по существу представляющих собой ошибки отечественных переводчиков, в недостаточной мере знакомых с процессами создания АС, привели к тому, что в различных средствах информации появились статьи, книги, модели и прочие источники, имеющие откровенные ошибки в трактовке процессов, моделей, документов, связанных с созданием АС. Особенно это явно проявилось при описании предметной области и определения требований к АС.
В данной статье представлен способ описания функциональных требований к АС и ее функций с использованием стандартов в области информационных технологий, современных методологий создания АС, и диаграмм "Use Case Diagram" и "Actvity Diagram" универсального языка моделирования UML 2.0. Авторы рассчитывают, что использование "Use Case" в контексте определения требований в соответствии со стандартами создания АС приобретет большую ясность.
Итак, рассмотрим процесс определения требований согласно действующим отечественным стандартам.
При использовании стандартов создания АС в соответствии с на стадии "Техническое задание" в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. АС разрабатывается на стадии "Эскизное проектирование" и "Техническое проектирование", описание автоматизируемых функций АС производится на стадии "Техническое проектирование".
При разработке АС в соответствии с должны быть отслежены связи между функциональными требованиями к системе и функциями системы, их реализующими. Функции системы в свою очередь должны быть детально описаны.
В табл. 1. представлены стадии работ по созданию АС и документы, формируемыми на стадиях, связанных с описанием требований и функций .
Как видно из табл. 1, создание АС на стадиях 3-5, подразумевает подготовку:
предварительной схемы функциональной структуры системы (эскизное проектирование);
окончательной схемы функциональной структуры (техническое проектирование);
описания автоматизируемых функций системы.
Таблица 1. Стадии создания АС и документы, связанные с требованиями к АС и функциями, их реализующими
|
№ стадии по ГОСТ 34.601-90 |
Наименование |
Документы, модели, создаваемые на стадиях по ГОСТ 34.602-89, |
ГОСТ, в котором описан документ |
|
Техническое задание |
Техническое задание (ТЗ) |
||
|
Эскизное |
Схема функциональной структуры |
РД 50-34.698-90 п. 2.3. |
|
|
Техническое |
Схема функциональной структуры |
||
|
Описание автоматизируемых |
РД 50-34.698-90 п. 2.5 |
В соответствии с ТЗ на АС есть документ, оформленный в установленном порядке и определяющий цели создания АС, требования к АС и основные исходные данные, необходимые для ее разработки, а также план-график создания АС.
В ТЗ определяются:
требования к системе в целом;
требования к функциям (задачам), выполняемым системой;
требования к видам обеспечения.
Функциональные требования к системе определяют, действия системы, которые она должна выполнять. Функциональные требования реализуются через функции системы . Под функцией АС подразумевается совокупность действий АС, направленная на достижение определенной цели или аспект определенного поведения системы , а под задачей - функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида .
Не функциональные требования есть ограничения, накладываемые на работу системы, и стандарты, которым должна соответствовать система .
В схеме функциональной структуры отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком.
В описании автоматизируемых функций приводят:
перечень подсистем АС с указанием функций и (или) задач, реализуемых в каждой подсистеме;
описание процесса выполнения функций;
необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком.
Теперь рассмотрим определение требований с использованием понятия "Use Case". Как уже говорилось ранее, в стандарте UML отсутствует привязка к стадиям создания АС, однако, производители CASE - средств для работы с UML и методологий использования UML, как правило, предлагают схожие подходы к работе с требованиями.
Рассмотрим, например, подход компании Sparx System, являющейся производителем инструментария Еnterprise Architect, поддерживающим создание моделей предметной области и АС с использованием UML 2.0. Ими предложен шаблон модели требований, представленный на рис. 1. На рис. 2 представлен пример модели требования с использованием шаблона.
Как видно из шаблона модели требований и его примера для моделирования требований предлагается использовать элемент UML "Requirement". Для моделирования функций системы предлагается использовать элемент "Use Case". При этом элемент "Use Case" в описании UML, представленном в инструменте Еenterprise Architect, трактуется следующим образом: "Use Case elements are used to build Use Case models . These describe the functionality of the system to be built. Use Case Model describes a system"s functionality in terms of Use Cases".
Другими словами, элемент "Use Case" используется для построения модели "Use case Model". Модель "Use case Model" используется для описания функциональности системы.
Под функциональностью системы в соответствии с понимается совокупность свойств программного средства, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности.
В спецификациях OMG UML (UML Superstructure Specification, v2.0, p. 17) элемент "Use Case" определяется как: "The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system".
Другими словами, элемент "Use Case" определяет последовательность действий системы, которые она может выполнять, включая ее взаимодействие с пользователем системы.
Рис. 1. Способ моделирования требований к системе
Рис. 2. Пример реализации требования
В дополнении к сказанному выше, хотелось представить определение модели "Use Case Model" из популярного в нашей стране и за рубежом процесса разработки систем Rational Unified Process компании IBM: "The use-case model is a model of the system"s intended functions and its environment …" (рис. 3).
Рис. 3. Определение модели "Use Case Model"
Модель "Use case Model" есть модель предполагаемых функций системы и ее окружения, и служит контрактом между клиентами и разработчиками. Модель используется как существенные входные данные в деятельности по анализу, проектированию и тестированию.
В табл. 2 представлено сравнение определений схемы функциональной структуры в соответствии с ГОСТ и модели "Use Case Model", функции системы и элемента "Use Case" в соответствии с описанием UML 2.0.
Таблица 2. Сравнение определений моделей и их элементов
|
Определение схемы функциональной структуры |
Определение модели "UseCaseModel" |
|
В схеме функциональной структуры отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком |
Если требуется в разделе указывается время выполнения функции. Время формирования отчета не должно превышать 5 сек. Если требуется в разделе указывается требования к надежности выполнения функции. Если требуется, в разделе указывается требования к характеристики необходимой точности выполнения функции. Если требуется, в разделе указывается требования к достоверности результатов выполнения функции. Связи с другими функциональными требованиями Если требуется, в разделе указываются связи между требованиями. Данный шаблон рекомендуется использовать при создании документа "Описание автоматизируемых функций" и схемы функциональной структуры. Использование шаблона существенно облегчит понимание требований системы и их реализации, как со стороны заказчика, так и со стороны разработчика, что позволит в свою очередь уменьшить количество ошибок, связанных с неправильно определенными требованиями. В заключении нам хотелось бы отметить, что перед применением UML для описания предметной области и систем необходимо изучить методики бизнес моделирования и разработки систем, которые предполагается использовать, и лишь затем перейти к созданию соглашений по моделированию с использованием UML. На наш взгляд, это конструктивный путь позволяющий избежать методических проблем, связанных с трактовкой терминов, а также обеспечить эффективное использование возможностей UML. Список литературыГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ"; ГОСТ 34.602-89 "ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ"; ГОСТ 34. 201-89. ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ; ГОСТ 34.003-90. "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ"; IBM/RATIONAL UNIFIED PROCESS; ГОСТ Р ИСО/МЭК 15026-2002. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. УРОВНИ ЦЕЛОСТНОСТИ СИСТЕМ И ПРОГРАММНЫХ СРЕДСТВ; РД 50-34.698-90. "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ"; ГОСТ 28806-90. ГОСТ КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ; |
Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы. В техническом задании мы описываем предметную область, существующую инфраструктуру Заказчика, требования к создаваемому функционалу, а также нефункциональные требования. Получившийся документ необходим как бизнес-пользователю для того, чтобы он убедился в том, что все его пожелания к будущей системе учтены, так и нам, чтобы оценить стоимость разработки системы.
Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.
Главным фактором успеха при разработке технического задания является правильно выстроенная коммуникация с заказчиком. Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде. При этом очень важно (1) разговаривать с заказчиком на одном языке, чтобы тому не приходилось разжевывать очевидные для специалиста понятия предметной области и (2) уметь правильно слушать.
Приведем ниже принципы, которыми мы руководствуемся при написании технического задания, и проиллюстрируем их выдержками из разработанного нами технического задания на многокомпонентную систему баннерной рекламы для крупной Интернет-компании.
Структура технического задания
Каждое техническое задание содержит несколько обязательных разделов. В них определяется назначение документа, терминология, общий контекст проекта. Обычно первая часть документа выглядит так:
Если в начале документа даётся общая, концептуальная информация о разрабатываемой системе, то во второй, основной части документа, детально прописываются бизнес-требования и существенные для оценки стоимости разработки функциональные требования к системе.
В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае — анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.
7. Система размещения баннеров
8. Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine
Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами. Учитывая специфику данного проекта, мы посвятили отдельный раздел взаимодействию баннерки с биллинговой системой. Также в отдельный раздел мы выделили требования к достаточно независимой компоненте сбора и отображения статистической информации, которая является для заказчиков рекламных кампаний и менеджеров рекламных агентств едва ли не основным компонентом системы.
Отдельный раздел технического задания описывает требования к компоненту Banner Engine, отвечающему за показ баннеров, учёт статистики, её обработку и сохранение в виде, пригодном для дальнейшего анализа и построения отчетов.
Это – технически самый сложный и самый высоконагруженный компонент баннерной системы. В ТЗ мы включили раздел, содержащий некоторые технические и архитектурные детали, связанные с работой Banner Engine. Прежде всего, это позволяет минимизировать риски при оценке стоимости разработки системы, ведь в зависимости от выбранной архитектуры трудоемкость может отличаться в разы.
Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.
Бизнес vs Функциональные требования
В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:
— Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-пользователя. Бизнес-требования, в частности должны быть понятны руководителю, не имеющему технической подготовки и опыта.
— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта. Углубление в сложные зоны позволяет снизить риски при последующей оценке проекта. Обычно функциональные требования включают блок-схемы, диаграммы состояний, потоковые диаграммы, и дополняются макетами наиболее сложных экранов.
Пример бизнес-требования:
«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь, связанных с показом баннеров сверх оплаченного лимита. Помимо этого, возникает задача ограничить показ одного баннера одному пользователю, например — не больше N раз в день».
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».
Обычно мы включаем
Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.
Роль: Администратор
Пример функционального требования:
«После добавления новой площадки в системе, администратор должен создать связанные с ней рекламные места. При создании рекламного места должны указываться площадка, тип места, поддерживаемый формат баннеров, размер, частота показов (для статических мест). После создания рекламного места оно становится доступным для менеджеров, размещающих рекламу.
Техническое задание содержит требования к интеграции разрабатываемой системы с другими внешними и внутренними системами, используемыми заказчиком.
В контексте технического задания на баннерную систему, это – интеграция с системами управления сайтом компании, биллинга, аутентификации и хранения данных пользователей.
«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».
В техническое задание мы обычно включаем глоссарий , разъясняющий значения специальных терминов, используемых в документе. Очень важно точно определить значение терминов, которые в дальнейшем используются в документе.
«Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».
Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.
Основные принципы
При написании ТЗ мы стараемся максимально использовать графические материалы для наглядного и сжатого представления информации. Одна диаграмма зачастую в состоянии заменить несколько страниц текста. В данном контексте, мы видим своей целью т.н. рисование ТЗ , т.е. представление всех более-менее сложных фрагментов системы в графическом виде и использование текста в качестве комментариев к графическим материалам.
У руководителей предприятий обычно нет времени на изучение многостраничных технических требований. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и нами и растет качество самих требований.
Cледующая схема, иллюстрирующая структуру рекламных кампаний и взаимосвязь между основными понятиями в рамках рекламных кампаний, сэкономила нам несколько страниц текста.
По необходимости, мы используем в ТЗ прототипы избранных экранов системы (functional wireframes), которые, не являясь окончательными, демонстрируют базовый блок функциональности пользовательского интерфейса.
Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.
Прототипы, уже на стадии разработки, дают заказчику понять, как именно будет выглядеть интерфейс системы.
Требования должны быть написаны «живым человеческим» языком , понятным бизнес-пользователю в т.ч. руководителю высшего звена, не обладающему техническими навыками; в них должен содержаться минимум технической терминологии. Чем быстрее пользователь «вникнет» в содержания технического задания, тем более эффективно будет выстраиваться наше с ним общение.
Опыт в предметной области
Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными. Накопленный опыт в области управленческих бизнес-систем, крупных интернет-проектов, финансовых систем, e-commerce систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.
