Статьи

Требования Сбор Основы

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

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

Исследования показали, что 4 из 5 проектов по разработке программного обеспечения идут с течением времени, превышают бюджет или не дают ожидаемых результатов (The Chaos Report, 1994 Standish Group). С такими длинными шансами стоит заранее приложить усилия, чтобы минимизировать риск неудачи. Вопрос в том, как этого добиться?

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

Фокус и ясность

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

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

Недавний проект (онлайн-опрос), над которым я работал, преследовал две ключевые цели:

  1. увеличить скорость отклика
  2. улучшить качество полученных данных

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

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

Идеальная цель – короткая, краткая, ясная и согласованная всеми заинтересованными сторонами.

Формат для указания требований

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

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

Итак, если у вас есть формат, который вам, вашему клиенту и вашей проектной команде удобен, придерживайтесь его.

Автор документа с требованиями

Искусство написания требований требует больших навыков, и, как и написание кода, конечный результат, как правило, чище и более последовательный, если есть один автор. При выборе автора следует проявлять большую осторожность. Это вопрос баланса между необходимостью глубокого понимания предметной области проекта (т. Е. Бизнеса клиента) и понимания процесса разработки программного обеспечения. Автор с глубоким пониманием предметной области, но без опыта разработки программного обеспечения – рискованный выбор. Так же как и автор без понимания предметной области проекта, но с большим опытом в разработке программного обеспечения. В идеале вы хотите стремиться к автору, который имеет оба. Если это невозможно – что часто имеет место – убедитесь, что имеются хорошие процессы проверки, чтобы можно было определить детали.

Язык требований

Если в использовании языка есть только одно правило, то оно должно использовать тот же язык, что и ваш клиент. Это так просто. Если язык последовательный, это значительно снижает риск неверного толкования требований. Например, недавний проект содержит каталог продукции для семян. В первом проекте мы разбили семена на «типы», «категории» и «подкатегории». Хотя это имело смысл для нас, клиент и другие владельцы скейтбордов используют термины «урожай», «тип» и «разнообразие». Это должно было вызвать проблемы, если бы мы не использовали те же термины, что и клиент. Полезный способ избежать этой проблемы – включить глоссарий терминов и определений в документ с требованиями.

Точность имеет решающее значение

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

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

Минимизируйте риск ошибочной интерпретации

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

Вывод

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