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

Принципы преобразования потребностей в требования

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

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

Процесс выявления требований

  • Преобразование потребностей в требования начинается с необходимостей заинтересованных сторон (или целей, или задач), которые уточняются и развиваются до тех пор, пока не становятся действительными требованиями заинтересованных сторон. Первоначальные заботы заинтересованных сторон не могут служить требованиями, так как они часто не имеют чёткого определения, анализа и возможно, согласованности и осуществимости. Использование Концепции операций помогает понять проблемы заинтересованных сторон на уровне организации, а Системная операционная концепция — с системной точки зрения, инженерия требований ведёт заинтересованных сторон от этих первоначальных, часто скрытых потребностей к набору объективно адекватных, структурированных и более формальных заявлений о требованиях и целях заинтересованных сторон. 
  • Когда объект системы является элементом системы на втором или более низком уровне в общей системной структуре, также необходимо определить потребности и требования заинтересованных сторон на этом уровне. Эти потребности не ограничиваются только верхней системой в системной структуре. Могут быть дополнительные заинтересованные стороны, которые обнаруживаются только после принятия решений по архитектуре или дизайну на более низком уровне.
  • Затем требования заинтересованных сторон, владеющих системой, преобразуются в требования к элементам системы более низкого уровня для интересующей системы. Где риск из-за технологии или сложности значителен, требования действительно меняются из-за изменения потребностей, или требования изначально не были определены правильно, это преобразование может включать значительную итерацию. Те же процессы также применяются рекурсивно к элементам физической системы более низкого уровня, которые сами подлежат проектированию и разработке, в результате чего вновь генерируются требования к элементам системы более низкого уровня.

Этапы преобразования:

  1. Идентификация потребностей: На этом этапе происходит сбор первичных данных о потребностях заинтересованных сторон. Ключевой задачей является установление контакта с ними и понимание их видения и ожиданий.
  2. Анализ потребностей: Здесь потребности оцениваются на предмет их реализуемости, важности и влияния на проект. Анализ помогает отсеять нереалистичные или второстепенные потребности.
  3. Уточнение потребностей: На этом этапе происходит детализация и уточнение потребностей. Важно добиться полного понимания и согласия всех заинтересованных сторон относительно каждой потребности.

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