The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Инженерия требований - одна из самых важных дисциплин в разработке программного обеспечения. Возможно, даже более важная, чем архитектура, дизайн или само кодирование. Джой Биатти и Карл Вигерс в книге Software Requirements утверждают, что стоимость ошибок, допущенных в спецификации требований, значительно выше, чем ошибка в исходном коде. Я полностью согласен.
В проектах XDSD мы специфицируем требования с использованием Requs, контролируемого естественного языка, который звучит как английский, одновременно может быть разобран компьютером. Простой документ с требованиями на Requs может выглядеть примерно так:
Этот документ “Требования к программному обеспечению” (SRS) определяет два типа (Отдел и Сотрудник) и один метод UC (или “сценарий использования”).
Синтаксис Requs объясняется здесь.
Главная и единственная цель инженерии требований в любом проекте XDSD - создать полный и неоднозначный документ SRS. Человек, выполняющий эту задачу, называется “системным аналитиком”. В этой статье объясняются его основные задачи и обсуждаются возможные проблемы.
Мы вносим изменения в SRS постепенно, и наши приращения очень небольшие. Допустим, у нас есть примерный документ, о котором я упоминал выше, и я являюсь системным аналитиком по этому проекту. Все мои задачи будут связаны с “есть ошибка в SRS, давайте исправим ее”.
Даже если это предложение, оно все равно начнется с жалобы на неполноценность SRS. Например:
Имеется ли ограничение на зарплату сотрудника? Может ли она быть отрицательной?
Сколько сотрудников может быть в отделе? Может ли их количество быть равным нулю?
Может ли сотрудник получить снижение зарплаты?
Все эти ошибки адресованы мне. Мне нужно исправить их, улучшив SRS. Мой рабочий процесс одинаков для каждой задачи:
Change the SRS
Close the task
Давайте попробуем это шаг за шагом.
Как системный аналитик, моя работа состоит в понимании того, что хотят владельцы продукта (также известные как “поставщики требований”) и документировании их пожеланий. В большинстве случаев их желания очень смутны и хаотичны. Моя задача - сделать их полными и однозначными. Поэтому первым шагом является понимание, что требуется.
Прежде всего, я должен определить, кто является владельцем продукта, прежде чем начать. Владелец продукта подписывает SRS, поэтому я должен полностью прислушаться к его мнению. Однако моя задача не только слушать, но и предлагать. Хороший системный аналитик может провоцировать творческое мышление у владельца продукта, задавая правильные вопросы.
Хорошо, теперь, когда я знаю, кто является владельцем продукта, мне нужно поговорить с ним. В XDSD мы не проводим никаких встреч, телефонных звонков или любой другой формы неформального общения. Поэтому мой единственный механизм получения необходимой информации - это его тикеты.
Я буду создавать новые тикеты, адресованные владельцу продукта. Поскольку в проекте может быть много владельцев продукта, я должен создавать тикеты, которые четко указывают в первом предложении, что тикет относится к вопросам для определенных владельцев. Человек, получающий тикет, затем определит лучшего ответственного за него.
Таким образом, работая над одной задачей, я буду создавать много вопросов и получать много интересных ответов. Я буду делать все это, чтобы улучшить свое понимание разрабатываемого владельцами продукта.
Когда я понимаю, как SRS должен быть исправлен, пришло время вносить изменения в файлы Requs.
Документ SRS генерируется автоматически на каждом цикле непрерывной интеграции. Он составлен из частей, называемых файлами .req, которые обычно находятся в каталоге src/main/requs в хранилище проекта.
Моя работа как системного аналитика заключается в внесении изменений в некоторые из этих файлов и отправке запроса на слияние для рассмотрения.
Руководство GitHub объясняет, как работать с GitHub. Однако, в кратце, мне нужно:
Проверьте его копию на мой компьютер;
Make changes;
Сохраните мои изменения.
“Отправьте их на мой удаленный форк;”
Отправьте запрос на слияние (pull request).
Не имеет особого значения, какие файлы я редактирую, потому что Requs автоматически объединяет все файлы с расширением req. Я даже могу добавлять новые файлы в директорию - они будут обрабатываться. Также я могу добавлять поддиректории с файлами.
Перед отправкой запроса на слияние, я попытаюсь проверить, что мои изменения являются синтаксически и грамматически правильными. Я буду компилировать файлы Requs в документ SRS с использованием того же метода, который использует наш сервер непрерывной интеграции для их компиляции.
Однако, перед компиляцией, мне необходимо установить JDK7 и Maven.
После этого, я выполняю следующую команду в командной строке в директории проекта:
После ввода команд я ожидаю увидеть сообщение BUILD SUCCESS. Если этого не происходит, значит возникли ошибки и их нужно исправить. Мой запрос на слияние не будет принят, и я не смогу закрыть задачу, если Requs не сможет скомпилировать файлы.
После компиляции я могу открыть SRS в Firefox. Он находится в target/requs/index.xml. Несмотря на то, что это XML-файл, Firefox может открыть его как веб-страницу. Другие браузеры не будут работать. Хорошо, Google Chrome будет работать, но только с помощью этого небольшого трюка.
Как только все изменения будут завершены, я отправлю запрос на слияние (pull request). Затем менеджер проекта назначит кого-то для рассмотрения моего запроса на слияние, и я получу обратную связь.
В большинстве случаев, рецензент будет просить внести несколько исправлений. Обычно мои запросы рассматривают другие системные аналитики. Поэтому мне необходимо рассмотреть все комментарии и убедиться, что мои изменения удовлетворяют рецензента.
Я внесу дополнительные изменения в ту же ветку локально и отправлю их на GitHub. Запрос на слияние будет обновлен автоматически, поэтому мне не нужно создавать новый запрос.
Как только запрос на слияние будет достаточно чистым для рецензента, он сольет его в основную ветку (master).
Наконец-то, мой запрос на включение изменений был объединен, и я обращаюсь к владельцу задачи. Я сообщаю ему, что техническое задание было исправлено и прошу его просмотреть его. Его первоначальная проблема должна быть уже решена - техническое задание должно содержать необходимую информацию.
Он закрывает задачу, и менеджер проекта выплачивает мне оплату в течение нескольких часов.
P.S. Также, посмотрите эту статью о специальном лексере для Jekyll, который я создал, чтобы выделить синтаксис Requs в этой статье блога.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 16:38
