Презентация, доклад по дисциплине Разработка и анализ Требований к программному обеспечению

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

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

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

(в основе - всегда промышленная СУБД),
близкий к реальному времени режим работы,
сохранение общей модели управления для предприятий разных отраслей,
поддержка территориально-распределенных структур,
работа на широком круге аппаратно-программных платформ и СУБД.

- планирование поставок материалов, исходя из данных о комплектации производимой продукции и плана продаж.
CRP (Capacity Requirements Planning) - планирование производственных мощностей, исходя из данных о технологии производимой продукции и прогноза спроса.
MRPII (Manufacture Resource Planning) - планирование материальных, мощностных и финансовых ресурсов, необходимых для производства. Стандартизовано ISO.
ERP (Enterprise Resource Planning) - финансово-ориентированное планирование ресурсов предприятия, необходимых для получения, изготовления, отгрузки и учета заказов потребителей на основе интеграции всех отделов и подразделений компании.
SCM (Supply Chain Management) - управление цепочками поставок. Реализация бизнес-процессов на базе внешних предприятий и торговых площадок Основано на референтной модели SCOR, стандартизованной Supply Chain Council.
CRM (Customer Relationship Management) - управление взаимоотношениями с заказчиками. Комплекс методов и средств, нацеленный на завоевание, удовлетворение требований и сохранение платежеспособных клиентов.
ERPII (Enterprise Resource & Relationship Processing) - управление ресурсами и взаимоотношениями предприятия. Объединяет в себе 3 вышеперечисленные технологии.
Workflow - технология, управляющая потоком работ при помощи программного обеспечения, способного интерпретировать описание процесса, взаимодействовать с его участниками и при необходимости вызывать соответствующие программные приложения.
Workflow - поток работ (упорядоченное во времени множество заданий, которые получают сотрудники и которые обрабатываются ими вручную или с помощью средств автоматизации, но с той последовательностью и в рамках тех правил, которые определены для данного бизнес-процесса).
OLAP (Online Analytical Processing) - оперативный анализ данных. Технология поддержки принятия управленческих решений на основе концепции многомерных кубов информации.
Project Management - управление проектами. Поддерживается рядом международных стандартов.
CALS (Continuous Acquisition and Lifecycle Support) - непрерывная информационная поддержка поставок и жизненного цикла. Описывает совокупность принципов и технологий информационной поддержки жизненного цикла продукции на всех его стадиях. Объединяет в себе практически все вышеперечисленные подходы и технологии.

предприятия - достаточно нетривиальная задача.

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

редакция нотации RUP - Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software)

Требование – это (В IEEE Standard Glossary of Software Engineering Terminology (1990)):
условия или возможности, необходимые пользователю для решения проблем или достижения целей;
условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
документированное представление условий или возможностей для пунктов 1 и 2.

IEEE (Institute of Electrical and Electronics Engineers) - институт инженеров по электротехнике и электронике

Требования - это исходные данные, на основании которых проектируются и создаются автоматизированные информационные системы.

собираются там, где они появляются».

пригодность).
Символ "+" расширяет FURPS-модель, добавляя к ней:
ограничения проекта,
требования выполнения,
требования к интерфейсу,
физические требования,

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

"Concept of Operations Document".
• IEEE 1233 "Guide for Developing System Requirements Specifications".
• IEEE Standard 830-1998, "IEEE Recommended Practice for Software Requirements Specifications"
• IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
• IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.

2. Отечественные ГОСТ:
• ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
• ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
• ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

по важности и стабильности,
наличие количественной метрики.

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

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

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

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

Верифицируемость (пригодность к проверке)
Свойство верифицируемости существенно связано со свойствами ясности и полноты.

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

необходимости и полезности) и потребными ресурсами.

Треугольник компромиссов

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

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

Наличие количественной метрики

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

рабочих потоков (Workflow) программной инженерии, наряду, с такими, как проектирование интерфейса пользователя, либо программирование.
«Requirement Process»
«анализ требований» - ГОСТ Р ИСО/МЭК 12207-99
«поток работ», «требования», «работа с требованиями», «определение требований»

