Функциональных требований к нему он. Определение модели "UseCaseModel"

Требования к ПС

Требование – это характеристика или условие, которому должна удовлетворять ПС.

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

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

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

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

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

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

Цели анализа и моделирования требований

Целями анализа и моделирования требований являются:

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

• Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований.
• Разработчик ВИ – специалист организации-разработчика, который детализирует и уточняет модели требований.
• Заинтересованные лица – люди, предоставляющие информацию.
• Эксперт – представитель заказчика, участвующий в разработке модели требований.
• Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС.

Артефакты

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

• Предварительное соглашение – текстовый документ, который описывает, что будет включено в ПС и что решено исключить, то есть, он ограничивает системную функциональность. В нем отражаются пожелания заинтересованных лиц, а также указываются основные нефункциональные требования (например, описывается платформа реализации, точность вычислений, время отклика).
• Модель требований служит для достижения соглашения между заказчиком и разработчиками, давая возможность заказчику убедиться в том, что система будет делать то, что они ожидают, а разработчикам создать то, что требуется. Модель требований позволяет, во-первых, установить иерархию требований, что способствует лучшему пониманию человеком, во-вторых, дает наглядное графическое представление требований и зависимостей между ними, в третьих позволяет связать графическую форму представления с текстовой. Модель включает актеров и ВИ, показывает, как система взаимодействует с актерами и что она делает в каждом ВИ.
• Спецификация требований (Software Requirements Specification) – основной документ, используемый при проектировании и разработке ПС. Она включает модель требований и дополнительные спецификации, которые представляют собой текстовое описание требований к конечному продукту, но не к процессу его разработки и не содержат деталей реализации требований.
• Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса пользователя с ПС.
• Глоссарий – текстовый документ, содержащий определения основных понятий и терминов, которые должны одинаково пониматься заказчиком и разработчиком. Источниками данных для создания перечисленных артефактов могут, в частности, служить артефакты, созданные при бизнес-анализе (см. статью «RUP. Обследование организации (бизнес-анализ)».

В процессе анализа и моделирования требований можно выделить несколько основных этапов (см. рис.1).

Начало анализа.

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

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

Построение модели требований

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

Если число ВИ слишком велико, то для упрощения читаемости и поддержки модели целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Пакеты позволяют организовать иерархию требований. Верхний уровень иерархии обычно определяется, исходя из основных видов деятельности организации. Если был выполнен бизнес-анализ, то основные виды деятельности уже представлены в бизнес-модели в виде пакетов, и они могут быть просто скопированы в модель требований. Пакетов верхнего уровня не должно быть много. Целесообразно выделить пакет администрирования и пакет вспомогательных действий, и 2 – 4 пакета, основных видов деятельности. В свою очередь, пакеты верхнего уровня могут включать пакеты следующего уровня и т. д.

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

Детализация модели требований

Цели данной деятельности:

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

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

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

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

Составление дополнительных спецификаций

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

Проектирование пользовательского интерфейса

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

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

Создание спецификации требований

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

требования к программному обеспечению - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN software requirement … Справочник технического переводчика

ГОСТ Р 53195.4-2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению - Терминология ГОСТ Р 53195.4 2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению оригинал документа: 3.1 анимация (animation): Имитация работы программного… …

ГОСТ Р 52980-2008: Системы промышленной автоматизации и их интеграция. Системы программируемые электронные железнодорожного применения. Требования к программному обеспечению - Терминология ГОСТ Р 52980 2008: Системы промышленной автоматизации и их интеграция. Системы программируемые электронные железнодорожного применения. Требования к программному обеспечению оригинал документа: 3.1 автоматическая локомотивная… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 8.654-2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения - Терминология ГОСТ Р 8.654 2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения оригинал документа: 3.18 алгоритм хэширования: Алгоритм, который сжимает… … Словарь-справочник терминов нормативно-технической документации

МИ 2891-2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений - Терминология МИ 2891 2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений: Данные измерительная информация, представленная в виде, пригодном для передачи, интерпретации или обработки. Определения термина из… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 8.674-2009: Государственная система обеспечения единства измерений. Общие требования к средствам измерений и техническим системам и устройствам с измерительными функциями - Терминология ГОСТ Р 8.674 2009: Государственная система обеспечения единства измерений. Общие требования к средствам измерений и техническим системам и устройствам с измерительными функциями оригинал документа: вид средства измерений:… … Словарь-справочник терминов нормативно-технической документации

МИ 3372-12: Рекомендация. Государственная система обеспечения единства измерений. Магистральный нефтепродуктопровод. Системы измерений количества и показателей качества нефтепродуктов. Общие технические и метрологические требования - Терминология МИ 3372 12: Рекомендация. Государственная система обеспечения единства измерений. Магистральный нефтепродуктопровод. Системы измерений количества и показателей качества нефтепродуктов. Общие технические и метрологические требования:… … Словарь-справочник терминов нормативно-технической документации

СА 03-002-05: Стандарт ассоциации. Системы мониторинга агрегатов опасных производственных объектов. Общие технические требования - Терминология СА 03 002 05: Стандарт ассоциации. Системы мониторинга агрегатов опасных производственных объектов. Общие технические требования: 2.1. Агрегат: совокупность механически соединенных механизмов, узлов, машин и конструкций, работающих… … Словарь-справочник терминов нормативно-технической документации

П ССФЖТ 45/ИСО 9001-2003: Системы менеджмента качества. Требования - Терминология П ССФЖТ 45/ИСО 9001 2003: Системы менеджмента качества. Требования: 3.7 запись: Документ, содержащий достигнутые результаты или свидетельства осуществленной деятельности (ГОСТ Р ИСО 9000). Определения термина из разных документов:… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 51904-2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию - Терминология ГОСТ Р 51904 2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию оригинал документа: 3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий … Словарь-справочник терминов нормативно-технической документации

Книги

• Технические средства автоматизации. Интерфейсные устройства и микропроцессорные средства. Учебное пособие , В. Ф. Беккер. В соответствии с тенденцией информатизации современных технических средств автоматизации описываются датчики, интерфейсные, микропроцессорные и компьютерные устройства. Излагаются основные…
• Средства мультимедиа , С. В. Киселев. В учебном пособии предлагается применение компетентностного подхода к подготовке операторов ЭВМ. Изложены основы использования мультимедийных программ на IBM-совместимых персональных…

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

Все требования разбиваются на три уровня:

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

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

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

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

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

1. Функциональные требования

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

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

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

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

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

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

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

Существует большое число атрибутов качества. Например, стандарт ISO 9126 предлагает оценивать программную продукцию по шести характеристикам качества , рекомендуя использовать 21 показатель (подхарактеристику ) качества . Этот же стандарт советует учитывать, что представления о качестве для разных групп заинтересованных лиц отличаются, приводя в качестве примера представления о качестве пользователей, разработчиков и руководителей проекта.

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

Производительность

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

Надежность и доступность

Надежность – это вероятность работы системы без сбоев в течение определенного времени. Для измерения надежности может быть использовано среднее время работы системы до сбоя.

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

Безопасность

Удобство и простота обслуживания

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

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

Легкость сопровождения и эксплуатации

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

Мобильность

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

Повторное использование

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

Тестируемость

Этот атрибут показывает легкость, с которой компоненты проекта и комплексный продукт могут быть проверены на наличие ошибок.

2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ 3

3. Обозначения и сокращения 3

4.ЦЕЛИ, ОБЪЕМ И РЕЗУЛЬТАТ СОЗДАНИЯ СИСТЕМЫ 3

5.ОБЩИЕ СВЕДЕНИЯ 5

6.ТРЕБОВАНИЯ К СИСТЕМЕ 7

7.ТРЕБОВАНИЯ К НСИ 13

8.ТРЕБОВАНИЯ К МЕТОДОЛОГИЧЕСКОМУ ОБЕСПЕЧЕНИЮ 14

9.ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ 14

10.ТРЕБОВАНИЯ К ПЕРЕНОСУ ИСТОРИЧЕСКИХ ДАННЫХ 15

11.ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ 16

12.ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РАБОТ 16

Функциональные требования к подсистеме «Бюджетирование» 18

1.ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ 18

Функциональные требования к подсистеме «Казначейство» 27

Функциональные требования к подсистеме «ТОИР» 36

Функциональные требования к подсистеме «Кадровый учет» 67

Функциональные требования к подсистеме «Расчет заработной платы» 81

Функциональные требования к подсистеме «Регламентированный учет» 91

Функциональные требования к подсистеме «Продажи» 112

Функциональные требования к подсистеме «Управление договорами» 116

Функциональные требования к подсистеме «Инвестиции» 128

Функциональные требования к подсистеме «МТО и склад» 142

Функциональные требования к подсистеме «Охрана труда» 152

Функциональные требования к подсистеме «Управление автотранспортом» 160

Функциональные требования к подсистеме «Делопроизводство» 168

Функциональные требования к подсистеме «Производство» 175

Функциональные требования к подсистеме «ОРЭМ» 181

Общие требования к корпоративной автоматизированной системе управления

1.ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ

2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

3. Обозначения и сокращения

В этой статье я расскажу о следующем:

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

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

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

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

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

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

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

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

• Юридические требования - требования к лицензированию, патентной чистоте, etc.

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

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

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

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

• Книга Карла Вигерса "Разработка требований к программному обеспечению " - в разделе «Приложение Г» этой книги находятся примеры документации требований.

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

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

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

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

1. Система получает оповещение о событии, инициирующем рассылку уведомлений.
2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.
3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.

Требования к времени оповещения о событии, инициирующем рассылку уведомлений: система должна получать оповещение не позднее чем через XX секунд после возникновения события.
Требования к времени отправки уведомлений: все уведомления должны быть отправлены не позднее YY минут после получения оповещения о событии
Требования к повторной отправке рассылки после неудачной попытки: число повторных попыток должно быть равным 10, с интервалом в 10 мин после каждой неудачной попытки отправки.

Критерии качественных нефункциональных требований

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

• Полнота (отдельного требования и системы требований) - требование должно содержать всю необходимую информацию для его реализации. В него включается вся информация об описываемом параметре, известная на момент описания. Система требований также не должна содержать невыявленных и не определенных требований. Причины неполноты описания следует явно объявлять.
• Однозначность - требование должно быть внутренне непротиворечиво и все работающие с ним должны понимать его одинаково. Требования следует выражать просто, кратко и точно, используя известные термины. Обычно базовые знания читателей спецификации требований к ПО различаются. Поэтому в ее состав нужно включить раздел с определением понятий прикладной области, используемых при определении требований. Пример, неоднозначного требования. «Период обновления экрана должен быть не менее 20 сек.»
• Корректность отдельного требования и согласованность (непротиворечивость) системы требований - требование не должно содержать в себе неверной, неточной информации, а отдельные требования в системе требований не должны противоречить друг другу.
• Необходимость - требование должно отражать возможность или характеристику ПО, действительно необходимую пользователям, или вытекающую из других требований.
• Осуществимость - включаемое в спецификацию требование должно быть выполнимым при заданных ограничениях операционной среды. Осуществимость требований проверяется в процессе анализа осуществимости разработчиком. В частности, для нефункциональных требований проверяется возможность достижения указанных численных значений при существующих ограничениях.
• Проверяемость - проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того, что ПО удовлетворяет этому требованию. Каждое требование (особенно нефункциональное) должно содержать достаточно информации для однозначной проверки его реализации. Иначе, факт реализации будет основываться на мнении, а не на анализе, что приведет к проблемам при сдаче готового ПО. Для атрибутов качества (как мы помним, отдельной разновидности нефункциональных требований) критерием проверямости можно считать наличие численных значений характеристик качества продукта или системы

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

Атрибуты качества

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

Характеристики качества и модель качества ПО

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

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

Среди них можно выделить следующие:

• Модель качества по МакКоллу (McCall’s Quality Model)
• Модель качества по Боэму (Boehm’s Quality Model)

• 1061-1998 IEEE Standard for Software Quality Metrics Methodology
• ISO 8402:1994 Quality management and quality assurance

Характеристики качества с точки зрения влияния на архитектуру системы

Рассмотрим более подробно каждую из этих групп.

Группа runtime

• Доступность - атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
• Надежность - требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
• Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
• Масштабируемость - требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, .
• Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
• Требования к безопасности , как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак.
• Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
  1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;
  2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
  3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;
  4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.
• Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
• Ограничения , накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи

Группа design time

• Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
• Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
• Требования к переносимости (Portability) приложения или системы на другие платформы.
• Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
• Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
• Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
• Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
• Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы

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

Теги:

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