Анализ требований к программному обеспечению на примере
Charles Moore
⚡ Умное резюме
Анализ требований к программному обеспечению разбивает потребности заинтересованных сторон на функциональные и нефункциональные утверждения, ранжирует их на бизнес-уровне, архитектурном уровне и системном уровне, а затем проверяет каждое из них на соответствие качественным характеристикам, чтобы гарантировать возможность тестирования. tracДоступная, приоритетная спецификация.
Требование к программному обеспечению — это функциональная или нефункциональная потребность, которая должна быть реализована в системе. Функциональное требование означает предоставление пользователю конкретной услуги.
Например, в контексте банковского приложения функциональное требование заключается в том, что при выборе пользователем кнопки «Просмотреть баланс» он должен иметь возможность просмотреть свой последний баланс счета.
Требования к программному обеспечению могут быть и нефункциональными, например, требования к производительности. Например, нефункциональное требование может звучать так: каждая страница системы должна загружаться для пользователей в течение 5 секунд.
Итак, в основном требование к программному обеспечению – это
- Функциональный или
- Нефункциональный
это должно быть внедрено в систему. Требования к программному обеспечению обычно выражаются в виде утверждений.
Типы требований
Бизнес требованияЭто основные требования, взятые из обоснования проекта. Например, система мобильного банкинга предоставляет банковские услуги в Юго-Восточной Азии. Для Индии определены следующие требования: сводка по счетам и перевод средств, а для Китая — сводка по счетам и оплата счетов.
| Страна | Компания, предоставляющая банковские функции или услуги |
|---|---|
| Индия | Сводная информация по счету и перевод средств |
| Китай | Сводная информация по счету и Bill Оплата |
ArchiТребования к текстуре и дизайнуЭти требования более детализированы, чем бизнес-требования, и определяют архитектуру решения. Они определяют общий дизайн, необходимый для реализации бизнес-требований. Для образовательной организации типичные сценарии использования архитектуры и дизайна включают вход в систему, подробную информацию о курсе и регистрацию. Требование будет выглядеть следующим образом.
| Вариант использования в банковской сфере | Требование |
|---|---|
| Bill Оплата | Этот вариант использования описывает, как клиент может войти в систему интернет-банкинга и использовать Bill Платежная система. Клиент может просматривать панель управления с неоплаченными счетами от зарегистрированных поставщиков услуг. Клиент может добавлять, изменять и удалять данные поставщика услуг. Клиент может настраивать SMS- и email-уведомления о различных платежных операциях. Клиент может просматривать историю ранее оплаченных счетов. Инициаторами данного сценария использования являются клиенты банка или сотрудники службы поддержки. |
Требования к системе и интеграцииНа самом нижнем уровне находятся системные и интеграционные требования. Они содержат подробное описание каждого требования. Их можно представить в виде пользовательских историй, написанных на повседневном деловом языке. Требования содержат множество деталей, чтобы разработчики могли начать кодирование. Bill В приведенном ниже примере модуля платежей показаны требования к добавлению плательщика.
| Bill Оплата | Требования |
|---|---|
| Добавить BillERS | Название поставщика коммунальных услуг, номер клиента, автоматические платежи – Да/Нет, оплата всей суммы Bill – Да/Нет, Лимит автоматической оплаты – Не платить, если Bill превышает указанную сумму |
Иногда для проекта вы можете не получить никаких требований или документов, с которыми можно работать. Даже в этом случае существуют другие источники информации о требованиях, на которые вы можете полагаться при разработке программного обеспечения или тестового сценария. Другие источники требований, на которые вы можете полагаться, перечислены ниже.
Другие источники требований
- Передача знаний от коллег или сотрудников, уже работающих над этим проектом
- Обсудите проект с бизнес-аналитиком, менеджером по продукту, руководителем проекта и разработчиками.
- Проанализируйте предыдущую версию уже внедренной системы.
- Проанализируйте более старые документы с требованиями проекта.
- RevПросмотрите предыдущие сообщения об ошибках; некоторые сообщения об ошибках преобразуются в запросы на улучшение, которые могут быть реализованы в текущей версии.
- Если имеется инструкция по установке, ознакомьтесь с ней, чтобы узнать, какие работы по установке необходимы.
- Проанализируйте предметную область или отраслевые знания, которые команда пытается внедрить.
Какой бы источник требований вы ни использовали, задокументируйте их в общем формате и дайте их на проверку опытным членам команды.
Как анализировать требования
Рассмотрим пример образовательной программной системы, в которой студент может зарегистрироваться на различные курсы.
Рассмотрим, как анализировать требования. Каждое требование должно соответствовать набору стандартных качественных характеристик, которые включают в себя следующее:
- Atomic
- Уникально идентифицированный
- Завершенный
- Последовательный и однозначный
- TracEable
- Приоритетное
- Проверяемый
В следующей таблице каждый атрибут представлен тремя столбцами:
- В первом столбце указано – «требование к качеству».
- Во втором столбце указано – «плохое требование с некоторой проблемой».
- В третьем столбце показано то же требование, «преобразованное в хорошее требование».
| Требование Качество | Пример плохого требования | Пример хорошего требования |
|---|---|---|
| Atomic | Студенты смогут поступить в бакалавриат и аспирантуру. | Студенты смогут поступить на программы бакалавриата. Студенты смогут поступить на программы магистратуры. |
| Уникально идентифицированный | 1. Студенты смогут поступить на программы бакалавриата. 1. Студенты смогут поступить на программы магистратуры. | Запись на курсы. Студенты смогут записаться на программы бакалавриата. Студенты смогут записаться на программы магистратуры. |
| Завершенный | Пользователь-профессор войдет в систему, указав свое имя пользователя, пароль и другую соответствующую информацию. | Пользователь-профессор войдет в систему, указав свое имя пользователя, пароль и код кафедры. |
| Последовательный и однозначный | Студент будет иметь либо курсы бакалавриата, либо курсы последипломного образования, но не оба одновременно. Некоторые курсы будут открыты как для студентов, так и для аспирантов. | У студента будет либо бакалавриат, либо аспирантура, но не оба сразу. |
| TracEable | Сопоставлять информацию об учащихся с требуемым идентификатором BRD? | Ведение информации об учащихся — соответствует идентификатору требования BRD 4.1. |
| Приоритетное | Зарегистрированный студент — Приоритет 1. Поддержание информации о пользователе — Приоритет 1. Запись на курсы — Приоритет 1. Просмотр табеля успеваемости — Приоритет 1. | Регистрация студента — Приоритет 1. Ведение информации о пользователе — Приоритет 2. Запись на курсы — Приоритет 1. Просмотр табеля успеваемости — Приоритет 3. |
| Проверяемый | Каждая страница системы будет загружаться в приемлемые сроки. | Страницы регистрации студента и записи на курсы системы загрузятся в течение 5 секунд. |
Давайте рассмотрим каждый из этих атрибутов более подробно, начиная с AtomIC.
Atomic
Каждое требование должно быть атомарным, то есть оно должно находиться на самом низком уровне детализации и не может быть разбито на компоненты. В следующих примерах сравниваются атомарные и неатомарные требования.
Продолжая пример с системой в сфере образования: здесь плохое требование звучит так: «Студенты смогут записываться на бакалаврские и магистерские курсы». Это плохое требование, потому что оно не является атомарным — оно смешивает две разные сущности: бакалаврские и магистерские курсы. Соответствующее хорошее требование разделяет его на два. Одно требование касается зачисления на бакалаврские курсы, а другое — зачисления на магистерские курсы.
Уникально идентифицированный
Следующий атрибут качества — уникальная идентификация. В плохом примере два отдельных требования имеют один и тот же идентификатор № 1. Если команда ссылается на требование по его идентификатору, становится непонятно, какое из двух требований имеется в виду. В хорошем примере они объединены в Раздел 1 — Зачисление на курсы, с подтребованиями 1.1 (зачисление на бакалаврские курсы) и 1.2 (зачисление на магистерские курсы).
Завершенный
Каждое требование должно быть полным. Например, здесь плохое требование гласит: «Профессор войдет в систему, указав свое имя пользователя, пароль и другую необходимую информацию». Фраза «другая необходимая информация» расплывчата. Полное требование перечисляет точные поля, такие как код факультета, которые профессор должен предоставить.
Последовательный и однозначный
Все требования должны быть последовательными и недвусмысленными. В неудачном примере одно требование гласит: «Студент будет посещать либо бакалаврские, либо магистерские курсы, но не оба одновременно», а другое — «Некоторые курсы будут доступны как для бакалавров, так и для магистрантов».
Первое требование подразумевает разделение курсов на две взаимоисключающие категории, но второе противоречит этому, открывая некоторые курсы для обеих групп.
Требование о хорошем качестве обучения разрешает конфликт, четко указывая, что каждый курс обозначается либо как курс бакалавриата, либо как курс магистратуры, и студент может записаться только на курсы одной категории.
TracEable
Каждое требование должно быть tracЭто возможно, поскольку требования существуют на нескольких уровнях: бизнес-уровне, архитектурном и проектном, а также системном и интеграционном.
Когда вы преобразуете бизнес-требования в архитектурные и проектные требования, или архитектурные и проектные требования в системные и интеграционные требования, tracНеобходимо обеспечить удобство использования. Каждое бизнес-требование должно соответствовать одному или нескольким архитектурным и проектным требованиям. В неудачном примере «Поддержание информации о студентах – соответствие идентификатору запроса BRD?» отсутствует идентификатор требования.
Правильное требование содержит то же утверждение, но явно соответствует требованию BRD с идентификатором 4.1. Каждое требование должно содержать tracкарта возможностейpingСистемные и интеграционные требования также должны соответствовать коду, который их реализует, и тестовым примерам, которые их проверяют.
TracТаким образом, удобство использования обеспечивается на всех этапах проекта.
Приоритетное
Каждое требование должно быть расставлено по приоритетам, чтобы команда знала, что нужно реализовать в первую очередь, а что может подождать. В плохом примере требованиям «Регистрация студента», «Поддержание информации о пользователе», «Запись на курсы» и «Просмотр табеля успеваемости» присвоен приоритет 1. Не все требования могут иметь приоритет 1, поэтому их необходимо ранжировать реалистично. В хорошем примере требованиям «Регистрация студента» и «Запись на курсы» присвоен наивысший приоритет 1, «Поддержание информации о пользователе» — приоритет 2, а «Просмотр табеля успеваемости» — приоритет 3.
Проверяемый
Каждое требование должно быть проверяемым. Плохой пример: «каждая страница системы должна загружаться в приемлемые сроки», — не поддается тестированию по двум причинам. Во-первых, «каждая страница» может означать десятки страниц, что значительно увеличивает объем работы по тестированию. Во-вторых, «приемлемые сроки» не определены — приемлемые для кого и по какому критерию? Хорошее требование решает обе проблемы, указывая конкретные страницы («страницы регистрации студентов и зачисления на курсы») и устанавливая измеримую целевую задержку в 5 секунд.
