Целью определения функциональности является получение от владельца подробного описания результата работы над проектом. Ниже представлены цели проведения этапа определения функциональности.
- Определить, каким образом существует и функционирует программное решение, чтобы разработчик с наименьшими аналитическими затратами мог создать это решение без запроса дополнительных сведений от владельца.
- Согласовать с владельцем результат работы над проектом: представление программного решения, способ его функционирования после сдачи проекта, дату окончания работ.
- Повторно вывести оценку объема работы и сроков его выполнения.
- Получить согласие владельца с представлением программного решения, его функциональными возможностями и датой окончания работ.
Как говорилось выше, способ существования программного решения и его функции составляют функциональное требование к программному решению. Фразу «способ существования и функционирования решения» можно интерпретировать очень вольно, поэтому следует сузить область функциональности в контексте программного решения. Задайте владельцу следующие вопросы и получите ответы, уточняющие функциональные требования, предъявляемые к программному решению для интернета.
Формирование спецификаций требований. Обучение проектированию ПО. Часть 7 Тренинг 1
- Где будет расположено программное решение в процессе функционирования? Решение можно разместить на сайте владельца либо на сайте сторонней организации. Платформу (операционная система, веб-сервер или другой продукт, предназначенный для оптимизации работы) можно выбрать заранее и оговорить для совместного использования с разрабатываемым решением. Если владелец не знает ответа на данный вопрос, тогда специалист предоставляет свои рекомендации.
- Каких клиентов будет обслуживать программное решение? Интернет-решения не всегда поддерживают клиент браузера. Иногда требуются другие способы поддержки программных решений, расположенных в различных местах интернета, с данными, которые нужно обрабатывать перед предоставлением конечному пользователю. Специалист определяет всех потребителей данных и функциональных возможностей.
- Что требуется для работы программного решения? Интернет-решения могут обслуживать и другие серверы, расположенные в интернете. В решении можно предусмотреть получение данных из другой системы перед обработкой информации. Специалист определяет всех поставщиков данных и функциональных возможностей.
- Кто взаимодействует с системой? Выявляются конечные пользователи, действия, которые они выполняют в программном решении, и их требования к решению. Каковы роли, существующие в технологическом процессе, и какова ответственность, связанная с этими ролями?
- Какие сущности реального мира представляются в программном решении? Выявляется и документируется объектная модель программного решения. Необходимо определить и смоделировать объекты в системе и их атрибуты, абстрагируясь от технических ограничений системы. Определяются объекты, описывающие действия, выполняемые программным решением.
- Что именно выполняет программное решение? В конечном счете программа производит над данными определенные действия перед доставкой клиенту. Для определяемых объектов моделируются и документируются соответствующие взаимодействия и описываются выполняемые действия.
При определении способа существования и функционирования решения большая часть информации зависит от мнения владельца. Часто владелец сам не знает точно, что именно он хочет видеть в результате проекта. На этапе сбора требований владелец должен сделать заключение о результатах. Определив суть программного решения, владелец выявляет промежуточные результаты и необходимые ресурсы.
2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)
При определении программного решения его нужно задокументировать с указанием того, что владелец ожидает от конечного результата проекта. Этот документ называется функциональной спецификацией. После создания функциональной спецификации оценка повторно проверяется и при необходимости пересматривается.
План проекта с основными этапами и датами является частью функциональной спецификации. Владелец должен ознакомиться с функциональной спецификацией и оценкой. Работу не следует начинать, пока он письменно виде не подтвердит функциональность, описанную в спецификации. В таблице 6.2 приведены промежуточные результаты, необходимые для выполнения этапа определения функциональности.
Функциональная спецификация
Функциональная спецификация описывает ожидаемый результат работы над проектом с точки зрения владельца. Она является подготовительным этапом перед составлением технического проекта и обеспечивает понимание владельцем конечного результата. В этом документе указываются действия, выполняемые программным решением. Видимые промежуточные результаты нужно подробно описать, чтобы разработчик создавал программное решение без дополнительных вопросов к владельцу. Функциональная спецификация создается с технически абстрагированной точки зрения и не содержит технических инструкций по созданию решения.
| 1 | Функциональная спецификация | Бизнес-аналитик. |
| 2 | Квалифицированная оценка функциональных требований | Разработчики. |
| 3 | Квалифицированный план проекта для функциональных требований | Менеджер проекта. |
| 4 | Согласие владельца с определенными функциональными требованиями, даты окончания работ в плане | Менеджер проекта. |
Функциональная спецификация занимает объем не более 30 страниц и состоит из следующих элементов.
- Определение каждого функционального требования; это нужно, чтобы специалисты по разработке и контролю качества могли определенным образом называть компоненты спецификации в технической спецификации и сценариях тестирования.
- Рисунки или диаграммы каждого окна, связанного с результатом проекта или представляемого конечному пользователю.
- Запись контроля за изменениями.
- Содержание.
- Титульная страница с именем владельца и названием проекта.
- Нижний колонтитул с именем компании разработки, сведениями о конфиденциальности информации и датой печати документа.
- Идентификация проекта запоминающимся именем.
Хорошим методом уникальной идентификации каждого элемента в функциональной спецификации является нумерация фрагментов текста, описывающих работу того или иного компонента. Данный метод целесообразен для описания субординации функциональных спецификаций. На рисунке 6.4 приведен пример фрагмента текста в документе, в котором используется иерархическая нумерация для определения функциональных спецификаций.
Рекомендуемый объем функциональной спецификации не должен превышать 30 страниц, так как он должен оперативно просматриваться членами команды разработки перед планированием и началом непосредственной работы над программным решением. Не создавайте спецификацию произвольного размера. Если функциональные требования занимают более 30 страниц, не урезайте их, а вместо этого создайте еще одну функциональную спецификацию для определения всех функциональных требований.
Рис. 6.4. Уникально определенные с помощью иерархической нумерации функциональные требования
При наличии нескольких небольших функциональных спецификаций вместо одной в проекте появляется большее число итераций. Функциональная спецификация может рассматриваться как область итераций. Функциональная спецификация определяет мельчайшие части проекта, с которыми нужно ознакомить владельца.
Разработка всегда осуществляется согласно функциональным требованиям. Итерации уменьшают цикл разработки и снижают вероятность получения некорректного результата. Чем больше в проекте итераций, тем больше промежуточных результатов, с которыми нужно ознакомить владельца.
Ему будет намного спокойнее наблюдать за успешным выполнением промежуточных этапов проекта, чем находиться в томительном ожидании конечного результата. Выполнение проекта с итерациями будет «занимать» голову владельца позитивными событиями, связанными с проектом. Если владелец не может видеть или понять промежуточные результаты, или если между ними проходит длинный промежуток времени, то он начинает отрицательно судить о ходе выполнения проекта.
Заключение о конфиденциальности имеет юридическую силу, если документ предоставляется другой организации, не имеющей права на его просмотр. При составлении с компанией контракта на разработку ПО владелец обычно подписывает договор о неразглашении, который запрещает предоставление полученных материалов другим организациям. Если документ имеет статус конфиденциального, то получатели несут правовую ответственность при нелегальном прочтении документа. Владелец должен соблюдать большую осторожность при распространении документа, а получатель документа должен понимать требования конфиденциальности перед прочтением документа.
Область контроля за изменениями на лицевой странице документа определяет дату, номер версии, обзор изменений, внесенных в документ, с указанием авторов изменений. На рисунке 6.5 показан пример титульной страницы функциональной спецификации.
Примечание. Документ Word, использованный в качестве демонстрационной функциональной спецификации, доступен с исходным кодом на веб-сайте автора книги.
увеличить изображение
Рис. 6.5. Титульная страница демонстрационной функциональной спецификации
Разработка шаблона функциональной спецификации или ее общей структуры является хорошо зарекомендовавшим себя конструктивным подходом, который позволяет всем пользователям документа отыскивать определенную информацию по аналогии с другими спецификациями, изученными ранее. Недостатком такого подхода является то, что однажды допущенная ошибка может повторяться снова и снова.
Чтобы привести в равновесие конструктивность и предоставление документации, отвечающей требованиям организации, сконцентрируйтесь на сути проекта. При необходимости отклонитесь от шаблона, принятого по умолчанию, чтобы поточнее описать работу программного решения.
Если функциональная спецификация изменяется в каждом проекте, то следует изменить шаблон документа. Ниже приведены основные положения, которыми следует руководствоваться при составлении функциональной спецификации.
Источник: intuit.ru
Разница между Требованиями и Спецификацией в разработке программного обеспечения
Основное различие между Требованиями и Спецификацией в разработке программного обеспечения заключается в том, что Требования — это потребности заказчика, которые должны учитываться в разрабатываемом программном обеспечении, тогда как Спецификация является техническим документом с проанализированными требованиями. Спецификация описывает функции и поведение программного обеспечения.
Разработка программного обеспечения (Software Engineering) — это дисциплина по методической разработке программного обеспечения. Требования являются основой программного обеспечения. Сбор и анализ требований является основным этапом разработки программного обеспечения . Спецификация требований программного обеспечения ( Software Requirements Specification , SRS) — это документ, который содержит проанализированные требования и фазы разработки, такие как проектирование, внедрение, использование SRS.
Содержание
- Обзор и основные отличия
- Что такое Требования в разработке программного обеспечения
- Что такое Спецификация в разработке программного обеспечения
- Сходство между Требованиями и Спецификацией в разработке программного обеспечения
- В чем разница между Требованиями и Спецификацией в разработке программного обеспечения
- Заключение
Что такое Требования в разработке программного обеспечения?
Весь проект зависит от требований. Первым шагом к разработке программного обеспечения является подготовка технико-экономического обоснования. Основное внимание уделяется техническим аспектам продукта. Следующим процессом является сбор требований.
Это возможно благодаря общению с клиентами, конечными пользователями и пользователями системы, которые будут использовать продукт в итоге. Интервью, опросы и вопросники являются основными методами сбора требований. П осле сбора требований производится окончательный анализ.
Функциональные и нефункциональные требования являются двумя типами этих требований. Требования, которые определяют функциональный аспект программного обеспечения, является функциональными требованиями. Следовательно, они определяют функцию системы или подсистемы.
Например, система управления библиотекой должна иметь возможность добавления, редактирования, удаления и поиска информации о книге. Также, она должна иметь возможность редактирования и удаления информации читателя книги. Кроме того, она должна уметь рассчитывать штраф за поздний возврат. Это пример некоторых функциональных требований системы на примере библиотеки.
Нефункциональные требования определяют ожидаемые характеристики программного обеспечения. Безопасность, ремонтопригодность, удобство использования, надежность и доступность являются примерами нефункциональных требований.
Другой тип требований — это бизнес-требования. Они определяют бизнес-цели, видение и задачи.
Что такое Спецификация в разработке программного обеспечения?
Прежде всего, клиенты и конечные пользователи описывают свои требования на естественном языке. Документирование этих требований происходит после анализа. Этот документ называется Спецификацией требований к программному обеспечению ( Software Requirements Specification , SRS). Затем системные аналитики переводят их на технический язык для команды разработчиков программного обеспечения.
Эта спецификация работает как соглашение между заказчиком и командой разработчиков о том, что должен делать программный продукт. Правильная спецификация помогает предотвратить сбои программного обеспечения. Это также помогает команде разработчиков получить четкое представление о продукте, который они должны разработать.
Сходства между Требованиями и Спецификацией в разработке программного обеспечения?
- Спецификация — это документ с проанализированными требованиями.
В чем разница между Требованиями и Спецификацией в разработке программного обеспечения?
| Требования против Спецификации в разработке программного обеспечения | |
| Требования представляют собой описания услуг, которые должна предоставлять программная система, и ограничения, при которых она должна работать | Спецификация — это технический документ, который описывает функции и поведение программного приложения |
| Использование | |
| Требования помогают описать, что должно делать программное обеспечение | Спецификация помогает получить четкое представление о продукте для его разработки и минимизировать сбои программного обеспечения |
Заключение — Требования против Спецификации в разработке программного обеспечения
Разница между Требованием и Спецификацией в в разработке программного обеспечения (Software Engineering) заключается в том, что Требования — это потребности заказчика, которые должны быть решены программным обеспечением, тогда как Спецификация — это технический документ с проанализированными требованиями.
Источник: raznisa.ru
Требования и спецификации в разработке программ
В ключевое отличие между требованиями и спецификациями в программной инженерии заключается в том, что требование — это потребность заинтересованной стороны, которой должно удовлетворять программное обеспечение, тогда как спецификация — это технический документ с проанализированными требованиями. Спецификация описывает особенности и поведение программного обеспечения.
Программная инженерия — это дисциплина методической разработки программного обеспечения. Требования — основа программного обеспечения. Сбор и анализ требований — это важный этап разработки программного обеспечения. SRS — это документ, содержащий проанализированные требования. На этапах разработки, таких как проектирование и внедрение, используется SRS.
1. Обзор и основные отличия
2. Что такое требования в программной инженерии
3. Что такое спецификация в программной инженерии
4. Связь между требованиями и спецификациями в программной инженерии
5. Параллельное сравнение — требования и спецификации в разработке программного обеспечения в табличной форме
6. Резюме
Что такое требования в программной инженерии?
Весь проект зависит от требований. Первый шаг к разработке программного обеспечения — это технико-экономическое обоснование. Он фокусируется на технических аспектах продукта. Следующий процесс — сбор требований. Это возможно путем общения с клиентами, конечными пользователями и пользователями системы, которые будут использовать продукт в конце.
Интервью, опросы и анкеты — основные методы сбора требований. Наконец, анализ происходит после сбора требований.
Функциональные и нефункциональные требования — это два типа этого требования. Требование, определяющее функциональный аспект программного обеспечения, является функциональным требованием. Следовательно, он определяет функцию системы или подсистемы. Кроме того, система управления библиотекой должна добавлять, редактировать, удалять и искать сведения о книгах.
Он также должен добавлять, редактировать и удалять данные участника. Более того, он должен рассчитать штраф за просрочку возврата. Это несколько функциональных требований к этой системе. Нефункциональное требование определяет ожидаемые характеристики программного обеспечения.
Безопасность, ремонтопригодность, удобство использования, надежность и доступность — вот некоторые примеры нефункциональных требований. Другой тип — бизнес-требования. Они определяют бизнес-цели, видение и цели.
Что такое спецификация в программной инженерии?
Прежде всего, клиенты и конечные пользователи описывают свои требования на естественном языке. Документирование этих требований происходит после анализа. Этот документ называется Спецификацией требований к программному обеспечению (SRS). Затем системные аналитики переводят их на технический язык для команды разработчиков программного обеспечения.
Эта спецификация работает как соглашение между заказчиком и командой разработчиков о том, что должен делать программный продукт. Правильная спецификация помогает предотвратить программные сбои. Это также помогает команде разработчиков получить четкое представление о продукте, который они должны разработать.
Какая связь между требованиями и спецификацией в программной инженерии?
- Спецификация — это документ с проанализированными требованиями.
В чем разница между требованиями и спецификациями в разработке программного обеспечения?
Требования и спецификации в программной инженерии
Резюме — Требования и спецификации в программной инженерии
Разница между требованием и спецификацией в программной инженерии состоит в том, что требование — это потребность заинтересованной стороны, которая должна быть решена с помощью программного обеспечения, тогда как спецификация — это технический документ с проанализированными требованиями.
Источник: ru.strephonsays.com