Определение системных требований

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

1. Общие функциональные требования. Основные функции, выполняемые системой, определяются на самом высшем (абстрактном) уровне представления системы. Детализация функциональных требований происходит уже на уровне подсистем. Например, при разработке СУП обязательно будет предусмотрено требование иметь базу данных полетов, совершенных в контролируемом системой воздушном пространстве. Однако структура этой базы данных не будет определена до тех пор, пока не будут отработаны требования к другим подсистемам.

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

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

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

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

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

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

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

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

Подчас основная трудность в определении системных требований состоит в том, что система строится для того, чтобы помочь в решении "злостной" проблемы (wicked problem) [294]. "Злостная" проблема – это проблема такой большой сложности и имеющая столько взаимосвязанных входных воздействий, что ее невозможно точно описать. Истинная природа такой проблемы может проявиться только в процессе ее решения. В качестве экстремального примера "злостной" проблемы можно привести задачу предсказания землетрясений. В настоящее время не существует точных способов предсказания ни эпицентра землетрясения, ни его времени, ни силы, ни воздействия на окружающую среду. Поэтому невозможно заранее полностью спланировать все действия на случай большого землетрясения – это можно сделать только тогда, когда оно произойдет.