PI-Lec3 (1)

	Agileметодыитребования
•		Специалисты,использующиеAgileметоды,утверждают,что
		представлениедокумтр бованийнтаявляепустойсяратойвремени,
		посколькутребованияизменяютакбыстрося
•		Поэтомудокументвсегдаявляактуальнымется
•		МетодЭкстремальногопрограммированияиспользуетдополнительные
		техническиетребованиявыражаеттребованиякакпользовательские«
		истории»
•		Этопрактичнодлябизнес-систем,нопроблемадлясистем, ично
		которыетребольшогоуютанализапередпоставкойнапример( ,
		критическиважныесистемы)или,стемразрабатываемыхнесколькими
		командами
				31
		Читателидокумента
		требований
			Опредтребованияляют,проверяют
Заказчикисистемы			специфицированныетребованиянасоответствие
			требованиямзаказываесистемы.Онимогутй
			вноситьизмененияспецификацию
Руковомпаниидство-			Используютспецификациюдлярасчетацены
	разработчика		системыдляпланирорвцессазработкиния
			системы
Разработчики			Используютспецификациювпроцессеразработки
	системы		системы
	Инженеры,		Используютспецифприазработкекациютестов,
тестирующиесистему			необходимыхдляаттестациисистемы
Инженеры,поддержки			Спецификацияпомогаетразобравсиситьсяеме
	системы		понять,каквзаимодействуютееотдельные	32
			компоненты
		Изменениедокум нта
		требований
•		Информациявдокумтребонтезавотанистипасистемыйметода
		используемоговразработке
•		Системы,разрабпостепеннотанныебудут,какправило,имеютменьше
		деталейвдокумтребованийнте
•		Докумтребованийнтырегламентируютсястандартами
				33

Структдокурамента требованийIEEE/ANSI 830

	Раздел	Описание
	Предисловие	Здесьопределяетсякруглиц,накоторыхрассчитанданныйдокумент.Описываются
		предыдущазрабатываеве сии программнпроду,оготакизмененияжетаго,
		внесенныекаждуюверсию.Даетсяобоснованиедлясозданияойрсиипродукта
		Здесьболееразвернутообосннеобхвываетзданиясодимостьистемы.Кратко
	Введение	перечсистемныесляютсяфункцииобъясняется,каксистемабудетработать
		совместнодругсистемами.Должнобытьпоказ,какр нозработкасистемы
		"вписывает"общуюбизнестратегиюякомпании,заказывающейпрограммный
		продукт
	Глоссарий	Даетсяописаниетехническихтермин,исповльзуедоку.Здмнеыхделаетсянтесь
		как-липредполбохобуровнезнажеилипрактий опытеческомитателя
		документа
		Описервисыываются,предоставляемыепользователям,инефункциональные
	Пользовательские	системныетребования.Этоописаниеможетбытьсделестественномна языке
		использовансхемдиаграмм,блокдругихформзаписи,понятныхзаказчику
	требования
		программнойсистемы.Здесьтакжедолжныбытьприведеныстандартынапрограммный
		продуктипроцессегоразработки

34

Структдокурамента требованийIEEE/ANSI 830

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

35

Структдокурамента требованийIEEE/ANSI 830

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

36

Спецификация

требований

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

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

•Систребованияемныеявляютсяболееподробнымитребованиями могутвключатьсебябольшетехнинформациической

•Требованиямогутбычастьюконтнаразрктасистемыботку

37

	Способынаписания
	спецификациитребований
	Системазаписи	Описание
	Естественныйязык	Описаниетребованийпомощьюсписка.Каждоепредложениеотдельное
		требование
	Структуризированный	Использовстандформаниертныхшаблоновдлянаписанспецияфикации
	естественныйязык
	Языкиоп сания	Использованиеспециальныхструктурирязык,подобовязыкаманных
		программирования,гдеспецификациятребованийстроитсянаоснове
	программ
		выбраннойоперационноймоделисистемы
		Графическийязык,использующийдляописафуниякциональныхтребований
	Графическаянотаци	диаграммыблок-схемы,дополненныетекст вымиясн.Сегодняниями
		частоиспользуетсядиаграммывар антовспользования
		последовательностейнаязыкеUML
		Этосистемынотаций,основанныенаматематичконц,таепциях,скихак
	Математические	теорияконечныхавтоматовилитеориямножеств.Этоформализованная
		однозначнаяилишеннаядвусмысленностизаписьтемныхтребований.
	спецификации	ОднакомногиезаказчикиПОнепонимаютформальныхспецификаций,
		вследствиечеговозникаютопределенныепроблемыпризаключении
		контнарактовзрабпрограммныхткупродуктов

38

Требование

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

•Требдованиялжнызаявить,чтосистемадолжнаделать, проект долженописать,каконивыполняются

•Напрактике,требованияпро ктдругделимыотдруга

•Архитектурасистемыможетбытьразработанабезструктутребованийяир

•Системаможетвзаимосдействоватьругсистемами,котопределяютрые проектныетребования

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

•Этом бытьжетследствиемнормативныхтребований

39

Спецификациина естественномязыке

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

•Используетсядляописаниятребований,потомучтоэтовыразительно, интуитунив.ерсальноЭтоознача, т етбованиямогутбы ь понятыкакразработчикутакзаказчику

