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

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

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

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

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

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

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

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

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

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

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

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