Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). В процессе сботребований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики,разработчики или пользователи.
Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. Требования к ПО должны быть документируемые, выполнимые, тестируемые, с уровнем детализации, достаточным для проектирования системы. Требования могут быть функциональными и нефункциональными.
Анализ требований включает три типа деятельности:
- Сбор требований — общение с клиентами и пользователями, чтобы определить, каковы их требования; анализ предметной области.
- Анализ требований — определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований.
- Документирование требований — требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.
Анализ требований может быть длинным и трудным процессом, во время которого вовлечены много тонких психологических навыков. Новые системы изменяют окружающую среду и отношения между людьми, поэтому важно определить все заинтересованные лица, принять во внимание все их потребности и гарантировать, что они понимают значения новых систем.
#7 Что такое требования?
Аналитики могут использовать несколько методов, чтобы выявить следующие требования от клиента: проведение интервью, использование фокус-групп или создание списков требований. Более современные методы включают создание прототипов и сценариев использования. Где необходимо, аналитик будет использовать комбинацию этих методов, чтобы выявить точные требования заинтересованных лиц так, чтобы была создана система, которая удовлетворяет деловые потребности.
Процесс анализа требований к информационной системе включает следующие фазы:
- Разработка требований
- Выявление требований
- Анализ требований
- Спецификация требований
- Проверка требований
- Управление требованиями
Источник: unetway.com
3.13. Требования к программному обеспечению.
Ранее были рассмотрены функции системы. Функции представляют собой описания желательного и полезного поведения. Покажем соответствие между функциями и требованиями к программному обеспечению. В документе видения описаны функции на языке пользователя. Требования к программному обеспечению, в свою очередь, описывают эти функции более подробно.
Что такое функциональные требования 🛰 ? Четкая постановка задач разработчику
Чтобы предоставить пользователю некую функцию, разработчики должны выполнить одно или несколько конкретизированных программных требований. Другими словами, функции помогают понимать и обсуждать систему на высоком уровне абстракции, но с их помощью невозможно описать систему и создать на основании этого описания код. Для этой цели функции слишком абстрактны.
Требования к программному обеспечению более конкретизированы. Мы собираемся на их основе создавать код. Следовательно, они должны быть «тестируемыми», т.е. достаточно конкретными, чтобы можно было проверить, действительно ли система реализует некое заданное требование.
Функциональные требования к программному обеспечению описывают, как ведет себя система. Эти требования обычно ориентированы на действия и содержат формулировки вида: «Когда пользователь делает X, система будет делать Y». Большинство продуктов и приложений, предназначенных для выполнения полезной работы, содержит множество функциональных требований к программному обеспечению. Программное обеспечение используется для реализации большей части функциональных возможностей.
При определении функциональных требований к ПО следует искать золотую середину между слишком конкретизированной формулировкой требования и слишком общей и неоднозначной. Например, как правило, ни к чему иметь обобщенное функциональное требование следующего вида: «Когда пользователь нажимает кнопку “Пуск”, система запускается и начинает работать». С другой стороны, формулировка требования, которая состоит из нескольких страниц текста, по-видимому, слишком конкретизирована, хотя и может быть правомерной в некоторых частных случаях. Опыт свидетельствует, что определение требования, состоящее из одного — двух предложений, обычно является наилучшим, когда нужно соотнести потребность пользователя с приемлемым для работы команды разработчиков уровнем конкретизации.
Нефункциональные требования к программному обеспечению
Функциональные требования описывают, как система должна вести себя, когда ей предоставляются определенные входные данные или условия. Но этого недостаточно для полного описания требований к системе. Необходимо также учитывать следующие характеристики, которые Роберт Грейди (Grady) [7] назвал «нефункциональными требованиями».
- практичность (Usability);
- надежность (Reliability);
- производительность (Performance);
- возможность обслуживания (Supportability).
Эти требования, как правило, используются для описания некоторых «атрибутов системы» или «атрибутов системного окружения». Благодаря их удобной классификации команда может больше узнать о системе, которую необходимо создать.
Требования практичности.
Важно описать, насколько легко будущие пользователи смогут освоить данную систему. Если предполагается, что заказчик будет просматривать требования и участвовать в их обсуждении, следует все требования в этой сфере писать на естественном языке. Поскольку практичность зависит от точки зрения наблюдателя, целесообразным будет привести следующие рекомендации:
Указать необходимое время подготовки пользователя для достижения минимальной производительности (способности выполнять простые задачи) и операционной производительности (способности выполнять обычные текущие задачи). В этом случае может понадобиться добавить в глоссарий проекта отдельные описания для начинающих пользователей (которые, быть может, никогда прежде не видели компьютер), средних и опытных.
Указать время выполнения типичных задач или транзакций, осуществляемых конечным пользователем. При создании системы ввода заказов на покупку, вероятно, наиболее типичными задачами, выполняемыми конечными пользователями, будут ввод, удаление или модификация заказа, а также проверка состояния заказа. Если пользователь знает, как выполнять эти задачи, сколько времени он потратит на ввод типичного заказа: 1 минуту, 5 минут, 1 час… Безусловно, эта характеристика будет зависеть от технической реализации: пропускной способности сети, объема оперативной памяти, мощности процессора, которые совместно определяют время ответа, обеспечиваемое системой, но время выполнения задач также напрямую зависит от практичности системы, и нужно иметь возможность зафиксировать это значение.
Сравнить практичность новой системы с уже существующими современными системами, которые известны и пользуются успехом у пользователей. Иными словами, требование может выглядеть так: «Новая система должна быть признана подавляющим большинством (90%) пользователей такой же практичной, как и существующая XYZ-система». Обратите внимание, что нефункциональные требования к ПО, равно как и все остальные, должны допускать возможность проверки соответствия. Команда разработчиков должна описывать требование так, чтобы пользователи могли проверить соответствие практичности установленному критерию.
Оговорить существование систем интерактивных подсказок, программ-помощников, средств предупреждения, руководств пользователя и других форм документации и помощи, а также определить их функциональное поведение.
Следовать соглашениям и стандартам, разработанным для человеко-машинного интерфейса. Чтобы новая система работала «почти так же, как та, которую пользователь уже использовал», необходимо следовать согласованным стандартам от приложения к приложению.
Например, можно указать требование соответствия общим стандартам практичности, таким как стандарты CUA (Common user access) компании IBM или стандарты Windows-приложений, опубликованные компанией Microsoft. Примером подлинного прорыва в сфере практичности в компьютерном мире может служить разница между командными строками операционных систем DOS и UNIX и GUI-интерфейсами операционных систем Windows и Macintosh. GUI-интерфейсы значительно упростили использование компьютера для пользователей, не имеющих технического образования. Еще одним примером является Internet-браузер, который стал окном в мир World Wide Web и радикально ускорил освоение Internet рядовым пользователем.
Было предпринято несколько попыток сделать более строгим весьма расплывчатое понятие практичности. Наибольший интерес представляет так называемый «Билль о правах пользователей», предложенный Каратом (Karat), [8]. Последняя его версия состоит из десяти основных пунктов.
- Пользователь всегда прав. Если возникает проблема с использованием системы, то дело в системе, а не в пользователе
- Пользователь имеет право на программное и аппаратное обеспечение, которое легко монтируется и демонтируется без негативных последствий.
- Пользователь имеет право на то, чтобы система делала в точности то, что обещано.
- Пользователь имеет право на простые в использовании инструкции (руководства пользователя, интерактивные или контекстно-зависимые подсказки, сообщения об ошибках), которые позволят ему понимать систему и использовать ее для достижения желаемых целей, а также эффективно и легко выходить из сложных ситуаций.
- Пользователь имеет право на внимание со стороны системы, а также на то, чтобы иметь возможность получить ответ системы на запрос о внимании.
- Пользователь имеет право на то, чтобы система предоставляла четкую, понятную и точную информацию о выполняемой задаче и ее выполнении.
- Пользователь имеет право на то, чтобы его информировали о всех системных требованиях для успешного использования программного обеспечения или аппаратуры.
- Пользователь имеет право знать о пределах возможностей системы.
- Пользователь имеет право общаться с провайдером технологии и получать полные и исчерпывающие ответы, когда в этом возникает необходимость.
- Пользователь должен быть хозяином программных и аппаратных технологий, а не наоборот. Продукты должны использоваться естественно и интуитивно.
Следует отметить, что некоторые из перечисленных пунктов по своей сути являются неизмеримыми и не могут выступать в роли кандидатов в требования. С другой стороны, ясно, что это документ может служить отправной точкой при определении требований, касающихся практичности предлагаемого продукта.
Требования надежности.
Конечно, никому не нравятся ошибки, системные сбои или потери данных. К счастью, даже самый оптимистично настроенный пользователь знает, что ошибки и сбои программы неизбежны. Таким образом, в требованиях следует указывать, в какой степени система обязана вести себя приемлемым для пользователя образом. Как правило, при этом описываются следующий набор показателей.
Доступность (availability). Система должна быть доступна для операционного использования в течение указанного времени (в процентном выражении). Иногда требование может указывать непрерывную «nonstop» доступность, т.е. 24 часа в сутки, 365 дней в году. Однако на практике чаще оперируют, к примеру, 99-процентной доступностью между 8 часами утра и полуночью.
При этом следует определить, что понимается под «доступностью». Означает ли процентная доступность, что все пользователи должны иметь возможность использовать все системные услуги в любое время?
Среднее время между сбоями (mean time between failures, MTBF). Обычно оно указывается в часах, но может также указываться в днях, месяцах или годах. Здесь тоже нужна точность: требования должны четко определять, что понимается под «сбоем».
Среднее время восстановления (mean time to repair, MTTR). Как долго системе разрешается не работать после сбоя? MTTR может иметь несколько значений; например, пользователь может указать, что 90% всех системных сбоев должны ликвидироваться за 5 минут, а 99.9% — в течение часа. Вновь важна точность: требования должны четко указывать, означает ли восстановление, что все пользователи снова будут иметь возможность получать доступ ко всем услугам, или допускается частичное восстановление системы.
Точность (accuracy). Указывается точность в системах с числовым выводом. Например, должны ли результаты в финансовых системах приводиться с точностью до копеек или рублей, каково количество точек после запятой в системе, осуществляющей математические расчеты.
Количество различных ошибок. Обычно ошибки делятся на незначительные, серьезные и критические. Здесь также важны четкие определения: требования должны определять, что понимается под «критической» ошибкой — полная потеря данных или невозможность использовать определенную часть функциональных возможностей системы.
Требования производительности
При записи требований производительности обычно используют следующие характеристики:
- среднее и максимальное время ответа для транзакции;
- число транзакций в секунду, именуемое также пропускной способностью;
- емкость: количество пользователей или транзакций, которые система может обслуживать;
- допустимые режимы снижения производительности при ухудшении параметров работы системы.
Если новая система должна совместно с другими системами или приложениями использовать аппаратные ресурсы (ЦП, память, каналы, дисковую память, сетевой диапазон частот), может потребоваться указать, насколько «цивилизованно» она себя при этом ведет.
Возможность обслуживания
Возможность обслуживания заключается в способности легко модифицировать программное обеспечение с целью внесения изменений и исправлений. В некоторых предметных областях можно заранее предвидеть вероятную природу будущих изменений, и требования могут содержать указание «времени ответа» группы поддержки для простых, средних и сложных изменений.
Например, команда работает над созданием новой системы бухгалтерского учета. Одно из многих требований к такой системе состоит в автоматическом расчете налога на добавленную стоимость при генерации счетов-фактур. Опытные бухгалтеры — пользователи системы располагают информацией, что налоговые органы периодически изменяют ставку налога. Тогда требование можно сформулировать следующим образом: «Модификация системы с целью задания новой ставки налогообложения должна осуществляться командой в течение одного дня после получения уведомления от налоговых органов».
Но предположим, что налоговая инспекция периодически вносит в алгоритм расчета налога на добавленную стоимость существенные поправки, например следующего вида: «Разрешено ведение бухгалтерского учета по упрощенной схеме налогообложения. При этом предприятия, работающие по упрощенной схеме освобождены от уплаты НДС. Налог на прибыль в этом случае исчисляется как 10 процентов от оборота по счету юридического лица за отчетный период». Подобные модификации сложнее предусмотреть в программе; хотя можно попытаться сделать ее максимально гибкой. Команда разработчиков, вероятно, согласится, что данная модификация попадает в категорию изменений «среднего уровня» сложности, для которых требование может задавать время реагирования — одна неделя.
Ограничения проектирования
Ограничения проектирования налагаются на проект системы или процессы, с помощью которых система создается. Они не влияют на внешнее поведение системы, но должны выполняться для удовлетворения технических, деловых или контрактных обязательств.
Типы ограничений проектирования приведены в табл. 3.12.
Таблица 3.12. Типы ограничений проектирования.
Тип источника ограничения
Программа должна быть написана на Visual Basic.
Источник: studfile.net
Требование к программе или программному продукту
Работа риэлторов заключается в общение с клиентами, работа с документами и базами предложений, показ квартир, ведение деловых переговоров по телефону и лично, организация сделок и их оформление. Данная программа поможет объединить несколько задач. Объединить всю информацию о клиентах, о недвижимости, о поставщиках в одну базу данных; сделать работу с удаленной базой данных; шаблоны договоров и вывод нужной информации на печать; все это упростив и ускорив процесс совершения сделки.
1.2. Постановка задачи
Для того что бы улучить работоспособность риэлторов — облегчить работу, повысить скорость поиска, защищенность информации, качество информации, надежность и т.д. Возникли предпосылки автоматизации данного комплекса задач.
Целью автоматизированного варианта решения комплекса задач с точки зрения риэлторов является повышение качества рабочего процесса. Для достижения выделенных целей автоматизации комплекса задач, необходимо выполнение соответствующих подцелей, а именно:
1. улучшение показателей работы риэлторов:
1) увеличение скорости поиска и обработки информации риэлторами по недвижимости;
2) повышение уровня над данными;
3) увеличение скорости и производительности по составлению договоров и заключению сделок;
2. улучшение значений показателей качества обработки информации:
1) полное и эффективное использование технических средств, имеющихся в наличии;
2) анализ и группировка информации;
3) сокращение времени поиска, обработки и получения данных;
4) повышение достоверности и точности информации, степени ее защищенности.
3. ввод, редактирование, удаление и обновление данных:
1) о недвижимости, клиентах;
2) об отдельном клиенте;
3) об отдельном объекте;
4. составление и вывод на печать различных документов и отчётов:
1) составление и печать описание объектов;
2) составление и печать данных клиента;
3) составление и печать договора;
5. выдача справочной информации:
1) справочник «Жилой кодекс РФ»;
АИС «Риэлтор плюс» должно функционировать на рабочем месте сотрудников, которые не имеют специальных навыков программирования. Поэтому программа должна иметь дружественный по отношению к пользователю интерфейс, а также интуитивно понятен и быть прост в освоении.
Основание для разработки
Основанием для разработки является задание, выданное на 2 технологическую практику для разработки АИС «Риэлтор плюс» и утверждено зам. директора по учебной работе Красногорского Государственного Колледжа.
Назначение разработки
Главной идеей разработки программы АИС «Риэлтор плюс» было комплексное объединение функций, таких как:
1. Работа с базой данных;
2. Составление договоров;
3. Web-поиск;
4. Отправка электронных писем;
5. Жилищный кодекс РФ;
Это должно ускорить и облегчить выполнение работы риэлторов.
Требование к программе или программному продукту
Главной задачей программы АИС «Риэлтор плюс» эта работа с базой данных и составление договоров, дополнительные функции программы это – Web-поиск, отправка электронного письма, помощник по «Жилищному кодексу РФ».
Работа с базой данных представлена в 2 режимах:
В удаленном — происходит подключение к удаленной базе данных через технологию «Клиент-Сервер». Пользователь подключившись к базе данных работает с ней, после завершения работы база данных сохраняется и в обновленном виде находится на сервере.
В клиентском режиме клиент подключает свою базу данных, которая находится на его компьютере или съемном носителе. После работы с базой данных она обновляется.
Функция составление договоров помогает составить договор из данных и тут же вывести его на печать.
Web- поиск представляет собой встроенные браузер. Это удобно тем что можно быстро начать поиск нужной информации в интернете не выходя из программы. Функция отправки электронных писем, способствует отправке всех необходимых данных не выходя из программы и не заходя на электронную почту. Помощник по «Жилищному кодексу РФ» производит поиск по статьям, а так же просто по не обходимым сточкам или словам.
Требование к надежности
Программа должна производить проверку подключения к интернету, без перебойно работать с базой данных как в удаленном так и в клиентском режимах. В случае сбоев выдавать сообщение об ошибке.
Источник: poisk-ru.ru