Определение требований к ПО

В данной статье представлено описание определения требований к ПО по Карлу Вигерсу.

Особенности интерпретации требований

В главе Вигерса по интерпретации требований имеется несколько определений для термина «Требование»:

1. Одно определение заключается в том, что требование — это «нечто такое, что определяет выбор дизайна». Такое определение предложил консультант Брайан Лоренс. Определение является неплохим, т.к. оно неформальное и в эту категорию можно отнести много видов информации.

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

3. И наиболее точное определение:

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

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

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

Некоторые типы требований и их определения:

1. Бизнес‑требование — Высокоуровневая бизнес‑цель организации или заказчиков системы

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

3. Ограничение — Ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта

4. Внешнее требование к интерфейсу — Описание взаимодействия между ПО и пользователем, другой программной системой или устройством

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

6. Функциональное требование — Описание требуемого поведения системы в определенных условиях

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

8. Атрибут качества — Вид нефункционального требования, описывающего характеристику сервиса или производительности продукта

9. Системное требование — Требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования

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

Уровни требований к ПО:

1. Бизнес‑требования. На данном уровне описывается причина по которой организация нуждается в такой системе, т. е. цели, которые необходимо достичь.

2. Пользовательские требования. На данном уровне описываются возможности, которые должны быть доступны в системе, которые в свою очередь должны приносить пользу кому‑то. Также, на данном уровне описываются атрибуты или характеристики продукта, которые важны для удовлетворения пользователей.

3. Функциональные требования. На данном уровне описываются описывается поведение продукта при тех или иных условиях. ФТ определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес‑требований. ФТ описываются в форме традиционных утверждений со словами «должен» или «должна».

Бизнес‑аналитик документирует функциональные требования в спецификации требования к ПО (software requirements specification, SRS), с необходимым уровнем детализации для описания ожидаемого поведения системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и в связанных с проектом функциях. Этот артефакт называют по‑разному: документ бизнес‑требований, функциональная спецификация, документ требований и т. п. Спецификация требований к ПО может представлять собой отчет, сгенерированный на основе информации, хранимой в средстве управления требованиями.

Термин «Системные требования» описывает требования к продукту, который содержит многие компоненты или подсистемы.

Бизнес‑правила (business rules) включают корпоративные политики, правительственные постановления, отраслевые стандарты и вычислительные алгоритмы.

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

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

К требованиям проекта относятся:

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

2. потребности в обучении персонала;

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

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

5. инфраструктурные изменения, которые необходимо внести в рабочую среду;

6. требования и процедуры для выпуска продукта, установки в рабочей среде, конфигурирования и тестирования;

7. требования и процедуры для перехода со старой на новую систему, например требования по переносу и преобразованию данных, по настройке безопасности, переносу производства и обучению для восполнения недостатка квалификации — это требования иногда называют требованиями по переходу (transition requirements) (IIBA 2009);

8. требования по сертификации продукта и его соответствия требованиям регулирующих органов;

9. скорректированные политики, процессы, организационные структуры и аналогичные документы;

10. сорсинг, приобретение и лицензирование ПО сторонних производителей и компонентов оборудования;

11. требования по бета‑тестированию, производству, упаковке, маркетингу и дистрибуции;

12. соглашения об уровне обслуживания с клиентами;

13. требования по правовой защите (патенты, товарные знаки или авторское право) интеллектуальной собственности, связанной с разрабатываемым ПО.