Введение
Инженерный процесс
В системной инженерии и разработке программного обеспечения анализ требований сосредоточен на задачах, определяющих потребности или условия для реализации нового или измененного продукта или проекта, с учетом потенциально противоречивых требований различных заинтересованных сторон, а также на анализе, документировании, подтверждении и управлении требованиями к программному обеспечению или системе. Анализ требований является критически важным фактором успеха или неудачи проекта в области систем или программного обеспечения. Требования должны быть задокументированы, выполнимы, измеримы, тестируемы, прослеживаемы, связаны с выявленными бизнес-потребностями или возможностями и определены с уровнем детализации, достаточным для проектирования системы.
Сессии по разработке совместных требований (JRD)
Требования часто имеют межфункциональные последствия, которые неизвестны отдельным заинтересованным сторонам и часто упускаются из виду или определяются неполно во время интервью с ними. Эти межфункциональные последствия можно выявить, проводя сессии JRD в контролируемой среде под руководством опытного фасилитатора (бизнес-аналитика), где заинтересованные стороны участвуют в обсуждениях для сбора требований, анализа их деталей и выявления межфункциональных связей. Для документирования обсуждения должен присутствовать специально выделенный протоколист, что позволит бизнес-аналитику направлять дискуссию в сторону, генерирующую соответствующие требования, отвечающие цели сессии. Сессии JRD аналогичны сессиям совместного проектирования приложений (Joint Application Design). В первом случае сессии направлены на выявление требований, которые служат основой для проектирования, а во втором – на определение конкретных элементов дизайна, необходимых для реализации этих требований.
Списки требований, относящихся к контракту
Одним из традиционных способов документирования требований были списки требований, оформленные как контракт. В сложных системах такие списки могут разрастаться до сотен страниц. Уместной метафорой будет очень длинный перечень покупок. В современном анализе такие списки практически не используются, поскольку они показали себя крайне неэффективными в достижении поставленных целей, однако они до сих пор встречаются.
Сильные стороны
Содержит перечень требований. Необходимо предоставить договор между спонсором(ами) проекта и разработчиками. Для крупной системы может быть предоставлено высокоуровневое описание, на основе которого можно будет сформулировать более детальные требования.
Слабые стороны
Такие списки могут насчитывать сотни страниц. Они не предназначены для удобного для читателя описания желаемого приложения. Такие списки требований представляют собой абстрактное перечисление всех требований, поэтому контекста в них мало. Бизнес-аналитик может добавить контекст к требованиям в сопроводительной проектной документации. Эта абстракция не предназначена для описания того, как требования соотносятся друг с другом или взаимодействуют. Список может не отражать взаимосвязи и зависимости между требованиями. Хотя список упрощает расстановку приоритетов для каждого пункта, удаление одного пункта вне контекста может сделать недействительным весь сценарий использования или бизнес-требование. Список не отменяет необходимости внимательно обсуждать требования с заинтересованными сторонами, чтобы достичь общего понимания последствий для проектирования желаемой системы/приложения. Простое создание списка не гарантирует его полноты. Бизнес-аналитик должен приложить все усилия для выявления и сбора максимально полного списка требований и рассчитывать на заинтересованные стороны, которые укажут на упущенные требования. Эти списки могут создать иллюзию взаимопонимания между заинтересованными сторонами и разработчиками; бизнес-аналитики играют ключевую роль в процессе их интерпретации. Выявить все функциональные требования до начала разработки и тестирования практически невозможно. Если эти списки рассматриваются как незыблемый договор, то требования, возникающие в процессе разработки, могут привести к спорным запросам на изменения.
Альтернатива спискам требований
В качестве альтернативы спискам требований, гибкая разработка программного обеспечения использует пользовательские истории для формулирования требований на простом языке.
Измеримые цели
Лучшие практики рассматривают составленный список требований лишь как отправные точки и многократно задают вопрос "почему?", пока не будут выявлены истинные бизнес-цели. Заинтересованные стороны и разработчики затем могут разработать тесты для измерения степени достижения каждой из этих целей. Такие цели меняются медленнее, чем длинный перечень конкретных, но не поддающихся измерению требований. Как только будет определен небольшой набор критически важных, измеримых целей, возможно быстрое прототипирование и короткие итеративные циклы разработки, позволяющие предоставлять реальную ценность заинтересованным сторонам задолго до середины проекта.
Прототипы
Прототип – это компьютерная программа, демонстрирующая часть свойств другого компьютерного приложения, позволяющая пользователям визуализировать приложение, которое еще не создано. Популярной формой прототипа является макет, который помогает будущим пользователям и другим заинтересованным сторонам составить представление о том, как будет выглядеть система. Прототипы облегчают принятие дизайнерских решений, поскольку аспекты приложения можно увидеть и обсудить до начала разработки. Введение прототипов часто приводило к значительному улучшению коммуникации между пользователями и разработчиками. Ранний показ приложений позволял сократить количество изменений на более поздних этапах и, следовательно, существенно снизить общие затраты. Прототипы могут быть представлены в виде плоских диаграмм (часто называемых вайрфреймами) или рабочих приложений с имитированной функциональностью. Вайрфреймы создаются в различных документах графического дизайна и часто лишаются цветовой гаммы (то есть используют серую палитру) в тех случаях, когда предполагается, что финальное программное обеспечение будет иметь разработанный графический дизайн. Это помогает избежать путаницы относительно того, отражает ли прототип окончательный внешний вид и ощущения от приложения.
Случаи использования
Случай использования — это структура для документирования функциональных требований к системе, как правило, включающей программное обеспечение, будь то новое или изменяемое. Каждый случай использования предоставляет набор сценариев, описывающих, как система должна взаимодействовать с пользователем или другой системой для достижения конкретной бизнес-цели. Случаи использования обычно избегают технической терминологии, предпочитая язык конечного пользователя или эксперта предметной области. Разработка случаев использования часто ведется совместно инженерами по требованиям и заинтересованными сторонами. Случаи использования – это кажущиеся простыми инструменты для описания поведения программного обеспечения или систем. Случай использования содержит текстовое описание того, как предполагается, что пользователи будут взаимодействовать с программным обеспечением или системой. Случаи использования не должны описывать внутреннее устройство системы и не должны объяснять, как система будет реализована. Вместо этого они показывают шаги, необходимые для выполнения задачи, без каких-либо последовательных предположений.
Спецификация требований
Спецификация требований – это синтез результатов анализа текущих потребностей бизнеса и оценка этих потребностей для определения и формулирования того, что необходимо для их удовлетворения в рамках рассматриваемого решения. Анализ, выявление и спецификация требований позволяют перейти от понимания текущего состояния к описанию будущего состояния. Спецификация требований может охватывать всю полноту и глубину будущего состояния, которое предстоит реализовать, либо фокусироваться на устранении конкретных недостатков, таких как приоритетные ошибки программного обеспечения, которые необходимо исправить, и внесении улучшений. Поскольку практически любой крупный бизнес-процесс предполагает использование программного обеспечения, систем данных и технологий, спецификация требований часто связана с разработкой программных систем, их приобретением, стратегиями облачных вычислений, встроенным программным обеспечением в продукты или устройства, или другими технологиями. В более широком смысле, спецификация требований включает или фокусируется на любой стратегии или компоненте решения, таком как обучение, документация, персонал, маркетинговые стратегии, оборудование, материалы и т.д.
Типы требований
Требования классифицируются различными способами. Ниже приведены распространенные классификации требований, относящиеся к техническому менеджменту: