Дополнительно / IEEE-830-1998. Методика составления спецификаций требований к программному обеспечению

Стандарт IEEE 830-1998Методикасоставления. спецификацийтребованийпрограммномуобеспечению

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

, можиметножественныеь

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

конкретно.

SRSявляетважнойчапроцстьюя

ессаостребованийавленияжизненномцикле

программного

обеспеченияиспользуется

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

,реализации,

монитопро,вериктангефикации

проверкеправильности,такжепри

обучении,какописвстанIEEEдартео1074

-1997должнабыть. SRS

однозначнойкакдлятех,ктос сеё,таидлявктех,ктояетеё

использ.Однако,этигручастоетппы

не

имеют обладаютобщимконтекстом,благодаряразличиямвсвоёмопыте,подготовкеорганизационной

роли,следовательно,несклонныопистребованиявать

кпрограммномуобеспечению

схожим образом.

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

дляразработчика,

могутказатьсянеэффектвтом,чтоонивными

ухудшают пониманиепользователем,наоборот.

Вподразделахс4.34.2.даются3.1.рекоме2.3,какизбнедациижатьоднозначности.

4.3.2.1 «Ловушки» естественногоязыка

Требованиячастопишутсянаестественномзыкенапример( ,английск)Естественный. языкпом

существу своему являетсянеоднозначным.

SRS наестественном

языкедолж на анализироваться

независимойсторонойдлявыявлеприменениянеоднозначногозыка

так,что

быэтунеоднозначность

можнобылскорректировать.

Одизнедоимиспользовантатязыковихляетсядлительностьизучениях.Ктоже,многие

пользователи,неимеющиеотношенияктехн

ике,счинепонятнхтают

ыми.Крто,этигомеязыкилучше

выражаютопределённые

типытребований

имеютлучшуюприменимдлянекоттиповси.стрыхемь

Вследствиеэтого

,онимогут

неявнымобразом

влиятьнатребования

.

4.3.2.3 Инстпредставленияументы

требований

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

разделяюнатрисяосновныхкатегории

— объектные,процесс ные иповеденческие

.Прииспользовании

объектно-ориентировме,требованияодовкл нныхссифиц

ируютсяязыкреальныхобъектовм,их

атрибутовфункций,выполняэтимиобъ.Мемыхк,ориетамиодынпроцесстированные,

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

Поведенческиеподходыописвнешнееповедевают

ниесистемыязыкомнекихабстракпонятийных

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

Степень,доко акиеосройедсметобытьвагутдыполезнывподготSRS,зависитотвкебъма

сложностипрограммы.В

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

-либо

специфическийинструмент.

Прииспользован иилюбогоизэтихподходовлучшевсего

сопровождатьих

описаниями наестественном

языке.

Такимобразом

заказчики,незнакомыесоспецифической

темойобозначений,

темменее

будутвсостояниипонятьSRS.

4.Завершенность3.3

SRSявляполн,еслитсяолькой

, еслионавключаследующиеэл:менты

а)Всесущественныетребования,независимоототн, голикнисятсяфункциональным

возможностям,

рабочимхарактеристикам,програничениямект,атрибутаымиливнешним

интерфейсам.Вчастнос,должныбыподтвеьииобработанылюбыежденывнешние

требов,налспецагаемыениясистемыфикацией

(частьюкоторойбудетявлятьсяпрограмма)

.

Версияпереводаот8

сентября2014г.

11

Стандарт IEEE 830-1998Методикасоставления. спецификацийтребованийпрограммномуобеспечению

б) Определениеоткликовпрограммногообеспнавсеклассывходченияда,которыеных

могутбытьреализ,вовсехозможныхваныситуациях.Следуетзаметить,чтоважно

определитьотклики

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

в) Полные обозначенияссылкивсерисунки,таблицысхемывSRSопределениевсех

термиедизмеренияницов.

4.Использование3.3.1

метки <TBD>

ЛюбаяSRS,вкоториспфраользуетсяй

за« подлежитопределению

