МИНИСТЕРСТВО ПО РАЗВИТИЮ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И КОММУНИКАЦИЙ РЕСПУБЛИКИ УЗБЕКИСТАН ТАШКЕНТСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ИМЕНИ МУХАММАДА АЛ-ХОРАЗМИЙ Самостоятельная работа. По предмету “Dasturiy injiniringga kirish” На тему: Функциональные и нефункциональные требования. Требования процессов инжиниринга. Определение требования. Технические требования. Проверка требования. Изменение требования. Выполнил (а) QUDRATOV S. U. Ф.И.О студента. Группа 085-22 SDIr Принял (а): KUTDUSOVA E. R. Ташкент 2024. Содержания Введение 1. Функциональные и нефункциональные требования. 2. Требования процессов инжиниринга. 3 Определение требования. 4. Определение технических требований. 5. Проверка требования. 6. Изменение требования. Заключение. Список литературы. Введения Функциональные и нефункциональные требования В процессе разработки программного обеспечения и систем важное место занимают требования. Требования определяют, что система должна делать и какими характеристиками должна обладать. Они делятся на функциональные и нефункциональные. Функциональные требования описывают конкретные действия или функции, которые система должна выполнять. Например, они могут указывать, что пользователь должен иметь возможность создавать учетную запись или отправлять сообщения. Нефункциональные требования, в свою очередь, описывают характеристики системы, такие как производительность, надежность, масштабируемость и удобство использования. Требования процессов инжиниринга Процессы инжиниринга требований играют ключевую роль в успешной реализации проектов. Эти процессы включают выявление, документирование, анализ, проверку и управление изменениями требований. Выявление требований начинается с определения потребностей и ожиданий заинтересованных сторон. После этого идет документирование, которое обеспечивает ясность и понимание требований всеми участниками проекта. Анализ требований помогает выявить возможные конфликты и определить приоритеты. Проверка требований необходима для обеспечения их полноты, точности и соответствия исходным потребностям. Управление изменениями позволяет адаптировать требования к изменяющимся условиям и новым вводным. Определение требования Требование – это документированное утверждение о функции, характеристике или ограничении системы, которое должно быть выполнено для удовлетворения потребностей пользователей или достижения целей проекта. Определение требований является критически важным этапом, так как оно закладывает основу для всего процесса разработки. На этом этапе важно тщательно проработать требования, чтобы минимизировать риски и избежать недопонимания в дальнейшем. Технические требования Технические требования описывают технические аспекты и характеристики системы, необходимые для ее реализации и эксплуатации. Они включают в себя аппаратные и программные компоненты, архитектурные решения, стандарты и протоколы, которые должны быть соблюдены. Технические требования обеспечивают совместимость, надежность и эффективность системы, а также помогают определить границы и ограничения технической реализации. Проверка требования Проверка требований – это процесс оценки требований с целью подтверждения их правильности, полноты и соответствия исходным нуждам. В рамках этого процесса используются различные методы, такие как инспекции, обзоры и тестирование прототипов. Проверка требований позволяет выявить и устранить ошибки на ранних стадиях разработки, что способствует уменьшению затрат на исправление дефектов в дальнейшем. Изменение требования Изменение требований – это неизбежная часть любого проекта. Изменения могут возникать по разным причинам: изменение бизнес-целей, выявление новых потребностей, технологические новшества или внешние факторы. Управление изменениями требований включает в себя процедуры для контроля, оценки и утверждения изменений. Эффективное управление изменениями помогает сохранить согласованность и актуальность требований на протяжении всего жизненного цикла проекта, а также минимизировать риски, связанные с их реализацией. 1. Функциональные и нефункциональные требования. Требования к программной системе часто классифицируются как функциональные, нефункциональные и требования предметной области. Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать. Нефункциональные требования. Описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и тд. Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными. В действительности четкой границы между этими типами требований не существует. Например, пользовательские требования, касающиеся безопасности системы, можно отнести к нефункциональным. Однако при более детальном рассмотрении такое требование можно отнести к функциональным, поскольку оно порождает необходимость включения в систему средства авторизации пользователя. Поэтому, рассматривая далее эти виды требований, мы должны всегда помнить, что данная классификация в значительной степени искусственна. Классический пример (см. рисунок 4.3) высокоуровневого структурирования групп требований как требований к продукту описан в работах одного из классиков дисциплины управления требованиями – Карла Вигерса. Рисунок 4.3. Уровни требований по Вигерсу Группа функциональных требований Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения. Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Группа нефункциональных требований (Non-Functional Requirements) Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнеспроектов, для автоматизации которых создается соответствующее программное обеспечение. Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные функциональностью требования системы, связаны направленной на непосредственно решение с бизнес- потребностей. Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта пользователей и/или в различных разработчиков. “измерениях”, Атрибуты портируемости, интероперабельности (прозрачности важных касаются для вопросов взаимодействия с другими системами), целостности, устойчивости и т.п. Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам. Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных аппаратных подсистем. операций с использованием программно- 2. Требования процессов инжиниринга. Выявление требований является первым и критически важным этапом процесса инжиниринга требований. Целью этого этапа является сбор и определение требований от всех заинтересованных сторон, включая пользователей, заказчиков, разработчиков и других участников проекта. Методы выявления требований включают: Интервью: Проведение бесед с пользователями и другими заинтересованными сторонами для получения их мнений и ожиданий. Опросы и анкеты: Распространение опросов для сбора информации у большого числа пользователей. Рабочие группы и семинары: Организация совместных встреч для обсуждения и выработки требований. Анализ существующей документации: Изучение текущих систем и процессов для выявления требований. Наблюдение: Наблюдение за пользователями в процессе их работы для выявления скрытых требований. Методы документирования требований Документирование требований обеспечивает ясность и точность в понимании того, что должно быть разработано. К основным методам документирования требований относятся: Спецификации требований: Подробное описание всех функциональных и нефункциональных требований в виде текстового документа. Пользовательские истории: Краткие описания требований с точки зрения конечного пользователя, часто используемые в методологиях Agile. Диаграммы и модели: Визуальные представления требований, такие как диаграммы прецедентов, диаграммы потоков данных и архитектурные схемы. Прототипы: Создание ранних версий системы для визуализации требований и получения обратной связи. Анализ требований и выявление конфликтов Анализ требований направлен на оценку собранных данных для обеспечения их логичности, непротиворечивости и полноты. В этот этап входят: Выявление конфликтов: Определение и разрешение противоречий между требованиями. Определение приоритетов: Классификация требований по важности и срочности для эффективного планирования разработки. Анализ осуществимости: Оценка технической и финансовой выполнимости требований. Трассировка требований: Установление связей между требованиями и другими артефактами проекта для отслеживания изменений. Проверка требований: методы и инструменты Проверка требований — это процесс, направленный на подтверждение правильности, полноты и соответствия требований ожиданиям пользователей. К основным методам проверки требований относятся: Инспекции и обзоры: Формальное рассмотрение документов требований с целью обнаружения ошибок и недочетов. Тестирование прототипов: Проверка требований с помощью прототипов системы для выявления недочетов и получения обратной связи. Валидация с пользователями: Подтверждение того, что требования соответствуют потребностям и ожиданиям конечных пользователей посредством тестирования и обратной связи. Управление изменениями требований включает процедуры для контроля, оценки и утверждения изменений в требованиях. Основные шаги включают: Процедуры внесения изменений: Определение формальных процессов для внесения изменений в требования, включая подачу запросов на изменения и их рассмотрение. Оценка влияния изменений: Анализ влияния предложенных изменений на проект, включая оценку их влияния на сроки, бюджет и качество. Утверждение изменений: Формальное утверждение изменений уполномоченными лицами. Документирование изменений: Ведение записи всех изменений и их обоснований для обеспечения прозрачности и отслеживаемости. 3. Определение требования. Понятие требования Требование — это документированное утверждение о том, какую функцию должна выполнять система, какую характеристику должна иметь или какое ограничение должно быть соблюдено для удовлетворения потребностей пользователей и достижения целей проекта. Требования формируют основу для всех последующих этапов разработки и внедрения системы, обеспечивая ясность и согласованность в понимании задач и ожиданий всех заинтересованных сторон. Классификация требований Требования делятся на несколько основных категорий: Функциональные требования: Определяют конкретные функции и операции, которые система должна выполнять. Они описывают взаимодействие системы с пользователями и другими системами. Примеры включают: пользователь должен иметь возможность создавать учетные записи, система должна отправлять уведомления по электронной почте при определенных событиях. Нефункциональные требования: Описывают характеристики и атрибуты системы, такие как производительность, безопасность, надежность, масштабируемость и удобство использования. Примеры включают: система должна обрабатывать до 1000 запросов в секунду, время отклика системы не должно превышать 2 секунд. Бизнес-требования: Описывают высокоуровневые цели и задачи, которые система должна помочь достичь. Эти требования часто связаны с бизнес-стратегиями и ключевыми показателями эффективности. Примеры включают: система должна увеличить удовлетворенность клиентов на 20%, сократить затраты на обработку заказов на 15%. Технические требования: Определяют технические параметры и ограничения системы, такие как используемые технологии, стандарты и протоколы. Примеры включают: система должна быть разработана с использованием архитектуры микросервисов, система должна поддерживать стандарт безопасности данных PCI DSS. 4. Проверка требования. Понятие проверки требований Проверка требований — это процесс оценки требований для подтверждения их правильности, полноты, непротиворечивости и соответствия исходным потребностям и ожиданиям заинтересованных сторон. Основная цель проверки требований — убедиться, что документированные требования действительно отражают то, что необходимо пользователям, и могут быть реализованы в рамках проекта. Методы проверки требований Существует несколько методов, используемых для проверки требований: Инспекции и обзоры: Формальные процессы, в ходе которых группа специалистов (инспекторов) систематически проверяет документированные требования. В процессе обзоров выявляются ошибки, недочеты и возможные улучшения. Инспекции могут проводиться в форме встреч или письменного анализа. Тестирование прототипов: Создание и использование прототипов системы для проверки правильности и полноты требований. Прототипы позволяют пользователям и заинтересованным сторонам взаимодействовать с ранней версией системы и предоставлять обратную связь о том, насколько требования соответствуют их ожиданиям. Валидация с пользователями: Включает проведение встреч, интервью и опросов с конечными пользователями для подтверждения того, что требования правильно отражают их потребности. Валидация может также включать демонстрацию прототипов и сценариев использования. Анализ использования: Моделирование или симуляция системы на основе требований для оценки их реалистичности и выполнимости. Этот метод помогает выявить потенциальные проблемы на ранних стадиях. Инструменты для проверки требований Для проверки требований используются различные инструменты: Средства для совместной работы: Платформы и приложения для проведения инспекций и обзоров в режиме реального времени (например, Jira, Confluence, Google Docs). Программное обеспечение для прототипирования: Инструменты для создания интерактивных прототипов и макетов (например, Axure, Balsamiq, Sketch). Средства моделирования и симуляции: Программные решения для моделирования систем и процессов (например, MATLAB, Simulink). Трекеры и системы управления требованиями: Инструменты для управления требованиями и отслеживания изменений (например, IBM Rational DOORS, Jama Software). 5. Изменение требования. Эффективное управление изменениями включает несколько ключевых этапов: Инициирование изменений: Любое изменение начинается с запроса на изменение, который может быть инициирован любой из заинтересованных сторон. Запрос должен содержать описание изменения, обоснование и предполагаемое влияние на проект. Оценка изменений: Команда проекта проводит анализ влияния предлагаемого изменения на сроки, бюджет, ресурсы и качество проекта. Оценка включает технический и бизнес-анализ, а также оценку рисков. Принятие решений: На основе проведенной оценки принимается решение о принятии, отклонении или изменении запроса. Это решение обычно принимается специальным комитетом по управлению изменениями или руководством проекта. Реализация изменений: В случае утверждения изменения оно внедряется в проект. Это может включать пересмотр документации, обновление планов и графиков, а также корректировку разработанных или разрабатываемых компонентов системы. Документирование изменений: Все изменения должны быть тщательно документированы, включая их обоснование, оценку влияния и процесс внедрения. Это обеспечивает прозрачность и отслеживаемость изменений. Коммуникация изменений: Важно информировать всех заинтересованных сторон о внесенных изменениях, их обосновании и влиянии на проект. Эффективная коммуникация помогает избежать недопонимания и сопротивления изменениям. Инструменты для управления изменениями требований Для эффективного управления изменениями требований используются различные инструменты и методы: Системы управления требованиями: Инструменты, такие как IBM Rational DOORS, Jama Software и Jira, помогают отслеживать и управлять требованиями на всех этапах их жизненного цикла. Средства для совместной работы: Платформы, такие как Confluence, Slack и Microsoft Teams, облегчают коммуникацию и совместную работу над изменениями. Программное обеспечение для управления проектами: Инструменты, такие как Microsoft Project, Trello и Asana, помогают планировать и контролировать процесс внедрения изменений. Примеры успешного управления изменениями Примеры успешного управления изменениями включают проекты, в которых изменения требований были своевременно выявлены, тщательно оценены и эффективно внедрены без значительного влияния на сроки и бюджет. Ключевыми факторами успеха являются проактивное управление, прозрачность и эффективная коммуникация с заинтересованными сторонами. Заключения Функциональные и нефункциональные требования являются основополагающими элементами в разработке успешных программных продуктов и систем. Они определяют, что система должна делать и какими характеристиками обладать, создавая ясное и исчерпывающее представление о конечном продукте. Разработка и управление требованиями требуют тщательного и системного подхода, который охватывает все аспекты инжиниринговых процессов. Процессы инжиниринга требований, включающие выявление, документирование, анализ, проверку и управление изменениями, играют ключевую роль в обеспечении успешной реализации проектов. Эти процессы помогают выявить и устранить возможные проблемы на ранних этапах, что способствует снижению рисков и повышению качества конечного продукта. Определение требования — это фундаментальный этап, на котором формируются ожидания и потребности пользователей. Тщательная проработка требований на этом этапе обеспечивает ясность и понимание целей проекта всеми заинтересованными сторонами. Технические требования, описывающие технические аспекты системы, гарантируют, что разработка будет осуществляться в соответствии с заданными стандартами и протоколами. Они обеспечивают совместимость, надежность и эффективность системы, что критически важно для ее успешного функционирования. Проверка требований — это процесс, который позволяет убедиться в правильности и полноте требований. Своевременная проверка помогает выявить и устранить ошибки, что снижает вероятность возникновения проблем на поздних стадиях разработки и эксплуатации. Изменение требований — неизбежная часть любого проекта. Эффективное управление изменениями позволяет адаптировать систему к новым условиям и потребностям, сохраняя согласованность и актуальность требований на протяжении всего жизненного цикла проекта. В заключение, успешное управление функциональными и нефункциональными требованиями, а также процессами их инжиниринга, обеспечивает основу для создания высококачественных и востребованных продуктов. Комплексный подход к работе с требованиями способствует достижению целей проекта и удовлетворению потребностей пользователей, что является залогом успешной реализации любых проектов в области разработки программного обеспечения и систем. Список литература. язык программирование пользовательский 1 Lynn Beighley & Michael Morrison Head First PHP Издание “O‘Reilly”. 812 стр., 2019год 2 PHP (2 book set) by Jon Duckett. Издание “Wiley”. 1152 стр., 2014 год 3 https://chatgpt.com/c/59693e3b-1cd7-4fb7-b5ee-35a91c32e79c. 4 https://www.irisoft.ru/interesting/inzhiniring-trebovanij-formirovanie-iupravlenie-trebovanijami/.
