Срс что это: SRS что это такое в машине? — Определение и принцип работы

что такое и зачем это нужно разработчикам

Как правило, заказчики и разработчики говорят на разных языках. Клиент представляет внешнее поведение системы: что она будет делать и как с ней будут работать конечные пользователи. Программисты же думают о продукте с точки зрения его внутренних характеристик. 

Понять друг друга им помогает бизнес-аналитик, он превращает потребности клиента в требования, а требования в задачи для разработчиков. Первоначально это делается путем составления спецификаций требований к программному обеспечению (Software requirements specification или SRS).

Что такое SRS

Software requirements specification — один из самых важных документов в разработке программного обеспечения. Он описывает работу ПО, его функции и нагрузки. Проще говоря, SRS предоставляет всем участникам дорожную карту для проекта.

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

Преимущества SRS

• Software requirements specification является основой проекта. Документ закладывает базу, которой будут следовать все участники команды разработки.
• Спецификации требований к программному обеспечению — это способ более четкой коммуникации. Этот инструмент помогает быть уверенным в том, что все участники процесса правильно понимают друг друга. 
• Написание SRS также может минимизировать общее время и затраты на разработку. Команды разработчиков встроенных систем особенно выигрывают от использования SRS.
• Такая документация помогает избежать дальнейших улучшений и изменений в проекте, которые задерживают завершение или приводят к дополнительным расходам. 

Как выглядит

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

В YuSMP Group SRS обычно выглядит так:

Роль

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

Блок/фича

Функциональности обычно представляем в виде блоков или таблицы, которая включает в себя три раздела — это пользовательская история, бизнес-правила (UseCases) и валидация (на схеме показываем, что требования к фиче выполнены).

Пользовательская история

Этот раздел отображает сценарий использования конкретной фичи. Подробнее о пользовательских историях можно узнать здесь.

UseCases (Бизнес-правила)

Внутри пользовательских историй мы размещаем бизнес-правила или UseCases. Это перечень условий, при котором фича будет работать так, как нужно клиенту.

Разработкой такого документа, как правило, занимаются бизнес-аналитики. Мы уже рассказывали о том, что часто вовлекаем заказчика в процесс, чтобы уже на ранних этапах формировался продукт, который точно будет соответствовать ожиданиям. Опыт создания SRS в сотрудничестве с клиентом тоже оказался полезным — мы вносили изменения в фичи, когда они еще были на «бумаге», а не в разработке.

Зачем мы используем SRS

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

Но это еще не все:  

• Дизайнеры получают представление о проекте через документы SRS, чтобы они могли адаптировать дизайн к варианту использования.
• Тестировщики получают рекомендации по созданию тестовых примеров, соответствующих потребностям бизнеса.
• На основании SRS можно составить содержательную презентацию для инвесторов: бизнес-процессы легко визуализировать для грамотной презентации проекта.

Еще SRS важен, потому что это единый источник информации, который предотвращает недопонимание как между менеджером проекта и командой, так и между заказчиком и аутсорс-компанией. 

Published by YuSMP Group in Блог, Статьи

Почему не нужна спецификация требований к программному обеспечению?

Как говорится, без ТЗ — результат хз. Во многих сферах это действительно так работает: без четкого технического задания сотрудник или подрядчик не может качественно выполнить задачу. В IT технические задания для проектов разработки давно изжили себя. С приходом agile- и SCRUM-методологий больше не нужно писать 40-страничные документы и подробно объяснять каждое решение. В статье разберемся, почему пора забыть об SRS документе, и чем заменить сложное техзадание.

SMS? BTS? CMS? SRS!

SRS (software requirements specification, спецификация требований к программному обеспечению) — документ с требованиями к приложению, по-нашему — техническое задание. В эсэрэску входят требования и ограничения по функциональности и производительности SRS составляют для прозрачного взаимодействия заказчика и подрядчика.  

SRS обычно пишут простым «клиентским» языком, потому что и составляется он на основе мнения клиента. Чтобы начать сотрудничество, подрядчику необходимо узнать, чего хочет заказчик, понять желания и бизнес-цели. На основе информации с нескольких созвонов на стороне подрядчика составляют SRS документ.

У SRS документа есть ряд особенностей. 

Структура

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

Структура SRS документа включает в себя детальное описание каждой части будущего приложения. Проблема в том, что 90% информации в таком документе — вода; настоящую пользу несут разве что картинки — примеры дизайна и описания работы сложных алгоритмов. Допустим, если бы у Tinder был SRS, то там бы был алгоритм мэтчинга. И еще 37 страниц ненужной инфы.

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

• Введение
  • Цели 
  • Соглашения о терминах
  • Предполагаемая аудитория и последовательность восприятия
  • Масштаб проекта
  • Ссылки на источники
• Общее описание
  • Видение продукта
  • Функциональность продукта
  • Классы и характеристики пользователей
  • Среда функционирования продукта (операционная среда)
  • Рамки, ограничения, правила и стандарты
  • Документация для пользователей
  • Допущения и зависимости
• Функциональность системы
  • Функциональный блок X (таких блоков может быть несколько)
    • Описание и приоритет
    • Причинно-следственные связи, алгоритмы (движение процессов, workflows)
    • Функциональные требования

• Требования к внешним интерфейсам
  • Интерфейсы пользователя (UX)
  • Программные интерфейсы
  • Интерфейсы оборудования
  • Интерфейсы связи и коммуникации
• Нефункциональные требования
  • Требования к производительности
  • Требования к сохранности (данных)
  • Критерии качества программного обеспечения
  • Требования к безопасности системы
• Прочие требования
  • Приложение А: Глоссарий
  • Приложение Б: Модели процессов предметной области и другие диаграммы
  • Приложение В: Список ключевых задач

Релевантность

Как бы ни хотелось рассказать в SRS документе о преимуществах компании или идеях, которые пришли в голову уже в процессе разработки, делать это запрещено. У документа — четкая цель, а значит, такое же четкое содержание. SRS всегда отражает функциональность и технические характеристики продукта.

Прозрачность

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

Точность

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

Рейтинг по важности

Никаких «два пишу, четыре в уме»! Если на исполнение того или иного требования уйдет много времени, стоит поставить для него высокий приоритет. В целом ранжирование требований по важности и стабильности — хорошая идея. Под стабильностью мы понимаем, насколько точно поставили задачу, и придется ли что-то менять в процессе исполнения.

Изменения

И хотя SRS — это документ с жесткой регламентацией, систематически в него можно и нужно вносить изменения. Правда, это не так легко, как кажется — SRS документ далеко не гибкая форма. Больше всего от этого страдают стартапы: в MVP приложения часто нужно вносить правки, а спецификацию требований к программному обеспечению менять забывают. Даже в крупных компаниях, которые любят бумажки и бюрократию, можно часто найти Confluence с документацией 5-летней давности. Зачем делалось? Конечно, для галочки!

SRS в России и за рубежом

За семь лет работы мы заметили, что отношение к SRS документам в России и за рубежом значительно отличается. Пытаемся понять, почему в России так любят бумажки, и как «продать иностранцу дизайн-концепт по цене SRS».

Россия 🇷🇺

Зарубеж ✖️🇷🇺

Заказчики из России часто просят составить SRS документ. Здесь принято делать большие отчеты ко всему, что происходит вокруг, поэтому даже современная IT-сфера не обходится без кучи бумажек. Иногда мы вынуждены делать подобные документы, потому что заказчик — крупная госструктура, где без отчетов, как известно, никуда. Про одного из таких заказчиков написали кейс «Большой брат оказался реальностью». Читайте по ссылке ниже 👇

А вот зарубежные клиенты SRS требуют редко. Они охотно принимают наши правила и соглашаются на гибкую модель работы. Есть, конечно, и принципиальные заказчики. Однажды клиент настаивал на составлении SRS документа, потому что хотел уйти на разработку к другому подрядчику. Мы его «переобули»: сделали гибрид SRS и нашего стандартного описания дизайна, добавили иллюстрации. Ему понравилось и он остался с нами!

 

 

5 причин отказаться от SRS

Мы в Purrweb не делаем SRS документы. Это принципиальная позиция, от которой мы отступали всего пару раз — напоминаем, что количество наших проектов перевалило за 250. Мы не тратим время на бумажную волокиту и бюрократию и сохраняем ресурсы клиента. Выделили пять основных причин, почему SRS не нужен. 

Время

SRS сожрет ваше время и не поперхнется косточкой менеджера по продажам. Сколько времени уйдет на составление документа? Мы попросили нашего операционного директора оценить эту задачу. Цифры говорят сами за себя:

Все дело в высокой детализации SRS документа. Сбор нужной информации может затянуться — бизнес-аналитикам придется подойти к дизайнерам, разработчкам, тестировщикам, тимлидам. Внутри спецификации требований к программному обеспечению много технических моментов, которые тяжело осмыслить человеку, далекому от разработки. За время, которое тратится на SRS, мы успеваем провести один спринт и прийти к заказчику с первыми результатами. Мы уверены: это лучше, чем бумажка. 