Body Of Knowledge – свод знаний о программной инженерии. Представляет собой международный стандарт, подготовленный координационным комитетом программной инженерии (Software Engineering Coordinating Committee) под эгидой АСМ и IEEE. Цель документа – определить необходимый набор знаний и рекомендуемые практики, которыми должны владеть специалисты в области программной инженерии. В настоящее время существует версия 3.0, подготовленная в 2014 году, в которой содержатся 15 областей знаний. Каждая область знаний представляет собой иерархически упорядоченный текст стандартизованного типа, включая понятийный аппарат, методы и средства, инструменты поддержки инженерной деятельности и др.


SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:
Requirements Elicitation (Извлечение требований),
Requirements Analysis (Анализ требований в узком смысле),
Requirements Specification (Специфицирование требований),
Requirements Validation (Проверка требований).

the Problem (Анализ проблемы),
Understand Stakeholder Needs (Понимание потребностей совладельцев),
Define the System (Определение системы),
Manage the Scope of the System (Управление контекстом системы),
Refine the System Definition (Уточнение определения системы).
RUP (Rational Unified Process – "рациональный унифицированный процесс") – методология разработки программного обеспечения от IBM. RUP - формализованный, итеративный, инкрементный, настраиваемый процесс разработки, направляемый требованиями, базирующийся на метриках и визуальном моделировании на основе UML. Процесс поддерживает команды любого размера.

и специфицирование требований" ;
• Расширенный анализ требований ( "Расширенный анализ требований. Моделирование" и "Расширенный анализ требований. Иллюстрированные сценарии и прототипы" );
• "Документирование требований" ;
• "Проверка требований" ;
• "Введение в управление требованиями" ;
• "Совершенствование процессов работы с требованиями" .

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

Ответ на первый вопрос. Общая классификация задач, работ и операций программной инженерии, представленная в ГОСТ Р ИСО/МЭК 12207-99. SWEBOK.
Ответ на второй вопрос. MSF, RUP, Oracle PJM, XP, FDD, SCRUM, PSP, Crystal, DSDM.
Методологии подразделяются на 3 "волны":
- каскадные
- прогнозирующие (RUP)
- "гибкие" (agile).

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

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

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

- постановка задачи, определение рамок проекта;
Представитель заказчика - постановка задачи, определение рамок проекта, контроль работы исполнителя, приемка результатов работы;
Архитектор системы - разработка архитектуры, проектирование подсистем;
Программист - разработка программного кода;
Тестировщик - составление тест-плана, тестовых сценариев;
Менеджер проекта - планирование и контроль исполнения работ.

Совладельцы (stakeholders, RUP и MSF) - все участники проекта создания программной системы, прямо или косвенно заинтересованных в его успехе.

каркас решений Microsoft) – методология разработки программного обеспечения от Microsoft. MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта.
Шесть ролевых кластеров модели проектной группы - это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи.
MSF организован на базе комбинации каскадной и спиральной моделей. Отдельная стадия работы содержит в себе 5 фаз:
• Envisioning (выработка концепции),
• Planning (планирование),
• Developing (разработка),
• Stabilizing (стабилизация),
• Deploying (внедрение).

для которого разрабатывается (выбирается) АИС в виде бизнес-моделей
или
стоит пропустить этот этап и сразу формировать артефакты АТ?

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

Заказчиком и Разработчиком
С позиций моделирования, анализ требований (АТ) и анализ проблемной области (АПО) - принципиально разные процессы
Анализ предметной области преследует классические цели создания модели: имеется объект и задача аналитика - отразить этот объект в создаваемой модели с требуемой степенью точности.
Анализ требований направлен на моделирование воображаемого, еще не существующего объекта (АИС).
Сначала создается модель, а затем, на ее основании, синтезируется объект.

"формула" создания АИС:
ОС->М(ОС)->М(АИС)->М'(АИС)->М''(АИС)->М'''(АИС)->АИС

Документ АТ является ничем иным, как моделью модели ОС

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

На практике это возможно в следующих случаях:
Разработчик является частью (структурным подразделением, дочерним предприятием и т.д.) ОС, в коллектив Разработчика входят эксперты, хорошо знающие предметную область;
Заказчик наравне с Разработчиком участвует в создании документа АТ и разделяет с ним ответственность за принятие решений. Это - путь "agile методологий".

