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

1.

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

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

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.

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