» (метка TBD),неявляетсяполной

SRSОднако,иногда.

меткаTBDнеобходимадолжна

сопровождаться:

а) Опиус,ловийявляющаниемпричвозникновенияхсяой

ситуации TBD (нап, римерочему

ответ неизвестен)так,чтобы

эту ситуациюможнобылразрешить;

б) Описаниемтого,чтод бытьлжно

сделано,чтобыисключит

ьметку TBD,ктоответствененза

её

устранениеконагдадолжнобытьустранена

.

Непротиворечивостьбозначаетвнутреннююнепротиворечиво

сть.ЕслиSRSнесогласована

каким-то

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

как, например, спецификация системныхтребований

(System

Requirements Specification, SyRS),тоонаявляетсянекорректнойсм(. 4.3.1).

4.Внутренняя3.4.непротиворечивость1

SRSявляевнутренненепротиворечивойся,только

если никакоеподмножество

отдельныхтребований,

описанныхвней,

енаходитсявпротиворечии

.ТремятипамивероятныхконфликтовSRSявляются

следующие:

а) Могутвходитьконфликтзаданныехарактеристикиреальныхобъектов.Например,

1) Форматтчетаовыходданможетных

бытьописанводномтребовани

икак

табличный,авдругом

— кактекстовый .

2) Однотребмоустанавливатьжетвание,чтовсеиндикаторыдолжныбыть

зелеными,в

товремякакдругомможетбытьуказа,чтовсеиндикаторы

должныбытьсиними.

б) Междудвумязаданнымидействиямиможетсущес

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

конфликт.Например,

1) Однотребмоустанавливажетвание,чтопрограммабудеть

складыватьходных

параметра,а

другоеможетуказывать,

чтопрограмперемножатьбудетих

.

2) Однотребовани

еможетустанавливать,чтоА«»должн

овсегдаследоватьзБ«»

,в то

времякакдругое

можеттребовать,ч событияА«»Б«»

происходили

одновременно.

в) Дваилиболтремебогутванийписыватьодинтотжереальныйобъект,но

использовать

для этогообъектаразличныетермины

.Например,

запровводеграммыс

пользователем

можетназываться«

подсказк»воднтребованиийм«

запросом» в другом.Использование

стандарттерминологиий

и определподдерживаетний

непротиворечивость.

SRSя

вляетсяупорпозначимостидоченной/илиустойч,еслкаждоетребованиевостиимеетй

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

Какправило,всетреб,к касаютсяторыеванияпрограммногоизд, являюелия

тсяважнымиравной

степени.Некотортребмбгутываниятье

неотъемлемыми,особеннодля

приложений, которых

зависитжизньлюдей,

втовремякакдругиемогутбыть

лишь желательными.

Версияпереводаот8

сентября2014г.

12

SRS являетсямодифицируемой,еслитолько

, еслиееструктураистиль

таковы,чтолюбыеизменения

требмобытьгутванийыполненылегко,полностью

инепротивобразомссох ечивыманением

структурыистиля.Какправило,модифицируемостьтребует,чтобы

SRS:

а) Имеласвязаннилегкиспользовуюструктуруогл,авлениемнии

алфавитным указателемиявно

выраженнымиперекрё

стнымиссылками;

б) Небылаизбыточной(есть,одножетребнедолжнопоявлятьсявание

SRS более чемв

одномместе);

в) Выражалакаждоетребованиераздельно,несм сгошиваядругимитребованиями.

Избытсамапосебенеявляетсячношибкойсть,нооналегкоможетпривестикпоявлениюошибок.

Иногдаизбыточностьможетпомочьсделать

SRS болеечитаемой,номогутвоз

никнутьпроблемыпри

обновлении избыточногодокумента.Нап, ребимеробытьжетвание

змененотольководнизтехм

мест,гдеоноп является.Тогда

SRS

становитсяпротиворечивой.Каждыйраз,когдаизбыточность

необходима,

SRS должнавключатьявныеперссылкикрёстные,чтобысдеёлать

модифицируемой.

