Требования к программному обеспечению

Требования к программному обеспечению представляют собой описание функций и возможностей целевой системы. Требования передают ожидания пользователей от программного продукта. Требования могут быть очевидными или скрытыми, известными или неизвестными, ожидаемыми или неожиданными с точки зрения клиента.

Разработка требований

Процесс сбора требований к программному обеспечению от клиента, их анализа и документирования известен как разработка требований.

Целью проектирования требований является разработка и поддержка сложного и описательного документа «Спецификация требований к системе».

Процесс разработки требований

Это четырехэтапный процесс, который включает:

Технико-экономическое обоснование
Сбор требований
Спецификация требований к программному обеспечению
Проверка требований к программному обеспечению

Давайте кратко рассмотрим процесс -

Технико-экономическое обоснование

Когда клиент обращается к организации с просьбой разработать желаемый продукт, он приходит с приблизительным представлением о том, какие все функции должно выполнять программное обеспечение и какие все функции ожидаются от программного обеспечения.

Ссылаясь на эту информацию, аналитики подробно изучают возможность разработки желаемой системы и ее функциональных возможностей.

Это технико-экономическое обоснование направлено на достижение цели организации. Это исследование анализирует, может ли программный продукт быть практически материализован с точки зрения реализации, вклада проекта в организацию, ограничений по стоимости и в соответствии с ценностями и целями организации. Он исследует технические аспекты проекта и продукта, такие как удобство использования, ремонтопригодность, производительность и возможность интеграции.

Результатом этого этапа должен быть отчет о технико-экономическом обосновании, который должен содержать адекватные комментарии и рекомендации для руководства о том, следует ли осуществлять проект.

Сбор требований

Если технико-экономическое обоснование положительно в отношении реализации проекта, следующий этап начинается со сбора требований от пользователя. Аналитики и инженеры общаются с клиентом и конечными пользователями, чтобы узнать их идеи о том, что программное обеспечение должно предоставлять и какие функции они хотят, чтобы программное обеспечение включало.

Спецификация требований к программному обеспечению

SRS - это документ, созданный системным аналитиком после сбора требований от различных заинтересованных сторон.

SRS определяет, как предполагаемое программное обеспечение будет взаимодействовать с оборудованием, внешними интерфейсами, скоростью работы, временем отклика системы, переносимостью программного обеспечения на различные платформы, ремонтопригодностью, скоростью восстановления после сбоя, безопасностью, качеством, ограничениями и т. Д.

Требования, полученные от клиента, написаны на естественном языке. Системный аналитик несет ответственность за документирование требований на техническом языке, чтобы они были понятны и полезны группе разработчиков программного обеспечения.

SRS должна иметь следующие функции:

Требования пользователя выражаются на естественном языке.
Технические требования выражены на структурированном языке, который используется внутри организации.
Описание дизайна должно быть написано псевдокодом.
Формат форм и распечаток экрана графического интерфейса пользователя.
Условные и математические обозначения для DFD и т. Д.

Проверка требований к программному обеспечению

После разработки спецификаций требований утверждаются требования, упомянутые в этом документе. Пользователь может запросить незаконное, непрактичное решение, или эксперты могут неправильно интерпретировать требования. Это приводит к огромному увеличению стоимости, если не пресекать ее в зародыше. Требования можно проверить на соответствие следующим условиям -

Если они могут быть реализованы на практике
Если они действительны и соответствуют функциональности и области применения программного обеспечения
Если есть неясности
Если они полные
Если они могут быть продемонстрированы

Процесс предъявления требований

Процесс запроса требований можно изобразить с помощью следующей диаграммы:

Requirements gathering - Разработчики обсуждают с клиентом и конечными пользователями и знают их ожидания от программного обеспечения.
Organizing Requirements - Разработчики расставляют требования по приоритетам и упорядочивают их по важности, срочности и удобству.
Negotiation & discussion - Если требования неоднозначны или есть некоторые противоречия в требованиях различных заинтересованных сторон, если они есть, то это обсуждается и обсуждается с заинтересованными сторонами. Тогда требования могут быть расставлены по приоритетам и разумно скомпрометированы.

