Requerimientos Funcionales y No Funcionales

Unidad II Especificacin de Requerimientos de Software Unidad Curricular Ingeniera de Software II; Modulo: FUNDAMENTOS DE INGENIERA DE REQUISITOS Y ANLISIS
Tabla de contenido Tabla de contenido.............................................................................................................1 1.Requerimientos funcionales y no funcionales ...............................................................2 1.1.Requerimientos funcionales .......................................................................................2 1.2.Requerimientos no funcionales ..................................................................................3 2.Requerimientos del dominio ..........................................................................................4 3.Requerimientos del usuario y del sistema .....................................................................5 3.1.Requerimientos del usuario ........................................................................................5 3.2.Los requerimientos del sistema ..................................................................................5 4.Lenguaje o notacin usada en la especificacin de requerimientos...............................6 4.1.Diagrama de caso de uso.............................................................................................6 4.2.Diagrama de Estados y Diagrama de Actividades.......................................................8 4.3.Ejemplo de especificacin de requerimientos usando los diagramas de casos de uso y actividad........................................................................................................................10 4.4.Notacin textual de los requerimientos.....................................................................13 5.Obtener o escribir requerimientos de alta calidad........................................................14 6.Estndares de la documentacin de los requerimientos .............................................16
En esta unidad se tiene como objeto establecer los conceptos y fundamentos involucrados en la especificacin de requerimientos donde el alumno entender los diferentes tipos de requerimientos funcionales, no funcionales, del dominio, del usuario y del sistema. As como se demostrara con ejemplos el uso del lenguaje UML, para la declaracin de los requerimientos. Continuando con las caractersticas y actividades involucradas en la obtencin de requerimientos de calidad, con ejemplos de declaraciones malas y buenas. Y por ltimo se describe el documento de requerimientos de IEEE.
1. Requerimientos funcionales y no funcionales

A menudo los requerimientos de sistemas de software se clasifican en funcionales y no funcionales, o como requerimientos del dominio. Tambin se clasifican del usuario y el sistema.
1.1. Requerimientos funcionales

Son declaraciones de los servicios que proveer el sistema, de la manera en que ste reaccionar a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin declaran explcitamente lo que el sistema no debe hacer. Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que ste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc. Muchos de los problemas de la ingeniera de software provienen de la imprecisin en la especificacin de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementacin. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de ste e incrementando el costo. En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente. Completa significa que todos los servicios solicitados por el usuario estn definidos. Y la consistencia significa que los requerimientos no tienen definiciones contradictorias. En la prctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y completitud. La razn de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen despus de un anlisis profundo. Una vez que stos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos. Ejemplos de requerimientos funcionales Matriculacin La matricula ser realizada de forma interactiva. Se le preguntara al alumno cual es el plan de estudios en que desea matricularse (pueden ser varios). Se podr generar una copia impresa de la matricula (sin valor oficial) en el computador desde donde se realice el proceso de matriculacin. As mismo, se podr generar el impreso de pago debidamente cumplimentado. Para la matriculacin se consultaran los datos del expediente y se realizaran las validaciones necesarias, descritas a continuacin
Pago de matrcula: La aplicacin generara un impreso para que el alumno realice el pago correspondiente a la matricula en 1 o 2 plazos (segn las fechas establecidas). Si el alumno tiene matriculas de honor de cursos anteriores o disfruta de algn tipo de beca, la aplicacin deber calcular automticamente los descuentos correspondientes
Gestin de docencia El secretario ser el encargado de introducir que profesores corresponden a cada asignatura (si no, no podrn introducir las actas los profesores). Los profesores de cada asignatura tendrn acceso a las listas de los alumnos que estn matriculados en sus asignaturas y la aplicacin les debe permitir rellenar las actas.
Estadsticas En control de estudio se podrn obtener estadsticas que clasifiquen a los alumnos por su lugar de residencia, sexo, edad, cursos o asignaturas
1.2. Requerimientos no funcionales

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estndares, y otros Son aquellos requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representacin de datos que se utiliza en la interface del sistema. Muchos requerimientos no funcionales se refieren al sistema como un todo ms que a rasgos particulares del mismo. Esto significa que a menudo con ms crticos que los requerimientos funcionales particulares. Mientras que el incumplimiento de este ltimo degradar el sistema, una falla en un requerimiento no funcional del sistema lo inutiliza. Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las polticas de la organizacin, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las polticas de privacidad, etctera. Ejemplos de requerimientos NO funcionales Interfaces Hardware: El sistema se debe implementar sobre la infraestructura existente en las aulas de prcticas de la ctedra Ingeniera de Software Software: No existe posibilidad de adquirir software. La aplicacin deber funcionar sobre Oracle
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.
1.2.1. Requerimientos del producto

Especifican el comportamiento del producto; como los requerimientos de desempeo en la rapidez de ejecucin del sistema y cunta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad. Requerimientos organizacionales. Se derivan de las polticas y procedimientos existentes en la 3
organizacin del cliente y en la del desarrollador: estndares en los procesos que deben utilizarse; requerimientos de implementacin como los lenguajes de programacin o el mtodo de diseo a utilizar, y los requerimientos de entrega que especifican cundo se entregar el producto y su documentacin.
1.2.2. Requerimientos externos

Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interacta con los otros sistemas de la organizacin; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos ticos. Estos ltimos son impuestos al sistema para asegurar que ser aceptado por el usuario y por el pblico en general. Un problema comn con los requerimientos no funcionales es que algunas veces son difciles de verificar. Se redactan para reflejar las metas generales del usuario, como la facilidad de uso, la capacidad del sistema para recuperarse de las fallas o la respuesta rpida al usuario. Estos requerimientos causan problemas a los desarrolladores del sistema puesto que dejan abierta la posibilidad a la interpretacin, lo que provoca discusiones subsecuentes una vez que el sistema se entregue. De forma ideal, los requerimientos no funcionales no se deben expresar de manera cuantitativa utilizando mtricas que se puedan probar de forma objetiva. En la prctica, la especificacin cuantitativa de requerimientos es difcil. A los clientes no les es posible traducir sus metas en requerimientos cuantitativos; para algunas de stas, como las de mantenimiento, no existen mtricas que se puedan utilizar; el costo de verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy alto. En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de requerimientos. En la prctica, esto es difcil. Si un requerimiento no funcional se declara de forma separada a los funcionales, algunas veces es difcil ver la relacin entre ellos. Si se declaran con los requerimientos funcionales, es difcil separar las condiciones funcionales y no funcionales e identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un balance apropiado que dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que claramente se refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocndolos en una seccin aparte o diferencindolos, de alguna forma, de los otros requerimientos del sistema. 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).
2. Requerimientos del dominio

Son requerimientos que provienen del dominio de aplicacin del sistema y que reflejan las caractersticas de ese dominio. stos pueden ser funcionales o no funcionales. Se derivan del dominio del sistema ms que de las necesidades especificas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cmo se deben ejecutar clculos particulares. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicacin. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria.
Ejemplo en un Sistema de Biblioteca, este deber proveer visores para que el usuario lea documentos en el almacn de documentos
3. Requerimientos del usuario y del sistema

Algunos de los problemas que surgen durante el proceso de ingeniera de requerimientos son resultado de no hacer una clara separacin entre los diferentes niveles de descripcin. Esto se hace utilizando requerimientos del usuario para determinar los requisitos abstractos de alto nivel, y requisitos del sistema, para designar la descripcin detallada de lo que el sistema debe hacer. De igual forma que en estos dos niveles de detalle, se puede producir una descripcin ms detallada para establecer un puente entre la ingeniera de requerimientos y las actividades de diseo. Los requerimientos del usuario, los del sistema y la especificacin del diseo de software se definen de la siguiente manera:
3.1. Requerimientos del usuario

Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar. Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento tcnico detallado. nicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las caractersticas de diseo del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementacin. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos. Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural: falta de claridad, confusin de requerimientos y conjuncin de requerimientos.
3.2. Los requerimientos del sistema

Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificacin funcional, debe ser preciso. ste sirve como un contrato entre el comprador del sistema y el desarrollador del software. Son descripciones ms detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificacin del sistema y, por lo tanto, debe ser una especificacin completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseo del sistema. La especificacin de requerimientos del sistema incluye diferentes modelos del sistema como el de objetos o el de flujo de datos. En principio, los requerimientos del sistema debern establecer lo que ste har y no la manera en que se implementar. Sin embargo, en el nivel de detalle requerido para especificar el sistema completamente, es casi imposible excluir toda la informacin de diseo. Una especificacin del diseo del software, es una descripcin abstracta del diseo del software, que es una base para un diseo e implementacin detallados; agrega detalle a la especificacin de requerimientos del sistema
4. Lenguaje o notacin usada en la especificacin de requerimientos.

