Будущее требование: что это такое, описание и особенности

18. Разработка требований к программному обеспечению. Выявление и анализ требований. Спецификации требований. Управление изменениями требований.

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

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

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

На практике часто применяется подход, используемый в различных методологиях разработки ПО и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п.

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользователь­ские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания вы­полняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы — проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

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

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

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

Различие между пользовательскими и системными требованиями показаны в примере, представленном примере 1. Здесь показано, как пользовательские требования могут быть преобразованы в системные.

Пример. Пользовательские и системные требования

Пользовательские требования

1. ПО должно предоставить средство доступа к внешним файлам, созданным в других программах.

Спецификация системных требований

Пользователь должен иметь возможность определять тип внешних файлов.

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

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

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

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

Пользовательские требования пишутся для заказчика ПО и для лица, заключающего контракт на разработку программной системы, причем они могут не иметь детальных технических знаний по разрабатываемой системе (рис. 4.2). Спецификация системных требований предназначена для руководящего технического состава компании-разработчика и для менеджеров проекта. Она также необходима заказчику ПО и субпод­рядчикам по разработке. Эти оба документа также предназначены для конечных пользо­вателей программной системы. Наконец, проектная системная спецификация является документом, который ориентирован на разработчиков ПО.

Выявление и анализ требований

Фаза с таким или сходным названием (чаще всего применяют термин «разработка требо­ваний») присутствует во всех известных моделях жизненного цикла. Более того, совре­менные тенденции в технологии программирования таковы, что данная фаза все чаще рас­сматривается не только как первая, но и как главная, а иногда и решающая фаза жизнен­ного цикла. Дело в том, что заметные успехи технологии программирования позволяют, при наличии адекватных требований, организовать выполнение других фаз, если и не как автоматический, то, во всяком случае, как управляемый и измеримый процесс. Другими словами, если современные программисты точно знают, что именно нужно сделать, они это, скорее всего, сделают. Верно и обратное: если требования к программному обеспече­нию не определены, или недостаточно определены, то, скорее всего, успешной разработка не будет. Об этом свидетельствует статистика, собранная при анализе проведения проек­тов — большая часть причин неуспешного выполнения конкретных проектов была квали­фицирована как ошибки или недоработки на фазе анализа требований.

Схема разработки требований

Разработка требований это первая из основных фаз процесса создания программных сис­тем. Этот фаза состоит из следующих основных работ (рис. 5).

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

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

Формирование и анализ требований. Взаимодействуя с пользователями, обсуж­дая и анализируя с ними задачи, возлагаемые на систему, разрабатывая модели и прототипы, разработчики формулируют пользовательские требования.

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

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

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

Читайте также:
Предмета спора больше нет, а услуги юриста оплачены...

На этапе анализа разрабатываются пользовательские и системные требования к про­граммной системе, которые оформляются в виде единого документа – спецификации тре­бований, – являющегося формальным соглашением заказчика с разработчиком системы. Практика показывает, что требования к разрабатываемой программной системе часто из­меняются. Это обусловлено тем, что разработка программной системы довольно дли­тельный процесс, во время которого:

понимание пользователями возможностей системы, решаемых ею задач, может из­мениться;

происходят изменения в деловой среде, техническом, программном и другом обес­печении системы, которые должны быть учтены;

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

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

К действиям по управлению требованиями относятся:

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

анализ предлагаемых изменений требований, оценка воздействия и стоимости каж­дого изменения до его принятия;

включение одобренных изменений при помощи определенной процедуры;

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

отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

отслеживание статуса требований и действий по изменению на протяжении всего проекта.

В организации (или в проекте) должны быть определены действия по управлению требо­ваниями. Эти действия должны быть документированы и должны выполняться всеми уча­стниками проекта. При разработке процесса нужно определить:

методы и средства управления версиями спецификации и отдельных требований;

процесс разработки, согласования, экспертизы и утверждения базовой версии;

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

процесс передачи новых требований и изменений существующих требований заин­тересованным лицам;

методы анализа влияния и стоимости внесения изменения.

Кроме этого описание процесса должно содержать определение участников проекта, от­ветственных за выполнение каждой конкретной задачи.

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

В процессе выполнения проекта требование, обычно, изменяет свое состояние от началь­ного («предложено»), до конечного, например, «реализовано». Состояния требований по­зволяет оценить степень готовности проекта. Рекомендуются использовать состояния тре­бования, приведенные в табл. 1.

Таблица 1. Состояния требования

Определение

Требование запрошено авторизированным источником

Требование проанализировано, его влияние на проект просчитано, и оно было размещено в базовой версии определенной версии продукта. Клю­чевые заинтересованные в проекте лица согласились с этим требованием, а разработчики обязались его реализовать.

Код, реализующий требование разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода.

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

Утвержденное требование удалено из базовой версии. Следует зафикси­ровать причины и лицо, принявшее это решение.

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

В процессе управления требованиями должны быть определены лица, которые могут из­менить состояние требования. Управление статусом позволяет численно определить сте­пень готовности проекта, считая, например, что основная часть работы закончена, если все требования имеют состояние «Проверено» или «Удалено».

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

Диаграмма состояний для типового процесса внесения изменений в спецификацию приве­дена на рис. 6.

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

Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные вход­ные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых слу­чаях указывается, что система не должна делать.

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

Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не­функциональными.

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

Группа функциональных требований

Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.

Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).

Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа нефункциональных требований (Non-Functional Requirements)

Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.

Читайте также:
Двухпалатный парламент: что это такое, описание и особенности

Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.

Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.

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

Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функциисистемы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Виды требований и задачи управления ими по BABOK®Guide

Одна из основных профессиональных обязанностей системного и бизнес-аналитика – это управление требованиями при разработке программного обеспечения. Сегодня мы рассмотрим, какие виды требований выделяет BABOK®Guide и как это профессиональное руководство по бизнес-анализу рекомендует работать с ними.

Что такое требование и дизайн по BABOK

Начнем с определений по BABOK®Guide: требование – это пригодное для практического использования представление решения в виде условия или возможности, которые необходимы заинтересованной стороне (стейкхолдеру) для достижения цели, инициированной потребностью. BABOK®Guide различает следующие виды требований:

  • Бизнес-требование (business requirement), которое отвечает на вопросы «Почему это нужно?» или «Зачем я этого хочу?» и представляет собой отображение целей, задач и результатов, объясняющих, для чего было инициировано изменение и каким образом будет оцениваться успех его реализации;
  • Требование стейкхолдера (stakeholder requirement), которое отвечает на вопрос «Что нужно?» и описывает потребности отдельной заинтересованной стороны или целой группы стейкхолдеров, необходимые для выполнения бизнес-требований. Фактически, они могут играть роль проводника от бизнес-требований до требований к решению.
  • Требование к решению (solutionrequirement), которое отвечает на вопрос «Что я хочу?» и описывает возможность или качество решения, удовлетворяющие требованиям стейкхолдера. Требования к решению делятся на функциональные требования и нефункциональные. Функциональное требование (functionalrequirement) означает поведенческую возможность, которую должно предоставлять решение. Нефункциональное требование (non-functionalrequirement) описывает особенности эксплуатации: производительность, информационную безопасность, удобство использования и выражается в измеримых показателях, которые являются своего рода ограничениями варианта реализации (дизайна) решения. Подробнее про нефункциональные требования читайте в нашей новой статье.
  • Переходное требование (transition requirement), которое отвечает на вопрос «Каковы условия реализации перехода от бизнес-потребности к внедренному решению?», описывая возможности решения и условия, каким оно должно соответствовать для перехода из текущего состояния в целевое. В отличие от других видов требования, переходное требование является временным, т.к. становится не нужным после завершения изменения. Например, требование относительно форматов и процедур преобразования данных при переходе от одной системы к другой.

Штурм BABOK за 5 дней: подготовка бизнес-аналитиков к экзамену на сертификат CBAP/CCBA (IIBA® Endorsed Сourse, 40 PD)

Код курса
Ближайшая дата курса
Длительность обучения
40 ак.часов
Стоимость обучения
75 000 руб.

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

  • если фокус лежит на понимании потребности, речь идет о требовании;
  • когда речь идет о конкретном варианте реализации, т.е. решении, аналитик имеет дело с дизайном.

При этом руководство BABOK отмечает, что в ИТ-сфере термин «дизайн» обычно используется именно для технических вариантов решения, которые создаются непосредственно специалистами по реализации: разработчиками программного обеспечения, ИТ-архитекторами и т.д. А требование означает выдвигаемые бизнесом условия или ожидаемые возможности.

Трассировка требований: от потребности к дизайну

Задачи управления требованиями в BABOK®Guide

Из 6-ти областей знаний BABOK 2 посвящены непосредственной работе с требованиями: «Управление жизненным циклом требований» (Requirement Life Cycle Management) и «Анализ требований и определение дизайнов» (Requirements Analysis and Design Definition). Как видно из названия, область знаний «Анализ требований и определение дизайнов» носит инструментальный характер и сосредоточена на моделировании – именно здесь разрабатываются различные виды процессных и структурных диаграмм, например, UML, BPMN, IDEF0, EPC, DFD или ERD, чтобы описать поведение и строение проектируемого решения, а также процедуры работы с ним через решение следующих задач бизнес-анализа:

  • Спецификация и моделирование требований (Specify and Model Requirements)
  • Верификация требований (Verify Requirements)
  • Валидация требований (Validate Requirements)
  • Определение архитектуры требований (Define Requirements Architecture)
  • Определение вариантов дизайна (Define Design Options)
  • Анализ потенциальной ценности и рекомендация решения (Analyze Potential Value and Recommend Solution)
Читайте также:
Взаимные расчеты: что это такое, описание и особенности

Чем отличается верификация от валидации, читайте в нашей новой статье. А непосредственное управление требованиями выполняется в рамках области знаний «Управление жизненным циклом требований» и включает следующие задачи работы с требованиями:

  • Трассировка (Trace Requirements)
  • Поддержание (Maintain Requirements)
  • Приоритизация (Prioritize Requirements)
  • Оценка изменений (Assess Requirements Changes)
  • Утверждение (Approve Requirements)

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

Задачи управления жизненным циклом требований по BABOK®Guide

Практическое управление требованиями реализуется с помощью соответствующих программных инструментов, например, Archi для моделирования диаграмм, и Jira для трассировки, приоритезации и поддержания требований. В следующей статье мы рассмотрим, как организовать управление требованиями в Agile-проектах с учетом особенностей гибких методологий и строгих предписаний ГОСТов на разработку ТЗ.