40

Руковпописаниюдство требований

•Придумайтестандартныйформатиспользуйтеегодлявсех требований

•Описывайтетребованияпоследовательно,разделяяобязательныеи желаемыетребования

•Используйтевыделениетекстацеляхопределенияключевыхчастей требования

•Избегайтеиспользованиякомпьютертерминыхов

•Включайтеобъяснениеобосн( )того,птребованиечему необходимо

41

Проблемысестественным языком

•Отсутствиеясности

•Беспорядоктребований

•Объединениетребований

42

Пример ТребованиякПОинсулиновойпомпы

•3Система.2 должнаизмерятьуровеньсахакровиапри необходимостивводитьинсулинкаждые10минут.Изменение( уровня сахавкроатносительновимедленно,поэтболеечастыему измерениянетребует;менеечасизмеренятыемогутприквестия неоправданновысокур сахаравнюму).

•...

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

43

Структурированныйязык спецификаций

•Подходкнаписаниютребован,гдесвободапиясаттребованийля ограниченатребованиязапистандартнымываютсяспособом

•Этох работаетошодлянекотоиповребованых,например, й требованквстроеннойсистемеяуправления

44

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

•Описафункцииилииеобъекта

•Описаниевходныхданныхиисточники

•Описаниевыходныхданныхсуказанпунктаихназначенияем

•Указание,чтонеобходимодлявыполненияфункции

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

•Описаниепобочныхэффектовесли( ониесть)

45

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

Инсулиноваяпомпа/ПОуправления Функция дозуВычисляетинсулина:безопауровеньсныйахара

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

Входданные	Текущзначсахараение(R2);двапредыдущих
значения(R0R1)
Источникивходныхданных	Текущзначсахараениеиздатчика;
Предыдущиезначения-изпамяти
Выходнданные	инсуДозадлвводаяина
Пунктназначения	Основнойциклуправления

46

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

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

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

Предусловие резервуареВинсулинадолжносодержпократьсяйней меремаксимальнодопустимраздозавая

ПостусловиеR0заменитьR1,заменитьR1R2

Побочныеэффекты Отсутствуют

47

Табличнаяспецификация

•Используетсявдополнениекестественномуязыку

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

•Наприм,систинсулиновермапомпыосносвйрасчетыываетоина скоростиизмененияуровнсахакровитабличнаяспецификация объясняет,каквычислитьдозуинсудразличныхяинасценариев

48

Табличныйспецификации

	вычисленийдляинсулиновой
	помпы
	Условие	Действия
	Уровеньсахпадаетра(R2 < R1)	CompDose = 0
	Уровеньсахарастабилен(R2 = R1)	CompDose = 0
	Уровеньсахрасра,нотеростампснижается	CompDose = 0
	((R2 - R1) < (R1 < R0))
	Уровеньсахрасра,нотеростампстабиленили	CompDose = round((R2 - R1)/4)
		If rounded result = 0 then
	увеличивается((R2 - R1) >= (R1 < R0))
		CompDose = MinimumDose

49

Процессразработки требований

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

•Существуетрядобщихмероприя,харакдлятвсехийерныхпроцессов

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

•Анализтребований

•Проверкадопустимтребованийсти

•Управлениетребованиями

•Практически,разработкатребований-итератидействие, которомное чередованыэтипроцессы

50

Спиральоцесса разработкитребований

Requirements

specification

System requirements specification and modeling

User requirements specification

		Business requirements
		specification
		Start	Feasibility
	System
Requirements			study	Requirements
	req.
elicitation	elicitation	User		validation
		requirements	Prototyping
		elicitation

Reviews

System requirements document

51

		Выявленианалиез
			требований
	•	Иногдаегоещеназываютоткрытиемтребований
	• Включаеттехническихсотрудни,работающихсковлиентами,чтобы
		узнатьопредметнойобластиприложения,услуги,которыесист ма
		должнаобеспечитьэксплуатационныеогран стемычения
	• Можетвключатьконечныхпользователей,менеджеров,инженеров
		участвующихобслуживании,экспоертоведмеобласти.дной.
		Ихвызываютзаинтересованнымисторонами
			52
		Процессвыявления
		требовианалнизай
		Этап	Действия
			Взаимодействзаинтересованнымил цами,чтобы
	Выявлтребованийние		выявитьихтребования.Требованияпредметной
			областивыявляютсянаэтойстадии
	Классификациятребований		Требованформируютсягруппии
			когерентныекластеры
	Назначениеприоритетов		Приоритезтребованийциязрешение
	разрешениепротиворечий		конфликтовтребований
	Спецификациятребований		Требдованкументиначяиследующийнаетсяруют
			циклспирали
			53
		Процессвыявления
		требовианалнизай
			Выявлтребованийние
		Спецификация	Классификация
		требований	требований
			Назначениеприоритетов
			иразрешение
			противоречий
			54

Проблемыанализа требований

•Заинтересовсторонынезн,ачтоютонидействительноыехотят

•Заинтересованныесторонывыражаюттребованиясвоихсобственных терминах

•Различзаиныетсторресомовгутанныеысказывать противоречивыетребования

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

•Изментребованийниепроцессеанализа

55