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

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

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

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

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

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

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

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

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

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