NORMA IEEE 830 PARA ESPECIFICACIN DE REQUERIMIENTOS DE SOFTWARE

Noviembre de 2005

Antes de describir la norma 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 tecnologa de informacin y telecomunicaciones (TIT): Hardware Software Redes (LAN, MAN, WAN, VPN, web, almbricas, inalmbricas, etc.)

Cmo saber si el problema puede resolverse con TIT

La causa del problema est relacionada con... almacenamiento de datos? procesamiento de datos? transferencia de datos?
Si el problema puede resolverse por medios ms baratos sin necesidad de invertir en TIT, para qu gastar en TIT?

Si el problema se relaciona con almacenamiento, procesamiento o transferencia de datos, conviene definir los requerimientos especficos (necesidades) que tengamos Al definir claramente los requerimientos que deseamos que satisfaga un software, se facilitan:

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

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

Muchos problemas en los proyectos de software se deben a una inadecuada especificacin de requerimientos

Para definir los requerimientos de un software, podemos apoyarnos en una norma que nos gua para hacer las preguntas pertinentes: IEEE 830 Esta norma le sirve tanto al usuario/cliente como al desarrollador

IEEE 830
Recommended Practice for Software Requirements Specifications
SRS

El propsito principal de esta norma es ayudarnos a elaborar un documento muy til: el SRS Es esencialmente una gua para redaccin

IEEE 830

Quin la hizo: Software Engineering Standards Committee, del IEEE Computer Society IEEE (Institute of Electric and Electronic Engineers, en E.U.A.) Cundo: 1998 Es de uso obligatorio? NO

IEEE 830

Quin la puede usar:

Un cliente/usuario que vaya a definir requerimientos (caractersticas) de un software que necesite Un desarrollador (interno/externo) que haga software a la medida mediante proyecto Un desarrollador que haga software de paquete que se venda masivamente

IEEE 830 sirve para que...

Un cliente describa claramente lo que quiere Un proveedor entienda claramente lo que el cliente quiere Se establezcan bases para un contrato de desarrollo (o de compra-venta) Se reduzca el esfuerzo de anlisis, diseo, y programacin (evitando re-trabajos)

IEEE 830 sirve para que...

Se tenga una base o referencia para validar o probar el software solicitado Se facilite el traspaso del software a otros clientes/usuarios Se le puedan hacer mejoras (o innovaciones) a ese software

CONSIDERACIONES PARA REDACTAR EL SRS

Su naturaleza Su ambiente Caractersticas deseables del documento Preparacin conjunta del SRS Evolucin del documento Prototipos Diseo implcito en el SRS Requerimientos de proyecto implcitos

Naturaleza del SRS

El SRS es una especificacin para un producto de software en particular, ya sea un slo programa, o un conjunto de programas, que realicen ciertas funciones en un ambiente especfico
A veces el usuario no sabe si necesitar un solo programa o ms de uno

NATURALEZA DEL SRS

Frecuentemente, el usuario slo conoce las necesidades pero no el tipo de solucin ms conveniente El SRS puede escribirse por uno o ms representantes del proveedor, uno o ms del cliente, o por ambos Lo ms recomendable es que haya representantes de ambas partes El usuario/cliente puede redactar un borrador inicial y despus revisarlo con el proveedor

NATURALEZA DEL SRS (cont.)

Funcionalidades deseadas Interfaces externas Desempeo

Atributos (seguridad, portabilidad, mantenibilidad, etc.)

Restricciones de diseo impuestas a la implementacin (estndares tcnicos propios o internacionales, lenguaje de progr., sistema operativo, lmites de recursos, polticas internas).

AMBIENTE DEL SRS

El SRS es la fuente principal para hacer el plan detallado de un proyecto de software Un SRS puede referirse a los requerimientos deseados de todos los componentes de un sistema grande, o a componentes (mdulos) individuales del mismo

AMBIENTE DEL SRS

Si se hacen SRS por separado para varios mdulos, tiene que mantenerse la consistencia en los documentos

Si un software necesita interactuar con otro, tienen que especificarse los requerimientos de esa interaccin (interfaces), definiendo sus funcionalidades y el nivel de desempeo deseado

CARACTERSTICAS DE UN BUEN SRS

Correcto No ambiguo Completo Consistente Ordenado con base en importancia y/o estabilidad Verificable Modificable Rastreable

Correctez

El SRS es correcto si los requerimientos escritos son aquellos que el software deber cumplir
No hay un mtodo para saber si el SRS es correcto; lo importante es que se pida lo que realmente se necesita

No ambiguo

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

Ejemplos: planta, obra, maestro, carga, flecha

No ambiguo (cont.)

Problema: El usuario/cliente y el desarrollador generalmente tienen diferentes perfiles profesionales, y por ello describen los requerimientos en diferente forma Problema: Las descripciones que pudieran ser ms claras para el desarrollador, podran ser difciles de entender para el usuario, y viceversa.

No ambiguo (cont.)

El lenguaje natural es inherentemente ambiguo; por ello, es conveniente que el SRS sea revisado por un tercero que no haya participado en la redaccin Se han creado lenguajes formales para especificacin de requerimientos de software, que se basan en reglas matemticas y lgicas para evitar la ambigedad (como la Notacin Z, ISO/IEC Z Standard 13568:2002)

Ejemplo de uso de Notacin Z

RAdd Birthday Birthday Book name?: NAME date?: DATE result!: REPORT

(name? known
birthday= birthday {name? result!= ok) V Date?}

(name? known
birthday = birthday result != already_known)

No ambiguo (cont.)

Mtodos de representacin de requerimientos:

Basados en objetos: identificar clases de objetos similares (alumno, empleado, producto, etc.). Basados en procesos (compras, ventas, cobranza) Basados en conductas (la conducta de un robot)

COMPLETO

El SRS es completo si incluye:

Todos los requerimientos significativos sobre funcionalidades, desempeo, restricciones de diseo, atributos, o interfaces externas Las respuestas que debera dar el software a todas las posibles entradas de datos en todas las situaciones posibles (entradas aceptables o no aceptables: validacin) Especificacin de unidades de medida (si son aplicables) En caso de que el SRS tenga diagramas o tablas informativas, hay que darles nmero o identificacin

CONSISTENTE

Los diversos requerimientos escritos tienen que ser compatibles entre s; no debe haber contradicciones ni conflictos entre ellos. Para lograr la consistencia deben evitarse los siguientes conflictos:

En caractersticas especificadas de objectos del mundo real De lgica o de tiempo entre dos actividades Referencia a un mismo objeto del mundo real pero usando diferentes palabras para el mismo objeto

ORDENADO POR GRADO DE IMPORTANCIA O ESTABILIDAD

Cada requerimiento especificado debe tener alguna identificacin (nmero, letra, secuencia alfanumrica) para indicar su grado de importancia o de estabilidad
Algunos requerimientos son ms importantes que otros Al rankearlos se puede dar a cada requerimiento la atencin que se merece

ORDENADO POR GRADO DE IMPORTANCIA O ESTABILIDAD

Grado de estabilidad: nmero de cambios que se podran esperar para un requerimiento, debido a eventos futuros que afecten a la organizacin, las responsabilidades, y las personas que usarn el software
Grado de necesidad:

Esencial Condicional Opcional

VERIFICABLE

Un requerimiento es verificable si existe algn mtodo rentable mediante el cual se pueda analizar si el software cumple ese requerimiento. Ejemplo:

La respuesta del programa deber darse dentro de los 20 seg posteriores a la apertura de la vlvula VX389, y debe responder correctamente en el 60% de los casos El programa tiene que funcionar bien

Contraejemplo (algo no verificable):

VERIFICABLE (cont.)

Si no existe algn mtodo para saber si el software cumple o no un requerimiento, entonces ese requerimiento debe ser revisado o eliminado.

MODIFICABLE

Es modificable si la estructura y estilo de redaccin permiten la realizacin de cambios en forma fcil, completa y consistente Para esto es recomendable:

Incluir ndice, tabla de contenido y tabla de referencias cruzadas Cada requerimiento debe aparecer slo una vez (la redundancia propicia errores de inconsistencia) Poner cada requerimiento separado de los dems

RASTREABLE

Cada requerimiento debe identificarse con algn nmero, letra o secuencia alfanumrica Un SRS es rastreable si el origen de cada requerimiento es claro, y si facilita el seguimiento de cada requerimiento a lo largo del proyecto de software Dos tipos de rastreabilidad:

Hacia atrs: en cada requerimiento se menciona explcitamente su fuente documental Hacia delante: los documentos que se deriven del SRS deben usar las identificaciones de requerimientos como fueron dadas en el SRS

