Требования к программному обеспечению - это поле в программной инженерии, которое занимается установлением потребностей заинтересованных сторон, которые должны быть решены с помощью программного обеспечения. В стандартном глоссарии терминологии программной инженерии IEEE требование определяется как:
Действия, связанные с работу с требованиями к программному обеспечению можно в общих чертах разделить на выявление, анализ, спецификацию и управление.
Выявление требований - это сбор и выявление требований от заинтересованных сторон и других источников. Могут быть использованы различные методы, такие как совместное проектирование приложений (JAD), интервью, анализ документов, фокус-группы и т. Д. Выявление информации - это первый шаг в разработке требований.
Анализ - это логическая разбивка, происходящая из извлечения. Анализ включает достижение более глубокого и точного понимания каждого требования и представление наборов требований множеством взаимодополняющих способов.
Требования Сортировка или приоритезация требований - еще одна деятельность, которая часто следует за анализом. Это относится к гибкой разработке программного обеспечения на этапе планирования, например от Планирование покера, однако это может быть не то же самое в зависимости от контекста и характера проекта и требований или продукта / услуги, которые разрабатываются.
Спецификация включает представление и хранение собранных знаний о требованиях в устойчивой и хорошо организованной форме, что способствует эффективному обмену информацией и управлению изменениями. Примеры использования, пользовательские истории, функциональные требования и модели визуального анализа - популярные варианты спецификации требований.
Валидация включает в себя методы подтверждения того, что для построения решения, соответствующего бизнес-целям проекта, был указан правильный набор требований.
Требования меняются во время проектов, и их часто бывает много. Управление этим изменением становится первостепенным для обеспечения создания правильного программного обеспечения для заинтересованных сторон.
Принимая во внимание, что эти действия могут включать некоторые артефакты, такие как отчеты о наблюдениях (пользователь наблюдение ), анкеты (интервью, опросы и опросы), варианты использования, пользовательские истории ; такие мероприятия, как требования семинары (charrettes ), мозговой штурм, отображение разума, ролевые игры ; и даже, прототипирование ; программные продукты, обеспечивающие некоторые или все эти возможности, могут использоваться для решения этих задач.
Есть по крайней мере один автор, который открыто поддерживает инструменты отображения разума, такие как FreeMind ; и, в качестве альтернативы, для использования спецификации с помощью инструментов примера, таких как Concordion. Кроме того, идеи и утверждения, вытекающие из этих действий, могут быть собраны и систематизированы с помощью вики и других инструментов совместной работы, таких как Trello. Фактически реализованные функции и соответствие стандартам варьируются от продукта к продукту.
Документ спецификации требований к программному обеспечению (SRS) может быть создан с использованием такого общего программного инструмента, как текстовый процессор или электронная таблица; но есть несколько специализированных инструментов для выполнения этой деятельности.
Некоторые из этих инструментов могут импортировать, редактировать, экспортировать и публиковать документы SRS. Они могут помочь или не помочь пользователю следовать стандартам, таким как IEEE 2918-2011, для составления требований в соответствии с некоторой структурой. Точно так же инструмент может использовать или не использовать какой-либо стандарт для импорта или экспорта требований (например, ReqIF ); или вообще не разрешать эти обмены.
Инструменты этого типа проверяют, есть ли какие-либо ошибки в документе требований в соответствии с некоторой ожидаемой структурой или стандартом.
Инструменты этого типа сравнивают два набора требований в соответствии с некоторой ожидаемой структурой документа и стандартом.
Инструменты этого типа позволяют объединять и обновлять документы требований.
Инструменты этого типа позволяют отслеживать требования к другим артефактам, таким как модели и исходный код (прямая отслеживаемость), или к предыдущим, таким как бизнес-правила и ограничения (назад прослеживаемость).
Модельно-ориентированное системное проектирование (MBSE) - это формализованное приложение моделирования для поддержки требований к системе, проектирования, анализа, измерения, проверки и проверки действия, начинающиеся на этапе концептуального проектирования и продолжающиеся на протяжении этапов разработки и последующих этапов жизненного цикла. Также можно использовать модельный подход для одних этапов разработки требований и, более традиционный, для других. Возможны всевозможные комбинации.
Уровень формальности и сложности зависит от используемой базовой методологии (например, i * гораздо более формален, чем SysML, и даже более формален, чем UML )
Инструменты в этой категории могут обеспечивать некоторое сочетание упомянутых ранее и других возможностей, таких как управление конфигурацией требований и совместная работа. Фактически реализованные функции и соответствие стандартам различаются от продукта к продукт.
Существуют даже более функциональные или общие инструменты, которые поддерживают другие этапы и действия. Они классифицируются как инструменты ALM.