Functionality — функциональность;
• Usability — удобство использования;
• Reliability — надежность;
• Performance — производительность;
• Supportability — удобство сопровождения.
При этом часть формулировок требований относится к ограничениям на проектирование, реализацию и интерфейсы (значок «+»):
• Design — ограничения проектирования;
• Implementation — ограничения на программную реализацию, например, разработка на заданном языке программирования;
• Interface — ограничения на интерфейсы;
одинаковый набор полей карточки (или атрибутов) и одинаковый набор связей с карточками других картотек.
• Класс — это описание набора «одинаковых» объектов, т. е. объектов, имеющих одинаковый набор атрибутов, одинаковый набор операций и одинаковый набор указателей на другие объекты. Картотеки представимы классами.
• Объект — это экземпляр класса, т. е. запись, или «карточка», в соответствующей картотеке.
• Атрибут — поименованное свойство объекта.
• Операция — сервис, который может быть запрошен у объекта. Метод или функция, инкапсулированная в объект.
• Модель — это «упрощение реальности» в интересах заинтересованных лиц.
• База данных — набор картотек, взаимосвязанных друг с другом и ведущихся на компьютере.
• Сервер — процесс, предоставляющий целостный доступ к общему ресурсу.
• Сервер БД, или СУБД (система управления БД), предоставляет целостный доступ к базе данных как общему ресурсу.
• Картотека — набор карточек с «одинаковой структурой», представляется в модели классом.
• Карточка — запись в картотеке, представляется в модели объектом. Все карточки одной и той же картотеки имеют одинаковую структуру:
основные процессы создания ИС:
1. Моделирование бизнес процессов.
2. Управление требованиями.
3. Анализ и проектирование.
4. Реализация.
5. Тестирование.
6. Развертывание.
7. Управление изменениями и конфигурациями.
8. Управление проектом.
9. Управление средой разработки.
Используется объектно-ориентированный подход, существенно отличающийся от известного моделирования «сущность — связь», или 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)
Перечислите и кратко опишите возможности продукта. Возможности — высокоуровневые способности системы, необходимые для удовлетворения потребностей пользователей. Каждая возможность — это внешне заданный сервис, который требует серию вводов для достижения желаемого результата. Например, возможностью следящей системы может быть способность выдавать отчеты по времени. Поскольку модель сценария использования использует возможности, обновляйте определения, ссылающиеся на сценарий использования.
Шаблоны документов, содержащих требования к системе
Запрос заинтересованного лица