Обратное требование: что это такое, описание и особенности

Обратное требование: что это такое, описание и особенности

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

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

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

Производные требования

Вот простой пример:

Предположим, что требование пользователя следующее – “система должна работать на улице 12 месяцев в году на Аляске”.

Возникают несколько производных требований:

  1. Система должна работать при температуре ниже 0 C.
  2. Система должна работать в снегу.

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

  • Разделить системы (модели) на элементы (например, с помощью методов OOAD).
  • Определить, как будут взаимодействовать эти элементы для достижения желаемого поведения системы.
  • Добавить поведения низкого уровня для выполнения требований взаимодействия уровня элементов.

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

Выделенные требования

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

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

Выбор подхода зависит от контекста работы и ожиданий заказчика. Например, в Национальном агентстве аэронавтика и космоса (NASA) [в Руководстве по гарантировании программного обеспечения, NASA Goddard Space Flight Center Office of Safety, Reliability, Maintainability and Quality Assurance, 9/89] существует четыре уровня детализации требований:

  • Уровень 1. Миссия – высокий уровень, фиксируются на ранней стадии.
  • Уровень 2. Система – выделенный уровень, который также фиксируется очень рано. Эти требования происходят из уровня миссии и затем закрепляются за сегментами.
  • Уровень 3. Подсистема (сегмент) – выделенный уровень, требования на котором происходят из требований системного уровня, присвоенных сегменту.
  • Уровень 4. Элемент конфигурации (элемент конфигурации аппаратного обеспечения, элемент конфигурации программного обеспечения) – этот уровень происходит из предыдущего уровня и затем уточняется.

Уровни требований и их соответствие в RUP

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

Читайте также:
Муниципальные выборы: что это такое, описание и особенности

© Copyright IBM Corp. 1987, 2006. Все права защищены..

Все для аналитиков

Страницы

  • Главная страница
  • Управление проектами
  • Управление требованиями

среда, 17 августа 2011 г.

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

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

Кратко: требование это зафиксированное желание пользователя, которое должна выполнять система.

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

  • Бизнес-требования. Что система система должна делать с точки зрения бизнеса. Слово “бизнес” в данном контексте ближе к слову “заказчик”. Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.
  • Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). Иначе говоря, пользовательские требования – это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
  • Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования.
  • Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными. Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability.
  • Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия “сайт-CRM” также относятся к нефункциональным требованиям.
  • Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
    • легкость и простота использования (usability)
    • производительность (performance)
    • удобство эксплуатации и технического обслуживания (maintainability)
    • надежность и устойчивость к сбоям (reliability)
    • взаимодействия системы с внешним миром (interfaces)
    • расширяемость (scalability)
    • требования к пользовательским и программным интерфейсам (user and software interface).

Более подробно про атрибуты качества

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

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

Существует прекрасная методика FURPS+, позволяющая создать качественную документацию при разработке ПО сколь угодно большой сложности.

Все вышесказанное относится только к дисциплине “Управление требованиями” в рамках методологии RUP. В рамках ГОСТ и определения требований другие и сами требования разбиваются на совершенно другие группы.

18. Разработка требований к программному обеспечению. Выявление и анализ требований. Спецификации требований. Управление изменениями требований.

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

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

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

Читайте также:
Преступный результат: что это такое, описание и особенности

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

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользователь­ские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания вы­полняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы — проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

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

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

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

Различие между пользовательскими и системными требованиями показаны в примере, представленном примере 1. Здесь показано, как пользовательские требования могут быть преобразованы в системные.

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

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

1. ПО должно предоставить средство доступа к внешним файлам, созданным в других программах.

Спецификация системных требований

Пользователь должен иметь возможность определять тип внешних файлов.

Для каждого типа внешнего файла должно иметься соответствующее средство, при­менимое к этому типу файлов.

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

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

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

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

Выявление и анализ требований

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

Схема разработки требований

Разработка требований это первая из основных фаз процесса создания программных сис­тем. Этот фаза состоит из следующих основных работ (рис. 5).

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

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

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

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

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

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

