Спецификация требований: Правила составления Software requirements specification / Хабр

Правила составления Software requirements specification / Хабр

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

Что такое SRS ?

SRS — Software Requirement Specification — специальная документация для ПО которая содержит в себе информацию о том, как должна себя вести система, какие функции должна выполнять, какую нагрузку должна выдерживать и тд.

Зачем оно надо ?

Все предельно просто. Вы используете ТЗ (велосипед), я использую SRS (машину). Надеюсь аналогия получилась ясная? 🙂

Структура SRS

Ниже приведена структура на англ языке в raw виде. Чуть ниже в статье мы рассмотрим каждый пункт более подробно

• Introduction
  • Purpose
  • Document conventions
  • Intended Audience and Reading Suggestions
  • Project scope
  • References

• Overall Description
  • Product perspective
  • Product features
  • User classes and characteristics
  • Operating environment
  • Design and implementation constraints
  • User documentation
  • Assumptions and dependencies

• System features
  • System feature X (таких блоков может быть несколько)
    • Description and priority
    • Stimulus/Response sequences
    • Functional requirements

• External interface requirements
  • User interfaces
  • Software interfaces
  • Hardware interfaces
  • Communication interfaces

• Non functional requirements
  • Performance requirements
  • Safety requirements
  • Software quality attributes
  • Security requirements

• Other requirements
• Appendix A: Glossary
• Appendix B: Analysis Models
• Appendix C: Issues list

И так со структурой разобрались, теперь перейдем к разделам и тому, что в них надо писать.

Базовые требования ко всем разделам SRS

• Кратко, четко. Описывает все предельно кратко и четко. Насколько это возможно.
• Без двусмысленных описаний. Человек читающий SRS должен понимать именно то, что написано, а не что-то другое. Закон Мерфи: Если Вас могут понять неправильно, Вас поймут неправильно. Избегайте этого
• Простота и «читабельность». Не используйте каких либо слишком заумных оборотов. Красота в простоте 🙂
• DFD-диаграммы. Спецификация не может быть полной если мы не знаем что на входе в описываемый софт, а что на выходе. Все должно быть четко нарисовано.
• Степень детализации. Это эвристический параметр. Его можно определить так: если я могу свободно изложить информацию о функционале и написанное не вызывает у меня смущения, если требования однозначны и не подлежат никакому двоякому пониманию, если требования в достаточной для меня мере описывают поведение функционала, то проработку SRS можно считать завершенной

Пояснение каждого пункта структуры SRS

Introduction \ Purpose

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

Introduction \ Document conventions

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

Introduction \ References

В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.

Overall Description \ Product features

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

Overall Description \ Operating environment

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

Overall Description \ Design and implementation constraints

Данный раздел гнусный :). Он ограничивает полет мысли разработчика налагая стандарты разработки. Такими ограничениями могут быть, например, такие вещи:

• Язык программирования, база данных
• Стандарты кодирования
• Стандарты обмена данными
• Ограничения накладываемые Operational Enviroment, допустим совместимость только с ФФ
• Ограничения которые могут быть наложены бизнес-логикой проекта

Overall Description \ User documentation

Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.

System features \ System feature X

Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»

System features \ System feature X \ Description and priority

Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения?.. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.

System features \ System feature X \ Stimulus/Response sequences

Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор

System features \ System feature X \ Functional requirements

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

External interface requirements

Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.

Non functional requirements

Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.

Non functional requirements \ Performance requirements

Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.

Non functional requirements \ Software quality attributes

Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?

Non functional requirements \ Security requirements

Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп

Appendix A: Glossary

Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел. Вставляем ссылочки на такие пояснения. Такой себе словарик.

Appendix B: Analysis Models

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

Appendix C: Issues list

Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.

Заключение

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

P.S. прошу сильно не винить — первая статья более или менее среднего масштаба на хабре. Исправления в синтаксисе приветствуются (стараюсь писать грамотно, однако 7-ми классное образование по русскому языку накладывает свой отпечаток.)

Спецификация требований программного обеспечения — Википедия

Материал из Википедии — свободной энциклопедии

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — законченное описание поведения программы, которую требуется^{[уточнить]} разработать.

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

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

В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».

Рекомендуемая стандартом IEEE 830^[1] структура SRS

• Введение
  • Цели
  • Соглашения о терминах
  • Предполагаемая аудитория и последовательность восприятия
  • Масштаб проекта
  • Ссылки на источники

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

• Функциональность системы
  • Функциональный блок X (таких блоков может быть несколько)
    • Описание и приоритет
    • Причинно-следственные связи, алгоритмы (движение процессов, workflows)
    • Функциональные требования

• Требования к внешним интерфейсам
  • Интерфейсы пользователя (UX)
  • Программные интерфейсы
  • Интерфейсы оборудования
  • Интерфейсы связи и коммуникации

• Нефункциональные требования
  • Требования к производительности
  • Требования к сохранности (данных)
  • Критерии качества программного обеспечения
  • Требования к безопасности системы

• Прочие требования
  • Приложение А: Глоссарий
  • Приложение Б: Модели процессов и предметной области и другие диаграммы
  • Приложение В: Список ключевых задач

См. также

Примечания

Ссылки

Разница между Требованиями и Спецификацией в разработке программного обеспечения

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

Разработка программного обеспечения (Software Engineering) — это дисциплина по методической разработке программного обеспечения. Требования являются основой программного обеспечения. Сбор и анализ требований является основным этапом разработки программного обеспечения. Спецификация требований программного обеспечения (Software Requirements Specification, SRS) — это документ, который содержит проанализированные требования и фазы разработки, такие как проектирование, внедрение, использование SRS.