Неэффективность

Как бы хорошо и подробно менеджеры не прописали требования на старте проекта, буквально ВСЁ может пойти не так в ЛЮБОЙ  момент. Так что время + силы, затраченные на составление SRS мягко говоря «не окупятся». Скорее всего, ваши бизнес-аналитики почувствуют себя бесполезными. Из всего документа, на который они потратят 80 часов рабочего времени, клиенту пригодится 15-20%. 

Все остальное в SRS документе — вода, налитая в угоду бюрократии. Такие документы составляют в крупных компаниях для эффекта «создания бурной деятельности» и отчета ради отчета, который в 9 из 10 случаев даже не откроют.  

Не по agile 

SRS не совместим с гибким подходом к разработке. Невозможно смотреть на пустой экран и видеть будущее приложение с точностью до кнопки. Однако методика составления SRS документа утверждает обратное: нужно составить подробный план действий с детальным описанием каждого шага еще до того, как команда приступит к работе.

Подобный подход неплохо мэтчится с моделью Waterfall —  «каскадной разработкой». Особенность ватерфола в том, что все стадии создания проекта идут по порядку. Сначала делают весь дизайн, потом всю разработку, затем все тестируют, и если находят баги, исправляют в уже готовом приложении. Возвращение к предыдущему шагу не предусматривают, поэтому каждый этап важно сделать «на отлично». На наш взгляд, крайне идеалистическая модель. Никакой SRS не спасет от ошибок или срочных задач, которые не предусмотрели в спецификации требований к программному обеспечению.

Так что компании, которые используют agile и SCRUM-методологии, отказываются от SRS документов. Там (и здесь) работают спринтами. Тестирование проходит в конце двухнедельной итерации, поэтому баги находятся сразу. Так разработчику не приходится перелопачивать весь код, чтобы найти поломку.

Такая модель удобна не только для компании разработки, но и для клиента. С agile подходом вы всегда на связи с проектным менеджером, а значит, владеете актуальной информацией по проекту. Не приходится все время обращаться к SRS документу, данные в котором могут устареть на первой же итерации. 

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

Компании разработки SRS не нужен

Откроем страшную тайну: мы бы не пользовались SRS, даже если бы клиент настаивал его подготовить. Документ лежал бы мертвым грузом на рабочих столах разработчиков. Когда нас впервые попросили составить SRS документ, мы просто скачали шаблон из интернета и кастомизировали под заказчика. Спойлер: стартапер этого даже не заметил. Думаем, он его и не открывал. Да и мы не открывали.

Если у вас стартап, то тем более

«А что не так со стартапом?», — спросит владелец стартапа. Со стартапом все в порядке, а вот с SRS документом все еще нет. Пока другой подрядчик будет составлять документ с подробным описанием функциональности будущего приложения, мы уже сделаем первую версию дизайна и покажем его клиенту.   

Purrweb выбирает такой подход исходя из целевой аудитории — у нас это стартапы, которые приходят за MVP (минимально жизнеспособным продуктом).

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

Работа с клиентом в Purrweb начинается с созвона с аккаунт-менеджером. На звонке мы обсуждаем идею проекта и обещаем клиенту несколько практических результатов (deliverables) нашей работы — концепт, пользовательские истории, структура баз данных. Мы даже не предлагаем составить SRS документ.

Кристина Спиридонова, 
менеджер по работе с клиентами в Purrweb

Почему дизайн — first, расскажем в следующем блоке.

Вместо тысячи слов: альтернатива SRS

Вместо тысячи слов и десятков страниц ненужной информации мы предлагаем заказчикам подход design first. Это значит, что сразу после того, как мы подтверждаем сотрудничество, начинает работать дизайн-команда. Не бойтесь, дизайнеры не надизайнят «что надо и не надо» — все детали аккаунт менеджер и заказчик обсуждают на созвонах, бизнес-аналитик оценивает стоимость проекта. Мы получаем от клиента антиреференсы, иногда наработки по дизайну — так что всегда есть от чего оттолкнуться.

Почему хорошо начинать с дизайна?

Потому что дизайн — это часть будущего продукта, а SRS документ — всего лишь набор слов, собранный в строгую структуру. 

Ни в одном техническом задании или в спецификации требований к программному обеспечению не получится прописать все сразу. По ходу проекта все может измениться (и 100% изменится) — никто не вернется в ТЗ, чтобы что-то исправить или обновить.