Читайте также:
Профессиональный хранитель: что это такое, описание и особенности

На этапе анализа разрабатываются пользовательские и системные требования к про­граммной системе, которые оформляются в виде единого документа – спецификации тре­бований, – являющегося формальным соглашением заказчика с разработчиком системы. Практика показывает, что требования к разрабатываемой программной системе часто из­меняются. Это обусловлено тем, что разработка программной системы довольно дли­тельный процесс, во время которого:

понимание пользователями возможностей системы, решаемых ею задач, может из­мениться;

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

понимание разработчиками поставленных перед ними задач меняется.

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

К действиям по управлению требованиями относятся:

определение основной (базовой) версии спецификации требований для конкретной версии продукта;

анализ предлагаемых изменений требований, оценка воздействия и стоимости каж­дого изменения до его принятия;

включение одобренных изменений при помощи определенной процедуры;

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

отслеживание отдельных требований от проектирования до кода приложения и его тестирования;

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

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

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

процесс разработки, согласования, экспертизы и утверждения базовой версии;

процесс присвоения, контроля и изменения статуса требования;

процесс передачи новых требований и изменений существующих требований заин­тересованным лицам;

методы анализа влияния и стоимости внесения изменения.

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

Минимальной единицей управления в спецификации требований является отдельное тре­бование, поэтому вопрос идентификации требования достаточно важен. Форма представления требования может быть различной (текстовая, графическая и т.д.), поэтому для идентификации требования обычно используют связанный с ним набор атри­бутов. Атрибутами могут быть: дата создания требования, номер текущей версии требо­вания, номер версии продукта, для которой предназначено требование, автор требования, ответственный за реализацию требования, состояние требования, происхождение и обос­нование требования, подсистема, для которой предназначено требование и т.д. Главное при выборе атрибутов, чтобы они однозначно идентифицировали требование и его со­стояние.

В процессе выполнения проекта требование, обычно, изменяет свое состояние от началь­ного («предложено»), до конечного, например, «реализовано». Состояния требований по­зволяет оценить степень готовности проекта. Рекомендуются использовать состояния тре­бования, приведенные в табл. 1.

Таблица 1. Состояния требования

Определение

Требование запрошено авторизированным источником

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

Код, реализующий требование разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода.

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

Утвержденное требование удалено из базовой версии. Следует зафикси­ровать причины и лицо, принявшее это решение.

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

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

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

Диаграмма состояний для типового процесса внесения изменений в спецификацию приве­дена на рис. 6.

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

Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

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

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

Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не­функциональными.

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

Читайте также:
Муниципальная милиция: что это такое, описание и особенности

Группа функциональных требований

Бизнес-требования (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) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функциисистемы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

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

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

  1. Что такое функциональные требования?
  2. Что такое нефункциональные требования?
  3. Почему важна разница между функциональными и нефункциональными требованиями?
  4. Как собираются функциональные и нефункциональные требования?
  5. Примеры и передовой опыт
  6. Истории пользователей
  7. Сценарии использования
  8. Документ со спецификацией требований к программному обеспечению
  9. Заключение

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

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

Другими словами, функциональное требование — это то, ЧТО приложение должно или не должно делать после ввода некоторых данных.

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

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

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

Читайте также:
Обязанность доказывания: что это такое, описание и особенности

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

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

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

Почему важна разница между функциональными и нефункциональными требованиями?

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

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

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

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

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

Как собираются функциональные и нефункциональные требования?

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

Давайте посмотрим, что включает в себя каждый тип требований.

Функциональные требования можно разделить на три группы:

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

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

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

Примеры и передовой опыт

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

Истории пользователей

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

Как (пользователь) я хочу (цель), чтобы (причина).

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

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

Сценарии использования

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

Читайте также:
Поверхностные следы: что это такое, описание и особенности

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

Действия для этих ролей могут выглядеть следующим образом:

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

Документ со спецификацией требований к программному обеспечению

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

Основные разделы, которые обычно включаются в документ SRS:

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

