Пользовательские требования к программе

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

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

Далее составляются системные требования. Они включат в себя:

1. Требования к архитектуре системы. Например, число и размещение хранилищ и серверов приложений.

2. Требования к параметрам оборудования. Например, частота процессоров серверов и клиентов, объём хранилищ, размер оперативной и видео памяти, пропускная способность канала и т.д.

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

4. Требования к программному интерфейсу.

Как писать User Story?

5. Требования к структуре системы. Например, Масштабируемость, распределённость, модульность, открытость.

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

· распределенность — система должна поддерживать распределённое хранение данных.

· модульность — система должна состоять из отдельных модулей, интегрированных между собой.

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

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

Разработка технического задания

Техническое задание оформляют в соответствии с ГОСТ 34.602—89. Техническое задание должно содержать следующие раз­делы:

· наименование и область применения;

· основание для разработки;

· технические требования к программе или программному изделию;

· стадии и этапы разработки;

· порядок контроля и приемки;

Содержание разделов

ü Введение должно включать краткую характеристику области применения программы или программного продукта, а также объекта (например, системы), в котором предполагается их использовать. Основное назначение введения — продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных.

ü В разделе «Наименование и область применения» указы­вают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

ü В разделе «Основание для разработки» должны быть указаны:

• документ (документы), на основании которых ведется разработка. Таким документом может служить план, приказ, договор и т. п.;

Как написать пользовательский сценарий для интерфейса сайта или приложения

• организация, утвердившая этот документ, и дата его утверждения;

• наименование и (или) условное обозначение темы разработки.

ü В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

ü. Раздел «Технические требования к программе или про­граммному изделию» должен содержать следующие подразделы:

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

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

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

• требования к составу и параметрам технических средств — указывают необходимый состав технических средств с указанием их технических характеристик;

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

• требования к маркировке и упаковке в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки;

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

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

ü В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

ü В приложениях к техническому заданию при необходимости приводят:

• перечень научно-исследовательских и других работ, обосновывающих разработку;

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

• другие источники разработки.

В случаях, если какие-либо требования, предусмотренные техническим заданием, заказчик не предъявляет, следует в соответствующем месте указать «Требования не предъявляются».

Источник: studopedia.su

Пользовательские требования

«Пользовательские требования» (user requirements) описывают цели и задачи, которые пользователи смогут решать при помощи системы.

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

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

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

«Функциональные требования» (functional requirements) определяют функциональность программного обеспечения, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках «пользовательских» и «бизнес требований». Иногда они называются требованиями поведения (behavioral requirements), т.к. они описывают детальное поведение системы, выполняемые ею действия и отклики, а также информацию, которой система будет управлять. Так как «функциональное требование» является низкоуровневым описанием действий системы, их часто описывают в виде методов (операций) класса и данных, которые обрабатываются в конкретном методе. «Функциональные требования» документируются в спецификации требований к программному обеспечению (техническом задании) или постановках задач на разработку.

Характеристики качества

