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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.1

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

Рис. 3.2

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

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

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