RASTREABLE (cont.)

La rastreabilidad hacia delante facilita las actividades de diseo, codificacin, y modificacin del software.

PREPARACIN CONJUNTA DEL SRS

El desarrollo de un software solamente debera iniciar cuando el cliente y el proveedor estn de acuerdo acerca de lo que el software deber hacer

EVOLUCIN DEL SRS

Un SRS puede necesitar cambios mientras el software est en etapas de diseo o de desarrollo
Los cambios pueden estar motivados por: deficiencias, errores, omisiones o imprecisiones en el documento original Cada requerimiento debe documentarse tan completo como sea posible, an si pudiera necesitar cambios posteriormente

EVOLUCIN DEL SRS

Los cambios en los requerimientos tienen que documentarse con el propsito de: identificarlos, controlarlos, rastrearlos, y reportarlos Tanto el cliente como el proveedor deben designar a su respectivo responsable de autorizar (o rechazar) cambios en los requerimientos

CREACIN DE PROTOTIPOS

Un prototipo es un pequeo programa parecido al software solicitado que sirve de ejemplo, muestra o modelo para que el cliente vaya especificando sus requerimientos en forma progresiva junto con el desarrollador

CREACIN DE PROTOTIPOS

El prototipo es til para:

Que el cliente/usuario vea y describa ms fcilmente las funcionalidades que desea

Prever aspectos de la conducta del sistema, haciendo que el SRS sea ms completo y preciso
Reducir la cantidad de cambios durante las etapas de diseo o desarrollo

CREACIN DE PROTOTIPOS (cont.)

Un prototipo puede ayudar al usuario a definir detalles especficos de la interfaz humana o de las funcionalidades que requiera Puede facilitarle al desarrollador el diseo y la programacin del software

DISEO IMPLCITO EN EL SRS

Aunque el SRS no constituye un documento de diseo, implcitamente est dicindole a los desarrolladores lo que se espera que ellos diseen

Establece restricciones

El SRS tiene que especificar las funcionalidades que se aplicarn sobre ciertos datos para producir resultados en cierto lugar para determinados usuarios

Lo que generalmente no necesita escribirse en el SRS

Cmo se deben organizar los mdulos del software Cmo se deben asignar funcionalidades especficas a cada mdulo Cmo ser el flujo de datos o el control de ejecucin de los mdulos Eleccin de estructuras de datos que se usarn dentro del cdigo

Sin embargo

Algunas situaciones especiales pueden inducir requerimientos estrictos de diseo Ejemplo: las restricciones de seguridad contra ataques en Internet pueden requerir que:

Algunas funcionalidades del software se localicen en mdulos (programas) separados Slo se permita una comunicacin limitada entre ciertos mdulos Se verifique la integridad de datos para variables crticas

Ms ejemplos de restricciones en diseo

Requerimientos fsicos (ej. peso en el shuttle) Requerimientos de desempeo Uso de estndares de desarrollo de software Estndares de aseguramiento de la calidad del software Los requerimientos se establecen siempre desde el punto de vista del usuario/cliente

REQUERIMIENTOS DE PROYECTO IMPLCITOS

El SRS se enfoca en el software como producto, no en su proceso de creacin Implcitamente establece restricciones sobre la planeacin y administracin del proyecto correspondiente

REQUERIMIENTOS DE PROYECTO IMPLCITOS (cont.)

El SRS da origen a otros documentos (por separado) relacionados con el ciclo de vida de un software

Estimacin de costos (cmo calcularlos?) Fechas de entrega Reportes de avances Mtodos de desarrollo Aseguramiento de la calidad Criterios de validacin y verificacin Procedimientos de aceptacin

CONTENIDO Y ORGANIZACIN TPICOS DE UN SRS

( Del documento ) ( Del software )

Contenido y organizacin tpicos de un SRS

CONTENIDO DE UN SRS

SECCIN 1: INTRODUCCIN Debe incluir una descripcin general del SRS, mostrando lo siguiente: 1.1 Propsito del documento 1.2 Alcance 1.3 Definiciones, acrnimos, y abreviaturas 1.4 Referencias 1.5 Descripcin general del documento

CONTENIDO DE UN SRS
1.1 Propsito del documento: aqu se tiene que:
Explicar

para qu se usar el documento

Especificar

a qu tipo de lectores est destinado (usuarios, clientes, analistas, programadores, etc.)

