В данном уроке мы будем разбираться, зачем нужно работать с требованиями :

1. Статистика крупных проектов и основные причины провалов
   
2. Проблема нечеткости целей
   
3. Проблемы коммуникации. Область проблем и область решений
   
4. Требования и цикл работы с требованиями
   
5. Проектирование требований. Типичные проблемы
   

Тезисы

• Небольшие проекты более успешны.
  
• Две группы причин приводящие к провалу проектов
  
  • Нечеткие требования
    
  • Плохая коммуникация
    
    

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

Согласно исследованиям Standish Group, успешными является только небольшая часть проектов. Как бы мы ни старались, какие бы новые технологии не появлялись, количество проектов, которые завершаются успешно (успешно – мы имеем ввиду с результатом, который предоставлен заказчику вовремя и в рамках бюджета), относительно невелико.

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

Какие причины лежат в основе провалов проектов?

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

Вторая группа проблем – плохая коммуникация (политика, конфликты среди заинтересованных лиц).

Из наиболее важных факторов, с которые участники проектов связывают провалы или проблемы в проектах, половина так или иначе связана с управлением и проектированием требований.

Тезисы

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

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

Где чаще всего возникают проблемы с коммуникацией?

1. Между заказчиками/пользователями программы. Когда у нас есть несколько заказчиков, и каждый из них имеет свое, отличное от других участников, представление о том, что должна делать программа, какой бы совершенной ни была команда создания решения, продукт будет удовлетворять только одну из сторон.
   
   
2. Взаимопонимание между заказчиками и разработчиками. Чаще всего общие договоренности на уровне «Сделайте так, как нужно», приводят к выявлению разногласий только при представлении результатов разработки.
   
   
3. Коммуникация внутри команды разработки. Неоднозначность в понимании того что и как должно быть сделано для достижения результата. Зачастую разработчики по-разному себе представляют, как именно должна работать программа. И тот, и другой вариант имеют право на жизнь, каждый из вариантов мог бы решить задачу стоящую перед заказчиком. Однако в результате недостаточной коммуникации того, что должна делать система, реализованными оказываются части разных вариантов и реализация не стыкуется: функция, реализованная одним разработчиком, и функция, реализованная другим разработчиком - работают, но не позволяют достичь конечного результата.
   

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

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

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

Давайте приведем пример, важности разграничения этих областей.

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

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

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

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

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

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

• В предметной области находятся ответы на вопрос: «Зачем нам необходимо это разрабатывать?» (Зачем ?)
  
• В области решения - «Каким образом это может быть сделано?» (Как?),
  

И требования отвечают на вопрос: «Что должно быть сделано программой ?» (Что?).

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

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

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

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

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

В рамках создания программного обеспечения выделяют следующие группы требований:

1. Первичные требования и ожидания, которые существуют у заказчика или у потенциальных пользователей продукта и представляют собой потребности (needs) или пожелания в отношение того, что должна делать система или программа. Работа над первичными требованиями приводит к тому, что мы формулируем цели и формулируем проблему, которую мы действительно собираемся решить.
   
   
2. Возможности (Features)– это те характеристики решения, которое оно предоставляет потребителям и заказчикам для того, чтобы достичь необходимого им результата. Возможности поддерживают цель. И цели, и возможности, и потребности, находятся в предметной области.
   
   
3. Возможностям соответствуют Функциональные требования (Functional requirements). Что именно должна делать система для того, чтобы реализовать и обеспечить возможности, которые необходимы заказчику.
   
   
4. Для возможностей и функций дополнительно выделяются требования к качеству (Quality requirements). Недостаточно того, что система можем что-то открыть, что-то рассчитать или что-то вычислить. Принципиально важным также является то, каким образом она это делает. Насколько удобен интерфейс? Насколько высока точность? Насколько быстро это делается?
   
   
5. Ограничения(Constraints) В отличие от требований к программному обеспечению, ограничения – это факторы, которые находятся вне зоны влияния заказчика или команды, занимающейся разработкой программного обеспечения. И, соответственно, если мы можем вести переговоры и договариваться с заказчиком в отношении требований основной группы, ограничения относятся к той категории требований, которые мы не можем изменить. В основном, ограничения, которые мы рассматриваем в рамках управления требованиями, проистекают из тех или иных возможностей, связанных с инфраструктурой или возможностями технологий.
   

Проектирование требований сильно зависит от условий (внутренняя, заказная или продуктовая) и домена (предметной области), в котором происходит разработка.

Принципиально важно кто осуществляет эту разработку, и кто является потенциальным клиентом – частные лица или глобальные корпорации?

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

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

Наиболее часто встречающиеся симптомы и проблемы, связанные с недостаточной работой над требований:

1. Переполненная очередь задач на анализ и/или на разработку программного обеспечения. Команда просто не справляется с объемом пожеланий заказчика.
   
   
2. Заказчик полностью диктует, что должно быть реализовано командой, и, соответственно, решение формируется без учета возможностей разработчика. Эта проблема частично связана с переполнением очереди задач.
   
   
3. Обратная ситуация, когда разработчик лучше всех знает, что должно быть сделано, и конфликты возникают в тот момент, когда программное обеспечение передается заказчику или он начинает его использовать. Это также является симптомом того, что заказчик не вовлечен в процесс работы над требованиями.
   
   
4. Одна из самых больших проблем серьезных проектов – это, так называемый ползущий объем работ (scope creep), когда с каждым реализованным куском функциональности, объем работы, который вам необходимо сделать, становится больше.
   
   

Однако, существуют и проблемы, которые связаны с тем, что аналитики или разработчики продукта проводят избыточное время, работая над требованиями:

1. Аналитический паралич. В ситуации, когда очень высокий уровень неопределенности и физически нет возможности охватить весь объем, команду охватывает так называемый аналитический паралич, команда не может выйти из фазы работы с требованиями. Эта проблема связана с тем, что необходимо более конкретно определить цели таким образом, чтобы была возможность осуществить планирование и проектирование работы.
   
   
2. Проблема Gold Plating, или позолота – ситуация, в которой требования не завершаются по той причине, что, либо заказчик, либо аналитик старается достичь максимального качества требований. Среднестатистический объем требований, который не изменится в проекте – это порядка 60 %. То есть больше трети требований изменятся. Когда мы уделяем слишком большое внимание шлифовке и работе с требованиями, мы затягиваем время и расходуем и свои, и чужие ресурсы.

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

1. Определить границы решения. Четко понимать что мы должны и можем изменять, и что мы должны изменить для того, чтобы достичь результата.
   
   
2. Сформировать цель разработки и бизнес-требования.
   
   
   • Для этого нужно проработать первичные требования, потребности заказчика, определить проблему, которая стоит за теми потребностями, которые лежат на поверхности.
   • Cформулировать возможности для преодоления проблем и, соответственно, оценить альтернативы и выявить ограничения.
3. Определить решение. Нам нужно определить, как с нашей системой будут взаимодействовать пользователи или другие системы.
   
   
4. Определить требования к качеству решения.
   
   
5. В процессе работы нам необходимо Управлять требованиями и измененияим (фиксировать принятые решения). Не только в процессе реализации системы, но и в процессе работы над требованиями, иногда возникают изменения, на которые необходимо реагировать.