Требования исходят от различных заинтересованных сторон. Чтобы устранить двусмысленность и конфликты, они обсуждаются для ясности и правильности. Нереалистичные требования разумно скомпрометированы.
Documentation - Все формальные и неформальные, функциональные и нефункциональные требования документируются и становятся доступными для обработки на следующем этапе.

Методы выявления требований

Выявление требований - это процесс выяснения требований к предполагаемой системе программного обеспечения путем взаимодействия с клиентом, конечными пользователями, пользователями системы и другими лицами, заинтересованными в разработке системы программного обеспечения.

Есть разные способы узнать требования

Интервью

Интервью - сильная среда для сбора требований. Организация может проводить несколько типов интервью, таких как:

Структурированные (закрытые) интервью, в которых каждая информация, которую нужно собрать, решается заранее, они строго следуют шаблону и предмету обсуждения.
Неструктурированные (открытые) интервью, когда информация для сбора информации не решена заранее, более гибкие и менее предвзятые.
Устные интервью
Письменные интервью
Индивидуальные интервью, которые проводятся между двумя людьми за столом.
Групповые интервью, которые проводятся между группами участников. Они помогают выявить недостающие требования, поскольку в них задействовано множество людей.

Обзоры

Организация может проводить опросы среди различных заинтересованных сторон, задавая вопросы об их ожиданиях и требованиях от будущей системы.

Анкеты

Документ с заранее определенным набором объективных вопросов и соответствующих вариантов передается всем заинтересованным сторонам для ответа, которые собираются и компилируются.

Недостатком этого метода является то, что если вариант решения какой-либо проблемы не упоминается в анкете, проблема может остаться без внимания.

Анализ задачи

Команда инженеров и разработчиков может проанализировать операцию, для которой требуется новая система. Если у клиента уже есть какое-то программное обеспечение для выполнения определенной операции, оно изучается и собираются требования к предлагаемой системе.

Анализ домена

Каждое программное обеспечение попадает в определенную категорию домена. Специалисты в данной области могут оказать большую помощь в анализе общих и конкретных требований.

Мозговой штурм

Неформальные дискуссии проводятся между различными заинтересованными сторонами, и все их мнения записываются для дальнейшего анализа требований.

Прототипирование

Прототипирование - это создание пользовательского интерфейса без добавления подробных функций, позволяющих пользователю интерпретировать функции предполагаемого программного продукта. Это помогает лучше понять требования. Если на стороне клиента не установлено программное обеспечение для справки разработчика, и клиент не знает о своих собственных требованиях, разработчик создает прототип на основе первоначально упомянутых требований. Прототип демонстрируется клиенту, и отзывы отмечаются. Отзывы клиентов служат исходными данными для сбора требований.

Наблюдение

Команда экспертов посещает организацию или рабочее место клиента. Они наблюдают за фактической работой существующих установленных систем. Они наблюдают за рабочим процессом на стороне клиента и за тем, как решаются проблемы исполнения. Команда сама делает некоторые выводы, которые помогают сформировать требования, ожидаемые от программного обеспечения.

Характеристики требований к программному обеспечению

Сбор требований к программному обеспечению - это основа всего проекта разработки программного обеспечения. Следовательно, они должны быть ясными, правильными и четко определенными.

Полные технические требования к программному обеспечению должны быть:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Достоверный источник

Требования к программному обеспечению

Мы должны попытаться понять, какие требования могут возникнуть на этапе выявления требований и какие требования ожидаются от программной системы.

В целом требования к программному обеспечению следует разделить на две категории:

Функциональные требования

В эту категорию попадают требования, относящиеся к функциональной стороне программного обеспечения.

Они определяют функции и функциональные возможности внутри и из программной системы.

Примеры -

Опция поиска, предоставляемая пользователю для поиска по различным счетам-фактурам.
Пользователь должен иметь возможность отправлять любой отчет руководству по почте.
Пользователи могут быть разделены на группы, и группам могут быть предоставлены отдельные права.
Должны соответствовать бизнес-правилам и административным функциям.
Программное обеспечение разработано с сохранением обратной совместимости.

Нефункциональные требования

В эту категорию попадают требования, не связанные с функциональной стороной программного обеспечения. Это неявные или ожидаемые характеристики программного обеспечения, о которых пользователи предполагают.

Нефункциональные требования включают:

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Аварийное восстановление
Accessibility

Требования логически классифицируются как

