Разработка требований к ПО: общие понятия
Очень часто при внедрениях от клиента можно услышать фразы типа: «А как этого нет. Это же есть в ….. Я думал, что это само собой понятно. Я без этого не смогу нормально работать. Ваша система …..» Ну и дальше в таком роде. Справедливо ли это?
Наверное нет. Каждая система (в данном случае я говорю про ERP) содержит определенный функционал и может в себе не содержать некоторые «фичи» которые есть в других.
И когда начинается разработка или внедрение клиент должен озвучить все свои «хотелки» иначе существует риск, что что-то не будет реализовано и тогда пиши пропало.
Часть вины за это конечно лежит и на компании которая занимается разработкой или внедрением. Бизнес-аналитик (это человек который занимается сбором и обработкой требований) должен уметь задавать правильные вопросы и читать между строк. Клиент может и не сможет четко описать что он хочет и может ходить вокруг и около того, что ему действительно необходимо.
Стадия сбора требований как правило предшествует стадии разработки и внедрения. И именно на ней формируется scope проекта.
Содержание проекта (Project Scope) Работы, которые необходимо выполнить, чтобы получить продукт, услуги или результат с указанными характеристиками и функциями.
Содержание
1 Что же такое требование? Уровни и типы требований
2 Разработка и управление требованиями2.1 Выявление и сбор требований (elecitation)
2.2 Анализ требований
2.4 Утверждение требований
2.5 Управление требованиями
3 Основные проблемы при работе с требованиями3.1 Недостаточное вовлечение пользователей
3.2 Небрежное планирование
3.3 «Разрастание» требований пользователей
3.4 Двусмысленные требования
3.5 Требования -«бантики»
3.6 Противоречивые требования
Что же такое требование? Уровни и типы требований
Здесь и далее я буду опираться на определения из книги Карла Вигерса и Джоя Битти «Разработка требований к программному обеспечению»
Существует много определений данного понятия мы же остановимся на таком:
Требование — спецификация того, что должно быть реализовано. В них описано поведение системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы.
И давайте дадим определения терминов которые используються при классификации требований.
Словарик бизнес-аналитика
Бизнес-требование — высокоуровневая бизнес-цель организации или заказчиков системы. Оно должно отвечать на вопрос «Что?» и «Зачем?».
Бизнес-правило — политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. Это не требование к ПО, но оно служит источником нескольких типов требований к ПО.
Ограничение — ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта.
Внешнее требование к интерфейсу— описание взаимодействия между ПО и пользователем, другой программной системой или устройством.
Характеристика — одна или несколько логически связанных возможностей системы, которая представляет собой ценность для пользователя и описаны рядом функциональных требований.
Функциональное требование — описание требуемого поведения системы в определенных условиях.
Нефункциональное требование — описание свойства или особенности, которыми должна обладать система, или ограничение, которое должно соблюдаться.
Атрибут качества — вид нефункционального требования, описывающего характеристику сервиса или производительности продукта.
Системное требование — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
Пользовательское требование — задача, которую определенные классы пользователей должны иметь возможность выполнять в системе, или требуемый атрибут продукта.
Требования к ПО состоят из трех уровней:
- Бизнес-требования;
- Пользовательские требования;
- Функциональные требования.
Вдобавок к этому выделяют еще нефункциональные требования.
Давайте рассмотрим каждый уровень чуть более детальней.
Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые она планирует достичь с ее помощью. Как правило их высказывают те, кто финансирует проект. Пример бизнес-требования: «Есть необходимость вести учет взаиморасчетов с контрагентами в разрезе договоров».
Пользовательские требования (user requirements) описывают цели и задачи, которые пользователь должен иметь возможность выполнять с помощью продукта. Они описывают то, что пользователь должен иметь возможность делать с системой. Это по сути user stories и сценарии. Например: «Я как пользователь системы хочу иметь возможность быстро посмотреть остатки конкретного товара на складе и посмотреть историю его перемещений»
Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Такие требования описывают в форме традиционных утверждений со словами должен или должна. Например — «система должна в момент проведения в системе документов по взаиморасчетам с контрагентами (инвойс, банковская выписка) дать возможность указать договор по которому ведутся взаиморасчеты» или «система должна давать возможность пользователю выбрать место хранения при закупке товара, куда он будет оприходован» или «должна быть возможность указать в карточке сотрудника дату его рождения и система за 2 дня до его наступления должна высылать директору по персоналу об этом уведомление».
Как правило бизнес-требования и функциональные требования ложаться в основу технического задания на разработку ПО.
Системные требования (system requirements) описывают требования к продукту, которые содержит многие компоненты или подсистемы (например рабочее место кассира, которое оборудовано сканером считывания штрих-кодов, весами, принтером и т.д.).
Бизнес-правила (business rules) — включают корпоративные политики, правительственные постановления, отраслевые стандарты и вычислительные алгоритмы. Они находятся за пределами любой системы ПО. Однако часто они накладывают ограничения на функции системы.
Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым»
Нефункциональные требования это чёткие критерии того, как система должна работать, в отличие от функциональных, которые описывают, что система должна делать. Давайте посмотрим на пример.
«API метод должен возвращать список ресторанов в короткой форме: id, название, адрес»
Это функциональное требование, оно описывает поведение системы.
«API метод должен отдавать данные не более чем за 200ms на 95 перцентиле и не более чем за 500ms на 99 перцентиле.»
А это уже нефункциональное требование, которое описывает определённый атрибут качества – performance.
Разработка и управление требованиями
Область разработки технических условий разделяется на разработку требований и управление требованиями. И начинается все с выявления требований.
Выявление и сбор требований (elecitation)
Этот этап включает в себя все действия, связанные с выявлением требований, таких как интервью, совещания, анализ документов, создание прототипов и другие. К ключевым действиям относятся:
- Определение классов ожидаемых пользователей продукта и других заинтересованных лиц;
- Понимание задач и целей, а также бизнес-целей, которым соответствуют эти задачи;
- Изучение среды, в которой будет использоваться новый продукт;
- Работа с отдельными людьми для пониманиях их потребностей и ожидания в отношении качества.
Анализ требований
Этот этап подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основными действиями на этом этапе будут:
- анализ информации и отделение функциональных требований от нефункциональных, бизнес-правил, предпологаемых решений и другой информации;
- разложение высокоуровневых требований до нужного уровня детализации;
- выведение функциональных требований из информации других требований;
- распределение требований по компонентам ПО;
- согласование приоритетов реализации;
- понимание относительной важности атрибутов качества;
- выявление пробелов в требованиях или излишних требований, не соответствующих заданным рамкам.
Документирование
Представление и хранение знаний о требованиях определенным способом. Например в письменные требования, диаграмы пригодные для дальнейшего использования.
Утверждение требований
На этом этапе подтвержается правильность имеющегося набора требований, которые позволят реализовать решение, удовлетворяющее бизнес-целям.
Нельзя создать идеальные требования. Если смотреть с практической точки зрения, то цель разработки требований — накопить общее понимание требований необходимое для разработки очередной порции продукта.
Управление требованиями
Это процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.
Цель управления требованиями состоит в том, чтобы гарантировать, что организация документирует, проверяет и удовлетворяет потребности и ожидания её клиентов и внутренних или внешних заинтересованных лиц. Управление требованиями начинается с выявления и анализа целей и ограничений клиента. Управление требованиями, далее, включает поддержку требований, интеграцию требований и организацию работы с требованиями и сопутствующей информацией, поставляющейся вместе с требованиями.
Установленная таким образом отслеживаемость требований используется для того, чтобы уведомлять заинтересованных участников об их выполнении, с точки зрения их соответствия, законченности, охвата и последовательности. Отслеживаемость также поддерживает управление изменениями как часть управления требованиями, так как она способствует пониманию того, как изменения воздействуют на требования или связанные с ними элементы, и облегчает внесение этих изменений.
Управление требованиями включает общение между проектной командой и заинтересованными лицами с целью корректировки требований на протяжении всего проекта. Постоянное общение всех участников проекта важно для того, чтобы ни один класс требований не доминировал над другими. Например, при разработке программного обеспечения для внутреннего использования у бизнеса могут быть столь сильные потребности, что он может проигнорировать требования пользователей, или полагать, что созданные сценарии использования покроют также и пользовательские требования.
Основные проблемы при работе с требованиями
Выявление требований непростой процесс. Проблему усугубляет то, что заказчик может говорить о чем угодно, но только не о том, что ему действительно нужно. Основное следствие проблем с требованиями — переделка того, что вы думаете что уже готово (на это расходуется от 30 до 50% общего бюджета разработки). С ростом объема переделок растет и растрата ресурсов и разочарования.
Создание более качественных требований это инвестиции, а не затраты.
Недостаточное вовлечение пользователей
Заказчики зачастую не понимают всю важность этапа сбора требований и обеспечения их качества. Это влечет за собой обнаружение ошибок в требованиях на поздних стадиях проекта ну и соответственно к задержке завершения проекта.
Еще существует риск того, что бизнес-аналитик может не понять и неправильно задокументировать бизнес-требования или потребности клиента. Иногда бизнес-аналитик может идти по пути определения «идеальных» бизнес-требований, которые реализуют разработчики. Но потом этим решением не пользуются.
Небрежное планирование
Неопределенные, плохо понятые требования порождают слишком оптимистические оценки, которые возвращаются и не дают нам покоя, когда возникает перерасход.
«Разрастание» требований пользователей
В процессе разработки требований scope проекта может разрастаться невиданными темпами и соответственно это увеличивает бюджет проекта и его сроки завершения. Менеджер проекта должен предусмотреть «буферы планирования». Если на проекте применяются гибкие методологии его ведения, то новые требования помещаются в резерв (беклог). Такие изменения могут быть важны, но они всегда имеют свою цену.
Двусмысленные требования
Признаком этого может быть то, что одно и тоже требование может пониматься по разному. Следствием этого является наличие разных ожиданий и удивление полученному результату.
Требования -«бантики»
Разработчики в процессе разработки могут добавлять функции, которые отсутствуют в спецификации и это может привести к проблемам. Задача команды реализующих требования — четко соблюдать требования спецификации, а не своевольничать.
Противоречивые требования
Бывает, что какие-то конкретные два или более требования противоречат друг другу. Иногда “совсем”, что никак нельзя совместить. Иногда всё-таки можно предусмотреть “разные режимы”, в каждом из которых одно требование удовлетворяется, а другое при этом оказывается недоступно. Или решить какую-то из задач другим способом — тогда противоречие исчезнет.
Чтобы продвинуться в сторону решения, нужно начать разматывать цепочку “для чего / почему”. По каждому из требований (как было описано в первой части статьи). То есть мы должны понять как можно глубже, из чего возникли именно такие требования, и что люди, пришедшие с этими требованиями, хотят “на самом деле”.
Выводы
Работа с требованиями может иногда казаться излишней и такой которая не повышает рентабельность проекта. Многие живут в реальности, что самое главное — это разработка и разработчики это самые нужные люди в компании (наверное поэтому у них такие большие зарплаты), но кому нужна разработка если она никому не нужна. Если неправильно сформирован scope проекта и возникают постоянные переработки, то кому от этого будет хорошо даже если за весь этот банкет платит заказчик. Та что тут говорить, если во многих компаниях даже нет такой позиции как бизнес-аналитик, его роль совмещает в себе проджект менеджер или разработчик.
Инвестиция в качественный сбор и оформление требований может принести следующие выгоды:
- меньше деффектов в требованиях и в готовом продукте;
- меньше ненужных функций;
- меньше расползания границ проекта;
- меньше беспорядка;
- продукты которые делаю то, что нужно.
Источник: biconsult.ru
О важности системных требований
Часто ли мы изучаем системные требования прежде,чем ставим какую-то новую программу? А стоило бы – это избавит от многих проблем.
Rodion Nagornov
Мы уже изучили такой замечательный документ, как Лицензионное соглашение к нашему продукту. Что же, настало время ознакомиться с другим, не менее важным, но еще более часто игнорируемым — Системными требованиями к продукту.
Нарушение Лицензионного соглашения приводит к довольно очевидным проблемам с лицензией, а вот несоблюдение системных требований порождает много технических проблем, не все из которых легко диагностировать. Особенно это касается процесса установки и взаимодействия с другими приложениями (в первую очередь с браузерами).
Несоблюдение системных требований порождает много технических проблем.
Нередко встречается интересное мнение по поводу системных требований. Звучит оно примерно так: «Я заплатил за программу деньги, а ваша обязанность после этого — сделать так, чтобы она работала. И какая вообще разница, что у меня за компьютер?» Возможно, подобное мнение имеет право на жизнь в каких-то других областях рынка, но абсолютно неприемлемо в сфере компьютерных технологий.
Это касается не только антивирусов, но и любых других приложений: игр, графических редакторов, почтовых клиентов, браузеров… Разработчики каждого приложения заранее предупреждают, что их программа сможет корректно работать только в оговоренных условиях. При их несоблюдении ответственность за некорректную работу продукта с производителя снимается.
Если вы приобретаете приложение, заведомо зная (или не озаботившись предварительно проверить), что ваш компьютер не соответствует системным требованиям приложения, то разработчики не виноваты в возникающих из-за этого проблемах. Необходимость соблюдать указанные характеристики не зависит от уровня вашей компьютерной грамотности, наличия/отсутствия свободного времени/желания что-то изменять в своем компьютере или заплаченных за программу денег. Это просто безусловная необходимость в сфере цифровых технологий, аналогичная необходимости спать и питаться для сохранения работоспособности человека. Ее нужно принять за аксиому.
Где можно ознакомиться с системными требованиями к нашим антивирусам? Конечно же, удобнее всего сделать это в Интернете. Например, раздел каждого продукта включает в себя страницу с системными требованиями. Кроме того, их можно найти в интернет-магазине на нашем официальном сайте, а также на сайтах наших официальных партнеров.
Если же вы предпочитаете покупать лицензии в обычных магазинах, то системные требования в полном объеме напечатаны на коробке с диском. Не постесняйтесь перед приобретением покрутить ее в руках и сравнить характеристики вашего компьютера и минимальные системные требования. Это избавит вас от большей части возможных технических проблем в дальнейшем.
Думаю, следует разобрать ключевые позиции системных требований, на которые прежде всего следует обратить внимание. В качестве примера используем системные требования к свежей версии Kaspersky Internet Security — http://support.kaspersky.ru/kis2014#requirements
На картинке я выделил требования, наиболее часто не соблюдаемые нашими пользователями. Начнем с операционных систем.
Пожалуй, самое важное правило, которое мне хотелось бы донести: наши приложения устанавливаются только на официально выпущенные в релиз версии операционных систем.
Пожалуй, самое важное правило, которое мне хотелось бы донести, прежде всего до продвинутых пользователей: наши приложения устанавливаются только на официально выпущенные в релиз версии операционных систем. Ваше стремление установить себе самую свежую версию Windows, чтобы испытать ее новые возможности, вполне объяснимо и понятно, однако установить на предварительную версию операционной системы продукт «Лаборатории Касперского» не получится. Все поддерживаемые версии системы перечислены в системных требованиях. Это, кстати, объясняет, почему данная лицензия неприменима на Mac или Android.
Кроме собственно версии Windows следует обращать внимание на Service Pack, установленный на вашем компьютере. Service Pack — это крупное обновление системы, которое включает в себя исправление множества критических ошибок. Все они находятся в свободном доступе на сайте Microsoft, поэтому проблем с их получением и установкой возникать не должно. Очень часто проблемы с установкой антивируса (особенно у пользователей Windows XP SP2) решаются установкой SP3.
Если посмотреть на строчку «1 Гб свободной оперативной памяти», то следует обратить особое внимание на слово «свободной». Оно указывает на то, что в каждый конкретный момент времени (а особенно в периоды обновления и проверки) на компьютере должно быть свободно более 1 Гб оперативной памяти. Заметьте, не всего, а свободно.
Если на вашем компьютере установлена Windows 7, а оперативной памяти всего 2 Гб, то минимум половина из них будет занята системными процессами. Если включить еще пару ресурсоемких приложений (например, Photoshop), то для корректной работы антивируса ресурсов не останется, система начнет тормозить, зависать, падать в «синий экран смерти» и вообще вести себя не самым приятным образом. Поможет в таком случае физическое увеличение объема оперативной памяти. Не считайте это лишней тратой денег — это в любом случае полезно!
480 Мб свободного места на жестком диске — это минимальный объем, который необходим для установки антивируса. Разумеется, неплохо иметь еще минимум 5-10 Гб сверх этого, опять же, чтобы избежать торможения системы.
Одна из наиболее обсуждаемых сейчас на форумах тем — невозможность работы наших продуктов без подключения к Интернету. Однако, если проследить историю развития антивирусов, можно заметить, что это системное требование остается неизменным как минимум с версии антивируса 6.0. То есть оно не появилось вот так вот вдруг, ни с того ни с сего.
Наши приложения действительно не могут быть активированы без подключения к Сети. Также у вас не будет возможности получать обновления и часть защиты, обеспечиваемой с помощью «облачных» технологий. И способа обойти это ограничение тоже нет.
Начиная с этого года интерфейс наших приложений реализован с помощью технологий .NET Framework. Даже если его нет на вашем компьютере, наш продукт установит его самостоятельно. Однако, если в процессе возникнут какие-то трудности, вы будете извещены об этом. Тогда придется скачать и установить .NET вручную.
Ну и напоследок еще одна животрепещущая тема — совместимые версии браузеров. Два наиболее частых вопроса, которые встречаются по этому поводу: «Почему Анти-Баннер не работает после обновления Firefox?» и «Когда он заработает?». Отвечаю. В системных требованиях перечислены все поддерживаемые версии браузеров.
Если версия вашего браузера в этом списке отсутствует, то Анти-Баннер не работает именно по этой причине. Список совместимых браузеров изменяется и дополняется с выходом новых патчей к нашим антивирусам. Соответственно, ответ на второй вопрос: Анти-Баннер заработает после выхода нового патча.
На этом, думаю, можно закончить сегодняшний обзор. Надеюсь, мне удалось убедить вас в необходимости читать системные требования до покупки приложений, а не после возникновения трудностей. Приятного и беспроблемного пользования нашими антивирусами!
Источник: www.kaspersky.ru
Системные требования и требования к ПО
Системные требования являются подмножеством функциональных требований к ИС. Это наиболее важные, существенные требования, которые относятся в целом к системе и не содержат избыточной детализации.
-общие системные требования к ИС
-требования к ПО, как подмножеству системных требований, направленных исключительно на программные компоненты системы
В практке компьютерной инженерии бытует более узкий подход: под системными требованиями понимаются требования, выдвигаемые прикладной программной системой (в частности — информационной) к среде своего функционирований (системной, аппаратной).
Пример таких требований:
— тактовая частота процессора
-требования к выбору ОС и т.д.
Найдите 2 минуты и прочитайте про:
Мышление Мышление – это психический познавательный процесс обобщенного и опосредованного отражения предметов и явлений объективного мира.
Маркетинговое исследование Статья создана: 25 ноября 2009 | Маркетинговые исследования и анализ Маркетинговое исследование — это систематизированный сбор.
ЗАПОЛНЕНИЕ МЕДИЦИНСКОЙ ДОКУМЕНТАЦИИ МЕДСЕСТРОЙ ПРИЕМНОГО ОТДЕЛЕНИЯ 1. Журнал ЭКСТРЕННОЙ (срочной!) госпитализации пациента — Ф.И.О. пациента.
Профессиональная этика Кодексы профессиональной этики: история и современность. https://studopedia.ru/17_167099_sistemnie-trebovaniya-i-trebovaniya-k-po.html» target=»_blank»]studopedia.ru[/mask_link]
Системные Требования
Для эффективного использования все компьютерное программное обеспечение требует присутствия на компьютере определенных аппаратных компонентов или других программных ресурсов . [1] Эти предварительные условия известны как (компьютерные) системные требования. и часто используются в качестве руководства, а не абсолютного правила.
Большинство программ определяет два набора системных требований: минимальные и рекомендуемые. С увеличением потребности в более высокой вычислительной мощности и ресурсах в новых версиях программного обеспечения системные требования со временем имеют тенденцию к увеличению. Отраслевые аналитики предполагают, что эта тенденция играет большую роль в обновлении существующих компьютерных систем, чем в технологических достижениях. Второе значение термина «системные требования» представляет собой обобщение этого первого определения, дающее требования, которые должны быть выполнены при проектировании системы или подсистемы.
- 1 Рекомендованные системные требования
- 2 Аппаратные требования
- 2.1 Архитектура
- 2.2 Вычислительная мощность
- 2.3 Память
- 2,4 Вторичное хранилище
- 2,5 Адаптер дисплея
- 2,6 Периферия
- 3.1 Платформа
- 3.2 API и драйверы
- 3.3 веб-браузер
Рекомендуемые системные требования [ править ]
Часто производители игр предъявляют потребителю набор требований, отличных от тех, которые необходимы для запуска программного обеспечения. Эти требования обычно называют рекомендуемыми требованиями. Эти требования почти всегда значительно выше, чем минимальные требования, и представляют собой идеальную ситуацию для запуска программного обеспечения. Вообще говоря, это лучший ориентир, чем минимальные системные требования, чтобы иметь полностью удобную и приятную работу с этим программным обеспечением.
Требования к оборудованию [ править ]
Наиболее распространенным набором требований, определяемых любой операционной системой или программным приложением , являются физические ресурсы компьютера, также известные как оборудование . Список требований к оборудованию часто сопровождается списком совместимости оборудования (HCL), особенно в случае операционных систем. В списке HCL перечислены проверенные, совместимые, а иногда и несовместимые аппаратные устройства для конкретной операционной системы или приложения. В следующих подразделах обсуждаются различные аспекты требований к оборудованию.
Архитектура [ править ]
Все компьютерные операционные системы предназначены для конкретной компьютерной архитектуры . Большинство программных приложений ограничены конкретными операционными системами, работающими на определенных архитектурах. Хотя существуют независимые от архитектуры операционные системы и приложения, большинство из них необходимо перекомпилировать для работы на новой архитектуре. См. также список распространенных операционных систем и поддерживаемых ими архитектур.
Вычислительная мощность [ править ]
Мощность центрального процессора (ЦП) является фундаментальным системным требованием для любого программного обеспечения. Большинство программ, работающих на архитектуре x86 , определяют вычислительную мощность как модель и тактовую частоту процессора. Многие другие характеристики ЦП, влияющие на его скорость и мощность, такие как скорость шины , кеш -память и MIPS , часто игнорируются. Это определение мощности часто ошибочно, поскольку процессоры AMD Athlon и Intel Pentium с одинаковой тактовой частотой часто имеют разную пропускную способность. Интел пентиум Процессоры пользовались значительной популярностью и часто упоминаются в этой категории. [ нужна ссылка ]
Память [ править ]
Все программное обеспечение при запуске находится в оперативной памяти (ОЗУ) компьютера. Требования к памяти определяются после рассмотрения требований приложения, операционной системы, вспомогательного программного обеспечения и файлов, а также других запущенных процессов. При определении этого требования также учитывается оптимальная производительность другого несвязанного программного обеспечения, работающего в многозадачной компьютерной системе.
Дополнительное хранилище [ править ]
Требования к устройству хранения данных различаются в зависимости от размера установки программного обеспечения, временных файлов, создаваемых и поддерживаемых при установке или запуске программного обеспечения, а также возможного использования пространства подкачки (при недостатке ОЗУ).
Адаптер дисплея [ править ]
Программное обеспечение, требующее отображения компьютерной графики лучше среднего , например графические редакторы и высококачественные игры , часто определяет высокопроизводительные видеоадаптеры в системных требованиях.
Периферийные устройства [ править ]
Некоторым программным приложениям необходимо широко и/или специально использовать некоторые периферийные устройства , требуя более высокой производительности или функциональности таких периферийных устройств. К таким периферийным устройствам относятся дисководы CD-ROM , клавиатуры , указывающие устройства , сетевые устройства и т. д.
Требования к программному обеспечению [ править ]
Требования к программному обеспечению касаются определения требований к программным ресурсам и предварительных требований, которые необходимо установить на компьютер для обеспечения оптимальной работы приложения. Эти требования или предварительные условия обычно не включены в пакет установки программного обеспечения и должны быть установлены отдельно перед установкой программного обеспечения.
Платформа [ править ]
Вычислительная платформа описывает своего рода структуру , аппаратную или программную , которая позволяет программному обеспечению работать. [2] Типичные платформы включают в себя архитектуру компьютера , операционную систему или языки программирования и их библиотеки времени выполнения .
Операционная система является одним из требований, упомянутых при определении системных требований (программного обеспечения). Программное обеспечение может быть несовместимо с разными версиями одной и той же линейки операционных систем, хотя часто сохраняется некоторая мера обратной совместимости. Например, большая часть программного обеспечения, разработанного для Microsoft Windows XP , не работает в Microsoft Windows 98 , хотя обратное не всегда верно. Точно так же программное обеспечение, разработанное с использованием новых функций ядра Linux версии 2.6, обычно не работает или компилируется должным образом (или вообще не компилируется) в дистрибутивах Linux, использующих ядро версии 2.2 или 2.4.
API и драйверы [ править ]
Программное обеспечение, широко использующее специальные аппаратные устройства, такие как высококачественные видеоадаптеры , требует специального API или более новых драйверов устройств. Хорошим примером является DirectX , представляющий собой набор API для обработки задач, связанных с мультимедиа, особенно с программированием игр, на платформах Microsoft .
Веб-браузер [ править ]
Большинство веб-приложений и программного обеспечения в значительной степени зависят от веб-технологий , чтобы использовать браузер по умолчанию, установленный в системе. Microsoft Internet Explorer — часто используемое программное обеспечение, работающее в Microsoft Windows , которое использует элементы управления ActiveX , несмотря на их уязвимости.
Прочие требования [ править ]
Некоторое программное обеспечение также имеет другие требования для правильной работы. Яркими примерами являются подключение к Интернету (тип и скорость) и разрешение экрана дисплея.
Примеры [ править ]
Ниже приведены несколько примеров определений системных требований для популярных компьютерных игр и тенденции постоянно растущей потребности в ресурсах:
Например, в то время как StarCraft (1998) требует:
| Windows 95 или NT или выше | |
| Процессор Pentium с тактовой частотой 90 МГц или выше | |
| 16 МБ ОЗУ | |
| доступно 80 МБ | |
| CD-ROM , 2x или выше | |
| DirectX 3.0 или выше |
Для Doom 3 (2004 г.) требуется:
| Windows 2000 / ХР | |
| Процессор Pentium 4 1,5 ГГц или Athlon XP 1500+ или выше | |
| 384 МБ ОЗУ | |
| 2,2 ГБ свободного места | |
| 8- кратный CD-ROM | |
| Аппаратный 3D-акселератор — минимум 64 МБ памяти DirectX 9.0b | |
| 16-битная звуковая карта, совместимая с DirectX 9.0b |
| Windows XP с пакетом обновления 3 (SP3), Windows Vista с пакетом обновления 2 (SP2), Windows 7 | |
| Core 2 Duo или Athlon X2 с тактовой частотой 2,4 ГГц | |
| 2 ГБ оперативной памяти | |
| 8 ГБ свободного места, 23,8 ГБ + 1 ГБ пространства подкачки | |
| Видеокарта , совместимая с DirectX 9.0c . Аппаратный 3D-акселератор — не менее 256 МБ памяти. | |
| Звуковая карта, совместимая с DirectX 9.0c |
| Windows 8.1 64-разрядная, Windows 8 64-разрядная, Windows 7 с пакетом обновления 1 (64-разрядная), Windows Vista с пакетом обновления 2 (64-разрядная) | |
| Core 2 Quad Q6600 с тактовой частотой 2,4 ГГц или AMD Phenom 9850 с тактовой частотой 2,5 ГГц | |
| 4 ГБ ОЗУ | |
| 65 ГБ свободного места | |
| Графический процессор , совместимый с DirectX 10 : GeForce 9800GT 1 ГБ или ATI Radeon HD 4870 1 ГБ | |
| звуковая карта, совместимая с DirectX 10 |
Смотрите также [ править ]
- Требование
- Анализ требований
- Спецификация требований к программному обеспечению
- Спецификация (технический стандарт)
- Спецификация системных требований (SyRS)
Ссылки [ править ]
- ^«Определение системных требований» . Техтермс.com . Проверено 23 января 2014 г. .
- ^«Определение платформы» . Техтермс.com . Проверено 23 января 2014 г. .
- ^«Системные характеристики ПК Grand Theft Auto V — поддержка Rockstar» . Игры Рокстар . Проверено 22 апреля 2015 г.
Источник: wikipredia.net