После того как требования собраны, необходимо сделать несколько вещей сразу:
1. Проверить требования.
2. Проанализировать требования.
3. Расставить приоритеты.
Проверка требований заключается в ответе на следующие вопросы:
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) ли требование? Действительно ли формулировка требования содержит только одно требование? Отсутствуют ли в требованиях такие слова ("и", "или", "но" ), которые могут указывать на наличие нескольких требований в формулировке требования.
Пример: пользователь может авторизоваться и выбрать себе каталог для загрузки фотографий. На самом деле, авторизация не является требованием, это условие для появления возможности выбора каталога для загрузки.
При проверке требований желательно, чтобы проверял не тот человек, создававший исходный список. Дело в том, что длительной работе с требованиями "глаз замыливается" и трудно самостоятельно их оценить. Проверку требований проще поручать старшему аналитику, начальнику отдела аналитики, техническому директору или тестировщику.
1. Проверить требования.
2. Проанализировать требования.
3. Расставить приоритеты.
Проверка требований заключается в ответе на следующие вопросы:
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) ли требование? Действительно ли формулировка требования содержит только одно требование? Отсутствуют ли в требованиях такие слова ("и", "или", "но" ), которые могут указывать на наличие нескольких требований в формулировке требования.
Пример: пользователь может авторизоваться и выбрать себе каталог для загрузки фотографий. На самом деле, авторизация не является требованием, это условие для появления возможности выбора каталога для загрузки.
При проверке требований желательно, чтобы проверял не тот человек, создававший исходный список. Дело в том, что длительной работе с требованиями "глаз замыливается" и трудно самостоятельно их оценить. Проверку требований проще поручать старшему аналитику, начальнику отдела аналитики, техническому директору или тестировщику.
