Функциональные Нефункциональные

требования                                                  требования

 

Рис. 1.2. Уровни требований по Вигерсу

Рис.1.3. Программные требования

   Далее порядок изложения будет соответствовать рис. 1.3.

   На рисунке имеются 7 столбцов. Нумерацию будем вести слева направо и сверху вниз. Например блок 2.1 это «Модели процессов»  и т. д. Начнем с блока 1.       

         1. Основы программных требований

      (Software Requirements Fundamentals)

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

  

 

 

1.1 Определение требований (Definition of a Software Requirement).

    Здесь дается само понятие «требования», как такового, и отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования. Необходимо обратить внимание на следующие определения понятия «требование» (на основе стандарта IEEE Standard Glossary of Software Engineering Terminology, 1990):

· Условие или возможность, требуемые пользователем для решения задач или достижения целей. 

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

· Документальная репрезентация (зафиксированное представление, определение, описание) условий или возможностей, перечисленных в предыдущих пунктах. 

1.2 Требования к продукту и процессу (Product and Process Requirements).

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

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

1.3 Функциональные и нефункциональные требования (Functional and Non-functional Requirements).

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

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

 

 

1.3.1. Потребности – отражают проблемы бизнеса, а так же персоналии и процессы, которые должны быть соотнесены с приобретением и использованием системы.

1.3.2.  Группа функциональных требований, включает:

· Бизнес – требования – определяют высокоуровневые цели заказчика разрабатываемого программного обеспечения.

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

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

1.3.3. Группа нефункциональных требований, включает:

· Бизнес-правила связанные с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами, учетными практиками, алгоритмами вычислений и т.д.

  Часто можно видеть недостаточное внимание к такого  рода требованиям сотрудников ИТ - департаментов, в основном, технических специалистов, вовлеченных в проект. По сути, бизнес-правила определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса.

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

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

 

 

· Не следует путать «внешние интерфейсы»  и «пользовательские интерфейсы». Вопросы организации пользовательского интерфейса весьма важны в данной категории требований. Однако, «внешний интерфейс» это взаимодействие с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга эксплуатации – по сути взаимодействие с «внешним миром».  Функциональные же требования направлены на решение бизнес – потребностей, с пользовательским интерфейсом.

· Атрибуты качества – описывают дополнительные характеристики продукта в различных «измерениях», важных для пользователей и разработчиков. Атрибуты касаются вопросов согласованного подключения элементов системы, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.  

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

1.3.4. Системные требования.

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

    Необходимо сделать несколько важных замечаний по бизнес-правилам.

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

 

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

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

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

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

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

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

   Анализируя различные источники на предмет работы с features, следует отметить следующее:

· С точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными (в т.ч. с ограничениями проектирования или атрибутами качества).

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

  С одной стороны это может быть «список характеристик, указанный на коробке продукта» в случае создания «коробочного ПО», с другой стороны это может список высокоуровневых возможностей системы, например при заказной разработке ПО автоматизации бизнес-процессов конкретной организации.

· Features могут быть разного уровня детализации – от выражения высокоуровневых возможностей системы (например, «Расчет заработной платы …»), до достаточно конкретных требований (например, «Автоматическое уведомление Клиента по e-mail о резервировании товара на складе»).

 

1.4 Независимые свойства (Emergent Properties).                

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

 

Требования с количественной оценкой (Quantifiable Requirements).

  Это требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность «столько-то запросов в секунду».

  В то же время, важно понимать, что постановка вопроса (то есть формулирование требования) в форме «система должна обеспечить рост пропускной способности» без указания конкретных количественных характеристик является некорректно определенным требованием.

  Например, требование «система должна вести журнал подключений пользователей» может и должно детализироваться с точки зрения описания информации, которую необходимо сохранять в журнале, однако, такое требование уже не будет являться количественным требованием. А требование с формулировкой «система должна обладать интуитивно-понятным пользовательским интерфейсом» - непроверяемое.

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

  Например, в устах системного администратора специализированного программного обеспечения, привыкшего работать в командной оболочке Unix/Linux, объясняющего свои потребности аналитику, фиксирующему запросы пользователя и привыкшего оперировать Microsoft Office.

  Может ли такое требование быть переформулировано или детализировано для адекватности интерпретации?

Ответ - да.

Например, так – средний показатель ошибок оператора не должен превышать 2% от объема вводимой информации и 85% пользователей должны дать положительную оценку прототипу пользовательского интерфейса на этапе опытной эксплуатации.

Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с численными величинами – как часто? насколько быстро? в каком количестве? и т.п.

Большинство требований с количественной оценкой относится к атрибутам качества. В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту:

«Система должна производить поиск документов за время, не превышающее 5 секунд». Это типичное требование с количественной оценкой, в котором определена верхняя граница диапазона времени, за которое должен быть осуществлен поиск документов.

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

1.6 Системные требования и программные требования (System Requirements and Software Requirements).

  Данное разделение базируется на определении «системы», данном INCOSE (International Council on Systems Engineering) «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы».

Таким образом, подразумевается, что система является более емким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое. Отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности.

 

2. Процесс работы с требованиями (Requirements Process)

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

Цель данного раздела, в соответствии с SWEBOK, дать понимание того, что такое процесс работы с требованиями, как таковой. В русском языке, также используется название -   «процесс определения требований».

 

2.1 Модель процесса определения требований.

Основные свойства процесса следующие:

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

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

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

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

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

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

  2.2 Участники процессов (Process Actors).

  В этой теме вводится понятие «роли» и дается понимание «ролей» для людей, которые участвуют в процессе работы с требованиями. Таких людей также называют «заинтересованными лицами». Заинтересованное лицо – некто, имеющий возможность (в том числе, материальную) повлиять на реализацию проекта.

  Типичные примеры ролей:

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

 Заказчики (Customers) - те, кто отвечают за заказ программного обеспечения или, в общем случае, являются целевой аудиторией на рынке программного обеспечения (образуют целевой рынок ПО).

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

 Аналитики (Market analysts). Продукты массового рынка программного обеспечения ориентированы на широкий круг неперсонифицированных, не всегда высококвалифицированных лиц. Они не являются «заказчиками» в смысле «те, кто заказывает разработку».

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

 Регуляторы. Многие области применения («домены») являются регулируемыми, например, телекоммуникации или банковский сектор. Программное обеспечение для ряда целевых рынков (в первую очередь, корпоративного сектора) требует соответствия руководящим документам и прохождения процедур, определяемых уполномоченными органами – регуляторами. 

 Инженеры – программисты.

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

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

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