Презентация на тему: Понятие требований, классификация, уровни требований

• 1 слайд

  МДК 02.01. Технология разработки программного обеспечения
  Цель занятия: рассмотреть основные требования, классификацию и уровни требований. Изучить методологию и стандарты, регламентирующие работу с требованиями.
  Л1.Понятие требований, классификация, уровни требований.
  Методологии и стандарты, регламентирующие работу с требованиями на платформе 1С:Предприятие
  

• 2 слайд

  IEEE и IEC
  разработка стандартов в области ИТ
  IEEE(Institute of Electrical and Electronics Engineers) – институт инженеров по электротехнике и электронике, международная некоммерческая ассоциация специалистов в области техники, делит с МЭК мировое лидерство в области разработки стандартов по радиоэлектронике и электротехнике.
  IEC(International Electrotechnical Commission) – международная электротехническая комиссия, некоммерческая организация, признанный лидер в области создания международных стандартов в сфере электрики, электроники и смежных технологий, в том числе – в области информационных технологий.
  

• 3 слайд

  IEEE и IEC
  функции стандартов
  1. Повышение уровня безопасности в различных сферах
  2. Обеспечение конкурентоспособности и качества продукта процесса или услуги
  3. Обеспечение единства измерений или их сопоставление
  4. Обеспечение рационального использования ресурсов
  5. Обеспечение взаимозаменяемости и совместимости оборудования или технических средств
  6. Присвоение сокращенных названий или кодов продуктам процессам или услугам
  7. Создание классификации и каталогов продуктов процессов или услуг
  

• 4 слайд

  IEEE и IEC
  уровни стандартов
  Стандарты имеют распространение в пределах компетенции органа который их принял. Различают следующие уровни стандартизации:
  
  Международная стандартизация. Органом по стандартизации является ИСО (ISO). Нормативным документом ИСО являются стандарты ИСО.
  Межгосударственная стандартизация. Охватывает ряд независимых государств (СНГ, ЕЭС и др.). Нормативным документом стран СНГ является межгосударственный стандарт.
  Национальная стандартизация — это стандартизация в пределах одного государства (к примеру стандарты ДСТУ или ГОСТы).
  Правила, нормы и рекомендации в определенной области — действуют в границах определенных сфер деятельности (к примеру IEEE)
  Стандарты организаций — сюда входят стандарты предприятий, стандарты обществ и т. п.
  

• 5 слайд

  Продуктная документация
  Данная документация используется проектной командой во время разработки и поддержки продукта. Она включает:
  План продукта (Product Management Plan)
  Документ бизнес-требований (Business Requirements Document)
  Маркетинговая документация (Market Requirements Document)
  Документ требований к программному продукту (Product Requirements Document) или спецификация требований (Software Requirements Specification);
  Спецификация функциональных требований (Functional Specifications Document);
  Техническое задание (Terms of Reference TOR);
  Mind Maps, Макеты, Прототипы;
  Use Cases и User Story;
  Дизайн (Graphic Design, Web Design, Game design).
  План продукта — это официальный утвержденный документ, который в общем определяет, в какой последовательности проект выполняется, проверяется и контролируется. Данный документ не имеет стандартизированной формы и его содержание может варьироваться в зависимости от компании.
  

• 6 слайд

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

• 7 слайд

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

• 8 слайд

  Уровни требований
  Бизнес-требования
  Business requirements
  Пользовательские требования
  User requirements
  Функциональные требования
  Functional requirements
  Выделяют три уровня требований.
  Бизнес требования определяют что системы должна делать с точки зрения бизнеса, в данном случае «бизнес» используется как «заказчик»
  
  Пример бизнес-требования:
  Система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза.
  
  Зачастую формулируются топ-менеджерами, либо акционерами предприятия
  

• 9 слайд

  Бизнес-требования
  Business requirements
  Пользовательские требования
  User requirements
  Функциональные требования
  Functional requirements
  Выделяют три уровня требований.
  Пользовательские требования описывают цели и задачи пользователей системы, которые должны достигаться/выполнятся пользователями при помощи создаваемой программной системы.
  Пример требований пользователя:
  Система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнений.
  
  Требования пользователей зачастую плохо структурированы, дублируемы и противоречивы.
  Уровни требований
  

• 10 слайд

  Бизнес-требования
  Business requirements
  Пользовательские требования
  User requirements
  Функциональные требования
  Functional requirements
  Выделяют три уровня требований.
  
  Функциональные требования определяют функциональность(поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей.
  
  Пример функциональных требований:
  Заказ может быть создан, отредактирован, удален и перемещен с участка на участок.
  Уровни требований
  

• 11 слайд

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

• 12 слайд

  Классификация RUP
  Акроним FURPS обозначает следующие категории требований:
  -Functionality (Функциональность)
  -Usability (Применимость)
  -Reliability (Надежность)
  -Performance (Производительность)
  -Supportability (эксплуатационная пригодность).
  
  
  Символ "+" расширяет FURPS- модель, добавляя к ней:
  -ограничения проекта,
  -требования выполнения,
  -требования к интерфейсу,
  -физические требования,
  
  
  

• 13 слайд

  Методологии и стандарты, регламентирующий работу с требованиями
  1. Разработки IEEE:
  -IEEE 1362 "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. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
  
  

• 14 слайд

  Характеристики, которым должны отвечать требования
  1. Единичность — требование описывает одну и только одну вещь.
  2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
  3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
  4. Атомарность — требование нельзя разделить на более мелкие.
  5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
  

• 15 слайд

  Характеристики, которым должны отвечать требования
  6. Актуальность — требование не стало устаревшим с течением времени.
  7. Выполнимость — требование может быть реализовано в рамках проекта.
  8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
  9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
  10. Проверяемость — реализованность требования может быть проверена.
  

• 16 слайд

  Стадии выявления и представления требований
  Выявление
  Первичный анализ
  Документирование
  Проверка
  Исправление и уточнение недостатков
  Переработка
  Повторная оценка
  Прояснение
  

• 17 слайд

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

• 18 слайд

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