Бизнес пользовательские функциональные требования

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

Процесс (согласно ИСО 9000) — это совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы.

Сегодня исследование процессов организации невозможно представить себе без технологической поддержки, оказываемой CASE-средствами ( Computer Aided System Engineering ), реализующими различные методологии анализа и описания сложных систем.

Одной из наиболее широко распространенных методологий (и одновременно нотаций) является ARIS (ARchitecture of Integrated Information Systems).

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

Use Case VS User Story. Выбираем подход к специфицированию требований

Наиболее часто используемые типы моделей описаны ниже.

Диаграмма цепочки добавленного качества

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

Перечень основных объектов модели представлен в таблице 1.2.

Событийная цепочка процесса

Событийные цепочки процессов (Extended Event driven Process Chain Diagram, диаграмма eEPC) применяются для детального описания бизнес-процессов компании, упомянутых на VAD-диаграммах . Диаграммы содержат последовательность шагов и результатов их выполнения. Как правило, для каждого шага указываются исполнитель, входящие и исходящие документы (носители информации) и используемые информационные системы.

Перечень основных объектов модели представлен в таблице 1.3.

Организационная схема

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

Перечень основных объектов модели представлен в таблице 1.4.

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

Диаграмма носителей информации

Диаграмма носителей информации используется для построения классификации документов компании.

Перечень основных объектов модели представлен в таблице 1.5.

Диаграмма типа информационной системы

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

Перечень основных объектов модели представлен в таблице 1.6.

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

Основные понятия управления требованиями

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

Этап разработки разделяют на определение , анализ , документирование и оценку требований , в рамках которых осуществляют следующие действия:

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

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

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

К сожалению, не существует и единого определения требований. Так, например, согласно стандарту IEEE Standard Glossary of Software Engineering Terminology под требованиями понимаются:

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

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

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

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

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

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

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

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

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

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

Таблица 1.7. Пример таблицы требований к процессу№ требования Шаг процесса Описание Тип решения

—	—	—	—

Номер требования будет формироваться по следующим правилам:

• R — текстовая константа, обозначающая требование к системе;
• XX — группа бизнес-процессов ( PU — закупки, SA — сбыт, LO — склад);
• YY — уникальный номер требования в группе.

Источник: intuit.ru

Виды требований к программным продуктам

Публикую больше для себя, чтобы всегда было под рукой… Ничего нового вы для себя здесь не найдёте, но всё удобно и в одном месте..

Итак, IEEE Standard Glossary of Software Engineering Terminology определяет требования как:

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

Какие требования бывают

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

Бизнес-требования (business requirements)

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements)

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements)

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Системные требования (system requirements)

Системные требования (system requirements) – это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Бизнес-правила (business rules)

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

Нефункциональные требования

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

Характеристика продукта (feature)

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

Какими характеристиками должны обладать хорошие требования?

Характеристики качества превосходных требований:

– Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

– Корректность. Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.

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

– Необходимость. Каждое требование должно отражать возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения. Отследите каждое требование вплоть до стадии сбора мнений пользователей, когда выявлялись варианты использования,
бизнес-правила или другие источники.

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

– Однозначность. Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.

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

Какими характеристиками должны обладать спецификации требований?

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

– Полнота. Никакие требования или необходимые данные не должны быть пропущены.

– Согласованность. Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Несогласованность документов следует устранить до начала процесса разработки. Вы не всегда знаете, какое именно положение некорректно (если какое-то некорректно), пока не выполните исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен.

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

Источник: akiselev87.wordpress.com

18. Разработка требований к программному обеспечению. Выявление и анализ требований. Спецификации требований. Управление изменениями требований.

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

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

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

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

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользователь­ские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания вы­полняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы — проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

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

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

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

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

Пример. Пользовательские и системные требования

Пользовательские требования

1. ПО должно предоставить средство доступа к внешним файлам, созданным в других программах.

Спецификация системных требований

1. Пользователь должен иметь возможность определять тип внешних файлов.
2. Для каждого типа внешнего файла должно иметься соответствующее средство, при­менимое к этому типу файлов.
3. Внешний файл каждого типа должен быть представлен соответствующей пикто­граммой на дисплее пользователя.
4. Пользователю должна быть предоставлена возможность самому определять пикто­грамму для каждого типа внешних файлов.
5. При выборе пользователем пиктограммы, представляющей внешний файл, к этому файлу должно быть применено средство, ассоциированное с внешними файлами данного типа.

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

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

