Está en la página 1de 93

M.C.

Mara Guadalupe Monjars Velasco

Temario
Requerimientos de proceso. Requerimientos de los usuarios (actores involucrados). Requerimientos para el anlisis y negociacin. Requerimientos para la gestin.

Qu son los requeriemientos


De acuerdo al IEEE: Una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo Propiedades o restricciones determinadas de forma precisa que deben satisfacerse. Una condicin o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificacin u otro documento formal.

Requerimientos funcionales y no funcionales


Los requerimientos/requisitos de un sistema describen los servicios que ha de ofrecer el sistema y las restricciones asociadas a su funcionamiento. Requerimientos funcionales Expresan la naturaleza del funcionamiento del sistema (cmo interacciona el sistema con su entorno y cules van a ser su estado y funcionamiento).
NOTA: A veces, tambin es conveniente indicar lo que no har el sistema.

Requerimientos no funcionales Restricciones en el espacio de posibles soluciones: Rendimiento del sistema: fiabilidad, tiempo de respuesta, disponibilidad Interfaces: dispositivos de E/S, usabilidad, interoperabilidad Proceso de desarrollo: estndares, herramientas, plazo de entrega
NOTA: La distincin entre requerimientos funcionales y no funcionales no siempre resulta evidente (p.ej. la seguridad puede interpretarse inicialmente como un requerimiento no funcional al principio pero, tras elaborarlo, conduce a la aparicin de requerimientos funcionales como la necesidad de autentificar a los usuarios del sistema).

La Ingeniera de Requerimientos es un conjunto de actividades en las cules, utilizando tcnicas y herramientas, se analiza un problema y se concluye con la especificacin de una solucin (Ortas 1997).

Ingeniera de Requerimientos
La IR es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto (IBM Rational). Es un proceso de descubrimiento y comunicacin de las necesidades de clientes y usuarios y la gestin de los cambios de dichas necesidades (Duran 2000).

Visin del proyecto

SRS: Software Requirement Specification Una especificacin de Requerimientos de Software (ERS) es un documento que contiene una descripcin completa de qu har el software sin describir cmo lo har.

Por qu son importantes?


De los requerimientos dependen todas las dems actividades del proceso de desarrollo de software Lo que se pretende con una buena Ingeniera de Requerimientos es reducir costos y retrasos del proyecto, mejorar la calidad del software, evitar el rechazo de los usuarios finales entre otras cuestiones.

Entre ms tarde detecte un error en el ciclo de vida del desarrollo de software, ms caro costar repararlo.

Proceso de Ingeniera de Requerimientos


Participacin del usuario
Requerimientos del usuario Retroalimentacin del usuario

Estudio de factibilidad

Especificacin de requerimientos

Modelos a validar por el usuario

Obtencin y anlisis
Conocimiento

Especificacin
Modelo de requerimientos

Validacin

Necesidad de ms conocimiento

Resultado de validacin

Para todos los sistemas nuevos, el proceso de la Ingeniera de Requerimientos empieza con el estudio de Factibilidad. La entrada de este es una descripcin resumida del sistema y de cmo se utilizar dentro de la organizacin. El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la Ingeniera de Requerimientos y el proceso del desarrollo del sistema.

Algunos autores manejan los conceptos de viabilidad y factibilidad. Cuando se habla de factibilidad se habla de que se puede hacer y cuando es viabilidad de que se puede llevar acabo (sostener/mantener)
ORGANIZACIN SIRVE?

SI

INGENIERIA DE REQUERIMIENTOS

Es el proceso que sirve para determinar el dominio de la aplicacin, cuales servicios debe proporcionar el sistema, as como su desempeo requerido, las restricciones de hardware, etc. Se trabaja estrechamente con los usuarios a fin de conocer la problemtica en detalle.

Las actividades que cubre son: Comprensin del dominio Recoleccin de requerimientos Clasificacin de requerimientos Resolucin de conflictos Priorizacin Verificacin de requerimientos

Especificacin de Requerimientos Verificacin de Requerimientos DOCUMENTO DE REQUERIMIENTOS

Comprensin del dominio

Priorizacin

Recoleccin de Requerimientos

Resolucin de conflictos

Clasificacin

