kazminaviktoriya1
В профиль
Выход
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Моделирование требований
В этом уроке вы узнаете, что такое моделирование требований к ПО и какие задачи можно решить с помощью моделей.
Анализ требований к ПО и их моделирование
Требования могут приходить из разных источников (в зависимости от классов пользователей, бизнес-правил и прочего) и в разной форме — в виде электронного письма, наброска на бумаге и даже личного сообщения в мессенджере. Чтобы упорядочить разрозненные требования, нужно их проанализировать.
В процессе анализа системный аналитик приводит требования к такому виду, чтобы:
- Их можно было реализовать, то есть создать и протестировать ПО.
- Они были читаемы и понятны всем членам команды (включая заказчика и разработчиков).
- В них можно было ориентироваться и поддерживать их актуальность.
- Их можно было согласовать с заказчиком.
В процессе анализа требований участвует не только системный аналитик. К приоритизации, кроме менеджера проекта, подключается заказчик. В распределении требований по компонентам также участвует тимлид (от англ. teamlead — руководитель) разработки. Для того чтобы все участники процесса однозначно поняли требования и дали необходимую обратную связь, существуют модели требований к ПО, а моделированием требований занимается как раз системный аналитик.
Что такое моделирование требований к ПО
Моделирование входит в процесс анализа и помогает проверить, насколько качественно разработаны требования.
Модель — это упрощённое (схематичное) представление реальности, сохраняющее ключевые свойства первоначального объекта и передающее информацию для дальнейшего анализа, общения и понимания. С помощью модели можно проверить поведение любой сущности, не создавая эту сущность целиком.
Модели требований — это упрощённые (схематичные) представления разных аспектов требований. Что подразумевается под аспектами? Например, взаимодействие системы и пользователя, организация связей между сущностями и прочее. Модели позволяют рассмотреть требование с разных сторон. Это помогает составить более полное представление о том, что нужно реализовать.
Модели требований можно представить в любом виде (рисунок на салфетке тоже вариант), но чаще всего их составляют в виде схем и диаграмм. Некоторые модели требований представляют в виде таблиц.
Моделирование необходимо не для всех требований, но очень полезно для описания вариантов использования (Use Case) системы пользователем, для описания связей между сущностями системы, при описании протекающих в системе процессов, для описания взаимодействия разных частей системы друг с другом. А, например, такое требование, как «поменять цвет кнопки», можно не моделировать.
Задачи моделирования требований
С помощью моделирования требований системный аналитик:
- Проясняет внешнее поведение программы независимо от её технической реализации.
- Однозначно описывает требования (то есть так, чтобы у формулировок не было второго значения).
- Сокращает число пропусков и несоответствий в требованиях.
- Упрощает процесс внесения изменений в требования.
Прояснение внешнего поведения программы
Внешнее поведение системы — то, как систему видит обычный пользователь. Он не знает, как она работает с технической точки зрения, и задумываться об этом ему необязательно. Например, для того, чтобы пользоваться смартфоном, не нужно знать принципы работы микросхем.
Модели требований позволяют создать требования такого качества, что становится возможным оценить внешнее поведение системы в различных ситуациях, не тратя время на разработку ПО.
Таким образом, на уровне модели требований можно будет продумать все варианты использования системы и предугадать возможные проблемы.
Однозначное описание (читабельность) требований
Поскольку модели требований чаще представлены в виде схем, благодаря наглядности их проще понять, чем текстовое описание.
Например, вам приходит письмо от заказчика с требованием: «Для того чтобы помочь пользователю с решением, надо ли брать на прогулку зонтик, система должна знать прогноз погоды на день. В зависимости от прогноза (ожидается ли дождь) она выдаст соответствующий ответ».
Если мы смоделируем это требование, то есть преобразуем его текстовое описание в схему, получится так:
Это достаточно простой пример. Бывает так, что вам нужно учесть множество развилок. Представьте, что будет, если сформулировать в виде текста блок-схему, которая описывает логику определения стоимости места в салоне самолёта?
Сокращение числа пропусков и несоответствий в требованиях
Когда требования становятся более читабельными и наглядными, системный аналитик часто замечает в них недочёты, например недостаток информации.
Выявить лакуны (пробелы) в требованиях и восстановить недостающее звено — ещё одна задача моделирования. Таким образом, модели помогают уменьшить количество пропусков и несоответствий в требованиях.
Как именно собрать недостающую информацию с заинтересованных лиц, каждая команда разработки решает самостоятельно. Некоторые команды могут использовать для этого общий чат, другие — регулярные созвоны или встречи.
Упрощение процесса внесения изменений в требования
При наличии наглядной модели требований намного проще внести в неё изменения и затем скорректировать сами требования так, чтобы они были точнее и полнее.
Чем моделирование требований к ПО отличается от проектирования ПО
Для составления моделей достаточно использовать элементы диаграмм (стрелки, квадратики и другие обозначения). Элементы диаграмм задаёт нотация. О том, что это такое и какие бывают нотации, вы узнаете в следующем уроке.
При моделировании требований системному аналитику не нужно знать технические стороны реализации ПО: какие типы данных будут применяться, какую базу данных выберет архитектор ПО, какая архитектура будет заложена (микросервисная или монолит). Моделирование требований не затрагивает конкретную технологию.
Модель можно реализовать на любом языке программирования, в разных типах приложений (веб-приложение, мобильное или десктоп), с любой базой данных и при любой архитектуре.
Как только аналитик использует в описании требования конкретные технические детали реализации, он переходит к задаче проектирования ПО. Проектирование ПО производится на выбранных технологиях, с учётом возможностей этих технологий и с помощью технических специалистов — разработчиков и дизайнеров.
Определите, какие утверждения относятся к моделированию требований, какие — к проектированию ПО.
Описать модель процесса проверки домашнего задания в приложении Chatty.
Моделирование требований
Речь идёт о моделировании требований, так как необходимо описать процесс, без уточнения технической реализации.
С помощью диаграммы описать связь между преподавателем и его учениками.
Моделирование требований
Важно показать, каким образом на понятийном уровне будут связаны ученик и преподаватель.
Описать взаимодействие микросервисов системы приложения Chatty.
Проектирование ПО
Микросервисная архитектура — это уже способ реализации предложенной модели.
Данные о преподавателе хранятся в БД в поле с типом char и содержат не более 60 символов.
Проектирование ПО
В данном утверждении описано техническое требование к реализации.
Сопоставить количество возможных действий в системе для ролей «студент» и «абитуриент».
Моделирование требований
С помощью моделей можно выявить количество возможных действий в системе и сравнить их.
Определить оптимальное расположение полей на форме создания заявки.
Проектирование ПО
Имеется в виду один из вариантов изображения, чтобы реализовать конкретную модель.
Подведём итоги
В этом уроке вы узнали, для чего нужны модели требований и какие задачи они решают.
- Моделированием требований к ПО занимается именно системный аналитик. Это часть процесса анализа.
- Модель требований сохраняет ключевые характеристики ПО и позволяет оценить внешнее поведение системы в различных ситуациях, не тратя время на разработку ПО.
- Моделирование — способ сделать требования наглядными и читабельными.
- В моделях требований проще, чем в тексте, выявить пропуски и несоответствия, что упрощает внесение правок в требования.
- В результате анализа получаются требования, с которыми могут работать все участники проекта.