Разработанные требования, как правило, утверждаются представителем пользователя. В независимой от пользователя разработке, требования к ПС определяются без какого. Это происходит обычно тогда, когда разработчик решает создать ПС широкого применения в расчёте на то, что разработанное им ПС найдёт спрос на рынке профаммных средств. С точки зрения обеспечения надёжности ПС наиболее предпочтительным является контролируемая пользователем разработка. Спецификация качества программного средства Разработка спецификации качества сводится, по существу, к построению своеобразной модели качества требуемого ПС . В этой модели должен быть перечень всех тех свойств, которые необходимо обеспечить в этом ПС и которые в совокупности образуют приемлемое для пользователя качество ПС. При этом каждое из этих свойств должно быть в достаточной мере конкретизировано с учётом определения требований к ПС, а также с учётом возможности оценки его наличия у разработанного ПС или оценки степени, в которой ПС обладает этим свойством. Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС, разработанных . Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от примитивов качества ПС. С данным критерием связано много различных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества. Изучаемость это характеристики ПС, которые позволяют минимизировать усилия по изучению и пониманию программ и документации ПС. Модифицируемость это характеристики ПС, которые позволяют автоматически настраивать на условия применения ПС или упрощают внесение в него вручную необходимых изменений и доработок. Ниже определяются используемые примитивы качества ПС . Здесь приводится достаточно большой список, состоящий из . Некоторые их комбинации образуют более крупные понятия критерии и подкритерии качества. Такие комбинации можно рассматривать как определённые системы. Но ни одна из этих комбинаций не содержит более шести примитивов . Эффективность по ресурсам . Эффективность по устройствам . Этот примитив качества синтезирован нами из таких примитивов . Независимость ПС от устройств . Функциональная спецификация программного средства С учётом назначения функциональной спецификации ПС и тяжёлых последствий неточностей и ошибок в этом документе, функциональная спецификация должна быть математически точной. Это не означает, что она должна быть формализована настолько, что по ней можно было бы автоматически генерировать программы, решающие поставленную задачу. А означает лишь, что она должна базироваться на понятиях, построенных как математические объекты, и утверждениях, однозначно понимаемых разработчиками ПС. Достаточно часто функциональная спецификация формулируется на естественном языке. Тем не менее, использование математических методов и формализованных языков при разработке функциональной спецификации весьма желательно, так что этим вопросам будет посвящена отдельная глава. Функциональная спецификация состоит из трёх частей. В первой части должны быть определены на концептуальном уровне все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами. Примером описания информационной среды может быть концептуальная схема базы данных или описание сети датчиков и приборов, которой должна управлять разрабатываемая ПС. Во второй части вводятся обозначения всех определяемых функций, специфицируются все входные данные и результаты выполнения каждой определяемой функции, включая указание их типов и заданий всех соотнощений . И, наконец, определяется семантика каждой из этих функций, что является наиболее трудной задачей функциональной спецификации ПС. Обычно эта семантика описывается неформально на естественном языке примерно так, как это делается при описании семантики многих языков программирования. Эта задача может быть в ряде случаев существенно облегчена при достаточно четком описании внещней информационной среды, если внещние функции задают какие. В третьей части должны быть перечислены все существенные случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию . Примером может служить обнаружение ошибки во время взаимодействия с пользователем, попытка применить какую. Для каждого такого случая должна быть определена . Методы контроля внешнего описания программного средства Разработка внешнего описания обязательно должна завершаться проведением тщательного и разнообразного контроля его правильности. Цель этого процесса состоит в поиске как можно большего числа ошибок, сделанных на этом этапе. Учитывая, что результатом этого . Можно выделить следующие методы контроля, применяемые на этом этапе. Первый метод предполагает внимательное прочтение текста внещнего описания разработчиком с целью проверки его полноты и непротиворечивости, а также выявления других неточностей и ощибок. Смежный контроль спецификации качества сверху это её проверка со стороны разработчика требований к ПС, а смежный контроль функциональной спецификации это её проверка разработчиками требований к ПС и спецификации качества. Смежный контроль внещнего описания снизу это его изучение и проверка разработчиками архитектуры ПС и текстов программ, а также его изучение и проверка разработчиками документации по применению и разработчиками комплекта тестов. Пользовательский контроль внещнего описания это участие пользователя . Если разработка требований к ПС велась под управлением пользователя, то пользовательский контроль внещнего описания, по существу, означает его смежный контроль сверху. Однако, если представителю пользователя оказывается трудно самостоятельно разобраться во внещнем описании, создается специальная группа разработчиков, выполняющая роль пользователя .