Выявление и анализ требований

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

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

Схема разработки требований

Разработка требований — это первая из основных фаз процесса создания программных сис­тем. Этот фаза состоит из следующих основных работ (рис. 5).

• Анализ предметной области. Позволяет выделить сущности предметной области, определить первоначальные требования к функциональности и определить грани­цы проекта.
• Анализ осуществимости. Должен выполняться для новых программных систем. На основании анализа предметной области, общего описания системы и ее назна­чения принимается решение о продолжении или завершении проекта.
• Формирование и анализ требований. Взаимодействуя с пользователями, обсуж­дая и анализируя с ними задачи, возлагаемые на систему, разрабатывая модели и прототипы, разработчики формулируют пользовательские требования.
• Документирование требований. Сформированные на предыдущем этапе пользо­вательские требования должны быть документированы. При этом нужно учесть, что основными читателями этого документа будут пользователи, поэтому основ­ными требованиями к нему будут ясность и понятность.
• Детализация требований. Разработчики детализируют требования пользователей, формируя более точные подробные системные требования.
• Согласование и утверждение требований. На этом этапе пользовательские и сис­темные требования должны быть оформлены в виде единого документа, содержа­щего все функциональные и нефункциональные требования. Такой документ, обычно, называется спецификацией требований. Спецификация требований долж­на удовлетворять следующим характеристикам качества: корректность, однознач­ность, завершенность и согласованность.

На этапе анализа разрабатываются пользовательские и системные требования к про­граммной системе, которые оформляются в виде единого документа — спецификации тре­бований, — являющегося формальным соглашением заказчика с разработчиком системы. Практика показывает, что требования к разрабатываемой программной системе часто из­меняются. Это обусловлено тем, что разработка программной системы довольно дли­тельный процесс, во время которого:

• понимание пользователями возможностей системы, решаемых ею задач, может из­мениться;
• происходят изменения в деловой среде, техническом, программном и другом обес­печении системы, которые должны быть учтены;

• понимание разработчиками поставленных перед ними задач меняется.

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

К действиям по управлению требованиями относятся:

• определение основной (базовой) версии спецификации требований для конкретной версии продукта;
• анализ предлагаемых изменений требований, оценка воздействия и стоимости каж­дого изменения до его принятия;

• включение одобренных изменений при помощи определенной процедуры;
• согласование плана проекта с требованиями;

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

В организации (или в проекте) должны быть определены действия по управлению требо­ваниями. Эти действия должны быть документированы и должны выполняться всеми уча­стниками проекта. При разработке процесса нужно определить:

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

• процесс передачи новых требований и изменений существующих требований заин­тересованным лицам;

• методы анализа влияния и стоимости внесения изменения.

Кроме этого описание процесса должно содержать определение участников проекта, от­ветственных за выполнение каждой конкретной задачи.

Минимальной единицей управления в спецификации требований является отдельное тре­бование, поэтому вопрос идентификации требования достаточно важен. Форма представления требования может быть различной (текстовая, графическая и т.д.), поэтому для идентификации требования обычно используют связанный с ним набор атри­бутов. Атрибутами могут быть: дата создания требования, номер текущей версии требо­вания, номер версии продукта, для которой предназначено требование, автор требования, ответственный за реализацию требования, состояние требования, происхождение и обос­нование требования, подсистема, для которой предназначено требование и т.д. Главное при выборе атрибутов, чтобы они однозначно идентифицировали требование и его со­стояние.

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

Таблица 1. Состояния требования

Определение

Требование запрошено авторизированным источником

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

Код, реализующий требование разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода.

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

Утвержденное требование удалено из базовой версии. Следует зафикси­ровать причины и лицо, принявшее это решение.

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

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

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

Диаграмма состояний для типового процесса внесения изменений в спецификацию приве­дена на рис. 6.

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

Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

1. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные вход­ные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых слу­чаях указывается, что система не должна делать.
2. Нефункциональные требования. Описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и тд.
3. Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не­функциональными.

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

• Группа функциональных требований

• Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.
• Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).
• Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

• Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
• Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
• Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
• Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . ), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.

Источник: skarlupka.ru