Представим, что нужно узнать стоимость и сроки разработки, но исполнитель не торопится озвучивать предложение, дает большие «вилки», а для точности просит ТЗ, хотя ему уже все предоставили. Разбираемся, почему так происходит и что с этим делать.
5646 просмотров
Понимание задачи
Прежде чем взяться за выполнение любой задачи, ее нужно тщательно проанализировать. Если постараться вместить анализ в простой алгоритм, то выглядеть будет вот так:
- Задача. В чем ценность?
- Решение. Как выполним?
- Работоспособность. Решение соответствует задаче?
- Результат. В каком виде ожидается результат?
- Срок. Когда нужен результат и почему?
- Ограничения. Что может повлиять на работу?
- Референсы. Делал ли кто-то что-нибудь подобное? Как мы можем это применить?
Этот алгоритм подходит для любой ситуации, даже самой мелкой бытовой:
- Задача: украсить комнату картиной;
- Решение: вбить в стену гвоздь;
- Работоспособность: гвоздь выдержит картину;
- Результат: картина висит на стене и радует глаз;
- Срок: успеть до прихода гостей на выходных;
- Ограничения: нужно сделать днем, чтобы не мешать соседям;
- Референсы: у друзей картина здорово смотрится над диваном.
Пример специально упрощен, потому что как мы увидим, в жизни задачи часто формулируются в виде готового решения. В данном случае — «вбить в стену гвоздь». Это ловушка.
Подмена задачи решением
Если задача направляется исполнителю в виде решения, то все может пойти не так — во-первых, сразу отметаются альтернативные варианты, а во-вторых, без понимания настоящей задачи нельзя убедиться в работоспособности, и весь вышеупомянутый алгоритм ломается.
С 1960-х в корпоративном мире популярна карикатура с качелями на дереве. Она высмеивает то, как разные отделы интерпретируют и реализуют проектные требования. Ожидаемо, сатира прижилась и в области разработки информационных систем. Для многих это иллюстрация испорченного телефона, хотя это лишь следствие, а первопричина — за пределами изображения.
Заказчик не описал свою проблему. Заказчик описал решение — качели.
Вернемся к нашему примеру с картиной. Исполнителю поручили вбить в стену гвоздь. Он не знает, для чего это, и какую ценность дает, поэтому не может предложить альтернативу — вдруг картина небольшая и легкая, и хватило бы двустороннего скотча? Вбив гвоздь, он свернет все работы и уберет инструменты, так как для него задача выполнена. Чтобы повесить картину придется во второй раз доставать стремянку, отодвигать мебель и так далее — дополнительные издержки.
Для масштабных задач эта проблема не менее актуальна. Перенесемся в сферу IT и посмотрим, как может выглядеть подмена:
- «Нужно разработать кастомную ERP-систему»;
- «Хотим запустить мобильное приложение на iOS и Android»;
- «Ищем пять сениор-фронтендеров на проект»;
- «Сделайте SPA на React».
Неопытного исполнителя здесь ничего не насторожит. Более того, он радуется такой заявке, если она соответствует профилю услуг. А опытные знают, что это не задачи.
Здесь начинается самое интересное. Озвучив решение, клиент ждет от исполнителя предложение. В этот момент одни начнут доставать звонками и просить заполнить бриф, тогда как другие пришлют оформленные КП с приблизительной стоимостью.
Какой из подходов правильный, а какой нет, мы судить не будем. У каждого свои методы работы. Кто-то действует на авось, кто-то планирует расширять смету после старта работ, кто-то по модели fixed-price вообще не работает.
Главное, что проект подвергается рискам на самом старте — ведь может оказаться, что:
- подойдет и коробочная ERP с готовыми модулями для интеграций;
- приложением будут пользоваться работники с Android;
- на проекте еще не готовы дизайн и API, фронтендеры будут простаивать;
- под текущий стек и требования лучше подходит Vue.
Проблема с подменой связана с устройством контрактной работы. Как обычно происходит? Компания решает, что ей нужно что-то автоматизировать или оцифровать. Она обращается к IT-поставщикам или объявляет тендер.
Участники тендера брифуют клиента, составляют ТЗ и готовят сметы. В этих документах написано, как должно работать ПО, из каких модулей состоять, какие интеграции включать. На основании озвученных предложений по срокам и бюджетам компания выбирает подрядчика.
Исполнитель выполняет контракт. На проекте срабатывают всевозможные риски, вследствие чего страдает внутреннее качество. После сдачи исполнитель получает деньги и умывает руки, а система оказывается не приспособленной к задачам компании и дорогой в поддержке и развитии. Компания решает все переделать. Цикл повторяется.
Нарушить порочный круг можно. Далее рассмотрим как.
Истинное предназначение ТЗ
Традиция контрактной работы в том, чтобы требовать от исполнителя четкого соответствия ТЗ, соблюдения сроков и бюджетов. Уровень проработки самого ТЗ остается за рамками этой работы.
Истинная цель документа — предоставить сторонам гарантии, что исполнитель не обманет и сделает все как надо, а заказчик не потребует лишней работы и заплатит. Поэтому ТЗ прикладывают к договору.
Обратите внимание, «как надо» — это решение, а оно часто оказывается неработоспособным. В интеллектуальном труде сначала нужно понять для чего, и только потом как.
Вопросы эти должны звучать как на высоком уровне бизнес-целей, ради которых создается продукт, так и на низком, касающемся технических особенностей реализации.
И вот здесь возникают сложности. Заказчик как правило понимает, зачем ему нужен разрабатываемый продукт, какие потребности бизнеса он должен закрыть. Возможно есть референсы, по которым формулируются собственные пожелания. Но если речь идет о сложных системах, этого недостаточно для начала разработки.
Ситуация усугубляется путаницей вокруг ТЗ. В обиходе этот термин часто используют для описания требований любого уровня детализации. А на самом деле это объемный документ на десятки или сотни страниц, содержащий технические подробности реализации. Но независимо от понимания, речь лишь о формате хранения самого важного — проектных требований .
Далее поговорим о содержании и качестве проработки самих требований.
Типы требований
Все проектные требования принято делить на четыре категории:
Бизнес-требования
Любой продукт разрабатывается для удовлетворения объективных потребностей бизнеса. Например, сотрудники предприятия работают с множеством однотипных документов, вручную внося их данные в действующую систему для последующего анализа или другого использования. Потребностью бизнеса в этом случае будет сократить время на обработку документов.
На этом этапе пока не понятно, каким именно способом должна помочь система для удовлетворения потребности. Возможны несколько вариантов решения: внедрить сервис автоматического распознавания или запрашивать данные из внешних источников и автоматически вносить в нужные реестры.
Критерии успеха также фиксируются на этом этапе. Например, «сократить средний срок обработки документов с двух дней до двух часов». Помимо конкретных целей фиксируются границы, чтобы заказчик и исполнитель понимали, когда работу над проектом можно считать завершенной.
Помочь сформировать бизнес-требования может аналитик, но полностью делегировать задачу не выйдет. Только заказчик знает все аспекты своего бизнеса и цели, для которых разрабатывается проект.
Пользовательские требования
Если бизнес-требования должны отражать потребности бизнеса, то пользовательские требования — потребности пользователей системы. Иными словами, пользовательские требования — это задачи, которые определенные классы пользователей должны иметь возможность выполнять в системе (например, «регистрация на обучающий курс», «бронирование отеля» и т.д.).
Их выявлением и документированием может заниматься аналитик из команды исполнителя либо специализированная организация, согласовывая результаты работы с заказчиком.
Функциональные требования
Функциональные требования описывают то, как отвечая на конкретные воздействия пользователя будет работать каждый элемент системы. Например, «система должна отправлять на электронный адрес пользователя, сделавшего заказ, уведомления об изменении статуса заказа».
Нефункциональные требования
Это требования, которые описывают, как должна работать система. Они могут определяться бизнес-правилами, требованиями к производительности, аппаратной совместимости, безопасности, внешними интерфейсами, ограничениями дизайна и реализации. Именно здесь определяется, на каких устройствах должна работать система, какой наплыв пользователей выдерживать одновременно, и какие языки программирования и технологии использовать.
Пользовательские, функциональные и нефункциональные требования должны вытекать из бизнес-требований, соответствовать целям, ради которых создается продукт. На них нужно ориентироваться, проверяя, будет ли та или иная желаемая функция способствовать достижению целей бизнеса, и стоит ли тратить на ее описание и разработку силы.
Как описывать требования
Бизнес-требования, а также нефункциональные требования удобно описывать в виде утверждений. Пользовательские и функциональные требования можно описывать с помощью пользовательских историй (user stories) и сценариев использования (use cases).
Пользовательская история — это краткое утверждение о потребности пользователя, сформулированное на повседневном языке. Формируется по следующему шаблону:
Например: «Как посетитель сайта образовательной платформы я хочу зарегистрироваться в системе, чтобы иметь возможность записаться на интересующий меня курс».
Такая формулировка позволяет разработчикам определить типы пользователей, которым должен быть доступен данный функционал, суть самого функционала и цель его реализации.
Последнее полезно для сопоставления с бизнес-требованиями, чтобы можно было понять, насколько данный функционал будет соответствовать целям создания продукта. Пользовательская история не должна содержать описания конечной реализации требования.
Вместе с исходным утверждением формулируются критерии приемки разработанного в рамках пользовательской истории функционала. На основании этих критериев разработчики смогут выделить в рамках пользовательской истории подзадачи для реализации конкретных функций, а тестировщики — составить тесты для их проверки.
Формат удобен тем, что не требует много времени для составления, а также большого объема документации. Но с их помощью не всегда можно описать альтернативные варианты развития событий или какие-то сложные кейсы. Для таких случаев можно применять сценарии использования.
Сценарии использования — это описание последовательности взаимодействия системы и внешнего действующего лица, в результате которого действующее лицо получает полезный результат.
Структура сценариев использования может различаться на разных проектах, но, как правило, должна содержать:
- название и идентификатор;
- наименования действующих лиц;
- входные и выходные условия;
- триггер, запускающий описываемый сценарий;
- пошаговое описание нормального и альтернативных направлений развития сценария;
- исключения;
Сценарии использования более подробны, в сравнении с пользовательскими историями, и потому более удобны для разработчиков, но в то же время на их написание уходит больше времени.
Поэтому способ описания требований лучше выбирать с учетом их сложности, а также используемой в проекте методологии (пользовательские истории больше подходят для проектов гибкой разработки, тогда как варианты использования — в проектах с водопадной методологией).
В каком формате хранить требования
Требования к продукту фиксируются в проектной документации. Состав документации зависит от степени сложности и объемов проекта и может включать техническое задание, высокоуровневое проектирование, спецификацию на разработку, устав проекта и т.д.
Документ о концепции и границах (vision and scope document) содержит описание бизнес-контекста и концепции продукта, исходные данные, цели и задачи, критерии успеха и ограничения. Этот документ можно назвать верхнеуровневым; он нужен, чтобы зафиксировать основные ожидания от продукта.
Остальные типы требований фиксируются в спецификации или техническом задании, на основании которых можно приступать к написанию кода.
Спецификация требований (specifications) описывает функции и ограничения разрабатываемого продукта. Документ включает общее описание продукта, классов пользователей, которые будут с ним взаимодействовать, операционной среды, различных ограничений по дизайну и реализации, функций системы, а также требований к данным, внешним интерфейсам и пр.
Техническое задание (statement of work) содержит подробности реализации проекта, а также описание порядка контроля и приемки системы, состава работ по вводу ее в действие, требования к документированию и источники разработки. Однако в зависимости от проекта, какие-то разделы могут объединяться, добавляться или убираться.
Упрощая, можно сказать, что спецификация — это документ о том, как создать продукт, а ТЗ — о том, как создать и запустить. Но на практике границы размыты. Важно не название, а суть итогового документа, чтобы на его основании любая команда разработчиков смогла понять, как именно нужно реализовать желаемый продукт.
Когда аналитики слишком много или наоборот не хватает
При принятии решений могут возникать две крайности.
В первом случае — желание учесть при анализе все нюансы и найти совершенный вариант. Это приводит к так называемому аналитическому параличу (analysis paralysis), когда решение не принимается. Часто это проявляется при водопадной модели с длительными этапами планирования, сбора требований и проектирования при чрезмерно бюрократизированной корпоративной культуре.
Во втором случае — решения принимаются на лету, инстинктивно, без какого-либо систематического изучения. Вследствие чего часто оказываются поспешными и неверными, что причиняет вред организации. Это явление называют смерть от инстинкта (extinct by instinct).
Разберем это на конкретном примере. Представим, что мы хотим добавить в продукт планировщик встреч. Задача кажется простой, пока вы не изучите ее внимательно.
В первом случае подробный анализ функций ведет к бесконечно увеличивающемуся количеству функций. В случае с планировщиком может потребоваться масса элементов: выбор места, времени, участников, рассылка приглашений, интеграция календаря, вспомогательная документация и т. д. Может ли организатор менять время встречи, что если кто-то откажется присутствовать, за сколько времени уведомлять о начале? Если увлечься анализом, то с виду простая функциональность превращается в большую головную боль.
Если принимать все эти решения полагаясь исключительно на энтузиазм и интуицию, то может случится так, что функциональность даст мало ценности для бизнеса, но ее поддержание будет отнимать ресурсы от более приоритетных задач. Стабильность бизнеса будет страдать.
Здесь нужен баланс. Аналитика должна быть достаточной, чтобы иметь под рукой всю информацию, чтобы избежать крупных неприятностей.
Далеко не всегда требуется детальное описание абсолютно всех аспектов работы продукта до начала работы над ним. Анализа должно быть достаточно, чтобы обеспечить короткий период реализации — возможно, пилотный запуск, чтобы получить раннюю обратную связь о работоспособности решения. Затем нужен постоянный цикл диагностики и корректировки подходов.
Какой-то функционал можно отложить на последующие релизы, указав его в списке требований, чтобы разработчики могли сразу учесть это при проектировании системы. По задачам, которые поступают в разработку, необходимо однозначное детальное понимание результата и заказчиком и разработчиками.
Что делает клиент, а что исполнитель
Как мы уже сказали, для формализации требований требуются активное участие заказчика. Сегодня на стороне клиента может быть целый IT-отдел с собственными аналитиками и настроенным процессом постановки и декомпозиции задач. Чем больше компетенций развито внутри, тем эффективнее можно подключать для работы внешних специалистов.
Вы можете отдать на аутсорс всю разработку под ключ, включая этап аналитики, а можете обеспечить у себя процесс формализации задач и их декомпозиции и эффективно привлекать отдельных специалистов на аутстаффинг.
Например, задачи ставит менеджер, далее по ним составляется список функциональных требований, архитектор или старший разработчик декомпозирует эти требования на отдельные задачи, которые можно беспрепятственно передавать внешней команде.
Обращаясь за IT-услугами, несложно попасть в ловушку контрактной работы с долгими согласованиями объемов, сроков, бюджетов, планов и графиков.
Бюрократия обещает гарантии и защиту и позволяет переложить проектные риски на сторону исполнителя, но часто от такого подхода никто не выигрывает — запуск разработки и вывод продукта на рынок задерживается, бизнес упускает прибыль и медленнее возвращает инвестиции.
При этом выявление требований — неотъемлемая часть понимания задачи. Без этого невозможно подобрать работоспособное решение. Разные типы требований и способы их фиксации нужны, чтобы достичь единого видения продукта заказчиком и поставщиком и выстроить эффективную стратегию аутсорсинга разработки.
Спасибо, что дочитали до конца! Это блог IT-продакшна Work Solutions. Мы занимаемся аутсорсингом и аутстаффингом: создаем веб-приложения на заказ и усиливаем штат наемных специалистов. Будем очень рады вашим:
⭐ на GitHub;
➕ на Хабре;
в Facebook.
Источник: vc.ru
Требования к ПО на пальцах
Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.
Если коротко, то основные этапы разработки требований — это:
- Зачем нам что-то делать? (нужно больше золота)
- Что мы будем делать? (все как у людей, но дешевле)
- Как мы это сделаем? (с блокчейном и датасаентистами, естественно)
- Когда мы это сделаем? (вчера, а отрефакторим «потом»)
Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.
Как известно, неверная задача может обойтись довольно дорого. Например, если полгода команда из 5 программистов разрабатывала систему, которая никому не была нужна.
В наш беспокойный век Agile разработкой требований часто пренебрегают. Но гибкие методологии не всегда спасают от больших потерь. Поэтому, даже если у вас нет аналитика на проекте, даже если вы вообще не IT — не забывайте про здравый смысл и берите из лучших практик то, что нужно в данный момент.
Так что же такое требования и почему важно уметь их разрабатывать?
Итак, обратимся к истокам:
То есть о требованиях можно говорить, как о будущих свойствах. Как о том, каким будет продукт, удовлетворяющий целям разработки.
С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.
1. Зачем?
Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.
Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.
Заказчик попросит срочно показывать ему все заказы, которые были сделаны в системе. Допустим, мы напряглись и впихнули посреди спринта задачу на отображение всех заказов для администратора. После этого заказчик просит выводить в отдельном окне список всех компаний, чьи заказы он видит. Сделали и это. Потом заказчик просит выводить дополнительно вообще все компании-партнеры.
Окей… Через какое-то время мы встречаемся с заказчиком и видим, как он выгружает оба списка в эксель, ВПРит разницу и начинает обзванивать компании, у которых нет заказов, чтобы напомнить им, что нужно делать заказы через нашу систему.
Если бы мы с самого начала спросили у заказчика, какую цель он хочет достичь, просматривая все заказы — мы бы сэкономили кучу времени и сил, сразу сделав отчет с компаниями, которые не делали пока заказы.
Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.
Определившись с целью необходимо четко ее обозначить и установить критерии, по которым вы сможете точно сказать, что цель достигнута.
Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.
Это облегчает понимание задач и в то же время развязывает руки в выборе средств достижения цели.
И да, не забывайте согласовывать эту красоту с заказчиками. Вообще не забывайте согласовывать требования со всеми заинтересованными сторонами.
2. Что?
Цель достигается разными путями. И второй важный шаг при разработке требований как раз про выбор пути — что конкретно мы будем делать, чтобы прийти к цели.
Чтобы сократить процесс согласования счетов, мы можем:
А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.
Б. Перейти на электронный документооборот — достоверность счетов и данных в них будет подтверждена оператором ЭДО, подтверждение человеком не потребуется.
В. Автоматически распознавать сканы счетов и сравнивать данные с цифрами из системы закупок. Ручная проверка и согласование не потребуются.
Чтобы продумать все варианты, надо разобраться — а что же происходит сейчас? Как устроен процесс без вашей системы, как работают пользователи и заказчики? Даже если процесса еще нет, подробная информация про текущее состояние очень важна. Так мы поймем, какое решение устранит проблему, а не создаст еще одну.
У каждого варианта реализации свои плюсы и минусы, свои необходимые ресурсы и свой уровень результата. Смоделировав все опции, проработав или хотя бы просто проговорив с заинтересованными сторонами эту информацию — вы сможете сделать взвешенный и обоснованный выбор.
3. Как?
Итак, мы поняли нашу цель и что мы будем делать, чтобы ее достичь. Осталось разобраться с тем — как мы это реализуем: какие страницы будем показывать пользователям, в каком виде отобразим отчет для заказчика, как получим данные из другой системы, как будем хранить их у себя и так далее.
Этот этап — дело техники. И если вы успешно прошли предыдущие два — будет гораздо проще.
Хоть техника и зависит от контекста, полезно двигаться по “чек-листу” Вигерса и других умных людей. Если для вас какой-то тип требований сейчас не актуален — окей, не описываем. Но важно не забыть и проверять себя.
- Анкета должна содержать файл с фото, так как фото необходимо при оформлении документов — это бизнес-требование. А возможно, и бизнес-правило.
- Из бизнес-требования следует, что у пользователя должна быть возможность прикрепить фото к анкете — это пользовательское требование. То есть требование, описывающее действия пользователя.
- Получается, что система должна иметь функционал прикрепления фото к анкете — это уже функциональное требование, описывающее поведение системы. Или как должна работать система, чтобы выполнять исходное пользовательское требование.
- Будем хранить все фото в формате base64 в отдельной таблице в БД. Это — нефункциональные требования.
- Фото в очень хорошем качестве нам не нужно, а также мы не хотим покупать много памяти для сервера. Поэтому сделаем ограничение на размер загружаемого фото: не более 10Мб.
На каждое бизнес-требование, как правило, приходится несколько пользовательских. Пользовательское требование декомпозируется на какое-то число функциональных. К каждому функциональному требованию нужно продумать нефункциональные требования и ограничения.
Также нефункциональные требования и ограничения могут напрямую вытекать как из пользовательских требований, так и из бизнес-требований и правил.
Таким образом получаются деревья из требований, в вершине каждого из которых — бизнес-требование.
4. Когда?
В “лесу” ваших требований скорее всего найдется сколько-нибудь взаимоисключающих и сколько-нибудь повторяющихся. Поэтому полезно всю эту красоту документировать и представлять в виде таблиц и диаграмм.
Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.
Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.
Однако, как правило, «пятенный» уровень детализации не позволяет увидеть подводные камни и продумать все возможные сценарии. Ведь вроде и так все понятно, а нарисовал схемку — и вот тебе и бесконечный вызов, и забытая ветка процесса, и кратчайший путь к золоту.
Поэтому полезно знать, какие есть инструменты для обращения хаоса в порядок.
В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).
А дальше можно уже раскидывать по спринтам/этапам разработки и внедрения. Ну и повторять эти упраженения в рамках каждой итерации. И будет вам счастье — никаких переделок, довольный заказчик, счастливая команда, работающий и приносящий пользу продукт, эльфы играют на арфе на фоне радуги.
Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше.
Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.
Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.
Спасибо за внимание и удачного проектирования.
- разработка требований
- аналитика
- системный анализ
- техническое задание
- постановка задач
- процесс разработки
Источник: habr.com
Разработка требований к ПО: общие понятия
Очень часто при внедрениях от клиента можно услышать фразы типа: «А как этого нет. Это же есть в ….. Я думал, что это само собой понятно. Я без этого не смогу нормально работать. Ваша система …..» Ну и дальше в таком роде. Справедливо ли это? Наверное нет.
Каждая система (в данном случае я говорю про ERP ) содержит определенный функционал и может в себе не содержать некоторые «фичи» которые есть в других.
И когда начинается разработка или внедрение клиент должен озвучить все свои «хотелки» иначе существует риск, что что-то не будет реализовано и тогда пиши пропало.
Часть вины за это конечно лежит и на компании которая занимается разработкой или внедрением. Бизнес -аналитик (это человек который занимается сбором и обработкой требований) должен уметь задавать правильные вопросы и читать между строк. Клиент может и не сможет четко описать что он хочет и может ходить вокруг и около того, что ему действительно необходимо.
Стадия сбора требований как правило предшествует стадии разработки и внедрения. И именно на ней формируется scope проекта.
Содержание проекта (Project Scope) Работы, которые необходимо выполнить, чтобы получить продукт, услуги или результат с указанными характеристиками и функциями.
Содержание скрыть
Что же такое требование? Уровни и типы требований
Здесь и далее я буду опираться на определения из книги Карла Вигерса и Джоя Битти «Разработка требований к программному обеспечению»
Существует много определений данного понятия мы же остановимся на таком:
Требование — спецификация того, что должно быть реализовано. В них описано поведение системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы.
И давайте дадим определения терминов которые используються при классификации требований.
Словарик бизнес-аналитика
Бизнес-требование — высокоуровневая бизнес-цель организации или заказчиков системы. Оно должно отвечать на вопрос «Что?» и «Зачем?».
Бизнес-правило — политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. Это не требование к ПО, но оно служит источником нескольких типов требований к ПО.
Ограничение — ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта.
Внешнее требование к интерфейсу — описание взаимодействия между ПО и пользователем, другой программной системой или устройством.
Характеристика — одна или несколько логически связанных возможностей системы, которая представляет собой ценность для пользователя и описаны рядом функциональных требований.
Функциональное требование — описание требуемого поведения системы в определенных условиях.
Нефункциональное требование — описание свойства или особенности, которыми должна обладать система, или ограничение, которое должно соблюдаться.
Атрибут качества — вид нефункционального требования, описывающего характеристику сервиса или производительности продукта.
Системное требование — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
Пользовательское требование — з адача, которую определенные классы пользователей должны иметь возможность выполнять в системе, или требуемый атрибут продукта.
Требования к ПО состоят из трех уровней:
- Бизнес-требования;
- Пользовательские требования;
- Функциональные требования.
Читать: Чего хочет бизнес от IT?
Вдобавок к этому выделяют еще нефункциональные требования.
Давайте рассмотрим каждый уровень чуть более детальней.
Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые она планирует достичь с ее помощью. Как правило их высказывают те, кто финансирует проект. Пример бизнес-требования: «Есть необходимость вести учет взаиморасчетов с контрагентами в разрезе договоров».
Пользовательские требования (user requirements) описывают цели и задачи, которые пользователь должен иметь возможность выполнять с помощью продукта. Они описывают то, что пользователь должен иметь возможность делать с системой. Это по сути user stories и сценарии. Например: «Я как пользователь системы хочу иметь возможность быстро посмотреть остатки конкретного товара на складе и посмотреть историю его перемещений»
Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Такие требования описывают в форме традиционных утверждений со словами должен или должна. Например — «система должна в момент проведения в системе документов по взаиморасчетам с контрагентами (инвойс, банковская выписка) дать возможность указать договор по которому ведутся взаиморасчеты» или «система должна давать возможность пользователю выбрать место хранения при закупке товара, куда он будет оприходован» или «должна быть возможность указать в карточке сотрудника дату его рождения и система за 2 дня до его наступления должна высылать директору по персоналу об этом уведомление».
Как правило бизнес-требования и функциональные требования ложаться в основу технического задания на разработку ПО.
Системные требования (system requirements) описывают требования к продукту, которые содержит многие компоненты или подсистемы (например рабочее место кассира, которое оборудовано сканером считывания штрих-кодов, весами, принтером и т.д.).
Бизнес-правила (business rules) — включают корпоративные политики, правительственные постановления, отраслевые стандарты и вычислительные алгоритмы. Они находятся за пределами любой системы ПО. Однако часто они накладывают ограничения на функции системы.
Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым»
Нефункциональные требования это чёткие критерии того, как система должна работать, в отличие от функциональных, которые описывают, что система должна делать. Давайте посмотрим на пример.
«API метод должен возвращать список ресторанов в короткой форме: id, название, адрес»
Это функциональное требование, оно описывает поведение системы.
«API метод должен отдавать данные не более чем за 200ms на 95 перцентиле и не более чем за 500ms на 99 перцентиле.»
А это уже нефункциональное требование, которое описывает определённый атрибут качества – performance.
Разработка и управление требованиями
Область разработки технических условий разделяется на разработку требований и управление требованиями. И начинается все с выявления требований.
Выявление и сбор требований (elecitation)
Этот этап включает в себя все действия, связанные с выявлением требований, таких как интервью, совещания, анализ документов, создание прототипов и другие. К ключевым действиям относятся:
- Определение классов ожидаемых пользователей продукта и других заинтересованных лиц;
- Понимание задач и целей, а также бизнес-целей, которым соответствуют эти задачи;
- Изучение среды, в которой будет использоваться новый продукт;
- Работа с отдельными людьми для пониманиях их потребностей и ожидания в отношении качества.
Читать: Шпаргалка бизнес-аналитика. Бизнес-требования
Анализ требований
Этот этап подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основными действиями на этом этапе будут:
- анализ информации и отделение функциональных требований от нефункциональных, бизнес-правил, предпологаемых решений и другой информации;
- разложение высокоуровневых требований до нужного уровня детализации;
- выведение функциональных требований из информации других требований;
- распределение требований по компонентам ПО;
- согласование приоритетов реализации;
- понимание относительной важности атрибутов качества;
- выявление пробелов в требованиях или излишних требований, не соответствующих заданным рамкам.
Документирование
Представление и хранение знаний о требованиях определенным способом. Например в письменные требования, диаграмы пригодные для дальнейшего использования.
Утверждение требований
На этом этапе подтвержается правильность имеющегося набора требований, которые позволят реализовать решение, удовлетворяющее бизнес-целям.
Нельзя создать идеальные требования. Если смотреть с практической точки зрения, то цель разработки требований — накопить общее понимание требований необходимое для разработки очередной порции продукта.
Управление требованиями
Это процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.
Цель управления требованиями состоит в том, чтобы гарантировать, что организация документирует, проверяет и удовлетворяет потребности и ожидания её клиентов и внутренних или внешних заинтересованных лиц. Управление требованиями начинается с выявления и анализа целей и ограничений клиента. Управление требованиями, далее, включает поддержку требований, интеграцию требований и организацию работы с требованиями и сопутствующей информацией, поставляющейся вместе с требованиями.
Установленная таким образом отслеживаемость требований используется для того, чтобы уведомлять заинтересованных участников об их выполнении, с точки зрения их соответствия, законченности, охвата и последовательности. Отслеживаемость также поддерживает управление изменениями как часть управления требованиями, так как она способствует пониманию того, как изменения воздействуют на требования или связанные с ними элементы, и облегчает внесение этих изменений.
Управление требованиями включает общение между проектной командой и заинтересованными лицами с целью корректировки требований на протяжении всего проекта. Постоянное общение всех участников проекта важно для того, чтобы ни один класс требований не доминировал над другими. Например, при разработке программного обеспечения для внутреннего использования у бизнеса могут быть столь сильные потребности, что он может проигнорировать требования пользователей, или полагать, что созданные сценарии использования покроют также и пользовательские требования.
Основные проблемы при работе с требованиями
Выявление требований непростой процесс. Проблему усугубляет то, что заказчик может говорить о чем угодно, но только не о том, что ему действительно нужно. Основное следствие проблем с требованиями — переделка того, что вы думаете что уже готово (на это расходуется от 30 до 50% общего бюджета разработки). С ростом объема переделок растет и растрата ресурсов и разочарования.
Создание более качественных требований это инвестиции, а не затраты.
Недостаточное вовлечение пользователей
Заказчики зачастую не понимают всю важность этапа сбора требований и обеспечения их качества. Это влечет за собой обнаружение ошибок в требованиях на поздних стадиях проекта ну и соответственно к задержке завершения проекта.
Еще существует риск того, что бизнес-аналитик может не понять и неправильно задокументировать бизнес-требования или потребности клиента. Иногда бизнес-аналитик может идти по пути определения «идеальных» бизнес-требований, которые реализуют разработчики. Но потом этим решением не пользуются.
Небрежное планирование
Неопределенные, плохо понятые требования порождают слишком оптимистические оценки, которые возвращаются и не дают нам покоя, когда возникает перерасход.
«Разрастание» требований пользователей
В процессе разработки требований scope проекта может разрастаться невиданными темпами и соответственно это увеличивает бюджет проекта и его сроки завершения. Менеджер проекта должен предусмотреть «буферы планирования». Если на проекте применяются гибкие методологии его ведения, то новые требования помещаются в резерв (беклог). Такие изменения могут быть важны, но они всегда имеют свою цену.
Двусмысленные требования
Признаком этого может быть то, что одно и тоже требование может пониматься по разному. Следствием этого является наличие разных ожиданий и удивление полученному результату.
Требования -«бантики»
Разработчики в процессе разработки могут добавлять функции, которые отсутствуют в спецификации и это может привести к проблемам. Задача команды реализующих требования — четко соблюдать требования спецификации, а не своевольничать.
Противоречивые требования
Бывает, что какие-то конкретные два или более требования противоречат друг другу. Иногда “совсем”, что никак нельзя совместить. Иногда всё-таки можно предусмотреть “разные режимы”, в каждом из которых одно требование удовлетворяется, а другое при этом оказывается недоступно. Или решить какую-то из задач другим способом — тогда противоречие исчезнет.
Чтобы продвинуться в сторону решения, нужно начать разматывать цепочку “для чего / почему”. По каждому из требований (как было описано в первой части статьи). То есть мы должны понять как можно глубже, из чего возникли именно такие требования, и что люди, пришедшие с этими требованиями, хотят “на самом деле”.
Выводы
Работа с требованиями может иногда казаться излишней и такой которая не повышает рентабельность проекта. Многие живут в реальности, что самое главное — это разработка и разработчики это самые нужные люди в компании (наверное поэтому у них такие большие зарплаты), но кому нужна разработка если она никому не нужна. Если неправильно сформирован scope проекта и возникают постоянные переработки, то кому от этого будет хорошо даже если за весь этот банкет платит заказчик. Та что тут говорить, если во многих компаниях даже нет такой позиции как бизнес-аналитик, его роль совмещает в себе проджект менеджер или разработчик.
Инвестиция в качественный сбор и оформление требований может принести следующие выгоды:
- меньше деффектов в требованиях и в готовом продукте;
- меньше ненужных функций;
- меньше расползания границ проекта;
- меньше беспорядка;
- продукты которые делаю то, что нужно.
Источник: www.antonpiskun.pro
