Другие преобразования с использованием архитектуры системы

из "Разработка и управление требованиями "

Поскольку процесс разработки последовательно спускается все ниже и ниже от одного уровня к другому, то на каждом из этих уровней (этапов) создается, по сути, собственная архитектурная модель (см. рис. 6.1). На каждом этапе процесс проходит точно так же, как это описано в предыдущих разделах. Другими словами, после разработки требований для подсистем более высокого уровня, начинают разрабатываться требования для компонентов этих подсистем, которые, на следующем шаге, рассматриваются уже как независимые подсистемы со своими компонентами, и так далее. [c.152]
Однако существуют особый случай (использования архитектурной модели системы), который может считаться исключением из этого правила. Это отражено на рис. 6.9, который показывает, что архитектура системы и последующие требования для подсистем могут быть получены непосредственно из пользовательских требований. [c.152]
Такой вариант возможен в том случае, когда архитектурная модель системы известна заранее (вспомните, например, уже ранее рассмотренные физические системы -автомобиль или самолет). [c.152]
Здесь уместно также привести пример из телекоммуникационной индустрии, где применяемые стандарты зачастую предписывают архитектуру решения. Опять же встает чисто теоретический вопрос, являются ли требования, предъявляемые к системе, на самом деле пользовательскими или они, по сути своей, являются уже системными требованиями. Какой бы ответ ни был бы получен, это вполне обычная практика - транслировать входящие требования на уровень производных (требований к подсистемам). Получается это благодаря тому, что стандарты, сами по себе, достаточно детализированы. [c.153]
В данной главе были рассмотрены общие свойства области решений и охарактеризован процесс разработки требований, используемый в этой области. [c.153]
Было дано описание процесса преобразования пользовательских требований в системные и последующий процесс преобразования системных требований в требования для подсистем. [c.153]
Были рассмотрены два различных примера, которые помогли раскрыть типы функциональностей, используемых для описания требований в области решений. [c.153]
Было продемонстрировано, что помимо внутренней функциональности необходимо рассматривать также и интерфейсную функциональность функциональность для обеспечения взаимодействия с людьми а также защитную функциональность, обеспечивающую как защиту системы от внешних воздействий, так и безопасность ее эксплуатации по отношению к людям и окружающей среде. [c.153]
Было упомянуто, что на более поздних этапах возможно появление дополнительных ограничений, в том числе, для соблюдения требований применяемого законодательства и для прохождения системой необходимой сертификации. [c.153]

Вернуться к основной статье