Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Требования к системе - это описание того, что система должна делать, услуги или услуги, которые она предоставляет, и ограничения на ее работу. В стандартном глоссарии терминологии программной инженерии IEEE требование определяется следующим образом: [1]

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

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

Обратите внимание, что формулировка « Требования к программному обеспечению» дополнительно используется в примечаниях к выпуску программного обеспечения для объяснения того, какие пакеты программного обеспечения требуются для сборки / установки / использования определенного программного обеспечения. [3]

Выявление [ править ]

Основная статья: Выявление требований

Выявление требований - это сбор и выявление требований от заинтересованных сторон и других источников. Могут использоваться различные методы, такие как сеансы совместного проектирования приложений (JAD), интервью, анализ документов, фокус-группы и т. Д. Извлечение информации - это первый шаг разработки требований.

Анализ [ править ]

Основная статья: Анализ требований

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

Требования Сортировка или приоритезация требований - еще одна деятельность, которая часто следует за анализом. [4] Это относится к гибкой разработке программного обеспечения на этапе планирования, например, с помощью Планирования покера , однако это может быть не то же самое в зависимости от контекста и характера проекта и требований или продукта / услуги, которые разрабатываются.

Спецификация [ править ]

Основная статья: Спецификация требований к программному обеспечению

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

Проверка [ править ]

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

Управление [ править ]

Основная статья: Управление требованиями

Требования меняются в ходе проекта, и их часто бывает много. Управление этим изменением становится первостепенным для обеспечения создания правильного программного обеспечения для заинтересованных сторон.

Инструментальная поддержка для разработки требований [ править ]

Инструменты для выявления, анализа и проверки требований [ править ]

Принимая во внимание, что эти действия могут включать некоторые артефакты, такие как отчеты наблюдений ( наблюдение пользователей ), анкеты ( интервью , опросы и опросы), варианты использования , истории пользователей ; такие мероприятия, как семинары по требованиям ( charrettes ), мозговой штурм , отображение разума , ролевые игры ; и даже прототипирование ; [5] программные продукты, обеспечивающие некоторые или все эти возможности, могут использоваться для решения этих задач.

Есть, по крайней мере, один автор, который открыто выступает за инструменты отображения разума, такие как FreeMind ; и, в качестве альтернативы, для использования спецификации с помощью примеров инструментов, таких как Concordion . [6] Кроме того, идеи и утверждения, вытекающие из этих действий, могут быть собраны и систематизированы с помощью вики-страниц и других инструментов для совместной работы, таких как Trello . Фактически реализованные функции и соответствие стандартам варьируются от продукта к продукту.

Инструменты для спецификации требований [ править ]

Документ со спецификацией требований к программному обеспечению (SRS) может быть создан с использованием такого общего программного инструмента, как текстовый процессор или электронная таблица; но есть несколько специализированных инструментов для выполнения этой деятельности.

Некоторые из этих инструментов могут импортировать, редактировать, экспортировать и публиковать документы SRS. Они могут помочь или не помочь пользователю следовать стандартам, таким как IEEE 2918-2011, для составления требований в соответствии с некоторой структурой. Аналогичным образом, инструмент может использовать или не использовать какой-либо стандарт для импорта или экспорта требований (например, ReqIF ); или вообще не разрешать эти обмены.

Инструменты для проверки документов с требованиями [ править ]

Инструменты такого типа проверяют, есть ли какие-либо ошибки в документе требований в соответствии с какой-либо ожидаемой структурой или стандартом.

Инструменты для сравнения требований [ править ]

Инструменты такого типа сравнивают два набора требований в соответствии с некоторой ожидаемой структурой документа и стандартом.

Инструменты для слияния и обновления требований [ править ]

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

Инструменты для отслеживания требований [ править ]

Инструменты этого типа позволяют отслеживать требования к другим артефактам, таким как модели и исходный код (прямая отслеживаемость), или к предыдущим, таким как бизнес-правила и ограничения (обратная отслеживаемость).

Инструменты для модельно-ориентированного программного обеспечения или проектирования системных требований [ править ]

Системная инженерия на основе моделей (MBSE) - это формализованное приложение моделирования для поддержки системных требований, проектирования, анализа, измерения, [7] верификации и валидации, начиная с этапа концептуального проектирования и продолжаясь на протяжении всей разработки и последующих этапов жизненного цикла. Также можно использовать модельный подход для одних этапов разработки требований и, более традиционный, для других. Возможно очень много комбинаций.

Уровень формальности и сложности зависит от используемой базовой методологии (например, i * намного более формален, чем SysML, и даже более формален, чем UML )

Инструменты для разработки общих требований [ править ]

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

Существуют даже более эффективные или общие инструменты, которые поддерживают другие этапы и действия. Они классифицируются как инструменты ALM .

См. Также [ править ]

  • Требование
  • Разработка требований
  • Спецификация требований к программному обеспечению (SRS)
  • Комплексный и надежный процесс спецификации требований
  • Список инструментов разработки требований
  • Нефункциональное требование
  • Требования к производительности, которые покрываются тестированием производительности программного обеспечения
  • Требования безопасности
  • Требования безопасности

Ссылки [ править ]

  1. ^ IEEE Computer Society (1990). «Стандартный глоссарий терминологии программной инженерии IEEE» . Стандарт IEEE .
  2. ^ «Руководство по сводам знаний в области программной инженерии» . Компьютерное общество IEEE . Проверено 11 января 2013 года . CS1 maint: обескураженный параметр ( ссылка )
  3. ^ «Версия ядра Linux 5.x - Документация ядра Linux» . www.kernel.org . Проверено 25 марта 2021 .
  4. ^ Дэвис, Алан Марк. (2005). Достаточно управления требованиями: где разработка программного обеспечения встречается с маркетингом . Нью-Йорк: паб Дорсет Хаус. ISBN 0-932633-64-1. OCLC  57211148 .
  5. ^ https://www.liquidplanner.com/blog/7-tools-to-gather-better-software-requirements/
  6. ^ Laplante, Phillip A. (2009). «Разработка требований к программному обеспечению и системам». CRC Press. Отсутствует или пусто |url=( справка )
  7. ^ Монперрус, М .; Baudry, B .; Champeau, J .; Hoeltzener, B .; Jézéquel, JM (2011). «Автоматизированное измерение моделей требований» . Журнал качества программного обеспечения . 21 (1): 3–22. DOI : 10.1007 / s11219-011-9163-6 .

Дальнейшее чтение [ править ]

  • Вигерс, Карл ; Битти, Джой (2013). Требования к программному обеспечению (3-е изд.). Microsoft Press . ISBN 978-0-7356-7966-5. CS1 maint: обескураженный параметр ( ссылка )
  • Кокберн, Алистер (2001). Написание эффективных сценариев использования . Pearson Education . ISBN 0-201-70225-8. CS1 maint: обескураженный параметр ( ссылка )
  • Леффингуэлл, Дин (2000). Управление требованиями к программному обеспечению: единый подход . Эддисон-Уэсли Профессионал . ISBN 0-201-61593-2.
  • Бурек, Пол (2008). Создание четких требований к проекту, отличающих «что» от «как» . Документ конференции. Управление требованиями, бизнес-анализ, управление объемом.
  • Купман, Филипп (2020). Требования к встроенному программному обеспечению . Осенние лекции.
  • Поиск IEEE Xplore. «Требования к программному обеспечению» .