1 для чего определяются высокоуровневые требования к системе

Понятие требования. Классификации требований

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

Существуют различные трактовки понятия «Системные требования» ( system requirements ).

INCOSE (International Council on Systems Engineering ) дает более детальное определение системы: «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы». Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [2.8]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.

Функциональные, нефункциональные требования и характеристики продукта

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

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

Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).

Основные атрибуты качества:

достаточно хорошо раскрыты в модели FURPS (см. ниже).

Существует и более общий взгляд на данное понятие [2.9]: «features могут быть как относящимися к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта».

С.Орлик в [2.6] отмечает, что «с точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными».

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

Классификация RUP

В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [2.1].

Акроним FURPS обозначает следующие категории требований:

Символ «+» расширяет FURPS-модель, добавляя к ней:

часть из которых уже была рассмотрена выше.

Кроме того, в спецификациях RUP выделяются такие категории требований, как

FURPS (Functionality Usability Reliability Performance Supportability: функциональность, удобство использования, надежность, производительность, удобство сопровождения)— классификация требований к программным системам, разработанная в Hewlett-Packard. Согласно классификации, все требования подразделяются на 5 категорий, непосредственно следующих из составляющих наименования классификации. В настоящее время используется, как составная часть более общей классификации FURPS+.

FURPS+ (Functionality Usability Reliability Performance Supportability +: функциональность, удобство использования, надежность, производительность, удобство сопровождения, дополнительные требования) — расширенная версия классификации требований FURPS. Дополнительно включает в себя ограничения, разделенные на следующие группы требований:

Подробно описана в работе Роберта Грейди.

Методологии и стандарты, регламентирующие работу с требованиями

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

Источник

Типы требований к ПО с примерами | часть 2

Jan 1, 2019 · 4 min read

Откуда берутся требования? Какие вообще бывают требования? Об этом — читайте в этой статье.

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

🔥 Интересуешься тестированием и хочешь получать актуальную информацию?

👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!

QA_PRO | Тестирование

Информация по обеспечению качества (QA), контролю качества (QC) и тестированию ПО

Источники требований

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

Для выявления требований чаще всего используются следующие техники:

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

Типы требований

П о чти в каждом проекте существует 3 заинтересованных стороны:

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

Уровень заказчика (бизнес-требований)

На этом уровне находится только один тип требований – бизнес требования (business requirements).

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

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

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

Основываясь на этих требованиях можно получить общее видение проекта.

Уровень пользователя

Описывают “взгляд” на продукт глазами пользователя.

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

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

Пример оформления этих же требований в виде User Stories

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

Доступ к инструменту предоставляется только сотрудникам поддержки уровня Main support и выше.

Аналитики не должны иметь возможности изменять полученные отчеты.

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

Система должна работать с большими объёмами данных (сотни тысяч записей).

Уровень разработки (продуктных требований)

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

Конечным документом, содержащим все требования уровня разработки является Спецификация требований (software requirements specification, SRS). Часто это объемный документ, содержащий сотни страниц.

К уровню разработки относятся следующие типы требований:

Список проверок должен быть отсортирован по конечной дате выполнения (deadline) заказа.

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

Приложение должно поддерживать работу с мобильных устройств (минимальная ширина экрана – 320 px).

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

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

Основными подгруппами являются:

Приложение должно работать в последних версиях браузеров Chrome, Firefox, Safari.

Приложение должно работать на Raspberry PI 3b+.

Весь трафик между браузером и сервером должен быть зашифрован (HTTPS соединение).

Отправка письма с отчетом на почту аналитиков должно выполняться согласно RFC3207 (SMTP over TLS).

Все данные системы должны храниться в БД под управлением СУБД MySQL.

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

Теперь у вас есть понимание того, что:

Осталось определиться с тем, что такое “качественные” требования, и какими свойствами они должны обладать, чтоб с ними было проще работать в дальнейшем.

Источник

Дополняем Scrum архитектурными процессами. Часть 1. Требования

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

В данном цикле статей, автор предлагает свое видение архитектурных процессов в рамках Scrum, которые вытачивались им на нескольких проектах (мобильные банки), в том числе на текущем (CleanEngine). Область применения подхода: business critical, mission critical и life critical проекты.

В статьях используются определения, термины и подходы архитектурной школы Carnegie Mellon Software Engineering Institute (SEI), равно как и авторов, связанных с этой школой. Так же предполагается, что команда не нарушает базовые принципы Scrum, такие как, например, самоорганизация. При этом, не обязательно, чтобы команда состояла из высококлассных специалистов, как требует Scrum. Достаточно наличие компетенций в команде, у Scrum Master или Architecture Owner-а (о нем позже).

Введение в первую статью

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

Определения

В рамках данной статьи под архитектурой понимаем определение данное в книге Software Architecture in Practice (SAP) «The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.» Самый нижний уровень, до которого еще речь идет об архитектуре — это концепты и сущности. Классы, методы, атрибуты и тд выходят за данное понятие.

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

Типы архитектурных требований (АТ) и их формализация

Ниже рассмотрим типы требований к системе, которые по мнению SEI, оказывают влияние на архитектуру и необходимы/достаточны для принятия архитектурных решений. В SAP они упоминаются как architecture drivers. В зависимости от этих требований и их взаимовлияния подбираются те или иные архитектурные паттерны и тактики.

Высокоуровневые Функциональные Требования (ФТ)

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

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

Удобно их записать в Видении проекта еще на стадии инициации проекта (Sprint 0, Initiation Phase, Inception Phase) и поддерживать там. Одновременно в таск-трекере вести их как большие User Story, вехи, инициативы и тд в зависимости от выбранного формата ведения требований. Например, при совместном использовании Confluence и Jira от Atlassian в последнем удобно создать Epic, а в первом удобно создать видение проекта и интегрировать данные Epic-и.

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

Нефункциональные требования / Атрибуты Качества (АК)

В англоязычной литературе можно встретить под названием Non-Functional Requirements или Quality Attributes.

Эти требования описывают то, какими качествами должна система обладать и до какой степени. Например, она должна быть доступна в 99.9999% времени, цикломатическая сложность метода должна быть меньше 7. Это те самые слова, которыми оперируют, говоря о качестве продукта: security, reliability, maintainability, и тд.

Таких атрибутов качеств системы очень много (свыше 170, согласно некоторым публикациям). Определение какими из них система должна обладать осложняется тем, что они «вложены» друг в друга. Так, например, невозможно сказать, что performance или reliability не «вложены» в usability. Поэтому часто используют корпоративные или индустриальные стандарты, такие как ISO 25010, в качестве справочника/чеклиста таких характеристик. Полезно бывает сесть с заказчиком и пройтись по данному ISO обсудив с ним и выбрав релевантные атрибуты качества. Этот список так же будет отправной точкой для Плана Качества (Quality Plan), но это отдельная история и, возможно, отдельный цикл статей.

АК часто мешают друг другу. Так, чтобы обеспечить надежность системы часто приходится жертвовать производительностью. Так же производительность в конфликте с сопровождаемостью (maintainability). Поэтому важна приоритезация таких АК, чтобы понимать, что для системы важнее и принимать соответствующие решения. Например, если важно покрыть Android приложение тестами (testability), то может скорее всего будет применен паттерн MVP. Если же такой потребности нет и приложение несложное, то, возможно будет лучше оставить MVVM.

Наконец, система в любом случае обладает этими качествами, но в какой-то степени. Например, у системы не может быть нулевой производительности или «полной». Более того, небольшое повышение какой-либо характеристики может означать существенное изменение в архитектуре и существенное увеличение бюджета. Поэтому из всех возможных АК выделяют только те, которые наиболее значимы для системы и стараются определить необходимый и достаточный уровень.
Одним из наиболее конкретных и строгих форматов ведения АК является так называемый «6 part scenario»:

Их можно прикладывать как один из Acceptance Criteria к User Story или Epic. Так же они могут быть частью Definition of Done (Done Criteria). Так как обычно АК относятся к большой части системы или к ней целиком, то описывать их часто необходимо на уровне Epic.

Более простой и менее строгий формат написания — в одном предложении в Acceptance Criteria (например, скорость отклика системы должна быть 0.5 сек). Такой формат вполне допустим и достаточен, если из Done Criteria ясно следует, например, где, кем и при каких условиях будет проводиться тестирование этого приемочного критерия. Например, user story должна быть опубликована на staging environment и протестирована при 200 запросах/сек в течении 10 минут в таких-то условиях.

Ограничения (Constraints)

Видение проекта

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

Резюме

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

Источник

Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта

VI Определяем функции системы и границы проекта

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс

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

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

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

Для управления Границами проекта, как на начальных стадиях, так и в течение всего проекта, очень удобно использовать функциональное или процессное моделирование. Модели этого типа позволяют описывать события и последовательности исполнения Бизнес процессов во времени.

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