Содержание

1. Обзор и основные отличия
2. Что такое Требования в разработке программного обеспечения
3. Что такое Спецификация в разработке программного обеспечения
4. Сходство между Требованиями и Спецификацией в разработке программного обеспечения
5. В чем разница между Требованиями и Спецификацией в разработке программного обеспечения
6. Заключение

Что такое Требования в разработке программного обеспечения?

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

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

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

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

Другой тип требований — это бизнес-требования. Они определяют бизнес-цели, видение и задачи.

Что такое Спецификация в разработке программного обеспечения?

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

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

Сходства между Требованиями и Спецификацией в разработке программного обеспечения?

• Спецификация — это документ с проанализированными требованиями.

В чем разница между Требованиями и Спецификацией в разработке программного обеспечения?

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

Заключение — Требования против Спецификации в разработке программного обеспечения

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

Спецификация требований — QALight

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

В этой статье мы рассмотрим составляющие данного документа, рекомендованные стандартом IEEE 830 (структура SRS – Softwarerequirementsspecification):

Введение:

•   Цели

•   Соглашения о терминах

•   Предполагаемая аудитория и последовательность восприятия

•   Масштаб проекта

•   Ссылки на источники

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

•   Видение продукта

•   Функциональность продукта

•   Классы и характеристики пользователей

•   Среда функционирования продукта (операционная среда)

•   Рамки, ограничения, правила и стандарты

•   Документация для пользователей

•   Допущения и зависимости

Функциональность системы:

•   Функциональный блок X (таких блоков может быть несколько)

•   Описание и приоритет

•   Причинно-следственные связи, алгоритмы (движение процессов, workflows)

•   Функциональные требования

Требования к внешним интерфейсам

•   Интерфейсы пользователя (UX)

•   Программные интерфейсы

•   Интерфейсы оборудования

•   Интерфейсы связи и коммуникации

Нефункциональные требования

•   Требования к производительности

•   Требования к сохранности (данных)

•   Критерии качества программного обеспечения

•   Требования к безопасности системы

Прочие требования

•   Приложение А: Глоссарий

•   Приложение Б: Модели процессов и предметной области и другие диаграммы

•   Приложение В: Список ключевых задач

Несмотря на такое большое количество пунктов, которые входят в нашу спецификацию, все же «ядро» требований к приложению находится в функциональных требованиях. Зачастую, их представляют в виде пользовательских сценариев (Use cases).

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

Также, есть несколько требований к составлению самой спецификации:

•   Описание всех функций должно быть максимально кратким и четким.

•   Не допускать двусмысленных описаний: каждая сущность должна быть предельно ясна любому человеку.

•   В то же самое время: простота.

•   Детализация должна быть в рамках максимального понимания и избегания избыточного текста.

Стандарты и шаблоны для ТЗ на разработку ПО / Хабр

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34

• ГОСТ 19

• IEEE STD 830-1998

• ISO/IEC/ IEEE 29148-2011

• RUP

• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения

2. Назначение и цели создания (развития) системы

3. Характеристика объектов автоматизации

4. Требования к системе

5. Состав и содержание работ по созданию системы

6. Порядок контроля и приемки системы

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

8. Требования к документированию

9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;

2. Основания для разработки;

3. Назначение разработки;

4. Требования к программе или программному изделию;

5. Требования к программной документации;

6. Технико-экономические показатели;

7. Стадии и этапы разработки;

8. Порядок контроля и приемки;

9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

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

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия

• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)

• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

1. Введение

• 1. Назначение системы
• 2. Содержание системы (границы системы)
• 3. Обзор системы
  • 1. Содержание системы
  • 2. Функции системы
  • 3. Характеристики пользователей

• 4. Термины и определения

2. Ссылки

3. Системные требования

• 1. Функциональные требования
• 2. Требования к юзабилити
• 3. Требования к производительности
• 4. Интерфейс (взаимодействие) системы
• 5. Операции системы
• 6. Состояния системы
• 7. Физические характеристики
• 8. Условия окружения
• 9. Требования к безопасности
• 10. Управление информацией
• 11. Политики и правила
• 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
• 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

1. Введение

• 1. Назначение
• 2. Содержание (границы)
  • 3. Обзор продукта
  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователей
  • 4. Ограничения

• 4. Термины и определения

2. Ссылки

3. Детальные требования

• 1. Требования к внешним интерфейсам
• 2. Функции продукта
• 3. Требования к юзабилити
• 4. Требования к производительности
• 5. Требования к логической структуре БД
• 6. Ограничения проектирования
• 7. Системные свойства ПО
• 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.

• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

1. Введение.

• 1. Цель.
• 2. Краткая сводка возможностей.
• 3. Определения, акронимы и сокращения.
• 4. Ссылки.
• 5. Краткое содержание.

2. Обзор системы

• 1. Обзор вариантов использований.
• 2. Предположения и зависимости.

3. Детальные требований

• 1. Описание вариантов использования.
• 2. Дополнительные требования.
• 3. Другие функциональные требования.
• 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).

Также рекомендую ознакомиться со следующими материалами:

Спецификация программного обеспечения — это… Что такое Спецификация программного обеспечения?

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — законченное описание поведения программы, которую требуется разработать.

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

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

В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».

Рекомендуемая стандартом IEEE 830^[1] структура SRS

• Введение
  • Цели
  • Соглашения о терминах
  • Предполагаемая аудитория и последовательность восприятия
  • Масштаб проекта
  • Ссылки на источники

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

• Функциональность системы
  • Функциональный блок X (таких блоков может быть несколько)
    • Описание и приоритет
    • Причинно-следственные связи, алгоритмы (движение процессов, workflows)
    • Функциональные требования

