Выделение и анализ требований к ПО

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

Формулировка потребностей может быть разбита на следующие этапы:

· Выделить 1,2,3 основные проблемы

· Определить причины возникновения проблем, оценить степень их влияния и выделить наиболее существенные из проблем, влекущих появление остальных.

· Определить ограничения на возможные решения.

Формулировка потребностей не должна накладывать лишних ограничений на возможные решения, удовлетворяющие им. Нужно попытаться сформулировать, что именно является проблемой, а не предлагать сразу возможные решения.

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

Варианты использования ПО

Вариантом использования (use case) называют некоторый сценарий действий системы, который обеспечивает ощутимый и значимый для ее пользователей результат. На практике в виде одного варианта использования оформляется сценарий действий системы, который будет, скорее всего, неоднократно возникать во время ее работы и имеет достаточно четко определенные условия начала выполнения и завершения. Примеры вариантов использования: Покупатель в Интернет-магазине выбирает товар. Для этого он может выбрать категорию товара, фирму-изготовителя или группу таких фирм и отфильтровать оставшиеся товары по цене, габаритам и цвету. Определившись, он выбирает товар, кликая на соответствующем значке мышкой. Оператор системы контроля качества газопровода ищет участки газопровода с повышенным риском возникновения аварии. Для этого он выбирает группу ранее случившихся аварий, фильтруя их по дате, нанесенному ущербу, типу аварии и запускает процедуру анализа характеристик соответствующих участков газопровода на совпадение, по крайней мере, двух характеристик. При таком анализе учитываются изготовитель труб и их партия, история хранения труб на складах, землепроходческая бригада, бригада сварщиков, показатели нескольких последних проведенных инспекций, показатели химической активности грунтов, наличие близлежащих предприятий, влияющих на хим ические и электрические характеристики грунтов. После этого на карте выделяются

участки, характеристики которых также попадают под найденный «шаблон аварии».

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

Не нашли, что искали? Воспользуйтесь поиском: