В этой статье я хотела бы кратко рассказать о практиках и приемах, которыми я пользуюсь для поиска неявных требований в процессе их извлечения и анализа.
В первую очередь, определимся с терминологией. Требования, начинающиеся с фраз «система должна …», «пользователь должен иметь возможность …» и т.п. – это все примеры явных требований, потому что тут заинтересованная сторона (stakeholder) явно сформулировала, что именно требуется от системы. Под неявными требованиями договоримся понимать те, которые не озвучены или не сформулированы в явном виде, но требующие анализа и, возможно, реализации.
Почему их надо искать? Потому что, так или иначе неявные требования станут явными – или в процессе согласования требований с заказчиком, или в процессе разработки или в процессе приемочного тестирования. Однако чем позже они будут найдены, тем дороже может быть для проекта их реализация и тем хуже, значит, аналитик выполнил свою работу.
Свои советы я бы свела к следующему списку:
- Управляйте заинтересованными сторонами.
- Планируйте процесс сбора требований.
- Проводите продуктивные беседы.
- Составьте контрольный список.
Давайте рассмотрим каждый из пунктов подробнее.
Управляйте заинтересованными сторонами.
Очень важно быть уверенными, что требования собраны действительно у всех заинтересованных сторон. Для поиска заинтересованных сторон могут использоваться разные инструменты, к примеру, колесо заинтересованных сторон.
Примером заинтересованной стороны, чьи требования должны учитываться в обязательном порядке, но кого иногда выпускают из виду, может быть государство в виде законодательных актов и регулирующих процедур. Особенно это важно при разработке систем, имеющих дело с деньгами (бухгалтерский учет, страхование) или со здоровьем и жизнью людей (здравоохранение, фармацевтика).
Также важно проанализировать ваши заинтересованные стороны (зачем им этот проект, какие цели они хотят достичь с помощью него). Затем приоритизировать их, определить насколько им интересен этот проект, а также насколько вам нужно вовлечение заинтересованных сторон в него и в какой роли – чтобы систематизировать эту информацию можно составить RACI chart.
Планируйте процесс сбора требований.
Нужно хорошо подумать и составить план действий по сбору требований с помощью найденных заинтересованных сторон. Учитывайте занятость и доступность определенной заинтересованной стороны, а также психологические и культурные особенности.
Классическим примером могут служить восточные культуры, где сильна власть и авторитет начальника. Поэтому на встрече для сбора требований подчиненный может не решиться сказать нечто важное только потому, что это может не одобрить его руководство.
Из всего арсенала доступных техник для сбора требований (мозговой штурм, интервью, фокус-группы, анкетирование, семинары, прототипирование и т.п.) выберите те, которые наиболее подходят для данного проекта, ведь неверно подобранный инструментарий значительно усложняет процедуру сбора требований и повышает вероятность что-либо не учесть.
Проводите продуктивные беседы.
Если часть требований собирается при личных встречах к ним нужно быть максимально готовыми, чтобы они прошли максимально продуктивно: создайте план коммуникации, пригласите нужных людей на встречу, заранее разошлите повестку, назначьте модератора, после встречи ознакомьте ее участников с результатами. В противном случае вам будет сложнее убедить в необходимости тратить время на встречи в следующий раз, и у вас будет меньше возможностей получить необходимую информацию.
При беседе учитывайте невербальный язык (положение тела и рук, взгляд, интонацию и т.п.) ваших собеседников, чтобы при необходимости вы могли отреагировать и скорректировать ход беседы, всегда оставаясь открытым и конструктивным для собеседника.
Задавайте больше открытых вопросов – таким образом можно получить много полезной информации. Примером таких вопросов могут быть: «Может ли произойти такая ситуация <описание ситуации>? Что вы обычно делаете в таких случаях? Кто этим занимается?», Они являются способами исследования менее вероятные сценарии и опции, которые система должна предоставить пользователю.
Следите за новыми терминами. К примеру, упоминание новой для проекта сущности (например, «отчет») в ответе на ваш открытый вопрос должно послужить для вас отправной точкой для новых вопросов и, возможно, к набору дополнительных требований в итоге. В нашем примере, возможно, к системе надо будет добавить модуль работы с отчетами.
В случае если работа с отчетами будет за пределами границ системы (out of scope), это все равно надо выяснить и зафиксировать. Для больших и сложных систем для этих целей бывает полезно составить контекстную диаграмму.
Составьте контрольный список.
Составьте личный (который будет помогать конкретно вам) контрольный список, для поиска неявных требований при анализе на ваших следующих проектах.
Примером может послужить такой перечень:
- пользователи, права, роли – почти каждой системой будет пользоваться не один пользователь и даже не одна группа пользователей, а значит, в какой-то мере управление учетными записями и правами доступа будет нужно подавляющему множеству систем. Однако иногда и аналитик, и заинтересованные стороны сосредотачиваются на обсуждении основных функциональных возможностей системы, считая функциональность управления пользователями и правами «по умолчанию», при этом, забывая включить ее в границы системы.
- CRUD (create, read, update, delete) – надо помнить, что каждый объект (сущность) должен каким-то образом поступать в систему (например, создаваться через GUI или импортироваться в базу данных из связанной системы).
- Почти для каждого объекта должна быть возможность редактировать/ изменять его посредством системы, удалять посредством GUI или системой автоматически по некому триггеру. Исключение составляют системы, где регулирующими нормами пользователям запрещено удалять информацию и данные – они достаточно долго хранятся и отображаются в системе для целей аудита.
- При этом все данные (сущности и атрибуты сущностей) должны как-то использоваться системой (например, в отчетах или отображаться на GUI или участвовать в расчетах третьей величины). Если у вас есть неиспользуемые данные, то это верный признак того, что надо пересмотреть эту функциональность еще раз.
- Нефункциональные требования – странно, но некоторые из нефункциональных требований часто оказываются в границах проекта позже, чем следовало. И не всегда потому, что аналитик забыл про их сбор. А потому, что аналитик не смог донести до ответственных лиц то, что нефункциональные требования важны, так же требуют детального анализа и обсуждения, как и функциональные, а их несвоевременный учет может привести к материальным потерям.
Автор
Тарасюк Надежда, участник сообщества analyst.by,
аналитик с 6+ опытом в сфере.
Нумерованные списки как-то вправо съехали..
У меня все хорошо)
Вот всякие спискис контрольными вопросами я вообще люблю :) Спасибо за материал.
Спасибо за отзыв )
Статья понравилась. Хотелось бы обсудить различные инструменты для работы с неявными требованиями.
В QFD принято различать неявные требования 2-х видов:
1) подразумеваемые, которые явно не формулируются, но считаются само собой разумеющимися.
2) неосознанные, которые явно не формулируются, потому что никто еще не осознал их
Очевидно, что для управления требованиями разных видов нужны разные инструменты. Да и жизненный цикл у разных видов требований будет отличаться. Было бы интересно почитать статью на эту тему.
Андрей, спасибо за комментарий!
Мне кажется, что все различия разных типов неявных требований будут актуальны только на стадии их извлечения и частично на стадии анализа. Дальше эти требования становятся явными и работа с ними идет как и с остальными требованиями.
С подразумеваемыми требованиями происходит именно так.
Не думаю, что с неосознанными требованиями будет все точно также. На то они и не осознанные, что никто пока не представляет, что и как получится.
Тут пригодится какая-нибудь модель. Представим, что есть требование количественно улучшить какое-то свойство (или параметр) системы. Например, хочу такой же авто, только чтобы ездил еще быстрее на 20%. Это вполне осознанное и ожидаемое требование.
1) Если пользователь понимает, что чтобы увеличить скорость, нужно увеличить мощность двигателя, а это, в свою очередь, увеличит вес авто и снизит скорость, то он также будет осознавать, что можно требовать +10% увеличения скорости, но нельзя требовать +20% и более. Другими словами, он не будет осознавать, что можно хотеть +20% и даже +200%. Я бы назвал такой вид требований условно неосознанными.
2) Очевидно, что есть неосознанные требования типа «Вау! Я даже в своих самых буйных фантазиях такого не мог себе представить!». Что-то вроде безусловно неосознанные требования. Для нашего примера что-то типа «скорость без ограничений».
Я бы хотела сначала отметить, что в данном случае у нас есть несколько предположений:
QFD — это всего лишь инструмент. Им можно пользоваться, а можно нет (выбрать другой инструмент, к примеру).
Допустим, что тут этот инструмент применим и что в рамках него действительно можно разделить на 2 группы неявные требования
(я к сожалению знакома с нюансами QFD не так хорошо как хотелось бы и такой классификации требований не нашла — буду признательна, если дашь ссылку или посоветуешь, где можно почитать).
Теперь вернемся к твоему примеру с автомобилями. Я боюсь мы погрязнем в выяснении терминологии, но попробуем:
1) Если пользователь понимает, что чтобы увеличить скорость, нужно увеличить мощность двигателя, а это, в свою очередь, увеличит вес авто и снизит скорость…»
Во-первых не очень понятно при чем тут пользователь (ты ведь имел в виду конечного пользователя?). Это не его работа думать за счет чего можно произвести увеличение скорости. Эта работа происходит по время стадии анализа требований (модели, спецификации и т.д.)
Во-вторых метания на сколько же надо нам увеличить скорость вполне покрываются первым пунктом в моей статье — грамотным управлением заинтересованными сторонами. В твоем примере это могут быть маркетинговые исследования и законодательные акты (у нас ведь есть ПДД ;) ).
2) «...Для нашего примера что-то типа «скорость без ограничений».» — в принципе все рассуждения выше вполне подходят и под этот пример тоже, т.к. скорость без ограничений невозможна (не только по физическим законам, но и внешними законодательными ограничениями системы). Ну и не вполне понятно кому нужен такой автомобиль — на какое из бизнес требований трассируется это функциональное требование?
Так что ты меня пока не убедил, что нужны разные инструменты по сбору неявных требованиях для двух типов этих самых требований)
Я всё равно не понял пример с неосознанными требованиями. В твоем примере ты пошел раскручивать реализацию требования +20%, наложил связанные требования, ограничения и тыпы.
Мне понравилось =)
Не знаю, а по-моему здесь написаны вполне известные каждому аналитику вещи (
Единственное, что понравилось, это интересные примеры из опыта!
Странная причина недовольства статьей — отсутствие в ней знаний, которые уже были приобретены ранее из других источников. Радуйтесь : )
Или вы думаете, что читая даже гуру (аля Вигерс, Коберн, Леффингуэлл) они вам каждый раз будут америку в практиках работы с требованиями открывать в каждой своей новой книге или статье?
Надя, а можно попросить примеры из жизни? :)
Типа «вот на проекте Х было неявное требование такое-то».
Могу подсобить с примерами даже :)
Денис,
Мне кажется в статье много примеров (я специально уделяла этому внимание) — и все они из жизни).
Беседы аля «вот на проекте Х было неявное требование такое-то» боюсь будут очень непродуктивными, т.к. уйдет много времени, чтобы ввести в специфику конкретного проекта. Ну и на каждом мало-мальски крупном проекте таких требований очень много, чтобы можно было в рамках комментария к статье составить исчерпывающий список.
«Могу подсобить с примерами даже :)» — если у тебя есть что-то конкретное и интересное для разбора — делись! с радостью обсужу :)
Хорошая статья — но комментарии лучше :)
1. Тема ассамшенов не очень раскрыта в статье.
2. Согласен с Андреем по поводу того, что тянущиеся(из требования А следуют, требования Б и В) требования, это то на что всегда следует обращать внимание при поиске неявных требований.
Craftsman спасибо за отзыв)
«1. Тема ассамшенов не очень раскрыта в статье.» — поясните свою точку зрения пожалуйста. О каких именно предположениях вы тут упоминаете и какое отношения они имеют к неявным требованиям.
просто пример приведу, допустим заказчик подразумевает что форматирование цены в приложении будет locale dependent, т.к. ему кажется это очевидным. но при этом я вном виде это требование не прозвучало.
Михаил Сорокин
Это в первом абзаце написано: заказчик подразумевает = не озвучил вслух = договорились называть требование неявным.
И далее советы из статьи применяем — для вашего примера это скорее всего обнаружится при грамотных сессиях requirements elicitation или в процессе анализа результатов.
Как вариант это может обнаружиться при анализе работы системы конкурента - это работа с заинтересованными сторонами.
Также у меня вопросы вида способ округления денежных сумм, зависимость формата даты и других данных от локали, обработка данных для пользователей из разных временных зон также входят в личный чеклист (контрольный список).
Спасибо за статью, но позвольте придраться к следующей цитате:
Примером заинтересованной стороны, чьи требования должны учитываться в обязательном порядке, но кого иногда выпускают из виду, может быть государство в виде законодательных актов и регулирующих процедур.
Государство не обязательно является заинтересованной стороной. К примеру возьмём ситуацию, когда ИТ-компания делает софт для банка. Госрегулятор и законодательство — это источники требований к системе, но само гос-во не стейкхолдер, так как не участвует в проекте, затронуто в процессе реализации и не получает результат.
Таким образом, Вы несколько смешали понятия источника требований и заинтересованной стороны.
Проблема, скорее, в терминологии и трудностях перевода.
http://en.wikipedia.org/wiki/Stakeholder - сторона может быть и не заинтересована, но может оказать влияние на проект.
Андрей, спасибо за комментарий, придраться позволяю :)
Я думаю,что определять понятие stakeholder лучше шире, чем просто «лицо, группа лиц, заинтересованная в проекте». Помимо интереса в проекте, это может быть общая бизнес цель или вообще люди, чья деятельность изменится, когда проект будет завершен.
И кстати сам интерес в проекте, может быть как положительным, так и отрицательным (люди или группы лиц могут саботировать или более явно мешать развитию проекта).
В моей практике был случай, когда top-менеджмент был активным сторонником разработки ПО системы, а middle-менеджмент был против по нескольким причинам, в частности т.к. проект мог повлечь за собой сокращение штата этих самых middle-менеджеров и их подчиненных.
Кстати, BABOK тоже использует довольно широкое понятие для stakeholders. Можно посмотреть их stakeholder onion диаграмму (http://clip2net.com/s/5Ghp5X).
И высокая заинтересованность в проекте, так же не является величиной по умолчанию. Например, широко используется матрица «сила влияния / заинтересованность в проекте» для анализа этих самых stakeholders.