Используется объектно-ориентированный подход, существенно отличающийся от известного моделирования «сущность — связь», или ER-моделирования. Модель имеет визуальный характер и изображается в нотации Unified Modeling Language (UML), которая широко известна среди аналитиков, архитекторов, разработчиков и программистов. Описаны паттерны, применяемые для преобразования диаграмм классов на UML, и приведены примеры их практического использования. Изложение ведется согласно методологии IBM RUP
Модель предметной области служит разным целям:
1) помогает определить логическую структуру БД информационной системы;
2) является основой для составления «расширенного» словаря проекта;
3) помогает найти все сценарии (при выявлении функциональных требований в специальной форме — в виде сценариев использования (Use Cases));
4) позволяет не пропустить «вспомогательные» сценарии, которые могут быть не упомянуты в постановке задачи, полученной от заказчика ИС.
Важной особенностью модели предметной области является ее независимость от используемых ИС и баз данных
Для проведения визуального моделирования будем использовать специальные программные инструменты, называемые CASE-средствами (Computer Assist Software Engineering)[1]. Тогда будет возможно проведение «генерации кода» по модели («прямое проектирование», или forward engineeging) и обратное проектирование (reverse engineering) — восстановление модели по программному коду или по существующей БД
Модель — это «упрощение реальности» в интересах заинтересованных лиц. Такое определение относится и к нашему моделированию. Здесь главным заинтересованным лицом является инвестор или топ-менеджер организации. Есть и другие заинтересованные лица — аналитики, архитекторы, разработчики информационной системы (ИС), и поэтому одной модели, как правило, недостаточно. Нужны разные «упрощения» для разных читателей модели[1].
Первым шагом процесса моделирования является определение целей моделирования
Свойства продукта (Features)
Перечислите и кратко опишите возможности продукта. Возможности — высокоуровневые способности системы, необходимые для удовлетворения потребностей пользователей. Каждая возможность — это внешне заданный сервис, который требует серию вводов для достижения желаемого результата. Например, возможностью следящей системы может быть способность выдавать отчеты по времени. Поскольку модель сценария использования использует возможности, обновляйте определения, ссылающиеся на сценарий использования.
Шаблоны документов, содержащих требования к системе
Запрос заинтересованного лица
Страничка Кумскова М. И. на сайте УЦ Люксофт. URL: https://www.luxoft-training.ru/about/experts/kumskov.html
[2] Учебный центр «Люксофт». URL: https://www.luxoft-training.ru/
[3] Визуальное моделирование с применением UML. URL: https://www.luxoft-training.ru/kurs/vizualnoe_modelirovanie_s_primeneniem_uml.html
[4] Мастерская по применению UML для работы с требованиями. URL: https://www.luxoft-training.ru/kurs/masterskaya_po_primeneniyu_uml_dlya_raboty_s_trebovaniyami.html
[5] Объектно-ориентированный анализ и проектирование на UML. URL:https://www.luxoft-training.ru/kurs/obektno-orientirovannyy_analiz_i_proektirovanie_na_uml.html
[6] Механико-математический факультет МГУ им. М. В. Ломоносова. Курсы повышения квалификации. URL: http://do.math.msu.ru/
[7] Системный анализ. Информационные системы. Программа повышения квалификации. URL: http://do.math.msu.ru/information-systems-analysis
[8] Системный анализ. Бизнес-системы. Программа повышения квалификации. URL: http://do.math.msu.ru/business-systems-analysis
[9] Введение в анализ данных. Программа повышения квалификации. URL: http://do.math.msu.ru/data-analysis-for-managers
Определение границ системы — задаем вопросы:
• Какие внешние интерфейсы должны быть реализованы в разрабатываемой системе?
• Каким образом сценарии использования могут помощью понять границы проекта?
• Что должно входить в систему?
• Что не должно входить в систему?
Выявление экторов — задаем вопросы:
• Кто использует систему?
• Кто получает информацию от системы?
• Кто вносит информацию в систему?
• В какой части организации система будет использоваться?
• Кто поддерживает работоспособность системы?
• Какие другие системы используют эту систему?
Выявление сценариев использования — задаем вопросы:
• Какова цель каждого эктора при взаимодействии с системой?
• Для чего эктор будет использовать систему?
• Будет ли эктор создавать, хранить, изменять, удалять или читать данные из системы?
• Будет ли эктор информировать систему о внешних событиях или изменениях?
• Необходимо ли эктора информировать о каких-либо изменениях в системе?
Определяем «границы системы». Все то, что будет внутри системы, пока не рассматриваем, а все то, что будет вне системы, выявляем на втором шаге. Фактически здесь мы устанавливаем «систему координат» для всех последующих рассмотрений — систему как «черный ящик».
Выявить заинтересованных лиц (stakeholders, список ведется в Vision).
2. Собрать их пожелания (набор документов — Stakeholder Requests).
3. Выделить (путем символьной разметки) в пожеланиях ключевые потребности (needs) и классифицировать их:
• симптомы бизнес-проблем («issues»);
• действующие лица (пользователи, «needs-actors»);
• варианты использования («need-use cases»);
• бизнес-правила и бизнес-процессы («needs-business rules», «needs-business processes»);
• ограничения (needs-constraints).
4. Основные термины проекта описать в Глоссарии (Glossary), используя модель предметной области.
5. Проанализировать симптомы и сформулировать основную бизнес-проблему, на решение которой будет направлена разрабатываемая ИС (секция Problem Statement формулируется в Vision).
6. Отобрать потребности (Needs), соответствующие предложенному направлению решению проблемы (Problem Statement используется как фильтр).
7. Для отобранных потребностей (на основе Глоссария) сформировать перечень бизнес-требований к разрабатываемой системе (Features формулируется в Vision). Построить матрицу трассировки Needs и Features.
8. На основе модели предметной области выявить сценарии использования. Построить UseCases диаграмму на UML.
9. Описать эскизы (Outline) сценариев использования (UseCases), трудоемкость которых можно оценить по объему альтернативных потоков.
10. Провести трассировку UseCases и Features для оценки трудоемкости бизнес-требований к ИС.
11. Описать другие требования к системе (FURPS+), собрав их в Спецификации требований (Requirement Specifications).
12. Выполнить первоначальную оценку сложности реализации бизнес-требований (efforts).
13. Разработать план реализации сценариев использования по итерациям.
14. На каждой итерации эскизы сценариев вариантов использования дополнить до полной спецификации сценария использования.
15. На протяжении всего процесса документирования требований пополнять Глоссарий по мере необходимости.