М(ОС). Это - модель бизнес-анализа (проблемной области).

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

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

Затем, путем углубленного анализа и проектирования, формируются, соответственно, аналитическая модель М'(АИС), проектная модель М''(АИС) и модель реализации М'''(АИС).

Модель уровня реализации позволяет синтезировать собственно АИС, как совокупность программных, информационных, организационных и др. артефактов.

АИС в свою очередь представляет собой модель организационной системы М'(ОС), замыкая цикл моделирования.

моделей:
модели, преследующие цель анализа и улучшения организационной системы (например, SWOT , VCM, BPR, CPI/TQM/ISO9000, BSC),
модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).

CPI (Continuous Process Improvement) - непрерывный процесс усовершенствования. Относится ко всем аспектам деятельности компании; предусматривает постоянный поиск способов улучшения работы организации и использование этих способов для совершенствования продукции компании, создания более благоприятного рабочего климата на предприятии и т. п.
Наиболее развитая модель описания проблемной области предлагается в методологии ARIS.
ARIS (Architecture of Integrated Information Systems) — архитектура интегрированных информационных систем. Методология и CASE-средство для моделирования бизнес-процессов организаций c целью их автоматизации от компании Softwareag. Основные черты методологии - поддержка 5 различных, но взаимосвязанных между собой точек зрения на предприятие; наличие сверхмощного, не имеющего аналогов графического языка, насчитывающего десятки различных диаграмм и сотни специальных символов для всевозможных аспектов деятельности предприятий и его автоматизации.
CASE (Computer Aided Software Engineering) – набор инструментов и методов, позволяющих автоматизировать отдельные этапы жизненного цикла программной инженерии. Согласно IEEE STD.620.12-1990, CASE – это "использование компьютеров, способствующее процессу программной инженерии; может включать приложения программных средств для проектирования, трассировки требований, генерации кода, тестирования, генерации документации и других действий программной инженерии".

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

RUP и их связь с потоком работ АТ

документы с описанием бизнес-процессов предприятия, выполненные консалтинговым агентством, либо просто документы (должностные инструкции, распоряжения, своды бизнес-правил), принятые на предприятии.

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

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

При выборе собеседника для целей сбора требований определяющими являются две вещи:
Он действительно является экспертом по данному вопросу;
Его мнение действительно является ценным при формировании целевого набора требований

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

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

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

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

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

результаты измерений

и сформулировать вопросы к экспертам


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

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

(Rapid Application Development) – быстрая разработка приложений

RAD базируется на следующих базовых принципах:
Эволюционное прототипирование;
CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода;
Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами;
Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online;
Жесткие временные рамки, как противоядие от "расползания границ" проекта: если команда не укладывается в срок - функционал сужается.

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

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

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

MSF

Концепция в ГОСТ РФ
Основные работы этапа:
• Изучение объекта;
• Проведение научно-исследовательских работ (НИР);
• Разработка вариантов концепции АС;
• Оформление отчета о выполненной работе.

совладельцев
• Определение границ системы
• Идентификация ограничений
• Формулировка постановки задач
• Определение возможностей системы
• Оценка результатов

разделы:
1. Введение
2. Позиционирование
3. Описания совладельцев и пользователей
4. Краткий обзор изделия
5. Возможности продукта
6. Ограничения
7. Показатели качества
8. Старшинство и приоритеты
9. Другие требования к изделию
10. Требования к документации
11. Приложение.

ядра проектной группы и подготовка документа общего описания и рамок проекта (vision/scope document).
Видение (vision) - это ничем не ограничиваемое представление о том, каким должно быть решение .
Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.
Управление рисками представляет собой итеративный процесс, осуществляемый на протяжении всего жизненного цикла проекта.
Во время фазы выработки концепции производится выявление и анализ бизнес-требований. Более детально эти требования рассматриваются во время фазы планирования.
Ведущим ролевым кластером на фазе выработки концепции является "Управление продуктом".

выгод
Концепция решения
• Цели, задачи, предположения и ограничения
• Анализ применимости
• Требования
Рамки
• Список характеристик/функций
• Вне рамок
• Стратегия подготовки релизов
• Критерии применимости
• Эксплуатационные критерии
Стратегии проектирования решения
• Стратегия проектирования архитектуры
• Стратегия технического проектирования

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