«Характеристики качества» (quality of service) описывают цели и атрибуты качества разрабатываемой системы. Атрибуты качества системы (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:

• легкость и простота использования (usability)
• производительность (performance)
• удобство эксплуатации и технического обслуживания (maintainability)
• надежность и устойчивость к сбоям (reliability)
• взаимодействия системы с внешним миром (interfaces)
• расширяемость (scalability)
• требования к пользовательским и программным интерфейсам (user and software interface).

«Характеристики качества» определяются для каждого варианта использования системы (совокупности вариантов использования) или для системы в целом. «Характеристики качества» не описывают то, что система должна делать, они описывают то, как система должна или не должна работать. Например, для варианта использования «Зарегистрировать читателя» могут быть определены:

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

На рис. 1 представлена примерная классификация характеристик качества программного обеспечения: Рис 1. Классификация характеристик качества

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

Высокая доступность и удобный интерфейс: разрабатываем нефункциональные требования

Продолжая обучение начинающих системных и бизнес-аналитиков основам разработки ТЗ, сегодня рассмотрим, что такое нефункциональные требования к ПО и как их составить. Также разберем, чем доступность отличается от надежности, как измерить качество пользовательского интерфейса и других характеристик проектируемой системы с комментариями BABOK®Guide, а также рекомендациями российских ГОСТ’ов и зарубежных стандартов.

Что такое нефункциональные требования и какие они бывают: взгляд BABOK®Guide

Как логично следует из названия, функциональные требования описывают функции ПО, т.е. его поведение, а нефункциональные относятся к характеристикам и условиям работы. Руководство к профессиональному своду знаний по бизнес-анализу BABOK®Guide отмечает, что нефункциональные требования означают особенности эксплуатации: производительность, информационную безопасность, удобство использования и прочие свойства, выражаемые в измеримых показателях, которые являются своего рода ограничениями варианта реализации (дизайна) решения.

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

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

Лучшее из BABOK®Guide: ТОП-10 задач и 20+ техник для аналитика

Код курса

EXBAB

Ближайшая дата курса

11 сентября, 2023

Длительность обучения

24 ак.часов

Стоимость обучения

45 000 руб.

Рекомендации стандартов по разработке ТЗ и примеры измерения нефункциональных требований

Российские ГОСТ’ы по разработке технического задания (ТЗ), 34.602-89 и 19.201-78, которые мы разбирали здесь, также предлагают свой список нефункциональных требований, который частично пересекается с перечнем BABOK. Зарубежные стандарты по спецификации требований к ПО (SRS, Software Requirements Specification), ISO IEEE 29148-2018 и IEEE 830-1998, тоже приводят рекомендации по атрибутам качества ПО, которые можно использовать в качестве нефункциональных требований.

Еще атрибуты качества ПО подробно разбираются в стандарте ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015) «Требования и оценка качества систем и программного обеспечения. Модели качества систем и программных продуктов». Наконец, некоторые метрики оценки качества, которые относятся к ИТ-сервису, упомянуты в библиотеке ITIL. Разумеется, в каждом конкретном случае не все категории нефункциональных требований будут упомянуты в отдельно взятом ТЗ или SRS. Однако, поскольку нефункциональные требования являются именно требованиями, а не пожеланиями, они должны быть точно сформулированы и иметь четкие критерии проверки их достижимости, т.е. значения упомянутых характеристик.

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

Наиболее часто используемым показателем для измерения доступности является значение SLA (Service Level Agreement, соглашение об уровне предоставления услуг между поставщиком и потребителем). Этот показатель обычно измеряется в процентах и говорит о времени безотказной работы и простоя системы.

Например, при SLA 99,99% максимальный период возможной недоступности системы в день соответствует 9 секундам, а время безотказной работы составляет 23 часа 59 минут и 51 секунду. Если брать годовой период измерения (365 дней или 8760 часов), то при этом уровне SLA система может быть недоступной 52 минуты и 36 секунд.

Чем выше уровень SLA, тем дороже будет TCO (Total Cost Ownership, общая стоимость владения) системы. Для некоторых решений, связанных с жизненно важными сервисами, требуется действительно высокая доступность со SLA близким к 100%, например, уровень «5 девяток» – 99,999%. А для приложений внутреннего документооборота или других учетных систем в рамках одного предприятия такой SLA будет избыточным. Для расчета времени безотказной работы существует множество открытых сервисов, например, http://shootnick.ru/uptime/99.

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

Чтобы снизить степень неопределенности и облегчить процесс верификации требований, аналитик должен определить критерии их приемки. Например, требование к удобству пользовательского интерфейса может быть сформулировано как необходимость соответствия предписаниям ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности». Для веб-приложений актуальны время первого отклика страницы и адаптация к мобильным устройствам, что можно выразить в численных значениях с помощью сервиса https://developers.google.com/speed/pagespeed/insights.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

TTIS

Ближайшая дата курса

24 июля, 2023

Длительность обучения

12 ак.часов

Стоимость обучения

20 000 руб.

Удобство использования в контексте обучения можно выразить долей пользователей, которые освоят часть функциональных возможностей системы за конкретный период времени. Например, 95% пользователей должны быть способны использовать 80% функций системы не более чем через 8 часов обучения. Эффективность работы может выражаться в быстродействии или объеме обрабатываемых данных, например, система должна выполнять 90% запросов не более чем за 1 секунду в условиях средней загрузки (10 тысяч пользователей и объем трафика 1 Гб/сек).

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

Источник: babok-school.ru