Внешнее описание программного средства

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

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

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

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

ПС.
Формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком, с которого и начинается этап разработки требований.
Трудности, возникающие в этом процессе, связаны с несколькими факторами:
пользователи часто плохо представляют, что им на самом деле нужно от готового ПС
применение пс в привычных сферах деятельности пользователей может потребовать принципиального изменения всей технологии этой деятельности
проблемы, которые необходимо отразить в определении требований, могут не иметь определенной формулировки (сложность формализации задачи), что в итоге приводит изменению понимания разработчиками этих проблем.
В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесообразно и реализуемо "заказываемое" ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обладать.
________________________________________________________________________
? Чем на данном этапе может помочь разработка упрощенной версии требуемого ПС (прототипирование)

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

Должны описывать функциональные и нефункциональные системные требования естественным языком с использованием простых таблиц, а также наглядных и понятных диаграмм. Эти требования должны определять только внешнее поведение системы
Системные требования. Содержат детализированное описание пользовательских требований. Они включают в себя максимально полную спецификацию системы в целом. Системные требования определяют, что должна делать система, не показывая при этом механизмов реализации. В документе, содержащем требования к системе, желательно отделять пользовательские требования от более детализированных системных требований, поскольку понимание последних требует определенных профессиональных знаний и навыков.
_________________________________________________________________________________? Составьте для своего программного средства 2 перечня требований:
Пользовательские
Системные

системы
формирование и анализ требований
специфицирование требований и создание соответствующей документации
аттестация требований и процесс управления изменениями системных требований
Анализ технической осуществимости создания системы.( В соответствии с ГОСТ Р ИСО/МЭК 12207)
Производится анализ создаваемой системы и ее назначения. Для этого определяются источники информации (менеджеры отделов, разработчики программного обеспечения, технологи, конечные пользователи и т.д.), затем производится сбор и анализ информации о будущей системе, определяются решаемые задачи и выбираются технологии реализации.
1)заказчик инициирует процесс заказа, описывая концепцию или потребность в заказе, разработке или модернизации системы, программного продукта или программной услуги
2)заказчик определяет и анализирует требования к системе.

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

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

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