CONTENIDO DE UN SRS
1.2 Alcance Aqu se tiene que:
Identificar por su nombre genrico (y especfico) el producto(s) de software que se estn requiriendo; por ejemplo: sistema de administracin de inventario, generador de reportes, sistema manejador de bases de datos marca SperX, etc.)

Explicar lo que el software har, y, si fuera necesario aclararlo, tambin lo que no se espera que haga

CONTENIDO DE UN SRS
1.2 Alcance Aqu se tiene que:
Describir para qu se aplicar el software, incluyendo sus beneficios relevantes, objectivos, y metas Ser consistente con las disposiciones que se hayan dado en especificaciones de mayor nivel jerrquico (si existen); por ejemplo, las de algn sistema de mayor jerarqua

CONTENIDO DE UN SRS
1.3 Definiciones, acrnimos, y abreviaturas
Dar las definiciones de todos los trminos, acrnimos (siglas) y abreviaturas que sean pertinentes para el adecuado entendimiento del SRS Esta informacin puede ofrecerse mediante referencias a uno o ms apndices del SRS o referencias hacia otros documentos (manuales de la organizacin, procedimientos de aseguramiento de calidad, hojas de registro, etc.)

CONTENIDO DE UN SRS
1.4 Referencias
Ofrecer una lista completa de todos los documentos a los que se haga referencia en el SRS Identificar cada documento mediante su ttulo, nmero de reporte (si es aplicable), fecha, y organizacin que lo public Especificar las fuentes de las cuales pueden obtenerse los documentos referenciados Esta informacin puede ofrecerse haciendo alusin a un apndice o hacia otro documento

CONTENIDO DE UN SRS
1.5 Descripcin gral. del documento
Describir lo que contienen las secciones restantes del documento Explicar cmo est organizado

CONTENIDO DE UN SRS

SECCIN 2: DESCRIPCIN GRAL. DEL SOFTWARE

Aqu no se establecen los requerimientos especficos, sino que se describe el fondo general que da lugar a los requerimientos, los cuales se definen detalladamente hasta la seccin 3 del SRS; sto los hace ms fciles de entender.

CONTENIDO DE UN SRS

SECCIN 2: DESCRIPCIN GRAL. DEL SOFTWARE

Usualmente se incluyen estas 6 subsecciones: 2.1 Perspectiva del software 2.2 Funciones del software 2.3 Caractersticas del usuario 2.4 Restricciones 2.5 Suposiciones y dependencias 2.6 Posposicin de requerimientos

CONTENIDO DE UN SRS
2.1 Perspectiva del software

Describir el software en perspectiva con otros software relacionados: similitudes y diferencias Si el software es independiente y totalmente autocontenido, eso tiene que decirse aqu. Si se est requiriendo un software que formar parte de un sistema ms grande, se tiene que describir la relacin de los requerimientos del sistema grande con las funcionalidades del software requerido y debe identificarse cmo se comunicarn ambos

CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.)

Para describir las relaciones entre el software requerido y el sistema grande, pueden ser tiles los diagramas de bloques En los diagramas de bloques se pueden mostrar los componentes principales del sistema grande y su relacin jerrquica (y de flujo de datos) con el software requerido

Ejemplo de diagrama de bloques: Sistema para Inscripciones

1.0
Estudiante Cursos

solicitados

Mdulo para Verificar disponibilidad

Cursos disponibles
Archivo de cursos

Carta de confirmacin

Cursos autorizados

Detalles de curso

3.0
Mdulo para Notificar inscripcin

2.0
Registro
Mdulo para Inscribir al estudiante

Inscripcin a curso

Datos estudiante

Archivo de estudiantes

Basado en Laudon & Laudon. Sistemas de Informacin Gerencial. Prentice-Hall. Mxico, 2002.

Ejemplo de diagrama de bloques: Sistema para Inscripciones

3.0
Mdulo para Notificar inscripcin

Este podra ser un software que estamos requiriendo, que formara parte del sistema grande

Basado en Laudon & Laudon. Sistemas de Informacin Gerencial. Prentice-Hall. Mxico, 2002.

CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.)

Describir las condiciones (restricciones) dentro de las cuales deber funcionar el software: 2.1.1 Interfaces de sistema (*) 2.1.2 Interfaces de usuario 2.1.3 Interfaces de hardware 2.1.4 Interfaces de software 2.1.5 Interfaces de comunicaciones 2.1.6 Restricciones de memoria 2.1.7 Operaciones 2.1.8 Requerimientos de adaptacin a un lugar (*) Qu es una interfaz?

CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.) 2.1.1 Interfaces de sistema: lo que hay entre los diversos mdulos del sistema

Enumerar cada interfaz de sistema Descripcin de la interfaz del software para hacerlo compatible con el sistema

Veamos los mdulos...

1.0
Estudiante Cursos
Mdulo para Verificar disponibilidad

solicitados

Cursos disponibles
Archivo de cursos

Carta de confirmacin

Cursos autorizados

Detalles de curso

3.0
Mdulo para Notificar inscripcin

2.0
Registro
Mdulo para Inscribir al estudiante

Inscripcin a curso

Datos estudiante

Archivo de estudiantes

1.0
Estudiante Cursos

solicitados

Mdulo para Verificar disponibilidad

Cursos disponibles
Archivo de cursos

Carta de confirmacin

Cursos autorizados

Detalles de curso

3.0
Mdulo para Notificar inscripcin

2.0
Registro
Mdulo para Inscribir al estudiante

Inscripcin a curso

Datos estudiante

Archivo de estudiantes

Lo que hay entre los mdulos...

1.0
Mdulo para Verificar disponibilidad

Cursos autorizados

I.S.

I.S. significa Interfaz de sistema

3.0
Mdulo para Notificar inscripcin

I.S.
Registro

2.0
Mdulo para Inscribir al estudiante

Basado en Laudon & Laudon. Sistemas de Informacin Gerencial. Prentice-Hall. Mxico, 2002.

Lo que hay entre los mdulos...

Lo que hay entre los mdulos es flujo de informacin; por lo tanto se tiene que especificar qu informacin alimenta a cada uno de los mdulos que sean requeridos
Hay que especificar cmo es esa informacin (numrica, alfanumrica, rango de valores posibles, unidades de medida, etc.)

CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.2 Interfaces de usuario: lo que estar entre el usuario y el software Definir las caractersticas de :

Ventanas Colores Formatos y tamaos de letra Mens conos, botones Contenido de los reportes impresos Interfaz mediante A.S.R. y/o sntesis de voz Realidad virtual Otras interfaces usuario/mquina (electrodos)

CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.3 Interfaces de hardware: qu hardware usar el software para entrada/salida de informacin, incluyendo:

Caractersticas de configuracin (nmero de puertos de comunicacin, instruction sets, etc.). Qu dispositivos de hardware sern soportados por el software,y n qu forma sern soportados Protocolos de transferencia de datos entre dispositivos

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

CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.4 Interfaces de software: qu otros software se necesitarn para que el software requerido pueda funcionar, por ejemplo:

Sistemas operativos: Windows, Linux, AIX, Solaris, etc. Sistemas manejadores de bases de datos: Oracle, Sybase, MySQL, DB2, etc. Intrpretes de lenguajes (como PERL) Shells para sistemas expertos (como Sictus Prolog) Paquetes comerciales para ejecutar programas que usan redes neuronales (como MatLab)

Tambin los programas para que el software pueda interactuar con los dems mdulos

CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.5 Interfaces de comunicacin:
Qu tecnologa de redes se usar para comunicar a las computadoras en las cuales se usar el software:

Nombre genrico de la tecnologa: LAN, WAN, MAN, VPN, WWW, WiFi, etc. Topologa de la red: anillo, estrella, bus Protocolos de comunicacin: Ethernet, TCP/IP, ATM, FrameRelay, PPP Tipo de cableado: fibra ptica, par trenzado, coaxial

CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.6 Restricciones de memoria Se debe especificar si existe o no algn lmite en cuanto a la memoria (tanto primaria como secundaria) que podr tener disponible el software para ser ejecutado
Memoria primaria: la RAM (Random Access Memory) Memoria secundaria: disco, cinta

CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.7 Operaciones Especificar los diferentes modos de operacin del software por parte del usuario, por ejemplo:

Operaciones normales versus especiales (inscribir alumno versus respaldo de archivos) Operaciones interactivas y actividades que no requieran atencin del usuario Operaciones iniciadas por el usuario versus operaciones que se activen automticamente

CONTENIDO DE UN SRS
2.1 Perspectiva del software
2.1.8 Adaptacin a un lugar especfico