PROCESO DE OBTENCION Y ANLISIS DE REQUERIMIENTOS

Los requerimientos pueden ser funcionales (explcitos) o no funcionales (implcitos). Las caractersticas que deben perseguir los requerimientos son: necesario, conciso, completo, consistente, no ambiguo, verificable. Los problemas que presenta la Ingeniera de Requerimientos son tress:

1.

Los requerimientos no son obvios y provienen de muchas fuentes. Son difciles de expresar en palabras. Un requerimiento puede cambiar en el transcurso del proyecto. El xito de la obtencin de requerimientos consiste en ponernos en los zapatos de nuestros clientes y no desarrollando a nuestros gustos.

2. 3.

Para obtener requerimientos se siguen muchas tcnicas. Las ms populares son las entrevistas y cuestionarios. Tips para Disear Cuestionarios: Es necesario realizar un muestreo de los datos para encontrar necesidades. Las preguntas deben ser realmente significativas, sino no sirven.

Se debern poner escalas (preguntas cerradas) para cuantificar lo que se pretende. Con los resultados obtenidos se debe de realizar un anlisis estadstico para poder sacar conclusiones. Por lo tanto, las preguntas de un cuestionario deben de estar orientadas hacia solucionar dichas dudas.

Tips para realizar entrevistas: Utilizar una tcnica de rombo de preguntas cerradas, abiertas y cerradas. Observacin del mundo. Tener un guin flexible (improvisacin). Se debe tener facilidad de palabra y nunca perder el objetivo de la entrevista.

Los Sistemas Existentes son otra buena forma de hacer extraccin de requerimientos basndose en software ya existente dndole oportunidad a los clientes de observar interfaces, funcionalidades para sus proyectos. Grabaciones de Audio y Video: Se pueden utilizar como registro histrico o para analizar con mayor detenimiento una entrevista.

Permiten centralizarse en la entrevista ms que en el registro. La Arqueologa de Documentos ayuda a determinar posibles requerimientos sobre la base de inspeccionar la documentacin utilizada por la empresa; por ejemplo, boletas, facturas, remisiones, etc. Responde a preguntas como: Cul es el propsito de este documento?

Quin lo usa? Por qu? Para qu? Cules son las tareas que realizan con este documento? La tcnica del aprendiz es otra buena tcnica de Ing. De Requerimientos. El aprendiz es el analista mientras que el maestro es el cliente/usuario. El aprendiz se sienta con el maestro con el objetivo de aprender a travs de la observacin y de la realizacin de preguntas.

El aprendiz se sienta con el maestro con el objetivo de aprender a travs de la observacin y de la realizacin de preguntas. Estas tcnicas aunque muy bsicos son parte fundamental de la elicitacin de requerimientos. Se siguen utilizando ampliamente.

Las Tecnologas de Informacin y Comunicaciones se pueden aplicar de forma fcil y sencilla a las herramientas de Ingeniera de Requerimientos. Entre estas nuevas tecnologas se encuentran los blogs, wikis, redes sociales, podcasting, etc. Estas tecnologas sern utilizadas en el proyecto.

En el proyecto en su primera entrega (SRS). Se tendrn que aplicar forzosamente las tcnicas de entrevista (podcasting), cuestionario (blog, foro de discusin, red social) y llevar un control de cambios con un Wiki.

Cmo implementarlo? La entrevista se graba el audio en MP3 y se sindicaliza con RSS (podcasting) si es video se hace algo similar subindolo a un sitio de videos, podcasting. *Si se van a manejar diagramas se recomienda subirlo a un albm de fotos como flickr. Si se ocupa anexar documentos pueden subirse a portales de documentos como slideshare, scribd.

Para el cuestionario en cualquier blog como blogspot, twitter; foro de discusin o grupo de red social. Deber ser evidente que tanto el aplicador de la encuesta (ustedes) como el que la contesta (cliente/usuario final) son diferentes. En el Wiki se ir depurando el documento final de SRS. Todos debern realizar observaciones.

Cada parte vale 5% (para un total de 15%) de los 25 puntos. Recordar que para todos los trabajos en equipo se deber dejar bien claro cuales fueron las responsabilidades de cada quien dado que la calificacin se manejar 70 rendimiento individual y 30% grupal.

