NORMA IEEE 830 PARA ESPECIFICACIN DE REQUERIMIENTOS DE SOFTWARE

Noviembre de 2005

Antes de describir l n!r" IEEE 830###

Una vez que se ha detectado algn problema que afecte a la calidad del producto/servicio, o a la satisfaccin del cliente conviene analizar si puede resolverse mediante algn tipo de tecnolog!a de informacin " telecomunicaciones #$%$&' ()ard*are (+oft*are (,edes #-.N, /.N, 0.N, 12N, *eb, al3mbricas, inal3mbricas, etc &

C$"! s ber si el %r!ble" %&ede res!l'erse c!n TIT

4-a

con 5 almacenamiento de datos6 5 procesamiento de datos6 5 transferencia de datos6

causa del problema est3 relacionada

+i

el problema puede resolverse por medios m3s baratos sin necesidad de invertir en $%$, 4para qu7 gastar en $%$6

+i el problema se relaciona con almacenamiento, procesamiento o transferencia de datos, conviene definir los requerimientos espec!ficos #necesidades& que tengamos definir claramente los requerimientos que deseamos que satisfaga un soft*are, se facilitan'
5 5 5 5

.l

-a estimacin de su costo -a estimacin del tiempo para dise8arlo/programarlo -a decisin sobre desarrollarlo nosotros, subcontratar o comprar -a bsqueda de algn proveedor que pueda programarlo/venderlo

 9efinir

los requerimientos de un soft*are puede parecer algo sencillo, pero es comn que el usuario/cliente o el desarrollador cometan errores u omisiones importantes

/uchos

problemas en los pro"ectos de soft*are se deben a una inadecuada especificacin de requerimientos

 2ara

definir los requerimientos de un soft*are, podemos apo"arnos en una norma que nos gu!a para hacer las preguntas pertinentes' %::: ;<0 norma le sirve tanto al usuario/cliente como al desarrollador

:sta

IEEE 830
,ecommended 2ractice for +oft*are ,equirements +pecifications
+,+

 :l

propsito principal de esta norma es a"udarnos a elaborar un documento mu" til' el +,+ esencialmente una gu!a para redaccin

:s

IEEE 830
=ui7n

la hizo' +oft*are :ngineering +tandards >ommittee, del %::: >omputer +ociet" #%nstitute of :lectric and :lectronic :ngineers, en : U . & ?@@;

%:::

>u3ndo' 4:s

de uso obligatorio6 NA

IEEE 830

=ui7n la puede usar'

5

Un cliente/usuario que va"a a definir requerimientos #caracter!sticas& de un soft*are que necesite Un desarrollador #interno/eBterno& que haga soft*are Ca la medidaD mediante pro"ecto Un desarrollador que haga soft*are Cde paqueteD que se venda masivamente

IEEE 830 sir'e % r (&e###

Un Un

cliente describa claramente lo que quiere

proveedor entienda claramente lo que el cliente quiere establezcan bases para un contrato de desarrollo #o de compraEventa& reduzca el esfuerzo de an3lisis, dise8o, " programacin #evitando reEtrabaFos&

+e

+e

IEEE 830 sir'e % r (&e###

+e

tenga una base o referencia para validar o probar el soft*are solicitado facilite el traspaso del soft*are a otros clientes/usuarios le puedan hacer meForas #o innovaciones& a ese soft*are

+e

+e

CONSIDERACIONES PARA REDACTAR E) SRS

+u

naturaleza +u ambiente >aracter!sticas deseables del documento 2reparacin conFunta del +,+ :volucin del documento 2rototipos 9ise8o Cimpl!citoD en el +,+ ,equerimientos de pro"ecto Cimpl!citosD

N t&r le* del SRS

:l

+,+ es una especificacin para un producto de soft*are en particular, "a sea un slo programa, o un conFunto de programas, que realicen ciertas funciones en un ambiente espec!fico veces el usuario no sabe si necesitar3 un solo programa o m3s de uno