El lenguaje o notacin usada para la especificacin de requerimientos por excelencia es el UML (Lenguaje de modelado unificado), especficamente los diagramas de caso de uso, estados y actividades, estos dos ltimos describen en detalles los usos del sistema establecidos. Es as como estos diagramas se describen a continuacin
4.1. Diagrama de caso de uso.

Los diagramas de Casos de Uso describen o especifican lo que hace un sistema desde el punto de vista de un observador externo, enfatizando el qu ms que el cmo. Plantean escenarios, es decir, lo que pasa cuando alguien interacta con el sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el escenario de preparar su caf y el pan tostado (Ver Fig. No. 1) .
Fig. No. 1 Diagrama de Casos de Uso nivel 1 En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempean. Se representan mediante un hombre de palitos, de modo que en el ejemplo, Carlos es un Actor. Los Casos de Uso se representan por medio de valos y las lneas que unen Actores con Casos de Uso representan una asociacin de comunicacin. Por su puesto, un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo si tomamos por separado Preparar pan y Preparar cafe, podemos bajar un nivel de descripcin y llegar a los siguientes Casos de Uso. (Ver Fig. No. 2 y No. 3)
Fig. No. 2: Diagrama Casos de Uso nivel 2 A Carlos tuesta el pan en la tostadora, despus lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojndolo en un caf.
Fig. No. 3: Diagrama Casos de Uso nivel 2 B Carlos calienta leche, aade caf y azcar al gusto y se lo bebe. Los Casos de Uso suelen venir delimitados por fronteras o lmites, que definen una separacin entre lo que es realmente la funcionalidad del sistema y los actores que la usan o colaboran en su desempeo. En las figuras, esta separacin viene representada por medio de la caja que encapsula los valos. Los Casos de Uso son acompaados por una explicacin textual que clarifica las posibles cadencias del lenguaje meramente grfico. De esta manera, combinando Casos de Uso y explicacin textual, se puede obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de usuario, dada su sencillez de comprensin incluso por quien no est familiarizado con UML. Los Casos de Uso se emplean tambin en la preparacin de escenarios de pruebas con que verificar el software una vez ha sido construido. El siguiente Caso de Uso (Fig. No. 4) es equivalente al primero, Desayuno, slo que en l se ha condensado la mxima cantidad posible de informacin. En l se muestra un nuevo elemento que hasta ahora no se haba mostrado, el estereotipo, que viene entre sendos smbolos angulados << y >> y concreta un paso ms all el tipo de relacin existente entre dos Casos de Uso. Encontramos dos estereotipos <<include>> (Requiere) y <<extend>> (Variacin) . El primero indica que el Caso de Uso Tostar pan requiere de Usar tostadora para poder ser llevado a cabo. Esta es una forma muy adecuada de sacar factor comn entre Casos de Uso, o incluso de fraccionar Casos de Uso muy grandes. El segundo indica que el Caso de Uso Untar pan es una variacin de Untar. Observamos tambin que Comer pan y Beber cafe son una generalizacin de Alimentarse.
Fig. No. 4: Diagrama Casos de Uso nivel 1 detallado Carlos va a desayunar. Para ello debe hacer dos actividades distintas, pero relacionadas. La primera consiste en tostar pan, para lo cual necesita emplear una tostadora. Una vez tostado el pan, lo unta de mantequilla y mermelada de fresa (untar pan no es muy distinto de untar otro 7
tipo de alimentos). La segunda consiste en preparar el caf, par lo cual necesita calentar leche y aadir caf y azuzar. Terminadas ambas actividades, Carlos puede proceder a alimentarse, comiendo el pan tostado y bebiendo el caf. El orden en que realice las actividades da igual y tambin da igual si se realizan a la vez.
4.2. Diagrama de Estados y Diagrama de Actividades