• Требования к внешним интерфейсам
  • Интерфейсы пользователя (UX)
  • Программные интерфейсы
  • Интерфейсы оборудования
  • Интерфейсы связи и коммуникации

• Нефункциональные требования
  • Требования к производительности
  • Требования к сохранности (данных)
  • Критерии качества программного обеспечения
  • Требования к безопасности системы

• Прочие требования
  • Приложение А: Глоссарий
  • Приложение Б: Модели процессов и предметной области и другие диаграммы
  • Приложение В: Список ключевых задач

См. также

Примечания

Ссылки

ГОСТ 19.202-78 Единая система программной документации (ЕСПД). Спецификация. Требования к содержанию и оформлению (с Изменением N 1), ГОСТ от 18 декабря 1978 года №19.202-78

ГОСТ 19.202-78

Группа Т55

Единая система программной документации

СПЕЦИФИКАЦИЯ

Требования к содержанию и оформлению

Unified system for program documentation. Specification. Requirements to contents and form of presentation

МКС 35.080

Дата введения 1980-01-01

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. N 3351 дата введения установлена 01.01.80

ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в сентябре 1981 г. (ИУС 11-81).

Спецификация

1. Настоящий стандарт устанавливает форму и порядок составления программного документа «Спецификация», определенного ГОСТ 19.101-77.

Стандарт полностью соответствует СТ СЭВ 2090-80*.
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. — Примечание изготовителя базы данных.

(Измененная редакция, Изм. N 1).

2. Структура и оформление документа устанавливаются в соответствии с ГОСТ 19.105-78.

Информационную часть (аннотацию и содержание) допускается в документ не включать.

3. Спецификация является основным программным документом для компонентов, применяемых самостоятельно, и для комплексов.

Для компонентов, не имеющих спецификации, основным программным документом является «Текст программы».

Форма спецификации приведена в приложении.

4. Спецификация в общем случае должна содержать разделы:

документация;

комплексы;

компоненты.

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

5. В раздел «Документация» вносят программные документы на данную программу, кроме спецификации и технического задания, в порядке возрастания кода вида документа, входящего в обозначение.

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

3-5. (Измененная редакция, Изм. N 1).

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

7. Графы спецификаций заполняют следующим образом: в графе «Обозначение» указывают:

в разделе «Документация» — обозначения записываемых документов программы;

в разделе «Комплексы» — обозначения спецификаций комплексов, входящих в данный комплекс;

в разделе «Компоненты» — обозначения основных программных документов компонентов;

в графе «Наименование» указывают:

в разделе «Документация» — наименование и вид документа для документов на данную программу; полное наименование программы, наименование и вид документа для заимствованных документов;

в разделах «Комплексы» и «Компоненты» — полное наименование программы, наименование и вид документа;

в графе «Примечание» — дополнительные сведения, относящиеся к записанным в спецификации программам.

При отсутствии места в графе «Примечание» допускается записывать только порядковые номера примечаний. Текст примечаний записывают в конце соответствующих разделов спецификации. Допускается текст примечаний записывать на последних листах спецификации на листах без граф с проставлением порядкового номера примечания.

(Измененная редакция, Изм. N 1).

8. В графе «Обозначение» запись производят в одну строку. В остальных графах спецификации записи допускаются в несколько строк.

(Введен дополнительно, Изм. N 1).

ПРИЛОЖЕНИЕ (обязательное). ФОРМА СПЕЦИФИКАЦИИ

ПРИЛОЖЕНИЕ
Обязательное

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

Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
Единая система программной документации:
Сборник национальных стандартов. —
М.: Стандартинформ, 2010

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

— BMC Blogs

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

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

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

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

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

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

Опознаваемые запахи требований

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

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

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

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

Рекомендации для исключительной SRS

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

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

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

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

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

Назначение / Введение

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

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

• Перспектива продукта
  • Системные интерфейсы
  • Пользовательские интерфейсы
  • Аппаратные интерфейсы
  • Программные интерфейсы
  • Коммуникационные интерфейсы
  • Ограничения памяти
• Конструктивные ограничения
  • Операции
  • Требования к адаптации сайта
• Функции продукта
• Характеристики пользователя
• Ограничения, допущения и зависимости

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

• Требования к внешнему интерфейсу
• Функциональные требования
• Требования к характеристикам
• Требование к логической базе данных
• Программное обеспечение Системные атрибуты
  • Надежность
  • Наличие
  • Безопасность
  • Ремонтопригодность
  • Переносимость
• Организация особых требований

Приведенный выше пример адаптирован из IEEE Guide to Software Requirements Specifications (Std 830-1993).IEEE — это организация, которая устанавливает отраслевые стандарты требований SRS. Это наиболее широко используемый набор стандартов при создании SRS, который может быть адаптирован к потребностям каждого агентства.

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

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

Назначение / Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обнаружили ошибку или есть предложение? Сообщите нам об этом по электронной почте [email protected].

.

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

19

Компания по разработке программного обеспечения

• Компания

  Насчет нас

  Клиенты и отзывы

  Карьера

• Сервисы

  Консультации

  Разработка программного обеспечения на заказ

  Веб-разработка

  Разработка мобильных приложений

  Гарантия качества

  Ручное тестирование

  Автоматизированное тестирование программного обеспечения

  Сопровождение и поддержка

  Выделенная команда разработчиков программного обеспечения

• Экспертиза
• портфолио

  электронное обучение

  здравоохранение

  финансовый

  полное портфолио

• Insights

  Разработка программного обеспечения на заказ

  электронное обучение

  Бизнес-аналитика

  Healthtech

  Финансовые

  Мобильная разработка

  Веб-разработка

Связаться с нами
Связаться с нами
Связаться с нами

ОТРАСЛИ

Электронное обучение

Здравоохранение

Гостеприимство

Финансовые

Страхование

Телекоммуникации

Виды спорта

Интернет вещей

Электронная коммерция

Производство

Увидеть все

РЕШЕНИЯ

Бизнес-аналитика

Разработка игр

LMS

LXP

Корпоративная TMS

EHR \ EMR

Голос и речь

ERP

CRM

Сообщества

Предприятие

КЛЮЧЕВЫЕ ТЕХНОЛОГИИ

Джава

PHP

.СЕТЬ

Sharepoint \ Office 365

React Native

ReactJS

Блокчейн

Laravel

Joomla

Увидеть все

ДРУГОЙ

Разработка API

Разработка базы данных

Мобильные приложения

Разработка SAAS

• КОМПАНИЯ

  Насчет нас

  Клиенты и отзывы

  Карьера

• СЕРВИСЫ

  Консультации

  Разработка программного обеспечения на заказ

  веб-разработка

  Мобильная разработка

  Гарантия качества

  Ручное тестирование

  Автоматизированное тестирование программного обеспечения

  Сопровождение и поддержка

  Выделенная команда разработчиков программного обеспечения

• ЭКСПЕРТИЗА

  ОТРАСЛИ

  Электронное обучение

  Здравоохранение

  Гостеприимство

  Финансовые

  Страхование

  Телекоммуникации

  Виды спорта

  Интернет вещей

  Электронная коммерция

  Производство

  Увидеть все

  РЕШЕНИЯ

.

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

Вот сценарий: вы завершаете свой последний проект HTML-справки… больше никаких поздних ночей или выходных… возвращаемся к «нормальной» 50-часовой рабочей неделе. В этот момент руководитель группы разработки входит в ваш офис и говорит, что только что получила разрешение вашего менеджера на то, чтобы вы помогли команде разработчиков «составить шаблон спецификаций требований к программному обеспечению для следующего крупного проекта».

«А что?» — спросите вы с полушокированным видом.Наступает паника. «Чем я заслужил это? Даже не знаю с чего начать! Может быть, кто-то из списка TECHWR-L сможет помочь… »

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

В этой статье описывается, что представляет собой документ со спецификациями требований к программному обеспечению и почему он важен, обсуждается, как и почему технические писатели должны участвовать в их работе, а также обсуждаются критические элементы для написания SRS.Хотя в этой статье не рассматриваются все аспекты разработки SRS, она направлена ​​на то, чтобы помочь вам определить объем такого проекта, предоставить некоторые рекомендации по написанию SRS и предоставить дополнительные ресурсы. Надеюсь, с этой информацией вы не спросите: «Почему я?» но провозглашая: «Почему не я?»

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

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

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

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

Хорошо спроектированная, хорошо написанная SRS выполняет четыре основные задачи:

• Обеспечивает обратную связь с заказчиком. SRS — это гарантия клиента того, что организация-разработчик понимает проблемы или проблемы, которые необходимо решить, и поведение программного обеспечения, необходимое для решения этих проблем. Следовательно, SRS должна быть написана на естественном языке (в отличие от формального языка, описанного далее в этой статье), однозначным образом, который может также включать диаграммы, таблицы, диаграммы потоков данных, таблицы решений и так далее.
• Разбивает проблему на составные части. Простой акт записи требований к программному обеспечению в хорошо продуманном формате упорядочивает информацию, устанавливает границы вокруг проблемы, укрепляет идеи и помогает упорядоченно разбить проблему на составные части.
• Используется в качестве исходных данных для проектной спецификации. Как упоминалось ранее, SRS служит родительским документом для последующих документов, таких как спецификация программного обеспечения и техническое задание.Следовательно, SRS должна содержать достаточно подробностей в требованиях к функциональной системе, чтобы можно было разработать проектное решение. Он служит для проверки продукта. SRS также
• Он служит родительским документом для стратегий тестирования и проверки, которые будут применяться к требованиям для проверки.

Спецификации требований к программному обеспечению обычно разрабатываются на первых этапах «разработки требований», которая является начальной фазой разработки продукта, на которой собирается информация о том, какие требования необходимы, а какие нет.Эта стадия сбора информации может включать посещение объекта, анкетирование, опросы, интервью и, возможно, анализ окупаемости инвестиций (ROI) или анализ потребностей клиента или текущей бизнес-среды клиента. Фактическая спецификация, таким образом, пишется после того, как требования будут собраны и проанализированы.

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

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

• Технические писатели — это опытные сборщики информации, идеально подходящие для выявления и формулирования требований клиентов. Присутствие технического писателя в группе по сбору требований помогает сбалансировать тип и объем информации, полученной от клиентов, что может помочь улучшить спецификации требований к программному обеспечению.
• Технические писатели могут лучше оценивать и планировать проекты документации и лучше удовлетворять потребности клиентов в документации. Работа над SRS дает техническим писателям возможность узнать о потребностях клиентов из первых рук — на ранних этапах процесса разработки продукта.
• Технические писатели знают, как определить вопросы, которые беспокоят пользователя или клиента относительно простоты использования и удобства использования. Затем технические писатели могут взять эти знания и применить их не только к разработке спецификаций и документации, но и к разработке пользовательского интерфейса, чтобы гарантировать, что UI (пользовательский интерфейс) моделирует требования заказчика.
• Технические писатели, вовлекаемые на раннем этапе и часто в процесс, могут стать информационным ресурсом на протяжении всего процесса, а не сборщиками информации в конце процесса.

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

