Техническое задание на внедрение систем бизнес-анализа
Эксперты BI Consult готовы сформировать и защитить техническое задание на внедрение системы бизнес-анализа (BI, business intelligence).
На данном этапе проектная команда определяет будущую систему построения и использования бизнес аналитики в компании. Этот процесс в итоге охватывает многие смежные области: это и оптимизация бизнес процессов и появление новых KPI и возможно упрощение требований к управленческому учету.
Перед началом внедрения cистемы бизнес-анализа (BI, business intelligence) или хранилища данных, необходимо четко определить стратегию и постановку задачи, а именно:
- Насколько внедрение cистемы бизнес-анализа business intelligence согласовывается с целями компании;
- Перечень автоматизируемых бизнес-процессов;
- Объем обрабатываемых данных;
- Интенсивность использования Системы BI;
- Потенциальное количество взаимосвязанных приложений;
- Персонал, который будет использовать внедряемую Систему BI;
- Персонал, вовлеченный в процесс внедрения Системы BI.
Предлагаем Вашему вниманию примеры технических заданий для различных отраслей:
- Техническое задание на внедрение системы бизнес-анализа и отчетности для компании дистрибутора
- Техническое задание на внедрение системы бизнес-анализа и отчетности в страховом агентстве
- Техническое задание на внедрение системы бизнес-анализа и отчетности для компании фармацевтической отрасли
- Техническое задание на внедрение системы бизнес-анализа и отчетности для розничных сетей
- Техническое задание на внедрение системы бизнес-анализа и отчетности для сетей клиник (медицина)
- Техническое задание на внедрение системы бизнес-анализа и отчетности для торгово-производственной компании
- Постановка задачи для дэшборда
Этап обследования:
На этапе обследования осуществляется:
- Уточнение количества фактических и потенциально возможных пользователей Системы BI;
- Сбор и анализ требований к Системе бизнес-анализа;
- Уточняется периодичность использования формирования различных запросов/отчетов;
- Уточняются источники данных, смежные бизнес- приложения, форматы данных (as is и to be);
- Требования к синхронизации данных, консолидации, очистке и детализации;
- Оценка текущей инфраструктуры предприятия;
- Анкетирование;
- Согласование функциональных требований.
На базе полученной информации осуществляется формирование требований заказчика к Системе BI. Результатом этапа обследования является разработка технического задания (ТЗ), определяющего требования, порядок создания Системы BI. Техническое задание используется для фиксации требований, уточнения трудозатрат, осуществления калькуляции работ.
В соответствии с техническим заданием, производится проектирование и разработка Системы BI, а также приемка Системы при вводе в эксплуатацию.
Этап проектирования:
После разработки и утверждения ТЗ, осуществляется разработка технического проекта (ТП) реализации Системы BI.
На этапе проектирования осуществляется:
- Анализ требований в ТЗ;
-
По каждому требованию ТЗ определяется:
- Разработка спецификаций к модулям системы.
- Детальное проектирование реализации по каждому требованию.
- Перечень доработок компонентов Системы BI для реализации требования ТЗ;
- Возможность реализации требования функционалом готовых компонентов Системы;
- Определение взаимозависимостей между функциональными модулями Системы BI;
- Проектирование правил безопасности (требования к защите от несанкционированного доступа, аудиту, восстановлению информации, резервному копированию, к регистрации событий системы и др.);
- Разработка регламентов доступа к Системе BI;
-
Проектирование архитектуры решения:
- Анализ источников данных и информационных потоков;
- Проектирование взаимодействия информационных потоков между системами;
- Определение интеграционных связей;
- Разработка регламента взаимодействия между системами;
- Проектирование миграции данных из существующих систем;
- Определение единых форматов данных и схемы преобразования исходных данных в единый формат.
- Проектирование базы данных (описание всех объектов базы данных: пользователей, их привилегий, таблиц, представлений, индексов, кластеров, ограничений, пакетов, хранимых процедур и др.)
- Проектирование интерфейсов Системы BI.
При разработке технического проекта определяется целевая архитектура решения и прорабатывается детальная конфигурация будущей Системы BI, в частности:
- Проектирование архитектуры взаимодействия с внешними источниками данных, правил загрузки и преобразования информации;
- Организация хранилища данных;
- Проектирование витрин данных;
- Проектирование регламентированных отчетов и запросов;
- Проектирование архитектуры не регламентированных запросов;
- Проектирование архитектуры для осуществления многомерного анализа;
- Организация контрольных панелей;
- Организация мобильного доступа к информации;
- Организация подсистемы уведомлений;
- Проектирования интерфейса Системы BI;
- Определяются требования к аппаратному и программному обеспечению будущей Системы.
Технический проект определяет основные методы, используемые для разработки Системы BI и окончательного определения сметной стоимости Системы.
Для исключения создания изолированных BI-приложений и построения единой информационной структуры обеспечивающей работу с целостной и достоверной информацией при построении распределенной BI –системы, архитектура решения должна быть построена на использовании общих данных и объектной модели, должна использовать единую модель безопасности и администрирования.
Техническое задание на внедрение QlikView, Qlik Sense, Tableau, Microsoft PowerBI и других систем бизнес-анализа
На базе полученной информации осуществляется формирование требований заказчика к Системе BI; Результатом этапа обследования является разработка технического задания (ТЗ), определяющего требования, порядок создания Системы BI. Техническое задание используется для фиксации требований, уточнения трудозатрат, осуществления калькуляции работ. В соответствии с техническим заданием, производится проектирование и разработка Системы BI, а также приемка Системы при вводе в эксплуатацию.
Время на прочтение
15 мин
Количество просмотров 95K
Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.
Хорошо подумав, я решил, что вместить весь материал планируемой второй части в одну статью опять не получится, иначе это будет верхами и в теории, что и так написано во многих учебниках. Но ведь я ставлю задачу, чтобы это можно было применять на практике, поэтому не буду больше загадывать на будущее о том, сколько выпусков еще потребуется, чтобы закончить с темой. На это будет влиять и обратная связь с читателями, так что пишите, не стесняйтесь!
Пользуясь случаем, хочу задать вопрос: на сколько интересна была бы организация практического семинара-тренинга в Санкт-Петербурге на тему разработки Технического задания? Встретились бы, опытом обменялись. Если такой интерес будет не единичным, обещаю организовать.
Поскольку читателями являются не только специалисты в области разработки программного обеспечения, а также бизнес-аналитики и руководители различного уровня, постараюсь писать так, чтобы было интересно всем.
В этой части мы будет говорить о том, как организовать этап работ по сбору требований, из чего он должен состоять и какими инструментами можно пользоваться. Повторюсь, что данные работы с точки зрения этапов очень похожи на обследование предприятия с целью описания бизнес-процессов.
Как обычно происходит в жизни:
| Как это происходит в большинстве проектов | |
| Шаги | Как это происходит |
| Решение принято, проекту быть! | Понятное дело, что есть повод для радости, особенно, если проект большой, ничего плохого в этом нет! Главное, не радоваться слишком долго, оттягивая начало фактических работ, с этой минуты время будет идти по-другому. |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Обычно этот процесс ограничивается несколькими встречами с руководством, затем с руководителями подразделений. Зафиксировав некие «позывы» со стороны Заказчика, они фиксируются в виде общих формулировок. Иногда к этому добавляют имеющуюся документацию (кто-то когда-то пытался уже поводить обследование, документы по существующим регламентам, формы используемых отчетов) Как ни удивительно, но после этого большинство внедренцев систем автоматизации радостно восклицает: «да в нашей системе все это есть! Ну немного поднастроить и все будет работать». На вопрос, надо ли обсуждать, как все должно работать (или как выполняется конкретный процесс) с конечными пользователями, ответ обычно отрицательный. Высказывается мнение, что руководитель все знает за своих подчиненных. А зря… За этим скрывается множество ловушек и препятствий, и сдача работ может превратиться в марафон по полосе с препятствиями. Как известно, марафон принято бегать по ровной дороге, а бег с препятствиями возможен только на коротких дистанциях (можно и не добежать). |
| Документирование результатов работы | После этого начинается документирование результатов в зависимости от целей работ: Если требуется разработать Техническое задание, консультант начинает рассовывать полученную информацию по заготовленному шаблону документа, чтобы и выглядело красиво, и основные требования были зафиксированы (те, что озвучены от руководства, а то ведь могут не утвердить). Понимая, что на практике такое Техническое задание особо не используется и приходится все выяснять «по ходу дела», главной целью Технического задания он ставит минимальное время согласования и утверждения. И, если получится, информация для примерной оценки стоимости будущих работ (кстати, тоже немаловажно). Если требуется описать бизнес-процессы. Как ни странно, но часто все предшествующие действия выглядят аналогично, как и в случае с разработкой Технического задания. Разница лишь в оформлении документации. Тут возможны варианты: консультанты описывают процесс произвольными словами или используют какие-либо правила описания бизнес-процессов (нотации). В первом случае такой документ получается удивительным образом похож на Техническое задание. Бывает даже такое, что если заменить титульный лист, никакой разницы не увидишь.В последнем случае часто делают акцент не на соответствии действительности, а на «правильности описания», т.е. формальное следование правилам описания.К сожалению, оба варианта являются не самой лучшей практикой, т.к. являются скорее формальностью, а пользы приносят не много. |
Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».
Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?
Как видим, процесс заканчивается вопросом, т.к. на этом работа далеко не закончена и дальше начнется самое сложное и самое практичное – именно то, что будет определять применимость полученного результата в реальной жизни. Именно то, что будет определять судьбу предыдущей работы: или она отправится в шкаф (на полку или еще куда-нибудь), либо будет представлять собой ценный источник информации. А еще лучше, если она станет образцом для последующих проектов.
Хочу особо отметить, что до последнего шага на схеме (там, где вопрос) общий принцип сбора информации о деятельности компании выглядит одинаково, независимо от того, что планируется делать в дальнейшем, описывать бизнес-процессы или внедрять автоматизированную систему. Да, сама последовательность шагов одинаковая, но инструменты, применяемые на некоторых из них, могут отличаться. Мы данный момент обязательно рассмотрим, когда будем изучать методики и инструменты отдельных этапов. Подробно будем это делать в отдельных статьях, а сейчас рассмотрим только самое главное. Дальнейшие шаги будут отличаться и определяться тем, что требуется от проекта: описать бизнес-процессы или внедрять систему учета.
Давайте посмотрим, как можно реорганизовать подход к сбору информации о деятельности компании.
| Как это может происходить при более грамотной организации работ | |
| Шаги | Как это происходит |
| Решение принято, проекту быть! | Тут ничего не меняется относительно первого варианта, эмоции никто не отменял |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Этот шаг тоже остается, и он имеет большое значение. Но основное назначение первой встречи (или нескольких встреч) с руководителями и собственниками это знакомство. Знакомство в первую очередь с людьми и компанией. Сформулированные цели и пожелания на таких общих встречах могут быть самими различными, в том числе фантастическими. Все они будут, конечно же, выслушаны, но не факт, что будут реализованы. При более глубоком погружении в бизнес компании будут как появляться другие цели, так и отвергаться предыдущие. Я это к тому, что из предварительных встреч нельзя сформулировать четкие цели, все это потребует тщательной проработки.На таких встречах необходимо конспектировать все посылы от собственников и первых лиц, чтобы потом можно было к ним вернуться и обсудить, когда будет собрано достаточное количество информации. Даже простое на первый взгляд требование может оказаться нереализуемым либо очень трудоемким. |
| Формирование рабочей группы от Заказчика и Исполнителя, распределение ролей | Необходимо определиться, кто будет работать над проектом как со стороны Заказчика, так и со стороны Исполнителя. Несмотря на кажущуюся простоту данного этапа, он имеет очень большую роль. Если не зафиксировать четко, кто за что отвечает, в ходе реализации работ Вы рискуете столкнуться с неразберихой. Если со своей стороны Вы можете всегда конкретизировать роли в своей команде, то у Заказчика с этим могут возникнуть проблемы. На что следует обратить внимание: в состав рабочей группы Заказчика обязательно должны войти те люди, которые будут в дальнейшем хоть как-то влиять на принятие результата. Если допустить ситуацию, что при сдаче работ подключатся сотрудники Заказчика, которые не принимали участие в работах по формированию целей и выявлению требований, то проблемы гарантированы. Возможна даже такая абсурдная ситуация, что все, оказывается, сделано не так, как требовалось.В моей практике я сталкивался с такой ситуацией не раз.Поэтому, Вы себя можете обезопасить, если оговорите и зафиксируете документально, что никто, кроме рабочей группы Заказчика не может принимать участие в приемке-сдаче работ. А лучше всего, прописать такое в договорных условиях (В договоре или Уставе проекта). Помню, был такой случай: в одном крупном проекте учредитель решил подключиться к процессу (уж не знаю почему, скучно видать стало) и посетил одну из рабочих встреч, где обсуждался вопрос формирования счетов клиентам. Он с удивлением для себя узнал, что счет клиенту выставляет менеджер по продажам. В его представлении счет должен выставлять бухгалтер, и никак иначе. Но на самом деле бухгалтер вообще не представлял, о чем идет речь, а менеджер не мог себе представить, как так работать, если за каждым счетом бегать к бухгалтеру. В результате потеряли кучу времени, но ничего не поменялось, счет по-прежнему выставлял менеджер. А учредитель остался при своем мнении, но больше в процесс не вмешивался. На этом же этапе целесообразно разработать Устав проекта, в котором зафиксировать роли участников, порядок коммуникаций, регламент и состав отчетности, а также все остальное, что следует прописать в Уставе. Разработка Устава проекта это тема опять же отдельная. |
| Обучение проектной команды методикам и инструментам работы, согласование правил работы, видов и состава документации | Во-первых, необходимо разъяснить проектной команде все, что прописано в Уставе, как это будет применяться на практике. Во-вторых, проектную команду Заказчика необходимо обучить тем методам работы, которые Вы собираетесь использовать на всех последующих этапах. Имеет смысл обсудить форматы документов, которые будут использоваться, рассмотреть образцы. Если будут применяться какие-либо правила описания моделей или бизнес-процессов, то надо обсудить и эти правила, чтобы они были понятны. |
| Анкетирование | Этап анкетирования позволяет сравнительно быстрым способом получить достаточно достоверный срез информации о компании. Качество такой информации будет определяться тремя факторами:
Обращаю внимание, что методика анкетирования для последующей внедрения автоматизированной системы или описания бизнес-процессов в правильном случае различается. Конечно, структура анкет может быть и одинаковая, но это не самый лучший вариант. Когда мы описываем бизнес-процессы, то анкеты обычно носят более общий характер, т.к. неизвестно точно, с чем придется столкнуться. Если же речь идет о внедрении конкретной автоматизированной системы, то лучше иметь анкеты, учитывающие особенности этой системы. При таком подходе можно сразу выявить все узкие места системы, которые не подходят для данного предприятия. Как правило, методики внедрения готовых систем предусматривают наличие таких анкет. Такие анкеты могут разрабатываться либо по отдельным областям учета (например, учет заказов, продажи, ценообразование), либо для конкретных должностей (финансового директора, например). Состав вопросов примерно одинаковый. |
| Опросы | Опросом называется проведение устного собеседование со специалистами с целью выяснить особенности отдельных процессов. Необходимо организовать опрос так, чтобы он не выглядел как просто «встретились-поговорили», а более организовано. Для этого необходимо подготовить так называемый план опроса. В него можно включить те части анкеты, которые у Вас вызывают вопросы, противоречат сведениям других анкет или информация представлена поверхностно. Целесообразно добавить вопросы и просто из личного опыта.Ответы надо конспектировать в обязательном порядке. Идеально, если Вы договоритесь о ведении аудиозаписи. На этом же этапе следует проследить за полнотой предоставленной информации о документообороте (как форм первичных документов, так и различных отчетов) |
| Выделение ключевых бизнес- процессов или областей автоматизации | После анкетирования и опроса можно обосновано считать, что информации достаточно, чтобы делать выводы о выделении ключевых бизнес-процессов. На самом деле, уже можно выделить не только ключевые бизнес-процессы, но и практически все (если состав участников был выбран правильно). Вопрос выделения бизнес-процессов это тема совсем отдельная и не простая. Научиться тут сложно и вырабатывается в основном опытом. Из выделенных бизнес-процессов следует составить перечень (классификатор). Затем можно будет принимать решения, какие из них следует исследовать более глубоко, какие нет, а также выделять приоритеты. |
| Формулирование ключевых требований к системе, целей, критериев успешности проекта, процессов для детального изучения | К этому этапу должна быть собрана вся первичная информация о деятельности компании, составлен перечень бизнес-процессов. Теперь в самое время вернуться к целям, конкретизировать их, при необходимости обсудить с первыми лицами компании. При формулировке целей следует учесть конкретные показатели, при достижении которых будем считать проект успешным. Если речь идет о внедрении автоматизированной системы, то отдельным перечнем можно выделить требования к системе от ключевых пользователей. Я это делаю в виде отдельной таблицы, где все требования сгруппированы по подсистемам, для каждого требования указывается автор требования, формулировка и приоритет. Данную информацию можно будет использовать для составления плана развертывания системы (последовательности внедрения отдельных подсистем), а также для предложений по дальнейшему развитию системы (если отдельные подсистемы в текущем проекте внедрять не планируется). Если необходимо описать бизнес-процессы, принимаются решения о тех процессах, которые необходимо исследовать более детально. |
Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.
| Шаги | Что и как делать |
| Выделяем бизнес-процесс | Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично. |
| Детальное изучение бизнес- процесса | Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать) |
| Графическое и/или текстовое описание бизнес-процесса (первичное) | Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме. Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть. |
| Согласование с исполнителями и владельцем бизнес-процесса | Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить. |
| Выделение показателей бизнес-процесса | После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет. |
| Окончательное документирование бизнес-процесса | После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов. |
Теперь рассмотрим, как будет выглядеть подход к изучению требований к информационной системе с дальнейшим их отражением в Техническом задании
| Шаги | Что и как делать |
| Выделяем бизнес-требование/область автоматизации | Выделение в качестве требований целой области автоматизации (например, «Складские запасы») на практике используется, однако, это не самый эффективный способ детализации требований. Область автоматизации представляет собой группу требований, и рассматривать их лучше каждое в отдельности. Например, «Учет поступления материала на склад» |
| Детальное изучение бизнес-требования | Под детальным изучением бизнес-требования понимается то, как это хочет видеть и будет использовать конечный пользователь (разумеется, в соответствии с целями проекта). В технологиях разработки программного обеспечения это часто называют «вариант использования». Таким образом, детальное изучение бизнес-требования сводится к проработке вариантов использования. Пример такого варианта приведен в приложении 2 к статье. В простейших случаях варианты использования вовсе не обязательно рисовать в виде графических схем, можно ограничиться и текстовой формулировкой. Например, требование «При вводе номенклатуры цена должна рассчитаться как цена закупки +20%» рисовать не имеет смысла. В виде диаграммы имеет смысл представлять требования, объединенные до области автоматизации, как показано в примере в приложении 2. |
| Моделирование требований в информационной системе | Вот оно! Как Вы наверное помните, я уже обращал внимание на этот важнейший элемент в методике разработки Технических заданий. «Построй модель – получишь результат!» А что надо моделировать? Моделировать надо варианты использования, полученные на предыдущем этапе. Что должно быть на выходе моделирования? Должна получиться демонстрационная программа, в которую внесены пользовательские данные, причем желательно привычные его (пользователя) слуху, с учетом отраслевой специфики, актуальных проблем. И не просто так внесены, а должно быть понятно, откуда эти данные взялись, как рассчитались. В этом месте у читателя должны возникнуть вопросы:
Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная. Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит). Целесообразно сопроводить такую модель текстовым описанием, пусть даже кратким, чтобы пользователь мог самостоятельно попробовать поработать с моделью в свободное время. В этом же описании можно формулировать требования к доработкам. |
| Демонстрация информационной модели рабочей группе | Полученную модель показываем Заказчику и рассказываем, как все должно работать.Демонстрацию модели лучше проводить по подсистемам, т.е. по группам требований. В случае, если выяснится, что у клиента предлагаемая схема работать не будет, надо подумать о других вариантах использования, внести изменения в модель и показать еще раз. Только если есть уверенность, что планируемая модель у данного клиента «будет жить», можно считать модель удачной. |
| Разработка тестов | Зачем нужны тесты? То, как мы смогли реализовать требования, нужно будет проверять. Соответственно, на все ключевые участки, сложные алгоритмы и пр. тесты желательно сделать. В том числе эти тесты могут быть использованы при сдаче работ. Вовсе необязательно делать тесты на каждую функцию системы, везде должен быть здравый смысл. Если речь идет о готовой системе, то делать тест на «ввод нового элемента в справочник клиентов» будет выглядеть глупо и бесполезной тратой сил и времени. А вот если это совсем новая система, такое вполне возможно. Зачем делать тесты, если еще нет системы?Во-первых, разработчику будет понятнее, чего от него хотят добиться. Во-вторых, мы облегчаем жизнь тестировщику (кто-то ведь будет тестировать результат разработки). Вообще, тестирование это отдельная дисциплина, весьма не простая с множеством методик. На практике, как правило, все равно используются самые простые методы тестирования. |
| Документирование требований в виде Технического задания | Собранная информация на предыдущих этапах будет являться как раз тем, что и должно войти в основу документа «Техническое задание» в раздел с требованиями.Так что остается все это грамотно оформить. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дольше может начаться процесс разработки, поиск партнеров для проекта, тендер и т.д., все зависит от ситуации. |
Да, разработка Технического задания процесс трудоемкий, а значит и затратный. Но если он сделан грамотно, то избавляет Заказчика от не сбывшихся ожиданий. Исполнителю приходится делать то, что требуется Заказчику и не переделывать сто раз одно и тоже. Да и вообще, придает всему проекту прозрачность.
Приложение 1. Описанный бизнес-процесс в нотации EPC.
Приложение 2. Вариант использования подсистемы « Заказы»
Недавно мы рассматривали шаблоны разработки технических заданий на автоматизированные и информационные системы, а также стандарты спецификации требований к ПО. Сегодня поговорим, можно ли практике обойтись без всех этих ГОСТов, как бизнес-аналитику написать ТЗ, понятное для разработчиков, тестировщиков и Заказчика, а также при чем здесь UML с Agile.
Agile по-разгильдяйски или зачем нам ТЗ?
Российские ГОСТы по разработке ТЗ (уже недействующий 34.602-89 и заменивший его с 01.01.2022 ГОСТ 34.602-2020, что мы рассматриваем в новой статье, а также 19.201-78), а также зарубежные стандарты спецификации требований к ПО (ISO IEEE 29148-2018 и IEEE 830-1998), которые мы разбирали здесь – отличные шаблоны для составления технического задания, знать которые должен каждый аналитик. Однако, содержание любого предмета важнее его формы, поэтому давайте абстрагируемся от строгих рекомендаций и вспомним, зачем вообще нужно ТЗ и как его написать с максимальной пользой. Для этого ответим на 3 простых вопроса:
- зачем нужен этот документ;
- кто и для чего будет использовать изложенную в ТЗ информацию;
- есть ли в проекте жесткие правила и ограничения насчет структуры и содержания ТЗ.
Хотя ответ на первый вопрос может с первого взгляда казаться очевидным, все не так просто. К сожалению, на практике часто бывает, что ТЗ на продукт разрабатывается уже ПОСЛЕ его реализации в каком-то виде и нужно только в качестве обязательной части комплекта проектной документации, чтобы Заказчик и Исполнитель подписали договоры и акты выполненных работ. Другой вариант этого нежелательного кейса – так называемое «ТЗ для галочки», когда структура технического задания на разработку АС/ПО/ИС полностью соответствует стандарту, например, ГОСТ 34.602-89 или 19.201-78, но содержание написано общими фразами и не содержит полного набора функциональных и нефункциональных требований к будущему продукту.
В обоих случаях команда реализации рискует сорвать сроки и/или поставить результат, не соответствующий ожиданиям Заказчика. Поэтому важна не форма представления ТЗ, а полнота его содержания, обеспечивающая возможность создать работающий продукт, решающий проблемы бизнеса. Но не стоит ожидать от бизнеса четкого формулирования его пожеланий в виде готовых требований к продукту и тем более, документированного ТЗ. Определение требований и написание технического задания – это работа профессионального аналитика, которая требует определенных знаний и навыков, а также занимает массу времени. Поэтому опытный разработчик первым делом спрашивает у Заказчика ТЗ и не поддается провокациям типа: «У нас все по Agile, сейчас я на словах быстренько расскажу, что нужно». Однако, ТЗ необходимо не только для разработчика и Заказчика, этот документ читают и другие участники команды, о чем мы поговорим далее.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
24 апреля, 2023
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.
Для кого аналитик пишет техническое задание?
Агрегируя набор требований к решению с кратким описанием контекста его практического использования, ТЗ является базисом для Заказчика и команды реализации (разработчиков, тестировщиков, руководителя проекта). Поэтому можно сказать, что аналитик пишет ТЗ для следующих читателей:
- Заказчик – стейкхолдеры со стороны бизнеса, проблемы которого должен решить продукт с помощью его функциональных возможностей в заданных условиях его использования;
- Разработчик – к этой роли можно отнести как непосредственно программиста, пишущего программный код, так и архитектора ИТ-решения, а также тим/техлида и DevOps-инженера, т.е. всех непосредственных участников процесса реализации заявленных в ТЗ требований;
- Тестировщик – который проверяет, что результат соответствует заявленным ожиданиям, трассируя требования в набор тестов;
- Руководитель проекта – отвечая за бюджет и сроки поставки продукта, project manager должен понимать объем работы, который следует из контекста и набора требований к создаваемому продукту.
Несмотря на такой «разношерстный» состав читателей ТЗ, оно создается с единой для всех целью: описать, ЧТО должна делать проектируемая система, а не КАК (каким образом). А описание в ТЗ ограничений, зависимостей, экранных форм, а также доменных сущностей и взаимоотношений позволяет показать это точнее и понятнее. Помните, что техническое задание – это, прежде всего, набор однозначных и проверяемых требований к продукту, а НЕ план проекта, НЕ бизнес-кейс с технико-экономическим обоснованием разработки для инвесторов и НЕ проектное решение (пошаговое руководство для разработчиков).
Можно ли написать ТЗ не по стандартам?
Как уже было отмечено, все российские и международные стандарты по разработке ТЗ и спецификации требований – это всего лишь шаблоны для создания документа «техническое задание». Поэтому, если вы не работает с госзаказчиками и нет необходимости четко следовать структуре и содержанию этих ГОСТ’ов, а ТЗ нужно для единого понимания требований к продукту у бизнеса и исполнителей, можно разработать этот документ самостоятельно. Например, я предлагаю вам следующую рабочую структуру ТЗ на основе SRS по ISO IEEE 29148-2018, исключив некоторые пункты, предписываемые стандартом. Курсивом отмечены мои комментарии по включению в данный документ иллюстраций в виде UML-диаграмм и экранных форм.
- Введение
- Краткое описание – зачем и кому нужен продукт, какие бизнес-задачи и проблемы он решает, т.е. каковы бизнес-требования с плановыми целями и показателями их достижения
- Термины и сокращения
- Категории и характеристики пользователей и их потребности относительно продукта, т.е. требования стейкхолдеров, которые можно наглядно показать в виде UML-диаграммы use case
- Ограничения, бизнес-правила и стандарты
- Функциональные требования
- Функциональные требования – по каждому требованию:
- Название и кодировка
- Приоритет и трассировка с другими требованиями и/или бизнес-правилами
- Детальное представление в виде вариантов (сценариев) использования, так называемых юз-кейсов (use case) с возможными иллюстрациями основных и альтернативных потоков, например, в виде UML-диаграммы деятельности, BPMN или EPC-схемы бизнес-процесса. Также здесь можно показать экранные формы, доступные для актора в данном варианте использования.
- форматы и объем входных и выходных данных (результатов выполнения функции) – может входить в пункт Результат в описании вариантов использования
- Системные (архитектурные) требования
- Доменные сущности и связи между ними, что можно показать в виде UML-диаграммы классов или ER-схемы, описывающей таблицы базы данных
- Среда развертывания (программное и аппаратное обеспечение, например, операционная система ПК или мобильного телефона) – можно показать с помощью UML-диаграммы развертывания и компонентов
- Внешние компоненты (СУБД, браузер, сетевые подключения и пр.)
- Программные интерфейсы
- Интерфейсы оборудования
- Интерфейсы связи и коммуникации
- Нефункциональные требования
- Производительность
- Надежность и доступность
- Информационная безопасность и сохранность данных
- Удобство использования (пользовательские интерфейсы)
- Прочие требования
- К интеллектуальной собственности (патентная чистота)
- Требования к документации
- Функциональные требования – по каждому требованию:
Предложенную структуру можно дополнять и изменять по своему усмотрению. Например, добавить RACI и CRUDL-матрицы или включить в состав нефункциональных требований некоторые характеристики качества ПО, регламентированные стандартом ГОСТ Р ИСО/МЭК 25010-2015 «Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов» (ISO/IEC 25010:2011). О том, что такое нефункциональные требования и чем, например, надежность отличается от доступности, а также как измерить удобство пользовательского интерфейса, мы поговорим в следующий раз, а сейчас предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях.
Требования и ТЗ: открытый тест по российским и зарубежным стандартам
В заключение отмечу, что наличие у каждого из требований атрибута «приоритет» в ТЗ поможет проранжировать их по относительной важности и гибко управлять бэклогом в лучших Agile-традициях, реализуя в первую очередь самые важные требования. А дополнять ТЗ по мере изменения потребностей бизнеса и роста запросов к продукту можно, выпуская новую версию этого документа или частное техническое задание на отдельные части системы. О том, что такое ЧТЗ и как его составить, смотрите здесь. А про ошибки, которые совершают начинающие системные и бизнес-аналитики при разработке требований и ТЗ чаще всего, читайте в новой статье.
Практически разобраться с видами и формами представления требований, включая их специфицирование в ТЗ, вы сможете на курсе «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.
Техническое задание на внедрение систем бизнес-анализа
Эксперты BI Consult готовы сформировать и защитить техническое задание на внедрение системы бизнес-анализа (BI, business intelligence).
На данном этапе проектная команда определяет будущую систему построения и использования бизнес аналитики в компании. Этот процесс в итоге охватывает многие смежные области: это и оптимизация бизнес процессов и появление новых KPI и возможно упрощение требований к управленческому учету.
Перед началом внедрения cистемы бизнес-анализа (BI, business intelligence) или хранилища данных, необходимо четко определить стратегию и постановку задачи, а именно:
- Насколько внедрение cистемы бизнес-анализа business intelligence согласовывается с целями компании;
- Перечень автоматизируемых бизнес-процессов;
- Объем обрабатываемых данных;
- Интенсивность использования Системы BI;
- Потенциальное количество взаимосвязанных приложений;
- Персонал, который будет использовать внедряемую Систему BI;
- Персонал, вовлеченный в процесс внедрения Системы BI.
Предлагаем Вашему вниманию примеры технических заданий для различных отраслей:
- Техническое задание на внедрение системы бизнес-анализа и отчетности для компании дистрибутора
- Техническое задание на внедрение системы бизнес-анализа и отчетности в страховом агентстве
- Техническое задание на внедрение системы бизнес-анализа и отчетности для компании фармацевтической отрасли
- Техническое задание на внедрение системы бизнес-анализа и отчетности для розничных сетей
- Техническое задание на внедрение системы бизнес-анализа и отчетности для сетей клиник (медицина)
- Техническое задание на внедрение системы бизнес-анализа и отчетности для торгово-производственной компании
- Постановка задачи для дэшборда
Этап обследования:
На этапе обследования осуществляется:
- Уточнение количества фактических и потенциально возможных пользователей Системы BI;
- Сбор и анализ требований к Системе бизнес-анализа;
- Уточняется периодичность использования формирования различных запросов/отчетов;
- Уточняются источники данных, смежные бизнес- приложения, форматы данных (as is и to be);
- Требования к синхронизации данных, консолидации, очистке и детализации;
- Оценка текущей инфраструктуры предприятия;
- Анкетирование;
- Согласование функциональных требований.
На базе полученной информации осуществляется формирование требований заказчика к Системе BI. Результатом этапа обследования является разработка технического задания (ТЗ), определяющего требования, порядок создания Системы BI. Техническое задание используется для фиксации требований, уточнения трудозатрат, осуществления калькуляции работ.
В соответствии с техническим заданием, производится проектирование и разработка Системы BI, а также приемка Системы при вводе в эксплуатацию.
Этап проектирования:
После разработки и утверждения ТЗ, осуществляется разработка технического проекта (ТП) реализации Системы BI.
На этапе проектирования осуществляется:
- Анализ требований в ТЗ;
-
По каждому требованию ТЗ определяется:
- Разработка спецификаций к модулям системы.
- Детальное проектирование реализации по каждому требованию.
- Перечень доработок компонентов Системы BI для реализации требования ТЗ;
- Возможность реализации требования функционалом готовых компонентов Системы;
- Определение взаимозависимостей между функциональными модулями Системы BI;
- Проектирование правил безопасности (требования к защите от несанкционированного доступа, аудиту, восстановлению информации, резервному копированию, к регистрации событий системы и др.);
- Разработка регламентов доступа к Системе BI;
-
Проектирование архитектуры решения:
- Анализ источников данных и информационных потоков;
- Проектирование взаимодействия информационных потоков между системами;
- Определение интеграционных связей;
- Разработка регламента взаимодействия между системами;
- Проектирование миграции данных из существующих систем;
- Определение единых форматов данных и схемы преобразования исходных данных в единый формат.
- Проектирование базы данных (описание всех объектов базы данных: пользователей, их привилегий, таблиц, представлений, индексов, кластеров, ограничений, пакетов, хранимых процедур и др.)
- Проектирование интерфейсов Системы BI.
При разработке технического проекта определяется целевая архитектура решения и прорабатывается детальная конфигурация будущей Системы BI, в частности:
- Проектирование архитектуры взаимодействия с внешними источниками данных, правил загрузки и преобразования информации;
- Организация хранилища данных;
- Проектирование витрин данных;
- Проектирование регламентированных отчетов и запросов;
- Проектирование архитектуры не регламентированных запросов;
- Проектирование архитектуры для осуществления многомерного анализа;
- Организация контрольных панелей;
- Организация мобильного доступа к информации;
- Организация подсистемы уведомлений;
- Проектирования интерфейса Системы BI;
- Определяются требования к аппаратному и программному обеспечению будущей Системы.
Технический проект определяет основные методы, используемые для разработки Системы BI и окончательного определения сметной стоимости Системы.
Для исключения создания изолированных BI-приложений и построения единой информационной структуры обеспечивающей работу с целостной и достоверной информацией при построении распределенной BI –системы, архитектура решения должна быть построена на использовании общих данных и объектной модели, должна использовать единую модель безопасности и администрирования.
Техническое задание на внедрение Alpha BI, Loginom, Luxms BI, Modus BI, Visiology, Yandex.DataLens, Триафлай, Форсайт. Аналитическая Платформа, Arenadata, ClickHouse, Postgres Professional, ATK BiView-1C, Airflow и других систем бизнес-анализа
На базе полученной информации осуществляется формирование требований заказчика к Системе BI; Результатом этапа обследования является разработка технического задания (ТЗ), определяющего требования, порядок создания Системы BI. Техническое задание используется для фиксации требований, уточнения трудозатрат, осуществления калькуляции работ. В соответствии с техническим заданием, производится проектирование и разработка Системы BI, а также приемка Системы при вводе в эксплуатацию.
Юлия Ходакова
Начальник управления анализа и развития банковских технологий
Чтобы ТЗ было понятно и разработчику, и заказчику, оно должно соответствовать ряду правил. Каких? Разбираемся в статье.
Изучить аудиторию
- Для кого пишется документ? Кто его целевая аудитория (ЦА)? — Чаще всего это бизнес-заказчики, разработчики и тестировщики.
- Какой уровень подготовки у читателей? Насколько хорошо они знают предметную область? Насколько технически подкован бизнес-заказчик? — Тут всё зависит от само́й аудитории.
- Что хочет получить целевая аудитория от документа? — Заказчики хотят увидеть, что их требования учтены и как планируется их реализовать. Разработчики и тестировщики — понять, что делать.
- Что оценивает ЦА при согласовании документа? — Разработчики оценивают в ТЗ, насколько требования понятны и реализуемы; тестировщики — полноту описания для создания тест-кейсов; заказчик — полноту фиксации бизнес-требований и их реализации.
Эта информация плюс-минус актуальна для любого технического задания, и опытному системному аналитику не нужно тратить много времени на исследование ЦА. Джуниору же будет полезно пообщаться с коллегами, с тестировщиками и разработчиками в команде, с клиентом — и уточнить, что именно те хотят получить от документа и как этот документ в дальнейшем будет использоваться.
Собрать вводные от заказчика
На встрече с клиентом аналитик собирает информацию:
- Какими заказчик видит цели и задачи у проекта? Кто его целевая аудитория (пользователи)?
- На что в бизнесе заказчика повлияет достижение этих целей и выполнение задач?
- Делал ли уже заказчик что-то для закрытия этих потребностей бизнеса?
- Какой он видит реализацию проекта?
Как провести встречу
- Перед встречей с заказчиком, в идеале, стоит подготовиться: посмотреть вводные по проекту — возможно, заказчик уже предоставил описание и сопутствующие документы, — поговорить с коллегами и руководителем, которые наверняка смогут дать общие вводные. И ознакомиться с предметной областью и законодательством, например, если речь о реализации новых регуляторных требований. Это поможет разговаривать с заказчиком на понятном ему языке на известную вам тему.
- Заранее сформулируйте заказчику цель встречи и постарайтесь прислать вопросы, которые хотите обсудить. Так, у него будет время подготовить ответы и дополнительно пригласить на встречу других экспертов — если такие нужны.
- На первом интервью обязательно представьтесь, объясните свою роль на проекте и цель встречи.
Например, я, Иван Иванов, аналитик, буду разрабатывать техническое задание по вашему проекту… - Не полагайтесь на свою память: конспектируйте и записывайте встречу на диктофон. Но вначале обязательно предупредите собеседника о записи и получите согласие на неё.
- Сперва дайте слово заказчику — чтобы он подробно объяснил, в чём суть проблемы, которую должен решить проект, и что он хочет получить в итоге. И потом уточняющими вопросами дособерите информацию.
- В ходе беседы переспрашивайте, если что-то непонятно, но не злоупотребляйте этим, несколько раз задавая вопросы об одном и том же. Если нужно, уточните, где и у кого можно получить более подробную информацию.
- Уважайте время заказчика и соблюдайте тайминг. Если необходимо, запросите повторную встречу для обсуждения оставшихся вопросов.
- Поблагодарите заказчика за уделённое вам время и конструктивную беседу, зафиксируйте договорённости о коммуникациях и принципиальные вводные протоколом встречи.
- Не все заказчики одинаковы. Кто-то представляет себе, как должен быть реализован проект и готов в деталях рассказать о нём, кто-то может только сформулировать саму проблему. В любом случае сформулируйте один или несколько вариантов реализации и вернитесь к заказчику — чтобы тот выбрал вариант, который и пойдёт в работу.
«Дизайн на салфетке»
Я в своей практике постоянно использую приём «дизайн на салфетке». При обсуждении проекта сразу на бумаге прорисовываю и одновременно проговариваю с заказчиком верхнеуровневую схему реализации проекта — некий симбиоз бизнес-процесса, интеграции систем, документооборота и ролей участников. Такой подход позволяет:
- проверить правильно ли я поняла идею заказчика;
- совместно сформировать драфт концепции реализации проекта;
- выявить узкие места и зафиксировать вопросы, требующие дополнительной проработки, в том числе и со стороны заказчика.
«Дизайн на салфетке» отлично работает как с визуалами, так и с аудиалами. Немного хуже с кинестетиками, но это можно исправить, подготовив, например, динамические мокапы экранных форм.
Как написать ТЗ для разработчика и заказчика
Последующая работа аналитика и объём технического задания будут зависеть от того, что нам нужно: улучшить уже готовую систему или разработать новую.
Если нужно доработать уже существующую систему, то системный аналитик просто собирает требования бизнес-заказчика по задаче и вносит изменения в конкретные места ТЗ, которое было написано ранее. Или по договорённости с участниками готовит локальные требования, с учётом реализованного функционала и возможностей системы.
Если же продукта ещё нет, то он пишет для разработчика и тестировщика полное ТЗ на информационную систему, в котором описывает:
- общую информацию о ИС;
- предполагаемый технологический стек, на котором будет реализована система или ссылку на архитектурное решение, где это определяется;
- описание выполняемых бизнес-процессов;
- описание интерфейсов (пользовательских и интеграционных) и алгоритмов обработки объектов/данных, используемые справочники и формы отчётов;
- роли пользователей и доступные им функции, статусные модели объектов учёта.
Независимо от того, какое ТЗ вам нужно написать: полное или локальное, — при изложении информации нужно придерживаться трёх важных принципов. Расскажу о них в привязке к полному ТЗ на информационную систему.
Принцип 1. Структурированность информации
Важный принцип, соблюдение которого позволит и автору документа и его читателям быстро найти в нужную информацию.
Структуру ТЗ на можно разделить на 2 части:
- организационную;
- основную (тело ТЗ).
Когда вы приступаете к написанию документа, лучше сразу создать расширенную структуру ТЗ, которую в процессе работы уже можно будет дополнять. Уточните, есть ли в компании шаблоны документов, которые можно использовать для оформления организационной части ТЗ, если есть используйте их. Если нет — то шаблон, расписанный ниже.
В организационную часть входят:
- Титульный лист — наименование компании, кем утверждается документ (опционально), наименование документа, год создания документа.
- Оглавление — маршрутизация по документу. В Word есть удобный функционал для вставки и обновления Оглавления, используйте его.
- История изменений — нужный раздел ТЗ, который покажет разработчику и заказчику историю внесения изменений в документ. Например:
или
- Глоссарий — список сокращений и профессиональных терминов, которые используются в компании и документе — с пояснениями или ссылками на определения.
К основной части обычно относят:
- блок общей информации о ИС;
- детальное описание функциональных требований;
- нефункциональные требования.
Принцип 2. От общего к частному
Читая тот или иной документ, мы в первую очередь используем своего внутреннего визуала. Визуальное восприятие человека идёт «сверху вниз», то есть от общего к частному, и от крупных деталей к более мелким элементам.
Поэтому ещё один принцип, соблюдение которого сделает ваш документ более понятным и простым для восприятия — излагать информацию от общего к частному, от крупного к мелкому.
Помните, Техническое задание не художественный роман, и начинать документ с описания маленькой экранной формы (ЭФ) — плохая попытка заинтриговать читателей.
Как работает принцип «от общего к частному» покажу на примере расширенной структуры ТЗ.
В Блоке общей информации о ИС описывается:
- общая информация (цель создания ИС, её основное назначение и процессы какой предметной области должны быть реализованы в ИС);
- предполагаемый технологический стек, на котором будет реализована система или ссылка на архитектурное решение, где это определяется;
- перечисление выполняемых в ИС процессов/крупных функций;
- перечисление функциональных модулей ИС;
- интеграция — принципы интеграции; дополнительно опционально можно перечислить ИС, с которыми требуется интеграция.
Информация в данном блоке излагается крупно, ёмко, без деталей. Разделите Блок на подразделы. Как правило, Блок общей информации занимает в ТЗ не более 1,5–2 страниц.
Детальное описание функциональных требований
Это самый объёмный раздел ТЗ. По сути, его структура уже заложена списками бизнес-процессов/крупных функций и функциональных модулей, но теперь она расширяется и детализируется:
- Справочники — здесь описываются принципы использования справочников и списков, даётся список, справочников используемых в ИС. На этом уровне их можно разделить на группы: например, внутренние (ведётся в ИС, импортируется) и внешние. Описание каждого справочника, кроме наименования включает в себя: наименования атрибутов, коды атрибутов, их связь с другими справочниками.
- Роли — описываются ролевая модель: роли, функционал, кем и как администрируется.
- Функциональные модули — описываются принципы функционирования по каждому модулю из перечисленных в разделе «Блок общей информации —> Функциональные модули».
- Принципы построения интерфейсов ИС — описываются главное меню, если оно используется в системе. Также можно описать стандартные элементы экранных форм ввода и поиска.
- Список электронных сообщений, которыми система обменивается с другими системами. Раздел опциональный, информацию удобно оформлять в таблице — с явным указанием признака «входящее сообщение/исходящее сообщение».
- Реализуемые процессы — описываются алгоритмы выполнения каждого процесса в ИС из перечисленных в разделе «Блок общей информации —> Процессы». Описание процессов лучше всего располагать в логической последовательности.
При описании алгоритмов выполнения процессов нужно обязательно указать ролевую модель, справочники и тип процесса: ручной/полуручной/автоматический. И указать позитивный и негативный пути.
Для ручных процессов нужно прописать алгоритм выполнения от действий пользователя в системе — с указанием наименований экранных форм и используемых функциональных кнопок. Для автоматизированных — указать событие, инициирующее процесс, точки контроля выполнения процессов, результат выполнения. То есть артефакты, которые готовит система в процессе выполнения и по результатам конкретного процесса.
Если в рамках процесса ИС получает или формирует электронные сообщения, разработчику важно написать парсинг, который покажет, как разбирать и обрабатывать приходящие данные, как формировать сообщения и куда их отправлять. Этот раздел лучше оформлять в таблице.
Минимальное описание ЭФ включает
- Наименование поля на ЭФ.
- Тип и длина данных (на ЭФ и в базе данных, если отличаются).
- Обязательность (используют три варианта: О — обязательное, Н — необязательное, УО — условно/обязательное). Для УО в обязательном порядке прописать условие, при котором поле становится обязательным.
- Способ заполнения поля:
- ручное, автоматическое;
- выбор из выпадающего списка — перечисляем значения списка или даём гиперссылку на описание;
- выбор из справочника — даём гиперссылку на описание;
- чекбокс — описываем значения чекбокса;
- Проверки — описываются бизнес- и автоматические проверки поля.
- Маппинг на физическую модель данных (при необходимости).
Описание экранных форм (ЭФ) удобно давать в табличной форме.
Требования к печатным формам должны содержать
- шаблон печатной формы (со статической частью и динамической частью с маппингом на данные);
- алгоритм и режим формирования отчёта.
Требования к реализации ЭФ и ПФ можно оставить по тексту описания процессов. Но если таких описаний много и/или они объёмные, то лучше их вынести в отдельный раздел или приложение. А при описании давать гиперссылки на описание конкретных форм приложения.
Нефункциональные требования
Они могут относиться к системе в целом и к реализуемым процессам и функционалу в частности. Например: скорость отклика, режим доступности, пиковые нагрузки в периоде и тому подобное.
Принцип 3. Убрать информационный шум
Информационный шум — это элементы, усложняющие понимание текста, искажающие его смысл — или вовсе препятствующие адекватному пониманию содержания.
Если в документе сильный информационный шум, работать с ним сложно и автору, и уж тем более потребителям.
- В ТЗ не должно быть несогласованных предложений, бесконечных причастных и деепричастных оборотов, лексических и орфографических ошибок. Перечитывайте написанное перед отправкой документа на согласование. Хорошо, если дополнительно это будут делать коллеги, у которых не замылен глаз.
- Единое форматирование текста в документе и его приложениях обязательно. Разные шрифты, внезапный капслок или курсив, разные отступы и выравнивание абзацев, необоснованное цветовое выделение текста, отсутствие единого оформления заголовков и таблиц — всё это создаёт сильный информационный шум.
- Технические правки в документе, визуализируемые редактором в режиме рецензирования (например, форматирование, обновление ссылок или нумерации), нужно принимать перед отправкой на согласование документа.
- Описания однотипных объектов (например, справочников, ЭФ и ПФ) должны быть одинаковыми по форме и по составу данных. Массивные описания ЭФ и ПФ могут стать информационным шумом для описания реализуемого процесса. Решение одно — группируем и выносим в отдельный раздел или приложение.
Дополнительные артефакты ТЗ
Если разрабатываемая система будет обеспечивать выполнение STP-процессов с использованием электронного документооборота с внешними контрагентами удобно приложить DocFlow обмена электронными сообщениями:
Разработчик отсюда поймёт, как выполняется процесс, какие сообщения приходят на вход и выход, что нужно реализовать. А тестировщик сможет лучше протестировать сквозной процесс.
В некоторых ТЗ рисуют user story. Это помогает описать клиентский путь, адекватно спроектировать действия пользователя в системе и сделать user friendly интерфейс. С user story проще согласовывать ТЗ с заказчиком и делать тест-кейсы.
Полезно будет привести для разработчика в ТЗ диаграммы статусов пользователя и/или объекта учёта:
Что ещё важно
- ТЗ должно быть полным, нельзя пропустить раздел, потому что «тут и так всё понятно».
- Язык должен быть простым — насколько это возможно. «Хардовой» профессиональной лексики — немного, а все термины — объясняться в глоссарии. Помним, что уровень экспертизы потребителей документа может быть разным.
- В предложениях не должно быть двусмысленности, иначе появятся избыточные вопросы и замечания на этапе согласования. И велик риск, что разработчик реализует по ТЗ «как понял», а тестировщик «протестирует не то и не так».
В завершение хочу напомнить, что техническая документация, которую вы разрабатываете, — ваше лицо. Именно по документам, в первую очередь, судят о вас, как о профессионале. Поэтому ваша задача — сделать всё, чтобы подготовить идеальное ТЗ для разработчика и заказчика и по сути, и по форме.