Los diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado, en los usos establecidos para el sistema. El estado de un objeto depende de la actividad que est llevando a cabo o de alguna condicin dentro de los usos. Las transiciones son las lneas que unen los diferentes estados. En ellas se representa la condicin que provoca el cambio, seguida de la accin oportuna separada por /. En un estado en que el objeto esta pendiente de algn tipo de validacin que dependa de un proceso en curso, no es necesario evento externo alguno para que se produzca la transicin, ya que sta ocurrir cuando termine el proceso, en funcin del resultado de ste. En estos casos es conveniente, por claridad, incluir la condicin que de la que depende la transicin (entre corchetes). Los estados inicial, a partir del que se entra en la mquina de estados, y final, que indica que la mquina de estados termina, no tienen otro significado adicional, son elementos ornamentales y se representan mediante un circulo negro y un circulo negro resaltado respectivamente. Los estados de un diagrama de estados pueden anidarse, de forma que los estados relacionados pueden ser agrupados en un estado compuesto. Esto puede ser necesario cuando una actividad involucra sub-actividades asncronas o concurrentes. En las figura 5 y 6. Se muestra los diferentes estados del objeto artculo en el uso COMPRAR ARTICULOS
Figura 5: Mquina de Estados, estados simples
Figura 6: Mquina de Estados, estados compuestos
Los diagramas de actividades son bsicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de estados centran su atencin en el proceso o uso que est llevando a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas. Los diagramas de actividades pueden dividirse en calles que determinan qu objeto es responsable de qu actividad. Las actividades vienen unidas por transiciones, que pueden separarse en ramas en funcin del resultado de una condicin expresada entre corchetes. Cada rama muestra la condicin que debe ser satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o ms actividades paralelas. En la figura 7 se muestra un diagrama de actividades del uso COMPRAR ARTICULOS con los actores CLIENTE y TIENDA POR CATOLOGO (EMPLEADO)
Figura 7: Diagrama de Actividades
4.3. Ejemplo de especificacin de requerimientos usando los diagramas de casos de uso y actividad
Se desea especificar los requerimientos de un sitio web para el intercambio y comunicacin de informacin de la comunidad de la especialidad de informtica del IUTM-UPM. Luego de efectuar la respectiva extraccin de requerimientos con entrevista a los diferentes representantes de los actores involucrados en el sistema, se obtuvo para el actor ALUMNO el siguiente caso de uso (Ver Fig. 8)
10
Diagrama de CASO DE USO del Actor Alumno
Fig. 8 Diagrama de caso de uso del actor alumno en el sitio web para la especialidad de informtica del IUTM UPM Luego de establecer los respectivos usos, es necesario especificar en detalles las funciones o procedimientos indicados en los usos a travs de diagramas de actividades. A continuacin se describe el uso REGISTRASE EN LA WEB del actor alumno. (Ver Fig. 9)
11
DOCUMENTACION GRAFICA Diagrama Uso Actividad Registrarse como Alumno en el SITIO (RFA001)
Fig. 9 Diagrama de actividades del uso REGISTRARSE EN LA WEB del actor alumno en el sitio web para la especialidad de informtica del IUTM UPM
12
4.4. Notacin textual de los requerimientos