Создание SRS, пользовательских примеров и пользовательских историй имеет важное значение для эффективной разработки приложений.

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

Заключение

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

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

Что обозначает статус посылки или письма «Неудачная попытка вручения»

Любой пользователь, знающий трек-номер регистрируемого почтового отправления (сокращенно — РПО), к которым относятся посылки, заказные и ценные письма и бандероли, заказные мелкие пакеты, может отслеживать его через специальные сервисы отслеживания. Данные сервисы показывают весь путь пересылки РПО от момента приёма его в отделении почтовой связи (ОПС) до момента вручения.

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

Что значит «Неудачная попытка вручения»?

Пользователю, отслеживающему РПО на сайте Почты России, статус «Неудачная попытка вручения» показывается без дополнительных разъяснений. На самом деле в Общероссийской автоматизированной системе учета и контроля за прохождением регистрируемых почтовых отправлений (сокращенно – ОАСУ РПО) данный статус присваивается почтовому отправлению с дополнительными атрибутами. Количество таких атрибутов – 28. Ниже перечислим наиболее используемые:

  • Временное отсутствие адресата
  • Адресат переехал
  • Неправильный/нечитаемый/неполный адрес
  • Адресат отказался от отправления
  • Адресат заберет отправление сам
  • Доставка отложена по просьбе адресата
  • Неудачная доставка
  • Истек срок хранения в почтомате
  • Отправление повреждено и/или без вложения
  • За смертью получателя
  • Национальный праздник
  • Невозможно связаться с клиентом
  • Утрата
  • Форс-мажор/непредвиденные обстоятельства
  • Иная

Дополнительный атрибут для статуса «Неудачная попытка вручения», как было отмечено выше, на портале Почты России – не отображается, но его можно увидеть на некоторых других сервисах отслеживания, например, на GdePosylka.ru и 1track.ru.

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

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

Некоторые из указанных атрибутов можно увидеть при отслеживании EMS-отправлений, которые курьер должен доставлять адресату домой. Ниже представлен скриншот из сервиса, в который добавлен трек-номер посылки EMS, которой был присвоен статус «Неудачная попытка вручения» дважды:

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

Помогите, пожалуйста, что делать. Отправила посылку ems. Сообщение неудачная доставка. Посылка вернулась. Перепаковала, отправила заново. Считаю, что виновата Почта России. Они не защитили бланк EMS. Его должны были не приклеивать к посылке, а положить в специальный пластиковый конверт или, на крайний случай, в мультифорку. Все стерлось. Как возместить ущерб мне? Хочу вернуть деньги за отправку посылки, ведь пришлось дважды оплачивать доставку.

Читайте также:
Почерковедческая экспертиза: что это такое, описание и особенности

Елена, к сожалению, в данном случае что-то доказать и вернуть деньги, думаю, не получится. Больше нервов и времени потратите.

Неудачная попытка — это выписывание извещения на получение. И не обманывайте, что » не оказалось дома» или …еще 28 факторов. Никто «заказные» письма не носит до конечного адреса. Ходим за ними сами, хотя в оплату входит доставка.

Приложение. Порядок приема и вручения внутренних регистрируемых почтовых отправлений

Приложение
к приказу ФГУП “Почта России”
от 17 мая 2012 г. N 114-п

Порядок
приема и вручения внутренних регистрируемых почтовых отправлений

ГАРАНТ:

См. Порядок приема и вручения внутренних регистрируемых почтовых отправлений, утвержденный приказом ФГУП “Почта России” от 7 марта 2019 г. N 98-п

1. Общие положения

Настоящий Порядок приема и вручения внутренних регистрируемых почтовых отправлений (далее – Порядок) подготовлен в соответствии с Федеральным законом от 17.07.1999 N 176-ФЗ “О почтовой связи”, Правилами оказания услуг почтовой связи (далее – ПОУПС), утвержденными постановлением Правительства Российской Федерации N 221 от 15.04.2005, и иными нормативными правовыми актами Российской Федерации, в области почтовой связи.

