Системный Анализ. Предметная область. Модели на UML. Михаил Кумсков
Чтение книги онлайн.

Читать онлайн книгу Системный Анализ. Предметная область. Модели на UML - Михаил Кумсков страница 7

СКАЧАТЬ этом часть формулировок требований относится к ограничениям на проектирование, реализацию и интерфейсы (значок «+»):

      • Design – ограничения проектирования;

      • Implementation – ограничения на программную реализацию, например, разработка на заданном языке программирования;

      • Interface – ограничения на интерфейсы;

      Основной формой представления функциональных требований к ИС являются «сценарии использования» (Use-сases).7 Модель сценариев использования (Use-case Model) представляет собой набор текстовых описаний для каждого выявленного сценария. Шаги сценария со стороны системы представляют собой функциональные требования к ИС. Сценарий использования (Use-case) – это ключевое понятие RUP, которое является единицей организации работ в проекте (т. е. это единица планирования, проектирования, отладки и тестирования ИС). Модель сценариев использования является основой для эффективного планирования работ и управлению проектом, без его использования эффективность работы в проекте существенно снижается.

      Требования и их документирование

      Основными видами артефактов, содержащих описания требований к системе, согласно IBM RUP являются:

      • запросы заинтересованных лиц (ЗЛ – Stakeholder Requests);

      • глоссарий (Glossary).

      • видение (Vision);

      • модель сценариев использования (Use Case Model, состоит из Use Case Specification);

      • дополнительные спецификации (Supplementary Specification).

      В приложении 1 приведены шаблоны этих документов с кратким пояснением разделов.

      Последовательность обработки требований

      1. Выявить заинтересованных лиц (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. СКАЧАТЬ

<p>7</p>

Известны названия-синонимы: «варианты использования» или «прецеденты».