RFP/ Solicitud de Propuesta


RFP (Request for Proposal) es un documento en donde se especfica el desarrollo de un sistema o el uso de un bien o servicio. Las solicitudes de propuestas deben formularse en lenguaje claro, terminologa integral y formato estandarizado para facilitar la comprensin de los objetivos de los sistemas de la organizacin, por parte de los proveedores.

Stakeholders en Ing. Req.


Quines participan durante el proceso de Ingeniera de Requerimientos? Los supervisores del contrato Los clientes y los usuarios Los gerentes del negocio Los diseadores Los verificadores En metodologas agiles como Scrum se llaman Product Owners.

Factores de Calidad de McCall

Estndar ISO 9126

Documentacin de Req.
La especificacin de requerimientos es un acuerdo aprobado entre usuarios y desarrolladores del software y debe tener al menos las siguientes caractersticas: Contener todos los requerimientos deseados Cada requerimiento solo tiene una interpretacin posible.

Documentacin de Req.
El cumplimiento de cualquier requerimiento no debe provocar conflictos con el cumplimiento de otro requerimiento, es decir, que sea consistente. Prioridades definidas Especificados por escrito Posibles de probar o verificar Descritos como una caracterstica del sistema a entregar. Lo ms abstracto y conciso posible

Documentacin de Req.
Descritos como una caracterstica del sistema a entregar. Lo ms abstracto y conciso posible
Entendimiento

Lenguaje natural Lenguaje Metodologas estructurado (CASE,etc.) Especificaciones Formales

Precisin

Documentacin de Req.
Los requerimientos deben escribirse de modo que sean significativos no slo para los clientes, sino tambin para los diseadores que integran el equipo de desarrollo.
Clases de documentos de Requerimientos
Definicin de Requerimientos

Especificacin de Requerimientos

Definicin de Requerimientos
Est escrita en trminos que el cliente puede entender. Es un listado completo de todas las cosas que el cliente espera que haga el sistema propuesto. Es escrito en forma conjunta por el cliente y el desarrollador. Primero se perfila el propsito general del sistema. Se describen los antecedentes y los objetivos del desarrollo del sistema.

Definicin de Requerimientos
Si el cliente tiene un nuevo enfoque propuesto para resolver el problema, se perfila una descripcin del enfoque. Una vez registrada esta vista global del problema, se describen en detalle las caractersticas del sistema propuesto. Se definen el lmite del sistema y las interfaces que lo vinculan con el entorno.

Definicin de Requerimientos
Por ltimo, se discute el ambiente en el cul operar el sistema. Se incluyen requerimientos para el soporte, la seguridad y la privacidad.

Especificacin Requerimientos
Se escribe desde la perspectiva del desarrollador. Es la contrapartida tcnica al documento de definicin de requerimientos, y es escrito por analistas de requerimientos. Por ejemplo, el cliente no puede comprender la definicin de un requerimiento en trminos de una relacin matemtica compleja definida con una serie de ecuaciones.

Es una tcnica de Ingeniera de requerimientos que consiste en describir de manera amplia y detallada cada forma de operacin del sistema. Se pueden utilizar de todo tipo de organizadores grficos, van ms enfocadas al anlisis y especificacin de requerimientos. Las tcnicas mas utilizadas de este tipo son las historias de usuario y los casos de uso.

Son realizadas por los usuarios en forma de descripcin textual. Cuando se utiliza en forma grfica enfocadas a interfaces se denominan spikes. Se derivan de tcnicas como los sketches (borradores de la interfaz realizadas por los modeladores) y los storyboard (muestra de secuencia de navegacin)

Historia de Usuario
Nmero: 1 Usuario: Autor Modificacin de Historia Nmero: Prioridad en Negocio: Alta Puntos Estimados: (Alta / Media / Baja) Riesgo en Desarrollo: Puntos Reales: (Alto / Medio / Bajo) Iteracin Asignada: 2 Nombre: Enviar artculo

Descripcin: Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de los autores (nombre, email, afiliacin). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepcin del artculo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artculo.

Observaciones:

Los requerimientos del proceso son a nivel organizacional, describen el cmo, es decir, describen los procedimientos y polticas que las organizaciones deben seguir as como las restricciones que deben obedecer, por ejemplo, estndares usados en los procesos, los requerimientos de implementacin, etc.

