Самое полное руководство по управлению требованиями и отслеживаемости
Документ спецификации требований к программному обеспечению (SRS) — это важный документ для разработки программного обеспечения, который содержит подробное описание потребностей и требований конкретного проекта. В нем излагаются цели, объем, справочная информация, детали проекта, план реализации и другие связанные действия. Документ SRS служит контрактом между заказчиком и разработчиком, чтобы гарантировать, что обе стороны понимают спецификации и ожидания от разрабатываемого продукта. Кроме того, это помогает снизить риски, гарантируя, что все заинтересованные стороны полностью понимают, что от них ожидается на каждом этапе проекта.
Хорошо составленный документ SRS должен быть полным, четким и кратким, чтобы его могли легко понять как разработчики, так и клиенты. Кроме того, наличие SRS гарантирует, что любые изменения или обновления продукта во время разработки можно будет легко задокументировать и отследить. Это помогает свести к минимуму путаницу и гарантирует, что конечный продукт соответствует всем требованиям, указанным в документе. В целом SRS является важным инструментом для успешных проектов по разработке программного обеспечения, поскольку обеспечивает четкую основу для достижения успеха. При правильном использовании он может помочь командам достичь качественных результатов с минимальными усилиями.
Как написать документы системных требований (SRS)
Спецификация требований к программному обеспечению против спецификации бизнес-требований
Люди иногда смешивают концепции программного обеспечения и спецификаций бизнес-требований. На самом деле они оба совершенно разные.
Основное различие между спецификацией требований к программному обеспечению и спецификацией бизнес-требований заключается в том, что в первой содержится вся информация, относящаяся к программному обеспечению, а во второй — вся информация, относящаяся к бизнесу.
Спецификация требований к программному обеспечению (SRS)
Спецификация бизнес-требований (BRS)
Он определяет функциональные и нефункциональные требования, которые присутствуют в программном обеспечении.
Это официальный документ, в котором описываются различные требования, предъявляемые клиентом/заинтересованными сторонами.
Он основан на Спецификации бизнес-требований (BRS).
Он выводится из требований и взаимодействий клиента.
Он создается системным аналитиком, системным архитектором или бизнес-аналитиком.
Он создается бизнес-аналитиком.
В нем также на высоком уровне описаны как технические, так и функциональные характеристики программного обеспечения.
Он описывает функциональные характеристики программного обеспечения на очень высоком уровне.
Он имеет дело с ресурсами, которые предоставляет компания.
Он имеет дело с бизнес-требованиями.
Он описывает, как бизнес функционирует при использовании программного обеспечения или приложения.
Он определяет потребности клиента.
Документ используется от начала до конца проекта.
Таблицы и варианты использования включены.
Таблицы и варианты использования не включены.
Основные компоненты SRS
Основные разделы спецификации требований к программному обеспечению:
- Бизнес Драйверы – В этом разделе описаны причины, по которым заказчик хочет построить систему. Этот раздел также включает проблемы, с которыми клиент сталкивается при использовании текущей системы, и возможности, которые предоставит новая система.
- Бизнес-модель – В этом разделе обсуждается бизнес-модель, которую должна поддерживать система. Кроме того, он включает различные другие детали, такие как организационный и бизнес-контекст, основные бизнес-функции и блок-схемы процессов системы.
- Функциональные и системные требования – В этом разделе обычно подробно описываются требования, которые организованы в иерархическую структуру. Функциональные требования находятся на верхнем уровне, а подробные системные требования перечислены в виде подпунктов.
- Варианты использования системы – Этот раздел состоит из схемы вариантов использования унифицированного языка моделирования (UML), объясняющей все ключевые внешние объекты, которые будут взаимодействовать с системой, и различные варианты использования, которые им придется выполнять.
- Технические требования – В этом разделе обсуждаются все нефункциональные требования, составляющие техническую среду, и технические ограничения, в которых будет работать программное обеспечение.
- Системные качества – В этом разделе определяются многочисленные качества системы, такие как надежность, удобство обслуживания, безопасность, масштабируемость, доступность и ремонтопригодность.
- Ограничения и предположения – В этом разделе описаны все ограничения, накладываемые на конструкцию системы с точки зрения заказчика. Здесь также обсуждаются различные предположения инженерной группы о том, чего ожидать во время разработки.
- Критерии приема – Подробная информация обо всех условиях, которые должны быть выполнены перед передачей системы конечным потребителям, обсуждаются в этом разделе.
Структура СГД
1. Введение —
Во введении объясняется значение SRS в целом, его возможности для вашей команды и его структура.
1.1. Цель
Здесь объясните цель и структуру документации по программному обеспечению SRS: типы требований, которые будут рассмотрены, а также персонал, который будет ее использовать.
Этот раздел должен быть коротким: достаточно 1-2 абзацев.
1.2. Целевая аудитория
Вы можете углубиться и объяснить, как заинтересованные стороны и команды будут работать с SRS, а также участвовать в ее разработке. Обычно это владельцы продукта, инвесторы, бизнес-аналитики, разработчики, иногда тестировщики и операционный персонал. Вся структура определяется вашим подходом к разработке программного обеспечения и организационной структурой команды.
1.3. Использование по назначению
Опишите, в каких ситуациях ваша команда будет использовать SRS. Обычно его используют в следующих случаях:
- проектирование и мозговой штурм новых функций
- планирование продолжительности проекта, спринтов, оценка затрат
- оценка рисков
- мониторинг и измерение успеха команды
- конфликтные ситуации, когда вовлеченные стороны имеют разное видение качественно выполненного продукта.
1.4. Объем
В этой части рассматривается объем продукта, поэтому вам необходимо дать краткий обзор системы — ее основное назначение, функции и положение. Это сравнимо с тем, как вы объясняете продукт на собрании заинтересованных сторон, за исключением того, что вам разрешено более глубоко вникать в технические особенности.
В этом разделе должны быть описаны:
- Ожидается, что все типы пользователей будут взаимодействовать с системой
- Все основные части архитектуры
1.5 Определения и сокращения
В вашем документе команда часто использует определенные слова. Устранение возможных недоразумений, подключение новых разработчиков и разрешение конфликтных ситуаций станет проще, если вы проясните значение этих слов.
Вышеупомянутые компоненты составляют определение. Определения предоставляют информацию о функции, базовых технологиях, целевых лицах, бизнес-объектах (пользователях, клиентах, посредниках) и заинтересованных сторонах. Вы можете использовать аббревиатуру для более быстрого написания SRS, если хотите. Документ будет доступен для чтения до тех пор, пока он включен в таблицу определений.
2. Общее описание
Во второй части вы описываете читателям основные функции продукта, целевых пользователей и возможности системы. Это описание концентрируется только на ключевых функциях и архитектуре программного обеспечения, не вдаваясь в подробности о надстройках и соединениях.
2.1 Потребности пользователей
Эта часть является вопросом выбора, поэтому некоторые организации предпочитают не включать ее в свою техническую документацию SRS. Мы считаем, что лучше прямо сейчас перечислить проблемы, которые вы хотите решить с помощью вашего функционала. Это пригодится позже при мозговом штурме и мониторинге функций. Вы можете вернуться к этому разделу в любое время в процессе разработки продукта и посмотреть, не отклонилась ли команда взаимодействия с пользователем с намеченного пути.
Потребности относятся к проблемам, которые пользователи смогут решить с помощью системы. Вы можете разделить эти потребности на подкатегории, если имеете дело с сильно сегментированной аудиторией. Старайтесь не вдаваться в подробности о потребностях каждого пользователя. Вам нужно оставить место для интерпретации на тот случай, если проблема окажется более серьезной, чем вы думали изначально.
2.2 Допущения и зависимости
Предположения — это предположения команды о продукте и его возможностях, которые будут правильными в 99% ситуаций. Естественно предположить, например, что платформа, помогающая водителям ориентироваться в ночное время, будет использоваться преимущественно в ночном режиме.
Каково значение предположений? Они позволяют в первую очередь сосредоточиться на наиболее важных функциях приложения. Это предположение помогает понять, что дизайнеры должны разработать интерфейс, подходящий для видения в темноте, для помощника вождения в ночное время. Некоторые пользователи, безусловно, могут открыть приложение в течение дня, но это далеко не так, поэтому вам не нужно сразу включать связанные элементы в прототип.
3. Особенности системы и требования
В этой части подробно рассматриваются характеристики продукта и критерии исполнения. Поскольку предыдущие два раздела посвящены продукту в целом, здесь вы найдете более подробное описание.
3.1 Функциональные требования
указываются в списке функций, которые будут выполняться в системе. Эти критерии касаются вопроса «что будет создано?» а не «как» и «когда».
Функциональные требования начинаются с описания требуемой функциональности в зависимости от того, насколько она важна для приложения. Если вы хотите сначала поработать над этим, вы можете начать с дизайна, но затем вам следует перейти к разработке. Функциональные требования не содержат подробностей о стеках технологий, поскольку они могут меняться по ходу проекта. Вместо того, чтобы концентрироваться на внутренней логике, функциональные требования сосредотачиваются на функциональности конечного пользователя.
3.2 Требования к внешнему интерфейсу
Функциональные требования составляют значительную часть спецификации системных требований. Чтобы охватить все необходимые функции системы, вам понадобится 4-5 страниц информации. Некоторые команды разбивают их по темам, чтобы документ было легче читать.
Как правило, компоненты проектирования SRS рассматриваются отдельно от серверной части и бизнес-логики. Это имеет смысл, поскольку дизайнеры, а не разработчики, занимаются большей частью этой области, а также потому, что именно здесь начинается процесс разработки продукта.
В зависимости от проекта требования к внешнему интерфейсу могут состоять из четырех типов:
- Интерфейс пользователя
- Программный интерфейс
- Аппаратный интерфейс
- Интерфейс связи
Требования к внешнему интерфейсу описывают элементы страницы, которые будут видны конечному клиенту. Они могут включать в себя список страниц, элементы дизайна, ключевые стилистические темы, даже художественные элементы и многое другое, если они необходимы для продукта.
3.3 Системные требования
Системные требования продукта определяют условия, при которых он может использоваться. Обычно они относятся к аппаратным спецификациям и функциям. Требования к оборудованию SRS часто определяются минимальным и максимальным диапазонами, а также порогом оптимальной производительности продукта.
Создание системных требований перед началом создания продукта может показаться сложным, но это необходимо. Разработчики должны придерживаться требований к оборудованию, чтобы им не пришлось перезапускать проект позже. Мобильные приложения (с множеством переменных, которые необходимо учитывать) и приложения, требующие высокой реактивности (игры, любой продукт с VR/AR или IoT), особенно уязвимы.
3.4 Нефункциональные требования
Для многих организаций эта часть SRS является самой сложной. Если функциональные требования касаются вопроса о том, что создавать, то нефункциональные стандарты определяют, как это сделать. Они устанавливают критерии того, насколько эффективно должна работать система. В эту область включены пороговые значения производительности, безопасности и удобства использования.
Настоящая ценность заключается в том, что трудно определить нефункциональные требования. Дать определение таким фразам, как «параллелизм» или «переносимость», сложно, поскольку они могут иметь различное толкование для всех вовлеченных сторон. В результате мы выступаем за присвоение каждому нефункциональному требованию оценки. Вы можете пересмотреть требования вашего проекта в любое время, чтобы увидеть, удовлетворяет ли текущая система первоначальным ожиданиям.
Каких ошибок следует избегать при составлении спецификации системных требований?
По мере роста ваших навыков в разработке SRS процесс будет ускоряться. Тем не менее, когда вы только начинаете, разумно иметь под рукой список типичных ошибок для справки. Для этого подумайте над этим:
- Пренебрежение включением всеобъемлющего глоссария: Содержит ли ваша SRS жаргон, с которым знакомы только люди в отрасли? Если это так, создайте простой для понимания раздел словаря и включите в него определения любых малоизвестных слов или выражений. Это поможет всем пользователям понять как цель документа, так и терминологию.
- Создание беспорядка путем объединения идей: Структурируйте свой документ упорядоченным образом и доставляйте информацию читателям в логической последовательности. Во избежание недопонимания или путаницы не смешивайте концепции по всему тексту.
- Незнание потребностей и желаний целевой аудитории: Чтобы понять ожидаемый результат от программного обеспечения, важно понять, кто будет его использовать, а также какие результаты ожидаются. Например, предположим, что приложение было создано для создания отчетов. Некоторые из его требований должны подразумевать, как пользователи могут нажимать определенные кнопки для получения различных документов. Чтобы по-настоящему понять, что требуется от этой программы отчетности, а также определить, кто будет ее использовать, вы должны иметь представление как о пользователях, так и об их ожиданиях в отношении функциональности.
- Быть двусмысленным: Убедитесь, что ваши потребности однозначны. SRS сформулирован так, чтобы избежать недоразумений, поэтому очень важно убедиться, что документ не вызывает путаницы. Для каждой функции или описания условия убедитесь, что вы не включаете функции, которые еще не были указаны.
Источник: visuresolutions.com
Бизнес требования к продукту примеры
Требование к программному обеспечению – это функциональная или нефункциональная потребность, которая должна быть реализована в системе. Функциональная потребность подразумевает предоставление пользователю определенной услуги.
Например, в контексте банковского приложения функциональное требование будет заключаться в том, что когда клиент выбирает функцию «Просмотр баланса», он должен иметь возможность просматривать последний баланс своего счета.
Требование к программному обеспечению также может быть нефункциональным, это может быть требование к производительности. Например, нефункциональное требование заключается в том, что каждая страница системы должна быть видна пользователям в течение 5 секунд.
Итак, в основном требования к программному обеспечению – это
- Функциональные или
- Нефункциональный
- Типы требований
- Другие источники требований
- Как анализировать требования
- Атомный
- Однозначно идентифицировано
- Полный
- Последовательный и однозначный
- Прослеживаемый
- Приоритет
- Проверяемый
- Заключение
Бизнес-требования : это требования высокого уровня, взятые из бизнес-целей проекта. Например, система мобильного банкинга предоставляет банковские услуги. Бизнес-требование, которое решено, это – сводка счета и оплата счета решаются как бизнес-требование (конечная цель, чтобы пользователь совершил транзакцию).
Требования к архитектуре и дизайну : эти требования более подробны, чем бизнес-требования. Он определяет общий дизайн, необходимый для реализации бизнес-требований. Для образовательной организации сценариями использования архитектуры и дизайна будет вход в систему, детали курса и т. д. Требования будут такими, как показано ниже.
Пример использования в банковской сфере;Требование
Оплата счетов;Этот вариант использования описывает, как клиент может войти в систему сетевых банковских операций и использовать средство оплаты счетов. ;Клиент увидит панель неоплаченных счетов зарегистрированных биллеров. Он может добавлять, изменять и удалять детали биллера. Клиент может настроить SMS, оповещения по электронной почте для различных действий по выставлению счетов. Он может видеть историю прошлых оплаченных счетов. ;Акторами, запускающими этот вариант использования, являются клиенты банка или обслуживающий персонал.
Системные и интеграционные требования : на самом низком уровне у нас есть системные и интеграционные требования. Это подробное описание каждого требования. Это могут быть пути пользователей, описанные повседневным деловым языком. Требования содержат множество деталей, чтобы разработчики могли приступить к написанию кода. Здесь в примере модуля оплаты счетов, где будет упомянуто требование для добавления биллера
Оплата счетов;Требования
Добавить биллеров;Имя поставщика коммунальных услуг. ;Номер клиента отношений. ;Автоматические платежи — Да / Нет. ;Оплатить весь счет — Да / Нет. ;Автоматический лимит платежей — не платить, если счет превышает указанную сумму.
Иногда на проекте вы можете не получить никаких требований или документов для работы. Но все же есть и другие источники требований, на которых вы можете основывать свое программное обеспечение. Другими источниками требований, на которые вы можете положиться, являются.
Другие источники требований
- разговор о проекте с бизнес-аналитиком, менеджером по продукту, руководителем проекта и разработчиками уже работающими над этим проектом;
- анализ предыдущей версии системы, которая уже внедрена в систему;
- анализ старых документов требований проекта;
- просмотр предыдущих отчетов об ошибках, некоторые из отчетов об ошибках превращаются в запрос на улучшение, который может быть реализован в текущей версии;
- изучите руководство по установке, если оно доступно, чтобы узнать, какие установки требуются;
- проанализируйте знания в предметной области или отрасли, которые команда пытается внедрить.
Давайте изучим, как анализировать требования. Требования проявляются на разных уровнях:
- Атомный
- Однозначно идентифицированный
- Полный
- Последовательный и недвусмысленный
- Прослеживаемый
- Приоритет
- Проверяемый
- В первом столбце указан – «тип требования».
- Во втором столбце указано – «некачественно сформулированное требование».
- В третьем столбец указано – «требование из второго столбца в удобоваримом варианте».
Требования к качеству;Пример некачественного требования;Пример хорошего требования
Атомный;Студенты смогут поступать в бакалавриат и аспирантуру.;Студенты смогут поступить на курсы бакалавриата. ; ;Студенты смогут поступить в аспирантуру. Однозначно идентифицированный; 1- Студенты смогут записаться на курсы бакалавриата 1- Студенты смогут записаться на курсы последипломного образования.; 1. Запись на курс. ; ;2. Студенты смогут поступить на курсы бакалавриата. ; ;3.
Студенты смогут поступить в аспирантуру. Полный;Пользователь-профессор войдет в систему, указав свое имя пользователя, пароль и другую соответствующую информацию.;Пользователь-профессор войдет в систему, указав свое имя пользователя, пароль и код отдела.
Последовательный и недвусмысленный; У студента будут либо курсы бакалавриата, либо курсы последипломного образования, но не то и другое одновременно. Некоторые курсы будут открыты как для студентов, так и для аспирантов.; У студента будет либо бакалавриат, либо аспирант, но не оба сразу. Прослеживаемый; Сохранять информацию о студенте, сопоставленную с BRD req.ID?;Ведение информации о студентах, привязанной к BRD req ID 4.1. Приоритет; Зарегистрированный студент — приоритет 1. Ведение информации о пользователе — приоритет 1. Записаться на курсы — приоритет 1. Просмотреть табель успеваемости — приоритет 1.; Регистрация студентов — приоритет 1. Ведение информации о пользователе — приоритет 2. Записать курсы-приоритет 1. Просмотр табеля успеваемости — приоритет 3. Проверяемый;Каждая страница системы будет загружена в приемлемое время.;Страницы регистрации студента и записи на курсы системы загрузятся в течение 5 секунд.
Вывод : чем конкретнее требование, тем лучше.
Теперь давайте подробно разберемся с каждым из этих требований, начиная с уровня Atomic.
Атомный
Таким образом, каждое ваше требование должно быть атомарным, а это значит, что оно должно быть на очень низком уровне детализации, чтобы его нельзя было разделить на компоненты. Здесь мы увидим два примера требований: атомарный и однозначно идентифицированный уровень требований.
Итак, продолжим с примером построения системы для сферы образования. Здесь плохое требование: «Студенты смогут поступить на курсы бакалавриата и магистратуры». Это плохое требование, потому что оно не атомарно, потому что в нем говорится о двух разных сущностях: бакалавриате и аспирантуре. Таким образом, очевидно, что это плохое требование, поэтому хорошим требованием соответствия было бы разделение его на два требования. Итак, один говорит о зачислении на курсы бакалавриата, а другой говорит о зачислении в аспирантуру.
Однозначно идентифицировано
Точно так же следующее требование к качеству – это проверка на однозначную идентификацию, здесь у нас есть два отдельных требования, но у них обоих одинаковый ID # 1. Итак, если мы ссылаемся на наше требование со ссылкой на ID #, но неясно, на какое именно требование мы ссылаемся, поскольку оба имеют одинаковый ID # 1. Таким образом, зачисления на курс за счет выделение с помощью уникальных идентификаторов должно иметь два требования: 1.1 id – это зачисление на курсы бакалавриата, а 1.2 id – зачисление на курсы последипломного образования.
Полный
Все требования должны быть выполнены в полном объеме. Например, здесь неверное требование гласит, что «профессор-пользователь войдет в систему, указав свое имя пользователя, пароль и другую соответствующую информацию». Здесь другая важная информация не ясна, поэтому другая важная информация должна быть изложена в хорошем требовании, чтобы сделать требование полным.
Последовательный и однозначный
Далее, каждое требование должно быть последовательным и недвусмысленным, поэтому здесь, например, у нас есть требования: «У студента будут либо курсы бакалавриата, либо курсы последипломного образования, но не оба сразу». Это одно требование, но есть еще одно требование, которое гласит: «Некоторые курсы будут быть открытыми как для студентов, так и для аспирантов».
Проблема в этом требовании заключается в том, что из первого требования кажется, что курсы разделены на две категории: курсы для аспирантов и курсы для аспирантов, и студент может выбрать любой из двух, но не оба. Но когда вы читаете другое требование, оно противоречит первому и говорит о том, что некоторые курсы открыты как для аспирантов, так и для студентов.
Таким образом, очевидно, что это плохое требование можно преобразовать в хорошее таким образом: «У студента будет либо курс бакалавриата, либо курсы последипломного образования, но не то и другое одновременно». Это означает, что каждый курс будет отмечен как курс бакалавриата или курс аспирантуры.
Прослеживаемый
Каждое требование должно быть отслеживаемым, потому что существуют разные уровни требований. Мы уже видели, что наверху у нас есть бизнес-требования, а затем у нас есть требования к архитектуре и дизайну, за которыми следуют требования системной интеграции.
Теперь, когда мы преобразуем бизнес-требования в требования к архитектуре и дизайну или преобразуем требования к архитектуре и дизайну в требования системной интеграции, необходима прослеживаемость. Это означает, что мы должны быть в состоянии взять все бизнес-требования и сопоставить их с одним или несколькими требованиями к архитектуре и дизайну программного обеспечения. Итак, вот пример неверного требования, в котором говорится: «Сохранять информацию о студенте — сопоставлена с идентификатором требования BRD?». Пример идентификатора требования здесь не приводится.
Таким образом, преобразовав его в хорошее требование, оно говорит то же самое, но отображает идентификатор требования 4.1. Так что отображение должно быть для каждого требования. Точно так же, как у нас есть требования к высокоуровневому и низкоуровневому сопоставлению, сопоставление также существует между требованиями системы и интеграцией с кодом, который реализует это требование, а также существует сопоставление между системой и требованиями интеграции с тестовым примером, который проверяет это конкретное требование .
Таким образом, отслеживаемость осуществляется на всех уровнях проекта.
Источник: logrocon.ru
Что такое бизнес-требования и пользовательские требования
Часто у начинающих дизайнеров возникают вопросы относительно понимания фундаментальных понятий, на которых держится процесс проектирования успешных продуктов.
Бизнес-цели и требования — это одно и тоже? Как их отличать?
Ответ: цель бизнеса, в основном, что-то продать (товар, услугу), он продает некую ценность; требование — это то, что по мнению бизнеса должно присутствовать в продукте и обеспечить продажу.
Возникли проблемы с пониманием бизнес-требований и пользовательских требований, они могут быть одинаковыми?
Ответ: бизнес продает решение некой проблемы пользователя, то есть бизнес предлагает ценность, цель бизнеса — получить прибыль; у пользователя есть некая проблема которую он хочет решить, или потребность которую он хочет удовлетворить минимальными усилиями — это его цель.
Пример
Петя кондитер, он продает торты, это его товар. Петя хочет продавать как можно больше тортов и заработать на этом — это цель бизнеса.
Чтобы продавать торты Пете нужны магазины с витринами, продавцами, кассами и прочее — это бизнес-требования.
Юля любит сладкое, любит разнообразие, любит пробовать что-то новое, она хочет сделать свою жизнь приятнее —это цель пользователя.
Юля хочет знать где находится ближайший магазин со сладостями, когда завезли что-то новенькое, прийдя в магазин она хочет знать цену товара, из чего он сделан и когда его изготовили — это требования пользователя.
Хочешь изучить UX/UI Design и научиться проектировать сайты и приложения?
Источник: medium.com