основных используемых терминов.

Глоссарий оформляется, как текст, состоящий из абзацев, каждый из которых определяет значение одного из терминов проблемной области.
Термин обычно выделяют полужирным кеглем. Иногда проблемную область целесообразно сегментировать на ряд "подобластей" (subject areas).

колонки,
Таблица в три колонки,
Стиль RUP.

Кроме того, иногда целесообразно использовать:
Псевдокод,
Диаграмму активности UML,
Другие графические модели.

например:
"Менеджер запрашивает у Системы список заказов за период. Система отображает на экране найденные заказы данного Менеджера с указанием их основных атрибутов".
Свободный стиль допускает использование конструкций "Если то".
"Если Менеджер имеет полномочия Начальника Отдела, то Система предоставляет возможность просмотра заказов всех менеджеров этого отдела".

неопределенной форме совершенного вида, отражающая цель>
Контекст использования <уточнение цели, при необходимости - условия ее нормального завершения>.
Область действия <ссылка на рамки проекта>. Например - подсистема бухгалтерского учета.
Уровень <один из трех: обобщенный, цели пользователя, подфункции>.
Основное действующее лицо <имя роли основного актора или его описание>.
Участники и интересы <список других акторов-участников прецедента с указанием их интересов>.
Предусловие <то, что ожидается, уже имеет место>.
Минимальные гарантии <что гарантируется акторам-участникам>.
Гарантии успеха <что получат акторы-участники в случае успешного достижения цели>.

сценарий <здесь перечисляются шаги основного сценария, начиная от триггера и вплоть до достижения гарантии успеха>.
Формат описания: <Номер шага> <Описание действия>
Расширения <здесь последовательно описываются все альтернативные сценарии>. Каждая из альтернатив привязана к шагу основного сценария.
Формат описания: <Номер шага.Номер расширения> <Условие>:<Действие или ссылка на подчиненный вариант использования>.
В случае, если альтернативный сценарий не удается описать одной строкой - применяется следующий формат.
Начиная со строки, следующей после описания расширения, идет описание его действий в формате основного сценария:
<Номер шага.Номер расширения.Номер шага расширения> <Действие>
Список изменений в технологии и данных <что гарантируется акторам-участникам>. Например - в случае неудавшейся транзакции все данные, имевшиеся в системе до ее начала, сохраняются неизменными.
Вспомогательная информация <дополнительная информация, полезная при описании варианта использования>.

потоки событий
Специальные требования
Предусловия
Постусловия
Точки расширения

свободному формату описания варианта использования.

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

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

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

синтаксис описания перехода (надписи на стрелке) следующий:
Событие [сторожевое условие] / выражение действия

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

Принято выделять 3 уровня абстракции классов:
концептуальный уровень,
уровень спецификации,
уровень реализации.

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

Гейна-Сарсона (Gane-Sarson)

нотация Гейна-Сарсона

Событийная цепочка процессов (ARIS)

проектирования

из различных концептуальных решений;
проанализировать осуществимость.

одного и того же требования могут быть закуплены у различных поставщиков. Снабженец должен сопоставить поставщика каждой позиции каждого из требований.
А) Сценарий последовательной обработки требований.
А1. Система отображает реестр требований, имеющихся во входной очереди.
А2. Пользователь выбирает очередное требование.
А3. Система отображает перечень материалов требования и справочник поставщиков.
А4. Пользователь сопоставляет каждой из позиций требования поставщика из справочника поставщиков.
А5. Система придает требованию статус "обработано", высылает по электронной почте автору требования уведомление.
А6. Продолжать с шага А1, пока очередь не опустеет.
Б) Сценарий группировки по материалам.
Б1. Система отображает позиции всех требований и справочник поставщиков.
Б2. Пользователь группирует позиции по типу (так, чтобы однотипные позиции, поставляемые одним и тем же поставщиком, находились рядом).
Б3. Пользователь выбирает группу позиций и сопоставляет ей поставщика.
Б4. Система проверяет - не появились ли полностью обработанные требования. При положительном исходе проверки присваивает этим требованиям статус "обработано" и высылает по электронной почте автору требования уведомление.
Б5. Продолжать с шага Б1, пока очередь не опустеет.