NATURA)E+A DE) SRS

Grecuentemente,

el usuario slo conoce las necesidades pero no el tipo de solucin m3s conveniente :l +,+ puede escribirse por uno o m3s representantes del proveedor, uno o m3s del cliente, o por ambos -o m3s recomendable es que ha"a representantes de ambas partes :l usuario/cliente puede redactar un borrador inicial " despu7s revisarlo con el proveedor

NATURA)E+A DE) SRS ,c!nt# Guncionalidades

deseadas %nterfaces eBternas 9esempe8o

.tributos

(seguridad, portabilidad, mantenibilidad, etc.) de dise8o impuestas a la implementacin (estndares tcnicos propios o internacionales, lenguaje de progr., sistema operativo, lmites de recursos, polticas internas).

,estricciones

AM.IENTE DE) SRS

:l

+,+ es la fuente principal para hacer el plan detallado de un pro"ecto de soft*are +,+ puede referirse a los requerimientos deseados de todos los componentes de un sistema grande, o a componentes #mdulos& individuales del mismo

Un

AM.IENTE DE) SRS

+i

se hacen +,+ por separado para varios mdulos, tiene que mantenerse la consistencia en los documentos un soft*are necesita interactuar con otro, tienen que especificarse los requerimientos de esa interaccin #interfaces&, definiendo sus funcionalidades " el nivel de desempe8o deseado

+i

CARACTER/STICAS DE UN .UEN SRS

>orrecto No

ambiguo >ompleto >onsistente Ardenado con base en importancia "/o estabilidad 1erificable /odificable ,astreable

C!rrecte*
:l

+,+ es correcto si los requerimientos escritos son aquellos que el soft*are deber3 cumplir ha" un m7todo para saber si el +,+ es correctoH lo importante es que se pida lo que realmente se necesita

No

N! "bi0&!
Un

+,+ es no ambiguo si cada requerimiento establecido en 7l tiene una sla interpretacin posible, tanto por el cliente/usuario como por el desarrollador casos donde alguna palabra pudiera tener mltiples significados, se debe incluir su definicin precisa en un glosario que se adicione al +,+
5

:n

:Femplos' planta, obra, maestro, carga, flecha

N! "bi0&! ,c!nt# Pr!ble"

1 :l usuario/cliente " el desarrollador generalmente tienen diferentes perfiles profesionales, " por ello describen los requerimientos en diferente forma 1 -as descripciones que pudieran ser m3s claras para el desarrollador, podr!an ser dif!ciles de entender para el usuario, " viceversa

Pr!ble"

N! "bi0&! ,c!nt# :l

lenguaFe natural es inherentemente ambiguoH por ello, es conveniente que el +,+ sea revisado por un tercero que no ha"a participado en la redaccin han creado lenguaFes formales para especificacin de requerimientos de soft*are, que se basan en reglas matem3ticas " lgicas para evitar la ambigIedad #como la Notacin Z, IS !I"# Z Standard $%&'()*++*&

+e

E2e"%l! de &s! de Notacin Z

RAdd Birthday Birthday Book name?: NAME date?: DATE result!: REPORT (name? known irthday!" irthday #name? result!" ok% & (name? known irthday! " irthday result !" already'known% Date?$

N! "bi0&! ,c!nt# /7todos

5 5 5

de representacin de requerimientos'

Jasados en obFetos' identificar clases de obFetos similares #alumno, empleado, producto, etc & Jasados en procesos #compras, ventas, cobranza& Jasados en conductas #la conducta de un robot&

COMP)ETO
:l
5

+,+ es completo si inclu"e'

$odos los requerimientos significativos sobre funcionalidades, desempe8o, restricciones de dise8o, atributos, o interfaces eBternas -as respuestas que deber!a dar el soft*are a todas las posibles entradas de datos en todas las situaciones posibles #entradas aceptables o no aceptables' validacin& :specificacin de unidades de medida #si son aplicables& :n caso de que el +,+ tenga diagramas o tablas informativas, ha" que darles nmero o identificacin

5 5

CONSISTENTE
-os

diversos requerimientos escritos tienen que ser compatibles entre s!H no debe haber contradicciones ni conflictos entre ellos 2ara lograr la consistencia deben evitarse los siguientes conflictos'
5 5 5

:n caracter!sticas especificadas de obFectos del mundo real 9e lgica o de tiempo entre dos actividades ,eferencia a un mismo obFeto del mundo real pero usando diferentes palabras para el mismo obFeto

ORDENADO POR 3RADO DE IMPORTANCIA O ESTA.I)IDAD