SRS являетсяотсле

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

ежисточникваетсякаждогоизеё

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

позволяетссылатьсянакаждое

изтребованийпридальнейшейразработкеилимодернизации

документации.Рекомсл двандуютсятипаующиеотслеживаемости:

а)

Обратнаяотслеживаемо

ст(естьъо,кпредыдущимстадиямразработки).

Зависитот

того,

ссылаетсяливявномвидекаждоеизтребований

наегоисточниквболееранних

документах.

б)

Прямаяотсл

еживаемостъто(есть,ковсемдокументам

,порождаемым

SRS). Зависитот

того,

имеетликаждое

требованиеиз

SRS однозначноопределё

нноеимяилиномерссылки.

Прямая отслеживаемость SRS особенноважна,когдапр изделиеграммноевступастадию

эксплуатации исопровождения.По

мереизменениякодаархитектурных

документовне

обходимоиметь

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

4Совместная.4 подготовка

SRS

Процессразрабпрограммногобеспечеткидолженначинатьсяглашениямеждупоставщиком

заказчикповопросутомм

,чтод выполнятьлжнозавепрограммноешенноеобеспечение.Это

соглашениевформе

SRS должнобытьподгсовместтовле.Этоважно,таккакобычнонизаказчик,

нипоставщикнеимеютдостаточнойквалифик,чтобысосткачесцвитиьвенную

SRS самостоятельно.

а) Заказчикиобычнепонивдостаточмаютстепепроцесспроектированияиой

разработки

программногообеспечения,чтобысоставить

SRS,пригоднуюдля

использования.

б) Поставщикиобычнепондостаточимаютстепепроблемызаказчиканой

предметную

область,чтобыопредетребованиясл ,стемыкотораятьудовлетворит

заказчика.

Следов,закипоставщикзчиктельнодолжныработаоздатьвме,чтобыстехорошонаписанну

юи

полностьюпонятную

SRS.

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

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

программногообеспечениянепредо

пределя,азадасовмеютсяиподлежатсогласованиютно

изменению.Приэтомболеетрудно, менееважносделатьтак,чтобы

SRS удовлетворяла

характеристикам,изложеннывпункте4Вчастности.3.,

SRS,котораянесоо вретствуетбованиям

спецификацииееродительскойсистемы,являетсянекорректной.

Версияпереводаот8

сентября2014г.

14

Стандарт IEEE 830-1998Методикасоставления. спецификацийтребованийпрограммномуобеспечению

Даннаяметодикаспеци льн

онеобстильуждает,применение

языкаилиметодыкачественного

написания.Однаковесьмаважно,чтобы

SRS

былахорошонаписа

на.Вкачестверуководстваможет

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

техническихтекстов

.

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

SRS.Может

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

можетказатьсяневозможнымпределитьвсеформэкраинтерактивнойдлятыпрогрнаст дииммы

выработкитребований).

Дополнитизменениямогутпольные

надобитьсяпомеретого,какв

SRS

обнаруживаютсянеточности,недостатк

иипогрешности .

Двумяглавнымикритеэтомпроцессеиямиявляютсяследующие:

а) Требовадолжбытьопределнвыият мбъистойтщательностьюмены,какони

известнына

текущиймоме

нт,дажеесли

эволюционные изменениямогутбыть

предскакнеиа.збежныеаны

Долженбыотметотьфакт,чтоенявляютсяеи

полными.

б) Долженбытьинициализированформальныйпроцессизмене,чтобыидентифицироватьий,

управлять,происоставлятлеживать

ь отчет о запроектированныхизменениях.

Утвержденные

изменениятребдолжныбытьвавключеныий

SRS такимобразом,

чтобы:

1) Обесточнуюиполнуюечитьпроверкуизменений;

2) Обеспечитьанализтекущихзаменё

нныхчастей

SRS.

Макетирчастоиспнаоэтапеваниельзувыработкитребованийтсяпроекта.Существуютмногие

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

некоторыехарактеристикисис.См. акжеемы

