ser de lagnteria Stare
1) Msi Rees de Stat Sot
2.1. Se activa larefrigeracién
2.2. Se activa la he de alarma
43. Cuando la temperatura desciende por debajo de 125°C
4.1, Se desconecta la refrigeracién
43.2, Se desconecta la luz de alarma
9.63. Comprobar Ia consistencia de los distintos modelos del dominio
Por iltimo, ya se ha comentado en repetidas ocasiones que las transiciones del DTE equivalen a la
invocacidn de uno 0 varios procesos, los cuales modifican una o varias entidades, las cuales son las
{que motivan el cambio de estado, Por consiguiente, a disponibilidad de un DTE" permite usar éste
para comprobar Ia correccién y consistencia conjunta del DFD, ER y DTE, identificando de este
‘modo posibles errres en la comprensién del dominio.
La correecién y consistencia de los modelos DFD, ER y DTE se comprueba de un modo similar alo
indicado en la Figura 9. Coneretamente, debe comprobarse si:
+ Cada estado del DTE puede deseribirse mediante alguna combinacién de los valores de los
atributos de las entidades” del dominio™.
© Cada transicién puede asociarse a un conjunto de procesos, los cuales actian sobre las
‘entidades del dominio, cambiando los valores de algunos aributos. Los nuevos valores de
los atributos deben ser aquellos que definen el estado actual del DTE.
Finalmente, debe indicarse que la existencia de un FTE no impide en modo alguno realizar la
ccomprobacién de correccién y consistencia entre DFD y ER, descritaen la UNIDAD 8,
2 Cuaiquier DTE pemnite 19 tndiado aqu,independientemente de si models las transformaciones que
acontecen sobre ua entidd oI interaceinusuariosistma
JE'qungu nose ba indcado a Io larg dele presente UNIDAD, es convenente explicit en ese punto que,
aalemds de as eniades, ambien deben consierase Iss relaciones.
5 Como ya se ha indcado anerormentc, pueden exis algunes esos en lo que un estado nose defina en
términos de los atrbuts de una entidad, aunque ello noes fecuente
“Riana hal Regi Me de lagna el Stare
6} Not Reqs Ge Stes Stee
‘Figura 9. Relacin entre DFD, ER y DTE.
9.7. Otras caracterst
Las seociones anteriores se han dedicado a describir el DTE, dejando pendiente, hasta este
momento, fa descripcién del otro modelo paradigmatico orientado a estados mencionado en la
seccidn 93: El Statechar,
Los Statechart se han uilizdo_profusamente en ingenieria del software para mejorar las
capacidades de expresién de los DTE. Ademas, actualmente este tipo de modelo es muy popular ya
{que es la notacion utilizada en UML,
Desde el punto de vista sintictico, los Statecharts son equivalentes a diagramas de transicién de
cestados, con la tnics diferencia de que los estados se diagraman como recténgulos redondeados. Sin
‘embargo, el Statechart propone algunos constructores especificos para algunas situaciones de muy
‘complicada expresin en los diagramas de transicibn de estados". Estos son los siguientes:
1, Ortogonalidad, o concurrencia. En algunas ocasiones, pueden ocurrir mas de una cosa de
inter en el dominio al mismo tiempo. Por ejemplo, en la Figura 7 puede observarse que
cuando el homo supera los 190°C, se activa tanto Ia refigeracién como la luz de alarma,
(Otro ejemplo podria ser of estado del motor y de las Iuces de un vehfculo. Es evidente que
el motor puede estar encendido o apagado independientemente de si las luces estin
‘encendidas 0 apagadas,
Los DTE y lo Statecart pose la misma capacidad expresva, esto es, ambos pueden modelar las mismas
sitvaiones. Por consiguente, los consructoes () reglas sintcticas) que se indicarin a continuacion no
‘amplian ls capacidades expresivas del DTE; simplemente, permitenexpresar certs dominios con mayer
Telia
“Rigs hal Regios Master de Ingenieria del Software
Médulo Il — Requisitos de Sistemas Software
‘Cuando ello ccurre, se dioe que dichos estados “independientes” son ortogonales. Definir
cexplcitamente la ortogonalidad es importante en los Statechart, porque habitualmente se
considera que, en un modelo, sélo un estado puede estar activo al mismo tiempo”. De este
‘modo, se indica explicitamente qué estados podrin estar activos al mismo.
Desde el punto de vista de la diagramacién, los estados ortogonales se describen dentro de
tun euadrado con bordes redondeados™, separados por una linea punteada, tal y como se
‘muestra en la Figura 10,
mene
Figura 10, Statechart que corige et ejemplo mostrado en la seccién 9.6
2. Profundidad: Los Statechars pueden agrupar en un “macroestado” varios sub-estados, de
‘un modo similar a lo que el DFD realiza con los subprocesos. Esta capacidad es util en dos
situaciones: para precisar el funcionamiento de algunos dominios, y para modelar dominios
{que posean modos”.
2.1.8! primero de los casos se corresponde con aquellos dominios en los euales los estados
pueden definirse a distintosniveles de abstraccién, Por ejemplo, en un coche se podrian
fistinguir el estado “parado” y el estado “en marcha’. Sin embargo, el estado “en
marcha” podria precisarse més, identifieado los sub-estados “primera marcha”,
® Dicho de otro modo: El DTE mostrado en a Figura 7s incorecto porque dos estados estén actvos
siempre al mismo tiempo refrigeracién destctivada”y “luz de alarma desactivaa", asi como “reftigeracion
{tctvada y "luz dealarma actveda”), Se aa, simplemente, de una reglasintictca del DTE.
3 Dieho“euadrado” es, realmente, un estado especial que “contiene” als estas interno ortogoales. sta
«5 Inrazin por la cual dicho extado recibe un nome. Véas a esquina superior izquerda de It Figura 10.
EL IEEE-St-830-1998 distingue un tipo de organizacion de su seccién 3 denominado “por mods. Ello se
correspondeesenciaimente con lo indieado aga. Véase la UNIDAD 10 para mis deals,
‘eras Anns Region 5 Master de Ingenieria del Software
©} “Miédulo I~ Requisitos de Sistemas Software
2.2.B1 segundo de los easos se eorresponde con dominios que posean modos. Un modo es
tuna situacién del dominio que produce que cieras situaciones y acciones sean
admisibles, y otras no. Por ejemplo, en el modo “a prueba de fallos", Windows no
permite instalar controladores, mientras que en el modo “normal” si. En.este tipo de
‘dominios, cada modo puede modelarse como un macro-estado, y el funcionamiento
‘dentro de cada modo como un conjunto de sub-estados.
Un Sutechart con profundidad se diagrama como se muestra en Ia Figura 11. Los sub-
estados se dibyjan dentro de los macroestados, y se conectan Hbremente mediante
tramsiciones. Es perfectamente posible conectar “mediante. transiciones. sub-stados
pertnecientes al mismo macro-estado, como los sub-estados perenecentes a distintos sub-
tstados.
Es perectamentevélido, tal y como indica Ia Figura 11, que sagan transiciones de los
macro-stados. Ello significa que dicha tansicién puede activarse desde cualquier sub-
estado del macro-stado. Por ejemplo, en la Figura 11 existe una tansicin “prar™ desde el,
tmacroestado "en marcha” al estado “parado". Ello significa que dicha wansicin “para”
podria ocuri desde los estados “primera marcha”, “Segunda marcha”, ee
"También es vilido que entren trnsiciones en un macro-estado. En este caso, debe
centenderse que se activa la tansicion por defecto dentro del macte-stado, Por ejemplo, en
Ta Figura 11 a ansiiGn “arrancar” ativara el sub-stado “primera marcha".
Figura 11. Statechart con macro-stados
Finalmente, en los Statecharts es posible modelar lo que se conoce como “transiciones
condicionales”. Como su nombre indica, una transicién condicional es una transicién que puede Master de Ingenieria del Software
CO} “Médulo Il ~ Requisitos de Sistemas Software
realizarse ono, Las transiciones condicionales se especifican mediante guardas, esto es, condiciones
{que anteceden a ls eventos.
Por ejemplo, en un coche, para poner la marcha atrs, es necesario que el coche esté parado, Esta
‘auarda, 0 condicién para el cambio desde el estado “en marcha” al estado “marcha atris” se
indicaria entre corchetes, antecediendo al evento correspondiente, tal y como se indica la Figura 12.
Existen distntos formalismos para especificar las guardas, aunque el texto en lenguaje natural
acostumbra a ser suficiente durante el andlisis. Por ello, no se profundizara més en este particular.
. Primera marcha = ‘Sequnin marcha
(et par
Figura 12. Ejemplo de una guarda
9.8, Proceso de desarrollo de los modelos orientados a datos/objetos
‘Tal y como se ha indicado en la soccién 9.5, los DTE y Statecharts se construyen tanto a partir de
Jos requsitos, expresados por estimulo, como a partir de descripciones del dominio.
En el primero de los casos, la construccién del DTE es directa: Sélo es nevesario transcribir la
informacién contenida en los requsitos a un modelo, tal y como se realizé en la seccién 9.53.
En el segundo de los casos, el procedimiento para eonstrur el DTE y Statechart es ad-hoc,
Hiabitualmente, dichos modelos se construyen“tirando del hilo”. Este informal método consiste en
1, Identificar las posiblessituacionesiniiales del dominio (tales como el “coche parado” o el
“horno spagado”), as cuales proporcionan los estadosiniciales.
2, Identificar las posibles transiciones de salida desde los estadosinicales, lo cual eonducir a
nuevos estado
3. Actuar del mismo modo que en (2) partir de los nuevos estados identificados, ya sea
creando nuevos estados, ya sea creando transiciones a estados preexistentes.
“ana Rar Reon 7 Master de Ingenieria del Software
‘O) Midulo II — Requisitos de Sistemas Software
{Al igual que con el DFD y ER, no se puede estudiar ningin dominio por tiempo indefinide. Por
consiguiente, el analista deberi determina cuindo dar por finalizada la construccién del DTE 0
Statechar. UNIVERSIDAD
POLITECNICA DE
MADRID
FACULTAD DE INFORMATICA
ESPECIFICACION DE REQUISITOS
Profesora: Almudena Sierra
XX PROMOCION
2006 Master de Ingenieria del Software
Médulo II — Requisitos de Sistemas Software
UNIDAD 10
DOCUMENTACION DE REQUISITOS
10, DOCUMENTACION DF REQUISITOS.
10.1. CONTENIDO DE LA ESPECIFICACION DE REQUISITOS.
10.2. ELDOCUMENTO DE REQUISITOS. :
10.2.1. {COMO ORGANIZAR LOS REQUISITOS?
10.2.2. {CUAL ESLA ESTRUCTURA DE UNA ERS'
10.23. HERRAMIENTAS DE GESTION DE REQUISITOS 0s.
103. CARACTERISTICAS DESEABLES DE LA ESPECIFICACION
DE REQUISHTOS. rf
10.4. ESPECTFICACION DE REQUISITOS NO FUNCIONAL'S iL
10.4.1. PORTABILIDAD nL
10.42, FLABILIAD (RELIABILITY) 2
10.43. EFICIENCIA “2
10.4.4. HUMAN ENGINEERING, “3
10.4.5. VERIFICABILIDAD, COMPRENSI
[MODIFICABILIDAD . - 1B
10.5. ESPECIFICACION FORMAL, 13
10.5.1. COSTEDELA ESPECIFICACION FORMAL 4
10.5.2. ENFOQUES PARA LA ESPECIFICACION FORMAL sono 15
10.53. ESPECIFICACION ALGEBRAICA 15
10.54, ESPECIFICACION BASADA EN MODELOS. LENGUAIE 217
En la Figura 1 recordamos el proceso de Ia ingenieria de requisites. Vemos cémo después de
negociar los requisitos es necesario documentarlos. Obtenemos entonces un borrador que es
necesurio validar, para corregir los errores que st hayan podido introducir o detectar lagunas de
informacién. Esto nos llevari a nuevas iteraciones en el proceso, Se obtendri finalmente la
especificacién de requisits software ya validada, Este documento, como ilustra la figura se
Pardmetro gonérico———
sort
Imports < LISTA DE NOMBRE DE ESPECIFICACION>
Descripcin informal del tipo y sus operaciones
‘Signatures de las operaciones del tipo
‘Axiomas que s0 definen sobre las operaciones |
Figura 6 Bstructura de una especificacion de interfaces.
Los componentes de la espeificacién son los siguientes:
Introduceién. Define el nombre del tipo y declara otras especficaciones que se san,
Deseripcién, Deseribe informalmente las operaciones del tipo.
Signatur. Define la sintaxs de las operaciones. La interfazy sus pardmetros.
‘Axiomas. Define la seméntica de las operaciones mediante la definicién de axiomas que
caracterizan su comportamiento
En la Figura 7 se muestra un ejemplo de especificacién formal algebraica para una lista de enteros
UST ( Elem )
sorttist
ImporsiNTEGER
[Deinas a it where laments ae addod altho ond and removed
[om the ron.The operaons are Create wich bangs an omy list
nto exstenes Cong whic creates a new ist wh an added member
Length, which ovaluates be Ii size, Head, which evaluates the Font
Jeomont of hot, and Tal, which creates it by roving the had
om tsinput lst Undefined represonts an undefined valve of ype Ele}
(rato > Ust
Gone (List Elem) List
Head (Uist) elem
Leng (ist “>teteger
Tal (Ls!) st
inedexception{ empty ist)
= Croatethenv elseHead (L)
Length (L) +1
“a (Create) = Greate
‘(Gone (t, v) == Create then reatoelse Cons (Bil (L),
Figura 7. Ejemplo de definickin de una lista Master de Ingenieria del Software
‘Médulo II - Requisitos de Sistemas Software
10.5.4, Rspecificacién basada en modelos. Lenguaje Z
La especificacin besada en modelos permite Ia especificacién del comportamiento del sistema, La
cspecificacin del sistema se expresa como un modelo de estados del sistema. Las operaciones se
cspecifican definiendo cémo afectan al estado del sistema,
Un ejemplo de lenguaje de especificacién formal basado en modelos es Z. Esti basado en l6gica
bivaluaday teoria de conjuntos (hay variantes), Las operaciones se especfican mediante la relseién
centrada-salida (cémo se realiza la conversion es una caja negra). En la Figura 8 se muestra un
tjemplo de Ia funcién exponencial. Puede verse como se expresa mediante la entrada y Ia sada,
ppero como se realice el cileulo es una caja negra. De hecho hay varias formas, por ejemplo,
secuencialo recursivo.
in? Expononcial ot
inzzo our=a
Figura 8, Funcin exponencil
Las especificaciones se presentan como texto informal complementado con descripeiones formales
(Givididas en esquemas). Los esquemas introducen variables de estado y definen restricciones y
‘operaciones en el estado. En la Figura 9 se muestra la estructura de un esquema de Z para defini la
fncidn exponencial. La signatura define las entidades que constituyen el estado del sistema, Et
predicado establove las condiciones que siempre deben cumplirse para esas entidades.
Nombre del esquerna
‘Signatura del esque
co decaracén Pragicado del esquoma
Figura 9, Eaquema de Z para define la function exponencial,
Si un esquema define una operacién, como por ejemplo, la funcién exponencial, el predicado
testablece las pre y postcondiciones. La diferencia entre pre y postcondiciones define la accion
‘especificada en el esquema de operacin. ‘Master de Ingenieria del Software
Midulo Il - Requisitos de Sistemas Software
Sobre los esquemas se definen operaciones como la composicién de esquemas, renombramiento y
‘cultamiento, Estas operaciones permiten manipular los esquemas y definir esquemas mis
complejo
‘Veamos un ejemplo de un directorio de teléfonos. Supongamos los siguientes requisitos:
‘Una extensién puede estar compartida
‘© Una persona puede tener mis de una extension
‘© Sedeben proporcionar las siguientes operaciones:
= Alta de una asociacion entre una persona y una extensin
= Buscar la extensin de una persona
= Personas que responden a una extensin
= Pliminar una entrada del directorio,
En la Figura 10 se puede ver dos esquemas que representa un estado antes (members) y después
(members’) de una transformacion.
Phones
rmombers:P Person
fslephones: Peron <> Phone
om tolophenes & members
(Phone
Members’: P Person
Telephones: Porson <> Phone
om telephones’ & members!
Figura 10, Esquemas ante y después de hacer
operaciin.
En la Figura 11 se muestra un esquema que define Ja operacin de insertar una extensién para una
persona,
Regen oe Master de Ingenieria del Software
Médulo TI — Requisitos de Sistemas Software
-——Adtnty
members, members P Person
{elophones telephones’ Peron <> Phone
name? Person|
rewnumber?: Prone
dom ttphones = members
om ttphones & members!
name? © member
ame? |—newnumbor? « tlophones
telephone’ =tlophones (name? t= nownubor?}
members’ = members
11, Eaquema que describe la operacion de insertar
5 extension, “Anta Dosummiasion e Rage
‘Master de Ingenieria del Software
‘Médulo II — Requisitos de Sistemas Software
ANEXO
ALA UNIDAD 10 IEEE Std 630-1998
Resaont
rece sweat)
IEEE Recommended Practice for
Software Requirements
Specifications
Spenser
‘Software Engineering Standards Committee
ofthe
IEEE Computer Society
Approved 25 re 1988
IEEE-SA Standards Board
Abstract: The content and qualtios of good software requirements specication (SRS) are de-
scribed and several sample SRS outings aro presented. This recommended practice is aimed at
pectvng requirements a softwar tobe developed but also can be appie to assist in he seec-
tion of inhouse and commerdal sofware products. Gulcalines for compliance with IEEEIEIA
12207.1-1997 ae aso provide.
Keywords: conract, customer, protolyping, software requirements specication, suppl, system
requirements specications
‘The nt of Gaol ana Sconce Ergo ie
3 Eaten Seet Now rk NY Tool? 2304 USA
Cony 1998 nto Earl ar Eats Engnoes We
SIG cent Abad So Present Unas Ses oer
oprah ution may be repeded in any orm, nan cron ena atm ear, wou he pro
‘win pemeton ene pus TREE Standards documents are developed within th IEEE Societies and the Standards Coontinat-
ing Commies ofthe IEEE Stndar Association (IEEE-SA) Sundar Board. Meshes of the
‘commits serve voluntarily and without compensation. They ae not necessarily members ofthe
Tt. The standards developed within IEEE represents consesus ofthe broad expense onthe
nbjec within the Insite a wel a those avis ouse of TEEE that have expressed an ie
‘tin patcptig inthe development ofthe stands
‘Ute ofan TEEE Standard is wholy voluntary. Te existence ofan TEEE Standard des nt imply
that there ace no cer ways o proce, text, ears, purchase, markt, oe provide her goods sn
services reltd to the scoe ofthe IEEE Standard. Furthermore, the viewpoint expressed at he
‘ine a tundar is approved and issued is subject to change brow abou through developments in
{he tat of he aan comment received om ses of the stand. Every IEEE Standards sb
{ete to review a least every five yeas for eision or rafimation. When document is mere
than five yeas ld and as ot been reamed, st reasonable wo conclode that it cones,
though il of some vale, do ct wholly rec the presen rate of the ar. Uer are cautioned 0
‘hock to determine at they have he atest eon of any TEEE Standard.
Comment for revision of IEEE Standards are welcome from ay intrested party, regardless of
‘membership aflition with TEEE. Suggestions for changes document shoul bel tbe form of
‘proposed change of ext togsher with appropriate supporiag eomments.
Inception: Ocasonlly questions may arse eguding the meaning of prions of standards as
they relate to speiieappliutons, Whence ned for interpretations is rough the atention of
TERE, the Instat wl nin ation to prepare appropiate sponses. Since IEEE Staal rp-
resent a conentur of ll concemed lees it portant 10 ensue that an interpretation has
tho receved the copcumeace fa blanceof interests. Fortis reson, IEEE and the member of ts
‘ovites and Standen Coordinating Comaitees are nt able provide an instat response to
imerpreation requests except in thse cass Where the mater his previous} received formal
‘onsen,
‘Comets on tana nd requests for ntergrettions should be adresse to
‘Secretary, IFEE-SA Standads Board
4465 Hoes Lane
0. Box 1331
Piscataway, NIOBBSS-1331
USA
‘Note: Atenon © called io he possibly Wat plementation of is standard may
sequiteuse of subject mater covered by patent rights. By publiation ofthis standard,
‘no postion i taken with respect othe existence or vay of ny patent rights in
‘eanection thih. The TEE shall not be responsible fr idewtiying patents for
‘which license may be eqired by an IEEE standard oe for conducting quis at
‘heel validity or scope of those patents hat are brought ots atention,
Authorization to photacopy portions of any fvidaal stndard for internal or personal ws is
rated ty the Inte of Eleral and Blecronics Engineer, r., prvided that the approprie
{ee is pid to Copyright Clearance Center To amange fr payment of licensing fe, please coat
(Copyright Clearance Cese,Cusiomer Service, 229 Rosewood Drive, Danvers, MA 01923 USA;
(78) 750-8400, Pension to photocopy potions of any mdiidalsudard for educational clase
oom uk ea alo Boobie dough the Copyright Clearance Cente. Introduction
(isinsoion i op of EEE St 0-198, IEEE Recommend Practice fr Software Requlemets Speih-
Some)
“This recommended practice describes recommended approaches forthe specication of wofware require
tment Is based om 4 mode in whic thereat ofthe software quirement specifeaion proces Is an
‘nambigbos sad complete speciation document, H shoud elp
4) Softwar customer to accurately sre what they wish 1 bt
1) Softwar suppliers to understand excl what he cstomer wants
©) Indivianto accomplih the flloning oa
1) Develop a standard software rquzements specification (SRS) tine for their own organiza
2) Define the format and content of thee specifi sotware requirement specications;
3) Develop aditonl local supporting items sch as an SRS quality checklist, or an SRS wrte's
tandbooke
‘othe estes, suppliers, and oer indivi» god SRS shoul provide several specific benefits, soch
the allowing
— Establish the basis for agreement berween the customers and the supplies on what the software
produc iso do, The complete desrpton of he frcions to be performed by the sofware specified
nthe SRS wil ass the potenl users 0 determin fhe software specified ees their needs or
ow the software ms be adie to mest hie neds
= Reduce the development efor. The preparation ofthe SRS forces the various concered groups in
the cistomer’ organization to conser rigoosly ll ofthe requirements before design bens and
reduces ne redesign, recoding, and vtesing. Careful review ofthe requirement inthe SRS can
revel ossion, misunderstanding, and inconsistencies ery in he development cycle when thee
‘problems az easier 0 cone.
= Provdea bass for estimating costs and schedales, The description ofthe prodet be developed as
riven nthe SRS realistic ass or estimating projet cost and can be wed obtain approval or
Bids or price estimates,
— Provide baseline fr valldation and verifctin. Orgaiztions can develop ther validation and
‘eran plane mich more produsivey om a good SRS. AS apart ofthe development contrat,
the SRS provides «baseline gaa which compliance canbe mare
= Facilitate ansjer Toe SRS make it eset vansfer the software prod to new uses or ne
‘ruchines Chstomers ths find ete to transfer he software to ober pats of heir ganization,
‘supplies Gnd icsier o transit to new customer
= Sere as a bass for enhancement. Bacase the SRS discusses the product but nthe project that
developed he SRS serves a ats for ater enbuncemen ofthe finished product. The SRS may
need o be alr, batt does prove «foundation for continued production calato,
“The readers ofthis document are refered Annex B oe guidlines for using this recommended practice to
soe the requirements of(EEE/EIA 1220711997, IEEEJEIA Guide — Industry Implementation of ISOTEC
12207 1985, Standard for laformaton Technology — Software ile cele processes Life cycle daa,
Copy 808 EEE At hes reed. a Participants
“This recommended practice was prepared by the Life yele Dats Harmonization Working Group othe Slt
‘ware Engineting Standards Commitee ofthe IEEE Computer Society, At the ime this eoommended pac
the was approved, the working group consisted ofthe folowing members
‘Leonard 1. Tripp, Chair
avant Bye eas Lawrence Tero
Pali cor Dav ator Toca sami
ery Devine Bayle ‘Noman# Scmdeiod
Enarace Jeno Dev Sie
ay ier Fane ‘ime Neen Perera)
Inne Maser Dome Kline Peer er
Muay oma Na
“Te following persons were one allsng commits
Sy Davis A Gatton Inde Pa
‘Render K.Atcinon Jen Hag ‘ie Foac
Nida hago shunt Rr roe
Rete any ose Hey wens Pty
[ita Heer ese Kem rack
Hondo ‘wit Hey ‘vee Daly
Rid ated Hen ‘eng
MA ties Mae ech Poe Sage
Sis beiogs Matheney fide ene
Jeane Dee Homo Sepa Sec
Satie Res Soom ore Ham Sect
Manel Coe Neer Hang Ded Soh
Samer Coro’ Geo ten Tie Seinen
Eco Cars EV eee so Se
mcs Coca ‘ian ne Dane Siew
Kee Seon amie ata Singer
‘Toate. Ron’ Reset Sinus Sy
Syn Cerne oath 8 eer iver M Sh
cas Rane eee Neate Spe
Vegi be Groen eaves ask ary Mt See
WW Gen Cres Shaye Koen ‘ite Serene
Pl Gat mane ota Semis Sve
Geen Fach ‘nace LicsSpaone
SES, bene emi Eee Sta Sey
Soaen be ‘itn Ley Sein Boe Sey
Bowen ee ita Le ie Bove Ss
Roy betene Sime tec ‘im Tet
Saree Do Diora Rel Tyr
Eryn Dow Soentont Bosker Tamar
Gat rar Drags Serie ‘rich Tue
Ser ages Dar cde Umovie
Geet Reoidaane Glam veut
tote ater Mana Giovee
eae Pay “oom Neches Dad Wain
iytooer Pete Mcny ‘iam a
Eley Fite ‘Crk eNten Join Wale
SnaPesal Some Westy CEM: Sv renin
Bhar fe Mica! ‘Sora, Whnse
Regs Ba ‘ie iter Pawo
Aa Gara CoM Mate foinwer
tyne Fe Sis Woe ite Seok
Sita om Ghee Foran Sines oa
‘in Gran Se Sea Olan ie imeran
thom fer al
w Comyn © 1980 EEE, Ah sae, ‘When the TEEE-SA Standards Bord approved this recommended practice on 25 June 1998, it had the fol-
owing membership:
Richard J Holloman, Chair Donald. Heirman, Vice Chair
Judith Gorman, Secretary
Sih K. Aggarwal ea cum Brice Mec
hye R Camp Sim. ous Fangs Po
Samet Cae Lovet G Jonson Home Peener
Gay 8 Enpmann Keb eae (Geld Pesce
fanad Epain EGA Kime Som Posey
Jay Foe" Jongh. Roepings™ (ay Sen
Tame Gay ‘Sept Canter Har Weick
uten D.Gaon Iie Lape onal WZpee
Dowait Laetey
Member Bers
ae Zee
{BEE Stands Proj tor
ont © 198 EEE. ge sere ¥ Contents
1. Overview. . - '
Lt Scope = : seb
2, Refer nnn Specs acer mere}
a |
4. Conseraton for producing 0d SRS.
4 Natt of the SRS = ——]
442. nvironment ofthe SRS 3
443. Chances of good RS. aot
13 ont preparation ofthe SRS. et
445 ‘SRS evohtion - 8
{86 Prototyping ———= 9
{67 Emboldig design inthe SRS nnn
443. Embedding pret requirements inthe SRS — 0
5. Thepas ofan SRS nnn co 10
SA Iavoduction (Section ofthe SRS) es scoessrnpeet tL
52. Overall description (Section 2 ofthe SRS) a 2
53. Specific requirement (Secon 3 of he SRS) : 15
54, Supporing information ee x 0
Annex A. Gefrmative) SRS templates a
[Annex B_(nformative) Guielines for compliance With TEEEIETA 12207-1997 csnnscnnnsie 7
wi pig 188 IEEE tights sen, IEEE Recommended Practice for
Software Requirements
Specifications
1. Overview
“This recommended practice describes recommended approaches forthe speciation of software equ
‘meat Iti vied int ive clases. Clute | expla the scope of his commended racic. Clause 2
Tiss the references mad to ier standude laut 3 provides defnitins of specie ems used Clause 4
provides background information fr writing a god SRS. Clause 5 cscases cach ofthe essential pars of|
EEVSRS. This recommended practic also as two anexes one which provides ates format temps,
{done whch provides guidlines for compliance with IEEBIEIA 122071-1997.
1.1 Scope
‘This isa recommended practice for wring software requirements specications. I describes the content
nd quaies ofa good vtware requirement pecan SRS) ad presents Sever sample SRS ouines
“This recommended paces sme a speiving requirements of software o be developed bu alto canbe
plied toast nthe selection of inhouse and commercial software reduc, However, application to
‘Seady-develped software could be coumerproductive.
‘When software is embeded in sme large system, sch a medial equipment the sss beyond those
‘Mend inthis recommensed practice may hae toe aresse,
“This recommended practice describes the process of ceatng a product andthe content ofthe produc. The
proc san SRS, This recommended pace cn be used creat sch an SRS directly or ean be sed as
$ model fora moe specie sandr,
“This commended practice doesnot deny any specie method, nomenclature, ooo for preps an
SRS.
oni 808 EEE Adiga eer 1 S000 EEE RECOMMENDED PRACTICE FOR
2. References
“This secommende practice shal used in conjunction with he following publications.
ASTM E1340-96, Standard Guide for Rapid Prototyping of Compuurizd Systems!
IEE Sw 610 12-190, IEEE Standard Glossary of Software Engineering Terminology?
IEEE Std 750-1998, IEEE Standard for Software Quality Assurance Pas
IEE Std 7301-1995, IEEE Guide for Software Quality Assurance Planing,
IEEE Sud 828-1998, IEEE Standard for Software Contiguation Management Plans?
TEE Su 9821-1988, IEEE Standard Dictionary of Measure to Produce Reliable Software
IEEE Std 9822-1988 IEEE Gude forthe Use of IEEE Standard Dictionary of Mesures to Produce Rli-
le Software.
TERE Su! 1002-1987 (Reaff 1992), IBEE Standard Taxonomy fr Software Enginerng Standards
IEEE $id 1012-1998 IEE Standard for Software Verification and Validation,
TEE Sid 1012-198, IEEE Standard fr Software Verfcation and Validation: Content Map to IEEBIEUA
raawr-1991
[ERE Sud 1016-1998, IEEE Reoommensed Pracice fr Software Design Descriptions *
IEEE Std 1028-1997, IEEE Standard for Software Reviews
[BEE Sid 10121987 (Real 1993), IBEE Guide wo Software Configuration Management,
[GEE P10S4/D2 1, Draft Standard for Software Project Management Pans, dated 5 Aust 1998 °
[GEE Sud 1088-1998, IEEE Standard for Software Proce Mangement Plans: Content Map to TEEEVEIA
roamr-1977
[BEE Sud 10741997, IEEE Standard fr Developing Software Life Cle Processes.
[EEE Su 1283, 1998 on, IEEE Guide for Developing System Requizements Specifications ®
‘Spe we em een Sey Tin Mh a a, Cat
{Te cate oa frm ees of estan ni Eine AS Hot La PO Bon 31, Fat,
rants 31 098
petra pis Snes su however a ne LE ipa pastrami wa BO
Siar Tlie tmaown oy a ee
Fatieonty
Sard St EM tte re i itt
lamas Em es ie dt cnt eto
=e
2 Copy © 1098 HE, A ose ‘SOFTWARE REQUIREMENTS SPECIFICATIONS Prod
3. Definitions
In general the desintons of terms sed this recommend praciee conform to the dts provided a
IEEE Std 61012-1990, The deinions below ae key terms as they ae used in his recommended practice.
2.1 contract: A legally binding document agreed upon by te eusome and supple. This includes the e-
ical and orgaszational quirements cos and seule fra product. A comet may aso comin inor-
‘al br usefl information sch as the commitments or expectations ofthe pats involved.
542 customer: The perso, ee persons, who pay fr the product and usualy (bt no necessarily) dei he
Toquirments, Inthe context ofthis recommended prcice the customer snd the supplier may be members of
the same organization.
233 supplier: The person, or prions who produce product fora customer. In the context of his recom
Imende pret, the ester and the super may be members ofthe same organization
| user: The person, or erons, who operate a ntrct dry with the product. The users) and the
‘castomer) ae fen nthe same person).
4, Considerations for producing a good SRS
“This clause provides background infomation that shoul! be considered when writing an SRS. This inches
the following:
2) Nae ofthe SRS;
1) Environment of the SRS;
©) Charceitick of good SRS:
(©) Join poparion of te SRS;
1) SRS evolution:
1 Prootping
1) Embedling design in the SRS:
1) Embeding pret ruirements inthe SRS.
4.1 Nature of the SRS.
‘The SRS isa specication fora pacar software produ, program, o st of programs that performs
cerain function ina specie enviroment The SRS maybe wien by one of moe epresentatves of te
“ipl, one or more eprescltives ofthe cstomer of by both Subclause 4.4 recommends both.
‘The basi issues that he SRS writes) shall adress re the lowing
8) Functional, What ithe software suppose odo
>) External nerfs How docs he software iret with poople the system's hava, other hard
wate and oe software?
©) Performance. What ste speed, avail, response te, rcovery tine of various software une-
8) Anributes What se he ponability,corecines,msitsinability, security, ee comiderations?
2) Design constrains imposed on an implementation. eter any required standards in effet iple-
mentation language, polices for dtabase inert, resource limi, operating envionment) et?
‘The SRS wits) shoul! wo placing ithe design or project requiements inthe SRS.
Forreommenel content ofan SRS sce Clase 5
Cop 108 EEE Avro 3 42 Environment of the SRS.
kis imprint to conser the pat thatthe SRS plays inthe tot project pla, which is defied in IEEE Std
{610.12 1990. Th softwar may contin essen al the funtonlty ofthe projector it may be pa of a
Tasgr syrem. Inthe Iter cat pally there wil be an SRS that wl tte the intcacer between the
sytem aod is software portion, and will lace exteroal performance aod functionality requirement pon
{the software prion. OF couse the SRS shoud then agree with and expand ypn hee sytem requirements
[IEEE Su 107-1997 deserts the steps inthe software fe cele an the aplicable fps foreach sep.
ter sandars, such as those tse in Clause 2 relate o ober pars ofthe software ie yee and v0 ay
complement software requiements,
Since the SRS bas & specific role o payin the software development process, te SRS wets) should be
‘arefl noo go beyood the Bounds tha le. This means the SRS
18) Should cory define al ofthe software requirements A software requirement may exist bees
tothe nate ofthe ak be solved or Beate of special characte af the poe.
1) Shoald not describe any desig o implementation dt. These shouldbe described in the design
age ofthe projet
©) Should not impose atonal contains on the sofware. These ae properly specified in other
ocumens soc sa software guaity esrurance plan,
‘Therefore, a properly writen SRS limits the range of valid designs, but doesnot specify any particular
esi
43 Characteristics of a good SRS
‘An SRS shoul be
2) Cone
©) Unambiguous;
©) Complee;
) Comistent,
©) Ranke for mponance andlor ai
5 Wesabe,
2) Moditabie:
1h) Traceable
43:1 Correct
An SRS is comet if and only if very requirement sated teen sone that the software shall mee,
‘There is no oo or procedure that ensues comoctos. The SRS shouldbe compared with any applicable
sapere specication, such asa system reuiementsspecifaton, with eter projet documentation, and
‘with ter applicable standards, ensure thar agrees. Alieraiely the cusomer or user can determine if
‘he SRS conc ees the actual needs, Traceability makes this procedure ease apd less prove to eer
eed)
43.2 Unambiguous
‘An SRS is unambiguous if, and oly if, ver requirement stated therein has nly one interpretation. AS 2
‘minimum his requis that each characters ofthe tal prodct be deseribed using a single unique te,
4 Cony 186 EE hts econ, ‘SOFTWARE REQUIREMENTS SPECFICATONS sie
Incases where a een sod patil conte could have mile meanings the term shuld inched
ina glossary where its meaning is made more specific.
[An SRS isan important pat ofthe requirements process ofthe software if cycle and is use indesign,
Implementation, project montrng vesifeason and validation, and in tining a described in TEEE Sid
10741997, Te SRS shouldbe unambiguous both to Uhose who reat and to thse who seit. However,
"tet groups cen donot ave the sume background and therefore do nt todo describe oftware equi
mens the some way. Representations hat improve the requirements specification fr te developer may be
ourterrodictive i at they diminish undertanling ote user and Vice vers
Subclmses 43.2.1 through 4323 recommend how to avoid big,
43.2.1 Natural language pitas
Reuirements are often writen in natural language (Engst. Natural language is inherently ambi
tus A nfral language SRS should te reviewed by a independent pay t deny ambiguous we of
Tangy so htt canbe conected.
43.2.2 Requirements specification languages
‘One way oad the ambiguity inherent in natural language is wo wee the SRS ina patclar requirements
specication language. Rs language prcesors atomatically detect many lexical, syntactic, and semantic
(One dsadvaniage inthe us of such languages ihe lng fie requir to erm them. Also, my non
tecnica ses find them usinteligible: Merve, these languages tend wo be beter at expressing certain
types of requemeats and adessing cern types of systems. Thos, thy may influence the requireent in
be ways.
43.2.3 Representation tools
In gener, reureents methods and languages andthe tals hat supper them fall it three genera ate
ties objec, process, and behavior. Objet oriented approaches organize the requirements in ems of
Feal-world objets their ates, andthe services performed by those objets. Processus approaches
Cnpnie the reuiements ito hierarchies of funetions that communicate via data fows. Behavioral
{ppoaches deecbe extemal behavior ofthe sysiom in tems of some abstract notin (uch as pecate
Cle), material uncon, or state machines.
“The degree to which ssh ols end methods may be wef in preparing an SRS depends upon the size and
_compleity ofthe progran. No aemg is made here wo ese or endorse ny partic to
When asng any ofthese spproaches tebe to tain the ar Ianguage dscripons. That way, custom:
cersunfoiiar hho eons can still derstand the SRS.
4.3.3 Complete
‘An SRS is competi nd ony if tinelades the fllowing elements
8) Al siguiicant requirements, whether selting 1 fantonaliy, performance, design contain
‘ibe, or esteral intrfacee Tn partcalr any exer reqements pone by assem pee
‘eaion shoul he aeknowledged nd rested.
ep © 1990 EEE Ar eon s ieee
$0056 IEEE RECOMMENDED PRACTICE FOR
1) Deion of the reponse of the software to all ealzable cases of inpt daa in al realizable
lasses of snstions. Note that iis important io specify the responses to bah ai an invalid input
‘ale,
©) Fal lates and efeences tal gues, ables, and diagrams in the SRS and definition ofl terms
and nits of mess
413.1 Use of TBs
‘Any SRS that wes tho phase to be determined" (TBD) isnot a complete SRS, The TBD is, however, oea-
Sonal ncesary and shoal be accompanied by
1) description ofthe condition causing the TBD (e., why an answers noc know) s thar the sa
ation an be resolved;
1b) A description of whet mathe done oclimiate the TD, who it espoasible ois eliminaton, and
by when it mst be eliminated,
4.2.4 Coneletent
Consistency fers ointrnl consistency, If an SRS doesnot gre With Some higher evel document, uch
‘ea eye requirements speciation, he sna coe (Se 43.0,
4.2.4.1 Internal consistency
‘An SRS is ntl consist if, and only if, subst of individual equrements described int conti,
‘The hrc types of likly conics nat SRS ars Tllows:
2) ‘The spied characterises of el world objects may confit. Far example,
1) The format of 2x ouput eprt maybe decried in one requirement as abla bat in woth as
vex
2) One eguvement may sate that alight shal be green while smother may state tha lights
shal bebe
1b) Tee maybe logical or emporal confit beeweea wo spected actos, Fo example,
1) One requirement may specify thatthe program will add two inputs and another may specify
‘hat be program wil mai tem.
2) One requirement may sate tha A” mst bvay follow “B," while anther may ei that”
‘nd 8 occur simalaneouly
(2) Two or more requirements may describe the sme real-world objet bu se ifferent ems for tat
‘object For example, «program's request fra wer input may be cll “pomp” in one requze-
tment anda "cae in another The use of anda lemnology and definitions promotes consiseny.
4.5 Rankod for importance andlor stability
‘An SRS is ranked for importance andlor stabi each requirement in thas an deter onda other
‘he importance or ably of ta particular reeiemen.
“Typical ll of he requirement that ene to a sofware product re not equally nsporat. Some require
men maybe eset expecially for hife-stical appliaons, while otbers may be desirable
6 oy 1808 IEE, A ight sane eee
“SOFTWARE REQUIREMENTS SPECIFICATIONS sues iee
Each rouiement inthe SRS shold be identified to make these differences ler and expt, Identifying
the euements i the following manner eps!
8) Have eutomer give more earful consideration 10 each reguement, which often caries any
idea assumpsions they may hve.
1b) Hive developers make corect design decisions and devote appropiate evel of effort othe die
et prs ofthe software produc.
43.5.1 Degree of stability
(One method of ientifying requirements we the dimension of bili Stability canbe expressed in erm
ofthe numberof expected changes o any requenent based on experience or knowledge of fonhcoming
‘eats hat aft the organization, functions, ad peopl spore by the software tes,
4.3.5.2 Degree of necessity
voter way to rink requirements 10 dsingulsh classes of requrements as essemal,cononal, and
‘option
2) Fzential pies tha the sofware wil nt be scepable unless these requirements ae provided ia
‘an agred manne
>) Condtona. implies that thee are rogues ht wold eahance he software product, but woald
sotmake tunaccepabl if they are abset.
©) Optional. implies cia of functions tha ay oe may note woethwhile. This gives the supplier the
‘opportunity to propose something that exceeds the SRS.
43.6 Verifiable
[An SRS is eral if, nd onl if, every requirement sted hee i veriable. A requirement i eile
ian only if there exists sme ite cas fective process with which a person or machine can check that
the software product meets the requirement. In general ny ambiguous equirement is not verb
NNonveriale requirements inclu statements such as "works well” “god human interface” and “shall
‘uly happen” These reiements cannot be vere case imposible to defn the terms “good
“rll or “ell” The statement hat "he program shall never enter an infite lop” is nomeiale
‘because the esting ofthis quality is heresy impossible
‘An cxample of verifiable stems
owt ofthe program sal be produced within 20 of even 60% othe tne: and shal be
produced within 30 even 100% othe tine
‘This statment an he vere beats it uses concrete terms and measurable quantes
1 method cannot be devise to tein wheter the sft nel partic equrement, then tht
requirement shouldbe removed oe revise
Cony 180 EEE Ati reed 7 ‘Setaotem IEEE RECOMMENDED PRACTICE FOR
43.7 Moditabie
‘An SRS is modifiable if and only if its structure and style are such tht ay changes othe requirements can
‘pe ade easly, comply, nd consistently whe retsning the strctre tnd tle. Modality generally
sequises an SRS t
1) Have a cobrent and easy-to-use organization witha table of contents, an dex, and explicit roe
referening
1b) Not be redundant (., the sme requirement shoud not appear in more than oe place inthe SRS);
©) Express each requirement separately, rather thn termined with othe requsements,
Redundany set i not an ero, but can esl Jed to ers. Redundancy ean occasionally hep to make
an SRS more readable, bata poem can ase when the redundant document is updsted. For instance, 2
‘equirement may be alice in only on ofthe pines where it appears. The SRS then becomes inconsistent.
‘Whenever reundancy is cerry the SRS shoul include exp cross-references to make it modal
A.B Traceable
‘An SRS ls trsceable if the origin of ech oft requirement i ler and it alates the referencing of
‘ach requirement in utr developeat a enhancement documentation. The following we types of wace-
ity are recommended
8) Bacoardracebiy (i, to previous ges of developmen). This depends upon each requirement
cexpliily refereacing is source nearer documens
1) onsard raceablty (eo al documents spanned by the SRS). This Bepends wpon each requie-
‘ment inthe SRS having nique name or reference mune.
“Te forward traceability of he SRS is especialy important when the software product enters the operation
nd malatnane phase A code and design documents ae mailed, tis essential io be ale wo ascertai he
‘ompet eof equirement tha may be flected by tase moieaons.
44 Joint preparation of the SRS
‘Te software development proces should tepin with supper and customer agreement on What the
competed software must do. This agreement, inthe form ofan SRS, shouldbe jointly prepare. This i
moran because stall ether the customer nor he sappieri guid to write a good SRS alone
{Customers usually do nt understand the software design and development process well enough 0
‘write usable SRS
1) Suppliers usually do ot understand the customers problem and field of eedeavor well enough to
poly puree Era acy pte
‘Therefore, the customer and the supplier should work together to produce a well-writen and completely
ert) SRS,
A special station exes when a rystem nd ts software sre both beng defied concarey. Ten he fe
‘onal, ntertacet, perfomance, snd oer abuts and contains ofthe softwar are not predefined, but
‘ater ae jointly defined and sje! to negotiation and change. This maker more dic, tno les
Jmporant, to meet the charctentes sated in 3. In parca, an SRS that doesnot comply wih te
‘euieent of ts paren system specication is incorrect.
® ony 8 1080 EE At igs resend SOFTWARE REQUIREMENTS SPECIFICATIONS sano ie
‘This recommended practice des not specifically seuss styl, language usage oF tecigues of god wit
ing Its quite importans,boweve that an SRS e well writen, General echacal woking books cn be wed
for guidance
45 SRS evolution
‘Te SRS may need o evolve asthe development ofthe software product progresses. It may be imposible to
speci some detail a the ie the project ltd (et ny be impossible 0 define all of the sreen
{femats fran interactive program during the requirements phase). Adina changes may ens as de
‘lence, shortcomings, and inaccuracies sre iveovered inthe SRS,
‘Two major considerations i this proces ar the folowing:
1) Requirements shouldbe specified as completely and thoroughly a is known a the time, even if
‘holutionary revisions canbe foresen a inevabe. The fat tat they are incomplete should be
ed.
1) A forma change proves shoud bene oiden, contol, ack, and report projected changes.
[Approved changes in reqiemets shouldbe incorporate inthe SRS in sucha way 8810
1) Provide an acute and complete mdi tail of ehanges;
2) emit the review of cuenta superseded portions ofthe SRS.
46 Prototyping
Prtoyping used fequenly during the requirements potion ofa project Many tol exit ht allow 2
protrype, exiting some characerstics of stem, to Be crete very quickly and ens. See also ASTM
E1405
Prototypes are wel forthe following easns
4) ‘The customer may he more ikl 0 vew the protrype and react itthan to read the SRS and est
tot Thus the pretotype provides quick feedback
1) The proosype iplays unamticpste sapct of the systems behavior. Ths, it produces not only
tswers but also new guestions This ele reach loro on the SRS.
©) An SRS based on prottype tends to undergo les change ding developmen, dus shortening
{evelopment tine
A prottype shouldbe used a way to ist software roqulemens, Some characteristics such a seen oF
‘por formas canbe extracted dclly fromthe prottype. Other eqiremens canbe infeed by running
capeiments with be prose
4.7 Embedding design in the SRS
A reise species a excernly visible fection or atria fast. A design describes a pau
Jnr subcomponent of a system andor ierfaces with oer subcorponents. The SRS writers) should
leary dstngueh between idenifyingrequed design conswains and projecting vspcitc design. Note
that every regiement ia the SRS lint design ematves. This does not mean, hough tht every equie-
ments design
Cop © 1908 IEEE Att sere. 9 Seoo180 [EEE RECOMMENDED PRACTICE FOR
“The SRS should speciy hat factions we 1 be pefomed on what data to produce what resus at what
lection for whom. The SRS should focus on the services o be plone. The SRS shuld ot normaly
spect design ems soch she folowing
3) Partining he software into modules;
5) Allain nets tthe modules:
©) Desorbing the ow of information or conta etwees modules;
Choosing data sacar
A Necessary design requirements
In spi cases some requirements may severly etic the design. Fo example security or safety equre-
ents mny refs irety nt design suchas te nod to
3) Keep certain functions in separte nodules:
1) Permitonly iid sonication between rome ares of he program:
©) Chock dc inept for eral varibles.
‘Examples of ali design constrains are pyri quirements, performance requirements, software devel-
‘pment standards and software quality assurance standards.
‘Therefor, he equreents shoul be sted from a purely extemal viewpoint. When using modes oils.
tui the ogurements, remember tha he model only inciates the external behavior, ad doesnt speciy
sige
4.8 Embedding project requirements in the SRS.
“The SRS should dress he software prod, not the proces f producing the software product.
Projet reqiements representa understanding been the customer andthe suplersbout contract
Imai pertaining to prodaction of software and thus should not be iced ia tbe SRS. These normally
inclade ems euch a
2) Cons
1) Deter schedules;
©) Reprting procedures
4) Software develpment metus
©) Quay assurance:
1) Valiston and vericaton criteria;
8) Acceptance procedures
Project reuiements are specified in ober documents, ypically in a software development plan, asaftware
‘ity assurance plan or statement of Work.
5. The parts of an SRS
‘This clause dscuses each ofthe exsentl pars of the SRS, These parts are aranged in Figure 1 in an
‘ouine tat can serve as an example fr wring 4 SRS.
While a SRS doesnot have to fellow this outline or ase the names given here fr its pars, a good SRS
should inl he infomation discus hee
0 Conn 1996 EEE ari rear ese
SOFTWARE REQUIREMENTS SPECIFICATIONS sie ee
«Soe mqaments (See 6.1 trough 5: ot exlratns tose
fos rs Set hts rar are acne
operas
Figure 1—Prototype SRS outline
5.1 Introduction (Section 1 of the SRS)
“Te ntrouton ofthe SRS should provide an overview of he enize SRS. I shold conan tbe following
2) Purpose
1) Seope:
©) Definitions, seroays, and abbreviaons:
4) References,
®) Overview.
51
4 Purpose (1.1 of the SRS)
‘This mbnection should
2) Delicate he purpose of the SRS;
1) Specly he intended audience forthe SRS.
5.1.2 Seope (1.2 of the SRS)
‘This abection should
5) Nomi the oftware product(s) tobe produced by mame (eg, Host DBMS, Report Generator, et)
>) plan what the software produc.) wil, and, if necessary, will oc do;
©) Describe the application ofthe software big specified including relevant benefits, objectives, nd
Be consistent with similar statement in higher-level specications (eg. tbe system requirements
‘peetcton, they exis
Copa 1080 EEE Ati zene. 4 ‘901006 |SEE RECOMMENDED PRACTICE FOR
5.1.3 Definitions, acronyms, and abbreviations (1.8 of the SRS)
“Tis subsection shoul provide the definitions ofl terms, acronyms, nd sbbrevitions required to properly
Interpret the SRS. This infomation may be provided by rerence 0 one or more penis in the SRS. oF
byreference to other documents
5.1.4 References (1.4 of the SRS)
“Tis etn should
2) Provide a compete lis ofall documents referenced elsewhere inthe SRS:
1) entify each document y ide report amber apical) date and publishing organization:
©) Speedy the sources rm which the references canbe obtained.
‘Tis information may be provided by reference oan appendix oro anther doument
5.15 Overview (15 ofthe SRS)
‘This subsection should
2) Describe wht theres ofthe SRS contains;
1) Bxplan how the SRS i organized
5.2 Ovorall description (Section 2 of the SRS)
“This section ofthe SRS should describe the general actos tha fet he product and its equrement. Tis
section does ot state specie requirements. Instead it provies a backround for those requirements, which
se defined in detain Seton 3 ofthe SRS, and makes them easier io understand
‘This section usually consis fsx subsoctions a follows
2) Produc perspec
1) Product fenton:
©) User characteristics
©) Consuins,
©) Assumptions and dependencies
1 Apporioning of requremens.
5.2.1 Product perspective 21 ofthe SRS)
“This subsection ofthe SRS should pte prod into perpetve wih cer lated products the product
'sinependeot nd tally set comalne, sould beso stated hee If the SRS defines a proc tht sa
‘omiponeat of larger sytem, a fruentiycecers, then this subsection should ele the requirements of
tha rer system to fonesionality ofthe software ad shold ieniyiterfacesbesween tha s)tem and the
software.
| Bock diagram showing the major components ofthe larger system, interconnections, and external ne
{ces can be ef
2 Copper 196 ES Ath econ SOFTWARE REQUIREMENTS SPECICATION sie 06
“This mbeecton shoal sho describe how the software operates inside various constrains. For example,
these contains could inclde
3) Sytem intetaes,
©) Userimertces;
©) Hardvare nets;
Sofware inertaes;
©) Communications interfaces;
Memon
8) Operations
1) Site adaptation requirements
5.21.1 Systom interfaces
“This should ist each yee interface and identify the fanconality ofthe softwar to accomplish he system
regiment and th interface description Lo match he system
5.2.1.2 User intortaces
‘Tis should spel the following
8) The logical charactrnics ofeach imerfce beeen the sofrsare produc and its users Tis
Includes thse configuration charceristics (eg required Seren Tora, page or Window layous,
content of any reports or meus oF avalabliy of programmable funtion ys) nesessiy wo accom
li he software equrement
1) Altthe aspect of opting the interface wth person who mus se the system. This ay simply
Comprise lst of do's and dons on how the sytem will appear othe wer One example may be 2
roqiremen forthe option of long or short eror massages Like all bess, hese equrerents
‘ould be verifiable, ep," lek typist grade 4 can dofancion Xin Z min after I of ening”
father han "a typist cen do function X” (This may also be specie inthe Software Systm
‘Aber ener a section tiled Base of Use.)
5.21.3 Hardware interfaces
“This sholdspciy the logical characteristics of each interface between the vofware product and the hard
ware components ofthe system. The inlades configuration characteristics (aumberof por, suction
sets, fe) tao covers such mates wha devices re ob suppor how they are tobe supported, and
‘protocols For example, minal support may specify alee sppot opposed one be por.
5.2.1.4 Software intertaces
ing sytem, or a muhemticel package), and inerfaces with cter application systems
‘between an account receivable system anda general lege sytem), or ech eguied software product, the
following sbould be provided
Name;
Meme:
Speciation amber
‘Version sume
Source.
(tit)
ony 2 108 EE. ght esr a Soeosee IEEE RECOMMENDED PRACTICE FOR
Foreach inerace, the following shouldbe provided:
= Dincasson ofthe purpose af the inetxing softvar as related to this software product
= Dafinion ofthe interface in tems of message content and format. Is not necessary to eal any
‘welldocumerted interface, bt areerece to the document defining the inerfoe i regu,
5.2.1.5 Communications interfaces
“This sould pect he various interfaces wo communications ssh as local etna protools ee.
152.16 Memory constraints
“Tis should specify any applicable characteristics and lnits on primary and secondary memory.
52.1.7 Operations
‘Tis should psi the normal and special operations reuite by the user suchas
8) The various mades of operations in the we organization (ewe inated operations);
1) Per of interactive operations ad periods of unatended operations:
©) Data processing suppor fenton;
|8) Backup and recovery operations
[NOTE This ose peste a par of User erie sco.
5.2.1.8 Site adaptation requirements,
“This sould
8) Define the requirement for any data or intalizaton sequences that are specific 0 a given site
‘mission, or operational mode e.g ales, sft imi,
1) Specify the site or mission-elated features that should be modified wo adapt the software oa pstic=
slr instalaion
15.22 Product functions (2.2 of the SRS)
“Tis subsection of the SRS shuld provide a summary ofthe aj functions hat the software wil perform,
Forevample, an SRS fran scccuning program may se hsp t dress customer account maintenance,
‘ison statement, nd invoice preprtion without meatonig the vast mount of eal that each of tose
faesons egies.
‘Sometimes the function sary thai necessary for this pst canbe taken diely fom the section of he
higher-level specfeation fone exits) that allocates parla functions othe sotvare proc. Note that
forthe sake of larity
4) The runtons shoud be organized in away that makes te lst of funcons understandable to the
cnstomer orto anyone cs eaing he document forthe fst ime
1) Textalorgrapical methods can be usd to show the different fectons and thei elaionships.
‘Sha iagram sno intended to show a design of a product, at imply shes thelial lain
ships among variables
4 conyramt 198 EEE Ateneo ee
SOFTWARE REGUREMENTS SPECEICATIONS sun o8
5.2.3 User characteristics (2.3 ofthe SAS)
“Tis subsetion of the SRS shoud describe tae geerlcarsctrisic ofthe intended users of the product
including edo lee, experience, aad tecnica expeis. Tt shoul not be wed wo ste specific
‘Retirement rather should provide the reason why ceri specific requirements ae ter specified in
‘Seution Sf the SRS.
5.24 Conetrants (2.4 of the SRS)
“This subsection ofthe SRS shoul provide general description of ny eter items that wil iit he devel
pers optons, These include
1) Regulator policies
15) Hardware imitations signal ining equirement),
1) Interfaces ooteraplicaions
4) Parle operation;
©) Ait fneons:
1) Convol functions
2) Higherorder language requirement;
5) Signal handshake protools (eg, XON-XOFF, ACK-NACK):
1) Reliability egulements;
5) Cicaliy of he appliation;
1) Safty and security considerations
15.25 Assumptions and dependencies (2.5 ofthe SRS)
“This subsection of the SRS shoul ist ach ofthe factors that affect the requirements stad inthe SRS.
‘Thee Incr sc not Sexi constraints onthe software but are, rather, any changes fo hem that ean fect
ihe magement in tbe SRS. For expe, an astumpion maybe ta pec operating system wil be
alae onthe hardware designated forthe software prod. I in ft, th operating sytem is no val
‘hie the SRS would hen have to change acorns
{5.2.6 Apportioning of requirements (26 of the SRS)
“This subsection ofthe SRS shoud defy requirements hat may be delyed uni ure versions ofthe
sysem,
5.3 Specitic requirements (Section 3 of the SRS)
“Tis section ofthe SRS should contin al of the software requirements to aleve of deal sufcen 1o
Te aeigers to design astm ay those regimens, and teslers to est hat the syste sass
‘howe requiromens,Throusout tis section, ey sated requirement shoal be exerally pereiabl by
AIRE Setton, or other exemal systems, These requirements shoud incide at minimum adsorption of
(Sy ue ttl) nto the sytem, evry osu sponse) from the system, andl fonctions performed
{te Sten in yopone oan pt rn tipo of ouput AS this i fie the lest and most impor.
tan part of the SR, the following piles apy
«) Spec eguirmens shold bested in conformance with al the characesistics deseibed in 43
1) Spocie requirements should be crowe-referencodt earer documents ta lt.
{©} Allralementssoald be usgueyienifble
‘Cac atenton shoud be given to rpmnizng the requirements o maximize readabiiy,
copy 198 EE rs esr. is S00. 1086 | RECOMMENDED PRACTICE FOR
Before examining specie ays of organizing the requirements itis ep to understand the vais items
tha comprive eguirement sr dscribed in 8.1 trough 837
5.3.1 External Interfaces
“This should be detailed descripon ofall inputs ino and cups from the software system. It should
‘complement the iotrface descriptions a 8.2 and should ot epee! infomation ther
shoul nade bo contend formas follows:
2) Name ofitem:
1b) Deseo of purpose:
©) Source of input or destin of ups
4) Valid range accuracy. anor tolerance
©) Units of measure
Timing:
2) Relationships wo other inputoupus,
Seren oratlrgaization;
1) Window formaorganization;
D. Datsformas,
1) Command formas
1D Bad message.
5.3.2 Funetions
Functional requirments shuld define the fundamental sctons that must tke place in the software in
sceptng and processing the inputs and in processing and generating he outputs. These are generally ited
ss “shall” statements stating with "The system shal.”
‘These nce
3) Valin checks on he inputs
5) Beat sequence of operations
©) Responses o abnormal sitions, nhuding
1) Overtow
2) Communication facies
5). Erorhandling and covery
4) Bier of parameters
©) Relationship of outputs opus, inctding
1) pavouput sequences
2) Formulas fr input output conversion
Te may be appropriate to partion he functional requirements into subfuetons or subprocesses, This does
ot imply that he software design will al be partons tht Way.
5.2.2 Pertormance requirements
‘This subsection shoul specify both the sti and the dynamic mumedcal requirements placed on the st
wae or on burn neraction withthe software as whole. Satie nuercl requemets may include he
following
1) The umber of terminal to be supported,
5) ‘The mum of smaltaneoas wert be supported
©) Amount end typeof information o be handed.
6 opi © 1098 IEE, Ao cae ‘ese
‘SOFTWARE REQUIREMENTS SPECIFICATIONS sue ee
‘State numerical requirement ae sometimes identified under a separate section entitled Capacity.
‘Dynamic mamerial requirements may inch, for example, the mumbes of transactions an tasks andthe
‘mount of dia foe processed within certain ime pero fo both normal nd peak werload conditions.
All ofthese regiment shuld te sted in measurable erms
Forexamle
959 ofthe transact shall be processed ers tha 1
rater than,
Am operator shal have wat forthe wansacton to complete
NOTE en ini pl one concn amr cite pa of sing eh
pin of tat coe
45.34 Logical database requirements
“This shoud specify the logical egurements for any information hati to be placed into a database, Ths
say inclode the following
4) Types of infomation ed by varius fancons;
1) equency of use;
©) Accesing capabilites
(Daz ens and thee reaionships
©) Integrity consis;
1) Datnreenton exiremens,
5.35 Design constraints
“This should specify design consis hat can be imposed by other standards, hardware limitations
15.5.1 Standards compliance
“Tis subsection shuld specity the requirements derive fom existing sandals or egulations. They may
inclde the following
»
»
°
a
For example, this could specify the requirement for sofware wo wace processing activity. Such aces are
ended for some pplication to meet minum regulatory or Rnancal standards. An ait race equrereat
‘nay fr example, stat tht ll changes toa payrl database must be recorded ina uae le with before and
ser values.
5.3 Sonware system attributes
‘Tere are «numberof abe of software that can serve a8 reguiements. Ii important that requeed
tribes be specified so tha their achievement can be objectively verifed.Subclauses 5.3.61 through
53.55 povdea puta it of examples
Comyn 080 EEE Ahsan. v 53.61 Reliability
“This should pet the factor required to estas he required iby of he software system at nw of
sliver.
5.3.6.2 Avalabilty
“Tis should specify the factors require o guarantee a defined aia evel or the emits system suchas
checkpoint, every, and estar.
5383 Security
“Tis should pect the factors that proves the software fom accidental or malicious acess, we, modifica
‘Gn, dstnition, or disclosure, Spec requirement ia ths ea could incde the need to
2) Usa cenain cryptographic eign;
1) Keepspecifi log or history data ses,
©) Assign cra fonctions wo diferent modules;
{Rest comminicwions between some aes ofthe program:
©) Check da inert for esi vriabes,
52.64 Maintainablty
‘This ould pity abuts of sofware that rel to he ese of maintenance ofthe softvare isl. There
may be rome requirement for ceaineoduluiy, nerfees complexity, ete. Requirements should not be
lace here jut Recs they are thot toe good design practices.
5365 Portability
“Tis should specify albus of software that relate to the ease of poting the vottwae to oer ost
‘machines andr operating systems. This ay inl he felowing
1) Perentageof components with host dependent code:
>) Parentage of code that is host dependent,
©) Ure proven ponable language:
4) Use ofa pariulr compiler or lnguage subse;
©) Use ofa pariulr operating system,
{5.3.7 Organizing the specific requirements
For anything but vil systems the eile egirements tnd tobe extensive, For this eason, it s reso
‘mended tha careful consideration be piven o organizing these na manne optimal for unéersandng. Thee
{eno one optimal ongniation forall stems, Dire clases of systems end themselves olla ong
uations of requirements in Seton ofthe SRS. Some of these organizations are deserted in 5.3.7.1
Through S377
‘8.7.1 System mode
Some systems behave quite uifferenty depending onthe mee of operation. Fo example, a conta system
‘nay have different ses of functions depending on its mode training. normal or mergeey. When orpniz=
ing this secon by mode, the one in Alor A2 should be used. The chace depends on whether inefaces
snd performance are dependent on mode
8 Cony 808 EEE Aig ‘SOFTWARE REQUIREMENTS SPECIRCATIONS 0-186
5.17.2 User class
Some sysems provide diferent sts of functions to diferent classes of users. For example, an eleraior
‘con sysem presents difrentcapbilies to pasenges, maintenance workers, and fire fighters. When
‘rtniing ts Scion by user class, thecal in A3 should be used
5.3.7.3 Objects
(Objects ae res wor ents hat have counterpart within the system. For example, patent monitor
ng sytem, object inclade patent, semsors, suse, rooms, physicians, medicines, et. Asocaed with
cath object ir ase of tribes of hat obec) and futon (peforme by that bj). Mes nctions ae
ls calle services, ruta, orpoceses When organizing ths setionby objec, he ouline in A. shuld
‘ese, Nowe that sts fobs may share statutes and services. These are roped together s classes
5.37.4 Feature
‘A feature isan externally died eervice bythe syitr hat may require a sequence of inputs to eet the
desired result, For example, ina ilephone rstem, feats inclade local cal cll forwarding, and confer
ce all Each feature is overall described in sequence of stimulus response pais. When organizing tis
‘eston by feat, the olin in A shoul be wed.
5.2.7.5 Stimulus
‘Some systems can be best organized by describing thes fnctios in tems of still. Fo example the fae
tion ofan automa ical landing system may be organized iat sections for loss of power, wird shear,
‘de chenge nol vertea velit excessive te, When organizing this section by simul, the one
nAG shoul be wee,
5.3.7.6 Response
Some systems can be best organized by describing all the functions in support ofthe generation of 2
‘esyonse. For example ihe fantns of personel eystem may be orsnized to setionscoesponding 0
tl finctons ascisted wit generating paychecks all frctions associated wih generating a curetist of
mployens, ee The oalne in A. (wth al occurences of stimulus replaced with reponse) should be se
5..7:7 Functional hierarchy
‘When noe ofthe above cnpaizatonal schemes prove helpful tbe overall functionality canbe organized
io a erry of uncon organied by eer commen inputs, commen cups oF eotmmon itera data
acess, Dataflow diagrams and dt iconries cap be used to show the relationships between snd ong
the fonctions and data When orinzing this section by functional Neachy, the ouie ia A7 should be
wed.
5.38 Adaitional comments
‘Whenvera new SRS is contemple, more than one ofthe organizational chaque given in 5.3.7.7 may
‘be appropriate. In auch cases, onanize the specie requirements for multiple heachies tailored 1 the
specie needs of the rytem under specieaion. For example, see A for an orgnization combining wer
asad feats, Any addon egress maybe pina sepa Seton tthe endothe SRS.
“Tere are many soto, methods, and astomsied rapport os svat alin the documentation of
‘equim, Forth mos part, their nefuless i function of organization, Fo example, when rganizing
‘by mode, Gite sate machines rsa chars may prove helpful when organizing by objet, objet rented
Cony 1998 EEE arene » ee
‘Setooo08 IEEE RECOMMENDED PRACTICE FOR
analysis may prove helpful; when organizing by feat, stimulus response Sequences may prove ely
‘ad when oaizng by Taneonal earch, data flow diagrams and data dictionaries may prove help
In any ofthe outlines given in A. through AB, those sections called “Functional Requirement” may be
Potrebbero piacerti anche
- American Gods: The Tenth Anniversary EditionDa EverandAmerican Gods: The Tenth Anniversary EditionValutazione: 4 su 5 stelle4/5 (12945)
- The Iliad: A New Translation by Caroline AlexanderDa EverandThe Iliad: A New Translation by Caroline AlexanderValutazione: 4 su 5 stelle4/5 (5718)
- Pride and Prejudice: Bestsellers and famous BooksDa EverandPride and Prejudice: Bestsellers and famous BooksValutazione: 4.5 su 5 stelle4.5/5 (19653)
- The Picture of Dorian Gray (The Original 1890 Uncensored Edition + The Expanded and Revised 1891 Edition)Da EverandThe Picture of Dorian Gray (The Original 1890 Uncensored Edition + The Expanded and Revised 1891 Edition)Valutazione: 4 su 5 stelle4/5 (9054)
- The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good LifeDa EverandThe Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good LifeValutazione: 4 su 5 stelle4/5 (5794)
- The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good LifeDa EverandThe Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good LifeValutazione: 4.5 su 5 stelle4.5/5 (20014)
- The Odyssey: (The Stephen Mitchell Translation)Da EverandThe Odyssey: (The Stephen Mitchell Translation)Valutazione: 4 su 5 stelle4/5 (7770)
- Never Split the Difference: Negotiating As If Your Life Depended On ItDa EverandNever Split the Difference: Negotiating As If Your Life Depended On ItValutazione: 4.5 su 5 stelle4.5/5 (3273)
- The Picture of Dorian Gray: Classic Tales EditionDa EverandThe Picture of Dorian Gray: Classic Tales EditionValutazione: 4 su 5 stelle4/5 (9756)
- Anna Karenina: Bestsellers and famous BooksDa EverandAnna Karenina: Bestsellers and famous BooksValutazione: 4 su 5 stelle4/5 (7086)
- The Iliad: The Fitzgerald TranslationDa EverandThe Iliad: The Fitzgerald TranslationValutazione: 4 su 5 stelle4/5 (5646)
- Art of War: The Definitive Interpretation of Sun Tzu's Classic Book of StrategyDa EverandArt of War: The Definitive Interpretation of Sun Tzu's Classic Book of StrategyValutazione: 4 su 5 stelle4/5 (3321)
- How To Win Friends And Influence PeopleDa EverandHow To Win Friends And Influence PeopleValutazione: 4.5 su 5 stelle4.5/5 (6518)
- Habit 6 Synergize: The Habit of Creative CooperationDa EverandHabit 6 Synergize: The Habit of Creative CooperationValutazione: 4 su 5 stelle4/5 (2499)
- Wuthering Heights (Seasons Edition -- Winter)Da EverandWuthering Heights (Seasons Edition -- Winter)Valutazione: 4 su 5 stelle4/5 (9486)
- The 7 Habits of Highly Effective PeopleDa EverandThe 7 Habits of Highly Effective PeopleValutazione: 4 su 5 stelle4/5 (2566)
- Habit 1 Be Proactive: The Habit of ChoiceDa EverandHabit 1 Be Proactive: The Habit of ChoiceValutazione: 4 su 5 stelle4/5 (2556)
- The 7 Habits of Highly Effective PeopleDa EverandThe 7 Habits of Highly Effective PeopleValutazione: 4 su 5 stelle4/5 (353)
- Habit 3 Put First Things First: The Habit of Integrity and ExecutionDa EverandHabit 3 Put First Things First: The Habit of Integrity and ExecutionValutazione: 4 su 5 stelle4/5 (2507)
- The 7 Habits of Highly Effective People: The Infographics EditionDa EverandThe 7 Habits of Highly Effective People: The Infographics EditionValutazione: 4 su 5 stelle4/5 (2475)
