Требования к программному обеспечению являются описанием функций и функциональных возможностей целевой системы. Требования передают ожидания пользователей от программного продукта. Требования могут быть очевидными или скрытыми, известными или неизвестными, ожидаемыми или неожиданными с точки зрения клиента.
Требование техники
Процесс сбора требований к программному обеспечению у клиента, их анализа и документирования известен как разработка требований.
Целью проектирования требований является разработка и сопровождение сложного и описательного документа «Спецификация системных требований».
Требование инженерного процесса
Это четырехэтапный процесс, который включает в себя:
- Технико-экономическое обоснование
- Сбор требований
- Спецификация требований к программному обеспечению
- Проверка требований к программному обеспечению
Давайте посмотрим на процесс вкратце —
Технико-экономическое обоснование
Когда клиент обращается к организации за разработкой нужного продукта, он приходит к четкому представлению о том, какие функции должен выполнять программное обеспечение и какие функции ожидаются от программного обеспечения.
Ссылаясь на эту информацию, аналитики подробно изучают, возможна ли разработка желаемой системы и ее функциональных возможностей.
Это технико-экономическое обоснование ориентировано на цели организации. В этом исследовании анализируется, может ли программный продукт быть практически материализован с точки зрения реализации, вклада проекта в организацию, ограничений затрат и в соответствии с ценностями и целями организации. В нем рассматриваются технические аспекты проекта и продукта, такие как удобство использования, ремонтопригодность, производительность и возможность интеграции.
Результатом этого этапа должен стать отчет о технико-экономическом обосновании, который должен содержать адекватные комментарии и рекомендации для руководства относительно того, следует ли осуществлять проект.
Сбор требований
Если технико-экономическое обоснование положительно относится к выполнению проекта, следующий этап начинается с сбора требований от пользователя. Аналитики и инженеры общаются с клиентом и конечными пользователями, чтобы узнать их идеи о том, что программное обеспечение должно предоставлять и какие функции они хотят включить в программное обеспечение.
Спецификация требований к программному обеспечению
SRS — это документ, созданный системным аналитиком после сбора требований от различных заинтересованных сторон.
SRS определяет, как предполагаемое программное обеспечение будет взаимодействовать с аппаратным обеспечением, внешними интерфейсами, скоростью работы, временем отклика системы, переносимость программного обеспечения на различные платформы, ремонтопригодность, скорость восстановления после сбоя, безопасность, качество, ограничения и т. Д.
Требования, полученные от клиента, написаны на естественном языке. Системный аналитик обязан документировать требования на техническом языке, чтобы они могли быть поняты и полезны для команды разработчиков программного обеспечения.
SRS должен придумать следующие функции:
- Требования пользователя выражены на естественном языке.
- Технические требования выражены на структурированном языке, который используется внутри организации.
- Описание дизайна должно быть написано в псевдокоде.
- Формат форм и печать графического интерфейса.
- Условные и математические обозначения для DFD и т. Д.
Проверка требований к программному обеспечению
После того, как спецификации требований разработаны, требования, упомянутые в этом документе, подтверждаются. Пользователь может попросить о незаконном, непрактичном решении, или эксперты могут неправильно интерпретировать требования. Это приводит к огромному увеличению стоимости, если не пресечено в зародыше. Требования могут быть проверены на соответствие следующим условиям —
- Если они могут быть практически реализованы
- Если они действительны и согласно функциональности и области программного обеспечения
- Если есть какие-то неясности
- Если они завершены
- Если они могут быть продемонстрированы
Процесс выявления требований
Процесс выявления требований можно изобразить с помощью следующей диаграммы:
- Сбор требований — разработчики обсуждают с клиентом и конечными пользователями и знают их ожидания от программного обеспечения.
- Организация требований — Разработчики расставляют приоритеты и распределяют требования в порядке важности, срочности и удобства.
-
Переговоры и обсуждение — если требования неоднозначны или если есть какие-то противоречия в требованиях различных заинтересованных сторон, если они есть, то это обсуждается и обсуждается с заинтересованными сторонами. Требования могут быть затем расставлены по приоритетам и разумно скомпрометированы.
Требования исходят от различных заинтересованных сторон. Чтобы устранить двусмысленность и конфликты, они обсуждаются для ясности и правильности. Нереальные требования разумно скомпрометированы.
- Документация. Все формальные и неформальные, функциональные и нефункциональные требования документируются и предоставляются для последующей обработки.
Переговоры и обсуждение — если требования неоднозначны или если есть какие-то противоречия в требованиях различных заинтересованных сторон, если они есть, то это обсуждается и обсуждается с заинтересованными сторонами. Требования могут быть затем расставлены по приоритетам и разумно скомпрометированы.
Требования исходят от различных заинтересованных сторон. Чтобы устранить двусмысленность и конфликты, они обсуждаются для ясности и правильности. Нереальные требования разумно скомпрометированы.
Методы выявления требований
Выявление требований — это процесс выяснения требований для предполагаемой системы программного обеспечения путем общения с клиентом, конечными пользователями, пользователями системы и другими лицами, которые заинтересованы в разработке системы программного обеспечения.
Существуют различные способы определения требований
Интервью
Интервью являются сильной средой для сбора требований. Организация может проводить несколько типов интервью, таких как:
- Структурированные (закрытые) собеседования, в которых каждая информация, подлежащая сбору, определяется заранее, они твердо следуют шаблону и предмету обсуждения.
- Неструктурированные (открытые) интервью, где информация для сбора не определена заранее, более гибкая и менее предвзятая.
- Устные интервью
- Письменные интервью
- Индивидуальные интервью, которые проводятся между двумя людьми за столом.
- Групповые интервью, которые проводятся между группами участников. Они помогают выявить любые недостающие требования, так как вовлечены многочисленные люди.
Обзоры
Организация может проводить опросы среди различных заинтересованных сторон, запрашивая их ожидания и требования от будущей системы.
Анкетирование
Документ с предварительно определенным набором объективных вопросов и соответствующими вариантами передается всем заинтересованным сторонам для ответа, которые собираются и компилируются.
Недостатком этого метода является то, что, если в вопроснике не указан какой-либо вопрос, проблема может быть оставлена без внимания.
Анализ задач
Команда инженеров и разработчиков может проанализировать работу, для которой требуется новая система. Если у клиента уже есть какое-то программное обеспечение для выполнения определенной операции, оно изучается и требования предлагаемой системы собираются.
Анализ предметной области
Каждое программное обеспечение попадает в какую-то доменную категорию. Опытные люди в этой области могут оказать большую помощь в анализе общих и конкретных требований.
мозговая атака
Неформальные дебаты проводятся между различными заинтересованными сторонами, и все их вклады записываются для дальнейшего анализа требований.
макетирования
Прототипирование — это создание пользовательского интерфейса без добавления подробных функций, позволяющих пользователю интерпретировать функции предполагаемого программного продукта. Это помогает лучше понять требования. Если на стороне клиента не установлено программное обеспечение для справки разработчика, и клиент не знает о своих собственных требованиях, разработчик создает прототип на основе первоначально упомянутых требований. Прототип показан клиенту, и обратная связь отмечена. Отзывы клиентов служат входом для сбора требований.
наблюдение
Команда экспертов посещает организацию или рабочее место клиента. Они наблюдают за фактической работой существующих установленных систем. Они наблюдают за рабочим процессом на стороне клиента и за тем, как решаются проблемы с выполнением. Сама команда делает некоторые выводы, которые помогают сформировать требования, ожидаемые от программного обеспечения.
Требования к программному обеспечению Характеристики
Сбор требований к программному обеспечению является основой всего проекта разработки программного обеспечения. Следовательно, они должны быть четкими, правильными и четко определенными.
Полные спецификации требований к программному обеспечению должны быть:
- Очистить
- Правильный
- последовательный
- Последовательный
- понятный
- модифицируемый
- проверяемый
- Приоритетное
- недвусмысленный
- прослеживаемый
- Достоверный источник
Требования к программному обеспечению
Мы должны попытаться понять, какие требования могут возникнуть на этапе выявления требований и какие требования ожидаются от программной системы.
В целом требования к программному обеспечению следует разделить на две категории:
Функциональные требования
Требования, относящиеся к функциональному аспекту программного обеспечения, попадают в эту категорию.
Они определяют функции и функциональные возможности внутри и из системы программного обеспечения.
Примеры —
- Опция поиска предоставляется пользователю для поиска из различных счетов.
- Пользователь должен иметь возможность отправить любой отчет руководству.
- Пользователи могут быть разделены на группы, и группам могут быть предоставлены отдельные права.
- Должен соответствовать бизнес-правилам и административным функциям.
- Программное обеспечение разработано с сохранением нисходящей совместимости
Нефункциональные требования
Требования, которые не относятся к функциональному аспекту программного обеспечения, попадают в эту категорию. Они являются неявными или ожидаемыми характеристиками программного обеспечения, которые пользователи предполагают.
Нефункциональные требования включают в себя —
- Безопасность
- логирование
- Место хранения
- конфигурация
- Спектакль
- Стоимость
- Interoperability
- гибкость
- Аварийное восстановление
- доступность
Требования классифицированы логически как
- Должно быть : программное обеспечение не может работать без них.
- Должно иметь : Расширение функциональности программного обеспечения.
- Может иметь : Программное обеспечение все еще может нормально функционировать с этими требованиями.
- Список пожеланий : эти требования не соответствуют каким-либо целям программного обеспечения.
При разработке программного обеспечения необходимо реализовать «Должен иметь», «Должен иметь» — предмет споров с заинтересованными сторонами и отрицания, тогда как «может иметь» и «список пожеланий» можно сохранить для обновлений программного обеспечения.
Требования к пользовательскому интерфейсу
Пользовательский интерфейс является важной частью любого программного или аппаратного обеспечения или гибридной системы. Программное обеспечение широко распространено, если оно —
- прост в эксплуатации
- быстрый ответ
- эффективно обрабатывать ошибки в работе
- обеспечение простого, но последовательного пользовательского интерфейса
Принятие пользователем в основном зависит от того, как пользователь может использовать программное обеспечение. Пользовательский интерфейс является единственным способом восприятия системы пользователями. Хорошо работающая система программного обеспечения также должна быть оснащена привлекательным, понятным, последовательным и отзывчивым пользовательским интерфейсом. В противном случае функциональные возможности программного комплекса не могут быть использованы удобным способом. Говорят, что система хороша, если она предоставляет средства для ее эффективного использования. Требования к пользовательскому интерфейсу кратко упомянуты ниже —
- Содержание презентации
- Простая навигация
- Простой интерфейс
- отзывчивый
- Согласованные элементы интерфейса
- Механизм обратной связи
- Настройки по умолчанию
- Целенаправленный макет
- Стратегическое использование цвета и текстуры.
- Предоставить справочную информацию
- Ориентированный на пользователя подход
- Групповые настройки просмотра.
Программный системный аналитик
Системный аналитик в ИТ-организации — это человек, который анализирует требования к предлагаемой системе и обеспечивает правильное и правильное оформление и документирование требований. Роль аналитика начинается на этапе анализа программного обеспечения SDLC. Аналитик обязан убедиться, что разработанное программное обеспечение соответствует требованиям клиента.
Системные аналитики имеют следующие обязанности:
- Анализ и понимание требований предполагаемого программного обеспечения
- Понимание того, как проект будет способствовать достижению целей организации
- Определить источники требований
- Проверка требований
- Разработать и внедрить план управления требованиями
- Документация по бизнес, техническим, технологическим и технологическим требованиям
- Координация с клиентами для определения приоритетности требований и устранения и неоднозначности
- Завершение критериев приемки с клиентом и другими заинтересованными сторонами
Метрики и показатели программного обеспечения
Меры программного обеспечения можно понимать как процесс количественной оценки и символизации различных атрибутов и аспектов программного обеспечения.
Метрики программного обеспечения обеспечивают измерения для различных аспектов программного процесса и программного продукта.
Программные меры являются фундаментальным требованием разработки программного обеспечения. Они не только помогают контролировать процесс разработки программного обеспечения, но и помогают поддерживать превосходное качество конечного продукта.
По словам Тома ДеМарко (a) (Software Engineer): «Вы не можете контролировать то, что не можете измерить». По его словам, очень ясно, насколько важны меры программного обеспечения.
Давайте посмотрим некоторые метрики программного обеспечения:
Размер метрики — LOC (Lines of Code), в основном рассчитывается в тысячах доставленных строк исходного кода и обозначается как KLOC.
Функция Point Count — это мера функциональности, предоставляемой программным обеспечением. Функция Point count определяет размер функционального аспекта программного обеспечения.
Метрики качества — Дефекты, их типы и причины, последствия, интенсивность и их значение определяют качество продукта.
Количество дефектов, обнаруженных в процессе разработки, и количество дефектов, сообщенных клиентом после установки или доставки продукта на стороне клиента, определяют качество продукта.