En las secciones anteriores se ha establecido los requerimientos de manera grafica con el lenguaje de modelado UML, especficamente con los diagramas de casos de uso y actividades, pero es necesario para la comunicacin efectiva con los usuarios e interesados en el futuro sistema describir textualmente, lo plasmado en figuras. A continuacin se muestra la notacin textual para el caso de uso del actor alumno REGISTRARSE EN LA WEB. DOCUMENTACIN TEXTUAL ALUMNO Registrarse como Alumno en el SITIO (RFA001) A travs de este caso de uso, el sistema le permite al alumno registrarse como usuario con rol de Alumno en el Sitio Web
Actor Uso 1. Descripcin Breve
2. FLUJO DE EVENTOS 2.1 Pre condiciones El estudiante debe haber solicitado va presencial o por correo electrnico al WEB MASTER su clave de registro 2.2 Flujo Principal 2.2.1 Crear Registro 2.2.2 El estudiante escoge la opcin REGISTRARSE y el sistema muestra una plantilla vaca con los campos de datos siguientes. o NOMBRE PRINCIPAL (Obligatorio) o NOMBRE SECUNDARIO o APELLIDO PRINCIPAL (Obligatorio) o APELLIDO SECUNDARIO o CEDULA DE IDENTIDAD (Obligatorio) o TELEFONO CELULAR o TELEFONO DE HABITACION (Obligatorio al menos un telfono) o DIRECCION (Obligatorio) o FOTO (Obligatorio) o Correo electrnico (Obligatorio) o USUARIO (Obligatorio) o CLAVE SUMINISTRADA(Obligatorio) 2.2.3 2.2.4 2.2.5 Luego de llenar la plantilla el Alumno procera al seleccionar o pulsar el botn ENVIAR Se verifica las excepciones y si no las hay se enva un mensaje al correo electrnico con los datos registrados ms su clave o password inicial de sesin, con su mensaje respectivo Si existen excepciones se notifican con un mensaje (Flujo de Excepciones), invitando a corregir el error y seleccionar las opciones ENVIAR o SALIR SIN REGISTRARSE (Flujo Alterno)
2.3 Flujo Alterno 2.3.1 Selecciona SALIR SIN REGISTRASE, sale del sitio sin registrarse 2.4 Flujo de excepciones E1 En blanco cualquier campo obligatorio E2 Correo electrnico no existente E3 Usuario existente o registrado en la Base de Datos E4 Clave suministrada errada E5 Campos Nombres y Apellidos con nmeros .
13
Uso
ID Descripcin Entrada
RESUMEN DE ESPECIFICACION FUNCIONAL Registrarse como Alumno en el SITIO

RFA-001
Salida
A travs de este caso de uso, el sistema le permite al alumno registrarse como usuario con rol de Alumno en el Sitio Web NOMBRE PRINCIPAL (Obligatorio) NOMBRE SECUNDARIO APELLIDO PRINCIPAL (Obligatorio) APELLIDO SECUNDARIO CEDULA DE IDENTIDAD (Obligatorio) TELEFONO CELULAR TELEFONO DE HABITACION (Obligatorio al menos un telfono) DIRECCION (Obligatorio) FOTO (Obligatorio) Correo electrnico (Obligatorio) USUARIO (Obligatorio) CLAVE SUMINISTRADA(Obligatorio) Correo electrnico con el usuario y clave inicial Mensaje de excepciones E-1 En blanco cualquier campo obligatorio E-2 Correo electrnico no existente. E-3 Usuario existente o registrado en la Base de Datos. E-4 Clave suministrada errada E-5 Campos Nombres y Apellidos con nmeros
Excepciones
5. Obtener o escribir requerimientos de alta calidad

En todas las tcnicas involucradas descritas en la unidad I de la ingeniera de requerimientos, las actividades y caractersticas resaltantes para obtener o escribir requerimientos de alta calidad son los siguientes. Identificar las clases de usuario del producto esperado. Extraer las necesidades de los individuos que representan (STAKEHOLDER) cada clase de usuario. Comprender las tareas y metas del usuario y los objetivos de negocio con los que esas tareas se alinean. Analizar la informacin recibida de los usuarios para distinguir sus objetivos de tarea de requerimientos funcionales, requerimientos no-funcionales, reglas de negocio, y otros Destinar partes de los requerimientos de alto nivel a definir componentes de software en la arquitectura sistema. Comprender la importancia de los atributos de calidad. Negociar las prioridades de implementacin. Traducir las necesidades de usuario escritas dentro de las especificaciones y modelos de requerimientos Examinar los requerimientos documentados para asegurar el conocimiento comn de los requerimientos presentados por los usuarios y corregir cualquier problema antes de que el grupo de desarrolladores los acepte. Definir el punto de partida de los requerimientos. Revisar y evaluar el impacto de cada requerimiento cambiado antes de aprobarlo. Seguir cada requerimiento en su diseo, cdigo fuente y pruebas. Agrupar los requerimientos segn rendimiento y actividad de cambio durante todo el proyecto. La iteracin es una clave para el xito del desarrollo de los requerimientos.
14
Es as como los requerimientos descritos de alta calidad, estn caracterizados por lo siguiente. Completo - Cada requerimiento debe describir completamente la funcionalidad que debe alcanzar. Debe contener toda la informacin necesaria para que el desarrollador pueda disear e implementar la funcionalidad. Correcto - Cada requerimiento debe describir la funcionalidad con exactitud para ser construida. Un requerimiento de software que est en contradiccin con su requerimiento de sistema padre no es correcto Viable - Debe ser posible implementar cada requerimiento dentro de las capacidades y limitaciones conocidas del sistema y su ambiente operativo. Evitar especificar requerimientos inalcanzables, para esto es importante tener un analista de requerimientos trabajando con personal de cliente durante todo el proceso de obtencin. Necesario - Cada requerimiento debe documentar una capacidad que los clientes realmente necesitan. Prioritario - Asignar una prioridad de implementacin para cada requerimiento funcional. Si todos los requerimientos son considerados equitativamente importantes, es difcil que el administrador de proyecto responda a recortes de presupuesto, perdida de personal, o nuevos requerimientos adicionados durante el desarrollo. No Ambiguo - Consistente- Todos los lectores de requerimientos deben llegar a una sola interpretacin consistente, pero el lenguaje natural es muy propenso a la ambigedad. Escribir requerimientos en un lenguaje simple, conciso y sencillo apropiado para el usuario. Definir todos los trminos especializados y trminos que puedan confundir a lectores en un glosario. Verificable Rastreable Es cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Los requerimientos que estn incompletos, inconsistentes, o ambiguos son imposibles de demostrar.
Ejemplos en requerimientos expresados en lenguaje natural La existencia de un requerimiento debe estar debidamente justificada. MAL (Mezcla de varios requisitos) Para facilitar el uso del editor grafico, se podr activar y desactivar una rejilla que permitir alinear las figuras del diagrama. Cuando se ajuste la figura al tamao de la pantalla, se reducir el nmero de lneas de la rejilla para que no se dificulte la visualizacin del diagrama. BIEN (conciso y justificado) El editor permitir el uso de una rejilla de lneas horizontales y verticales que aparecern dibujadas tras el diagrama. Justificacin: La rejilla facilita la creacin de diagramas cuidados en los que las figuras se puedan alinear con facilidad (Manual Prctico de Usabilidad, seccin 15.3). Otro problema habitual es que los requerimientos de un sistema son, a veces, difciles de verificar (especialmente los requerimientos no funcionales). MAL (objetivos generales, vagos y abiertos a distintas interpretaciones) El sistema ser lo mas fcil de utilizar posible. El sistema proporcionara una respuesta rpida al usuario. El sistema se recuperara automticamente tras producirse un fallo.
BIEN (requisitos verificables) 15
Un usuario experimentado debe ser capaz de utilizar todas las funciones del sistema tras un entrenamiento de 2 horas, tras el cual no cometer ms de 3 errores diarios en media. Cuando haya hasta 100 usuarios accediendo simultneamente al sistema, su tiempo de respuesta no ser en ningn momento superior a 2 segundos. Ante un fallo en el software del sistema, no se tardara ms de 5 minutos en restaurar los datos del sistema (en un estado valido) y volver a poner en marcha el sistema.
6. Estndares de la documentacin de los requerimientos

