ТЗ: гостевые требования и спецификации — неотъемлемая часть успешного проекта

Как выглядит

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

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

Роль

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

Блок/фича

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

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

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

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

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

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

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

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

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

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

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

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

Выявление требований

Выявление требований — итеративный процесс, состоящий из следующих этапов:

1. Подготовка к выявлению.
2. Выявление.
3. Утверждение результатов.

Подготовка к выявлению требований

В процессе подготовки к выявлению требований необходимо ответить на следующие вопросы:

1. Что необходимо выяснить? — Анализируем имеющуюся информацию о системе:

а. Анализ текущего описания требований к системе.

b. Анализ текущей реализации системы.

c. Выявление недостающих и/или недостаточно описанных требований.

2. У кого? Где? — Определить источник требований:

а. Собрать список доступных источников, таких как:.

i. Документация.

ii. Артефакты бизнес-процессов и/или текущей реализации системы.

b. Определить список стейкхолдеров, которые могут выступать источником требований к системе.

3. Каким образом? — Выбрать оптимальный метод выявления требований.

Что такое BRS (спецификация бизнес-требований)?

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

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

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

Особенности БРС:

1. Это список всех требований, которые запросил клиент.
2. Он включает в себя цель продукта, пользователей, общий объем работ, все упомянутые возможности и функции, а также критерии удобства использования и производительности.
3. Варианты использования, а также диаграммы и таблицы не включены в этот тип статьи.
4. Высшее и среднее руководство, инвесторы в продукты и бизнес-аналитики являются основными пользователями BRS.

Обложки BRS:

1. Цель проекта.
2. Особенности и функциональные возможности продукта.
3. Требования к удобству использования.
4. Пользователи продукта.
5. Масштабы проекта.
6. Требования к производительности.

Выявление требований. Интервью

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

Подготовка к интервью

Подготовка к интервью состоит из следующих этапов:

1. Собрать информацию о собеседнике(ах):

а. Роль в проекте?

b. За какие вопросы ответственен?

2. Подготовить вопросы:

a. Сформулировать проблематику интервью.

b. Сформулировать вопросы.

c. Подготовить дополнительные вопросы.

3. Определить тайминг встречи.

a. Нужно стараться уложиться в один час. Чаще всего человек начинает терять концентрацию после 40 минут непрерывной беседы.

b. Для каждого вопроса определить необходимое время на обсуждение.

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

4. Согласовать календарь встреч.

a. Если предполагается несколько встреч — то не обходимо составить график встреч.

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

От себя рекомендую подготовить файл с вопросами и планом интервью. Для примера — вот шаблон, который использую я:

Протокол интервью

Проект:{}

Дата проведения:{}

Интервьюер: {Кто проводит интервью}

Интервьюируемый:{Кому задаём вопросы}

Проблематика:{Тема интервью}

Вопрос № 1:

Тайминг вопроса:

Текст вопроса:

Таймкод:

Ответы на вопрос:

Стейкхолдер 1 —

Стейкхолдер 2 —

Проведение Интервью

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

1. Всегда ведем запись встречи.

a. Спрашиваем собеседника, не против ли он вести запись разговора.

b. Включаем запись после согласия собеседника.

2. Small talk для разрядки.

a. Как настроение?

b. Как погода?

c. И т.д. и т.п.

d. Но не затягиваем, пара вопросов из вежливости, не более.

3. Начинаем с объявления проблематики.

4. Стараемся следовать плану встречи. Вопросы задаём последовательно.

5. Желательно в плане указываем тайм-код, в какую минуту разговора задан вопрос, чтобы упростить дальнейшую обработку протокола.

6. Стараемся раскрывать вопросы дополнительными вопросами. Беседа должна быть живой, не должна скатываться в сухой формат вопрос-ответ, иначе проще отправить собеседнику опросник и не тратить его время на встречу.

7. В конце обсуждения не лишним будет подтвердить позицию собеседника закрытым типом вопроса.

a. Например: Я правильно вас понял, что необходимо реализовать функционал следующим образом {Тезис}?

Обработка результатов Интервью

После проведения интервью необходимо письменно зафиксировать полученную информацию. Рекомендую делать это сразу после интервью. Итак:

1. Заполняем протокол встречи.

a. Читать краткий протокол встречи намного проще, чем смотреть часовую запись в поисках ответов.

2. Направляем участникам встречи результаты в формате «Вопрос — Зафиксированное решение».

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

Плюсы и минусы метода

Плюсы метода:

• Наиболее эффективный способ метод сбора требований.
• Меньшая вероятность недопонимания между собеседниками.
• Большая вероятность выявления «скрытых» требований.

Минусы метода:

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

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

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

