Привет Друзья! В данной статье, Мы рассмотрим самый главный документ в сфере IT - это конечно же Требования!
Любой проект, который планируется реализовать, начинается с требований, это самый главный документ который используется в процессе разработки программного продукта. Это тот документ на который все опирается и с которым будет позже сравниваться наш продукт. От того на сколько четко и грамотно они будут сформулированы во многом зависит успех нашего продукта
Требования — это документ, описание того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Выделяют 3 уровня требований:
Уровень бизнес требований – цель, ради которой создается продукт (для чего? какая польза? как получим прибыль?)
Уровень пользовательских требований - задачи, которые пользователь может выполнять с помощью продукта (регистрироваться? общаться, искать информацию о продукте)
Уровень продуктовых требований - представление, как будет реализовано в нашем продукте с точки зрения разработки, учитывая контекст бизнес требований и пользовательских требований
Так же выделяют функциональные и не функциональные требования:
1)Функциональные требования – отвечают на вопрос "что система должна делать?"
2)Нефункциональные требования – отвечают на вопрос "как система должна это делать?"
Теперь давайте рассмотрим как же нам получить информацию, для составления требований, основные пути:
1)интервью с заказчиком или пользователем;
2)наблюдение за продуктами Заказчика или конкурента;
3)Самостоятельное описание.
Рассмотрим примеры
Интервью с заказчиком или пользователем
Наш Руководитель проекта и бизнес-аналитик встречаются с заказчиком и обсуждают с ним требования, к продукту. Обсуждают для чего продукт создан, какой он будет нести функционал, как заказчик планирует получать прибыль, какие задачи сможет решать пользователь с помощью этого продукта, на каких платформах и системах будет запускаться наш продукт.
На примере социальной сети:
1)основная цель разработки данного продукта – это создание платформы для общения, с возможностью обмена медиа файлами, созданием групп для общения и обмена данными
2)прибыль заказчик может получать на основе платной регистрации, если такая имеется, встроенной рекламы, продажи подписок на музыку или отключение рекламы и т.д.
3)возможность запуска нашего приложения на ПК, на мобильных устройствах, в разных браузерах.
Все эти пункты и не только описываются в требованиях.
Наблюдение за продуктами Заказчика или конкурента
Мы так же можем обратить внимание на уже созданные продукты нашего заказчика, если таковы имеются и подчеркнуть из них информацию, например оформление. Так же рассмотреть основных конкурентов, которые уже реализовали подобный продукт. Например мессенджер WhatsApp, мы видим что кнопка ответа на звонок зеленая, а сброса красная, большинству пользователю уже интуитивно знакома такая особенность, поэтому нам выгоднее использовать ее в своем продукте, так как пользователь уже привык к этому.
Самостоятельное описание
Это составление на основе опыта команды, которая уже создавала подобные продукты.
Теперь давайте рассмотрим атрибуты требований:
1. Корректность — точное описание разрабатываемого функционала;
2. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам;
3. Недвусмысленность — требование должно содержать однозначные формулировки;
4. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация;
5. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться;
6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте;
7. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет;
8. Атомарность — требование нельзя разбить на отдельные части без потери деталей;
9. Модифицируемость — в каждое требование можно внести изменение.
Способы представления наших требований:
-Use case diagram – схема, где изображены возможности каждого из ролей в системе: админа, пользователя и т.д которые описывают варианты взаимодействия между пользовательским и программным обеспечением;
-User story – пользовательское-ориентированное описание целей, которые люди смогут достичь, используя наш продукт, написанный повседневным языком.
На пример: а) как пользователь я хочу регистрироваться онлайн, для того чтоб регистрироваться быстро и снизить бумажную работу; б) Как пользователь я хочу получить такую функциональность которая позволяла бы мне сделать следующее.
Должны быть критерии приемки – что должно быть сделано, чтоб критерии были реализованы.
Тестировщик должен придумать тест-кейсы чтоб проверить данные требования)
-UI mocup -шаблоны нашего UI
-Спецификация – в текстовой форме, структурированный набор требований к программному обеспечению и его внешним интерфейсам. Предназначен для того, чтобы установить базу для соглашения между заказчиком и командой разработки о том, как должен функционировать программный продукт.
Друзья, вот мы и рассмотрели такую важную тему: «что такое требования и как с ними работать?», обязательно выучите ее, ведь это основы разработки программного продукта . Пришло время прощаться, подписывайтесь на канал, ставьте лайк и до новых встреч!