2015-10-22
406
| Действие исполнителя. | Отклик системы. |
| 1.Покупатель подходи к кассе (с системой POST) и выбранными товарами. | |
| 2. Кассир вводит информацию о каждом товаре. Если выбрано несколько единиц одного и того же товара, кассир может ввести количество единиц. | |
| 3. Определяет цену и добавляет информацию о товаре для выполнения регистрации покупки (транзакции). Выводятся описание товара и его цена. | |
| 4.По завершении ввода информации кассир сообщает системе POST, что информация введена. | 5.Вычисляет и вводит общую стоимость покупки. |
| 6. Кассир сообщает покупателю общую стоимость покупки. | |
| 7. Покупатель дает деньги за покупку, сумма которых, возможно, превышает общую стоимость платежа. | |
| 8. Кассир вводит полученную сумму. | 9. Предоставляет сдачу. |
| 10. Кассир вносит в кассу полученные деньги и извлекает сдачу. | |
| 11. Кассир выдает товарный чек покупателю и сдачу. | |
| 12.Покупатель уходит с покупками. |
Приведем пример диаграммы взаимодействия для варианта использования “Снятые деньги со счета” для банкомата.
1.1. Анализ требований
Общие сведения
В данном разделе использовались материалы из книги Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. – М.: Издательский дом «Вильямс», 2002. 448 с.
Требования задают возможности, которые должна предоставлять система. Соответствие или несоответствие набору требований определяет в наибольшей степени успех или провал проекта.
Управление требованиями представляет собой процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе. Управление требованиями позволяет выявить, организовать и документировать требования к системе. Под управлением требованиями надо понимать набор организационных, стандартизованных, систематических процессов и методов работы с требованиями.
Разработчикам необходимо в рамках отведенного срока и бюджета разработать качественное ПО, удовлетворяющее реальные потребности клиента. В ходе решения этой сложной задачи надо определиться с рядом вопросов типа: является ли это потребностью или требованием, что необходимо иметь, а что желательно, является ли решение постановкой задачи или формулировкой решений, имеем ли дело с целью системы или одним из условий контракта.
Область проблем – это область реальных пользователей и других заинтересованных лиц, чьи технические и экономические познания отличаются от познаний разработчиков и потребности которых нужно удовлетворить, чтобы спроектировать систему. Если представить область проблем в виде пирамиды, то вершиной пирамиды будет потребность заинтересованных лиц.
Функции системы
Первоначально полезно сформулировать:
- объем и состав требований заказчика, предъявляемый разработчикам в проблемной области,
- каким образом (посредство каких решений) разработчики собираются реализовать вышеупомянутые требования.
Это будет небольшой список, называемый функциями создаваемой системы, и определяемый как обслуживание, которое осуществляет система для удовлетворения потребностей заинтересованных лиц. Функции системы занимают следующий уровень пирамиды анализа потребности.
Требования к программному обеспечению
После установления набора функций, согласованного с клиентом, следует шаг для определения более конкретизированных требований, которыми являются требования к программному обеспечению. Требования к программному обеспечению в пирамиде расположатся ниже функций системы.
Таким образом, в основании пирамиды проблемной области лежат программные требования, затем в середине находятся функции системы, а вершиной являются потребности, при чем функции и программные требования уже образуют область решений
