Вообще говоря, требования как таковые – это некоторая абстракция. В реальной практике они всегда существуют в виде какого-то представления – документа, модели, формальной спецификации, списка и т.д. Требования важны как таковые, потому что оседают в виде понимания разработчиками нужд заказчика и будущих пользователей создаваемой системы.
Но так как в программном проекте много различных аспектов, видов деятельности и фаз разработки, то это понимание может принимать очень разные представления. Каждое представление требований выполняет определенную задачу, например, служит «мостом», фиксацией соглашения между разными группами специалистов, или используется для оперативного управления проектом (отслеживается, в какой фазе реализации находится то или иное требование, кто за него отвечает и пр.), или используется для верификации и модельно-ориентированного тестирования. И в первом, и во втором, и в третьем примере мы имеем дело с требованиями, но формализованы они будут по-разному.
Мастер-класс по сбору и анализу требований
Итак, формализация требований в проекте может быть очень разной – это зависит от его величины, принятого процесса разработки, используемых инструментальных средств, а также тех задач, которые решают формализованные требования. Более того, может существовать параллельно несколько формализаций, решающих различные задачи. Рассмотрим варианты.
Неформальная постановка требований в переписке по электронной почте. Хорошо работает в небольших проектах, при вовлеченности заказчика в разработку (например, команда выполняет субподряд). Хорошо также при таком стиле, когда есть взаимопонимание между заказчиком и командой, то есть лишние формальности не требуются. Однако, электронные письма в такой ситуации часто оказываются важными документами – важно уметь вести деловую переписку, подводить итоги, хранить важные письма и пользоваться ими при разногласиях. Важно также вовремя понять, когда такой способ перестает работать и необходимы более формальные подходы.
Требования в виде документа – описание предметной области и ее свойств, техническое задание как приложение к контракту, функциональная спецификация для разработчиков и т.д.
Требования в виде графа с зависимостями в одном из средств поддержки требований (Enterprise Architect). Такое представление удобно при частом изменении требований, при отслеживании выполнения требований, при организации «привязки» к требованиям задач, людей, тестов, кода. Важно также, чтобы была возможность легко создавать такие графы из текстовых документов, и наоборот, создавать презентационные документы по таким графам.
Формальная модель требований для верификации, модельно-ориентированного тестирования и т.д.
Каждый способ представления требований должен отвечать на следующие вопросы:
– кто потребитель (пользователь) этого представления;
– как именно (с какой целью) это представление используется.
Перечислим ряд ошибок, встречающихся при составлении технических заданий и иных документов с требованиями.
7. Интервьюируем ЗАКАЗЧИКОВ (выявляем бизнес-требования). Курс бизнес-аналитик с нуля
1) Описание возможных решений вместо требований.
2) Нечеткие требования, которые не допускают однозначную проверку, оставляют недосказанности, имеют оттенок советов, обсуждений, рекомендаций: «Возможно, что имеет смысл реализовать также…..», «и т.д.».
3) Игнорирование аудитории, для которой предназначено представление требований. Например, если спецификацию составляет инженер заказчика, то часто встречается переизбыток информации об оборудовании, с которым должна работать программная система, отсутствует глоссарий терминов и определений основных понятий, используются многочисленные синонимы и т.д. Или допущен слишком большой уклон в сторону программирования, что делает данную спецификацию непонятной всем непрограммистам.
4) Пропуск важных аспектов, связанных с нефункциональными требованиями, в частности, информации об окружении системы, о сроках готовности других систем, с которыми должна взаимодействовать данная. Последнее случается, например, когда данная программная система является частью более крупного проекта. Типичны проблемы при создании программно-аппаратных систем, когда аппаратура не успевает вовремя и ПО невозможно тестировать, а в сроках и требованиях это не предусмотрено.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Разработка продукта: «дискавери-фаза» и способы оценить необъятное
C чего начать IT-разработку и как посчитать стоимость, если вы создаете продукт с нуля, усиливаете команду или у вас есть идея MVP? Отвечаем на вопросы и делимся лайфхаками, с которыми мы оцениваем 400 проектов в год – в статье Анны Шведовой, главы направления бизнес-решений SimbirSoft. Затронем вопрос, что делать, если нет ТЗ, и как в проработке IT-решения помогает «дискавери-фаза».
2471 просмотров
Делимся опытом, как проводит оценки команда SimbirSoft, и показываем примеры из нашей практики – более 900 проектов, реализованных за 20+ лет. Надеемся, что наш опыт может быть полезен как заказчикам – мы расскажем, какая исходная информация нужна для оценки проекта, так и коллегам по отрасли – обменяемся уникальной presale-экспертизой.
Анна Шведова, руководитель направления бизнес-решений SimbirSoft
Что такое оценка продукта
Если вы хотите создать IT-продукт – будь то B2B-приложение для предприятия или «новый Uber» для B2C, на старте важно оценить объёмы разработки.
Имея детальную “смету” проекта, вам будет проще сделать следующие шаги – например, найти инвестора или защитить проект перед руководителем, подобрать необходимых специалистов и т.д. Кроме того, без оценки сложно определить как сроки разработки, так и необходимый состав команды.
Чтобы обеспечить точность расчетов и предусмотреть риски, компании стремятся собрать команду экспертов из нескольких подразделений. Зачастую это аналитик, дизайнер, опытные разработчики – по одному от всех задействованных направлений или те, у кого есть узконаправленная экспертиза, например, в построении highload-решений.
Так, у нас в SimbirSoft есть группа оценки – Presale-специалисты. Процесс оценки мы автоматизировали в собственном IT-сервисе, что позволяет оперативно и достоверно рассчитывать сроки и стоимость реализации проектов. Мы оцениваем около 400 проектов в год, на оценку стандартного проекта отводится в среднем 3-5 рабочих дней (в человеко-часах это будут иные цифры, т.к. каждый специалист подключается к процессу оценки только в нужное время).
Работа начинается со сбора требований к продукту. Хорошо, если у клиента есть техническое задание (ТЗ), спецификация или хотя бы краткое описание идеи, на основе которого мы можем сами составить список требований (UserStory) для MVP, по которому уже будут рассчитываться сроки и стоимость разработки.
Однако, не всегда есть сформулированные требования и/или пожелания. В этом случае мы используем иной подход к оценке. Рассмотрим, когда он бывает полезен.
«Дискавери-фаза»
Бывает так, что у клиента есть только идея будущего бизнеса (не “продукта”, а “бизнеса”). Нет ни ТЗ, ни четких требований, даже нет понимания, с чего начать – нет выделенного MVP. В этом случае компания-разработчик может предложить пойти двумя направлениями:
- Способ №1: начать с разработки ТЗ