Ответ
Требования к ПО — это формализованные условия, возможности и ограничения, которым должна удовлетворять разрабатываемая система. Они фиксируют что должно быть сделано, но не как это реализовать технически.
Два основных типа требований:
-
Функциональные требования: Описывают поведение системы, её функции.
- Пример: "Система должна позволять пользователю сбрасывать пароль через email"
-
Нефункциональные требования: Описывают свойства системы (качества).
- Производительность: "95% запросов к API должны обрабатываться менее чем за 200 мс."
- Безопасность: "Все пароли должны храниться в хэшированном виде с использованием bcrypt."
- Удобство использования: "Новый пользователь должен выполнить первую задачу менее чем за 3 минуты."
Формат записи (User Story):
Как [роль пользователя],
Я хочу [возможность],
Чтобы [получить пользу/решить задачу].Роль QA: критически анализировать требования на предмет неоднозначности, противоречивости, тестируемости и полноты, участвуя в их уточнении.
Ответ 18+ 🔞
А, ну вот, опять про эти ваши «требования», блядь! Сидишь такой, думаешь — ну щас всё будет просто, как два пальца обоссать. Ан нет, сука, тут целая наука, ёпта! Это ж не просто «сделай мне красиво и чтобы работало» — это, блядь, документ, с которым потом все будут друг другу мозги выносить.
Короче, слушай сюда, что это за зверь такой. Требования к ПО — это, типа, официальная бумажка, где написано, что эта ваша система обязана уметь, а чего ей делать ни в коем случае нельзя. Фишка в том, что там пишут ЧТО надо сделать, но нихуя не пишут КАК это делать. Это уже головная боль программистов, блядь, а не заказчика.
Их, этих требований, всего два главных вида, как яйца у петуха:
-
Функциональные. Это самое простое и понятное. Ну, то есть, что система должна делать. Типа: «Пользователь должен иметь возможность нажать на кнопку «Забыл пароль» и получить письмо на почту, а не в жопу». Всё, понятно. Функция. Делай.
-
Нефункциональные. А вот это, сука, где начинается настоящий пиздец и полёт творческой мысли менеджера! Это не про то, ЧТО делает система, а про то, КАК ОНА ЭТО ДЕЛАЕТ. Качества её, блядь, свойства!
- Производительность: «95% всех запросов должны отрабатывать быстрее, чем я успеваю сказать «ёбушки-воробушки», а именно — за 200 миллисекунд». Не успел? Пизда тебе, а не система.
- Безопасность: «Пароли должны храниться так, чтобы даже если сервер украдут, то вор, открыв базу, подумал бы, что это шифровка от инопланетян, а не пароли. Используй bcrypt, мудак!».
- Удобство: «Любой дебил с двумя руками должен разобраться с интерфейсом за три минуты, иначе мы все тут идём нахуй».
А ещё их любят записывать в хитрожопом формате, который называется User Story (история пользователя, блядь). Выглядит как заклинание:
Как [я, царь и бог, или просто пользователь],
Я хочу [чтобы система мне сосала],
Чтобы [я получил кайф и пошёл дальше пить кофе].И вот тут, внимание, ебаный стоп-кран! Роль QA (то есть нас с тобой, если что) — это не просто сидеть и ждать, когда всё сделают, чтобы начать ломать. Нет! Наша святая обязанность — влезть в этот процесс на самом старте, когда эти требования ещё пахнут свежей макулатурой, и начать их дрочить вопросами.
«А что значит «быстро»?», «А что будет, если пользователь захочет это сделать вот так?», «А этот пункт не противоречит вон тому, который на пятой странице?», «А как мы поймём, что требование выполнено? Есть чёткие критерии, или будем на глазок, как всегда?».
Короче, наша задача — добиться, чтобы требования были недвусмысленными, полными, непротиворечивыми и — о, боже! — ТЕСТИРУЕМЫМИ. Чтобы потом не получилось, как в той истории: «Мы хотели мост через реку, а вы нам нарисовали солнышко и сказали, что оно тёплое». Вот за этим мы и следим, блядь. Чтобы солнышко хотя бы грело, как в ТЗ написано.