Требования к функционалу программы

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

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

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

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

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

Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft

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

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

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

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

2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)

Это «сможет» будет определяться квалификацией, инструментарием и, конечно же тем количеством времени, которое у него/них будет в наличии, а его, как известно, практически всегда не хватает. Таким образом, получается следующий парадокс – качество продукта будет напрямую зависеть не от стэйкхолдеров, а от специалистов, для которых важность продукта, который они разрабатывают, не очевидна. Стэйкхолдерам важно получить законченную функциональность в сроки согласованных работ , а иногда даже намного, намного ранее и получить дополнительное время на реализацию качественных атрибутов, значимость которых определяется только в процессе разработки. Именно поэтому многие характеристики разрабатываемого программного продукта и его архитектуры, скрытые от внимательного взора руководства, необходимо обозначать в активностях, предваряющих стадии проектирования и разработки. Многое на этой стадии зависит от опыта и мастерства системного архитектора и его команды, от профессионализма которых будет зависеть стратегический успех информационной системы, разрабатываемой для бизнес необходимостей конкретной организации.

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

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

Высокоуровневое назначение программного продукта — приносить выгоду его владельцу за счет автоматизации труда (интеллектуального, физического, монотонного и т.д. ) человека, а в идеале за счет полной замены человеческого ресурса и фактора, если это возможно.

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

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

Сначала мы рассмотрим функциональные требования .

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

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

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

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

• Цели разрабатываемого функционала;
• Задачи, которые должны быть выполнены для достижения поставленной цели;
• Сервисы, поддерживающие выполнение задач;
• … (и многое другое, касающееся непосредственно функциональных возможностей и особенностей программного продукта);

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

• Классический подход

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

Дополнительно отметим, что в подобном подходе основная тяжесть создания полноценного документа, охватывающего весь программный продукт , ложится на сотрудника, ответственного за сбор, анализ и синтез информации. При современной динамике изменений бизнес процессов и данных, поступающих от внешних и внутренних аспектов бизнеса, непосредственно влияющих на требования стэйкхолдеров, классический подход становится наименее эффективным. Именно поэтому в последнее время водопадные модели разработки программного обеспечения заменяются «гибкими» подходами (agile), цель которых в быстром и эффективном решении возникающих задач, даже если следующая будет противоречить предыдущей.

• Use cases (Варианты использования);

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

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

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

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

Они регламентируют внутренние и внешние условия функционирования программного продукта. Выделяют следующие основные группы нефункциональных требований:

• Атрибуты качества;

• Безопасность;
• Надежность;
• Производительность;

• Скорость и время отклика приложения;
• Пропускная способность workflow;
• Количество необходимой оперативной памяти;

• Платформа реализации архитектуры и программного продукта;
• Тип используемого сервера приложений;

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

Ранее описанная методология use cases может быть применена для сбора и анализа нефункциональных требований. При взаимодействии со стэйкхолдерами необходимо фиксацию каждого правила подытоживать фиксацией нефункциональных требований, выраженную в виде количественной характеристики определенного параметра: «программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности за время не более 0,5 с после того, как поступила соответствующая команда «

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

Прочие виды требований

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

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

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

• Время: Время на обучение пользователей, стабилизацию реализованных и внедренных принципов работы, поддерживающих достижение целей бизнес процессов, время на осознание организацией «хозяйнических» инстинктов по отношению к программному продукту

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

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

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

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

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

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

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

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

Рисунок 1 – Диаграмма прецедентов

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

Система должна предусматривать 4 роли пользователей: клиент, администратор, у каждой из которой свой состав функций.

а) просмотр ассортимента продукции пиццерии;

б) формирование заказа на основании текущего ассортимента;

в) создание заказа.

б) регистрация оператора;

в) добавление ассортимента продукции;

г) редактирование ассортимента продукции;

д) удаление ассортимента продукции.

б) просмотр перечня заказов;

в) изменение статуса заказа.

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

Устойчивое функционирование продукта должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:

