3. Формирование и анализ требований

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

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

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

1. выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц),

2. анализ (проверка целостности и законченности),

3. спецификация (документирование требований),

4. проверка правильности.

По уровням требования делятся на следующие категории.

1. Бизнес-требования, которые определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).

2. Пользовательские требования, определяющие набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Они могут выражаться в виде фраз утверждений, сценариев использования (use case) или пользовательских историй ({{lang-en|user stories), сценариев взаимодействия (scenario).

3. Функциональные требования, описывающие предполагаемое поведение системы, определяя действия, которые она способна выполнять. Они представляются в виде системной спецификации (system requirement specification, SRS).

По характеру различают следующие типы требований.

1. Функциональные — требования к поведению системы:

1. Бизнес-требования;

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

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

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

1. Бизнес-правила, которые определяют ограничения, вытекающие из предметной области и свойств автоматизируемого объекта (предприятия);

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

• Ограничения на программные интерфейсы, в том числе к внешним системам;

• Требования к атрибутам качества;

• Требования к применяемому оборудованию и ПО;

3. Требования к документированию;

4. Требования к дизайну и юзабилити (удобству);

5. Требования к безопасности и надёжности;

6. Требования к показателям назначения (производительность, устойчивость к сбоям и т. п.)

7. Требования к эксплуатации и персоналу;

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

Источниками требований могут быть следующие объекты.

• Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения);

• Нормативное обеспечение организации (регламенты, положения, уставы, приказы);

• Текущая организация деятельности объекта автоматизации;

• Модели деятельности (диаграммы бизнес-процессов);

• Представления и ожидания потребителей и пользователей системы;

• Журналы использования существующих программно-аппаратных систем;

• Конкурирующие программные продукты.

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

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

Анализ требований включает три типа операций.

1. Сбор, при котором происходит общение с клиентами и пользователями и анализ предметной области.

2. Анализ, на котором определяют, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; выполняют решение этих проблем и выявляют взаимосвязи требований.

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

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

Рис. 3.1

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

Рис. 3.2

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

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

Рекомендуемые подходы к спецификации требований программного обеспечения описаны стандартом IEEE 830—1998. Этот стандарт описывает возможные структуры, желательное содержание и качество спецификации требований программного обеспечения.