>ada

requerimiento especificado debe tener alguna identificacin #nmero, letra, secuencia alfanum7rica& para indicar su grado de importancia o de estabilidad requerimientos son m3s importantes que otros CranKearlosD se puede dar a cada requerimiento la atencin que se merece

.lgunos

.l

ORDENADO POR 3RADO DE IMPORTANCIA O ESTA.I)IDAD

Lrado

de estabilidad' nmero de cambios que se podr!an esperar para un requerimiento, debido a eventos futuros que afecten a la organizacin, las responsabilidades, " las personas que usar3n el soft*are de necesidad'

Lrado
5 5 5

:sencial >ondicional Apcional

4ERIFICA.)E
Un

requerimiento es verificable si eBiste algn m7todo rentable mediante el cual se pueda analizar si el soft*are cumple ese requerimiento :Femplo'
5

C-a respuesta del programa deber3 darse dentro de los 20 seg posteriores a la apertura de la v3lvula 1M<;@, " debe responder correctamente en el N0O de los casosD

>ontraeFemplo
5

#algo no verificable&'

C:l programa tiene que funcionar bienD

4ERIFICA.)E ,c!nt# +i

no eBiste algn m7todo para saber si el soft*are cumple o no un requerimiento, entonces ese requerimiento debe ser revisado o eliminado

MODIFICA.)E
:s

modificable si la estructura " estilo de redaccin permiten la realizacin de cambios en forma f3cil, completa " consistente esto es recomendable'

2ara
5 5 5

%ncluir !ndice, tabla de contenido " tabla de referencias cruzadas >ada requerimiento debe aparecer slo una vez #la redundancia propicia errores de inconsistencia& 2oner cada requerimiento separado de los dem3s

RASTREA.)E
>ada

requerimiento debe identificarse con algn nmero, letra o secuencia alfanum7rica Un +,+ es rastreable si el origen de cada requerimiento es claro, " si facilita el seguimiento de cada requerimiento a lo largo del pro"ecto de soft*are 9os tipos de rastreabilidad'
5 5

5 ci tr6s1 en cada requerimiento se menciona eBpl!citamente su fuente documental 5 ci del nte1 los documentos que se deriven del +,+ deben usar las identificaciones de requerimientos como fueron dadas en el +,+

RASTREA.)E ,c!nt# -a

rastreabilidad hacia delante facilita las actividades de dise8o, codificacin, " modificacin del soft*are

PREPARACIN CON7UNTA DE) SRS

:l

desarrollo de un soft*are solamente deber!a iniciar cuando el cliente " el proveedor est7n de acuerdo acerca de lo que el soft*are deber3 hacer

E4O)UCIN DE) SRS

Un

+,+ puede necesitar cambios mientras el soft*are est3 en etapas de dise8o o de desarrollo cambios pueden estar motivados por' deficiencias, errores, omisiones o imprecisiones en el documento original requerimiento debe documentarse tan completo como sea posible, an si pudiera necesitar cambios posteriormente

-os

>ada

E4O)UCIN DE) SRS

-os

cambios en los requerimientos tienen que documentarse con el propsito de' identificarlos, controlarlos, rastrearlos, " reportarlos el cliente como el proveedor deben designar a su respectivo responsable de autorizar #o rechazar& cambios en los requerimientos

$anto

CREACIN DE PROTOTIPOS
Un

prototipo es un peque8o programa parecido al soft*are solicitado que sirve de eFemplo, muestra o modelo para que el cliente va"a especificando sus requerimientos en forma progresiva Funto con el desarrollador

CREACIN DE PROTOTIPOS
:l
5

prototipo es til para'

=ue el cliente/usuario vea " describa m3s f3cilmente las funcionalidades que desea 2rever aspectos de la conducta del sistema, haciendo que el +,+ sea m3s completo " preciso ,educir la cantidad de cambios durante las etapas de dise8o o desarrollo

CREACIN DE PROTOTIPOS ,c!nt# Un

prototipo puede a"udar al usuario a definir detalles espec!ficos de la interfaz humana o de las funcionalidades que requiera facilitarle al desarrollador el dise8o " la programacin del soft*are

2uede

DISE8O 9IMP)/CITO: EN E) SRS

.unque

el +,+ no constitu"e un documento de dise8o, impl!citamente est3 dici7ndole a los desarrolladores lo que se espera que ellos dise8en
5

:stablece restricciones

:l

+,+ tiene que especificar las funcionalidades que se aplicar3n sobre ciertos datos para producir resultados en cierto lugar para determinados usuarios

)! (&e 0ener l"ente no necesit escribirse en el SRS

>mo

se deben organizar los mdulos del soft*are >mo se deben asignar funcionalidades espec!ficas a cada mdulo >mo ser3 el fluFo de datos o el control de eFecucin de los mdulos :leccin de estructuras de datos que se usar3n dentro del cdigo

Sin e"b r0!;

.lgunas

situaciones especiales pueden inducir requerimientos estrictos de dise8o las restricciones de seguridad contra ataques en %nternet pueden requerir que'
5 5 5

:Femplo'

.lgunas funcionalidades del soft*are se localicen en mdulos #programas& separados +lo se permita una comunicacin limitada entre ciertos mdulos +e verifique la integridad de datos para variables cr!ticas

M6s e2e"%l!s de restricci!nes en dise<!

,equerimientos

f!sicos #eF peso en el shuttle& ,equerimientos de desempe8o Uso de est3ndares de desarrollo de soft*are :st3ndares de aseguramiento de la calidad del soft*are -os requerimientos se establecen siempre desde el punto de vista del usuario/cliente

REQUERIMIENTOS DE PRO=ECTO 9IMP)/CITOS:

:l

+,+ se enfoca en el soft*are como producto, no en su proceso de creacin establece restricciones sobre la planeacin " administracin del pro"ecto correspondiente

%mpl!citamente

REQUERIMIENTOS DE PRO=ECTO 9IMP)/CITOS: ,c!nt# :l

+,+ da origen a otros documentos #por separado& relacionados con el ciclo de vida de un soft*are
5 5 5 5 5 5 5

:stimacin de costos #4cmo calcularlos6& Gechas de entrega ,eportes de avances /7todos de desarrollo .seguramiento de la calidad >riterios de validacin " verificacin 2rocedimientos de aceptacin

CONTENIDO = OR3ANI+ACIN T/PICOS DE UN SRS

( Del documento ) ( Del software )

>ontenido " organizacin t!picos de un +,+

CONTENIDO DE UN SRS
+:>>%PN 5

?' %N$,A9U>>%PN 9ebe incluir una descripcin general del +,+, mostrando lo siguiente' ? ? 2ropsito del documento ? 2 .lcance ? < 9efiniciones, acrnimos, " abreviaturas ? Q ,eferencias ? 5 9escripcin general del documento

CONTENIDO DE UN SRS
? ? 2ropsito del documento' aqu! se tiene que'
:Bplicar

para qu7 se usar3 el documento

:specificar

a qu7 tipo de lectores est3 destinado #usuarios, clientes, analistas, programadores, etc &

CONTENIDO DE UN SRS
? 2 .lcance 5 .qu! se tiene que'

%dentificar por su nombre gen7rico #" espec!fico& el producto#s& de soft*are que se est7n requiriendoH por eFemplo' sistema de administracin de inventario, generador de reportes, sistema maneFador de bases de datos marca +perM, etc & :Bplicar lo que el soft*are har3, ", si fuera necesario aclararlo, tambi7n lo que no se espera que haga

CONTENIDO DE UN SRS
? 2 .lcance 5 .qu! se tiene que'

9escribir para qu7 se aplicar3 el soft*are, inclu"endo sus beneficios relevantes, obFectivos, " metas +er consistente con las disposiciones que se ha"an dado en especificaciones de ma"or nivel Fer3rquico #si eBisten&H por eFemplo, las de algn sistema de ma"or Ferarqu!a

CONTENIDO DE UN SRS
? < 9efiniciones, acrnimos, " abreviaturas

9ar las definiciones de todos los t7rminos, acrnimos #siglas& " abreviaturas que sean pertinentes para el adecuado entendimiento del +,+ :sta informacin puede ofrecerse mediante referencias a uno o m3s ap7ndices del +,+ o referencias hacia otros documentos #manuales de la organizacin, procedimientos de aseguramiento de calidad, hoFas de registro, etc &

CONTENIDO DE UN SRS
? Q ,eferencias

Afrecer una lista completa de todos los documentos a los que se haga referencia en el +,+ %dentificar cada documento mediante su t!tulo, nmero de reporte #si es aplicable&, fecha, " organizacin que lo public :specificar las fuentes de las cuales pueden obtenerse los documentos referenciados :sta informacin puede ofrecerse haciendo alusin a un ap7ndice o hacia otro documento

CONTENIDO DE UN SRS
? 5 9escripcin gral del documento

9escribir lo que contienen las secciones restantes del documento :Bplicar cmo est3 organizado

CONTENIDO DE UN SRS
+:>>%PN

2' 9:+>,%2>%PN L,.- 9:+AG$0.,:

.qu! no se establecen los requerimientos espec!ficos, sino que se describe el fondo general que da lugar a los requerimientos, los cuales se definen detalladamente hasta la seccin < del +,+H 7sto los hace m3s f3ciles de entender

CONTENIDO DE UN SRS
+:>>%PN
5

2' 9:+>,%2>%PN L,.- 9:+AG$0.,:

Usualmente se inclu"en estas N subsecciones' 2 ? 2erspectiva del soft*are 2 2 Gunciones del soft*are 2 < >aracter!sticas del usuario 2 Q ,estricciones 2 5 +uposiciones " dependencias 2 N 2osposicin de requerimientos

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are
5 5 5

9escribir el soft*are en perspectiva con otros soft*are relacionados' similitudes " diferencias +i el soft*are es independiente " totalmente autoE contenido, eso tiene que decirse aqu! +i se est3 requiriendo un soft*are que formar3 parte de un sistema m3s grande, se tiene que describir la relacin de los requerimientos del sistema grande con las funcionalidades del soft*are requerido " debe identificarse cmo se comunicar3n ambos

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are #cont &
5

2ara describir las relaciones entre el soft*are requerido " el sistema grande, pueden ser tiles los diagramas de bloques :n los diagramas de bloques se pueden mostrar los componentes principales del sistema grande " su relacin Fer3rquica #" de fluFo de datos& con el soft*are requerido

E2e"%l! de di 0r " de bl!(&es1 Siste" % r Inscri%ci!nes

-./
Estudiante (ursos

soli)itados

M*dulo +ara &eri,i)ar dis+oni ilidad

(ursos dis+oni les

Ar)hi5o de )ursos

(arta de )on,irma)i*n

(ursos autori0ados

3./
M*dulo +ara Noti,i)ar ins)ri+)i*n

Re4istro

2./

Detalles de )urso 1ns)ri+)i*n a )urso Datos estudiante

Ar)hi5o de estudiantes

M*dulo +ara 1ns)ri ir al estudiante

Basado en Laudon & Laudon. Sistemas de Informacin Gerencial. Prentice-Hall. M !ico" #$$#.

E2e"%l! de di 0r " de bl!(&es1 Siste" % r Inscri%ci!nes

3./
M*dulo +ara Noti,i)ar ins)ri+)i*n

Este +odr6a ser un so,tware 7ue estamos re7uiriendo8 7ue ,ormar6a +arte del sistema 4rande

Basado en Laudon & Laudon. Sistemas de Informacin Gerencial. Prentice-Hall. M !ico" #$$#.

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are #cont &
5

9escribir las condiciones #restricciones& dentro de las cuales deber3 funcionar el soft*are' 2 ? ? %nterfaces de sistema #R& 2 ? 2 %nterfaces de usuario 2 ? < %nterfaces de hard*are 2 ? Q %nterfaces de soft*are 2 ? 5 %nterfaces de comunicaciones 2 ? N ,estricciones de memoria 2 ? S Aperaciones 2 ? ; ,equerimientos de adaptacin a un lugar (9% :;u< es una inter,a0?

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are #cont & 2 ? ? %nterfaces de sistema' lo que ha" entre los diversos mdulos del sistema
5 5

:numerar cada interfaz de sistema 9escripcin de la interfaz del soft*are para hacerlo compatible con el sistema

4e "!s l!s "$d&l!s###

-./
Estudiante (ursos
M*dulo +ara &eri,i)ar dis+oni ilidad

soli)itados

(ursos dis+oni les

Ar)hi5o de )ursos

(arta de )on,irma)i*n

(ursos autori0ados

3./
M*dulo +ara Noti,i)ar ins)ri+)i*n

Re4istro

2./

Detalles de )urso 1ns)ri+)i*n a )urso Datos estudiante

Ar)hi5o de estudiantes

M*dulo +ara 1ns)ri ir al estudiante

Estudiante (ursos

(arta de )on,irma)i*n

M*dulo +ara Noti,i)ar ins)ri+)i*n

e r t n e ( ) a s ' u lo u 2./ d 3./ & % m

-./
soli)itados
M*dulo +ara &eri,i)ar dis+oni ilidad

(ursos dis+oni les

s lo

(ursos autori0ados

Ar)hi5o de )ursos

Detalles de )urso 1ns)ri+)i*n a )urso Datos estudiante

Ar)hi5o de estudiantes

Re4istro

M*dulo +ara 1ns)ri ir al estudiante

)! (&e > ? entre l!s "$d&l!s###

-./
M*dulo +ara &eri,i)ar dis+oni ilidad

(ursos autori0ados

1.=.

3./
M*dulo +ara Noti,i)ar ins)ri+)i*n

1.=.
Re4istro

1.=. si4ni,i)a 1nter,a0 de sistema

2./
M*dulo +ara 1ns)ri ir al estudiante

Basado en Laudon & Laudon. Sistemas de Informacin Gerencial. Prentice-Hall. M !ico" #$$#.

)! (&e > ? entre l!s "$d&l!s###

( -o que ha" entre los mdulos es fluFo de informacinH por lo tanto se tiene que especificar qu7 informacin alimenta a cada uno de los mdulos que sean requeridos ( )a" que especificar cmo es esa informacin #num7rica, alfanum7rica, rango de valores posibles, unidades de medida, etc &

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are
2 ? 2 %nterfaces de usuario' lo que estar3 entre el usuario " el soft*are 5 9efinir las caracter!sticas de '
1entanas >olores Gormatos /ens Tconos,

" tama8os de letra

botones >ontenido de los reportes impresos %nterfaz mediante . + , "/o s!ntesis de voz ,ealidad virtual Atras interfaces usuario/m3quina #electrodos&

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are
2 ? < %nterfaces de hard*are' qu7 hard*are usar3 el soft*are para entrada/salida de informacin, inclu"endo'
>aracter!sticas

de configuracin #nmero de puertos de comunicacin, instruction sets, etc & =u7 dispositivos de hard*are ser3n soportados por el soft*are," 7n qu7 forma ser3n soportados 2rotocolos de transferencia de datos entre dispositivos

:Femplo' un sistema para administracin de inventarios puede requerir el uso de scanners especiales para leer cdigos de barras

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are
2 ? Q %nterfaces de soft*are' qu7 otros soft*are se necesitar3n para que el soft*are requerido pueda funcionar, por eFemplo'
+istemas

operativos' 0indo*s, -inuB, .%M, +olaris, etc +istemas maneFadores de bases de datos' Aracle, +"base, /"+=-, 9J2, etc %nt7rpretes de lenguaFes #como 2:,-& +hells para sistemas eBpertos #como +ictus 2rolog& 2aquetes comerciales para eFecutar programas que usan redes neuronales #como /at-ab&

$ambi7n los programas para que el soft*are pueda interactuar con los dem3s mdulos

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are
2 ? 5 %nterfaces de comunicacin' =u7 tecnolog!a de redes se usar3 para comunicar a las computadoras en las cuales se usar3 el soft*are'
5 5 5 5

Nombre gen7rico de la tecnolog!a' -.N, 0.N, /.N, 12N, 000, 0iGi, etc $opolog!a de la red' anillo, estrella, bus 2rotocolos de comunicacin' :thernet, $>2/%2, .$/, Grame,ela", 222 $ipo de cableado' fibra ptica, par trenzado, coaBial

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are
2 ? N ,estricciones de memoria +e debe especificar si eBiste o no algn l!mite en cuanto a la memoria #tanto primaria como secundaria& que podr3 tener disponible el soft*are para ser eFecutado /emoria primaria' la ,./ #,andom .ccess /emor"& /emoria secundaria' disco, cinta

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are
2 ? S Aperaciones :specificar los diferentes modos de operacin del soft*are por parte del usuario, por eFemplo'
5 5 5

Aperaciones CnormalesD versus especiales #inscribir alumno versus respaldo de archivos& Aperaciones interactivas " actividades que no requieran atencin del usuario Aperaciones iniciadas por el usuario versus operaciones que se activen autom3ticamente

CONTENIDO DE UN SRS
2 ? 2erspectiva del soft*are
2 ? ; .daptacin a un lugar espec!fico
5

9efinir los requerimientos respecto a datos o secuencias de inicializacin del soft*are que sean espec!ficas para un lugar, una misin o un modo operacional espec!fico :specificar las caracter!sticas relacionadas con el lugar o la misin que deban ser modificadas para adaptar el soft*are a una instalacin espec!fica

CONTENIDO DE UN SRS
2 2 Gunciones del producto +umario de las funciones principalesH por eFemplo, para el caso de un soft*are de contabilidad se mencionr!a el mantenimiento de cuentas de cliente, el registro de sus transacciones, la preparacin de facturas, pero sin mencionar los detalles requeridos de esas funciones

CONTENIDO DE UN SRS
2 < >aracter!sticas de los usuarios 9escribir sus caracter!sticas respecto a' Nivel educativo :Bperiencia profesional >apacidades t7cnicas :sta descripcin a"uda a comprender los motivos que dan origen a los requerimientos

CONTENIDO DE UN SRS
2 Q ,estricciones
%nformacin sobre posibles limitantes que deber3n respetar los dise8adores, como' a& 2ol!ticas regulatorias aplicables b& -imitaciones en el hard*are #p eF velocidad del microprocesador& c& %nterfaces hacia otras aplicaciones d& Guncionamiento en paralelo e& Gunciones de auditor!a de soft*are

CONTENIDO DE UN SRS
2 Q ,estricciones #cont &
f& 2rotocolos de comunicaciones de redes g& ,equiremientos de confiabilidad h& >riticidad de la aplicacin i& >onsideraciones sobre seguridad f!sica " lgica

CONTENIDO DE UN SRS
2 5 +uposiciones " dependencias
>ada uno de los factores que afecten a los requiremientos especificados :stos factores no son restricciones de dise8o para el soft*are, sino UUUUUUbut are, rather, an" changes to them that can affect the requirements in the +,+ Gor eBample, an assumption ma" be that a speciVc operating s"stem *ill be available on the hard*are designated for the soft*are product %f, in fact, the operating s"stem is not availE able, the +,+ *ould then have to change accordingl"

CONTENIDO DE UN SRS
2 N 9istribucin #apportioning& de requerimientos
.qu! se dice cu3les son los requerimientos que pueden atenderse hasta versiones futuras del sistema

Or0 ni* ci$n de l!s re(&eri"ient!s es%ec@Aic!s ,Secci$n 32ara lograr un meFor entendimiento de los requerimientos, conviene organizarlos con base en alguno de los siguientes criterios' 2or modo de operacin del sistema 2or clase de usuario 2or obFetos 2or caracter!sticas 2or est!mulos 2or respuestas 2or Ferarqu!a funcional

Or0 ni* ci$n de l!s re(&eri"ient!s es%ec@Aic!s ,Secci$n 3 2or

5

modo de operacin del sistema

5 5

2 eF si se desea un sistema de control para una planta industrial, sus modos de operacin podr!an ser' modo de entrenamiento, modo normal, " modo de emergencia )a" que definir las funcionalidades del sistema para cada tipo de modo Usar las plantillas . ? o . 2, la primera si los diversos modos de operacin requieren diferentes interfacesH la segunda si requieren diferentes tipos de desempe8o

Or0 ni* ci$n de l!s re(&eri"ient!s es%ec@Aic!s ,Secci$n 3 2or

5

clase de usuario

.lgunos sistemas ofrecen diferentes conFuntos de funciones para cada tipo de usuario 2 eF , un sistema de sucursal bancaria ofrece diferentes funciones para el personal de caFas, para los eFecutivos de cuenta o para el gerente Usar plantilla . <

Or0 ni* ci$n de l!s re(&eri"ient!s es%ec@Aic!s ,Secci$n 3 2or

5

obFetos

CAbFetosD son entidades del mundo real que tienen una representacin dentro del sistema 2 eF un sistema de monitoreo de pacientes inclu"e pacientes, sensores, enfermeras, habitaciones, m7dicos, medicinas, etc 2ara cada obFeto se define un conFunto de atributos " funcionalidades #denominadas servicios o m7todos& Usar plantilla . Q

Or0 ni* ci$n de l!s re(&eri"ient!s es%ec@Aic!s ,Secci$n 3 2or

5

caracter!sticas

5 5

Una caracter!stica es una funcionalidad del sistema que puede requerir una secuencia de entradas de datos para producir un resultado o una accin :F en la programacin de los circuitos de un aparato telefnico, las caracter!sticas son' llamada local, transferencia de llamada, " llamada en conferencia #con,erence call& >ada caracter!stica se describe generalmente como una secuencia de pares de est!muloErespuesta Usar plantilla . 5

Or0 ni* ci$n de l!s re(&eri"ient!s es%ec@Aic!s ,Secci$n 3 2or

5

est!mulos

UUU

Or0 ni* ci$n de l!s re(&eri"ient!s es%ec@Aic!s ,Secci$n 3 2or

5

respuestas

UUU

Or0 ni* ci$n de l!s re(&eri"ient!s es%ec@Aic!s ,Secci$n 3 2or

5

Ferarqu!a funcional

>uando ninguna de las plantillas resulta til, la funcionalidad general del sistema puede organizarse en una Ferarqu!a de funciones, "a sea con base en entradas comunes, salidas comunes, o accesos comunes a los datos +e pueden usar diagramas de fluFo de datos " diccionarios de datos para mostrar las relaciones entre las diversas funciones, entre los diversos datos, " entre las funciones " los datos Usar plantilla . S

BPre0&nt s ! c!"ent ri!sC