Вряд ли для кого-либо из посвященных будет секретом, что техническое задание, ТЗ, редко бывает изложено так, что исполнителю (да и заказчику) сразу становится понятно что делать, как делать и что из всего этого должно получиться. Оговорюсь сразу, что речь идет о ТЗ на проектирование систем в области информационных технологий, впрочем, некоторые описываемые далее принципы будут справедливы и для других областей.
Если не уделить достаточно внимания проработке ТЗ на самой начальной стадии работы над проектом, то вас гарантированно ждут трудности при сдаче работы, а нередко потеря прибыли и безупречной ранее репутации.
Существует множество тяжеловесных систем работы с требованиями, стандартов и методологий, описывающих эту работу. Ну, например, известны методологии PMI - института проектного менеджмента. В таких методологиях подробно расписаны подходы к выявлению требований, их сортировке, выделению приоритетов, противоречий, способов согласования, уточнения и так далее. Однако, как показывает практика, это все настолько громоздко - что использовать не хочется от слова "совсем".
Существуют графические нотации, типа UML или его расширения SysML, которые также позволяют описать систему и требования к ней. Они, вроде как, считаются сейчас устаревшими и популярностью не пользуются. На смену им пришли более современные нотации, которые производят на меня впечатление каких то комиксов с забавными картинками и подходят больше для презентаций, нежели для глубинного понимания.
Мое мнение, что и перегруженная методология и отказ от системных нотаций - это ошибка. Грамотная комбинация схем и подходов, описывающих проектируемую систему и требования к ней, весьма сильно помогает сделать нечто предсказуемое и полезное, ожидаемое Заказчиком с большой буквы "З".
В этой статье я хотел бы рассказать о своем подходе к анализу ТЗ и составлению некоторых полезных схем, позволяющих наглядно представить текстовое изложение требований и их проверок.
Важные тезисы
Система понятий, терминов, определений, которые используются при описании требований, должна быть единообразной, конкретной, одинаково пониматься и Заказчиком и Исполнителем.
Требования должны взаимно увязываться между собой, желательно выявить смысл каждого требования, цель его предъявления, а также влияние требования на оконечный продукт.
Выполнение требования должно быть достоверно проверяемо, то есть должна существовать такая процедура проверки, которая будет необходима и достаточна для подтверждения выполнения требования.
Способ проверки может быть разным для разных видов требований, выполнение требования может проверяться как аналитически так и фактически - непосредственным наблюдением.
Поясним каждый тезис. Что делает его важным? И что можно сделать, чтобы практически воплотить этот тезис?
Для пояснения, я буду использовать синтетические фрагменты ТЗ, банальные, но достаточные для иллюстративных целей. Предположим, мы разрабатываем некую систему сервисного обслуживания мобильных устройств.
Тезис про единство и конкретику понятий
Если Заказчик при составлении ТЗ использует разные термины для определения одного и того же, то это может ввести Исполнителя в заблуждение. На мой взгляд, даже синонимы при составлении требований - это зло. Кто даст гарантию, что даже сотрудники Заказчика однозначно понимают набор синонимичных терминов? Никто. И тогда, при изготовлении и приемке системы, изделия - каждый будет ожидать разного.
Пример:
...следует обеспечить обслуживание современных моделей оборудования...
Современные - это сколько месяцев, лет, начиная с какой даты? Современные по технологиям или по дате выпуска?
...должна быть обеспечена высокая скорость сервисного обслуживания...
Высокая - это какая? Какого именно обслуживания?
Ну и так далее...
Для того, чтобы избежать недопониманий, желательно при первичной проработке ТЗ выявить все термины и дать им четкие определения. Синонимы, если невозможно их избежать, перечислить совместно, в рамках одного определения. Дать количественные оценки для размытых понятий, типа "современные". Хорошо, если введены сокращения, которые используются при изложении. Это делает текст лаконичным.
Все это удобно сделать при помощи разработки документа, содержащего разделы "Используемые термины и определения", "Используемые сокращения". Во многих случаях, такие разделы будут включены (и по ГОСТ должны быть включены) в пояснительную записку проекта или научно-технический отчет по работе. Однако хотелось бы обратить внимание, что эти разделы ВАЖНЫ и им следует уделить внимание.
Про ГОСТы
Кстати, ГОСТы в свое время были продуманы очень грамотно. И если их действительно понять, а не просто тупо исполнять, то вероятность сделать качественный продукт существенно повышается.
Каждый термин, используемый в работе должен быть отражен в этом разделе с понятным описанием. Пусть это описание будет прочитано и понято, разъяснено заранее всем участникам работы. Например, определяем:
Современная модель оборудования - модель оборудования, выпущенная не ранее января 2022 года.
Если имеется возможность, желательно согласовать термины и определения с Заказчиком отдельным совместным решением, письмом, каким либо другим документом.
Тезис про смысл и взаимную увязку требований
Требования, изложенные в ТЗ, содержат разные понятия, излагаются в разных подразделах и в разных контекстах. Но, с точки зрения изготовления конечного продукта, все они должны иметь осмысленное значение и приводиться в ТЗ не просто так, а для достижения поставленной цели.
Если не сформировать при анализе ТЗ представление о том, как между собой связаны понятия и требования, то можно упустить какие-то важные моменты, которые не прописаны в ТЗ явно. Такое упущение может привести к тому, что формально ТЗ будет выполнено безукоризненно, но то, что будет реализовано на основании этого ТЗ, окажется никому не нужным и практически бесполезным.
Пример:
Цель работы: Разработка эффективной системы сервисного обслуживания мобильных устройств.
...следует обеспечить обслуживание современных моделей оборудования...
Мы уже ранее определились, что такое "современная модель". И под это определение вполне подходят устройства, которые недоступны на нашем рынке или крайне не популярны. Можно выполнить ТЗ буквально, но истинная цель работы при этом не будет достигнута! Имеет ли смысл система, умеющая обслуживать современные аппараты, которые никто не покупает или не может купить?
Что касается увязки требований между собой - представьте себе, что эти требования находятся в разных частях ТЗ. А еще можно представить, что устройство заказывается у исполнителя по отдельному частному ТЗ... Сложно все это сопоставить при помощи текста.
Для того, чтобы избежать конфликта требований можно нарисовать первую интересную картинку. Модель понятий. В которой каждый узел представляет термин, а стрелки разного типа - взаимоотношение между терминами. При этом, для каждого узла есть четкое определение задокументированное и согласованное на предыдущем шаге анализа. Типы стрелок удобно взять из нотации UML. Например, это относится к отношению "наследования", где обобщенное понятие, например, "Современное оборудование", может быть конкретизировано до "Мобильного телефона", "Планшета" и "Смарт-часов".
Составляя и представляя такую картинку участникам проекта, можно четко разъяснять, что "Существует пользователь, который эксплуатирует современное оборудование, типа Планшета или смарт-часов и он может обратиться в сервис для замены батареи".
По моей практике, такие картинки, схемы, помогают увидеть наглядно весь контекст ТЗ, каким бы сложным оно не было. Каждый термин приобретает смысл и значение с точки зрения разрабатываемого продукта.
Для того, чтобы пользователь обратился в сервис, он должен иметь возможность приобрести оборудование. Чтобы пользователей было много - модель должна быть популярна. Соответственно,имеет смысл уточнить термин:
Современная модель оборудования - модель оборудования, выпущенная не ранее января 2022 года и доступная к приобретению на потребительском рынке, при этом рейтинг модели должен быть не ниже 4 по оценке сайта market.yandex.ru или аналогичного.
Содержимое ТЗ, как правило, содержит:
Цель работы
Задачи
Требования
Цель работы достигается путем решения ряда задач, к выполнению которых предъявлены требования. Задачи могут включать в себя подзадачи. Требования могут предъявляться к структуре, составу, назначению, и т.п.
Эту иерархию удобно представить в виде диаграммы UML типа "Use case", диаграмма использования.
Такое представление дает удобный визуальный обзор основных работ, которые предстоит выполнить в ходе выполнения проекта. Ее можно детализировать в зависимости от сложности проекта. Например, можно уточнить, что исполнители бывают разные - Закупщик, Инженер, Менеджер.
Тезисы про проверяемость требований и разные способы проверки
Составив диаграмму использования, картинку про иерархию задач проекта, можно перейти к следующей картинке - представлению требований.
Для этого есть диаграмма UML (SysML) "Requirement diagram". Выглядит она примерно так:
Это простой фрагмент, на котором показаны следующие вещи:
Взаимосвязь с задачей, для которой эти требования сформулированы
Состав требований, а именно - что подразумевается выполнить для решения задачи
Что предполагается предъявить в качестве доказательства того, что требование было выполнено.
Чаще всего, для проверки выполнения требований выпускают документ, который называется "программа и методики испытаний", ПМИ. В нем подробно описывают что, в каких условиях, какими средствами, каким составом проверяющих, на основании каких процедур и по каким критериям проверяют.
Аналогично ТЗ, и более того - на одной диаграмме, этот документ (ПМИ) может быть представлен графически. Мне представляется это очень удобным, т.к. уже на этапе анализа ТЗ исполнитель продумывает - а как именно можно проверить требование.
То есть я предлагаю - разрабатывать набор испытаний сразу при получении ТЗ. И согласовывать его с Заказчиком тоже как можно раньше. В какой то момент, при составлении процедур испытаний, вы можете понять, что какие то вещи были недостаточно конкретизированы или сложно проверяются. Такого надо избежать!
Уже надоевший в этой статье термин "Современное оборудование" и связанное с ним требование может быть достоверно проверено так: "Убедиться, что представленное оборудование имеет дату выпуска не ранее 2022 года согласно информации на сайте производителя. Убедиться, что оборудование представлено на сайте market,yandex.ru и имеет рейтинг не ниже 4.0". Если все это так - то никаких претензий у Заказчика не возникнет и не может возникнуть. Все предельно конкретно и понятно.
Что касается типов проверок выполнения требований - они могут заключаться в визуальном осмотре, изучении документов, проведении эксперимента по методике. Все зависит от содержания требования. Но опять таки - они должны быть предельно конкретными, простыми, понятными всем.
Заключение
В этой статье приведен далеко не полный набор диаграмм и схем, которые используются в нашей практике при разработке сложных, комплексных проектов. Они прекрасно дополняют текстовые отчеты и помогают выявить упущенные детали,неявные связи, противоречия.
Из важных схем UML, которые в данной статье не упомянуты, я бы отметил еще диаграмму развертывания, на которой можно показать какие программные средства и как именно размещаются и взаимодействуют на "железе", системную диаграмму, на которой показано какие именно задачи решаются при помощи какого именно оборудования, диаграмму компонентов, на которой показано из каких частей состоит "железо" и как оно связано между собой.
Однако, даже приведенный здесь набор схем, картинок, весьма помогает при анализе текстовых документов. И не только ТЗ, а любых научно технических материалов, требующих медитации....
Если тема графического представления текстовых материалов кого-то интересует - пишите комментарии, есть еще чем поделиться...
:)