Как писать требования чтобы их понимали

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

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

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

Начнем с обсуждения:

  • Общих принципов написания «удобных» требований
  • Использования таблиц
  • Использования схем и диаграмм

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

  • Подход Specification by Example
  • Варианты использования
  • Мокапы интерфейса

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

Здесь, как и в дизайне интерфейсов, отлично работает правило: «Не заставляйте меня думать», про которое писал Стив Круг в одноименной книге.

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

  • Используйте простой слог и слова, избегайте общих формулировок.
  • Избегайте сложносочиненных предложений. В идеале, одно предложение = одна мысль.
  • Если вы встречаете союзы «но», «или», то скорее всего, здесь скрыты два отдельных требования.
  • Не используйте двойные отрицания.
  • Для требованиий со структурой «если , то » пишите сначала результат, а потом – условие. Пример: « Система должна запрещать сохранение заказа, если хотя бы одного товара нет в наличии» .

« Должна быть возможность удалить конкретный товар или сразу все товары из корзины» .

По сути, данное требование содержит два отдельных требования:

  1. «Должна быть возможность удалить конкретный товар из корзины» .
  2. «Должна быть возможность удалить сразу все товары из корзины» .

Такое разделение поможет не пропустить скрытое требование разработчику или QA и подскажет менеджеру, что здесь лучше завести две отдельные задачи.

Сам текст должен быть хорошо отформатирован. Есть мнение, что разработчики «не читают» требования. Оно отчасти верно. Обычно это вызвано тем, что требования «неудобно» читать: плохая структура, сложный слог, слишком большие блоки текста – пока дочитываешь конец, забываешь началои т.д.

Используйте средства, которые доступны вам в любом редакторе:

  • Списки
  • Абзацы
  • Полужирный шрифт

Например, если вы используете союз «и» (или несколько таких союзов), то лучше каждое условие написать с новой строки.

«Необходимо перевести заказ в статус «Доставляется», если заказ оплачен и весь товар есть в наличии на складе.»

Давайте упростим восприятие этого требования. Получим следующее:

«Необходимо перевести заказ в статус «Доставляется», если:

  • Заказ оплачен
  • И весь товар есть в наличии на складе.

Что мы сделали? Мы сняли часть когнитивной нагрузки с того, кто будет изучать данное требование. Уже из форматирования становится видно, что:

  • Речь идет о заказе в статусе «Доставляется».
  • Действие изменения статуса должно выполняться при соблюдении двух условий.

На первый взгляд все это очевидно, но в процессе рабочей деятельности, я постоянно сталкиваюсь с подобными недочетами. Я намерено не пишу «ошибки», так как формально оба требования равнозначны, но на практике, второй вариант воспринимается гораздо проще.

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

«Заказ отображается в личном кабинете пользователя, если заказ находится в одном из статусов: «Новый», «Ожидает оплаты», «Оплачен», «Доставляется». Заказ в статусе «Доставлен» не должен отображаться в личном кабинете.»

Как можно его упростить:

«Заказ отображается в личном кабинете пользователя, если его статус не равен «Доставлен» .

Во-первых, мы сделали само требование короче, а значит вероятность, что его прочитают стала выше.

Во-вторых, технические специалисты отлично считывают такие конструкции и вы, опять же, снимаете с них когнитивную нагрузку.

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

Запомните, таблицы – ваш главный «бро» 🙂

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

  • Как я могу упростить эти требования?
  • Как эти требования можно оформить в табличном виде?

Почему таблицы лучше работают:

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

Рассмотрим пример части из ТЗ на большую государственную систему из открытых источников:

Читайте также:
Бюджетный кодекс: что это такое, описание и особенности

«Успешно авторизованный пользователь, входящий в группу пользователей c ролью «Исполнитель», должен попадать на «UI-006 Главная страница личного кабинета», а пользователь, входящий в группу пользователей с ролью «Наблюдатель» – на «UI-092 Главная страница Мониторинга (дашборд)» подсистемы «Мониторинг». Если пользователь в личном кабинете настроил страницу по умолчанию, то открываемая страница должна определяться на основе выбранной настройки.»

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

«После успешной авторизации в системе, пользователю должна открываться стартовая страница, согласно условиям ниже:»

Если в дальнейшем у нас появится новая роль, то нужно будет всего лишь добавить еще одну строку в таблицу.

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

Пример формы редактирования из того же ТЗ:

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

  • Тип поля.
  • Значение поля при открытии формы.
  • Ограничения на выбираемые данные.
  • Можно ли редактировать поле и требования к валидации (если есть).

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

Когда использовать таблицы (спойлер – всегда!):

  • Вы описываете два и более объектов со одинаковыми свойствами (поля формы; разделы сайта; роли пользователей и т.д.).
  • Вы хотите описать реакцию системы при возникновении определенных событий.
  • Вы описываете миграцию данных или маппинг полей между системами.

Схемы и диаграммы – это еще один отличный способ улучшить качество передачи знаний в команде разработки.

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

Далее я поделюсь схемами, которые использую чаще всего.

Зачем нужна: Показывает как разрабатываемая система взаимодействует с внешними миром.

Внешний мир может быть представлен: другими ИТ-системами, пользователями или устройствами.

