Требования к программному обеспечению


Бесплатная юридическая консультация:

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

Оглавление:

Требования могут выражаться в виде текстовых утверждений и графических моделей.

В классическом техническом подходе совокупность требований используется на стадии проектирования программного обеспечения (ПО). Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях.

Этапу разработки требований может предшествовать технико-экономическое обоснование или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.

Содержание

  • Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
  • Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде сценариев использования (англ.use case ), пользовательских историй (англ.user stories ), сценариев взаимодействия (scenario).
  • Функциональные требования — охватывают предполагаемое поведение системы, определяя действия, которые система способна выполнять [источник не указан 1700 дней] . Описывается в системной спецификации (англ.system requirement specification , SRS).
  • Функциональный характер — требования к поведению системы
    • Бизнес-требования
    • Пользовательские требования
    • Функциональные требования
  • Нефункциональный характер — требования к характеру поведения системы
    • Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
    • Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным требованиям и ограничениям относятся:
      • Ограничения на программные интерфейсы, в том числе к внешним системам
      • Требования к атрибутам качества
      • Требования к применяемому оборудованию и ПО
    • Требования к документированию
    • Требования к дизайну и юзабилити
    • Требования к безопасности и надёжности
    • Требования к показателям назначения (производительность, устойчивость к сбоям и т. п.)
    • Требования к эксплуатации и персоналу
    • Прочие требования и ограничения (внешние воздействия, мобильность, автономность и т. п.).
  • Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
  • Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
  • Текущая организация деятельности объекта автоматизации
  • Модели деятельности (диаграммы бизнес-процессов)
  • Представления и ожидания потребителей и пользователей системы
  • Журналы использования существующих программно-аппаратных систем
  • Конкурирующие программные продукты

Характеристики качества требований по-разному определены различными источниками. Однако, следующие характеристики являются общепризнанными:

  • Интервью, опросы, анкетирование
  • Мозговой штурм, семинар
  • Наблюдение за производственной деятельностью, «фотографирование» рабочего дня
  • Анализ нормативной документации
  • Анализ моделей деятельности
  • Анализ конкурентных продуктов
  • Анализ статистики использования предыдущих версий системы

Все требования должны поддаваться проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).


Бесплатная юридическая консультация:

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

Нефункциональные требования, которые не поддаются проверке на программном уровне, все равно должны быть сохранены как документация намерений клиента. Такие требования к продукту могут быть преобразованы в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование. Сложные требования безопасности авиационного программного обеспечения могут быть удовлетворены следованием процессу разработки DO-178B (англ.) .

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

При разработке требований существует технический компромисс между слишком неопределёнными требованиями и требованиями столь детализированными, что они:

  • требуют много времени для разработки, иногда даже рискуют устареть к концу разработки;
  • ограничивают возможные способы реализации;
  • являются слишком дорогостоящими.

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

В зарубежной и российской практике встречаются следующие типы документов требований:


Бесплатная юридическая консультация:

  • Концепция программы (Vision) [источник не указан 1782 дня]
  • Спецификация программного обеспечения (англ.Software Requirements Specification, SRS )

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

За создание спецификации программного обеспечения чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.

Для графических моделей требований исторически использовались диаграммы или методологии графического моделирования: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

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

Источник: http://ru-wiki.org/wiki/%D0%A2%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%BC%D1%83_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8E


Бесплатная юридическая консультация:

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

Согласно Федеральному закону от 24.06.1998 N 89-ФЗ «Об отходах производства и потребления», при архитектурно-строительном проектировании, строительстве, реконструкции, капитальном ремонте зданий, сооружений и иных объектов, в процессе эксплуатации которых образуются отходы, индивидуальные предприниматели, юридические лица обязаны соблюдать федеральные нормы и правила и иные требования в области обращения с отходами.

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