Какого рода информацию должна включать SRS?

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

1. Интерфейсы
2. Функциональные возможности
3. Уровни эффективности
4. Структуры данных / элементы
5. Безопасность
6. Надежность
7. Безопасность / конфиденциальность
8. Качество
9. Ограничения и ограничения

Но как эти общие темы перевести в документ SRS? Что конкретно включает в себя документ СГД? Как это устроено? А как начать? Документ SRS обычно включает четыре ингредиента, как описано в следующих разделах:

1. Шаблон
2. Метод определения требований и связывания источников
3. Правила ведения хозяйственной деятельности
4. Матрица прослеживаемости

Начните с шаблона SRS

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

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

В таблице 1 показано, как может выглядеть базовая схема SRS.Этот пример является адаптацией и расширением стандарта IEEE 830-1998:

.

Таблица 1 Образец базовой схемы SRS

1. Введение 1.1 Цель 1.2 Условные обозначения в документе 1.3 Целевая аудитория 1.4 Дополнительная информация 1.5 Контактная информация / члены группы SRS 1.6 Ссылки 2. Общее описание 2.1 Обзор продукта 2.2 Функции продукта 2.3 Классы пользователей и характеристики 2.4 Операционная среда 2.5 Пользовательская среда 2.6 Ограничения проектирования / реализации 2.7 Предположения и зависимости 3. Требования к внешнему интерфейсу 3.1 Пользовательские интерфейсы 3.2 Аппаратные интерфейсы 3.3 Программные интерфейсы 3.4 Протоколы связи и интерфейсы 4. Системные характеристики 4.1 Системная характеристика A 4.1.1 Описание и приоритет 4.1.2 Действие / результат 4.1.3 Функциональные требования 4.2 Системная характеристика B 5.Другие нефункциональные требования 5.1 Требования к производительности 5.2 Требования безопасности 5.3 Требования безопасности 5.4 Атрибуты качества программного обеспечения 5.5 Проектная документация 5.6 Пользовательская документация 6. Прочие требования Приложение A: Терминология / Глоссарий / Список определений Приложение B: Определить

В таблице 2 представлена ​​более подробная схема спецификаций требований к программному обеспечению, показывающая структуру шаблона SRS.Это было перепечатано с разрешения его создателя Кена Ригби.

Таблица 2 Образец более подробной схемы SRS

1. Область применения	1.1 Идентификация. Укажите систему и программное обеспечение, к которым применяется этот документ, включая, если применимо, идентификационный номер (а), название (а), аббревиатуру (а), номер (а) версии и номер (а) выпуска. 1.2 Обзор системы. Укажите цель системы или подсистемы, к которой применяется этот документ. 1.3 Обзор документа. Обобщите цель и содержание этого документа. Этот документ состоит из шести разделов: Объем Справочные документы Требования Квалификационные положения Прослеживаемость требований Банкноты Опишите любые соображения безопасности или конфиденциальности, связанные с его использованием.
2. Справочные документы	2.1 Проектная документация. Укажите здесь документы системы управления проектами. 2.2 Прочие документы. 2.3 Приоритет. 2.4 Источник документов.
3. Требования	Этот раздел должен быть разделен на параграфы для определения требований к элементу конфигурации программного обеспечения компьютера (CSCI), то есть тех характеристик CSCI, которые являются условиями его принятия. Требования CSCI — это требования к программному обеспечению, сгенерированные для удовлетворения системных требований, назначенных этому CSCI.Каждому требованию должен быть присвоен уникальный идентификатор проекта для поддержки тестирования и прослеживаемости, и он должен быть сформулирован таким образом, чтобы для него можно было определить объективный тест. 3.1 Требуемые состояния и режимы. 3.2 Требования к возможностям CSCI. 3. 3. Требования к внешнему интерфейсу CSCI. 3.4 Требования к внутреннему интерфейсу CSCI. 3.5 Требования к внутренним данным CSCI. 3. 6 Требования к адаптации. 3. 7 Требования безопасности. 3. 8 Требования к безопасности и конфиденциальности. 3. 9 Требования к среде CSCI. 3. 10 Требования к компьютерным ресурсам.3.11 Факторы качества программного обеспечения. 3.12 Ограничения при разработке и реализации. 3.13 Требования к персоналу. 3.14 Требования, связанные с обучением. 3.15 Требования, связанные с логистикой. 3.16 Прочие требования. 3.17 Требования к упаковке. 3.18 Требования к приоритетности и критичности.
4. Квалификационные условия	Подлежит определению.
5. Прослеживаемость требований	Подлежит уточнению.
6. Примечания	Этот раздел содержит информацию общего или пояснительного характера, которая может быть полезной, но не является обязательной. 6.1 Использование по назначению. Эта спецификация требований к программному обеспечению должна… 6.2 Определения, используемые в этом документе. Вставьте сюда алфавитный список определений и их источник, если он отличается от заявленных источников, указанных в «Стандарте документации». 6.3 Сокращения, используемые в этом документе. Вставьте сюда алфавитный список сокращений и акронимов, если они не указаны в заявленных источниках, указанных в «Стандарте документации.» 6.4 Изменения по сравнению с предыдущим выпуском. Будет «неприменимо» для первоначального выпуска . Исправления должны определять метод, используемый для выявления изменений по сравнению с предыдущим выпуском.

Определить и связать требования с источниками

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

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

Таблица 3 В этой таблице-образце определены требования и приведены ссылки на их источники