Son todas sus necesidades, las cuales se traducen a los requerimientos de lo que esperan que un nuevo sistema realice y de las restricciones que lleva consigo. Un ejemplo de tales necesidades pueden ser las siguientes: Obtener soluciones a problemas en su trabajo bajo el sistema actual Una interfaz ms amigable, rpida de aprender, fcil de usar Un tiempo de respuesta ms corto, etc.

Requerimientos de usuario

Requerimientos del sistema

LENGUAJE COTIDIANO

LENGUAJE TCNICO

Cuando se estn investigando los requerimientos, el analista se encuentra con el problema de la comunicacin con el usuario pues el lenguaje cotidiano de ambos no es igual. Por ejemplo: Falta de claridad Conocen de manera muy general lo que desean obtener

No saben expresar o explicar lo que quieren del sistema Usan terminologas distintas Confunde los requerimientos funcionales y los no funcionales Confusin de requerimientos, pues expresan de varias formas un mismo requerimiento

Una vez identificados los requerimientos completos, consistentes y no ambiguos, se procede a clasificarlos. El analista debe hacerse la siguiente pregunta con cada uno de los requerimientos: El requerimiento es necesario o representa una caracterstica aadida que puede no ser esencial cuando se haya finalizado el sistema?

La razn de esta pregunta se debe a que es comn en clientes y usuarios solicitar ms de lo que puede realizarse, consumiendo recursos de negocios limitados, cmo sera el sobrepasar el presupuesto y el tiempo requerido para el desarrollo del sistema. La clasificacin de estos requerimientos es la siguiente:
requerimientos esenciales, aquellos que deben ser absolutamente satisfechos.

requerimientos deseables, que son importantes pero no indispensables. requerimientos opcionales, que son posibles pero que podran eliminarse

Despus de hacerse la clasificacin de requerimientos, el analista de sistemas realiza un proceso de negociacin con clientes, usuarios y el resto de los involucrados para resolver los conflictos relacionados con ciertos requerimientos segn su prioridad.

Parte de la negociacin de los requerimientos incluye identificar y analizar los riegos asociados a cada requerimiento adems de efectuar estimaciones de costo, tiempo y esfuerzo. Estas estimaciones ayudarn a una mejor eleccin de cules requerimientos tienen mayor prioridad que otros.

En esta actividad se incrementa la comunicacin entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos: Documentar todos los requerimientos a un nivel de detalle apropiado.

Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones

La gestin de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema y se lleva a cabo junto con el proceso de ingeniera de requerimientos. La planeacin comienza al mismo tiempo que la obtencin inicial de requerimientos y la administracin activa debe iniciar tan pronto est lista la primera versin del documento de requerimientos.

Se pueden utilizar tcnicas como la Lluvia de Ideas o anlisis FODA, el cual consiste en hacer una relacin entre elementos: Fortaleza: Factor interno positivo. Oportunidades: Factor externo positivo. Debilidades: Factor interno negativo. Amenazas: Factor externo negativo.

FODA industria Sw en Mxico


l l l l l l l l

FORTALEZAS Uso horario similar Afinidad cultural Proximidad y fcil traslado Menores costos de mano de obra Buena infraestructura aunque ms costosa TLCAN Estabilidad poltica Bajo riesgo geopoltico

l l l l l l

l l

DEBILIDADES Oferta limitada de mano de obra calificada Escaso manejo del ingls Niveles de certificacin de las empresas mexicanas Estructura de la industria de TI Temas de seguridad y corrupcin Falta de experiencia de las empresas en proyectos grandes de Mxico Acceso a capital Carga y legislacin laboral

l l

OPORTUNIDADES Asociacin con jugadores globales de desarrollo de TI canadienses Amplio espacio para el apoyo efectivo del gobierno Generar una masa crtica de mano de obra calificada

l l

AMENAZAS Alta competencia de pases emergentes en el mercado de TI (Brasil, Rusia, China y Filipinas) Incrementos en el costo de la mano de obra Constante innovacin tecnolgica

Una rbrica es un elemento que nos permite definir en forma tabular los requisitos que debe tener un producto en general y evaluarlos en base a un criterio determinado.