Настоящий Порядок устанавливает общие правила приема и вручения внутренних регистрируемых почтовых отправлений в объектах почтовой связи и обязателен для исполнения филиалами ФГУП “Почта России” и их структурными подразделениями.

2. Перечень основных внутренних и внешних документов, регламентирующих прием и вручение внутренних регистрируемых почтовых отправлений

2.1. Федеральный закон “О почтовой связи” от 17.07.1999 N 176-ФЗ.

2.2. Правила оказания услуг почтовой связи, утвержденные постановлением Правительства Российской Федерации от 15.04.2005 N 221.

2.3. Порядок приема, доставки и вручения внутренней посылочной почты, утвержденный приказом ФГУП “Почта России” от 24.01.2007 N 28-п.

2.4. Порядок приема, обработки, перевозки, доставки и вручения почтовых отправлений “Отправления 1-го класса”, утвержденный приказом ФГУП “Почта России” от 10.05.2011 N 180-п.

2.5. Порядок приема, обработки, перевозки и вручения внутренних отправлений EMS, утвержденный приказом ФГУП “Почта России” от 17.08.2009 N 305-п.

2.6. Инструкция по оформлению, приему, обработке, перевозке и вручению Ответного внутреннего почтового отправления, утвержденная генеральным директором ФГУП “Почта России” от 22.10.2009 N 4.2-02/13-НД.

2.7. Порядок оформления и вручения дефектных почтовых отправлений, утвержденный первым заместителем генерального директора ФГУП “Почта России” от 01.02.2011 N 3.2.2-05/2-нд.

2.8. Инструкция по применению пломб почтовых одноразовых для внутренних и международных регистрируемых почтовых отправлений, утвержденная приказом ФГУП “Почта России” от 26.03.2008 N 75-п.

2.9. Порядок применения номерных сигнальных пластиковых устройств “Альфа-М” и “Акула-М”, пломб свинцовых, утвержденный приказом ФГУП “Почта России” от 02.02.2011 N 34-п.

2.10. Порядок оформления сопроводительных документов при приеме внутренних партионных почтовых отправлений, утвержденный генеральным директором ФГУП “Почта России” от 23.03.2011 N 3.2.2-05/08-нд.

2.11. Учетная политика предприятия для целей бухгалтерского учета, утверждена приказом ФГУП “Почта России” от 30.12.2011 N 473-п.

2.12. Порядок приема, обработки, перевозки и вручения внутреннего почтового отправления “Мультиконверт”, утвержденный приказом ФГУП “Почта России” от 01.07.2011 N 236-п.

2.13. Порядок приема, обработки, перевозки и вручения внутренних почтовых отправлений “Магистральное крупногабаритное почтовое отправление”, утвержденный приказом ФГУП “Почта России” от 30.05.2011 N 199-п.

2.14. Инструкция о порядке взаимодействия Аппарата управления и филиалов ФГУП “Почта России” по оказанию услуг по приему, обработке, перевозке и доставке международной и внутренней экспресс-почты EMS, утвержденная приказом ФГУП “Почта России” от 22.11.2007 N 595-п.

2.15. Требования к почтовым отправлениям разряда “Служебное”, утвержденные распоряжением ФГУП “Почта России” от 17.07.2006 N 380.

2.16. Технические требования к ящикам из гофрокартона для упаковки, транспортировки и хранения почтовых отправлений, утвержденные руководителем Дирекции технологий и информатизации ФГУП “Почта России” от 27.10.2009.

2.17. Технические требования к пакетам почтовым полиэтиленовым с клапаном, утвержденные руководителем Дирекции технологий и информатизации ФГУП “Почта России” от 14.01.2010.

2.18. Приказ ФГУП “Почта России” “Об утверждении бланков почтовых переводов денежных средств” от 13.03.2007 N 81-п.

2.19. Распоряжение ФГУП “Почта России” от 19.01.2012 N 13-ра.

2.20. Правила перевозки по воздушным линиям Союза ССР, утвержденные приказом Министерством гражданской авиации и Министерством связи СССР от 27.12.1982 N 206/457.