Рисунок 6.1 — модель процесса определения функций

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

Наиболее удобной методикой функционального моделирования, с точки зрения определения границ проекта, на мой взгляд является “старая добрая” методология проектирования SADT, использующая иерархическую декомпозицию сверху вниз. Применение диаграмм IDEF0 имеет следующие преимущества перед аналогами:

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

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

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

2. Пример описания функции “Управление требованиями”

Хочу напомнить основные постулаты стандарта IDEFO. Графическую конструкцию стандарта составляют: понятие «Работа» (Activity) для обозначения действия, представленная в виде блока; четыре вида интерфейса: «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), представленный в виде дуг. Левая сторона блока предназначена для входов, верхняя — для управления, правая — для выходов, нижняя — для механизмов. Для более подробного изучения этой темы обратитесь к [2].

На первом шаге моделирования необходимо определить все потоки данных, поступающих в систему из вне (входные сигналы). В нашем случае это:

Рис.6.2 – Функциональная модель системы Управления требованиями верхнего уровня

Проваливаясь во внутрь функции (блока «Работа») мы попадаем на следующий уровень абстракции функциональности системы. Вначале мы видим только потоки данных, выявленные на предыдущем этапе (уровне), см. рис. 6.3.

Рис.6.3 – Начало работы по детализации функции Управление ИТ проектами

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

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

Рис.6.4 – Определение подпроцессов для функции Управление ИТ проектами

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

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

Пример модели этих функций с уже установленными взаимосвязями отображены на Диаграмме см. Рис. 6.5.

Рис.6.5 – Функциональная модель системы Управления требованиями

Если такие диаграммы используют в документе необходимо сопровождать их подробным описанием. Дальше приведен пример описания:

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

Из диаграммы видно, что блок “А1” имеет обратную связь от блока “А2”, в виде управляющей информации, доводящей о степени реализации требований, сформированных по Пользовательским историям (дуга «Отчет о реализации требований»). Эта связь позволяет отследить ход и полноту реализации Пользовательской истории в конечном продукте по цепочке, через спецификации требований.

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

В третий блок направим из блока “А2”, в качестве управляющих инструкций, ключевые показатели спецификаций. На основании их можно определить степень достижения заданной функциональности, используя отчет о выполнении задний, выставленных по этим спецификациям исполнителям. Отчет поступает в виде входящих параметров из блока “А4”.

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

3. Пример описания функции “Сбор потребностей заказчика”

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

Заглянем в блок А1 на рисунке 6.4, представляющий домен «Сбор потребностей заказчика». Его детализация показана на рисунке 6.5. Все потоки данных, которые входили в блок А1 на рисунке 6.4, соответственно попали и в детализирующую его диаграмму см. рис. 6.6.

Рис. 6.6 – Схема домена Сбор потребностей заказчика

Функционально домен мы разделили на четыре процесса:

4. Пример описания функции “Управления спецификациями требований”

Следующее уточнение произведем с доменом «Управление спецификациями требований проекта» (А2). На рисунке 6.7 изображена диаграмма этой модели.

Функционально домен делим на четыре процесса:

5. Пример описания функции “Управление заданиями”

На рисунке 6.8 изображена диаграмма, представляющая домен Управления Заданиями проекта (А4). Функционально домен мы разделили на четыре процесса:

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

Для процесса 5.2 опишем следующую Пользовательскую историю:

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

Процесс 5.3 затрагивает несколько Пользовательских историй:

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

В случае наступления риска, выполняется пользовательская история US8.

6. Пример описания функции “Управление выполнением”

На рисунке 6.9 изображена диаграмма, представляющая домен Управления выполнения проекта. Реализация этого домена немного выходит за рамки нашего проекта, но тесно с ним связана. Поэтому рассмотрим и его.

Рис. 6.9 – Схема домен Управления выполнения проекта

Функционально домен мы разделили на четыре процесса:

7. Подведем итоги процесса определения функций системы и границ проекта

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

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

В итоге, опираясь на разработанные нами диаграммы, мы можем на первом этапе вынести за рамки проекта функции группы «А3 Управления выполнением», а также функции «А4.2 Формирование заданий на итерацию» и «А4.3 Формирование заданий при наступлении риска». Из диаграммы видно, что в результате система лишится потока данных — «задания исполнителям», обусловленных работами по нивелированию рисков.

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

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

Источник