Прослеживаемость (трассируемость)
Прослеживаемость бывает вертикальной (verticaltraceability) и горизонтальной (horizontaltraceability). Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д.
Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями (requirementsmanagementtool) и/или матрицы прослеживаемости (traceabilitymatrix).
Типичные проблемы с прослеживаемостью:
● Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрёстных ссылок.
● При разработке требований не были использованы инструменты и техники управления требованиями.
● Набор требований неполный, носит обрывочный характер с явными «пробелами».
Модифицируемость
Модифицируемость характеризует простоту внесения изменений в отдельные требования и в набор требований. Можно говорить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а её изменение не приводит к нарушению иных описанных в этом перечне свойств.
Типичные проблемы с модифицируемостью:
● Требования не атомарны и не прослеживаемы, а потому их изменение с высокой вероятностью порождает противоречивость.
● Требования изначально противоречивы. В такой ситуации внесение изменений (не связанных с устранением противоречивости) только усугубляет ситуацию, увеличивая противоречивость и снижая прослеживаемость.
|
|
|
● Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями, и в итоге команде приходится работать с десятками огромных текстовых документов).
Проранжированность
Проранжированность может бытьраспределена по важности, стабильности, срочности. Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования.
Типичные проблемы с проранжированностью состоят в её отсутствии или неверной реализации и приводят к следующим последствиям:
● Проблемы с проранжированностью по важности повышают риск неверного распределения усилий проектной команды, направления усилий на второстепенные задачи и конечного провала проекта из-за неспособности продукта выполнять ключевые задачи с соблюдением ключевых условий.
● Проблемы с проранжированностью по стабильности повышают риск выполнения бессмысленной работы по совершенствованию, реализации и тестированию требований, которые в ближайшее время могут претерпеть кардинальные изменения (вплоть до полной утраты актуальности).
|
|
|
● Проблемы с проранжированностью по срочности повышают риск нарушения желаемой заказчиком последовательности реализации функциональности и ввода этой функциональности в эксплуатацию.
Корректность и проверяемость
Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных). В дополнение можно отметить, что проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию.
К типичным проблемам с корректностью также можно отнести:
● опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну осмысленную аббревиатуру в другую также осмысленную, но не имеющую отношения к некоему контексту; такие опечатки крайне сложно заметить);
● наличие неаргументированных требований к дизайну и архитектуре;
|
|
|
● плохое оформление текста и сопутствующей графической информации, грамматические, пунктуационные и иные ошибки в тексте;
● неверный уровень детализации. Например, слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту;
● требования к пользователю, а не к приложению. Например: “пользователь должен быть в состоянии отправить сообщение” — увы, мы не можем влиять на состояние пользователя.
Тестирование дизайна
Тестирование дизайна ПО может проходить на разных этапах, до реализации, во время, и после реализации основного функционала, например, если решили полностью изменить дизайн.
При тестировании дизайна происходит проверка эргономичности, интуитивной понятности интерфейса.
Типичными проблемами при тестировании дизайна являются:
● “Где я ?” Непонятно где находится пользователь. Порой, из-за очевидности, на различных страницах могут убирать заголовки, названия, поясняющую информацию. Возможно, это и правда очевидно для пользователей знакомых и постоянно пользующихся ПО, но всегда есть новые пользователи.
● “Что делать дальше?” - когда пользователю не очевидно какие действия нужно совершить, чтобы достигнуть цели
|
|
|
● “Лавина” - когда на странице расположено слишком много всего, страница загружена и трудно воспринимается
● “Что я сделал?” - когда ПО не является интерактивным. Пользователь должен получать от ПО ответную реакцию или корректное поведение например:
○ кнопочки визуально нажимаются,
○ при загрузке какого-то контента есть прелоадер или любое отображение, что ПО не зависло, а старательно что-то грузит,
○ при совершении действий по изменению каких-либо данных пользователю должны отображаться уведомления об успешном сохранении, удалении, запрете совершения какого-то действия,
○ при возвращении на предыдущее действие данные выбранные или введённые пользователем остаются на месте.
○ При сохранении, данных пользователя не надо перекидывать куда-то в другое место. Он разве этого хотел? Он же просто нажал кнопку “Сохранить”
○ Элементы интерфейса, выполняющие одинаковую функцию должны выглядеть одинаково. Например, если есть кнопки “Отмена”, “Закрыть”, “Вернуть”, то нужно выбрать одно название и выставить по всему интерфейсу ПО
Дата добавления: 2018-08-06; просмотров: 2140; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!