2.21. Распоряжение ФГУП “Почта России” от 29.07.2005 N 266/1.

2.22. Приказ Министерства РФ по связи и информатизации “О развитии системы штрихкодовой идентификации в почтовой связи” от 11.02.2000 N 15.

2.23. Порядок приема корреспонденции с использованием франкировальных машин, утвержден ФГУП “Почта России” от 15.05.2006.

2.24. Технология регистрации операции “Обработка” с атрибутом “Прибыло в место вручения” и операции “Неудачная попытка вручения” для регистрируемых почтовых отправлений в АИС, утвержденная руководителем Дирекции технологий и информатизации от 29.12.2009.

2.25. Перечень производственных документов, образующихся в процессе деятельности ФГУП “Почта России” при оказании услуг почтовой связи, утвержденный приказом ФГУП “Почта России” от 09.04.2012 N 86-п.

Читайте также:
Преследование уголовное: что это такое, описание и особенности

2.26. Постановление Правительства Российской Федерации от 06.05.2008 N 359 “О порядке осуществления наличных денежных расчетов и (или) расчетов с использованием платежных карт без применения контрольно-кассовой техники”.

2.27. Общероссийский классификатор услуг населению, утвержденный постановлением Госстандарта РФ от 28.06.1993 N 163.

3. Термины, определения и сокращения

В настоящем Порядке используются следующие термины, определения и сокращения:

АИС – автоматизированная информационная система.

АСЦ – автоматизированный сортировочный центр.

Вид почтового отправления – совокупность признаков, определяющих характер вложения, размеры, массу и способ упаковки почтового отправления. К видам почтовых отправлений относятся: письма; почтовые карточки; бандероли; секограммы; посылки; отправления EMS; письма 1-го класса; бандероли 1-го класса; мультиконверты; магистральные крупногабаритные почтовые отправления.

Внутреннее отправление EMS – регистрируемое почтовое отправление экспресс-почты пересылаемое в пределах Российской Федерации, вложение, размеры, вес и упаковка которого определяются Порядком приема, обработки, перевозки и вручения внутренних отправлений EMS.

Внутреннее почтовое отправление – почтовое отправление, принимаемое для пересылки и доставки адресату на территории Российской Федерации.

Возврат почтового отправления – направление почтового отправления по адресу отправителя, по причине, повлекшей невозможность вручения его адресату (представителю адресата).

Временное хранение почтового отправления – хранение в объектах почтовой связи нерозданных или невостребованных почтовых отправлений, в течение срока, определенного Правилами оказания услуг почтовой связи.

Вручение почтового отправления, уведомления о вручении – производственная операция, заключающаяся в выдаче почтового отправления, уведомления о вручении лично адресату или его представителю (отправителю или его представителю в случае возврата почтового отправления).

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

Досыл почтового отправления – производственная операция, заключающаяся в направлении почтового отправления по другому адресу.

Заказное почтовое отправление – регистрируемое почтовое отправление (почтовая карточка, письмо, секограмма, бандероль, письмо 1-го класса, бандероль 1-го класса, отправление “Мультиконверт”), принимаемое без оценки стоимости вложения, с выдачей отправителю квитанции и вручаемое адресату под расписку.

Засылка почтового отправления – ошибочное направление почтового отправления.

ИС – информационная система.

Календарная информация – информация, состоящая из: даты (формирования документа, приема почтовых отправлений), наименования объекта почтовой связи включая его почтовый индекс, наносимые при помощи печатающих устройств.

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

Магистральное крупногабаритное почтовое отправление (МКПО) – регистрируемое почтовое отправление, вложение, размеры, вес и упаковка которого определяются Порядком приема, обработки, перевозки и вручения внутренних почтовых отправлений “Магистральное крупногабаритное почтовое отправление”.

Мелкая посылка – посылка весом до 3 кг, большая сторона которой не превышает 35 см, а сумма трех измерений не превышает 70 см.

МСЦ – магистральный сортировочный центр.

