Требования к программному обеспечению [1] для системы — это описание того, что система должна делать, услуга или услуги, которые она предоставляет, и ограничения на ее работу. Стандартный глоссарий терминологии программной инженерии IEEE определяет требование как: [2]
Действия, связанные с работой с требованиями к программному обеспечению, можно в целом разделить на выявление, анализ, спецификацию и управление. [3]
Обратите внимание, что формулировка « Требования к программному обеспечению» дополнительно используется в примечаниях к выпуску программного обеспечения для объяснения того, какие пакеты программного обеспечения требуются для сборки/установки/использования определенного программного обеспечения. [1]
Выявление — это сбор и обнаружение требований от заинтересованных сторон и других источников. Можно использовать различные методы, такие как сессии совместного проектирования приложений (JAD), интервью, анализ документов, фокус-группы и т. д. Выявление — это первый шаг в разработке требований.
Анализ — это логическое разбиение, которое происходит из извлечения. Анализ включает в себя достижение более глубокого и точного понимания каждого требования и представление наборов требований несколькими, взаимодополняющими способами.
Сортировка требований или приоритизация требований — еще одна деятельность, которая часто следует за анализом. [4] Это относится к гибкой разработке программного обеспечения на этапе планирования, например, с помощью покера планирования , однако это может быть не то же самое в зависимости от контекста и характера проекта и требований или продукта/услуги, которые создаются.
Спецификация включает представление и хранение собранных знаний о требованиях в устойчивом и хорошо организованном виде, что способствует эффективному общению и управлению изменениями. Варианты использования, пользовательские истории, функциональные требования и модели визуального анализа являются популярными вариантами для спецификации требований.
Валидация включает в себя методы подтверждения того, что был указан правильный набор требований для создания решения, удовлетворяющего бизнес-целям проекта.
Требования меняются в ходе проектов, и их часто бывает много. Управление этими изменениями становится первостепенным для обеспечения создания правильного программного обеспечения для заинтересованных сторон.
Принимая во внимание, что эти действия могут включать в себя некоторые артефакты, такие как отчеты о наблюдениях ( наблюдение за пользователями ), анкеты ( интервью , опросы и голосования), сценарии использования , пользовательские истории ; такие действия, как семинары по требованиям ( charrettes ), мозговой штурм , составление ментальных карт , ролевые игры ; и даже создание прототипов ; [5] программные продукты, предоставляющие некоторые или все эти возможности, могут быть использованы для выполнения этих задач.
Есть по крайней мере один автор, который открыто выступает за инструменты для создания ментальных карт , такие как FreeMind ; и, в качестве альтернативы, за использование инструментов спецификации на основе примеров, таких как Concordion . [6] Кроме того, идеи и утверждения, полученные в результате этих действий, могут быть собраны и организованы с помощью вики и других инструментов для совместной работы, таких как Trello . Фактически реализованные функции и соответствие стандартам различаются от продукта к продукту.
Документ спецификации требований к программному обеспечению (SRS) может быть создан с использованием программного обеспечения общего назначения, например текстового процессора или одного из нескольких специализированных инструментов. Некоторые из этих инструментов могут импортировать, редактировать, экспортировать и публиковать документы SRS. Это может помочь создать документы SRS, следуя стандартизированной структуре и методологии, например ISO/IEC/IEEE 29148:2018. Аналогично, программное обеспечение может использовать или не использовать какой-либо стандарт для импорта или экспорта требований (например, ReqIF ) или вообще не разрешать эти обмены.
Инструменты такого рода проверяют наличие ошибок в документе с требованиями в соответствии с ожидаемой структурой или стандартом.
Инструменты такого рода сравнивают два набора требований в соответствии с некоторой ожидаемой структурой документа и стандартом.
Подобные инструменты позволяют объединять и обновлять документы с требованиями.
Инструменты такого рода позволяют отслеживать требования к другим артефактам, таким как модели и исходный код (прямая прослеживаемость), или к предыдущим, таким как бизнес-правила и ограничения (обратная прослеживаемость).
Системная инженерия на основе моделей (MBSE) — это формализованное применение моделирования для поддержки системных требований, проектирования, анализа, верификации и валидации, начинающееся на этапе концептуального проектирования и продолжающееся на протяжении всей разработки и последующих этапов жизненного цикла. Также возможно использовать подход на основе моделей для некоторых этапов инженерии требований и более традиционный подход для других. Возможны очень многие комбинации.
Уровень формальности и сложности зависит от базовой методологии (например, i* гораздо более формален, чем SysML , и даже более формален, чем UML ).
Инструменты в этой категории могут предоставлять некоторую смесь возможностей, упомянутых ранее, и других, таких как управление конфигурацией требований и совместная работа. Фактически реализованные функции и соответствие стандартам различаются от продукта к продукту.
Существуют еще более эффективные или общие инструменты, которые поддерживают другие этапы и виды деятельности. Они классифицируются как инструменты ALM .
{{cite web}}: Отсутствует или пусто |url=( помощь )