Когда использовать: На этапе проектирования системы, чтобы:

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

P.S. Еще эту диаграмму очень любят архитекторы.

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

  • Разрабатываемая система изображается в виде круга в центре.
  • По ее периметру изображаются внешние акторы (системы, пользователи, устройства) в виде прямоугольников.
  • Стрелками рисуются потоки данных (в том числе физических объектов) от актора к системе и наоборот.
  • Нужно показывать только основные потоки данных и/или операции.

Пример контекстной диаграммы из книги «Разработка требований к программному обеспечению» (Джой Битти, Карл Вигерс):

BPMN – это нотация описания бизнес-процессов в виде набора обозначений и ряда определенных правил.

Зачем нужна: Позволяет зафиксировать описание бизнес-процессов на этапе их дизайна и использовать это «знание» на этапе разработки и внедрения решения.

Когда использовать: Вообще, у BPMN довольно широкий спектр применения.

В контексте описания требований, чаще всего эта нотация используется для описания взаимодействий пользователей с системой и между собой. Становится видно, какие операции выполняет пользователь, а какие – система, и в какой последовательности. Можно показать процессы обработки ошибок.

При разработке BPMN-диаграмм (в контексте описания требований) главное – избавиться от перфекционизма.

Ваша основная задача – передать информацию, которой вы владеете, команде разработки с минимальными искажениями.

Качество ваших диаграмм будет зависеть от количества ранее созданных (волшебной пилюли, увы, здесь нет). На начальных этапах советую использовать базовые элементы:

  • Start/End Events – начальное и конечное события.
  • Activity – Действие, которое выполняет пользователь или система.
  • Gates – Шлюзы. Используются для принятия решений и запуска параллельных процессов.
  • Lanes – Дорожки, которые разграничивают разные типы пользователей и системы.

Пример описания бизнес-процесса обработки инцидентов:

Если вам интересна отдельная статья про примеры построения BPMN-диаграмм на реальных примерах, напишите об этом в комментариях.

Зачем нужна: показывает как объект переходит из одного состояния в другое.

Когда использовать:

  • У объекта много состояний (2+), логика переходов зависит от определенных событий.
  • С объектом могут совершать действия сразу несколько пользователей (например, редактирование заказа). Это поможет выявить исключительные ситуации, которые можно заранее продумать, а не фиксить потом на production.

Как и схемы в BPMN, диаграмма состояний отлично читается и техническими специалистами, и бизнес-пользователями, и экспертами.

Пример диаграммы состояний для объекта «инцидент» из BPMN-диаграммы выше:

Разработка требований к ПО: общие понятия

Очень часто при внедрениях от клиента можно услышать фразы типа: “А как этого нет. Это же есть в ….. Я думал, что это само собой понятно. Я без этого не смогу нормально работать. Ваша система …..” Ну и дальше в таком роде. Справедливо ли это? Наверное нет. Каждая система (в данном случае я говорю про ERP ) содержит определенный функционал и может в себе не содержать некоторые “фичи” которые есть в других.

И когда начинается разработка или внедрение клиент должен озвучить все свои “хотелки” иначе существует риск, что что-то не будет реализовано и тогда пиши пропало.

Часть вины за это конечно лежит и на компании которая занимается разработкой или внедрением. Бизнес -аналитик (это человек который занимается сбором и обработкой требований) должен уметь задавать правильные вопросы и читать между строк. Клиент может и не сможет четко описать что он хочет и может ходить вокруг и около того, что ему действительно необходимо.

Стадия сбора требований как правило предшествует стадии разработки и внедрения. И именно на ней формируется scope проекта.

Что же такое требование? Уровни и типы требований

  • Бизнес-требования;
  • Пользовательские требования;
  • Функциональные требования.

Вдобавок к этому выделяют еще нефункциональные требования.

Давайте рассмотрим каждый уровень чуть более детальней.

Сплошные линии означают “содержатся в “, а пунктирные – “являются отправной точкой” или “влияют на”

Читайте также:
Платежи по кредитам не поступали в банк по вине магазина.

Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые она планирует достичь с ее помощью. Как правило их высказывают те, кто финансирует проект. Пример бизнес-требования: “Есть необходимость вести учет взаиморасчетов с контрагентами в разрезе договоров”.

Пользовательские требования (user requirements) описывают цели и задачи, которые пользователь должен иметь возможность выполнять с помощью продукта. Они описывают то, что пользователь должен иметь возможность делать с системой. Это по сути user stories и сценарии. Например: “Я как пользователь системы хочу иметь возможность быстро посмотреть остатки конкретного товара на складе и посмотреть историю его перемещений”

Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Такие требования описывают в форме традиционных утверждений со словами должен или должна. Например – “система должна в момент проведения в системе документов по взаиморасчетам с контрагентами (инвойс, банковская выписка) дать возможность указать договор по которому ведутся взаиморасчеты” или “система должна давать возможность пользователю выбрать место хранения при закупке товара, куда он будет оприходован” или “должна быть возможность указать в карточке сотрудника дату его рождения и система за 2 дня до его наступления должна высылать директору по персоналу об этом уведомление”.

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

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

“API метод должен возвращать список ресторанов в короткой форме: id, название, адрес”

Это функциональное требование, оно описывает поведение системы.

