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