требования к программному обеспечению - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN software requirement … Справочник технического переводчика

ГОСТ Р 53195.4-2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению - Терминология ГОСТ Р 53195.4 2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению оригинал документа: 3.1 анимация (animation): Имитация работы программного… …

ГОСТ Р 52980-2008: Системы промышленной автоматизации и их интеграция. Системы программируемые электронные железнодорожного применения. Требования к программному обеспечению - Терминология ГОСТ Р 52980 2008: Системы промышленной автоматизации и их интеграция. Системы программируемые электронные железнодорожного применения. Требования к программному обеспечению оригинал документа: 3.1 автоматическая локомотивная… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 8.654-2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения - Терминология ГОСТ Р 8.654 2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения оригинал документа: 3.18 алгоритм хэширования: Алгоритм, который сжимает… … Словарь-справочник терминов нормативно-технической документации

МИ 2891-2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений - Терминология МИ 2891 2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений: Данные измерительная информация, представленная в виде, пригодном для передачи, интерпретации или обработки. Определения термина из… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 8.674-2009: Государственная система обеспечения единства измерений. Общие требования к средствам измерений и техническим системам и устройствам с измерительными функциями - Терминология ГОСТ Р 8.674 2009: Государственная система обеспечения единства измерений. Общие требования к средствам измерений и техническим системам и устройствам с измерительными функциями оригинал документа: вид средства измерений:… … Словарь-справочник терминов нормативно-технической документации

МИ 3372-12: Рекомендация. Государственная система обеспечения единства измерений. Магистральный нефтепродуктопровод. Системы измерений количества и показателей качества нефтепродуктов. Общие технические и метрологические требования - Терминология МИ 3372 12: Рекомендация. Государственная система обеспечения единства измерений. Магистральный нефтепродуктопровод. Системы измерений количества и показателей качества нефтепродуктов. Общие технические и метрологические требования:… … Словарь-справочник терминов нормативно-технической документации

СА 03-002-05: Стандарт ассоциации. Системы мониторинга агрегатов опасных производственных объектов. Общие технические требования - Терминология СА 03 002 05: Стандарт ассоциации. Системы мониторинга агрегатов опасных производственных объектов. Общие технические требования: 2.1. Агрегат: совокупность механически соединенных механизмов, узлов, машин и конструкций, работающих… … Словарь-справочник терминов нормативно-технической документации

П ССФЖТ 45/ИСО 9001-2003: Системы менеджмента качества. Требования - Терминология П ССФЖТ 45/ИСО 9001 2003: Системы менеджмента качества. Требования: 3.7 запись: Документ, содержащий достигнутые результаты или свидетельства осуществленной деятельности (ГОСТ Р ИСО 9000). Определения термина из разных документов:… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 51904-2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию - Терминология ГОСТ Р 51904 2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию оригинал документа: 3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий … Словарь-справочник терминов нормативно-технической документации

Книги

• Технические средства автоматизации. Интерфейсные устройства и микропроцессорные средства. Учебное пособие , В. Ф. Беккер. В соответствии с тенденцией информатизации современных технических средств автоматизации описываются датчики, интерфейсные, микропроцессорные и компьютерные устройства. Излагаются основные…
• Средства мультимедиа , С. В. Киселев. В учебном пособии предлагается применение компетентностного подхода к подготовке операторов ЭВМ. Изложены основы использования мультимедийных программ на IBM-совместимых персональных…

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

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

1. Функциональные требования к программному продукту

В базе хранятся не только сами описания и иллюстрации, но и шаблоны, задающие формат хранения материалов, определяющие интерфейс ввода/вывода и представление материала вразличного типа отчётах. Шаблоны описывают 3 компоненты: MVC – model, viewer, controller.

На рисунке 7 изображены доступные действия для пользователей ПС.

Пользователь должен иметь возможность:

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

добавлять данные для составления отчёта.

применять шаблоны для генерации отчётов.

редактировать и просматривать сгенерированные отчёты.

создаватьи редактировать картографические схемы и планы.

применять темы оформления web-приложения.

Рисунок 7

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

Добавление на карту специальных отметок.

Сохранение карты в формате JPGи сохранение отметок в видеXML.

Возможность загрузки карты по отметкам XML.

На рисунке 8 изображена файловая схема онлайн–редактора с подробным описанием функций и входных и выходных данных для всех файлов.

Рисунок 8

1. Характеристика выбранных программных сред и средств

Скриптовый язык программирования общего назначения – PHP5 (PHPHypertextPreprocessor); PHP – язык написания скриптов, которые встраиваются непосредственно в гипертекстовые файлы и исполняются на Web-сервере.

HTML (HyperTextMarkupLanguage) – стандартный язык разметки документов во Всемирной паутине. Большинство веб-страниц содержат описание разметки на языке HTML (или XHTML). Язык HTML интерпретируется браузерами и отображается в виде документа в удобной для пользователя и понятной форме.

XML(eXtensibleMarkupLanguage);XML– язык разметки, определяющий ряд правил кодировки в формате, удобном для чтения как человеку, так и программным средствам. СпецификацияXML1.0 и ряд других стандартов это открытые стандарты заданыеW3C(WorldWideWebConsortium).

SQL(StructuredQueryLanguage)SQL– узконаправленный язык программирования, созданный для управления данных в системах управления реляционными базами данных.

JSON(JavaScriptObjectNotation);JSON– Открытый стандарт форматирования текста, удобного для пользователя, для передачи объектов состоящих из пар «атрибут-значение».JSONприменяется для приёма и передаче данных между серверами,web-приложением и сервером, как альтернативаXML.

Каскадные таблицы стилей – CSS3 (CascadingStyleSheets); CSS – технология описания внешнего вида документа, написанного языком разметки. CSS используется как средство оформления веб-страниц в формате HTML и XHTML, но может применяться с любыми видами документов в формате, включая XML и XVL.

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

Технология AJAX(AsynchronousJavaScriptandXML);AJAX– набор взаимосвязанных техникweb-разработки, позволяющие создавать асинхронныеweb-приложения. При помощиAJAXweb-приложение может асинхронно(в фоновом режиме) отправлять и получать данные, никак при этом не вмешиваясь в процесс отображения текущегоHTMLдокумента. Не смотря на наличие стандартаXMLв названии, данные могут быть различного типа.

Технология AJAJ(AsynchronousJavaScriptandJSON);AJAJ– это технология аналогичная технологииAJAX, однако в отличии отAJAXпередаются данные типаJSON.

Библиотека jQuery; – набор функций и инструментов, облегчающие поиск и манипулирование элементов на страницеHTML-документа, а так же ряд других возможностей, такие как анимация элементов, обработка событий и облегченныйAPIдля работы сAJAXилиAJAJ.

GIMP (GNU ImageManipulationProgram);GIMP– графический редактор, предназначенный для редактирования фотографий, который также применяется для создания дизайнаweb-сайтов.

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

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

XAMPP(X(cross)ApacheMySQLPHPPerl);XAMPP– Набор серверных приложений для созданияweb-приложения. Включает в себяweb-серверApache, СУБДMySQL, интерпретаторPHPиPerl, а так же множество других программных средств.

WAMP(WindowsApacheMySQLPHP);WAMP– Набор серверных серверных приложений для созданияweb-приложения. Включает в себяweb-серверApache, СУБДMySQL, интерпретаторPHP.

FileZilla – FTP-сервер(File Transfer Protocol). Удобный и простой в настройке и обращенииFTP-сервер, используется для хранения, скачивания и загрузки файлов наweb-серверApache.

ChromeDeveloperTools– Набор инструментов для отладкиweb-приложения, содержится вweb-браузереGoogleChrome. Позволяет выполнять отладкуJavaScriptиDOMкода.

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

GoogleMapsStaticAPI–APIпредоставляемый корпорациейGoogleдля работы со статическими картамиGoogleMaps. Предоставляет возможность выбора определенной части карты с помощью заданных параметров координат и параметра масштабирования.

YandexMapsJSv2 –APIпредоставляемый компаниейYandexдля работы с динамическими и статическими картамиYandexMaps. В отличии отAPIGoogleMapsимеет более удобный способ отправки параметров при помощиXML-документа.

EmbarcaderoDelphi2010 –IDE(IntegratedDevelopmentEnviroment) для создания консольных, оконных,webи мобильных приложений. Содержит компилятор для языкаObjectPascal, диалект языкаPascal.

HTML2Canvas– библиотека дляJavaScript, позволяет производит «снимок экрана» текущей страницы на основеDOMHTML-документа.

Значительной популярностью при разработке автоматизированных систем в настоящее время в России пользуется универсальный язык моделирования (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. Стадии создания АС и документы, связанные с требованиями к АС и функциями, их реализующими

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

В ТЗ определяются:

требования к системе в целом;

требования к функциям (задачам), выполняемым системой;

требования к видам обеспечения.

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

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

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

В описании автоматизируемых функций приводят:

перечень подсистем АС с указанием функций и (или) задач, реализуемых в каждой подсистеме;

описание процесса выполнения функций;

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

Теперь рассмотрим определение требований с использованием понятия "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. Сравнение определений моделей и их элементов

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

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

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

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

Структурность - определяет наличие установленных связей и отношений между элементами внутри системы, распределение элементов системы по уровням и иерархиям.

Целостность - означает то, что все элементы системы функционируют как единое целое.

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

Следить за состоянием документа на любой его стадии;

Получать исчерпывающую информацию о документе;

Хранить данные о документах

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

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

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

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

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

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

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

По поводу человеческого фактора.

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

По поводу справочной системы.

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

По поводу документации.

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

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

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

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

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

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

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

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

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

Требования возможности сопровождения

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

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

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

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

Выводы

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

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

Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (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 систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.