Must Have : Программное обеспечение без них нельзя назвать работоспособным.
Should have : Расширение функциональности программного обеспечения.
Could have : Программное обеспечение по-прежнему может нормально работать с этими требованиями.
Wish list : Эти требования не соответствуют каким-либо целям программного обеспечения.

При разработке программного обеспечения должно быть реализовано «Должно быть», «Должно быть» является предметом обсуждения с заинтересованными сторонами и отрицания, тогда как «мог бы иметь» и «список желаний» можно сохранить для обновлений программного обеспечения.

Требования к пользовательскому интерфейсу

Пользовательский интерфейс - важная часть любого программного, аппаратного или гибридного оборудования. Программное обеспечение широко распространено, если оно -

легко работать
быстро в ответ
эффективное устранение операционных ошибок
обеспечение простого, но последовательного пользовательского интерфейса

Принятие пользователем во многом зависит от того, как пользователь может использовать программное обеспечение. Пользовательский интерфейс - это единственный способ восприятия системы пользователями. Хорошо работающая программная система также должна быть оснащена привлекательным, ясным, последовательным и отзывчивым пользовательским интерфейсом. В противном случае функциональные возможности программного комплекса невозможно будет использовать удобным образом. Система считается хорошей, если она предоставляет средства для ее эффективного использования. Требования к пользовательскому интерфейсу кратко упомянуты ниже -

Представление контента
Удобная навигация
Простой интерфейс
Responsive
Согласованные элементы пользовательского интерфейса
Механизм обратной связи
Настройки по умолчанию
Целенаправленный макет
Стратегическое использование цвета и текстуры.
Предоставьте справочную информацию
Ориентированный на пользователя подход
Настройки просмотра на основе группы.

Программный системный аналитик

Системный аналитик в ИТ-организации - это человек, который анализирует требования к предлагаемой системе и следит за тем, чтобы требования были задуманы и задокументированы должным образом и правильно. Роль аналитика начинается на этапе анализа программного обеспечения SDLC. Аналитик несет ответственность за то, чтобы разработанное программное обеспечение соответствовало требованиям клиента.

Системные аналитики несут следующие обязанности:

Анализ и понимание требований предполагаемого программного обеспечения
Понимание того, как проект будет способствовать достижению целей организации
Определите источники требований
Подтверждение требования
Разработать и внедрить план управления требованиями
Документирование деловых, технических, технологических требований и требований к продукции
Координация с клиентами для определения приоритетов требований и устранения двусмысленности
Завершение критериев приемки с клиентом и другими заинтересованными сторонами

Метрики и меры программного обеспечения

Программные меры можно понимать как процесс количественной оценки и обозначения различных атрибутов и аспектов программного обеспечения.

Программные метрики предоставляют меры для различных аспектов программного процесса и программного продукта.

Программные меры являются фундаментальным требованием программной инженерии. Они не только помогают контролировать процесс разработки программного обеспечения, но и помогают поддерживать высокое качество конечного продукта.

По словам Тома ДеМарко (инженера-программиста): «Вы не можете контролировать то, что не можете измерить». По его словам, очень ясно, насколько важны программные меры.

Давайте посмотрим на некоторые показатели программного обеспечения:

Size Metrics - LOC (Строки кода), в основном рассчитываемые в тысячах строк исходного кода, обозначаемые как KLOC.

Счетчик функциональных точек - это мера функциональности, предоставляемой программным обеспечением. Количество функциональных точек определяет размер функционального аспекта программного обеспечения.
Complexity Metrics - Цикломатическая сложность МакКейба количественно определяет верхнюю границу количества независимых путей в программе, которая воспринимается как сложность программы или ее модулей. Он представлен в терминах концепций теории графов с использованием графа потока управления.
Quality Metrics - Дефекты, их типы и причины, последствия, степень серьезности и их последствия определяют качество продукта.

Количество дефектов, обнаруженных в процессе разработки, и количество дефектов, о которых сообщает клиент после установки или доставки продукта на стороне клиента, определяют качество продукта.
Process Metrics - На различных этапах SDLC используемые методы и инструменты, стандарты компании и производительность разработки являются метриками процесса программного обеспечения.
Resource Metrics - Затраченные усилия, время и различные ресурсы представляют собой показатели для измерения ресурсов.