Кристина Спиридонова, 

менеджер по работе с клиентами в Purrweb

Как делаем мы: вместо больших документов прописываем пользовательские истории. По юзер сториз делаем дизайн, на основе дизайна оцениваем разработку, делаем архитектуру и структуру базы данных. И только на этапе разработки делаем небольшой документ — описываем, как работает логика на бэкенде или какой-то сложный алгоритм. Важно: это не официальный документ. Мы можем даже не передать его клиенту, а сделать «чисто для себя» и хранить в readme в репозитории.  

С таким подходом легко вносить изменения на любом этапе. Даже если к концу разработки отвалится, например, админка, которую делали в середине проекта, разработчику ничего не стоит вернуться и все «поднять». И главное — никаких сложных документов, волокиты, бюрократии и прочих страшных вещей из мира отчетов.

Заключение

Мы лояльно относимся к любым хотелкам заказчика: хочет кастомные чат, календарь и видеозвонки? Пожалуйста! Нравится следить за каждым шагом разработки? Без проблем, будем созваниваться чаще. Но если речь заходит о спецификации требований к программному обеспечению, мы до последнего будем предлагать клиенту альтернативные решения. 

SRS документ не соответствует ценностям agile-подхода, не несет пользы клиенту и отнимает как наши, так и его ресурсы. Мы в Purrweb давно делаем все иначе: работаем по SCRUM, не морочим заказчикам голову огромными ТЗ, а разрабатываем понятные интерфейсы с удобным дизайном.

Хотите заказать приложение в Purrweb? Ниже есть форма для e-mail 👇

Насколько публикация полезна?

Оцени эту статью!

56 оценок, среднее 4 из 5.

Оценок пока нет. Поставьте оценку первым.

Укажите свою почту и мы вышлем статью туда

SRS: Основы спецификаций требований к программному обеспечению — BMC Software

Блог Business of IT

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

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

Как узнать, что ваша SRS готова к разработке? Что делает его исключительным? Это то, что мы собираемся рассказать в этой статье.

Характеристики исключительного SRS

Есть определенные вещи, которые разработчики должны стремиться достичь в своем документе SRS, чтобы подготовить его к плавной разработке проекта. Их можно разделить на три категории:

• Значимые качества
• Характеристики, отвечающие целям
• Идентифицируемые требования Запахи

Давайте посмотрим.

Значимые качества

Значимые качества SRS — это те качества, которые направлены на то, чтобы помочь разработчику понять весь масштаб проекта.

• Решение проблемы. Хороший SRS разбивает проблему на части, которые легче решить. Это также помогает улучшить понимание проблем и облегчает их решение.
• Ввод данных для проектирования. Ваш SRS должен содержать сведения о дизайне, чтобы помочь в реализации и развертывании.
• Рассматривает компоненты для обратной связи. Значимым качеством для пользователей готового программного обеспечения является возможность оставить отзыв. Это следует учитывать при разработке сильной SRS.
• Включает стратегии проверки. Стратегии проверки должны быть реализованы, чтобы гарантировать, что требования сформулированы правильно и функционируют так, как они предназначены.
• Требования ранжированы по важности. Ранжирование требований по важности четко показывает как разработчикам, так и заинтересованным сторонам приоритеты. Если проект приближается к определенному сроку, например, к концу спринта, система ранжирования помогает разработчикам легко менять приоритеты.
• Полный, краткий и изменяемый. Готовый продукт должен как можно сжатее давать полную картину проекта разработки, чтобы способствовать пониманию. Он должен быть легко модифицируемым для учета отзывов и изменений.

Характеристики, соответствующие целям

Каждый проект разработки должен иметь заранее установленный набор целей. Эти характеристики используются для обеспечения достижения целей и сохранения проекта на правильном пути.

• Описание объема работ. Одной из важнейших целей является четкое определение объема работ. Масштаб направляет разработчиков через проект. Это создает понимание того, каким должен быть законченный проект, определяя, как его достичь.
• Определяет функции для конечного пользователя. Требования заказчика включают определенные функции для конечного пользователя, которые должны быть определены в SRS.
• Предоставляет возможность для обзора с заинтересованными сторонами. Одной из целей этого документа является обеспечение прозрачности между руководителями проектов и заинтересованными сторонами. Вот почему обзоры SRS между обеими сторонами являются важным критерием общего успеха.
• Очистить навигацию. Четкая, лаконичная структура документа с навигацией — важный ориентир для разработчиков.
• Испытания и доработка. Целью любого проекта разработки является создание основы для тестирования. Дополнительным соображением является то, как вы будете совершенствовать структуру после ее развертывания. SRS должна решать обе проблемы.
• Оценка затрат. Важно отметить, что SRS должна быть в состоянии оценить затраты на разработку и развертывание, а также эксплуатационные расходы.

Идентифицируемые запахи требований

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

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

Примеры обязательных запахов включают:

• Неоднозначные наречия и прилагательные
• Субъективный язык
• Превосходная степень
• Отрицательные утверждения

Рекомендации для проекта S1 SRS

могут варьироваться от Исключительного содержания до Исключительного SRS. Тем не менее, каждый проект, независимо от того, насколько он отличается, должен следовать установленному набору правил. Эти рекомендации легко запомнить, так как их аббревиатура состоит из слова ФАКТЫ .

• Функциональные требования. Функция SRS отделена от самого проекта разработки. Функциональные требования этого документа для обеспечения основы для реализации должны быть очевидны во всем документе.
• Расчетная модель. Модель анализа позволяет детализировать спецификацию определенных требований. Например, требование «Добавить товар в корзину» — команда, которая не учитывает другие детали, такие как размер и количество. Их можно конкретизировать с помощью модели анализа, поскольку она связывает функциональные требования с дизайном.
• Когнитивная модель. Это модель разработки, которая помогает разработчикам понять, как система будет восприниматься другими, обычно конечными пользователями.
• Содержание и структура спецификации. Это также известно как словарь данных. Он должен включать все данные, связанные с каждой организацией, в дополнение к организационным блок-схемам.
• Спецификация. Руководящие принципы для самой спецификации должны быть достаточно надежными, чтобы рассказать историю проекта разработки, и достаточно гибкими, чтобы допускать изменения в объеме и масштабе.

Структура исключительной SRS

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

Когда дело доходит до составления документа, ваша структура может выглядеть примерно так:

Цель/Введение

• Определения
• Обзор системы
• Ссылки

Overall description

• Product perspective
  • System Interfaces
  • User Interfaces
  • Hardware Interfaces
  • Software Interfaces
  • Communication Interfaces
  • Memory Constraints
• Design constraints
  • Операции
  • Требования к адаптации площадки
• Функции продукта
• Характеристики пользователя
• Ограничения, допущения и зависимости

Конкретные требования

• Требования к внешнему интерфейсу
• Требования
• Требования
• .
• Доступность
• Безопасность
• Ремонтопригодность
• Переносимость

Организация конкретных требований

Приведенный выше пример адаптирован из Руководства IEEE по спецификациям требований к программному обеспечению (Std 830-1993). IEEE — это организация, которая устанавливает отраслевые стандарты для требований SRS. Это наиболее широко используемый набор стандартов при создании СГД, и его можно адаптировать к потребностям каждого учреждения.

Определение структуры

Ниже приведены несколько ключевых компонентов приведенного выше примера:

Цель/Введение

В разделе «Цель» следует суммировать весь документ SRS. Это похоже на резюме бизнес-документов и задает тон проекту. Как правило, ключевые компоненты этого раздела включают определения, обзор систем и ссылки. Они помогают установить важные темы в проекте развития.

Общее описание

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

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

Особые требования

Целью раздела особых требований является подробное изложение всех требований, необходимых для разработки. Этот раздел предоставляет разработчикам основу для создания продукта в соответствии с требованиями.

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

Создание исключительного документа SRS

Теперь вы знаете, как создать исключительный документ SRS. Быстрый поиск покажет ряд шаблонов, к которым вы можете применить эти новые знания, если вы все еще не уверены на 100% в своих недавно изученных способностях.

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

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

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

Дополнительные ресурсы

• Блог BMC DevOps
• Конвейеры развертывания (CI/CD) в программной инженерии
• Что такое экстремальное программирование?
• Python и Go: в чем разница?
• Что такое ADDM? Объяснение обнаружения приложений и сопоставления зависимостей
• Картирование цепочки создания стоимости Wardley: что это такое и как создать свое

 

Эти сообщения являются моими собственными и не обязательно отражают позицию, стратегию или мнение BMC.

Видите ошибку или есть предложение? Пожалуйста, сообщите нам об этом по электронной почте blogs@bmc. com.

BMC приносит лучшую игру

BMC сотрудничает с 86% компаний из списка Forbes Global 50, а также с клиентами и партнерами по всему миру, чтобы создать свое будущее. Благодаря нашей истории инноваций, ведущим в отрасли решениям для автоматизации, управления операциями и услугами в сочетании с непревзойденной гибкостью мы помогаем организациям высвободить время и пространство, чтобы стать автономным цифровым предприятием, которое завоевывает возможности в будущем.
Узнать больше о BMC ›

Вам также может понравиться

Об авторе

Stephen Watts

Стивен Уоттс (Бирмингем, Алабама) участвует в различных публикациях, включая Search Engine Journal, ITSM.Tools, IT Chronicles, DZone и CompTIA.

Формат спецификации требований к программному обеспечению (SRS)

Улучшение статьи

Сохранить статью

• Уровень сложности: Easy
• Последнее обновление: 05 янв, 2023

Читать

Обсудить

Улучшить статью

Сохранить статью

Чтобы сформировать хорошую SRS, здесь вы увидите некоторые моменты, которые можно использовать и которые следует учитывать при формировании структуры хорошей SRS.

К ним относятся: 1. Введение

• (i) Назначение этого документа
• (ii) Область применения этого документа
• (iii) Обзор

2. Общее описание. Требования к производительности 4. Функциональные требования 4. Функциональные требования 6. Конструктивные ограничения 7. Нефункциональные атрибуты 8. Предварительный график и бюджет 9. Приложения Спецификация требований к программному обеспечению (SRS) Формат , как следует из названия, представляет собой полную спецификацию и описание требований к программному обеспечению, которое необходимо выполнить для успешной разработки программная система. Эти требования могут быть как функциональными, так и нефункциональными в зависимости от типа требования. Взаимодействие между различными заказчиками и подрядчиками осуществляется потому, что необходимо полностью понять потребности заказчиков. В зависимости от информации, собранной после взаимодействия, разрабатывается SRS, описывающая требования к программному обеспечению, которые могут включать изменения и модификации, необходимые для повышения качества продукта и удовлетворения требований заказчика.

1. Введение:
   • (i) Цель этого документа – Сначала объясняется и описывается основная цель, почему этот документ необходим и какова цель документа.
   • (ii) Область действия этого документа – В этом документе описывается и объясняется общая рабочая и основная цель документа, а также его ценность для клиента. Он также включает описание стоимости разработки и требуемого времени.
   • (iii) Обзор –
     Здесь объясняется описание продукта. Это просто резюме или общий обзор продукта.
2. Общее описание : Здесь общие функции продукта, которые включают в себя цель пользователя, характеристики пользователя, особенности, преимущества, о том, почему упоминается его важность. Также описаны особенности пользовательского сообщества.
3. Функциональные требования: Здесь полностью объясняется возможный результат программной системы, который включает в себя эффекты, связанные с работой программы. Все функциональные требования, которые могут включать расчеты, обработку данных и т. д., расположены в ранжированном порядке.
4. Требования к интерфейсу : Здесь полностью описаны и объяснены программные интерфейсы, которые означают, как программа взаимодействует друг с другом или с пользователями в форме любого языка, кода или сообщения. Примерами могут быть разделяемая память, потоки данных и т. д.
5. Требования к производительности : Здесь объясняется, как программная система выполняет желаемые функции при определенных условиях. Также поясняется требуемое время, требуемая память, максимальная частота ошибок и т. д.
6. Ограничения проекта : Здесь ограничения, которые просто означают ограничение или ограничение, указаны и объяснены для проектной группы. Примеры могут включать использование определенного алгоритма, ограничения аппаратного и программного обеспечения и т. д.
7. Нефункциональные атрибуты : Здесь объясняются нефункциональные атрибуты, которые требуются программной системе для повышения производительности. Примеры могут включать безопасность, переносимость, надежность, возможность повторного использования, совместимость приложений, целостность данных, масштабируемость и т. д.
8. Предварительный график и бюджет: В этом документе объясняются первоначальная версия и бюджет плана проекта, которые включают общую продолжительность, необходимую для разработки проекта, и общие затраты, необходимые для разработки проекта.
9. Приложения : В нем дается и поясняется дополнительная информация, такая как ссылки на места сбора информации, определения некоторых конкретных терминов, акронимов, сокращений и т. д.

Использование документа СГД:

1. Команда разработчиков требует его для разработки продукта в соответствии с потребностями.
2. Планы тестирования создаются группой тестирования на основе описания внешнего поведения.
3. Обслуживающему и вспомогательному персоналу это нужно, чтобы понять, что должен делать программный продукт.