“API метод должен отдавать данные не более чем за 200ms на 95 перцентиле и не более чем за 500ms на 99 перцентиле.”

А это уже нефункциональное требование, которое описывает определённый атрибут качества – performance.

Разработка и управление требованиями

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

Выявление и сбор требований (elecitation)

Этот этап включает в себя все действия, связанные с выявлением требований, таких как интервью, совещания, анализ документов, создание прототипов и другие. К ключевым действиям относятся:

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

Анализ требований

Этот этап подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основными действиями на этом этапе будут:

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

Документирование

Представление и хранение знаний о требованиях определенным способом. Например в письменные требования, диаграмы пригодные для дальнейшего использования.

Утверждение требований

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

Нельзя создать идеальные требования. Если смотреть с практической точки зрения, то цель разработки требований – накопить общее понимание требований необходимое для разработки очередной порции продукта.

Управление требованиями

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

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

Установленная таким образом отслеживаемость требований используется для того, чтобы уведомлять заинтересованных участников об их выполнении, с точки зрения их соответствия, законченности, охвата и последовательности. Отслеживаемость также поддерживает управление изменениями как часть управления требованиями, так как она способствует пониманию того, как изменения воздействуют на требования или связанные с ними элементы, и облегчает внесение этих изменений.

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

Основные проблемы при работе с требованиями

Выявление требований непростой процесс. Проблему усугубляет то, что заказчик может говорить о чем угодно, но только не о том, что ему действительно нужно. Основное следствие проблем с требованиями – переделка того, что вы думаете что уже готово (на это расходуется от 30 до 50% общего бюджета разработки). С ростом объема переделок растет и растрата ресурсов и разочарования.

Создание более качественных требований это инвестиции, а не затраты.

Недостаточное вовлечение пользователей

Заказчики зачастую не понимают всю важность этапа сбора требований и обеспечения их качества. Это влечет за собой обнаружение ошибок в требованиях на поздних стадиях проекта ну и соответственно к задержке завершения проекта.

Еще существует риск того, что бизнес-аналитик может не понять и неправильно задокументировать бизнес-требования или потребности клиента. Иногда бизнес-аналитик может идти по пути определения “идеальных” бизнес-требований, которые реализуют разработчики. Но потом этим решением не пользуются.

Небрежное планирование

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

Читайте также:
Взаимное страхование: что это такое, описание и особенности

“Разрастание” требований пользователей

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

Двусмысленные требования

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

Требования -“бантики”

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

Противоречивые требования

Бывает, что какие-то конкретные два или более требования противоречат друг другу. Иногда “совсем”, что никак нельзя совместить. Иногда всё-таки можно предусмотреть “разные режимы”, в каждом из которых одно требование удовлетворяется, а другое при этом оказывается недоступно. Или решить какую-то из задач другим способом — тогда противоречие исчезнет.

Чтобы продвинуться в сторону решения, нужно начать разматывать цепочку “для чего / почему”. По каждому из требований (как было описано в первой части статьи). То есть мы должны понять как можно глубже, из чего возникли именно такие требования, и что люди, пришедшие с этими требованиями, хотят “на самом деле”.

Выводы

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

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

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

Как составить техническое задание и получить то, что нужно

Если вы заказываете у сторонних подрядчиков проект, в котором нет жестких стандартов качества, попробуйте работать по техническому заданию. Оно поможет в разработке сайта, дизайна, написании статей в блог или оказании других маркетинговых и IT-услуг. ТЗ конкретизирует пожелания.

Рассказываем, как составить ТЗ так, чтобы вас поняли, что в него стоит добавить, кто должен оформлять этот документ и какие есть нюансы и особенности.

Что такое техническое задание

Техническое задание, или ТЗ — это документ, в котором фиксируются требования к проекту. Условно ТЗ можно назвать любое поручение исполнителю, главное, чтобы в нем были ясно прописаны характеристики итогового продукта.

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

Когда стоит составлять техническое задание

Всё зависит от проекта и вашей бизнес-модели. Если проект маленький, вы доверяете исполнителю, и риск получить не то, что вы хотели, мал, можно обойтись устным поручением.

Если проект требует значительных для вас вложений, он связан со сложной IT-сферой, где много нюансов из-за особенностей технологий, или с творческой сферой, стоит зафиксировать требования в ТЗ.

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

Кто должен составлять техническое задание

Устоявшейся практики нет — как договоритесь с подрядчиком.

Заказчик делает сам

Например, гендиректор студии архитектурной фотографии «АрхФото» Анатолий Шостак называет идеальным заказом ситуацию, когда заказчик сразу присылает подробное ТЗ и просит оценить работы.

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

Анатолий Шостак
Гендиректор «АрхФото»

Совместная работа

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

Техзадание полностью делает исполнитель

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

Совместная работа по составлению ТЗ и заказ задания исполнителю отличается в первую очередь подходом. Например, вы хотите заказать интернет-магазин:

  • Совместная работа. Вы говорите исполнителю, что хотите сайт с аккуратным отображением на любых устройствах, с возможностью регистрации личного кабинета и сбора баллов. Подрядчик уточняет, долго ли хранятся баллы, как их будут использовать. И оформляет ТЗ в документ.
  • Делает исполнитель. Вы ставите задачу — сделать интернет-магазин. Исполнитель с помощью бизнес-аналитика собирает и структурирует ваши требования к магазину, а также изучает конкурентов и целевую аудиторию, предлагает добавить в ТЗ требование отображать сайт на телевизорах — потому что ваши покупатели часто заказывают товары именно так.