El documento de los requerimientos de software es la declaracin oficial de qu es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificacin detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se integran en una nica descripcin. En otros, los del usuario se definen en una introduccin de la especificacin de los del sistema. Si existe un gran nmero de requerimientos, los detalles de los requerimientos del sistema se pueden presentar como documentos separados. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los administradores principales de la organizacin, quienes pagan por el sistema, hasta los ingenieros responsables del software. Una gran variedad de organizaciones han definido estndares para los documentos de requerimientos. Por ejemplo la IEEE sugiere la siguiente estructura para los documentos de requerimientos. 1. Introduccin propsito del documento de requerimientos Alcance del producto Definiciones, acrnimos y abreviaturas Referencias Resumen del resto del documento 2. Descripcin general Perspectiva del producto Funciones del producto caractersticas del usuario Restricciones generales Suposiciones y dependencias 3. Requerimientos especficos. Cubren los requerimientos funcionales, no funcionales y de interfaz. Obviamente, sta es la parte ms sustancial del documento, pero debido a la amplia variabilidad en la prctica organizacional, no es apropiado definir una estructura estndar para esta seccin. Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el desempeo del sistema, especificar los requerimientos lgicos de la base de datos, las restricciones de diseo, las propiedades emergentes del sistema y las caractersticas de calidad. Ver ejemplo de documento de especificacin de requerimientos del proyecto SITIO WEB PARA LA COMUNIDAD DEL IUTM-UPM
16
Enlaces recomendados http://iteso.mx/~juanjo/IEEE_Std1233_1998_esp_desarrollo_de_especificaci on_de_reque.pdf http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos http://html.rincondelvago.com/documento-de-requerimientos-delsistema.html http://bpa.peru-v.com/ingenieria_requerimientos.htm http://www.scribd.com/doc/15117381/Requerimientosdelusuariositemasfuncionales http://www.ldc.usb.ve/~abianc/materias/ci4712/docrequerimientos.doc http://www.gestiopolis.com/administracion-estrategia/requerimientos-desoftware-por-administradores-de-software.htm#
17
Unidad I Requerimientos de Software Unidad Curricular Ingeniera de Software II; Modulo: FUNDAMENTOS DE INGENIERA DE REQUISITOS Y ANLISIS
MINISTERIO POPULAR PARA LA EDUCACION SUPERIOR UNIVERSIDAD POLITECNICA MARACAIBO MARACAIBO EDO. ZULIA DEPARTAMENTO DE INFORMATICA. UNIDAD CURRICULAR: INGENIERIA DE REQUERIMIENTOS MDULO: FUNDAMENTOS DE INGENIERIA DE REQUISITOS Y ANALISIS
GUIA DE LA UNIDAD II ESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE
PROFESOR: ALFONSO R. GALEA BRACHO

Requerimientos Funcionales y No Funcionales

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Requerimientos Funcionales y No Funcionales

Transféré par

Droits d'auteur :

Formats disponibles

Unidad II Especificacin de Requerimientos de Software Unidad Curricular Ingeniera de Software II; Modulo: FUNDAMENTOS DE INGENIERA DE REQUISITOS Y ANLISIS

1. Requerimientos funcionales y no funcionales

1.1. Requerimientos funcionales

1.2. Requerimientos no funcionales

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

1.2.1. Requerimientos del producto

1.2.2. Requerimientos externos

2. Requerimientos del dominio

3. Requerimientos del usuario y del sistema

3.1. Requerimientos del usuario

3.2. Los requerimientos del sistema

4. Lenguaje o notacin usada en la especificacin de requerimientos.

4.1. Diagrama de caso de uso.

4.2. Diagrama de Estados y Diagrama de Actividades

Figura 5: Mquina de Estados, estados simples

Figura 6: Mquina de Estados, estados compuestos

Figura 7: Diagrama de Actividades

Diagrama de CASO DE USO del Actor Alumno

4.4. Notacin textual de los requerimientos

Actor Uso 1. Descripcin Breve

RESUMEN DE ESPECIFICACION FUNCIONAL Registrarse como Alumno en el SITIO

5. Obtener o escribir requerimientos de alta calidad

BIEN (requisitos verificables) 15

6. Estndares de la documentacin de los requerimientos

GUIA DE LA UNIDAD II ESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE

PROFESOR: ALFONSO R. GALEA BRACHO

Vous aimerez peut-être aussi