Опубликован: 18.06.2007 | Уровень: для всех | Доступ: свободно | ВУЗ: Сибирский федеральный университет (г. Красноярск)
Лекция 2:

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

< Лекция 1 || Лекция 2: 12 || Лекция 3 >

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

Существуют различные трактовки понятия "Системные требования" (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.

Подробно описана в работе Роберта Грейди.

Методологии и стандарты, регламентирующие работу с требованиями

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

1. Разработки IEEE:

  • IEEE 1362 "Concept of Operations Document".
  • IEEE 1233 "Guide for Developing System Requirements Specifications".
  • IEEE Standard 830-1998, "IEEE Recommended Practice for Software Requirements Specifications"
  • IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
  • IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.

2. Отечественные ГОСТ:

  • ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
  • ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
  • ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
< Лекция 1 || Лекция 2: 12 || Лекция 3 >
Ринат Гатауллин
Ринат Гатауллин

Здравствуйте. Интересует возможность получения диплома( https://intuit.ru/sites/default/files/diploma/examples/P/955/Nekommerch-2-1-PRF-example.jpg ). Курс пройден. Сертификат не подходит. В сертификате ошибка, указано по датам время прохождения около 14 дней, хотя написано 576 часов.

Аминат Албакова
Аминат Албакова

Здравствуйте, я прошла весь курс, но нигде не указано, что курс завершился удачно или что-то в этом роде, не знаю что делать, как получть диплом в электронном виде?