Definir los requerimientos respecto a datos o secuencias de inicializacin del software que sean especficas para un lugar, una misin o un modo operacional especfico

Especificar las caractersticas relacionadas con el lugar o la misin que deban ser modificadas para adaptar el software a una instalacin especfica

CONTENIDO DE UN SRS
2.2 Funciones del producto Sumario de las funciones principales; por ejemplo, para el caso de un software de contabilidad se mencionra 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.3 Caractersticas de los usuarios Describir sus caractersticas respecto a: Nivel educativo Experiencia profesional Capacidades tcnicas. Esta descripcin ayuda a comprender los motivos que dan origen a los requerimientos.

CONTENIDO DE UN SRS
2.4 Restricciones
Informacin sobre posibles limitantes que debern respetar los diseadores, como: a) Polticas regulatorias aplicables b) Limitaciones en el hardware (p.ej. velocidad del microprocesador) c) Interfaces hacia otras aplicaciones d) Funcionamiento en paralelo e) Funciones de auditora de software

CONTENIDO DE UN SRS
2.4 Restricciones (cont.)
f) Protocolos de comunicaciones de redes g) Requiremientos de confiabilidad h) Criticidad de la aplicacin i) Consideraciones sobre seguridad fsica y lgica

CONTENIDO DE UN SRS
2.5 Suposiciones y dependencias
Cada uno de los factores que afecten a los requiremientos especificados. Estos factores no son restricciones de diseo para el software, sino >>>>>>but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption may be that a specic operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly.

CONTENIDO DE UN SRS
2.6 Distribucin (apportioning) de requerimientos
Aqu se dice cules son los requerimientos que pueden atenderse hasta versiones futuras del sistema

Organizacin de los requerimientos especficos (Seccin 3)

Para lograr un mejor entendimiento de los requerimientos, conviene organizarlos con base en alguno de los siguientes criterios: Por modo de operacin del sistema Por clase de usuario Por objetos Por caractersticas Por estmulos Por respuestas Por jerarqua funcional

Organizacin de los requerimientos especficos (Seccin 3)

Por modo de operacin del sistema

P. ej. si se desea un sistema de control para una planta industrial, sus modos de operacin podran ser: modo de entrenamiento, modo normal, y modo de emergencia Hay que definir las funcionalidades del sistema para cada tipo de modo Usar las plantillas A.1 o A.2, la primera si los diversos modos de operacin requieren diferentes interfaces; la segunda si requieren diferentes tipos de desempeo

Organizacin de los requerimientos especficos (Seccin 3)

Por clase de usuario

Algunos sistemas ofrecen diferentes conjuntos de funciones para cada tipo de usuario. P. ej., un sistema de sucursal bancaria ofrece diferentes funciones para el personal de cajas, para los ejecutivos de cuenta o para el gerente

Usar plantilla A.3

Organizacin de los requerimientos especficos (Seccin 3)

Por objetos

Objetos son entidades del mundo real que tienen una representacin dentro del sistema. P. ej. un sistema de monitoreo de pacientes incluye pacientes, sensores, enfermeras, habitaciones, mdicos, medicinas, etc.

Para cada objeto se define un conjunto de atributos y funcionalidades (denominadas servicios o mtodos). Usar plantilla A.4

Organizacin de los requerimientos especficos (Seccin 3)

Por caractersticas

Una caracterstica es una funcionalidad del sistema que puede requerir una secuencia de entradas de datos para producir un resultado o una accin Ej. en la programacin de los circuitos de un aparato telefnico, las caractersticas son: llamada local, transferencia de llamada, y llamada en conferencia (conference call) Cada caracterstica se describe generalmente como una secuencia de pares de estmulo-respuesta Usar plantilla A.5

Organizacin de los requerimientos especficos (Seccin 3)

Por estmulos

>>>

Organizacin de los requerimientos especficos (Seccin 3)

Por respuestas

>>>

Organizacin de los requerimientos especficos (Seccin 3)

Por jerarqua funcional

Cuando ninguna de las plantillas resulta til, la funcionalidad general del sistema puede organizarse en una jerarqua de funciones, ya sea con base en entradas comunes, salidas comunes, o accesos comunes a los datos

Se pueden usar diagramas de flujo de datos y diccionarios de datos para mostrar las relaciones entre las diversas funciones, entre los diversos datos, y entre las funciones y los datos
Usar plantilla A.7

Preguntas o comentarios?