1. организацией бесперебойного питания технических средств;
2. использованием лицензионного программного обеспечения;
3. регулярным выполнением требований ГОСТ 51188-98. «Защита информации. Испытания программных средств на наличие компьютерных вирусов».

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

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

Для реализации серверной части сайта, на сервере должны быть установлены PHP версии 2.7 и выше, PostgreSQL 11 и Codeigniter framework 3.1.10. Для размещения сайта в сети Интернет должен быть приобретен домен.

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

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

• MS IE 9.0 и выше;
• Opera 41.0 и выше;
• Mozilla Firefox 3.5;
• Chrome 49.0.

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

– процессор – 2 х IntelXeon 3 ГГц;

– объем оперативной памяти – 4 Гб;

– дисковая подсистема – 20 Гб;

– сетевой адаптер – 100 Мбит/с.

1. для ПК пользователя:

– процессор – IntelPentium 1.5 ГГц;

– объем оперативной памяти – 512 Мб;

– сетевой адаптер – 100 Мбит/с.

1.5 Требования к времени восстановления после отказа

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

1.6 Требования к составу и параметрам технических средств

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

1. Операционную систему Windows XP с пакетом обновления 2 и старше;
2. Процессор Intel Pentium 4 / Athlon 64 или более поздней версии с поддержкой SSE;
3. 350 Мб свободного места на диске;
4. 512 Мб оперативной памяти.

1.7 Требования к архитектуре приложения

В качестве архитектуры разрабатываемой системы необходимо использовать трехзвенную клиент-серверную архитектуру, где в качестве первого звена выступает браузер клиента, а в качестве второго – Rest API, в качестве третьего – сервер БД. Модель выбранной архитектуры представлена на рисунке 2.

Рисунок 2 — Архитектура разрабатываемой системы

2 Проектирование системы

2.1 Диаграмма состояний

Диаграмма состояний разработанной программной системы представлена на рисунке 3.

Диаграмма состояний (state diagram) определяет все возможные состояния, в которых может находиться клиент, а также процесс смены состояний объекта в результате влияния некоторых событий. Диаграммы состояний строятся для единственного класса и описывают поведение единственного объекта.

Рисунок 3  Диаграмма состояний для клиента

Источник: studfile.net

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

Тщательный анализ требований к ПО определяет успешность проекта в целом.

Функциональные требования: Основные функции (возможности), которыми должен обладать продукт, что закрепляется соглашением. Требования имеют вид: входные данные, подаваемые в ПО, выполняемые операции, и ожидаемые результаты.

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

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

• Портативность (переносимость между системами/платформами/типами девайсов)
• Безопасность
• Легкость обслуживания в дальнейшем, «ремонтопригодность» продукта
• Надежность и устойчивость
• Масштабируемость/расширяемость
• Производительность/продуктивность
• Реюзабельность/возможность применять в других условиях/окружениях
• Гибкость/настраиваемость

Функциональные и нефункциональные требования — таблица различий:

ФункциональныеНефункциональные

Описывает продукт или одну из функций	Описывает один из показателей качественности продукта
«ЧТО продукт должен выполнять?»	Ограничения на то, «КАК продукт должен выполнять свои функции?»
Описывается пользователями	Описывается техническими специалистами (системными архитекторами/техлидами/разработчиками)
Всегда должны быть описаны	Не столь обязательны как функциональные
Описываются в use-кейсах	Описываются как показатели качества
Описываются на уровне частей продукта	Описываются на системном уровне
Верифицирует функциональность	Верифицирует продуктивность и юзабельность
Системное, интеграционное, E2E, API	Нагрузочное, юзабилити, надежности
Сравнительно просто описывается	Более трудно описывается
Например 1) Авторизация пользователя при его входе в систему 2) Выключение системы во время кибератаки 3) Отправка имейла пользователю при первой регистрации в системе	Например 1) Имейл должен быть отправлен не позже чем через 2 часа с момента регистрации 2) Каждый запрос должен обрабатываться не более 5 секунд 3) Страница должна загружаться не более 3 секунд, если ее запрашивает более 10000 пользователей

Источник: testengineer.ru