Для чего нужна проверка требований. Характеристики хороших требований. На каком этапе осуществляется проверка требований. VERIFICATION

1. Для чего нужна проверка требований
2. Анализ и критерии проверки требований
3. Verification

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

1. Убедиться в их качестве: Проверка требований позволяет убедиться, что требования являются достоверными, четкими, выполнимыми и не противоречивыми.
2. Улучшить коммуникацию: Проверка требований помогает улучшить коммуникацию между участниками проекта, в том числе между заказчиком и исполнителем.
3. Уменьшить риски: Проверка требований позволяет выявить и исправить риски, связанные с проектом, до того, как будут приняты критические решения или затрачены ресурсы.
4. Улучшить качество продукта: Проверка требований позволяет улучшить качество продукта или системы, гарантируя, что они будут соответствовать потребностям заказчика и конечных пользователей.

INVEST

1. Корректно ли требование. Отражает ли требование реальную потребность (need), желание (desire), или обязательство (obligation)? Определена ли основная причина появления требования?
Пример: повышение количества удовлетворенных клиентов это некорректное бизнес-требование. Корректным бизнес-требованием будет уменьшение времени подготовки документа до 1 часа. Такое требование является обязательством и является корневым.

2. Целостно (complete) ли требование?
Требование сформулированно в виде законченного предложения? Требование целиком размещено в одном месте документа, таким образом, что у читателя не возникает необходимости обращаться к дополнительной информации, чтобы понять это требование?

3. Ясно (clear) ли требование?
Требование недвусмысленно и непротиворечиво? Все ли заинтересованные лица согласны со значением требования?
Пример: В любой коробке лежит приз. Требование двусмысленно. Непонятно, в одной только коробке лежит приз или в каждой коробке лежит приз. Правильно требование: в каждой коробке находится приз, выбранный случайным образом из списка призов.

4. Согласованно (consistent) ли требование? Не противоречит ли требование другим требованиям? Соответствуют ли используемые термины терминам других требований и словарю?
Пример: Пользователь имеет возможность самостоятельно настроить «частоты» под свои критерии. Должно быть объяснение "частот", так как их трактовка в случае сайта не совпадает с общепринятой.

5. Проверяемо (verifiable) ли требование? Можем ли мы утверждать, что система соответствует требованию? Возможно ли определить для требования ясные, недвусмысленные тесты (criterion) типа "прошел/не прошел" (pass/fail)? Возможно ли установить, что требование прошло проверку (inspection), анализ (analysis), показ (demonstration) или тест (test)?
Пример: Новые добавленные приложения помещаются в начало списка. Это легко проверяемое требование. В отличие от "система должна предоставлять возможность легкого перехода по виджетам".

6. Трассируемо (traceable) ли требование? Имеет ли требование уникальное обозначение, так, что на него может быть сделана однозначная ссылка?
Трассируемость требований особенно важна, если требований больше 50 и они имеют разный приоритет.

7. Выполнимо (feasible) ли требование? Может ли требование быть реализовано в пределах стоимости (cost) и расписания (schedule)? Реализуемо ли технически требование с точки зрения применяемой (current) технологии? Требование физически достижимо (physically achievable)?
Пример: доступ к системе должен осуществляться в режиме 24/7. Это требование, в целом, выполнимо, но очень дорого. Если его изменить как "система не должна простаивать более 3 часов в месяц", то такое требование становится гораздо более реальным и выполнимым.

8. Отделено ли требование от дизайна (design independent)? Обоснованы ли требования, налагающие ограничения на дизайн? Позволяет ли формулировка требования реализовать его более чем одним способом?
Пример: Вывод призов на странице списком: изображение + текстовое описание. Это уже не требование, это уже решение по дизайну. Более правильным будет следующая формулировка: пользователь должен иметь возможность просмотра изображений и описаний призов.

9. Неделимо (atomic) ли требование? Действительно ли формулировка требования содержит только одно требование? Отсутствуют ли в требованиях такие слова ("и", "или", "но" ), которые могут указывать на наличие нескольких требований в формулировке требования.
Пример: пользователь может авторизоваться и выбрать себе каталог для загрузки фотографий. На самом деле, авторизация не является требованием, это условие для появления возможности выбора каталога для загрузки.

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

Verification

There are many methods for practicing the verification of the software like peer-reviews, walkthroughs, inspections, etc. that can help us in the prevention of potential faults otherwise, it may lead to the failure of the software.

Methods of Verification

Here are some of the common methods that are required for Verification are listed below.

• Peer Reviews
• Walk Through
• Inspections

Verification determines whether the product of some development activity meets its requirements (doing the thing right). Validation assesses whether a product satisfies customer needs (doing the right thing)

Verification: Doing the Thing Right

Verification is about checking if you've built your product according to the specific requirements and design documents you started with. It's like following a recipe to bake a cake and then checking if you added all the ingredients in the right amounts.

Example: Suppose you're creating a website for online grocery shopping. During the verification process, you'll check:

• Did you implement all the features listed in your requirements document, like a shopping cart, a checkout page, and a product search function?
• Does the search function work exactly as specified, filtering products based on categories like fruits, vegetables, or dairy?

Validation: Doing the Right Thing

Validation, on the other hand, ensures that the product you've built actually meets the needs of your customers or users. It's about making sure the cake you baked tastes good to the people who are going to eat it, regardless of what the recipe said.

Example: Continuing with the online grocery website, during the validation process, you might ask:

• Does the website make grocery shopping easier and more convenient for your customers?
• Are customers finding what they need through the search function? Is the checkout process smooth enough that they're happy to complete their purchases?

Simplified

Think of verification as your internal check during the cooking process, making sure you're following the recipe correctly.
Validation is when you serve the dish to your guests, and they confirm it's exactly what they wanted to eat.

So, in the context of developing a product or service:

• Verification is about checking your work against your plans during the development process.
• Validation is about checking the finished product with your customers to ensure it solves their problem or fulfills their need.