какие требования бывают и какими свойствами обладают хорошие требования

Качественные требования к ПО | часть 3

Jan 3, 2019 · 3 min read

Как можно определить (и улучшить) качество требований?

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

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

Свойства качественных требований

Качественными можно называть требования, которые соответствует перечисленным ниже свойствам:

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

По началу — б удут ошибки и это нормально. Исправляя их вы будете учиться и каждый раз писать все лучше и лучше 🙂

Такой чек-лист поможет вам:

Это завершающая статья о требованиях, самая короткая, но как по мне — самая важная! Надеюсь после прочтения у всех появилось базовое понимание что такое требования, зачем они нужны и как и ними можно работать 🙂

Но не забывайте — это ведь только начало!

В интернете есть множество интересных статей, книг, приложений для работы с требованиями — не бойтесь изучать это тему 🙂 Она очень интересная!

🔥 Интересуешься тестированием и хочешь получать актуальную информацию?

👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!

Источник

Какими характеристиками должны обладать хорошие требования?

Характеристики качества превосходных требований:

— Полнота Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

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

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

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

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

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

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

Источник

SkillsCup.com

Сайт переехал сюда: SkillsCup.com

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

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

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

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

Пример плохого требования: REQ1 Система не должна принимать пароль длиннее 15 символов.

Данное требование не проясняет что же должна делать система:

Пример хорошего требования: REQ1 Система не должна принимать пароль длиннее 15 символов. Если пользователь введет больше 15 символов, система должна отобрать сообщение об ошибке с просьбой исправить пароль.

2. Проверяемое – тестировщики должны иметь возможность проверить правильно ли требование реализовано в системе. Для этого требование должно быть четким, точным, недвусмысленным.

Пример плохого требования: REQ1 Поиск в системе должен осуществляться по имени, фамилии пользователя и т.д.

В данном примере критерии поиска должны быть раскрыты полностью. Иначе нельзя проверить выполняется ли требование в системе.

3. Четкое (краткое) – требование не должно содержать лишней информации. Оно должно быть изложено четко и просто.

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

Это требование может быть изменено следующим образом: REQ1 Система должна определять аэропорт как по коду аэропорта так и по названию города.

4. Точное – требование должно содержать в себе истинные факты.

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

6. Осуществимое – требование должно быть выполнимо в рамках существующих ограничений (время, деньги, существующие ресурсы)

7. Независимое – для понимания требование не нужно знать других требований.

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

8. Атомарное – требование должно содержать одну связанную сущность. Пример плохого требования: REQ1 В системе должна быть предусмотрена возможность забронировать полет, купить билет, зарезервировать номер в отеле, арендовать машину.

9. Необходимое – заинтересованные лица должны нуждаться в данном требовании.

10. Абстрактное – в требовании не должно содержаться информации о том как оно будет реализовано.

Также существуют определенные характеристики, которыми должен обладать набор требований:

а. Постоянное – не должно быть конфликтов между требованиями.

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

c. Полное – требование должно быть определено для всех возможных ситуаций.

Существуют дополнительные критерии, но они содержат в себе описанные выше, например:

Модифицируемость – если требование атомарно и полное, оно модифицируемо.

Трассировка (прослеживаемость) – если требование атомарно и имеет уникальный идентификатор, оно прослеживаемо.

Источник

Требования, какие и зачем

Mar 14, 2019 · 4 min read

AnalystBlog

Блог серийного аналитика. Если для вас «анализ» не пустой звук, вы хотите научиться выявлять и формулировать…

Какие бывают требования?

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

По ходу статьи я буду давать свои комментарии под такими сносками.

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

Функциональные требования в свою очередь подразделяются на:

Нефункциональные требования подразделяются на:

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

Остановимся на каждом типе требований подробнее.

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

Как понятно из названия это требования непосредственно к функциональности системы (сервиса, приложения), которую от нее ожидают.

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

Бизнес-требования, как правило, фиксируются в концепте ( concept) или уставе проекта ( project charter), иногда еще в так называемом в документе рыночных требований ( market requirements document). В общем, в любом верхнеуровневом документе, который описывает образ и границы системы.

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

Требования пользователей ( user requirements) описывают цели и задачи, которые пользователям позволит решить система. Простым языком я бы называл это “хотелки” пользователей. В отдельный документ такие требования конечно не выносятся, а просто фиксируются в виде “Пользовательских Историй” ( User Story) в тасктрекерах.

В мире гибких методологий (Agile, Scrum) беклог вашего проекта как раз наполняется подобными User Stories, при этом я всегда рекомендую аналитика подниматься от этих требований вверх, чтобы точно понимать какую цель преследует та или иная хотелка.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, что-бы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда их именуют “требованиями поведения” (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

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

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

Системные требования — это требования которые предъявляют вашей системе системы с которыми запланирована интеграция.

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

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

Фух, разобрались с функциональными, перейдем к НФТ.

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

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

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес правила обычно фиксируются в SRS, в разделе ограничений.

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

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

Иногда атрибуты качества называют “критерии успеха” — имея ввиду что по этим критериям пользователи будут оценивать будут оценивать качество вашей системы. Желательно выявить их на этапе сбора требований, и зафиксировать в user story и SRS. Т.о. вы не забудете предусмотреть реализацию мониторинга за этими показателями.

Ограничения ( constraints) касаются выбора возможности разработки внешнего вида и структуры продукта, а так же описывают внешние взаимодействия между системой и внешним миром.

Спасибо что дочитали до конца, надеюсь, статья оказалась для вас полезной!

Все самое свежее в моем телеграм-канале, присоединяйтесь:

Источник

WEBURSITET.RU

Онлайн-курсы профессиональной разработки ПО

Критерии качества требований

Текстовая расшифровка двенадцатого урока курса Введение в профессию аналитика.

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

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

Этот список я взял из статьи бывшего директора по маркетингу IBM (ссылка на статью здесь приведена).

Что такое хорошее требование? В данном случае речь идёт об отдельном требовании, можно сказать, атомарном.

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

Если говорить об SRS. Вот этот стандарт, о котором я говорил: IEEE 830. В нём тоже есть критерии качества, но это критерии для оценки не отдельного требования, а их совокупности, всей спецификации в целом. Они перечислены прямо в этом стандарте, а здесь переведены на русский язык.

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

Это критерии качества целой совокупности требований.

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

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

Давайте сначала посмотрим, какие критерии качества применяются к User Story, которая, собственно, является основным методом представления требований в Agile подходах, в Agile практиках. Они здесь перечислены.

Отдельная User Story, как атомарное требование, должна быть независимой. Этот принцип описан в книгах. Мы будем разбирать этот принцип более детально, что означает каждое из этих слов. Я пока очень коротко опишу.

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

Полезная. Это вообще очень важный принцип Agile: любая доработка должна принести пользу пользователю. И, соответственно, пользовательская история должна давать пользу для развития продукта.

Компактная. То есть небольшая. Не буду здесь вдаваться в подробности.

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

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

А теперь давайте мы их сравним. Я вынес в левую часть свойства хороших требований по тому списку IBM, из которого торчат уши водопадного процесса. А справа описал критерии хорошей пользовательской истории. Посмотрел, какие из них соответствуют друг другу, и нашёл, на самом деле, только два. Тестируемая пользовательская история — это то же самое, что проверяемое требование. А независимая пользовательская история — это то же самое, что модульное требование (я говорил, что здесь тоже должно быть слово «независимое»). А все остальные критерии в друг друга заменяют, но не полностью, а в даже противоречат.

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

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

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

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

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

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

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

Источник