Самое полное руководство по управлению требованиями и отслеживаемости
Принятие нотации EARS для разработки требований
Содержание
Введение
Разработка требований — это критический этап разработки программного обеспечения, который закладывает основу для всего проекта. Точные и четко определенные требования необходимы для создания успешного программного продукта, отвечающего потребностям пользователей. Чтобы добиться этого, специалисты по программному обеспечению часто обращаются к различным методологиям и нотациям, и одной из таких нотаций, набирающей популярность, является нотация EARS (Easy Approach to Assessment Syntax). В этой статье мы рассмотрим нотацию EARS, ее преимущества и то, почему ее принятие может улучшить процесс разработки требований.
Понимание нотации EARS
Что такое УШИ?
EARS, что означает «Легкий подход к синтаксису требований», представляет собой нотацию, предназначенную для облегчения сбора и документирования требований в ясной и краткой форме. Он был разработан исследователями как ответ на сложность и неоднозначность, часто связанные с традиционными методами документирования требований. EARS упрощает процесс разработки требований, предоставляя структурированный способ выражения требований с использованием естественного языка.
Ключевые элементы EARS
Нотация EARS включает в себя несколько ключевых элементов, что делает ее универсальным и эффективным инструментом разработки требований:
- Цели. В основе EARS лежат цели, которые представляют собой задачи высокого уровня, которых должна достичь программная система. Цели выражаются с использованием естественного языка и служат отправной точкой для определения требований.
- Мягкие цели: Мягкие цели — это нефункциональные требования или атрибуты качества, которые необходимы для успеха проекта, но не поддаются простой количественной оценке. Примеры включают удобство использования, ремонтопригодность и масштабируемость.
- Задачи: Задачи представляют собой конкретные действия или действия, которые необходимо выполнить для достижения цели. Они часто описываются в формате глагол-дополнение, что упрощает их понимание.
- Операнды: Операнды используются для предоставления дополнительной информации и ограничений, связанных с задачами. Они помогают уточнить, как и при каких условиях следует выполнять задачу.
- Предположения о предметной области: EARS поощряет документирование предположений о предметной области, в которой будет работать программное обеспечение. Эти предположения обеспечивают контекст и помогают обеспечить соответствие требований реальным сценариям.
Преимущества использования нотации EARS
Улучшенная ясность и точность
Одним из основных преимуществ использования нотации EARS является повышенная ясность и точность, которую она привносит в документацию требований. Структурируя требования в виде целей, задач и программных целей, EARS облегчает заинтересованным сторонам понимание того, что ожидается от программной системы. Такая ясность уменьшает двусмысленность и неправильное толкование, что в конечном итоге приводит к более точным требованиям.
Выражение естественного языка
EARS использует естественный язык, делая его доступным для широкого круга заинтересованных сторон, включая нетехнических членов команды. Такая инклюзивность гарантирует, что каждый, кто участвует в проекте, сможет внести свой вклад и понять требования, способствуя сотрудничеству и общему видению.
Гибкость и адаптивность
EARS — это гибкая система обозначений, которую можно адаптировать в соответствии с конкретными потребностями проекта. Независимо от того, разрабатываете ли вы систему, критическую для безопасности, или приложение, ориентированное на пользователя, EARS может удовлетворить различные типы требований. Эта адаптивность делает его ценным инструментом для различных контекстов разработки программного обеспечения.
Отслеживание и управление изменениями
Прослеживаемость — важнейший аспект разработки требований, гарантирующий, что каждое требование связано с его источником и может быть отслежено на протяжении всего жизненного цикла разработки. Нотация EARS обеспечивает четкую структуру для отслеживания, упрощая управление изменениями и оценку влияния модификаций на другие требования.
Соответствие лучшим практикам
Нотация EARS соответствует лучшим практикам разработки требований. Он поощряет разделение функциональных и нефункциональных требований, способствует использованию ясного языка и подчеркивает важность фиксации предположений предметной области — все это способствует более успешным проектам программного обеспечения.
Что такое ИНКОСЕ?
INCOSE, или Международный совет по системной инженерии, является международной некоммерческой членской организацией, которая предоставляет стандарты и рекомендации, помогающие организациям создавать более совершенные процессы системной инженерии. Стандарт системных требований INCOSE (SRS) содержит набор правил и стандартов, призванных помочь организациям оценивать заявления о требованиях до их реализации. SRS была принята рядом крупных корпораций, а также правительственными учреждениями по всему миру и может использоваться во многих различных отраслях промышленности для различных приложений. Для заинтересованных сторон, таких как разработчики программного обеспечения, бизнес-аналитики, менеджеры проектов, тестировщики, сотрудники ИТ-отдела и другие члены команды, важно хорошо понимать эти требования, прежде чем начинать работу над любым заявлением о системных требованиях или проектом.
В конечном счете, написание хороших требований требует тщательного баланса между подробным и кратким описанием, а также обеспечением того, чтобы требование было проверяемым и выполнимым. INCOSE SRS предлагает принципы и рекомендации, чтобы команды могли писать качественные требования и обеспечивать успех своих проектов. Это поможет избежать дорогостоящих ошибок во время разработки или после развертывания, тем самым помогая организациям создавать более качественные системы за более короткий промежуток времени.
Что такое правила INCOSE?
Заявления о требованиях оцениваются по правилам INCOSE. Эти стандарты помогают организациям оценить выполнимость и качество требований до их реализации. Процесс оценки включает четыре основных критерия:
- Ясность. Письменные требования должны быть ясными, легко читаемыми и понятными. Четко определите информацию, используя утвердительные предложения, которыми должны обмениваться участники. Каждое требование должно описывать четкие критерии успеха. Старайтесь использовать простую лексику и избегайте сокращений. Например, «Пользователь должен иметь возможность просматривать отчет журнала аудита».
- Атомарный. Каждое требование следует рассматривать как отдельный тестовый пример. Не следует использовать такие союзы, как «и», «или» и т. д., поскольку они могут привести к пропуску требований. Это особенно важно, поскольку подобные термины могут привести к тому, что разработчики и тестировщики программного обеспечения упустят из виду требования. Разделение сложных потребностей на более мелкие части до тех пор, пока каждую из них можно будет протестировать отдельно, — один из способов предотвратить это.
- Однозначность. Нечеткие, неполные или противоречивые требования могут привести к ошибкам и переделкам. Чтобы этого не произошло, требования должны быть проверены каждой заинтересованной стороной до их окончательной доработки. Это поможет выявить любые пробелы на раннем этапе, которые затем можно будет устранить.
- Проверяемость. Каждый член команды разработчиков должен иметь доступ к документу, чтобы иметь возможность ссылаться на него так часто, как это необходимо. Поскольку требования должны быть ясными, членам команды не нужна дополнительная информация. Все они должны быть доступны в документе SRS.
- Необходимость. Каждое требование должно документировать что-то, что действительно нужно пользователям, или что-то, что требуется для удовлетворения требований стандарта или интеграции из-за существования внешнего интерфейса. Кроме того, для каждого требования важно иметь авторизованный источник.
- Независимый дизайн. Каждое требование должно определять, что необходимо, а не то, как это будет реализовано. Требования должны определять характеристики системы, которые будут наблюдаться снаружи, а не внутренние детали.
- Выполнимость — каждое требование должно быть технически выполнимо и должно быть реализовано с учетом бюджета, сроков и других ограничений, влияющих на проект. Требования должны отражать фактическое положение дел, включая стоимость, сроки и технологии. Они не должны зависеть от будущих технологических достижений.
- Завершенность. Документ с требованиями должен включать достаточно информации, чтобы ваша команда разработчиков и тестировщики могли завершить работу над продуктом и убедиться, что он соответствует требованиям пользователя без ошибок.
- Правильно – требования, указанные в документах, должны быть очень точными, чтобы избежать путаницы. В них не должно быть никаких лазеек, двусмысленностей, субъективизма, превосходной степени или сравнений. Следовательно, чтобы написать правильные требования, мы должны получить правильную информацию и правильно документировать собранную информацию.
Использование EARS в процессе разработки требований
Чтобы эффективно использовать нотацию EARS в процессе разработки требований, рассмотрите следующие шаги:
- Обучение и ознакомление. Убедитесь, что ваша команда знакома с нотацией EARS. Обеспечьте обучение и ресурсы, которые помогут им понять ключевые элементы и принципы.
- Шаблоны и инструменты. Используйте шаблоны и программные инструменты, поддерживающие нотацию EARS. Эти инструменты могут упростить процесс документирования требований и облегчить сотрудничество между членами команды.
- Рекомендации и стандарты. Установите руководящие принципы и стандарты использования EARS в вашей организации. Определите соглашения об именах, структуру документа и лучшие практики для обеспечения единообразия.
- Сотрудничество. Поощряйте сотрудничество между заинтересованными сторонами, включая конечных пользователей, бизнес-аналитиков и разработчиков. Подход к естественному языку нотации EARS способствует лучшему общению и общему пониманию.
- Обзор и проверка. Внедрите процесс проверки и проверки, чтобы гарантировать, что требования, зафиксированные с помощью EARS, являются полными, последовательными и соответствуют целям проекта.
Заключение
Использование нотации EARS для разработки требований дает многочисленные преимущества, включая повышенную ясность, выражение на естественном языке, гибкость, отслеживаемость и соответствие передовым практикам. Используя EARS, группы разработчиков программного обеспечения могут улучшить процесс документирования требований и повысить вероятность реализации успешных проектов программного обеспечения, отвечающих потребностям и ожиданиям пользователей. Независимо от того, являетесь ли вы опытным инженером по требованиям или новичком в этой области, рассмотрение EARS в качестве варианта нотации — это шаг на пути к более эффективной и результативной разработке требований.
Не забудьте поделиться этим постом!
