Требования к системе программы

Содержание

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

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

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

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

Требования к продукту от разных стейкхолдеров могут быть противоречивы, разрознены и неполны. Обычно от инженера по требованиям требуется документировать (в тексте или какой-то модели) требования стейкхолдеров, а затем завизировать эти требования у них — чтобы подтвердить правильность понимания.

windows 11 vs 10 | какая система лучше в 2023 году?

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

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

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

Требование к требованиям стейкхолдеров: их понятность самим стейкхолдерам. Стейкхолдеры нуждаются в требованиях, которые сфокусированы их нуждами.

Требования к системе

Требования к системе (system requirements) — требования, достаточные для разработки системы, которые формулируются архитекторами, проектировщиками и аналитиками на основе анализа требований к продукту и описывают:

основные роли в системе,
сценарии использования системы,
информационные модели,
модели классов, поведения, развертывания,
прочие алгоритмы.

Их разрабатывает инженер по требованиям в ходе так называемой “аналитической” работы (хотя в этой работе кроме анализа требований стейкхолдеров и присутствует синтез системных требований).

Компьютер для 3D визуализации и рендера. Какой компьютер нужен для 3Д моделирования. Принцип выбора

К требованиям к системе предъявляют множество самых разных требований:

непротиворечивость,
полнота,
проверяемость
и т.д.

Требования по ГОСТ 34

Модальность

Чтобы понять природу требований, нужно разобраться с логическими модальностями высказываний о системе (модальная логика):

нейтральные высказывания о мире, суть которых непонятна без указания модальности. Например, «длина дана как 16».
алетическая (alethic) модальность, относящаяся к возможности существования: пока воплощения системы ещё нет, возможны варианты определений системы для разных возможных вариантов будущего воплощения системы. Например, «длина может быть 16».
деонтическая (deontic) модальность, относящаяся к обязыванию и дозволению. Например, «длина должна быть 16». Собственно, это и есть главная модальность “требований”, требования — это то, что должно быть, рекомендуется быть, разрешается быть, обязательно или необязательно и т.д.
темпоральная (temporal) модальность, связанная со временем. Например, «длина была 16 три года назад».
доксическая (doxastic) модальность, связанная с верой. «Я верю, что длина дана как 16». Доксическая модальность важна для квалификации (удостоверения того, что требования выполнены — вера в то, что система соответствует её определению).

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

Требования связаны с инженерными обоснованиями: они переформулируются как «декларации» (claim) разработчиков о соответствии — т.е. «я верю, что длина равна 16», а затем это высказывание доказывается по логическим правилам рациональной аргументации (помним, что логика — это дисциплина, занимающаяся правильностью рассуждений). Эти доказательства проводятся “как в суде” — и для этого даже заводится “дело” (assurance case, как раз от “судебного дела” — с вариантами dependability case, safety case, security case, requirement case, architectural quality case). Обзор по инженерным обоснованиям приведён тут.

Виды требований

Требования назначения (operational requirements) — относятся к назначению и целям создания системы. Совокупность этих требований должна описывать конечное состояние мира после того, как система будет развернута и начнет использоваться. Иногда их называют «требования к возможностям системы», «необходимые возможности». — требования, выведенные из портебностей стейкхолдеров после анализа потребностей.
Функциональные требования (functional requirements) — требования, определяющие функцию, которую должна быть способна выполнить система или элемент системы (ISO 24765) — требования, выведенные из сценариев использования. Самые распространённые практики инженерии требований — это выявление функций (поведения) системы из каких-то сценариев взаимодействия (user stories, use cases).
Требования к показателям функционирования (performance requirements) — описывают насколько хорошо система должна выполнять предъявленные к ней требования (минимальные числовые пороговые значения).
Требования к реализации (requirements) — требуемые характеристики и атрибуты физического воплощения системы и ограничения на ее конструкцию, внешний вид, общие свойства, вес, мощность, материал, ограничения на внешние интерфейсы.
Нефункциональные, “требования качества” (например, требованиям надёжности, ремонтопригодности, доступности, безопасности и т.д., так называемые “-ости”, по- английски это будут “ilities” — reliability, repairability, availability, safety, etc.).

Свойства качества (внешние)

Подробнее про требования защитоспособности (выделенные на рисунке выше) можно посмотреть в презентации Дональда Файерсмита — и там же можно посмотреть на презентацию по целеориентированной инженерии требований Яна Александера.

Стандарты представления требований

SysML
AP 233
RIF
ISO 29148
ITU Z.151 (URN=GRL+UCM)
другие языки из подхода GORE: выражение оппозиции цели-средства (ends – means)

i*
RFLP
ArchiMate
MBRD
OMG BMM
Planguage

Практики ЖЦ требований по ISO 15288

Жизненный цикл требований стейкхолдеров

Подготовиться (идентифицировать стейкхолдеров, определить стратегию определения потребностей стейкхолдеров и требований, получить или купить обеспечивающую систему и сервисы)
Определить потребности стейкхолдеров (определить контекст использования, идентифицировать потребности стейкхолдеров, приоритизировать и отобрать потребности, определить потребности стейкхолдеров и их обоснование)
Разработать Концепцию функционирования (operational concept) и другие концепции жизненного цикла (определить набор сценариев, определить взаимодействия пользователей и системы)
Преобразовать потребности стейхколдеров в требования стейкхолдеров (идентифицировать ограничения на инженерные решения, идентифицировать требования стейкхолдеров и все функции для требований качества, гармонизировать требования стейкхолдеров)
Анализировать требования стейкхолдеров (анализировать полное множество требований стейкхолдеров, определить критические показатели результативности, которые позволят оценить технические достижения, получить обратную связь от стейкхолдеров – валидировать, устранить все проблемы и противоречия со стейкхолдерами)
Управлять определением потребностей стейкхолдеров и требованиями (получить явное согласие на требования стейкхолдеров, поддерживать трассировку потребностей и требований, обеспечивать сведения по базисам)

Жизненный цикл требований к системе

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

Рабочие продукты требований

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

разделе “технические требования” технических заданий (хотя “техническое задание” чаще всего подробно перечисляет работы — “задание на работы”, а не требования, но всё-таки какое-то описание целевой системы как “чёрного ящика” это описание содержит);
документе “Опросный лист” (который посылается, чтобы опросить потенциальных поставщиков инженерных решений и содержит как раз основные требования к поставляемой системе);
посылаемом в ответ на “Опросный лист” документе “Технико-коммерческие предложения”;
Различных стандартах, некоторые из которых называются “технические условия” (т.е. даже в названиях они не содержат слова “стандарт” или “требования”).

Важно понимать, что:

требования системной инженерии — определения “чёрного ящика”, которые могут даже не содержать слово “требования” в своих рабочих продуктах и не содержать слов, обозначающих деонтическую модальность — быть без слов “должно”, “возможно”, “обязательно” и т.д.
требования совсем необязательно являются бумажными документами-текстами. Они вполне могут храниться в какой-то БД (в рамках какой-то “информационной системы управления требованиями” — DOORS, IRQA и т.д.) в виде отдельных пронумерованных текстовых описаний или в виде компьютерной модели, численной или логической.

Управление требованиями и инженерия требований

Управление требованиями — дисциплина инженерного менеджмента (логистическая, “инженерного документооборота”), она заключается в том, чтобы предоставить средства хранения требований и сообщения о них всем тем, кто в них нуждается. Для того, чтобы управлять требованиями, нужно их сначала иметь.
Инженерия требований — это поддисциплина системной инженерии, занимается разработкой требований. Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания “чёрного ящика”.

Требования к требованиям

Требования к требованиям по ISO 29148

Требования к группе требований:

Полнота (complete)
Согласованность с другими (consistent)
Выполнимость (affordable, проходимы по бюджетам и срокам)
Ограниченность (bounded)

Требования к одному требованию:

Необходимость (necessary) — Требование представляет определённую заинтересованным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятию требования.
Абстрактность (abstract) —
Недвусмысленность (unambiguous) — Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено.
Согласованность с другими (consistent) — Требование не противоречит другим требованиям и полностью соответствует внешней документации.
Полнота (complete) — Требование полностью определено в одном месте и вся необходимая информация присутствует.
Лаконичность (concise) — Требование не может быть разбито на ряд более детальных требований без потери завершённости.
Достижимость (feasible) — Требование может быть реализовано в пределах проекта.
Трассируемость (traceable) — Связь с вышестоящими и нижестоящими требованиями.
Проверяемость (verifiable) — Реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ.

Другое

Единичность — Требование описывает одну и только одну вещь.
Актуальность — Требование не стало устаревшим с течением времени.

Состояния

OMG Essence определяет следующие состояния для альфы «Требования» и контрольные вопросы для проверки каждого состояния:

❑ Стейкхолдеры, которые будут использовать новую систему, определены.

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

❑ Есть ясная возможность, которую будет адресовывать новая система.

❑ Стейкхолдеры согласны с назначениемновой системы.

❑ Ясно, что будет считаться успехом для новой системы.

❑ Стейкхолдеры имеют одинаковое понимание пределов предлагаемого решения.

❑ Технология описания требований согласована.

❑ Механизмы управления требованиями наличествуют.

❑ Приоретизационная схема ясна.

❑ Ограничения определены и приняты во внимание.Допущения ясно сформулированы.

❑ Происхождение требований ясно.

❑ Обоснование требований ясно.

❑ Противоречивые требования идентифицированы и ими занимаются.

❑ Требования сообщают существенные характеристики поставляемой системы.

❑ Наиболее важные сценарии использования системы могут быть объяснены.

❑ Приоритетность требований ясна.

❑ Влияние реализации требований понимается.

❑ Команда понимает, что должно быть обеспечено и соглашается обеспечить это.

❑ Скорость изменений к согласованным требованиям относительно низка и под контролем.

❑ Польза, обеспечиваемая реализацией требований, ясна.

❑ Части возможности, удовлетворяемые требованиями, ясны.

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

❑ Набор реализованных единиц требований обеспечивает ясную пользу для стейкхолдеров.

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

❑ Нет никаких невыполненных единиц требований, которые не дают принять систему как полностью удовлетворяющую требованиям.

❑ Система, принята стейкхолдерами как полностью удовлетворяющая требованиям.

Страницы в категории «Требования»

Показаны 3 страницы из 3, находящихся в данной категории.

Источник: sewiki.ru

6 Основные требования, предъявляемые к современным операционным системам

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

ОС является обязательным компонентом любой вычислительной машины.
ОС должна быть достаточно прозрачной для разработчиков ПО.

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

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

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

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

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

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

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

-во первых, переносимый код может быть написан на том языке, который имеется на всех машинах на которые планируется переносить систему. Как правило С или Java.
-во вторых, важно то, в какое физическое окружение программы она должна быть перенесена. различие в битностях архитектуры требует различных решений при создании ОС. 32 битная адрессация ОС очень сложно портируется на 16 битную адрессацию…

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

С — стандартизованный язык высокого уровня. Компиляторы С есть почти во всех архитектурах.

Изоляция процесса — некоторые низкоуровневые части ОС должны иметь доступ к процессорно-зависимым структурам данных и регистрам.

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

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

Windows 11 Требования к системе

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

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

Надежность
Безопасность
Совместимости

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

Минимальные требования к системе и компьютер

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

Процессоры и ЦП (единицы центральной процессорной обработки): 1 Или быстрее с 2 или более ядер, которые отображаются в списке утвержденных ЦП. Процессор на компьютере будет основным фактором, определяющим запуск Windows 11. Скорость часов (1 Или более быстрая потребность) и количество ядер (2 или более) являются неотъемлемой частью процессора по мере его выпуска и не считаются обновляемыми компонентами.
ОЗУ: 4 ГБ. Если на компьютере менее 4 ГБ памяти, иногда можно параметров обновления для получения дополнительной ОЗУ. Обратитесь на веб-сайт изготовителя компьютера или у розничного продавца, чтобы узнать, доступны ли простые и доступные варианты, которые соответствуют минимальным требованиям Windows 11. служба хранилища: 64 ГБ или большее хранилище. Если на компьютере недостаточно большого дискового пространства, иногда есть варианты его обновления. Обратитесь на веб-сайт изготовителя компьютера или у розничного продавца, чтобы узнать, доступны ли простые и доступные варианты, которые соответствуют минимальным требованиям Windows 11. Программное обеспечение системы: UEFI (для единого extensible Firmware Interface, современной версии PC BIOS) и Secure Boot. Если ваше устройство не соответствует минимальным требованиям, так как оно не обеспечивает безопасную загрузку, ознакомьтесь с этой статьей, чтобы узнать, можно ли предпринять необходимые действия, чтобы включить эту возможность. Безопасная загрузка может быть включена только с помощью UEFI, и в этой статье вы сможете понять, какие параметры можно изменить, чтобы сделать это возможным. TPM:доверенный модуль платформы (TPM) версии 2.0. Если ваше устройство не соответствует минимальным требованиям из-за TPM, ознакомьтесь с этой статьей, чтобы узнать, можно ли предпринять меры для ее устранения. Видеокарты: Совместим с DirectX 12 или более поздней с драйвером WDDM 2.0. Отображения: Дисплей высокой четкости (720p), который больше 9″ по диагонали, 8 бит на цветной канал. Если размер экрана меньше 9″, предполагаемый пользовательский интерфейс Windows может быть не полностью виден. Подключение к Интернету и учетные записи Майкрософт: Windows 11 Для первого использования требуется подключение к Интернету и учетная запись Майкрософт.
Windows версии для обновления: Для обновления до Windows 10 версии 2004 или более поздней Windows устройства. Бесплатные обновления доступны в Windows в Параметры >обновления и безопасности.

Обновление: особые требования для S-режима

Для Windows 10 Pro, образования и Enterprise S-режим больше не доступен в Windows 11. Пользователям, которые хотят перейти на Windows 11, потребуется выйти из S-режима, и они не смогут снова переключиться обратно. Windows 10 Домашняя можно перейти Windows 11 для дома в S-режиме, не переходя из S-режима.

Инструкции по выходу из S-режима (которые нужно завершить до обновления):

На компьютере, на Windows 10 S-режиме, откройте Параметры > обновления активации.
Найдите раздел Перейти Windows 10 Домашняя или Перейти Windows 10 Pro, а затем выберите ссылку Перейти в Магазин.

Примечание: Не выбирайте ссылку в статье Обновление выпускаWindows. Это другой процесс, который позволит вам работать в S-режиме.