Rbrica
Requisito A (100) B (85) C (70) Z (0) Revisin de Fuentes Bibliogrficas (20%) Consulta al menos tres fuentes bibliogrficas formales y las cita adecuadamente (libros, revistas, artculos tcnicos) Consult fuentes pero fueron menos de tres o no estuvieron bien citadas Consulto alguna fuente bibliogrficas que no eran formal No cit o consulto fuentes

Presentacin del Trabajo (10%)

El trabajo se entrega con un portada, ndice, introduccin, desarrollo y conclusiones propias

Falt una seccin o est mal planteada.

Faltaron dos secciones o estn Faltaron 3 o ms secciones mal planteadas

Ejemplificacin de las funciones del SQA (70%)

Se cuentan con al menos tres descripciones de puestos ejemplificando con organizadores grficos u otro tipo de evidencia sustancia las funciones del SQA

Una descripcin de puestos no est ejemplificada adecuadamente

Dos descripciones de la funciones del SQA no estn ejemplificadas adecuadamente

Tres descripciones no estn ejemplificadas adecuadamente.

FURPS+
Creado por HP utiliza una matriz de valoracin. Funcional (Functional): caractersticas, capacidades y seguridad. Facilidad de Uso (Usability): factores humanos, ayuda, documentacin. Fiabilidad (Reliability): frecuencia de fallos, capacidad de recuperacin.

FURPS+
Rendimiento (Performance): tiempos de respuesta, productividad, precisin, disponibilidad, uso de los recursos Soporte (Supportability): adaptabilidad, facilidad de mantenimiento, internacionalizacin, configurabilidad.

FURPS+
+: Implementacin: limitacin de recursos, lenguajes y herramientas, hardware Interfaz: restricciones impuestas para la interaccin humana Operaciones: gestin del sistema Empaquetamiento Legales: licencias, auditorias, etc.

FURPS+
Req Consultas a travs de un celular F Debern realizarse a travs de SMS/MMS, la respuesta ser en MMS U Pocos movimiento s del teclado R P Optimizado para desplegar informacin importante S Soporte en Plataformas J2ME + Ejecutarse con Equipos Nokia serie 60

Sistema Web de Captura Indicadores

Seguridad por autenticaci n y huella digital

Optimizado para navegador Opera

Actividad
Del problema asignado (proyecto) realizar la rbrica para especificar al menos 5 requerimientos (de preferencia con FURPS). indicando las caractersticas de si se cumple o no la actividad. Para entregar por equipos integraron en sus proyectos. como se

Prototipos
Los prototipos son una excelente herramienta para la obtencin de requerimientos dado que el cliente puede ver elementos funcionales en operacin del proyecto. El problema es que es una tcnica muy costosa, motivo por el cual su utilizacin est muy restringida.

Prototipos

Prototipos

Componentes/Prototipos

Reglas 2011
No recarga de combustible Nuevo sistema de puntuacin Tope presupuestal por equipo de 44 millones de euros.

Prototipos
Los prototipos son versiones reducidas, demos o conjunto de pantallas (que no son totalmente operativos) de la aplicacin pedida. Esta tcnica es til cuando:
1.

El rea de aplicacin no est bien definida (puede ser algo novedoso)

Prototipos
2.

El costo del rechazo de la aplicacin es muy alto. Es necesario evaluar primeramente el impacto del sistema en la organizacin. La tcnica ayuda para visualizar la diferencia entre desarrolladores y usuarios.

3.

Prototipos
Aunque limitado, se dispone de un sistema funcional en las primeras etapas de desarrollo. Esta tcnica se resume en: No s exactamente lo que quiero, pero lo sabr cuando lo vea Es una tcnica costosa

Chasis bsico: $450,000. Motor: no se venden de manera individual Llantas: 28 llantas por evento con un costo de $1,200 por juego, alrededor de $150,000 al ao Costo equipo: 50 personas

Otras partes: $150,000 de refacciones y $350,000 de partes de la caja de velocidades. Costo transporte: $500,000 al ao de transporte. Total: mnimo 2 millones, en promedio de 5-10 millones de dlares