Основные элементы спецификации программного обеспечения

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

Основными элементами спецификации программного обеспечения являются:

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

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

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

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

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

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

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

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

Материалы для самостоятельного изучения

Блоки знаний:

• Бизнес-анализ — раздел знаний, отвечающий за описание и формализацию бизнес-процессов. Прежде чем интерпретировать бизнес-процессы в виде ПО, необходимо их «правильно» описать и формализовать.
• Моделирование бизнес-процессов — изучение различных нотаций описания бизнес-процессов. Неразрывно связан с бизнес-анализом.
• Системный-анализ — раздел знаний, отвечающий за анализ процессов непосредственно в самом ПО.
• Моделирование систем — изучение нотаций описания систем ПО. Неразрывно связан с системным анализом.
• Документирование требований — изучение различных сред документирования информации о проекте и системе.
• Управление требованиями (согласование, управление изменениями, трассировка требований) — отдельный процесс в системе знаний об анализе в ИТ. Является одним из самых сложных процессов на долгосрочных проектах с большим количеством итераций.
• Прототипирование — изучение различных инструментов для моделирования интерфейсов и архитектуры ПО. Например: Figma для верстки макетов интерфейсов.

Книги:

• Вигерс, Карл: Разработка требований к программному обеспечению. 3-е издание, дополненное / Карл Вигерс, Джой Битти. — Санкт-Петербург : БХВ-Петербург, 2019. — 736 с.
• Ильяхов М., Сарычева Л. Пиши, сокращай. Как создавать сильный текст — 2017.
• Гэртнер, Маркус: ATDD — разработка программного обеспечения через приемочные тесты. — ДМК-Пресс, 2013. — ISBN 978-5-457-42706-8.
• Gojko Adzic, David Evans — Fifty Quick Ideas to Improve Your User Stories — 2014.
• Майкл Мескон, Майкл Альберт, Франклин Хедоури — Основы менеджмента

Хоп, Грегор Шаблоны интеграции корпоративных приложений (Signature Series) / Грегор Хоп, Бобби Вульф. — Москва : Вильямс, 2019. — 672 с.

Кон, Майк Пользовательские истории. Гибкая разработка программного обеспечения / Майк Кон. — Москва : Вильямс, 2018. — 256 с.

Паттон, Джефф Пользовательские истории. Искусство гибкой разработки ПО / Джефф Паттон — Санкт-Петербург : Питер, 2019. — 288 с.

Cockburn, Alistair Writing Effective Use Cases / Alistair Cockburn. — Addison-Wesley, 2001.

USE-CASE 2.0

Фаулер, Мартин UML. Основы. Краткое руководство по стандартному языку объектного моделирования / Мартин Фаулер. — Москва : Символ-Плюс, 2018. — 192 с.

Гойко, Аджич Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке / Аджич Гойко. — Москва : Альпина Паблишер, 2017. — 86 с.

Коберн, Алистер Быстрая разработка программного обеспечения/ Алистер Коберн. — Москва: Лори, 2002. — 336 с.

Корнипаев, Илья Требования для программного обеспечения: рекомендации по сбору и документированию / Илья Корнипаев. — Книга по требованию, 2013. — 118 с. Книга

Ми, Роберт Шаблоны корпоративных приложений / Роберт Ми, Мартин Фаулер. — Москва : Вильямс, 2018. — 544 с.

Мартин, Роберт Чистая архитектура. Искусство разработки программного обеспечения / Роберт Мартин. — Санкт-Петербург : Питер, 2018. — 352 с.

BABOK 3.0

SWEBOK 3.0

Виды спецификаций программного обеспечения

1. Техническая спецификация (ТЗ)

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

2. Функциональная спецификация

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

3. Дизайн-спецификация

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

4. Тестовая документация

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

5. Документация пользователя

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

6. Архитектурные спецификации

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

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

Составление технического задания на программирование

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

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

Что такое требования в программной инженерии?

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

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

Технический проект

На данном этапе выполняется комплекс наиболее важных работ, а именно:

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

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

Рабочая документация (рабочий проект)

На данном этапе осуществляется адаптация базовых средств программного обеспечения (операционной системы, СУБД, инструментальных сред конечного пользователя — текстовых редакторов, электронных таблиц и т.п.). Выполняется разработка программных модулей или методов обработки объектов – собственно программирование или создание программного кода. Проводятся автономная и комплексная отладка программного продукта, испытание работоспособности программных модулей и базовых программных средств. Для комплексной отладки готовится контрольный пример, который позволяет проверить соответствие возможностей программного продукта заданным спецификациям.

Основной результат работ этого этапа – создание эксплуатационной документации на программный продукт, включающей:

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

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