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

Почему проекты системной инженерии терпят неудачу?

Почему проекты в строго регулируемых отраслях терпят неудачу? Многие исследователи исследовали, почему системные и программные проекты терпят неудачу. В 2009 году группа Стэндиш провела исследование, которое показало, что большинство причин провала проектов связаны с требованиями.

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

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

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

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

Процесс разработки требований

Есть несколько действий, с которыми мы сталкиваемся при работе с требованиями. В цикле разработки требований есть пять основных видов деятельности, а именно:

1. Выявление требований – Это процесс сбора, анализа и понимания потребностей и ограничений заинтересованных сторон и пользователей на сезон. Пользователям нужна информация о домене, информация о существующей системе, правила, стандарты и т. д. На основе этой информации мы выявляем требования. После этого мы переходим к анализу требований и согласованию. 
2. Анализ требований и переговоры – Анализ – это процесс уточнения потребностей и ограничений пользователя на основе собранной и полученной информации. Затем мы переходим к работе с документацией. 
3. Требования Документация/спецификация – Получив техническое задание, переходим к документации. Мы четко и точно документируем потребности и ограничения пользователей. 
4. Проверка требований – Наконец, в процессе проверки мы указываем, что сезонные требования полны, кратки и ясны. 
5. Управление требованиями – Управление требованиями – это способ сбора, анализа, уточнения и приоритизации всех продуктов или требований на этапе разработки. На этом этапе также устанавливается прочная прослеживаемость между требованиями и источниками информации. 

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

Почему важно писать хорошие требования?

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

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

Чего мы достигаем, составляя большие требования?

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

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

Проблемы при написании требований

При написании требований люди сталкиваются с различными проблемами.

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

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

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

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

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

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

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

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

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

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

Стандарты написания требований?

EARS был бы эффективной методологией здесь. Это означает EASY Aподход к Requirements Syntax, Аластер Марвин. В этом методе мы пишем четким, лаконичным и понятным языком. Это улучшает весь рабочий процесс разработки требований и упрощает работу, делая вещи довольно простыми для понимания. 

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

• Каждое требование должно быть в форме полного предложения. Не следует использовать маркеры, аббревиатуры, аббревиатуры или модные словечки. Старайтесь составлять короткие, прямые и полные предложения. 
• Убедитесь, что в каждом требовании есть правильное подлежащее, сказуемое и глагол. Субъектом будет тип пользователя или система, о которой мы говорим. Предикатом могут быть условия, действия или желаемые результаты, которые мы ожидаем. Мы должны использовать такие слова, как «должен», «будет» и «должен», чтобы выразить некоторую необходимость, и такие слова, как «может», чтобы выразить необязательность в требовании. 
• Каждое требование должно эффективно объяснять конечный результат, который мы ожидаем от системы. 
• Кроме того, требование должно описывать качество, которое мы ожидаем от системы. Это помогает, когда мы измеряем конечный результат и видим, правильно ли реализовано требование или нет.

Основные компоненты документа с требованиями:

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

• Бизнес Драйверы – В этом разделе описаны причины, по которым заказчик хочет построить систему. Этот раздел также включает проблемы, с которыми клиент сталкивается при использовании текущей системы, и возможности, которые предоставит новая система.
• Бизнес-модель – В этом разделе обсуждается бизнес-модель, которую должна поддерживать система. Кроме того, он включает различные другие детали, такие как организационный и бизнес-контекст, основные бизнес-функции и блок-схемы процессов системы.
• Функциональные и системные требования – В этом разделе обычно подробно описываются требования, которые организованы в иерархическую структуру. Функциональные требования находятся на верхнем уровне, а подробные системные требования перечислены в виде подпунктов.
• Варианты использования системы – Этот раздел состоит из схемы вариантов использования унифицированного языка моделирования (UML), объясняющей все ключевые внешние объекты, которые будут взаимодействовать с системой, и различные варианты использования, которые им придется выполнять.
• Технические требования – В этом разделе обсуждаются все нефункциональные требования, составляющие техническую среду, и технические ограничения, в которых будет работать программное обеспечение.  
• Системные качества – В этом разделе определяются многочисленные качества системы, такие как надежность, удобство обслуживания, безопасность, масштабируемость, доступность и ремонтопригодность.
• Ограничения и предположения – В этом разделе описаны все ограничения, накладываемые на конструкцию системы с точки зрения заказчика. Здесь также обсуждаются различные предположения инженерной группы о том, чего ожидать во время разработки.
• Критерии приема – Подробная информация обо всех условиях, которые должны быть выполнены перед передачей системы конечным потребителям, обсуждаются в этом разделе.

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

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

Правила набора правильных требований

Существуют определенные правила, которым должны соответствовать требования, чтобы называться «Правильными».

• Завершенный – Документ с требованиями должен содержать достаточно информации, чтобы ваша команда разработчиков и тестировщики могли завершить продукт и убедиться, что он соответствует требованиям пользователя и не содержит ошибок.
• Согласованность – Поддерживать постоянный уровень детализации. Например, для пользовательских требований конечный пользователь должен быть субъектом каждого предложения. Точно так же для системных требований система должна быть подлежащим в каждом предложении.
• Возможность модификации – Требования могут меняться на протяжении всего жизненного цикла проекта. Журнал требований должен храниться, и должен быть возможен анализ влияния внесенных в него изменений на другие требования и элементы проекта.
• Приоритетность – Требования должны быть классифицированы с точки зрения важности. Не все характеристики, желаемые для системы, одинаково важны. Для этого было бы полезно установить правило для определения приоритетов требований на организационном уровне и адаптации его к каждому проекту. И работайте с пользователями, чтобы они могли расставлять приоритеты в требованиях.

Платформа ALM для требований Visure

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

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

Заключение

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