Анализ требований

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

• Прецеденты, которые описывают, как люди взаимодействуют с системой.

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

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

• Диаграмма состояний, которая может оказаться полезной, если концепция имеет своеобразный жизненный цикл с различными со­стояниями и событиями, которые изменяют эти состояния.

Анализируя состояния, помните, что самое важное - это взаимодейст­вие с вашими пользователями и клиентами. Обычно это непрограмми­сты, и они не знакомы с UML и другими подобными технологиями. Несмотря на это я успешно применял перечисленные приемы при об­щении с людьми, не имеющими инженерной подготовки. Чтобы до­биться этого, надо свести количество нотаций к минимуму. Не следует вводить элементы, специфичные для программной реализации.

Будьте готовы в любой момент отойти от правил UML, если это помо­жет улучшить взаимопонимание. Наибольший риск в случае примене­ния UML для анализа состоит в том, что вы строите диаграммы, не со­всем понятные специалистам в конкретной предметной области. Та­кая диаграмма хуже, чем бесполезная; она лишь способна вселить в разработчиков ложное чувство уверенности.