Читайте также:
Архипелажные воды: что это такое, описание и особенности

Универсального решения нет, но лучше доверять составление ТЗ представителю подрядчика — специалист лучше знает, как должен работать его проект. Но при этом не стоит отстраняться от работы — объясните подрядчику, зачем вам продукт, как вы планируете его использовать, кто и зачем им будет пользоваться, покажите примеры решений конкурентов, которые вы считаете хорошими.

Сколько стоит заказать ТЗ

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

Основатель компании по разработке информационных систем Work Solutions Максим Мул при заказе ТЗ рекомендует ориентироваться на 10-20 % от общей стоимости разработки продукта.

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

Максим Мул
Основатель Work Solutions

Если речь про IT-задачи, например, интеграцию между информационными системами, внедрение CRM, разработку дополнительного функционала ПО или приложения по API, то не стоит рассчитывать на ТЗ стоимостью меньше 50 000 руб., считает гендиректор компании «Информатика и Сервис» Владимир Севрук.

Чтобы составить минимально ценное для клиента и понятное разработчикам ТЗ, аналитику нужно потратить минимум одну неделю на опрос всех сотрудников клиента, уточнить возможность реализации требований с разработчиками и в итоге свести всё в один документ.
Такие затраты микро- и малый бизнес в основном не могут себе позволить — заказ ТЗ актуален для верхнего малого и среднего бизнеса, когда IT-продукт в итоге существенно сократит расходы бизнеса и это будет выгодно.

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

Платные подробные ТЗ применяют и в других сферах. Например, в архитектурной фотографии.

У нас есть более сложная форма ТЗ — мы называем ее «сценарий». Для сценария мы проводим предварительные съемки, прописываем и согласовываем все ракурсы с заказчиком, прорабатываем целевую аудиторию и рассчитываем тайминг каждого кадра с учетом движения солнца. И все это ещё до начала чистовой работы.

Анатолий Шостак
Гендиректор «АрхФото»

За составление такого подробного сценария в «АрхФото» берут деньги. В зависимости от сложности проекта и требований заказчика сценарий иногда стоит дороже самой съемки. Зато благодаря ТЗ заказчик еще до начала работ понимает, что получит в итоге, говорит Анатолий Шостак.

Как написать техническое задание

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

Пишите однозначно

Составляя ТЗ или описывая продукт подрядчику, старайтесь избегать качественных прилагательных. «Красивый» пиджак для одного человека будет приталенным, а для другого, наоборот, широкого покроя. Так и с любыми проектами: чем больше конкретики, тем лучше.

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

Бывает, что заказчик не знает, что конкретно хочет получить, причем часто сам того не осознавая. Из-за этого в ТЗ появляются расплывчатые и многословные формулировки. В итоге заказчик с исполнителем потратят значительное время на их уточнение. Эффективнее сделать ТЗ с конкретными и точными требованиями, без многословности.

Алексей Орлов
Руководитель проектов компании «Рексофт»

Стоит попробовать любые пожелания сводить к количественным требованиям.

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

Дайте подрядчику общую информацию

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

Гендиректор INOSTUDIO Максим Болотов рекомендует как минимум озвучить подрядчику идею проекта, который вы заказываете, уточнить, в чем его конкурентные преимущества и уникальность.

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

Максим Болотов
Гендиректор INOSTUDIO

Помогите разобраться в терминах и нюансах

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

Можно ввести отдельный раздел в виде словаря с расшифровкой или пояснять по ходу документа.

Покажите конкурентов

В ТЗ стоит добавить ссылки на аналогичные проекты и дополнить их описаниями: что конкретно нравится в аналогах, что стоит повторить, а чего точно стоит избегать.

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

Максим Болотов
Гендиректор INOSTUDIO

Уточните важные технические требования

Если вы делаете IT-продукт, стоит сразу согласовать все технические требования с вашим IT-специалистом и подрядчиками. Это необходимо, чтобы новое решение могло быть интегрировано в ваши имеющиеся платформы и бизнес-процессы.

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

Читайте также:
Идеологическая диверсия: что это такое, описание и особенности

О нюансах нужно предупреждать подрядчика еще во время обсуждения общего видения проекта и до составления ТЗ. Важно, чтобы исполнитель умел работать со всеми вашими технологиями.

Распишите сценарии использования продукта

Если вы делаете что-то стандартное, то так сильно погружаться в особенности продукта не стоит, это лишь запутает и добавит ТЗ многословности. Но в случае чего-то необычного попробуйте в техзадании отвечать не на вопрос «Что?», а на вопрос «Как будет делать пользователь?».

  • Плохо — «Требование 1. На сайте есть корзина, пользователь по дополнительному запросу может получить список дополнительных товаров». В этом случае непонятно, что и как должно работать.
  • Хорошо — «Когда пользователь заходит в корзину, сайт показывает ему всплывающий баннер. На этом баннере должны быть товары, которые могут пригодиться покупателю. Он может одним кликом добавить любой товар к заказу. Или закрыть окно». В этом случае понятно, как работает сценарий использования корзины и блока с кросс-товарами.

Если речь про IT-продукты, можно прописывать сценарии по такому шаблону:

  • действие пользователя;
  • ответ сайта;
  • если пользователь делает так, то сайт делает так;
  • если пользователь делает по-другому, то сайт отвечает так.

Опишите требования к проверке проекта

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

Например, для интернет-магазина это может быть:

  • Буду проверять корректное отображение в браузерах Chrome, Firefox, Mozilla трех последних версий.
  • Отображение на экранах мобильника с разрешением 320 px на 480 px, монитора с разрешением 1024 px на 802 px, большого монитора с разрешением…
  • Скорость разгрузки по сервису такому-то не больше 1 секунды.

Чем подробнее и длиннее чек-лист, тем лучше.

Двигайтесь от общего к частному

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

Шаблоны и примеры ТЗ

Универсального шаблона технического задания нет — требования будут отличаться в зависимости от отрасли и типа проекта.

Если вы решили составлять ТЗ самостоятельно, эффективнее попросить шаблон или пример у подрядчика. Или поискать брифы, которые предлагают заполнить исполнители у себя на сайтах — вопросы из таких форм можно использовать как разделы ТЗ.

Если планируете заказать IT-продукт, можно использовать за основу госстандарты. Например:

  • ГОСТ 34. Это еще советская разработка сбора требований для создания автоматизированных систем. Не готовый шаблон, но много вопросов к заказчику, которые помогут структурировать пожелания.
  • IEEE 29148-2011 — стандарт разработки сложных систем, в которых есть вопросы о требовании к функциям, а также рекомендация описать условия программного окружения, то есть платформ, которые будут работать вместе с вашим продуктом.
  • Rational Unified Process — продвинутая спецификация для разработки требований к IT-продуктам. Много внимания отводится вариантам использования.

Эффективнее будет составлять ТЗ вместе с выбранным подрядчиком. Он будет задавать вопросы, уточнять нюансы и структурировать информацию. А вы объяснять, что же вам в итоге нужно от продукта.

Когда ТЗ не нужно

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

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

С этим пониманием обратитесь к подрядчику. Возможно, он предложит использовать не ТЗ, а гибкие методологии создания продукта — когда сначала делают небольшой прототип, выпускают его, а затем собирают обратную связь от первых клиентов и постоянно дополняют требования на основе этой аналитики. С таким подходом проект реализуется с учетом потребности клиента.

Вместо ТЗ выгоднее сначала сделать предпроектное обследование, изучить реальные потребности клиентов, вместе с аналитиком подрядчика. А затем решать, нужно ли ТЗ вообще.
Может быть, выгоднее и эффективнее выполнять бизнес-задачу, например, с помощью SCRUM. Действуя небольшими итерациями в 1-2 недели, анализируя результат и постепенно дополняя требования.

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

Кратко — универсальные советы по составлению ТЗ

Составляя ТЗ самостоятельно или с подрядчиком, придерживайтесь следующих правил:

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

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

Будущее требование: что это такое, описание и особенности

  • Вебинары
  • Курсы
  • Услуги
  • Статьи
  • Конференции
  • Команда
Читайте также:
Пол-года не действовало ООО, сдавать ли нулевые отчеты?

Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.

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

Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.

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

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

В наглядном виде модель выявления требований представлена на схеме:

Модель выявления требований

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

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

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

Также бизнес-требования часто используются на проекте для приоритизации решений: если есть понимание, как то или иное решение связано с БТ, приоритизировать его не составит труда. Именно БТ являются снованием для принятия решений в ходе проектирования и внесения изменений в реализацию проекта.

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.

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

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

Вид БТ: Значимые характеристики продуктов или услуг

Примеры БТ:

  • Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
  • Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая ее.
  • Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.

Вид БТ: Распознавание и обработка событий

Примеры БТ:

  • Банк должен своевременно получать оповещения о сбоях в работе банкоматов.
  • К моменту начала этапа работ, все нужные материалы и оборудование должны находиться на объекте строительства и быть готовыми к использованию.
  • Сотрудники должны быть своевременно проинформированы о назначенных им задачах.

Вид БТ: Принятие решений

Примеры БТ:

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

Вид БТ: Сбор, обработка, хранение и предоставление информации

Примеры БТ:

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

Вид БТ: Обеспечение возможности выполнения действий

Примеры БТ:

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

Вид БТ: Предотвращение возможности выполнения действий

Пример БТ:

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

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

Требование, заданное с позиции «Система должна делать…», задает конкретное направление действиям разработчика, а также дает некоторые ограничения — в отличие от формулировки требований с позиции «Система не должна…»

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

Что представляет собой демпинговая цена

Больше материалов по теме «Ведение бизнеса» вы можете получить в системе КонсультантПлюс .

  1. Демпинг: разберемся с понятием
  2. Цели применения демпинга
  3. Разновидности демпинга
  4. Демпинг в международной торговле
  5. В чем минусы демпинговых цен
  6. Анти-демпинг

В борьбе за прибыль предприниматели используют различные средства, по факту сводящиеся к двум направлениям: борьба за получение денег (ценовая политика) или за клиента (конкурентная борьба). В этих торговых «войнах» нередко используется мощный инструмент, название которого звучит как выстрел – это демпинг.

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

Вопрос: Что такое демпинг? Будет ли считаться демпингом ситуация, при которой товар иностранного происхождения продается в ЕАЭС по ценам ниже цен товара, произведенного в Союзе?
Посмотреть ответ

Демпинг: разберемся с понятием

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

Читайте также:
Игорное заведение: что это такое, описание и особенности

НАПРИМЕР. Себестоимость 1 кг сливочного масла у фермерской организации составляет 300 руб. Компания участвует в тендере на поставку сливочного масла и выигрывает его, изъявив возможность продавать свой товар по 280 руб., включая сюда и затраты на упаковку, транспортировку, налоги и другие издержки.

К СВЕДЕНИЮ! Законодательствами некоторых стран демпинг запрещен и против него принимаются государственные меры.

Характерные признаки демпинга:

  • цена ниже себестоимости;
  • временное применение;
  • обусловленность стратегическим планированием;
  • пренебрежение контролем качества и уровнем сервиса;
  • заведомый материальный ущерб;
  • применение в конкурентной борьбе.

Вопрос: Установлен ли в Законе N 223-ФЗ по аналогии с Законом N 44-ФЗ процент снижения цены контракта, который можно считать «демпинговым» снижением?
Посмотреть ответ

Отличие демпинга от снижения цен

Цены, идущие вниз, – это далеко не всегда демпинг. Ценовая политика предприятия определяется многими факторами, среди которых – издержки производства, транспорта, зарплаты и др. Но «нормальная» цена, в отличие от демпинговой, какой бы низкой она ни была, никогда не упадет ниже уровня рентабельности. Внимание, это не демпинг:

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

Цели применения демпинга

Добровольный отказ от рентабельности, то есть продажа в убыток, – какой в этом экономический смысл? Зачем предпринимателю добровольно уменьшать цену, не давая производству возможность окупить выработку продукции? Есть определенные задачи, которые можно решить таким способом, применяя его в течение некоторого времени:

  1. Завоевание рыночной ниши. Если в определенном регионе или сфере деятельности появляется новое действующее лицо, оно может попытаться «втиснуться» на рынок, «переманив» потенциальных клиентов сниженными ценами.
  2. Борьба за солидного клиента. Ради «переманивания» серьезного партнера с тем, чтобы выиграть на объемах поставок или использования его имени в рекламе, можно какое-то время поработать и в убыток.
  3. Бонус для ценных партнеров. Чтобы стратегически важные клиенты остались верны фирме, она может на какой-то период организовать для них особые условия, в том числе и сниженные «до неприличия» цены.
  4. «Очистка завалов». Если у организации скопилось большое количество нераспроданных товаров, имеет смысл реализовать их даже в убыток, чтобы очистить место для новой продукции и повысить оборот.
  5. «С миру по нитке». Для привлечения розничных клиентов периодически можно вводить приятные для них демпинговые цены.
  6. Политика государства. Держава, стремясь снизить, например, процент по ипотеке, создает компании или банки с госучастием, вследствие чего и коммерческие банки вынуждены будут снизить процент.
  7. Долой «мелкую рыбу». Крупные компании, демпингуя, могут позволять себе «очищать» рынок от большого количества мелких конкурирующих фирм.

Разновидности демпинга

Сфера продаж разделяет демпинг на виды по особенности его реализации:

  • ценовой демпинг подразумевает продажу экспортного товара на внутреннем рынке по заниженной цене;
  • стоимостный демпинг – когда цену намеренно занижает сам экспортер.

В коммерции демпинг классифицируется по времени применения, степени вовлечения в деятельность организации и ее партнеров:

  • намеренный – применяется в соответствии с просчитанной стратегией и планом;
  • эпизодический (спорадический) – используется время от времени для избавления от излишков произведенной продукции;
  • постоянный – рентабельность достигается за счет качества и недопустимого снижения издержек;
  • оборотный – искусственное добавление цены на экспортную продукцию путем налогов и сборов для защиты внутреннего производителя;
  • взаимный – когда организации объединяются для создания рыночной монополии.

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

Демпинг в международной торговле

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

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

  • взять за норму самую высокую цену на схожую продукцию, предназначенную к экспорту из страны, куда собирается ввозиться товар;
  • сложить затраты на производство товара и добавить реализационные расходы.

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

В чем минусы демпинговых цен

В целом применение демпинга считается вредным для экономики. Если все сферы деятельности будут стараться уменьшить стоимость продукции для потребителя, не считаясь с реальными издержками, это очень негативно скажется на благосостоянии страны. Необоснованная дешевизна товаров легко порождает:

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

Анти-демпинг

Развитые государства принимают меры против неконтролируемого использования демпинговых цен, принимая специальные законодательные акты, такие как, например, Федеральный закон «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» от 05.04.2013 года № 44-ФЗ. В сфере международной торговли применяются антидемпинговые пошлины.

Компании – мировые производители также вправе принимать антидемпинговые меры, устанавливая приемлемый уровень цен для реализаторов и дилеров своей продукции и накладывая санкции в случае демпингования:

  • денежный штраф;
  • прерывание партнерских отношений;
  • урезание полномочий и т.п.

ВНИМАНИЕ! Несмотря на общую экономическую вредность, метод демпингования может быть полезен при разумном и дозированном применении для завоевания партнеров, привлечения клиентуры и наработки полезного опыта. Однако в постоянной перспективе конкурентная борьба должна вестись более «чистыми» способами.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: