Системные требования и требования к программному обеспечению
Существуют различные трактовки понятия "Системные требования" (system requirements).
К. Вигерс формулирует данный термин, как "высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть системе" [2.2]. При этом под системой понимается программная, программно-аппаратная, либо человеко-машинная система. Данная система является сложной, структурированной системой и системные требования являются подмножеством функциональных требований к продукту. В данное подмножество целесообразно относить наиболее важные, существенные требования, которые относятся в целом к системе и не содержат избыточной детализации.
INCOSE (International Council on Systems Engineering) дает более детальное определение системы: "комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы". Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [2.8]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.
|
|
|
INCOSE (International Council on Systems Engineering) - Международный совет по системной инженерии, www.incose.org — некоммерческая организация, ставящая своей целью развитие системной инженерии и профессиональный рост системных инженеров. В настоящее время насчитывает более 8000 членов. Под эгидой INCOSE разработан ряд международных стандартов в области системной инженерии.
В практике компьютерной инженерии бытует другой, более узкий контекст использования данного понятия: под системными требованиями в узком смысле понимаются требования, выдвигаемые прикладной программной системой (в частности - информационной) к среде своего функционирования (системной, аппаратной). Пример таких требований - тактовая частота процессора, объем памяти, требования к выбору операционной системы.
Функциональные, нефункциональные требования и характеристики продукта
Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
|
|
|
Функциональные требования записываются, как правило, при посредстве предписывающих правил: "система должна позволять кладовщику формировать приходные и расходные накладные". Другим способом являются так называемые варианты использования (users cases) - популярный и весьма продуктивный способ представления требований.
Use case - вариант использования, прецедент. Данный термин был введен в обиход программной инженерии шведским учёным Айваром Якобсоном (Ivar Hjalmar Jacobson) и по сей день является одной из наиболее позитивных абстракций в области создания требований к программному обеспечению. Согласно нотации UML 2.4.1 (http://www.omg.org/spec/UML/2.4.1/), прецеденты являются средством для определения требуемых использований системы. Как правило, они применяются для извлечения требований к системе, то есть, того, что система предполагает делать. Основными понятиями, связанными с вариантами использования являются акторы, прецеденты, и объект. Объектом является рассматриваемая система, в которой применяются прецеденты. Пользователи и любые другие системы, которые могут взаимодействовать с объектом, представлены в качестве акторов. Акторы всегда моделируют сущности, находящиеся за пределами системы. Требуемое поведение объекта задается одним или несколькими вариантами использования, которые определяются в соответствии с потребностями акторов. Строго говоря, термин "вариант использования" относится к типу прецедента. Экземпляр прецедента относится к проявлению поведения, соответствующего типу прецедента. Такие случаи, как правило, описывается через спецификацию взаимодействий.
|
|
|
Это - основной, определяющий вид требований, который будет рассматриваться на протяжении всего лекционного курса.
Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2.2] выделяет следующие основные группы нефункциональных требований:
· Внешние интерфейсы (External Interfaces),
· Атрибуты качества (Quality Attributes),
· Ограничения (Constraints).
Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).
|
|
|
Основные атрибуты качества:
· Применимость,
· Надежность,
· Производительность,
· Эксплуатационная пригодность,
достаточно хорошо раскрыты в модели FURPS (см. ниже).
Ограничения [2.2] - формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. Выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам (конец цитаты).
Характеристики продукта. К.Вигерс [2.2] формулирует характеристику, "фичу" (feature), как набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели.
Существует и более общий взгляд на данное понятие [2.9]: "features могут быть как относящимися к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта".
С.Орлик в [2.6] отмечает, что "с точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными".
Роль характеристик проявляется в первую очередь в области маркетинга: не всякий потенциальный потребитель продукта станет читать его функциональные описания, а набор ключевых характеристик, характеризующих конкурентные преимущества, можно сделать лаконичным и уместить на одной странице рекламной листовки, либо напечатать на компакт-диске.
Классификация RUP
В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [2.1].
Акроним FURPS обозначает следующие категории требований:
· Functionality (Функциональность)
· Usability (Применимость)
· Reliability (Надежность)
· Performance (Производительность)
· Supportability (эксплуатационная пригодность).
Символ "+" расширяет FURPS-модель, добавляя к ней:
· ограничения проекта,
· требования выполнения,
· требования к интерфейсу,
· физические требования,
часть из которых уже была рассмотрена выше.
Кроме того, в спецификациях RUP выделяются такие категории требований, как
· требования, указывающие на необходимость согласованности с некоторыми юридическими и нормативными актами;
· требования к лицензированию,
· требования к документированию.
FURPS (Functionality Usability Reliability Performance Supportability: функциональность, удобство использования, надежность, производительность, удобство сопровождения)— классификация требований к программным системам, разработанная в Hewlett-Packard. Согласно классификации, все требования подразделяются на 5 категорий, непосредственно следующих из составляющих наименования классификации. В настоящее время используется, как составная часть более общей классификации FURPS+.
FURPS+ (Functionality Usability Reliability Performance Supportability +: функциональность, удобство использования, надежность, производительность, удобство сопровождения, дополнительные требования) — расширенная версия классификации требований FURPS. Дополнительно включает в себя ограничения, разделенные на следующие группы требований:
· ограничения проектирования (design);
· ограничения разработки (implementation);
· ограничения на интерфейсы (interface);
· физические ограничения (physical).
Используется в методологии RUP.
Подробно описана в работе Роберта Грейди.
Дата добавления: 2021-03-18; просмотров: 149; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!