ASTM Е1340 -96.

Прототипыу

добныпоследующимпричинам:

а) Болеевероятно,чтоз

аказчик ознакомится прототипомиоценит

его,нежели

прочитает иоценит

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

связь.

б) Протображаеттипнепредвиденас ектыоведесистем. ныеия

Такимобразом,он

генерирует

толькоответы,нотакжеиновыевопр.Этомогаетсы

продвигатьсякзавершению

SRS.

в) SRS,базирующаясянапрототипе,

обычноменьшеменя тся

во времяразработки,сокращая

, таким

образомеё

длительность.

Прототипдолженисп

ользовкспоатьквысяобвления

требованийкпрограммномуобеспечению.

Некоторыехарактеристики,такиекакформэкранаилио ,могутчетаыбытьвыднепосредственнолены

изпрототипа.Другиетребмбытьгутванияыведеныпосредствомпроведенэксперименя

товс

прототипом.

Любтребопределяваннешнвифункцдимуюеилитатрси.юстемыбут

Архитектура

программногообеспечения

описываетспецифическийподкомпонентсистемы/илиегоинтерфейс

другимиподкомпонентами.Составитель

(-ли) SRS должныясноос разницузнаватьмежду

идентификацией требуемыхархитектурныхограниченпрое онкретархитектурыйрованойием

.

Следуетза

мети,чтокаждоетребованиеь

SRS ограничиваварианархитеыктур

.Темнеме,этонее

означает,чтокаждо

етребованиепредставляетсобойархитектурноерешение

.

Версияпереводаот8

сентября2014г.

15

Стандарт IEEE 830-1998Методикасоставления. спецификацийтребованийпрограммномуобеспечению

SRSдолжнауказывать,какиефункциидолжнывыпол

нятьсякакимиданными

ляполучениякаких

результатов вкакомместеидлякого. должнаSRSфокусироваться

предоставляемых услугах. SRS

обычнонедолжнауказыватьэлементы

архивнутреннейтекс руктурыпрограммы

,такиекак:

Вособыхслучаяхнекоторыетребм гвания

утстрогоограничивархитектуруь

.Например,

требованияк

защибезопалищенном гуттражатьснепоностив трукредспотребностьвуревенно

:

а)

Сохраненекотфувнотдельныхиикцийрыхмодулях;

б)

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

в)

Проверкецелостности

данныхдлякритическихпеременных.

Примерами применимыхогрархитектурыничений

являютсяфизическиетребования,

рабочим харак,стандаеристикамразрабп тыограммногобеткисобеспечениятандарты

качествапрогр.едстваммных

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

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

ено, ие

определяетархитектуру

.

4Встраивание.8 требокпроектуаний

SRS

SRSдолжнаотноситьсякпрогризделиюане, ммномукпроцессуего.здания

Требованиякпроектупредставляютсоглашениемеждузаказчикпоставщикомд говорным

вопросам,имеющимотношениексозданиюпрограммногообеспечения,такимобразом,нед

лжны

включатьсяSRSОниобычновключают. такиепозиции,как

а)

Стоимость;

б)

Графикипоставки;

в)

Процедуры предоставленотчетностия

;

г)

Методыразрабпрограммногобеспечениятки;

д)

Обеспечениекачества;

е)

Криутвержденияерииверификации;

ж)

Процедурыприемки.

5Части.

SRS

Вэтомразделеобсуждаетсякаждаяизнеобходим

ыхчастейSRSЭтичастипок. нрисункеазаныв1виде

макета,который

можетслужитьпримеромдлясоставленияSRS.

Несмотрянато,чтоSRSнедолжнаповэторять

макет илииспользоватьнаименования,приведенные

зддляечастейсь,качественносоставленна

я SRSдолжнавключатьвсюинформацию,обсуждаемую

здесь.

Версияпереводаот8

сентября2014г.

16

Нескоразспособовлькоичных

органиэтогоразациидела

SRS

см.вП

риложении)

Приложения

Алфавитныйуказатель

Рисунок1

— Эскизмакета

