Выявление требований

В разработке требований выявление требований — это практика исследования и выявления требований к системе от пользователей, клиентов и других заинтересованных сторон. Эту практику также иногда называют « сбором требований ».

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

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

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

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

В 1992 году Кристель и Канг определили проблемы, которые указывают на трудности выявления требований:

1. « Проблемы масштаба» . Границы системы нечетко определены, или клиенты/пользователи указывают ненужные технические детали, которые могут запутать, а не прояснить общие цели системы.
2. Проблемы понимания . Клиенты/пользователи не совсем уверены в том, что им необходимо, плохо понимают возможности и ограничения своей вычислительной среды, не имеют полного понимания проблемной области, испытывают трудности с сообщением о потребностях системному инженеру, упускают информацию. которые считаются « очевидными », определяют требования, которые противоречат потребностям других клиентов/пользователей, или определяют требования, которые являются неоднозначными или непроверяемыми.
3. Проблемы волатильности . Требования со временем меняются. Скорость изменения иногда называют уровнем волатильности требований.

Качество требований можно улучшить с помощью следующих подходов:

1. Визуализация . Использование инструментов, способствующих лучшему пониманию желаемого конечного продукта, таких как визуализация и моделирование.
2. Последовательный язык . Используйте простые, последовательные определения требований, описанные на естественном языке, и используйте бизнес-терминологию, распространенную на предприятии.
3. Рекомендации . Следование организационным руководящим принципам, описывающим методы сбора и типы требований, которые необходимо собрать. Эти рекомендации затем последовательно используются во всех проектах.
4. Последовательное использование шаблонов . Создание согласованного набора моделей и шаблонов для документирования требований.
5. Документирование зависимостей . Документирование зависимостей и взаимосвязей между требованиями.
6. Анализ изменений . Выполнение анализа первопричин изменений требований и принятие корректирующих действий.

Рекомендации

В 1997 году Соммервилль и Сойер предложили набор руководящих принципов по выявлению требований для решения проблем, подобных тем, которые выявили Кристель и Канг:

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

Последовательность действий

В 2004 году Голдсмит предложил «проблемную пирамиду» из «шести шагов, которые необходимо выполнить последовательно»:

1. Определите реальную проблему, возможность или вызов
2. Определите текущие меры, которые показывают, что проблема реальна.
3. Определите целевые показатели, чтобы показать, что проблема решена, и ценность ее решения.
4. Определите причину(ы) проблемы «как есть», поскольку необходимо устранить именно причины, а не саму проблему.
5. Определите «желания» бизнеса, которые должны быть реализованы для достижения целевых показателей.
6. Укажите дизайн продукта, отвечающий реальным требованиям бизнеса.

Однако Голдсмит отмечает, что выявить реальную проблему «чрезвычайно сложно».

подходы

В 2008 году Александр и Беус-Дукич предложили набор дополнительных подходов к выявлению требований:

• Определение заинтересованных сторон
• Моделирование целей
• Контекст моделирования
• Обнаружение сценариев (или вариантов использования )
• Обнаружение «качеств и ограничений» ( нефункциональных требований )
• моделирования Обоснование и предположения
• Написание определений терминов
• Анализ измерений (критерии приемки)
• Анализ приоритетов

Александер и Беус-Дукич предположили, что эти подходы могут проводиться с отдельными людьми (как в интервью ), с группами (как в целенаправленных встречах, известных как семинары, или через электронные системы встреч ) или с помощью «вещей» (артефактов), таких как прототипы .

Нефункциональные требования

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

1. Операция: насколько хорошо используется [требует редактирования]?
2. Ревизия: насколько легко исправлять ошибки и добавлять функции?
3. Переход: насколько легко адаптироваться к изменениям в технической среде?

В 2013 году Мурали Чемутури предложил использовать требования вспомогательной функциональности вместо нефункциональных требований, поскольку «нефункциональный» означает «никогда не функциональный». Во-вторых, эти требования фактически соответствуют некоторым требованиям, которые поддерживают основные или основные требования к функциональности.

Библиография

• Александр, Ян Ф.; Беус-Дукич, Льерка (март 2009 г.). Выявление требований: как определять продукты и услуги . Джон Уайли. ISBN  978-0-470-71240-5 .
• Голдсмит, Робин Ф. (2004). Выявление реальных бизнес-требований для успеха программного проекта . Артех Хаус. ISBN  1-58053-771-5 .
• Миллер, Роксана Э. (2009). В поисках требований к программному обеспечению: контрольные вопросы, позволяющие сосредоточить внимание на нефункциональных требованиях; Проверенные методы обеспечения правильного вовлечения заинтересованных сторон . Книги МавенМарк. ISBN  978-1-59598-067-0 .
• Соммервилл, Ян ; Сойер, Пит (май 1997 г.). Разработка требований: Руководство по передовой практике . Джон Уайли. ISBN  0-471-97444-7 .
• Гобов, Денис, Гученко, Инна. (2020). Методы выявления требований для программных проектов в украинских ИТ: предварительное исследование. http://dx.doi.org/10.15439/2020F16 .

См. также

• Прогрессивная разработка