Согласно Федеральному закону от 23.11.1995 № 174-ФЗ «Об экологической экспертизе» проектная документация объектов, используемых для размещения и (или) обезвреживания отходов I — V классов опасности, в том числе проектная документация на строительство, реконструкцию объектов, используемых для обезвреживания и (или) размещения отходов I — V классов опасности, а также проекты вывода из эксплуатации указанных объектов, проекты рекультивации земель, нарушенных при размещении отходов I — V классов опасности, и земель, используемых, но не предназначенных для размещения отходов I — V классов опасности являются объектами государственной экологической экспертизы.

Индивидуальные предприниматели и юридические лица, осуществляющие деятельность в области обращения с отходами, обязаны:

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

Деятельность по сбору, транспортированию, обработке, утилизации, обезвреживанию, размещению отходов I — IV классов опасности подлежит лицензированию в соответствии с Федеральным законом от 4 мая 2011 г. № 99-ФЗ «О лицензировании отдельных видов деятельности».


Бесплатная юридическая консультация:

При размещении отходов взимается плата за негативное воздействие на окружающую среду в соответствии с Федеральным законом от 10 января 2002 года N 7-ФЗ «Об охране окружающей среды» и Федеральным законом от 24.06.1998 N 89-ФЗ «Об отходах производства и потребления».

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

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

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

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


Бесплатная юридическая консультация:

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

Все права защищены.

Копирование материалов разрешено только с согласия правообладателя.

Источник: http://primtrud.ru/content/osnovnyie-trebovaniya-v-oblasti-obrashheniya-s-othodami.html

Требования к программному обеспечению.

Функциональные требования к программному обеспечению

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


Бесплатная юридическая консультация:

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

Требования к программному обеспечению более конкретизированы. Мы собираемся на их основе создавать код. Следовательно, они должны быть "тестируемыми", т.е. достаточно конкретными, чтобы можно было проверить, дей­ствительно ли система реализует некое заданное требование.

Функциональные требования к программному обеспечению описывают, как ведет себя система. Эти требования обычно ориентированы на действия и содержат формулировки вида: "Когда пользователь делает X, система будет делать Y". Большинство продуктов и приложений, предназначенных для выполнения полезной работы, содержит множество функциональных требований к программному обеспече­нию. Программное обеспечение используется для реализации большей части функцио­нальных возможностей.

При определении функциональных требований к ПО следует искать золотую середину ме­жду слишком конкретизированной формулировкой требования и слишком общей и не­однозначной. Например, как правило, ни к чему иметь обобщенное функциональное требование следующего вида: "Когда пользователь нажимает кнопку “Пуск”, система запускается и начинает ра­ботать". С другой стороны, формулировка требования, которая состоит из нескольких страниц текста, по-видимому, слишком конкретизирована, хотя и может быть правомерной в некоторых частных случаях. Опыт свидетельствует, что определение требования, состоящее из одного — двух предложений, обычно является наилучшим, когда нужно соотнести по­требность пользователя с приемлемым для работы команды разработчиков уровнем конкретизации.

Нефункциональные требования к программному обеспечению

Бесплатная юридическая консультация:

Функциональные требования описывают, как система должна вес­ти себя, когда ей предоставляются определенные входные данные или условия. Но этого недостаточно для полного описания требований к системе. Необходимо также учитывать следующие характеристики, которые Роберт Грейди (Grady) [7] назвал "нефункциональными требованиями".

· возможность обслуживания (Supportability).

Эти требования, как правило, используются для описания некоторых "атрибутов сис­темы" или "атрибутов системного окружения". Благо­даря их удобной классификации команда может больше узнать о системе, которую необходи­мо создать.

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

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

Указать время выполнения типичных задач или транзакций, осуществляемых ко­нечным пользователем. При создании системы ввода заказов на покупку, вероят­но, наиболее типичными задачами, выполняемыми конечными пользователями, будут ввод, удаление или модификация заказа, а также проверка состояния заказа. Если пользователь знает, как выполнять эти задачи, сколько времени он потратит на ввод типичного заказа: 1 минуту, 5 минут, 1 час… Безусловно, эта характеристика будет зависеть от технической реализации: пропускной способности сети, объема оперативной памяти, мощности процессора, которые совместно определяют время ответа, обеспечиваемое системой, но время выполнения задач также напрямую зависит от практичности системы, и нужно иметь возможность зафиксировать это значение.


Бесплатная юридическая консультация:

Сравнить практичность новой системы с уже существующими современными сис­темами, которые известны и пользуются успехом у пользователей. Иными слова­ми, требование может выглядеть так: "Новая система должна быть признана по­давляющим большинством (90%) пользователей такой же практичной, как и суще­ствующая XYZ-система". Обратите внимание, что нефункциональные требования к ПО, равно как и все остальные, должны допускать возможность проверки соответствия. Команда разработчиков должна описывать требование так, чтобы пользователи могли проверить соответствие практичности установленному критерию.

Оговорить существование систем интерактивных подсказок, программ-помощников, средств предупреждения, руководств пользователя и других форм документации и помощи, а также определить их функциональное поведение.

Следовать соглашениям и стандартам, разработанным для человеко-машинного ин­терфейса. Чтобы новая система работала "почти так же, как та, которую пользователь уже исполь­зовал", необходимо следовать согласованным стандартам от приложения к приложе­нию. Например, можно указать требование соответствия общим стандартам прак­тичности, таким как стандарты CUA (Common user access) компании IBM или стандарты Windows-приложений, опубликованные компанией Microsoft. Примером подлинного прорыва в сфере практичности в компьютерном мире может слу­жить разница между командными строками операционных систем DOS и UNIX и GUI-интерфейсами операционных систем Windows и Macintosh. GUI-интерфейсы значительно упростили использование компьютера для пользователей, не имеющих технического образо­вания. Еще одним примером является Internet-браузер, который стал окном в мир World Wide Web и радикально ускорил освоение Internet рядовым пользователем.

Было предпринято несколько попыток сделать более строгим весьма расплывчатое понятие практичности. Наибольший интерес представляет так называемый "Билль о правах пользователей", предложенный Каратом (Karat), [8]. Последняя его версия состоит из десяти основных пунктов.

· Пользователь всегда прав. Если возникает проблема с использованием системы, то дело в системе, а не в пользователе

ggg

· Пользователь имеет право на программное и аппаратное обеспечение, которое легко монтируется и демонтируется без негативных последствий.

· Пользователь имеет право на то, чтобы система делала в точности то, что обещано.

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

· Пользователь имеет право на внимание со стороны системы, а также на то, чтобы иметь возможность получить ответ системы на запрос о внимании.

· Пользователь имеет право на то, чтобы система предоставляла четкую, понятную и точную информацию о выполняемой задаче и ее выполнении.


Бесплатная юридическая консультация:

· Пользователь имеет право на то, чтобы его информировали о всех системных требованиях для успешного использования программного обеспечения или аппаратуры.

· Пользователь имеет право знать о пределах возможностей системы.

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

· Пользователь должен быть хозяином программных и аппаратных технологий, а не наоборот. Продукты должны использоваться естественно и интуитивно.

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


Бесплатная юридическая консультация:

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

Доступность (availability). Система должна быть доступна для операционного использования в течение указанного времени (в процентном выражении). Иногда требование может указывать непрерывную "nonstop" доступность, т.е. 24 часа в сутки, 365 дней в году. Однако на практике чаще оперируют, к примеру, 99-процентной доступностью между 8 часами утра и полуночью. При этом следует определить, что понимается под "доступностью". Означает ли процентная доступность, что все пользователи должны иметь возможность использовать все системные услуги в любое время?

Среднее время между сбоями (mean time between failures, MTBF). Обычно оно указывается в часах, но может также указываться в днях, месяцах или годах. Здесь тоже нужна точность: требования должны четко определять, что понимается под "сбоем".

Среднее время восстановления (mean time to repair, MTTR). Как долго системе разрешается не работать после сбоя? MTTR может иметь несколько значений; например, пользователь может указать, что 90% всех системных сбоев должны ликвидироваться за 5 минут, а 99.9% — в течение часа. Вновь важна точность: требования должны четко указывать, означает ли восстановление, что все пользователи снова будут иметь возможность получать доступ ко всем услугам, или допускается частичное восстановление системы.

Точность (accuracy). Указывается точность в системах с числовым выводом. На­пример, должны ли результаты в финансовых системах приводиться с точностью до копеек или рублей, каково количество точек после запятой в системе, осуществляющей математические расчеты.

Количество различных ошибок. Обычно ошибки делятся на незначительные, серьезные и критические. Здесь также важны четкие определения: требования должны опреде­лять, что понимается под "критической" ошибкой — полная потеря данных или невоз­можность использовать определенную часть функциональных возможностей системы.


Бесплатная юридическая консультация:

При записи требований производительности обычно используют следующие характеристики:

· среднее и максимальное время ответа для транзакции;

· число транзакций в секунду, именуемое также пропускной способностью;

· емкость: количество пользователей или транзакций, которые система может обслуживать;

· допустимые режимы снижения производительности при ухудше­нии параметров работы системы.


Бесплатная юридическая консультация:

Если новая система должна совместно с другими системами или приложениями ис­пользовать аппаратные ресурсы (ЦП, память, каналы, дисковую память, сетевой диапа­зон частот), может потребоваться указать, насколько "цивилизованно" она себя при этом ведет.

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

Например, команда работает над созданием новой системы бухгалтерского учета. Одно из многих требований к такой системе состоит в автоматическом расчете налога на добавленную стоимость при генерации счетов-фактур. Опытные бухгалтеры — пользователи системы располагают информацией, что налоговые органы периодически изменяют ставку налога. Тогда требование можно сформулировать следующим образом: "Модификация системы с целью зада­ния новой ставки налогообложения должна осуществляться командой в тече­ние одного дня после получения уведомления от налоговых органов".

Но предположим, что налоговая инспекция периодически вносит в алгоритм расчета налога на добавленную стоимость существенные поправки, например следующего вида: "Разрешено ведение бухгалтерского учета по упрощенной схеме налогообложения. При этом предприятия, работающие по упрощенной схеме освобождены от уплаты НДС. Налог на прибыль в этом случае исчисляется как 10 процентов от оборота по счету юридического лица за отчетный период". Подобные модификации слож­нее предусмотреть в программе; хотя можно попытаться сделать ее максимально гибкой. Команда разработчиков, вероятно, согласится, что данная модификация попадает в категорию измене­ний "среднего уровня" сложности, для которых требование может задавать время реаги­рования — одна неделя.

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


Бесплатная юридическая консультация:

Типы ограничений проектирования приведены в табл. 3.12.

Таблица 3.12. Типы ограничений проектирования.

Еще одним важным источником ограничений проектирования яв­ляются разнообразные инструкции и стандарты, которым подчиняется разработка проекта. Как правило, сформулированные в виде разнообразных инструкций проектные ограничения этого типа слишком длинные, чтобы их можно было непосредственно включить требования. В большинстве случаев достаточно внести их в список ограничений проектирования в форме ссылок. Однако при включении подобных ссылок тоже имеется определенный риск. Нужно внимательно следить за тем, чтобы включать конкретные, имеющие отношение к делу, а не общие ссылки. Например, одна ссылка вида: “Продукт должен соответствовать стандарту ISO 9001” фактически "связывает" продукт со всеми стандартами документа. Следует стремиться найти "золотую середину" между чрезмерной и недостаточной конкретизацией.

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

Следует отличать ограничения проектирования от других требований. Например, если требо­вания к ПО обозначены ярлыком "SR" (software requirement), для ограничений проек­тирования можно использовать ярлык "DC" (design constraint).


Бесплатная юридическая консультация:

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

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

Следует документировать объяснения для каждого ограничения проектирования: несколько предложений, объясняющих причину наложения того или иного ограничения проектирования. Это поможет восстановить, что послужило мотивом для наложения конкретного ограничения.

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

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


Бесплатная юридическая консультация:

Использование «дочерних» требований для повышения уровня конкретизации.

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

Рассмотрим пример. Предположим, необходимо разработать электрон­ный прибор, работающий от стандартной электросети. Как сформулиро­вать требования, касающиеся питания данного прибора?

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

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


Бесплатная юридическая консультация:

Родительское требование. Прибор должен работать от стандартной электросети.

· Дочернее 1. Прибор должен работать при напряжении в диапазоне Х1-X2 вольт АС.

· Дочернее 2. Для нормального функционирования прибор должен потреблять не более Y ампер.

· Дочернее 3. Прибор должен работать так, как указано в спецификации, если входная частота варьируется в пределах Х3-Х4 герц.

Использование дочерних требований является способом гибкого расширения и до­полнения спецификаций и одновременно обеспечивает контроль глубины представляе­мых деталей. Этот подход можно использовать и в том случае, если необходима дальнейшая кон­кретизация. Например, легко представить себе ситуацию, когда «дочернее» требование в свою очередь становится «родительским» для следующего уровня детализации. Другими словами, можно расширять иерархию далее, до такого уровня детализации, в котором нуждается проект. Не смотря на то, что понятие дочерних тре­бований чрезвычайно полезно, необходимо избегать слишком большого числа иерархи­ческих уровней детализации. В противном случае существует риск запутаться в массе микроскопиче­ских деталей. Как правило, достаточно ограничиться двумя подуровнями — "дочерним" и "внучатым".


Бесплатная юридическая консультация:

Лучше всего не отделять дочерние требования от родительских, а включать их в главный пакет требований. Чтобы при чтении проще было связать дочерние требования с родительским, обо­значение дочерних требований должно основываться на обозначении родительских. Предположим, что требование к программному обеспечению SR63.1 име­ет одно или несколько дочерних требований. Естественно будет обозначить дочерние требования SR63.1.1. SR63.1.2, SR63.1.3 и т.д.

При работе с требованиями, содержащими дочерние требования полезно иметь возможность расширять / сужать полный набор требований так, чтобы можно было рассматривать только родительские требования (отдельно) или родительские вместе с дочерними.

Источник: http://lektsii.org/.html

36. Требования в области охраны окружающей среды при осуществлении хозяйственной и иной деятельности.

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

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


Бесплатная юридическая консультация:

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

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

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

обеспечивать проведение инвентаризации выбросов вредных веществ в атмосферный воздух и разработку предельно допустимых выбросов;

внедрять малоотходные и безотходные технологии в целях снижения уровня загрязнения атмосферного воздуха;

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

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

осуществлять учет выбросов вредных веществ в атмосферный воздух и их источников, проводить производственный контроль за соблюдением установленных нормативов выбросов вредных веществ в атмосферный воздух;

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

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

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

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

При эксплуатации хозяйственных и других объектов запрещается:

осуществлять сброс в водные объекты неочищенных и необезвреженных в соответствии с установленными нормативами сточных вод;

производить забор воды из водных объектов, существенно влияющий на их состояние;

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

Со ст.34 по 53 ст. требования з-н об охране окр.среды.

 Основные Требования в области охраны окружающей среды при размещении зданий, строений, сооружений и иных объектов

 Требования в области охраны окружающей среды при проектировании зданий, строений, сооружений и иных объектов

 Требования в области охраны окружающей среды при строительстве и реконструкции зданий, строений, сооружений и иных объектов

 Требования в области охраны окружающей среды при вводе в эксплуатацию зданий, строений, сооружений и иных объектов

 Требования в области охраны окружающей среды при эксплуатации и выводе из эксплуатации зданий, строений, сооружений и иных объектов

 Требования в области охраны окружающей среды при эксплуатации и выводе из эксплуатации зданий, строений, сооружений и иных объектов

 Требования в области охраны окружающей среды при размещении, проектировании, строительстве, реконструкции, вводе в эксплуатацию, эксплуатации и выводе из эксплуатации военных и оборонных объектов, вооружения и военной техники

 Требования в области охраны окружающей среды при эксплуатации объектов сельскохозяйственного назначения

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

 Требования в области охраны окружающей среды при размещении, проектировании, строительстве, реконструкции городских и сельских поселений

 Требования в области охраны окружающей среды при производстве и эксплуатации автомобильных и иных транспортных средств

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

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

 Требования в области охраны окружающей среды при использовании радиоактивных веществ и ядерных материалов

 Требования в области охраны окружающей среды при использовании химических веществ в сельском хозяйстве и лесном хозяйстве.

Для продолжения скачивания необходимо собрать картинку:

Требования в

Требования в области охраны окружающей среды при осуществлении хозяйственной и иной деятельности регламентируются главой VII Федерального закона от 10 января 2002 г. N 7-ФЗ «Об охране окружающей среды».

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

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

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

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

При проектировании зданий, строений, сооружений и иных объектов (ст. 36) должны учитываться нормативы допустимой антропогенной нагрузки на окружающую среду, предусматриваться мероприятия по предупреждению и устранению загрязнения окружающей среды, а также способы размещения отходов производства и потребления.

Вход на сайт

ВНИМАНИЕ!

Постановление Пленума ВС РФ от 26 декабря 2017 года № 58 «О применении судами законодательства об обязательном страховании гражданской ответственности владельцев транспортных средств»

Постановление Пленума ВС РФ от 26 декабря 2017 года № 57 «О некоторых вопросах применения законодательства, регулирующего использование документов в электронном виде в деятельности судов общей юрисдикции и арбитражных судов»

Постановление Пленума ВС РФ от 26 декабря 2017 года № 56 «О применении судами законодательства при рассмотрении дел, связанных со взысканием алиментов»

Источник: http://jurkom74.ru/ucheba/trebovaniya-v-oblasti-ochrani-okruzhaiuschey-sredi-pri-osuschestvlenii-chozyaystvennoy-i-inoy-deyatelnosti

Понятие требования. Классификации требований

Определение понятия требования

Л.Новиков в русской редакции нотации RUP [2.9] приводит следующее определение : «Требование — это условие или возможность, которой должна соответствовать система».

В IEEE Standard Glossary of Software Engineering Terminology (1990) [2.1] данное понятие трактуется шире. Требование — это:

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

IEEE (Institute of Electrical and Electronics Engineers) — институт инженеров по электротехнике и электронике, http://www.ieee.org – международная некоммерческая ассоциация специалистов в области техники, делит с МЭК (http://www.iec.ch/) мировое лидерство в области разработки стандартов по радиоэлектронике и электротехнике. IEEE объединяет более 400 тыс. членов из 170 стран, в том числе более 100 тыс. студентов.

IEC (International Electrotechnical Commission) — международная электротехническая комиссия (МЭК), http://www.iec.ch. МЭК – некоммерческая организация, наряду с IEEE (http://www.ieee.org)- признанный мировой лидер в области создания международных стандартов в сфере электрики, электронники и смежных технологий, в том числе — в области информационных технологий. Под эгидой организации сотрудничают болееспециалистов. Некоторые из разработанных стандартов созданы совместно с ISO.

Введем еще одно определение . Требования — это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы . Первичные данные поступают из различных источников, характеризуются противоречивостью, неполнотой, нечеткостью, изменчивостью. Требования нужны в частности для того, чтобы Разработчик мог определить и согласовать с Заказчиком временные и финансовые перспективы проекта автоматизации. Поэтому значительная часть требований должна быть собрана и обработана на ранних этапах создания АИС. Однако собрать на ранних стадиях все данные, необходимые для реализации АИС, удается только в исключительных случаях. На практике процесс сбора, анализа и обработки растянут во времени на протяжении всего жизненного цикла АИС, зачастую нетривиален и содержит множество подводных камней; подробнее о процессе — в лекциях 4 — 8.

Классификация требований

Существует значительное количество различных методов классификации требований [2.2-2.7], наиболее существенные из которых будут рассмотрены в лекции.

Требования к продукту и процессу

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

Требования к проекту. Вопросы формулирования требований к проекту, т.е. к тому, как Разработчик будет выполнять работы по созданию целевой системы, казалось бы, не лежат в компетенции Заказчика. Без регламентации процесса Заказчиком легко можно было бы обойтись, если бы все проекты всегда выполнялись точно и в срок. Однако, к сожалению, мировая статистика результатов программных проектов говорит об обратном. Заказчик, вступая в договорные отношения с Разработчиком, несет различные риски, главными из которых является риск получить продукт с опозданием, либо ненадлежащего качества. Основные мероприятия по контролю и снижению риска — регламентация процесса создания программного обеспечения и его аудит.

Насколько подробно Заказчику следует регламентировать требования к проекту — вопрос риторический. Ответ на него зависит от множества факторов, таких, как ценность конечного продукта для Заказчика, степень доверия Заказчика к Разработчику, сумма подписанного контракта, увязка срока сдачи продукта в эксплуатацию с бизнес-планами Заказчика и т.д. Однако, со всей определенностью можно сказать следующее:

  1. регламентация процесса Заказчиком позволяет снизить его риски;
  2. мероприятия Заказчика по регламентации процесса приводят к дополнительным накладным расходам. Требуется найти разумный компромисс между степенью контроля рисков и величиной расходов.

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

  1. Разработчик представляет Заказчику согласованный план работ c детализацией (WorkBreakdownStructure — WBS ) с точностью до конкретных исполнителей.
  2. Разработчик осуществляет ежедневные сборки, регрессионное тестирование компонентов разрабатываемого продукта и тестирование продукта в целом.
  3. Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме online в интегрированной среде разработки Rational ClearCase с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий.

WBS Work Breakdown Structure – иерархическая структура работ. Согласно PMBOK , WBS – это ориентированная на результаты (предметы поставки) иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и получения необходимых результатов. С ее помощью структурируется и определяется все содержание проекта.

Уровни требований

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

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

Обычно выделяют три уровня требований.

  • На верхнем уровне представлены так называемые бизнес-требования ( business requirements ). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.
  • Следующий уровень — уровень требований пользователей ( user requirements ). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований.
  • Третий уровень — функциональный ( functional requirements ). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

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

Важные правила внедрения и использования АИС на предприятии — «Одна точка сбора», «Данные собираются там, где они появляются». Использование этих правил позволяет избежать затрат на необоснованное дублирование информации и, что важнее — потерь от ошибок учета, неизбежно возникающих при дублировании точек ввода.

Внедрение АИС на предприятии приводит к необходимости оснащения всех точек ввода информации автоматизированными рабочими местами (АРМ), обучению персонала и, зачастую, оптимизации и повышению уровня формализации рабочих процессов, выполняемых персоналом. Поэтому внедрение АИС — непростой процесс, часто требующий «перекройки человеческого материала» и встречающий сопротивление со стороны пользователей, которые не готовы, либо не хотят работать по-новому.

Вопросы и ответы

Какова сумма часов по программе, которые будут указаны в Дипломе о профессинальной переподготовке?

Я ранее сдал на сертификаты по безопасности информации и защиты персональных данных. Освобождает ли их наличие от сдачи обязательных курсов по этим темам при обучении на курсах МиниМБА по защите информации?

Источник: http://www.intuit.ru/studies/courses/945/174/lecture/4714