En equipos de 2 Personas se deber crear un prototipo de avin de papel el cual deber ser aquel que en las pruebas de ensayo llegue ms lejos. Ganar el equipo que con el recurso disponible y las restricciones de tiempo realice bien cada uno de los pasos indicados en la actividad.

Paso 1: Poner nombre a los equipos. Paso 2: Escoger un lder de proyecto. Paso 3: Diferenciar roles entre los equipos de trabajo: diseador, probador, constructor, etc. (Paso 1 a 3: 10%)

Paso 4: Elaborar especificacin de prototipo (50%). En este caso se debe tener un diseo claro que permita la construccin a gran escala del mismo. Cada equipo es responsable de su material, todos los equipos cuentan con igual recurso.

Paso 5: Personalizar su prototipo con algn detalle y mostrar las mejoras realizadas (la presentacin se hace hasta el final) (10%) Paso 6: Construccin y elaboracin del prototipo a gran escala (20%).

Paso 7: Se escogern una muestra aleatoria de dos aviones para la realizacin de la comprobacin de la calidad (10%).

JAD
Joint Application Development, Desarrollo Conjunto de Aplicaciones es una tcnica que consiste en realizar sesiones conjuntas entre los analistas de sistemas y los expertos del dominio. Con esta tcnica se obtienen sistemas ms enfocados a la realidad, muchas metodologas nuevas se fundamentan en esta premisa.

JAD
Por qu JAD funciona? Por que las entrevistas son lentas, difciles de hacer y complicadas de obtener datos. Al ser muchos revisores del proyecto es ms fcil detectar errores. Problema: se requiere de mucha organizacin

JAD
Implementacin Efectiva de Sistemas Informticos desde los puntos de vista Humano y Tcnico. Fue desarrollada en 1979 por E. Mumford, se enfoca en los aspectos sociales que estn presentes en el desarrollo del software, dado que un sistema no tendr xito sino es utilizado eficientemente por los empleados.

VORD
Existen mtodos que toman los puntos de vistas de los usuarios para encontrar cosas en comn, un ejemplo es VORD (Definicin de Requerimientos Orientados a Puntos de Vista). VORD consiste de los siguientes pasos: Identificacin de puntos de vista Estructuracin de dichos puntos de vista

VORD
Documentacin de puntos de vista (refinacin) Trazado del punto de vista (conversin a un diseo orientado a objetos)

Etnografa
Es una tcnica de observacin que se puede utilizar para entender los requerimientos sociales y organizacionales. Se centra en los siguientes aspectos: La forma en la que las personas trabajan y no como el sistema los hace trabajar Los requerimientos se derivan de la cooperacin de muchas personas

Actividad
En los equipos de trabajo realizar un prototipo no funcional del sistema en donde se muestren sus interfaces. Puede ser a travs de bosquejos (spikes), utilizando herramientas de diagramacin (por ejemplo: Visio), utilizando herramientas RAD (Rapid Application Development) como Visual Basic, HTML, NetBeans, etc. Entregar al finalizar la clase o mucho a la siguiente.

Qu requerimientos hay?

SRS
El estndar IEEE/ANSI 830-1998 sugiere el uso del siguiente formato para SRS: 1 Introduccin 1.1 Propsito del documento de requerimientos 1.2 Alcance del producto 1.3 Definiciones, acrnicos y abreviaturas 1.4 Referencias 1.5 Descripcin del resto del documento

SRS
2. Descripcin General 2.1 Perspectiva del producto 2.2 Funciones del producto 2.3 Caractersticas del usuario 2.4 Restricciones generales 2.5 Suposiciones y dependencias 3. Requerimientos especficos: incluye requerimientos funcionales, no funcionales y de interfaz.* Es la parte medular.

SRS
No hay estructura para esta seccin. Debe incluir requerimientos del usuario y del sistema. Se debe incluir una seccin para requerimientos cambiantes. 4. Apndice (anexo de todo su proceso de obtencin de requerimientos) 5. ndice

SRS
La seccin 3 contiene por categoras y ordenados por prioridad todos los requerimientos finales del software. En la etapa de anexos deber visualizarse la forma en como llegaron a obtener, analizar, especificar y validar requerimientos. Consultar documento de especificacin de SRS en la pgina Web del sitio