SRS

5.1 ВведениеРаздел( 1 SRS)

Введение SRS должно предоставлять краткийобзорвсе

SRS.Онодолжносодержатьследующиеподразделы:

а) Назначение;

б) Областьдействия;

в) Определения,

акронимысокращения;

г) Публикации;

д) Краткийобзор.

5.1.1 НазначениеПодраздел( 1.1

SRS)

Этподтраздолженл

:

а) Обрисоватьназначение

SRS;

б) Указатьаудиторию,длякоторойпредназначена

SRS.

5.1.2 ОбластьдействияПодраздел( 1.2

SRS)

Этподразделт

должен:

а)

Заднаватьзвание

создаваемомупрограммноеизделию(

-ям)

(например,

Host DMBS (Главнаясистемауправлебазойдан),Генераыхияотчеи торв

т.д.);

б) Объяснять,чтопрограммизделиебудет,вслучаенеобхоое,небуделать;имостиет

в) Описыватьприменениезадаваемогопрограммногообеспечения,включсвязнимнные

выгоды,целизадачи;

г)

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

уровня

(например,соспецсистемныхфикациейтреб),еслиосущваний

ествуют.

Версияпереводаот8

сентября2014г.

17

Стандарт IEEE 830-1998Методикасоставления. спецификацийтребованийпрограммномуобеспечению

5.1.3 Определения,акронимысокращенияПодраздел( 1.3

SRS)

Вэтомподразделедолжныбытьпредставленыопр

еделвстенияхрминов,акронимовсокращений

,

необходимыедляправильнойинтерпретации

SRS.Этаинформацияможетбытьобеспеченассылками

одноилиб приложенийлеев

SRS илиссылкнадругиеокументый.

5.1.4 ПубликацииПодраздел( 1.4

SRS)

Этподтраздолженл

:

а) Предполныйставитьписоквсехдокументов,на

которыеделаютсяссылкигде

-либовнутри

SRS;

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

и

организации-издателю;

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

Этуинформациюжнобеспечссылкойнаприилитьложениедругой

документ.

Этподтраздолженл

:

а) Описать,чтонаходитсявоставшейся

части SRS;

б)

Объяснить,какорганизована

структура SRS.

5Общее.2описаниеРаздел( 2 SRS)

Этотраздел

SRS долженописыватьобщиефа,которыевлияютнапрограммноеизделие

(-я)и

требования,предъявлякнему.Этотразделнеустанавливаетмыеконкретныетребования.Вместоэтог,

онобесппречивадварисведенияоттрх ,бкльныеоптванияхорыедробно

пределяютсявразделе

3 SRS,иделаетихболеепростымидляпонимания.

Этотразделобычносостизшесподразделит,именн: ов

а)

Контекст изделия;

б) Функциииздел;

я

в) Характеристикипользователей;

г)

Ограничения;

д) Допущениязависимости;

е) Разделениетребований.

5.2.1 Контекст изделия(

Подраздел2.1

SRS)

Этподразделт

SRS долженописывать

изделиев

контексте сдругими,связаннымизделиями.Есл

издеявлнезависимымяетсяиеполностьюавтономным,

это должнобыть

явно сформулировано

документе.Если

SRS опреизделиеявляется,которкомпоненбольшсист,какэчастоеймы

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

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

нтифицироватьинтерфейсы

междуэтойсистемойпрограммнымобеспечением.

Моказатьсяжетполезнымиспоб ьзованиеок

-схемы,показывающейг

лавныекомпонентыбольшей

си,стоединениймывнешнихинтерфейсов.

Версияпереводаот8

сентября2014г.

18

Этподтраздолжтакженл

описыватькакпрограммноеобеспечениефункционируетврамках

различограничений.Наприых,этиограничениямогутервключать

:

а)

Системныеинтерф; йсы

б)

Интерфейсыпользователя;

в)

Аппаратныеинтерфейсы;

г)

Интерфейпрограммногообе;сыпечения

д)

Интерфейсысвязи;

е)

Память;

ж)

Операции;

з)

Требованияпоадаптациимеспользования.

5.2.1.1 Системныеинтерф йсы

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

программнобеспечения,выпсистемнылняющиеготребовани

я,иопинтерфейсасаниедля

соотвесистствияеме

.

а) Логическхаракаждоготинтерфейсаристикимеждупрограммнымизделиемего

пользователями.

Этовключаетхарактеристики

конфигурациинап( ,т имеребуеформатыые

экрана,

компоновкустраницыилиокна,содержанотчетовлюбыхилиме, нлиюаличие

программируемых

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

программномуобеспечению.

б) Всеаспектыоптимиза

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

Они

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

пользователю.Однимизпримеможетбытьребование,предъявляемоекопцдлилинных

корсообщенийткихошибках.Подобновсемдругим,этребдолжбытьвапроверяемыминия,

X за Z минут послечасатренировки1 »,а

например, «

машинистка4

-го классаможетвыполнитьзадачу

не« машинисткаможетвыполнитьзадачу

Х» (ЭтотакжеможетбытьопределеновАтрибутах

Программной Системы в разделе,озаглавленномПростисп) льзованията

.

5.2.1.3 Аппаратныеинтерфейсы

Этподтраздопределятьолжлогическнхарактеристикикаждогонтерфейсамеждупрогр ммным

изделиемаппа

ратнымикомпонентамисистемы.Онвключаетконфигурационныехарактеристикичисло(

порт,наборыкомандивт..)Он.такжеохватываетвопросы

, касающтого,какустройстваиедолжныся

поддерживаться,каконидолжны отокживаться.На,поримердделы

ржкатерминаламожет

указыватьполнподдержкуэканнуюотивопострочнойддержке.ложность

Версияпереводаот8

сентября2014г.

19

Стандарт IEEE 830-1998Методикасоставления. спецификацийтребованийпрограммномуобеспечению

Длякаждогоинтерфейне обебходимоследующеепечитьа:

а) Обсуждениеназначения

взаимодействующего программобеспечениявотношенииого

кэтом у

программномуизделию

.

5.2.1.5 Интерфейсысвязи

Этподтраздопределятьолжразличныенинтерф

ейсысвязи,такиекак

протоколы локальнойсети

и

т.д.

5.2.1.6 Ограниченияпамяти

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

вторичной памяти.

5.2.1.7 Операции

а)

Различныережимыопераций

ворганизациипользователя

(например,операции,

запускаемые пользователем);

б)

Периодыинте

рактивныхоперацийпериодыавтоматическихопераций;

в) Функцииподдержкиобрданных;ботки

г) Операцрезервированиюпо восстановлению.

ПРИМЕЧАНИЕ — ЭтподразделтиногдауказывчастьразделаИнтерфейсыетсяпользователя.

5.2.1.8 Требованиякадап

тацисме тапользования

Этподтраздолженл

:

а) Определятьтребоваклюбымданнымилипоследоватеияинициализации,которыеьностям

являются

специфическдляданногоместа,зад,илрежчиработыминапример(ма,значения

сетки,пределы

безопасности ит.д.);

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

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

5.Функции2.2изделияПодраздел( 2.2

SRS)

Этподразделт

SRS

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

которыебудетвыполнять

программное обеспечение.Например,

SRS дляпрограмбухгалтерскогоучетаможетыиспользоватьэту

часть,чтобы

выделить такиефункции,каксопровождениесчетовклиента

,созданиеотчётов

о движении

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

каждойизэтихфункций.

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

спецификацииболеевыс

окогоуровесли( существуетня),которыйназначаетотдельныефункции

програмизделию.За,мчтовнетьтецеляхобмуясностиспечения:

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

понятным

заказчикулюбомучелове

ку,читающдокументвпервые. му

б) Могутбытьиспользованытекстовыеилиграфичесметоды,чтобыпорказиеличныеать

функции

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

апросто

показылогичсвязимаетскиежду

переменными.

Версияпереводаот8

сентября2014г.

20