Мультиконверт – это внутреннее почтовое отправление с товарным вложением, размеры, вес и упаковка которого определяются Порядком приема, обработки, перевозки и вручения внутреннего почтового отправления “Мультиконверт”.

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

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

ОАСУ РПО – Общероссийская автоматизированная система учета и контроля за прохождением регистрируемых почтовых отправлений.

Обыкновенное почтовое отправление – регистрируемое почтовое отправление (посылка, отправление EMS, МКПО), принимаемое без оценки стоимости вложения, с выдачей отправителю квитанции и вручаемое адресату под расписку.

ОПП – отделение перевозки почты при железнодорожной станции.

ОСП – обособленное структурное подразделение.

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

Отделение почтовой связи (ОПС) – объект почтовой связи, предоставляющий пользователям услуги почтовой связи.

Отправление 1-го класса – внутреннее почтовое отправление (письмо 1-го класса и бандероль 1-го класса), вложение, размеры, вес и упаковка которого определяются Порядком приема, обработки, перевозки, доставки и вручения почтовых отправлений “Отправлений 1-го класса”.

Пакет почтовый полиэтиленовый – упаковка для почтового отправления массой не более 3 кг, отвечающая техническим требованиям, утвержденным ФГУП “Почта России”.

Партионные почтовые отправления – почтовые отправления, сдаваемые по спискам ф. 103 отправителем согласно условиям договора в количестве 10 и более штук в один или несколько адресов.

Читайте также:
Простая гипотеза: что это такое, описание и особенности

ПЖДП – прижелезнодорожный почтамт.

ПКТ – почтово-кассовый терминал.

Почтовое отправление с уведомлением о вручении – регистрируемое почтовое отправление, при подаче которого отправитель поручает оператору почтовой связи сообщить ему или указанному им лицу, когда и кому вручено почтовое отправление.

Почтовое отправление с объявленной ценностью – регистрируемое почтовое отправление (письмо, бандероль, посылка, отправление 1-го класса, внутреннее отправление EMS), принимаемое с оценкой стоимости вложения, определяемой отправителем, с выдачей отправителю квитанции и вручаемое адресату под расписку.

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

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

“Правительственное” – разряд почтовых отправлений, отправляемых лицами, перечень которых определяется Правительством Российской Федерации.

“Президентское” – разряд почтовых отправлений, отправляемых лицами, перечень которых определяется Администрацией Президента Российской Федерации.

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

Разряд почтового отправления – совокупность признаков, определяющих принадлежность почтового отправления к определенной группе пользователей (президентское, правительственное, воинское, служебное, судебное, ОВПО).

Регистрируемая письменная корреспонденция – письма, почтовые карточки, секограммы, бандероли, принимаемые с присвоением им ШПИ, с выдачей отправителю квитанции и вручаемые адресату под расписку.

Регистрируемое почтовое отправление (РПО) – почтовое отправление, принимаемое с присвоением отправлению ШПИ/ШИ, выдачей отправителю квитанции и вручаемое адресату под расписку.

Секограмма – почтовое отправление, подаваемое в открытом виде, с вложением, предназначенным исключительно для слепых.

Служебное почтовое отправление – собственное почтовое отправление ФГУП “Почта России” разряда “Служебное”, пересылаемое по своим сетям почтовой связи без оплаты.

Судебное почтовое отправление – заказные почтовые отправления (письмо, бандероль) разряда “Судебное”, отправляемые федеральными судами Российской Федерации и мировыми судьями и пересылаемые с уведомлением о вручении.

Уведомление о вручении – бланк установленной формы, заполняемый отправителем при сдаче им регистрируемого почтового отправления и возвращаемый объектом почтовой связи отправителю или указанному им лицу с информацией о том, когда и кому выдано (вручено) регистрируемое почтовое отправление.

Хранение почтового отправления – услуга оператора почтовой связи по хранению почтового отправления в период, предшествующий вручению и определенный Правилами оказания услуг почтовой связи.

ШИ – штриховой идентификатор отправления EMS, соответствующий техническому стандарту Всемирного почтового союза S10.

