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

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

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) касаются выбора возможности разработки внешнего вида и структуры продукта, а так же описывают внешние взаимодействия между системой и внешним миром.

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

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

Источник

Требования к ПО на пальцах

Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.

Если коротко, то основные этапы разработки требований — это:

Если после выполнения просьбы получилось что-то не то — это либо накосячил исполнитель,
либо вы некорректно поставили задачу.

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

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

Так что же такое требования и почему важно уметь их разрабатывать?

Итак, обратимся к истокам:

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

С чего же начать разработку требований? В определении спрятана подсказка: начинать нужно с цели — для чего вообще нам что-то делать.

1. Зачем?

Как бы “ASAP. ” не требовалось что-то сделать — важно найти время и силы выяснить, зачем же это нужно.

Потому что часто, после выяснения цели, меняется или вовсе устраняется задача.

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

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

Можно воспользоваться методом “Пяти почему” или любым другим. Но обычно люди не сопротивляются: если проявить интерес к их работе — разгадка становится доступной.

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

Процесс заказа материалов считается автоматизированным, если >90% компаний-партнеров делают заказы через систему.

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

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

2. Что?

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

Чтобы сократить процесс согласования счетов, мы можем:

А. Перераспределить задачи между согласующими. В результате несколько человек могут быть исключены из процесса. Суммарное время процесса сократится за счет периодов передачи данных/ожидания/коммуникации при передаче.

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

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

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

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

3. Как?

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

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

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

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

4. Когда?

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

Тут есть много инструментов: например, BPMN для описания бизнес-процессов и UML для создания схем взаимодействий сервисов и компонентов.

Если у вас получается объяснять всем, что и как вы хотите сделать с системой, при помощи салфетки и 3х пятен от кофе — значит вы Джон Уик от аналитики и это потрясающе.

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

В схематическом и структурированном виде требования нужно приоритизировать — в зависимости от полезности (это вам скажет заказчик и пользователи) и трудоемкости (это вам скажет команда разработки).

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

Конечно, проблемы будут всегда. Будут переделки, сгоревшие дедлайны и баги. Не всегда будет возможность пройти все этапы и сделать нормальную аналитику, договориться или даже просто поговорить с заказчиком, задокументировать и протрассировать требования. Но в любой ситуации понимание “как должно быть” помогает сделать продукт лучше. Даже если в данный момент вы делаете “как получается” — вы осознаете, что упускаете, и знаете риски. А если вы знаете риски — значит вы можете ими управлять.

Подробнее про требования рекомендую почитать в книге Вигерса и Битти: “Разработка требований к программному обеспечению”. Хоть книга не всегда простая, но очень полезная. Большинство других материалов по теме — пересказ этих истин с той или иной степенью вольности.

Спасибо за внимание и удачного проектирования.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

Бизнес-требования, как правило, фиксируются в концепте (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) касаются выбора возможности разработки внешнего вида и структуры продукта, а так же описывают внешние взаимодействия между системой и внешним миром.

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

Источник

Типы требований к ПО с примерами | часть 2

Jan 1, 2019 · 4 min read

Откуда берутся требования? Какие вообще бывают требования? Об этом — читайте в этой статье.

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

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

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

QA_PRO | Тестирование

Информация по обеспечению качества (QA), контролю качества (QC) и тестированию ПО

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

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

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

Так же существуют более сложные методы, при котором аналитик должен «сам во всем разобраться», и уточнить собранную информацию у заказчиков:

Типы требований

П о чти в каждом проекте существует 3 заинтересованных стороны:

Все они смотрят на «продукт» со своей колокольни, следовательно требования разделяются на соответствующие группы или уровни.

Уровень заказчика (бизнес-требований)

На этом уровне находится только один тип требований – бизнес требования (business requirements).

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

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

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

Основываясь на этих требованиях можно получить общее видение проекта.

Уровень пользователя

Описывают “взгляд” на продукт глазами пользователя.

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

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

Пример оформления этих же требований в виде User Stories

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

Доступ к инструменту предоставляется только сотрудникам поддержки уровня Main support и выше.

Аналитики не должны иметь возможности изменять полученные отчеты.

Не зависимо от количества заказов, максимальное время открытия списка проверок не должно превышать 5 секунд.

Система должна работать с большими объёмами данных (сотни тысяч записей).

Уровень разработки (продуктных требований)

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

Конечным документом, содержащим все требования уровня разработки является Спецификация требований (software requirements specification, SRS). Часто это объемный документ, содержащий сотни страниц.

К уровню разработки относятся следующие типы требований:

Список проверок должен быть отсортирован по конечной дате выполнения (deadline) заказа.

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

Приложение должно поддерживать работу с мобильных устройств (минимальная ширина экрана – 320 px).

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

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

Основными подгруппами являются:

Приложение должно работать в последних версиях браузеров Chrome, Firefox, Safari.

Приложение должно работать на Raspberry PI 3b+.

Весь трафик между браузером и сервером должен быть зашифрован (HTTPS соединение).

Отправка письма с отчетом на почту аналитиков должно выполняться согласно RFC3207 (SMTP over TLS).

Все данные системы должны храниться в БД под управлением СУБД MySQL.

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

Теперь у вас есть понимание того, что:

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

Источник