Спецификация требований к программному обеспечению - Software requirements specification

Для более широкого освещения этой темы см. Требования к ПО.
IEEE жизненный цикл программного обеспечения

А спецификация требований к программному обеспечению (SRS) является описанием программная система быть развитый. Он создан по образцу спецификация бизнес-требований (КОНОПЫ), также известный как спецификация требований заинтересованных сторон (StRS).[нужна цитата ] В спецификации требований к программному обеспечению изложены функциональный и нефункциональные требования, и он может включать в себя набор сценарии использования которые описывают взаимодействия с пользователем, которые программное обеспечение должно предоставлять пользователю для идеального взаимодействия.

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

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

СГД может быть одним из результат описания элементов данных[4] или иметь другие формы содержания, предписанного организацией.

Обычно SRS пишется технический писатель, а системный архитектор, или программист.[5]

Структура

Пример организации SRS выглядит следующим образом:[6]

  1. Цель
    1. Определения
    2. Фон
    3. Системный Обзор
    4. Рекомендации
  2. Общее описание
    1. Перспектива продукта
      1. Системные интерфейсы
      2. Пользовательские интерфейсы
      3. Аппаратные интерфейсы
      4. Программные интерфейсы
      5. Коммуникационные интерфейсы
      6. Ограничения памяти
    2. Ограничения дизайна
      1. Операции
      2. Требования к адаптации сайта
    3. Функции продукта
    4. Характеристики пользователя
    5. Ограничения, предположения и зависимости
  3. Особые требования
    1. Требования к внешнему интерфейсу
    2. Функциональные требования
    3. Требования к производительности
    4. Требование к логической базе данных
    5. Системные атрибуты программного обеспечения
      1. Надежность
      2. Доступность
      3. Безопасность
      4. Ремонтопригодность
      5. Портативность
    6. Функциональные требования
      1. Функциональное разделение
      2. Функциональное описание
      3. Описание управления
    7. Характеристики окружающей среды
      1. Аппаратное обеспечение
      2. Периферийные устройства
      3. Пользователи
    8. Другой

Цели

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

  • Облегчение обзоров
  • Описание объема работ
  • Предоставление ссылки разработчикам программного обеспечения (например, средства навигации, структура документа)
  • Предоставление основы для тестирования первичных и вторичных вариантов использования
  • Включая Особенности к требованиям заказчика
  • Предоставление платформы для постоянного совершенствования (с помощью неполных спецификаций или вопросов)

Требования к запаху

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

Примеры запахов требований: субъективный язык, неоднозначные наречия и прилагательные, превосходная степень и Негативные утверждения.[7]

Смотрите также

Рекомендации

  1. ^ Bourque, P .; Фэрли, Р. (2014). "Руководство по сводам знаний по программной инженерии (SWEBOK)". IEEE Computer Society. Получено 17 июля 2014.
  2. ^ «Спецификация требований к программному обеспечению помогает защитить ИТ-проекты от сбоев». Получено 19 декабря 2016.
  3. ^ Прессман, Роджер (2010). Программная инженерия: подход практикующего специалиста. Бостон: Макгроу Хилл. п. 123. ISBN  9780073375977.
  4. ^ "DI-IPSC-81433A, ДАННЫЕ ОПИСАНИЕ ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ СПЕЦИФИКАЦИЯ (SRS)". everyspec.com. 1999-12-15. Получено 2013-04-04.
  5. ^ Донн Ле Ви-младший«Написание спецификаций требований к программному обеспечению (SRS)».2010.
  6. ^ Стеллман, Эндрю и Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения. O'Reilly Media, Inc. стр. 308. ISBN  978-0596009489.
  7. ^ а б Феммер, Хеннинг; Мендес Фернандес, Даниэль; Вагнер, Стефан; Эдер, Себастьян (2017). «Быстрая проверка качества с учетом требований запахов». Журнал систем и программного обеспечения. 123: 190–213. arXiv:1611.08847. Дои:10.1016 / j.jss.2016.02.047. S2CID  9602750.

внешняя ссылка

[1]

  1. ^ Таафф, Эд. "Мистер". мост. Получено 2019-02-02.