ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 19.10.2024
Просмотров: 33
Скачиваний: 0
Требованияпредметной области
•Этребованияотображаютусловия, которыхбудетэксплуатировать программнаясистема
•Онимогутбыпредставленыьвиденовыхфункциональных требований, видеогра ужичасформулированныений функционатреболввьныеиидеанийуказ, системанийкдолжна выполнятьвычисления
•Невыполнениетребованийпредметнойобластиможетпривестик выходусистемыизстроя
25
Требованияк ИСБиблиотекаВУЗа
•Стандартныйпользовательскийинте,предофейсдоступтавляющийко всембиблиотечбаздамн,долженныосновыватьсяхмнастандарте
Z39.50
•Дляобеспечеавтоправнскихияекоторыедокумдолжныбытьнты удаленыизсистемысразупослеполучения.Дляэтого,взависимостиот желанияпользователя,этидокуменмогубыраспечтыь илинатаны локальномсистесервере,илиномнасетевомпринтере
26
Системаавтоматического торможенияпоезда
Тормпоженвычездаипосляетсяформуле:
Dпоезд= Dуправление+ Dградиент,
где Dградиентравен9м.·81с2компенсирующий* градиент/альфа. Значение9м.·81с2/альфаизвестнодлявсехтипоездов.
Длянеспециалиструднопонэязыкотатьиобозначенияданной предметнойобласти
27
Проблемытребований предметнойобласти
•Понятность
•Неявность
28
Вопрос№2
Документированиетребований
29
Документирование требованийкПО
•Документ,содержащийтребования,такженазываспецификациеймый системныхтребован, этоофициальное– йпредписаниедля разработчиковпрограммнойсистемы
•Онсодержитпользовательскдетализированноетребовани ия описаниесистемныхтребований
•Внемуказываетсято,чтосистемадолжнаделать, некаконадолжна этоделать
30
|
Agileметодыитребования |
|
||
• |
Специалисты,использующиеAgileметоды,утверждают,что |
|
|
|
|
|
представлениедокумтр бованийнтаявляепустойсяратойвремени, |
|
|
|
|
посколькутребованияизменяютакбыстрося |
|
|
• |
|
Поэтомудокументвсегдаявляактуальнымется |
|
|
• |
МетодЭкстремальногопрограммированияиспользуетдополнительные |
|
||
|
|
техническиетребованиявыражаеттребованиякакпользовательские« |
|
|
|
|
истории» |
|
|
• |
Этопрактичнодлябизнес-систем,нопроблемадлясистем, ично |
|
|
|
|
|
которыетребольшогоуютанализапередпоставкойнапример( , |
|
|
|
|
критическиважныесистемы)или,стемразрабатываемыхнесколькими |
|
|
|
|
командами |
|
|
|
|
|
|
31 |
|
|
Читателидокумента |
|
|
|
|
требований |
|
|
|
|
|
Опредтребованияляют,проверяют |
|
Заказчикисистемы |
специфицированныетребованиянасоответствие |
|
||
требованиямзаказываесистемы.Онимогутй |
|
|||
|
|
|
|
|
|
|
|
вноситьизмененияспецификацию |
|
Руковомпаниидство- |
Используютспецификациюдлярасчетацены |
|
||
|
разработчика |
системыдляпланирорвцессазработкиния |
|
|
|
системы |
|
||
|
|
|
|
|
Разработчики |
Используютспецификациювпроцессеразработки |
|
||
|
системы |
системы |
|
|
|
Инженеры, |
Используютспецифприазработкекациютестов, |
|
|
тестирующиесистему |
необходимыхдляаттестациисистемы |
|
||
Инженеры,поддержки |
Спецификацияпомогаетразобравсиситьсяеме |
|
||
|
системы |
понять,каквзаимодействуютееотдельные |
32 |
|
|
компоненты |
|||
|
|
|
||
|
|
|
|
|
|
|
Изменениедокум нта |
|
|
|
|
требований |
|
|
• |
Информациявдокумтребонтезавотанистипасистемыйметода |
|
|
|
|
|
используемоговразработке |
|
|
• |
Системы,разрабпостепеннотанныебудут,какправило,имеютменьше |
|
|
|
|
|
деталейвдокумтребованийнте |
|
|
• |
|
Докумтребованийнтырегламентируютсястандартами |
|
|
|
|
|
|
33 |
Структдокурамента требованийIEEE/ANSI 830
Раздел |
Описание |
|
|
|
|
Предисловие |
Здесьопределяетсякруглиц,накоторыхрассчитанданныйдокумент.Описываются |
|
предыдущазрабатываеве сии программнпроду,оготакизмененияжетаго, |
||
|
внесенныекаждуюверсию.Даетсяобоснованиедлясозданияойрсиипродукта |
|
|
|
|
|
Здесьболееразвернутообосннеобхвываетзданиясодимостьистемы.Кратко |
|
Введение |
перечсистемныесляютсяфункцииобъясняется,каксистемабудетработать |
|
совместнодругсистемами.Должнобытьпоказ,какр нозработкасистемы |
||
|
"вписывает"общуюбизнестратегиюякомпании,заказывающейпрограммный |
|
|
продукт |
|
|
|
|
Глоссарий |
Даетсяописаниетехническихтермин,исповльзуедоку.Здмнеыхделаетсянтесь |
|
как-липредполбохобуровнезнажеилипрактий опытеческомитателя |
||
|
документа |
|
|
|
|
|
Описервисыываются,предоставляемыепользователям,инефункциональные |
|
Пользовательские |
системныетребования.Этоописаниеможетбытьсделестественномна языке |
|
использовансхемдиаграмм,блокдругихформзаписи,понятныхзаказчику |
||
требования |
||
программнойсистемы.Здесьтакжедолжныбытьприведеныстандартынапрограммный |
||
|
продуктипроцессегоразработки |
34
Структдокурамента требованийIEEE/ANSI 830
Раздел |
Описание |
|
|
Системная |
Здесьпривысокоуроодитсяпредставлениеневозможнойсистемнойархитектуры |
суказанием,какраспределесистемныефунпокцииомпонентамсистемы. |
|
архитектура |
Обязательнодолжныбытьвыделеныповторноиспользу(.е.ужсуществующиемые) |
|
компоненты |
|
|
Системные |
Подробноописываютсяфункциональныенефункциональныетребования.Если |
необходимо,нефункциональныетребованиядополняютсяописаниеминтерфейсов |
|
требования |
другихсистем |
|
|
Системныемодели |
Здесьпредставленонесколькосистемныхделей,показывающихвзаимоотношения |
междусистемныкомпонентамиеждусистемойееокружением.Этобыгуть |
|
|
объектныемодели,моделипотоковданныхилимоданныхели |
|
|
Эволюциясистемы |
Приводятсяосновныепредположениядопущения,накоторыхбазируетсясистема, |
такожидаемыепрогно( ) зирумененияваппаратныхмыесредствах, |
|
|
потребностяхпользователейи. |
35
Структдокурамента требованийIEEE/ANSI 830
Раздел |
Описание |
|
|
|
|
|
Здесьприводитсяспециализировинфотносящаяся, рм кцияннаяразрабатываемой |
|
|
системе,напримерописаниеаппаратныхсредствилибазыданных,скоторымидолжна |
|
Приложения |
работатьсистема.Приописанииаппаратныхсредствнеобходимопоказать |
|
минимальнуюоптимальнуюконфигурации,прикоторыхможетработатьпрограммная |
||
|
||
|
система.Описаниебазыданныхдолжноотображатьлогическуюструктуруданных, |
|
|
которымибудетработатьсистема, отношениямеждуними |
|
|
|
|
Указатели |
Вдокументевозможноиспользоваразличныхуказателей.Этоием бытьжетобычный |
|
алфавитныйуказатель,указательдиаграммилиуказательсистемныхфункций |
||
|
||
|
|
36
Спецификация
требований
•Процесснапипользовательскиханиясистемнытребований докумтребованийнте
•Требпользваниядователялжныбытьпонятконымиечным пользователямиклиен,ко неорыеимеютхнического образования
•Систребованияемныеявляютсяболееподробнымитребованиями могутвключатьсебябольшетехнинформациической
•Требованиямогутбычастьюконтнаразрктасистемыботку
37
Способынаписания |
||
спецификациитребований |
||
|
|
|
Системазаписи |
Описание |
|
|
|
|
Естественныйязык |
Описаниетребованийпомощьюсписка.Каждоепредложениеотдельное |
|
требование |
||
|
||
|
|
|
Структуризированный |
Использовстандформаниертныхшаблоновдлянаписанспецияфикации |
|
естественныйязык |
|
|
Языкиоп сания |
Использованиеспециальныхструктурирязык,подобовязыкаманных |
|
программирования,гдеспецификациятребованийстроитсянаоснове |
||
программ |
||
выбраннойоперационноймоделисистемы |
||
|
|
|
|
Графическийязык,использующийдляописафуниякциональныхтребований |
|
Графическаянотаци |
диаграммыблок-схемы,дополненныетекст вымиясн.Сегодняниями |
|
частоиспользуетсядиаграммывар антовспользования |
||
|
||
|
последовательностейнаязыкеUML |
|
|
|
|
|
Этосистемынотаций,основанныенаматематичконц,таепциях,скихак |
|
Математические |
теорияконечныхавтоматовилитеориямножеств.Этоформализованная |
|
однозначнаяилишеннаядвусмысленностизаписьтемныхтребований. |
||
спецификации |
ОднакомногиезаказчикиПОнепонимаютформальныхспецификаций, |
|
|
вследствиечеговозникаютопределенныепроблемыпризаключении |
|
|
контнарактовзрабпрограммныхткупродуктов |
|
|
|
|
38
Требование
проектирование
•Требдованиялжнызаявить,чтосистемадолжнаделать, проект долженописать,каконивыполняются
•Напрактике,требованияпро ктдругделимыотдруга
•Архитектурасистемыможетбытьразработанабезструктутребованийяир
•Системаможетвзаимосдействоватьругсистемами,котопределяютрые проектныетребования
•Использованиеопределеннойархитектуройдляудовлетворения нефункциональныхтребованийможетбытьтребованипредмобластиемтной
•Этом бытьжетследствиемнормативныхтребований
39