Идент. №	Пункт №	Требование	Источник бизнес-правил
17	5.1.4.1	Понимание / общение с использованием протокола SMTP	IEEE STD xx-xxxx
18	5.1.4.1	Понимание / общение с использованием протокола POP	IEEE STD xx-xxxx
19	5.1.4.1	Понимание / общение с использованием протокола IMAP	IEEE STD xx-xxxx
20	5.1.4.2	Открывается с той же скоростью, что и OE	Пример использования Doc 4.5.4

Установление бизнес-правил для непредвиденных обстоятельств и ответственности

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

Создание матрицы отслеживания требований

Бизнес-правила для непредвиденных обстоятельств и ответственности могут быть определены явно в матрице отслеживания требований (RTM) или содержаться в отдельном документе и ссылаться на матрицу, как показано в примере в таблице 3.Такая практика не оставляет сомнений в отношении ответственности и действий при определенных условиях, которые происходят на этапе разработки продукта.

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

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

Что мне нужно знать о написании SRS?

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

Таблица 4 показывает основные характеристики качественной SRS, которые были первоначально представлены на апрельской 1998 г. конференции по технологиям программного обеспечения «Выполнение требований с первого раза». Перепечатано с разрешения Центра технологий Software Assurance в НАСА (http://www.gsfc.nasa.gov/). Эти качественные характеристики тесно связаны с так называемыми «индикаторами силы и слабости», которые будут определены ниже.

Таблица 4 10 качественных характеристик языка SRS

Функции и уровни производительности

Характеристика качества SRS	Что это значит
Завершено	SRS точно определяет все рабочие ситуации, которые могут возникнуть, и способность системы их успешно решать.
Согласованный	SRS совместимы, и требуемые характеристики качества (безопасность, надежность и т. Д.) Не отменяют этих функций. Например, единственный безопасный электрический кусторез для живой изгороди — это тот, который хранится в коробке и не подключается к каким-либо электрическим шнурам или розеткам.
Точный	SRS точно определяет возможности системы в реальной среде, а также способы взаимодействия и взаимодействия с ней.Этот аспект требований является серьезной проблемой для многих SRS.
Возможность изменения	Логическая иерархическая структура SRS должна способствовать любым необходимым модификациям (объединение связанных вопросов вместе и отделение их от несвязанных вопросов упрощает изменение SRS).
Рейтинг	Индивидуальные требования SRS упорядочены в иерархическом порядке в соответствии со стабильностью, безопасностью, предполагаемой легкостью / сложностью реализации или другим параметром, который помогает в разработке этого и последующих документов.
Тестируемый	SRS должна быть указана таким образом, чтобы однозначные критерии оценки (прошел / не прошел или какая-либо количественная мера) можно было вывести из самой SRS.
Отслеживаемый	Каждое требование в SRS должно быть однозначно идентифицировано для источника (вариант использования, государственное требование, отраслевой стандарт и т. Д.)
Однозначно	SRS должен содержать формулировки требований, которые можно интерпретировать только одним способом.Это еще одна область, которая создает значительные проблемы для разработки SRS из-за использования естественного языка.
Действит.	Действительная SRS — это такая система, в которой все стороны и участники проекта могут понять, проанализировать, принять или одобрить ее. Это одна из основных причин, по которой SRS написаны с использованием естественного языка.
Поддается проверке	Поддающаяся проверке SRS согласована от одного уровня абстракции к другому.Большинство атрибутов спецификации субъективны, и окончательная оценка качества требует технической проверки экспертами в предметной области. Использование индикаторов силы и слабости дает некоторые свидетельства того, что предпочтительные атрибуты присутствуют или отсутствуют.

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

Центр космических полетов Годдарда (GSFC) изучил десятки спецификаций требований НАСА, которые выявили девять категорий показателей качества SRS.Отдельные компоненты в каждой категории — это слова, фразы и структуры предложений, которые связаны с атрибутами качества. Эти девять категорий делятся на два класса: категории, относящиеся к отдельным заявлениям спецификаций, и категории, относящиеся ко всему документу SRS. В таблице 5 приведены классы, категории и компоненты этих показателей качества. Эта таблица также была первоначально представлена ​​на конференции программных технологий в апреле 1998 г. «Выполнение требований с первого раза».»Перепечатано с разрешения Центра технологий Software Assurance в НАСА (http://www.gsfc.nasa.gov/).

Таблица 5 Показатели качества, относящиеся к отдельным отчетам SRS

От

Императивы : Слова и фразы, указывающие на наличие какой-либо функции, функции или результата. Они перечислены ниже в порядке убывания силы.
Должность	Используется, чтобы диктовать предоставление функциональных возможностей.
Обязательно или нельзя	Чаще всего используется для установления требований или ограничений производительности.
Требуется к	Используется как императив в операторах SRS, если они написаны пассивным голосом.
Применяются	Используется для включения в качестве ссылки стандартов или другой документации в качестве дополнения к конкретным требованиям.
Ответственный за	Используется как императив в SRS, написанных для систем с предопределенной архитектурой.
Уилл	Используется для обозначения вещей, которые операционная среда или среда разработки должна предоставить указанной возможности. Например, выхлопная система автомобиля будет приводить в действие виджет ABC.
Если	Не часто используется как императив в заявлениях SRS; однако при использовании оператор SRS всегда читается как weak. Избегайте использования Should в ваших SRS.
Продолжение : фразы, следующие за императивом и вводящие спецификацию требований на более низком уровне.Существует корреляция с частотой использования продолжений и организацией и структурой SRS, вплоть до определенного момента. Чрезмерное использование продолжений часто указывает на очень сложную, детализированную SRS. продолжений ниже перечислены в порядке убывания их использования в НАСА SRS. Используйте продолжений в ваших SRS, но сбалансируйте частоту с соответствующим уровнем детализации, требуемым в SRS. 1. Ниже: 2. Следующее: 3.Далее: 4. В списке: 5. В частности: 6. Поддержка:
Директивы : Категории слов и фраз, которые указывают иллюстративную информацию в SRS. Высокое отношение общего количества директив к общему количеству текстовых строк, по-видимому, коррелирует с тем, насколько точно требования указаны в SRS. Директивы ниже перечислены в порядке убывания их появления в НАСА SRS.Включите использование директив в свои SRS. 1. Рисунок 2. Таблица 3. Например, 4. Примечание
Параметры : категория слов, обеспечивающая свободу действий при выполнении содержащих их операторов SRS. Эта категория слов ослабляет SRS, снижает контроль клиента над конечным продуктом и учитывает возможные риски затрат и сроков. Вам следует избегать их использования в вашей SRS. Опции ниже перечислены в том порядке, в котором они чаще всего встречаются в SRS НАСА. 1. Банка 2. Май 3. Дополнительно
Слабые фразы : категория статей, которые могут создавать неопределенность и множественную / субъективную интерпретацию. Общее количество слабых фраз , найденных в SRS, указывает на относительную неоднозначность и неполноту SRS. слабых фраз ниже перечислены в алфавитном порядке.
адекватный	может	легкий	предусмотреть
минимум	может быть	эффективный	своевременно
если применимо	, но не ограничиваясь	по возможности	ТБД
при необходимости	возможность	если возможно
минимум	до	нормальный
Размер: Используется для обозначения размера документа SRS и представляет собой общее количество следующих элементов: 1.Строки текста 2. Количество императивов 3. Субъекты СГД 4. Пункты
Текстовая структура : Относится к количеству идентификаторов выписок, найденных на каждом иерархическом уровне SRS, и указывает на организацию, последовательность и уровень детализации документа. Самые подробные SRS НАСА были девятиуровневыми. SRS высокого уровня редко бывает глубже четырех уровней. В SRS, которые считаются хорошо организованными и согласованным уровнем детализации, было текстовых структур, напоминающих пирамиды (несколько заголовков уровня 1, но каждый нижний уровень имеет больше пронумерованных утверждений, чем уровень над ним).Текстовые структуры в форме песочных часов (многие заголовки уровня 1, несколько средних уровней и многие на более низких уровнях) обычно содержат большее количество вводной и административной информации. Ромбовидные текстовые структуры (форма пирамиды с последующим уменьшением количества утверждений на уровнях ниже пирамиды) указывает на то, что темы, представленные на более высоких уровнях, рассматривались на различных уровнях детализации.
Глубина спецификации : Количество императивов, обнаруженных на каждом из уровней SRS структуры текста.Эти числа включают в себя количество элементов списка нижнего уровня, которые вводятся на более высоком уровне императивом и сопровождаются продолжением. Цифры дают некоторое представление о том, какая часть документа с требованиями была включена в SRS, и могут указывать на то, насколько лаконичен SRS в определении требований.
Статистика удобочитаемости : Измерение того, насколько легко взрослый может прочитать и понять документ с требованиями. Используются четыре статистики читабельности (рассчитываются Microsoft Word).Хотя статистика удобочитаемости является относительной количественной мерой, не жертвуйте достаточной технической глубиной своей SRS ради числа. 1. Индекс легкости чтения по Флешу 2. Индекс уровня успеваемости Флеша-Кинкейда 3. Индекс успеваемости Коулмана-Лиау 4. Индекс успеваемости по Бормуту

Заключение

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

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

Брукс, Фредерик П.Мл., Нет серебряной пули: сущность и случайности программной инженерии, IEEE Computer, vol. 15, нет. 1, апрель 1987 г., стр. 10-18.

Гаузе, Дональд К. и Вайнберг, Джеральд М., Исследование качества требований перед проектированием, Издательство Дорсет Хаус, Нью-Йорк, 1989.

IEEE Std 830-1993, Рекомендуемая практика для спецификаций требований к программному обеспечению, 2 декабря 1993 г.

Вигерс, Карл Э. Программные требования, Microsoft Press, Редмонд, Вашингтон, 1999.

Ресурсы для шаблонов моделей Как отмечалось ранее, вам следует сначала поискать документы SRS, разработанные вашей компанией.Эти документы не только легко доступны для вас, но также, вероятно, для продуктов, похожих на продукт, для которого вы разрабатываете SRS. Дополнительные ресурсы включают: Стандарт IEEE 830-1998 описывает шаблон SRS (Таблица 1 является адаптацией и расширением этого шаблона). Группа особого интереса руководства (SIG) STC предлагает страницу справочных документов по адресу http://www.stcsig.org/mgt/reference.htm , который включает образец шаблона и другие связанные ресурсы. В сети также доступны другие сайты, которые предлагают примеры реальных SRS и шаблонов. Быстрый поиск «спецификаций требований к программному обеспечению» в вашей любимой поисковой системе должен дать некоторые полезные результаты.

.

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

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

Что такое спецификация системных требований?

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

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

Почему SRS следует включать в процесс разработки программного обеспечения?

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

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

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

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

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

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

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

Как написать спецификацию системных требований

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

• Что должно делать приложение или программное обеспечение? Ответ на этот вопрос помогает определить основные функции и основное назначение программного обеспечения.
• Как должна себя вести программа? Это помогает понять, как программное обеспечение взаимодействует со средой, в которой оно развернуто; он также определяет спецификацию оборудования и определяет IHM: как программное обеспечение взаимодействует с конечными пользователями. Описываемое программное обеспечение может представлять собой целую систему, но иногда оно является частью более обширной системы. Затем важно определить, как эта часть взаимодействует с более крупной системой, как две системы взаимодействуют друг с другом. Спецификация требований к системе CRM — хороший пример, когда важно понимать, как должно вести себя программное обеспечение.
• Каковы требования к производительности? Например, он предоставит информацию о приемлемом времени ответа, о том, как быстро он должен реагировать и как быстро он должен обрабатывать проблемы, когда они возникают.
• Существуют ли требования или ограничения, которые следует учитывать или соблюдать? Он направлен на определение ограничений, которые необходимо учитывать при проектировании, разработке и развертывании системы.

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

Наброски могут отличаться от спецификации проекта к другому. Однако мы можем рассмотреть следующую схему:

• Введение. Первым шагом при написании спецификации требований является согласование того, что должно делать программное обеспечение, пишем ли мы спецификацию требований системы CRM или другую спецификацию требований системы. На этом этапе важно, чтобы команда разработчиков и владельцы продукта вместе определили и написали эту часть.Владелец продукта не обязательно обладает навыками для написания хорошей SRS, но команда разработчиков не знает, что нужно конечным пользователям. Вот почему на данном этапе важно, чтобы обе стороны тесно сотрудничали. В этом разделе важно поместить программное обеспечение для сборки в его контекст. Здесь мы рассмотрим причину, по которой необходимо создать программное обеспечение, кто будет использовать программное обеспечение, что ему следует или не следует делать (иногда полезно и необходимо упомянуть, чего нам не следует ожидать от программного обеспечения).Иногда некоторые термины специфичны для бизнеса, и их упоминание в документе важно для понимания спецификации и создания программного обеспечения. Очень важно дать определение этим техническим терминам, чтобы можно было понять их содержание. В конце вводной части мы можем включить краткий обзор документа, чтобы дать читателям представление о том, чего они могут ожидать от документа. Также важно упомянуть в SRS все документы, которые можно прочитать, чтобы иметь более полное представление о системе, и все ссылки также должны быть задокументированы.
• Общее описание: в разделе описания важно объяснить различные функции приложения. В этой части определяются аппаратные интерфейсы и пользовательские интерфейсы. На каком устройстве конечные пользователи ожидают получить доступ к приложению, например, или каковы функции программного обеспечения, как пользователи могут ожидать их увидеть в приложении, что отображается в меню, каковы другие части, такие как отчеты, экспорт и т. Д. так далее.?
• Особые требования: В этом разделе подробно описаны требования, чтобы упростить разработку продукта и проверку программного обеспечения в соответствии с требованиями.Здесь важно описать все входные данные, которые обрабатывает программное обеспечение, и все выходы, чтобы лучше определить взаимодействие с другими системами и облегчить интеграцию. Функциональные возможности, перечисленные в предыдущем разделе, будут подробно описаны здесь. Здесь также необходимо определить критерии эффективности. Может возникнуть соблазн оставить на потом некоторые части документации, которые могут измениться в процессе разработки или на более позднем этапе. Однако важно тщательно задокументировать SRS и обновлять содержимое, если это необходимо и когда необходимо.
• Ссылки: теперь это может показаться очевидным, когда мы упоминаем об этом, но важно включить информацию о содержании, чтобы ее было легче найти при необходимости.

Недобросовестные методы SRS

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

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

Различия между плохими и хорошими требованиями Примеры документов

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

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

Плохо написанная спецификация

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

Этот пример спецификации системы кажется ясным.Однако, когда мы проводим некоторый анализ, он представляет некоторые примеры плохой практики. В этой спецификации нет ясности, и в ней не указано:

• По выбору суммы:
  • как покупатель выбирает или указывает сумму, которую он хочет снять.
  • Есть ли список вариантов
  • может ли он вручную ввести деньги, которые он хочет вывести
  • какой лимит он может снять за разовую транзакцию
  • есть ли какое-либо правило для приемлемой суммы, которую клиент может снять
• Для проверки транзакции: каковы правила проверки?
• Для доставки денег: Клиент получает квитанцию ​​постоянно?

Написание хорошего примера спецификации

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

Когда покупатель выбирает меню: «Снять деньги», он имеет возможность выбрать одну из шести различных сумм на экране: 10, 20, 30, 50, 100, 200, 300 долларов или выбрать на экране сумму вручную. он хочет уйти. Сумма должна быть кратной сумме одного из билетов, выданных банкоматом, с учетом максимального количества билетов для транзакции.После того, как клиент выбрал сумму, он может нажать кнопку подтверждения, чтобы продолжить транзакцию, или нажать кнопку отмены, чтобы отменить транзакцию и получить обратно свою карту. Если клиент подтверждает выбранную сумму, система проверяет, позволяет ли его баланс снять запрошенную сумму и не достиг ли еще максимальной дневной суммы. Система также проверила, может ли банкомат выдать сумму: система проверяет, достаточно ли у банкомата денег для удовлетворения потребности клиента и кратна ли сумма доставленным билетам.Если проверка прошла успешно, система спрашивает клиента, хочет ли он получить квитанцию ​​для своей транзакции. Если клиенту требуется квитанция для транзакции, система готовит квитанцию, деблокирует карту клиента, доставляет деньги и квитанцию. Если проверка прошла успешно, но клиент не хочет получать квитанцию, система разблокирует карту клиента и доставит деньги. Если транзакция не подтверждена, банкомат освобождает карту клиента и отображает причину, по которой его транзакция была отклонена.Каждая транзакция должна занимать не более трех секунд.

В заключение

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

.

No related posts.