приложения, не затрагивая логику обработки и базу данных.
Вертикальный или структурный прототип (vertical prototype, structural prototype) не ограничивается интерфейсом пользователя. Он реализует вертикальный "срез" системы, затрагивая все уровни ее реализации.

быстро промакетировать те или иные аспекты и компоненты системы.
RAD (rapid application development) - быстрая разработка приложений

Схема перехода от одноразового прототипа к детально проработанному UI

Эволюционный прототип (evolutionary prototype) создается, как первое приближение системы, призванное стать впоследствии самой системой.

Разработчик ограничен в ресурсах.
Достоинства:
Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок и т.п., отвлекаясь от анализа функциональности.
Заказчик никогда не скажет, глядя на бумажный интерфейс: "Да вы, я вижу, уже создали систему на 85%! Давайте закончим ее в течении недели".
Раскадровка – Промежуточное решение между электронным и бумажным вариантами прототипов UI класса являются презентации, изготовленные при помощи средств электронного офиса (например, комбинации Microsoft Visio и Microsoft PowerPoint).
Данный вид решения определяется как пассивная раскадровка.
Активная раскадровка является дальнейшим развитием понятия пассивной раскадровки, с применением средств анимации и т.п.
Интерактивная раскадровка представляет собой электронный одноразовый горизонтальный прототип.

или иные его особенности и, в конечном итоге, повысить степень комфортности пользователя.

Иллюстрированные сценарии прецедентов

19.201-78 "Техническое задание, требования к содержанию и оформлению" и ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы" (ТЗ на АС)

Структура ТЗ в соответствии с ГОСТ 34.602-89:
Общие сведения
Назначение и цели создания (развития) системы
Характеристика объектов автоматизации
Требования к системе
Состав и содержание работ по созданию системы
Порядок контроля и приемки системы
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
требования к документированию и источники разработки
расчет ожидаемой эффективности системы и оценку научно-технического уровня системы

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

акронимы и сокращения.
Ссылки.
Краткое содержание.
Обзор системы
Обзор прецедентов.
Предположения и зависимости.
Описание требований
Описание вариантов использования
Специальные требования.
Вспомогательная информация.

рекомендации по последовательности работы с документом для каждого класса читателей.
Границы проекта.
Ссылки.
Общее описание.
Общий взгляд на продукт.
Особенности продукта.
Классы и характеристики пользователей.
Операционная среда.
Ограничения проектирования и реализации.
Классификация ограничений:
определенные технологии, средства, языки программирования и базы данных, которые следует использовать или избегать;
ограничения, налагаемые операционной средой продукта;
обязательные соглашения или стандарты разработки;
обратная совместимость с продуктами, выпущенными ранее;
ограничения, налагаемые бизнес-правилами;
ограничения, связанные с оборудованием, например требования к быстродействию, ограничения памяти или процессора;
соглашения, связанные с пользовательским интерфейсом существующего продукта, которые необходимо соблюдать при его улучшении;
и протоколы обмена данными.
Документация для пользователей.
Предположения и зависимости
Функции системы
Для каждой i-й функции составляется следующее описание.
i Наименование i-й функции системы.
i.1 Описание и приоритеты.
i.2 Последовательности "воздействие - реакция".
i.З Функциональные требования.

пользователя
Основные характеристики UI:
ссылки на стандарты графического интерфейса пользователей или стилевые рекомендации для семейства продукта, которые необходимо соблюдать;
стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем, последовательностей полей вкладок, часто используемых элементов управления и т.п.;
конфигурация экрана или ограничения разрешения;
стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки;
быстрые клавиши;
стандарты отображения сообщений;
стандарты конфигурации для упрощения локализации ПО;
специальные возможности для пользователей с проблемами со зрением.
Интерфейсы оборудования
Интерфейсы ПО
Интерфейсы передачи информации
Другие нефункциональные требования
Требования к производительности
Приложение А. Словарь терминов (глоссарий).
Приложение Б. Модели анализа.
Приложение В. Список вопросов.

"проверка правильности", "аттестация", "утверждение".
Cтандарт IЕЕЕ 1012-1986:
Верификация - процесс оценивания системы или компонента с целью определить, удовлетворяют ли результаты некой фазы условиям, наложенным в начале данной фазы.
Валидация - процесс оценивания системы или компонента во время или по окончании процесса разработки с целью определить, удовлетворяет ли она указанным требованиям.

вводят для этих двух процессов обобщающее понятие V&V (Validation and Verification).
Согласно IEEE 1059-93, верификация и валидация программного обеспечения - упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла.
Следует убедиться в том:
• в спецификации требований к ПО должным образом описаны предполагаемые возможности и характеристики системы, которые удовлетворят потребности различных заинтересованных в проекте лиц;
• требования к ПО точно отражают системные требования, бизнес-правила и др.;
• требования обеспечивают качественную основу для проектирования и сборки ПО.

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

управлению требованиями, т.к. они статичны, сформулированы в начале проекта и неизменны во времени.

Низкий (порядка 20%) процент успешных проектов.
Причины:
1) лавинообразное разрастание цены исправления ошибок, возникших на ранних этапах создания системы от этапа к этапу;
2) статичность схемы.

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

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

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

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

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

управления информацией;
70% проектов по разработке военных систем ПО;
45% проектов по созданию ПО, выполняемых по контракту.

При принятии решения по запросу необходимо исходить:
а) из степени важности запроса для Заказчика и
б) из его стоимости для Разработчика. Стоимость определяется на основании анализа влияния изменения.

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

требований или таблицей трассируемости

институт, созданный на базе университета Карнеги-Меллона в Питсбурге в рамках деятельности комиссии Министерства обороны США по исследованию проблем, возникающих при разработке программных продуктов в организациях министерства.
EPC SEI Capability Maturity Model - Integrated [for Software Engineering and Systems Engineering] – модель зрелости для программной и системной инженерии, созданная в развитие модели CMM
Унаследовав от CMM описание пяти уровней зрелости организации, дополнительно определяет 22 процессные области (группы процессов программной инженерии). Набор моделей CMMI включает три модели: CMMI for Development (CMMI-DEV), ориентированная на организации, занимающиеся разработкой программного и аппаратного обеспечения, а также комплексных систем; CMMI for Services (CMMI-SVC, ориентированная на сервисные службы и CMMI for Acquisition (CMMI-ACQ), ориентированная на организации, приобретающие IT-продукты и услуги.

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

обеспечения (SEI) при университете Карнеги-Меллон
В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем

CMMI-SE/SW имеет две формы.
Ступенчатое представление (the staged representation)
Непрерывное представление (continuous representation)

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

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

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

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

ждать 2-3 месяца, пока Разработчик составит для него коммерческое предложение?
• Кто оплатит работы по анализу требований? (очевидно, Заказчик)
• Как быть, если цена вопроса окажется непомерной и от проекта придется отказаться - кто возместит Заказчику убытки на проведение исследований?

Решение:
• подыскав Разработчика, обладающего богатым опытом выполнения подобных проектов, который сможет дать требуемую оценку значительно быстрее (но риск ошибки при этом остается);
• взяв на себя риски возможного прекращения проекта на ранних стадиях, в случае, если выявится его несоответствие бюджетным ограничениям (в сложных рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета, чем все 100%, как это было в "каскадных" схемах разработки) - путь прогнозирующих методологий
• разделив с Разработчиком ответственность за конечный продукт, приготовившись день за днем работать с ним рука об руку вплоть до появления результата – путь (Agile) методологий.

анализа необходимо:
Выделить 25 - 99 функций, характеризующих систему (совместно, Заказчик и Разработчик);
Установить приоритеты для каждой из функций (Заказчик);
Оценить трудозатраты (Разработчик);
Оценить риски (Разработчик, возможно привлечение Заказчика);

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

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

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

инструментов
Работающее программное обеспечение ВЫШЕ всесторонней документации
Сотрудничество с клиентами ВЫШЕ переговоров по контракту
Реакция на изменения ВЫШЕ следования плану и 12 приложений (в столь же лаконичной форме) к нему.