ШПИ – штриховой почтовый идентификатор внутреннего регистрируемого почтового отправления, соответствующий РТМ 0001.01-99.

SMS-уведомление – уведомление о поступлении в ОПС или вручении внутреннего РПО, посредством передачи SMS-сообщения на номер сотового телефона, указанный отправителем.

4. Общий порядок приема регистрируемых почтовых отправлений

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

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

Виды писем: простое, заказное или ценное в чём разница

Личная и деловая переписка, пересылка документов и бумаг, открыток и других отправлений все также востребована в современном мире. Несмотря на развитие интернет-коммуникаций и обмена сообщениями посредством электронной почты и мессенджеров, личные бумаги – это приятное воспоминание. Для юридических лиц наличие бумажных носителей – необходимость, закрепленная законодательно. Законодательно закреплено хранение различных документов, перечень составляет более 1000 позиции, а срок хранения варьируется от 4 до 75 лет.

Существует несколько видов отправлений, в которых легко запутаться. Простое, заказное или ценное письмо, в чем разница? Расскажем на сайте blogfreo.ru о всех нюансах.

Виды почтовых отправлений

Письмо – самый простой формат пересылки документов. Какие бывают письма?

Простое

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

Заказное 1 класса

Данный вид корреспонденции имеет два плюса: пакет имеет индивидуальный трек-номер и пересылается авиапочтой. Пакет отправляется в пределах страны.

Ценное

Заказное или ценное письмо — в чем разница? Оформление отправления выполняет сотрудник отделения. Письму присваивают трек-номер и объявленную ценность: вид страхования отправления, за которое придется доплатить. Если корреспонденция затеряется в пути или будет повреждена, почта полностью или частично возместит стоимость, указанную при отправлении. Порядок вручения ценного письма аналогичен заказному.

Ценное 1 класса

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

Экспресс-пакет EMS

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

Читайте также:
Отчетный год: что это такое, описание и особенности

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

Можно воспользоваться дополнительными услугами и отправить заказное письмо с уведомлением. Или ценное письмо с описью вложения и уведомлением о вручении.Что это за опции?

Опись: что это такое и как ее заполнить

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

Бланк необходимо заполнить в 2 экземплярах по форме 107 (берется в почтовом отделении) и подать весь пакет документов сотруднику для сверки и оформления. Один бланк вкладывается в пакет, второй возвращается отправителю с отметкой и штампом.

Опись вложения в ценное письмо Форма 107 (Россия). Опись вложения в ценное письмо Форма 107 (Украина).

Обязательные строки для заполнения в ф. 107:

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

В незаполненных ячейках проставляется прочерк. Каждый следующий лист описи нумеруется от руки «Лист 1 из Х».

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

Уведомление о вручении: что это такое и как заполнить

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

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

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

На обратной стороне заполняется:

  • Вид и категория (простое, заказное, обыкновенное, с объявленной ценностью);
  • данные получателя. Для частного лица – ФИО. Для юридического лица – полное наименование компании;
  • Адрес получателя: индекс, область, город, улицу, дом, квартиру.

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

ВАЖНО! Уведомление о вручении является гарантом исполнения почтой своих обязательств. При невозврате данного документа отправителю, заказчик услуги вправе предъявить претензию и потребовать компенсации в установленном действующими нормативными документами порядке и сроки.

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

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

Стоимость почтовых отправлений

Сколько стоит заказное письмо с вложения описью?Сколько стоит отправить простой пакет? Как рассчитываются суммы за отправку?

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

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

  • Авиапересылка
  • Уведомление
  • СМС-информирование
  • Опись
  • Наложенный платеж

Определяются в соответствии с действующими тарифами для конкретного региона страны.

Полезные сервисы

Рассчитать стоимость ценного письма почта России можно самостоятельно на официальном сайте по ссылке: https://www.pochta.ru/letters .

Если вы хотите отправить заказное письмо Укрпочта, цена автоматически может быть рассчитана на официальном сайте. Ссылка на сервис: https://u.check-track.com/ru/calc/ .

Узнать, где находится пакет по трек-номеру:

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: