Cтраница 2
При построении системы обозначений для спецификаций требования полноты в интеррогативах то немногое, о чем нужно позаботиться, - это чтобы формальная нотация была удобной для запоминания. [16]
Одним из основных параметров, фигурирующих в спецификации требований к фильтрам ПАВ для селекции импульсных сигналов, должен быть уровень ложных сигналов ал с, измеряемый обычно во временной области, представляющий отношение наи-оольшего ( паразитного - сигнала на выходе фильтра к основному i пгналу ПАВ. ПАВ и генерацией ОЛВ) и следуют с различным запаздыванием относительно основного сигнала. При этом не следует путать понятие уровня / южных сигналов ал. [17]
Далее, мы должны побеспокоиться только о спецификации требования максимальной полноты. [18]
Данная модель предметной области используется при формировании моделей спецификаций информационных требований пользователей. [19]
Формально удобно считать, что ли-вопросы всегда содержат спецификацию требования различения, но она неизбежно будет пустой. [20]
Формально удобно считать, что уш-вопросы всегда содержат спецификацию требования различения, но она неизбежно будет пустой. [21]
В качестве эталона при проверках используется в первую очередь спецификация требований. Вычисления проверяются путем сравнения с результатами независимых расчетов по исходным формулам. Кроме того, в качестве эталона всегда используются неформализованные представления разработчика программы и коллектива специалистов, участвующих в проверках. [22]
У ряда читателей может возникнуть вопрос, зачем нужна спецификация требования полноты сама по себе: разве нельзя ее представлять как часть самого субъекта. Иногда такая проблема реально существует и достаточно важна как таковая, но в данном контексте, когда мы конструируем логику, призванную быть полезной, вопрос о необходимости некоторой языковой характеристики попросту снимается. Вряд ли можно сомневаться в пользе Введения требования полноты - важно оно или нет, мы все равно как-то отвечаем на вопрос и даем ответ с определенной степенью полноты. Для каждого интеррогатива, имитирующего лы-вопрос, существует эротетически эквивалентный ему одно-примерный лы-интеррогатив ( о понятии эротетической эквивалентности см. разд. Уникально-альтернативные / ш / сой-интеррогативы эротетически эквивалентны некоторым одно-примерным ка / сой-интеррога-тивам. Ни один / со / сой-интеррогатив с несколькими примерами не является эротетически эквивалентным какой-интеррогативу, исчерпывающему список. [23]
У ряда читателей может возникнуть вопрос, зачем нужна спецификация требования полноты сама по себе: разве нельзя ее представлять как часть самого субъекта. Иногда такая проблема реально существует и достаточно важна как таковая, но в данном контексте, когда мы конструируем логику, призванную быть полезной, вопрос о необходимости некоторой языковой характеристики попросту снимается. Вряд ли можно сомневаться в пользе введения требования полноты - важно оно или нет, мы все равно как-то отвечаем на вопрос и даем ответ с опреде-ленной степенью полноты. Уникально-альтернативные какой-интеррогативы эротетически эквивалентны некоторым одно-примерным / ошэ - интеррога-тивам. Ни один га / ш - интеррогатив с несколькими примерами не является эротетически эквивалентным какой-интеррогативу, исчерпывающему список. [24]
В результате данных тестов проверяется работа комплексных контуров согласно спецификации требований пользователей. В ходе данных тестов не следует сочетать их с каким-либо другим приложением. [25]
Началом жизненного цикла и основой проекта системы безопасности является разработка Спецификации требований к системе безопасности. [26]
Автоматизированная система, которая может использоваться для разработки и анализа спецификаций требований ( ЕЛ58 expression of requirements), a также служить инструментальным средством проектирования систем. Спецификация требований ( техническое задание) хранится в базе данных ЭВМ, применительно к которой язык постановки задач является входным языком запросов, а анализатор постановок задач играет роль управляющей системы и генератора отчетов. [27]
Каждая предпосылка состоит из трех частей: спецификации выбора числа, спецификации требования полноты и спецификации требования различения. [28]
Результатами работ на этой стадии являются функциональная и информационная модели организации и спецификации требований к предполагаемой системе, служащие в качестве исходных данных для проектирования системы. Желательно, чтобы функциональная и информационная модели и спецификации требований были выполнены с помощью формализованных методов их описания, например с использованием средств описания моделей в известных методологиях структурного или объектно-ориентированного проектирования и языков спецификаций. В этом случае в ТЗ, разрабатываемом по результатам стадии предпроектного обследования, должно быть указание на имеющиеся исходные данные и средства описания исходных данных. Ссылки в ТЗ на документы, определяющие выбранные средства описания исходных данных, - часть профиля инструментальной среды, поддерживающей основные процессы: проектирование, разработку, сопровождение и развитие прикладного программного обеспечения ИС. [29]
На стадии стратегического планирования и анализа требований уточняются исходные данные и разрабатываются спецификации требований к прикладному программному обеспечению и к среде. Эти спецификации должны позволять уточнить первичные функциональные профили ИС, заданные в ТЗ, дополняя их стандартами, применение которых потребуется на стадии проектирования. Такие дополнения, в частности, могут возникать в связи с принятием принципиальных решений по структуре прикладного ПО, архитектуре среды распределенной обработки данных, распределению функций защиты информации между прикладным программным обеспечением и средой ИС для обеспечения заданной категории информационной безопасности, выбору инструментальных средств проектирования и программирования. Принимаемые на этой стадии решения исходят из альтернативного выбора методологии и принципов построения ИС между функционально-модульным и объектным подходами. [30]