requerimientos funcionales y no funcionales

Unidad II Especificación de Requerimientos de SoftwareUnidad Curricular Ingeniería de Software II; Modulo: FUNDAMENTOS DE INGENIERÍA DE REQUISITOS Y ANÁLISIS

Tabla de contenido

1. Requerimientos funcionales y no funcionales....................................................21.1. Requerimientos funcionales..............................................................................21.2. Requerimientos no funcionales........................................................................32. Requerimientos del dominio.................................................................................43. Requerimientos del usuario y del sistema..........................................................53.1. Requerimientos del usuario..............................................................................53.2. Los requerimientos del sistema........................................................................54. Lenguaje o notación usada en la especificación de requerimientos..............64.1. Diagrama de caso de uso.................................................................................64.2. Diagrama de Estados y Diagrama de Actividades........................................84.3. Ejemplo de especificación de requerimientos usando los diagramas de casos de uso y actividad.............................................................................................104.4. Notación textual de los requerimientos.........................................................135. Obtener o escribir requerimientos de alta calidad...........................................146. Estándares de la documentación de los requerimientos...............................16

1


En esta unidad se tiene como objeto establecer los conceptos y fundamentos involucrados en la especificación 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 declaración de los requerimientos. Continuando con las características y actividades involucradas en la obtención 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. También 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 también declaran explícitamente 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 función de éste, sus entradas y salidas, excepciones, etc. Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. 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 especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. Completa significa que todos los servicios solicitados por el usuario están definidos. Y la consistencia significa que los requerimientos no tienen definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y completitud. La razón 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 después de un análisis 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

Matriculación

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 matriculación.

Así mismo, se podrá generar el impreso de pago debidamente cumplimentado. Para la matriculación se consultaran los datos del expediente y se realizaran las

validaciones necesarias, descritas a continuación…

2


Pago de matrícula:

La aplicación generara un impreso para que el alumno realice el pago correspondiente a la matricula en 1 o 2 plazos (según las fechas establecidas).

Si el alumno tiene matriculas de honor de cursos anteriores o disfruta de algún tipo de beca, la aplicación deberá calcular automáticamente los descuentos correspondientes…

Gestión de docencia

El secretario será el encargado de introducir que profesores corresponden a cada asignatura (si no, no podrán introducir las actas los profesores).

Los profesores de cada asignatura tendrán acceso a las listas de los alumnos que estén matriculados en sus asignaturas y la aplicación les debe permitir rellenar las actas.

Estadísticas

En control de estudio se podrán obtener estadísticas 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, estándares, y otros

Son aquellos requerimientos que no se refieren directamente a las funciones específicas 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 representación de datos que se utiliza en la interface del sistema.

Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. Esto significa que a menudo con más críticos 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 políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.

Ejemplos de requerimientos NO funcionales

Interfaces

Hardware: El sistema se debe implementar sobre la infraestructura existente en las aulas de prácticas de la cátedra Ingeniería de Software

Software: No existe posibilidad de adquirir software. La aplicación 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 desempeño en la rapidez de ejecución del sistema y cuánta 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 políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben

3


utilizarse; requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.

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 interactúa con los otros sistemas de la organización; 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 público en general.

Un problema común con los requerimientos no funcionales es que algunas veces son difíciles 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 rápida al usuario. Estos requerimientos causan problemas a los desarrolladores del sistema puesto que dejan abierta la posibilidad a la interpretación, 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 métricas que se puedan probar de forma objetiva.

En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como las de mantenimiento, no existen métricas 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 práctica, esto es difícil. Si un requerimiento no funcional se declara de forma separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con los requerimientos funcionales, es difícil 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 colocándolos en una sección aparte o diferenciándolos, de alguna forma, de los otros requerimientos del sistema.

NOTA: La distinción 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 aparición de requerimientos funcionales como la necesidad de autentificar a los usuarios del sistema).

2. Requerimientos del dominio

Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales.

Se derivan del dominio del sistema más que de las necesidades especificas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria.

4


Ejemplo en un Sistema de Biblioteca, este deberá proveer visores para que el usuario lea documentos en el almacén de documentos

3. Requerimientos del usuario y del sistema

Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer una clara separación entre los diferentes niveles de descripción. Esto se hace utilizando requerimientos del usuario para determinar los requisitos abstractos de alto nivel, y requisitos del sistema, para designar la descripción detallada de lo que el sistema debe hacer. De igual forma que en estos dos niveles de detalle, se puede producir una descripción más detallada para establecer un puente entre la ingeniería de requerimientos y las actividades de diseño. Los requerimientos del usuario, los del sistema y la especificación del diseño 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 técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementación. 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, confusión de requerimientos y conjunción 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 especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software.

Son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema.

La especificación 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 deberán 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 información de diseño.

Una especificación del diseño del software, es una descripción abstracta del diseño del software, que es una base para un diseño e implementación detallados; agrega detalle a la especificación de requerimientos del sistema

5


4. Lenguaje o notación usada en la especificación de requerimientos.

El lenguaje o notación usada para la especificación de requerimientos por excelencia es el UML (Lenguaje de modelado unificado), específicamente 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 continuación

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é más que el cómo. Plantean escenarios, es decir, lo que pasa cuando alguien interactúa 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 desempeñan. 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 líneas que unen Actores con Casos de Uso representan una asociación de comunicación. 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 descripción 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, después lo unta con mantequilla y mermelada de fresa y se lo come, posiblemente mojándolo en un café.”

6


Fig. No. 3: Diagrama Casos de Uso nivel 2 B

“Carlos calienta leche, añade café y azúcar al gusto y se lo bebe.”

Los Casos de Uso suelen venir delimitados por fronteras o límites, que definen una separación entre lo que es realmente la funcionalidad del sistema y los actores que la usan o colaboran en su desempeño. En las figuras, esta separación viene representada por medio de la caja que encapsula los óvalos.

Los Casos de Uso son acompañados por una explicación textual que clarifica las posibles cadencias del lenguaje meramente gráfico. De esta manera, combinando Casos de Uso y explicación textual, se puede obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de usuario, dada su sencillez de comprensión incluso por quien no está familiarizado con UML. Los Casos de Uso se emplean también en la preparación 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”, sólo que en él se ha condensado la máxima cantidad posible de información. En él se muestra un nuevo elemento que hasta ahora no se había mostrado, el “estereotipo”, que viene entre sendos símbolos angulados “<<” y “>>” y concreta un paso más allá el tipo de relación existente entre dos Casos de Uso. Encontramos dos estereotipos <<include>> (Requiere) y <<extend>> (Variación) . 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 común 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 variación de “Untar”. Observamos también que “Comer pan” y “Beber cafe” son una generalización 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 añadir 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 también 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 condición dentro de los usos.

Las transiciones son las líneas que unen los diferentes estados. En ellas se representa la condición que provoca el cambio, seguida de la acción oportuna separada por “/”. En un estado en que el objeto esta pendiente de algún tipo de validación que dependa de un proceso en curso, no es necesario evento externo alguno para que se produzca la transición, ya que ésta ocurrirá cuando termine el proceso, en función del resultado de éste. En estos casos es conveniente, por claridad, incluir la condición que de la que depende la transición (entre corchetes).

Los estados inicial, a partir del que se “entra” en la máquina de estados, y final, que indica que la máquina 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 asíncronas o concurrentes. En las figura 5 y 6. Se muestra los diferentes estados del objeto artículo en el uso COMPRAR ARTICULOS

Figura 5: Máquina de Estados, estados simples

8


Figura 6: Máquina de Estados, estados compuestos

Los diagramas de actividades son básicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de estados centran su atención 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 función del resultado de una condición expresada entre corchetes. Cada rama muestra la condición que debe ser satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o más 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)

9


Figura 7: Diagrama de Actividades

4.3.Ejemplo de especificación de requerimientos usando los diagramas de casos de uso y actividad

Se desea especificar los requerimientos de un sitio web para el intercambio y comunicación de información de la comunidad de la especialidad de informática del IUTM-UPM. Luego de efectuar la respectiva extracción 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)

Diagrama de CASO DE USO del Actor Alumno

10


Fig. 8 Diagrama de caso de uso del actor alumno en el sitio web para la especialidad de informática del IUTM UPM

Luego de establecer los respectivos usos, es necesario especificar en detalles las funciones o procedimientos indicados en los usos a través de diagramas de actividades. A continuación se describe el uso REGISTRASE EN LA WEB del actor alumno. (Ver Fig. 9)

DOCUMENTACION GRAFICA

11


Diagrama Actividad

Uso 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 informática del IUTM UPM

12


4.4.Notación textual de los requerimientos

En las secciones anteriores se ha establecido los requerimientos de manera grafica con el lenguaje de modelado UML, específicamente con los diagramas de casos de uso y actividades, pero es necesario para la comunicación efectiva con los usuarios e interesados en el futuro sistema describir textualmente, lo plasmado en figuras. A continuación se muestra la notación textual para el caso de uso del actor alumno REGISTRARSE EN LA WEB.

DOCUMENTACIÓN TEXTUALActor ALUMNOUso Registrarse como Alumno en el SITIO (RFA001)1. Descripción Breve A través de este caso de uso, el sistema le permite al alumno

registrarse como usuario con rol de Alumno en el Sitio Web 2. FLUJO DE EVENTOS2.1 Pre condiciones El estudiante debe haber solicitado vía presencial o por correo

electrónico al WEB MASTER su clave de registro2.2 Flujo Principal2.2.1 Crear Registro2.2.2 El estudiante escoge la opción “REGISTRARSE” y el sistema muestra una

plantilla vacía con los campos de datos siguientes.o NOMBRE PRINCIPAL (Obligatorio)o NOMBRE SECUNDARIO o APELLIDO PRINCIPAL (Obligatorio) o APELLIDO SECUNDARIOo CEDULA DE IDENTIDAD (Obligatorio)o TELEFONO CELULAR o TELEFONO DE HABITACION (Obligatorio al

menos un teléfono)o DIRECCION (Obligatorio)o FOTO (Obligatorio)o Correo electrónico (Obligatorio)o USUARIO (Obligatorio)o CLAVE SUMINISTRADA(Obligatorio)

2.2.3 Luego de llenar la plantilla el Alumno procera al seleccionar o pulsar el botón “ENVIAR”

2.2.4 Se verifica las excepciones y si no las hay se envía un mensaje al correo electrónico con los datos registrados más su clave o password inicial de sesión, con su mensaje respectivo

2.2.5 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 Alterno2.3.1 Selecciona “SALIR SIN REGISTRASE”, sale del sitio sin registrarse2.4 Flujo de excepcionesE1 En blanco cualquier campo obligatorioE2 Correo electrónico no existenteE3 Usuario existente o registrado en la Base de DatosE4 Clave suministrada erradaE5 Campos Nombres y Apellidos con números.

13


RESUMEN DE ESPECIFICACION FUNCIONAL Uso Registrarse como Alumno en el SITIOID RFA-001Descripción A través de este caso de uso, el sistema le permite al alumno registrarse

como usuario con rol de Alumno en el Sitio Web Entrada NOMBRE PRINCIPAL (Obligatorio)

NOMBRE SECUNDARIO APELLIDO PRINCIPAL (Obligatorio) APELLIDO SECUNDARIOCEDULA DE IDENTIDAD (Obligatorio)TELEFONO CELULAR TELEFONO DE HABITACION (Obligatorio al menos un teléfono)DIRECCION (Obligatorio)FOTO (Obligatorio)Correo electrónico (Obligatorio)USUARIO (Obligatorio)CLAVE SUMINISTRADA(Obligatorio)

Salida Correo electrónico con el usuario y clave inicial Mensaje de excepciones

Excepciones E-1 En blanco cualquier campo obligatorio E-2 Correo electrónico no existente. E-3 Usuario existente o registrado en la Base de Datos.E-4 Clave suministrada erradaE-5 Campos Nombres y Apellidos con números

5. Obtener o escribir requerimientos de alta calidad

En todas las técnicas involucradas descritas en la unidad I de la ingeniería de requerimientos, las actividades y características 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 información 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 implementación.• Traducir las necesidades de usuario escritas dentro de las especificaciones y modelos de

requerimientos• Examinar los requerimientos documentados para asegurar el conocimiento común 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 diseño, código fuente y pruebas.• Agrupar los requerimientos según rendimiento y actividad de cambio durante todo el

proyecto. • La iteración es una clave para el éxito del desarrollo de los requerimientos.

14


Es así como los requerimientos descritos de alta calidad, están caracterizados por lo siguiente.

Completo - Cada requerimiento debe describir completamente la funcionalidad que debe alcanzar. Debe contener toda la información necesaria para que el desarrollador pueda diseñar e implementar la funcionalidad.

Correcto - Cada requerimiento debe describir la funcionalidad con exactitud para ser construida. Un requerimiento de software que está en contradicción 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 obtención.

Necesario - Cada requerimiento debe documentar una capacidad que los clientes realmente necesitan.

Prioritario - Asignar una prioridad de implementación para cada requerimiento funcional. Si todos los requerimientos son considerados equitativamente importantes, es difícil 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 interpretación consistente, pero el lenguaje natural es muy propenso a la ambigüedad. Escribir requerimientos en un lenguaje simple, conciso y sencillo apropiado para el usuario. Definir todos los términos especializados y términos que puedan confundir a lectores en un glosario.

Verificable – Rastreable Es cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas. Los requerimientos que están 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 tamaño de la pantalla, se reducirá el número de líneas de la rejilla para que no se dificulte la visualización del diagrama.

BIEN (conciso y justificado)

El editor permitirá el uso de una rejilla de líneas horizontales y verticales que aparecerán dibujadas tras el diagrama.

Justificación: La rejilla facilita la creación de diagramas cuidados en los que las figuras se puedan alinear con facilidad (Manual Práctico de Usabilidad, sección 15.3).

Otro problema habitual es que los requerimientos de un sistema son, a veces, difíciles de verificar (especialmente los requerimientos no funcionales).

MAL (objetivos generales, vagos y abiertos a distintas interpretaciones)

El sistema será lo mas fácil de utilizar posible. El sistema proporcionara una respuesta rápida al usuario. El sistema se recuperara automáticamente 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á más de 3 errores diarios en media.

Cuando haya hasta 100 usuarios accediendo simultáneamente al sistema, su tiempo de respuesta no será en ningún momento superior a 2 segundos.

Ante un fallo en el software del sistema, no se tardara más de 5 minutos en restaurar los datos del sistema (en un estado valido) y volver a poner en marcha el sistema.

6. Estándares de la documentación de los requerimientos

El documento de los requerimientos de software es la declaración oficial de qué es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se integran en una única descripción. En otros, los del usuario se definen en una introducción de la especificación de los del sistema. Si existe un gran número 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 organización, quienes pagan por el sistema, hasta los ingenieros responsables del software. Una gran variedad de organizaciones han definido estándares para los documentos de requerimientos. Por ejemplo la IEEE sugiere la siguiente estructura para los documentos de requerimientos.

1. Introducción • propósito del documento de requerimientos • Alcance del producto • Definiciones, acrónimos y abreviaturas • Referencias • Resumen del resto del documento

2. Descripción general • Perspectiva del producto • Funciones del producto • características del usuario • Restricciones generales • Suposiciones y dependencias

3. Requerimientos específicos. Cubren los requerimientos funcionales, no funcionales y de interfaz. Obviamente, ésta es la parte más sustancial del documento, pero debido a la amplia variabilidad en la práctica organizacional, no es apropiado definir una estructura estándar para esta sección. Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el desempeño del sistema, especificar los requerimientos lógicos de la base de datos, las restricciones de diseño, las propiedades emergentes del sistema y las características de calidad.

Ver ejemplo de documento de especificación 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_especificacion_de_reque.pdf

http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos

http://html.rincondelvago.com/documento-de-requerimientos-del- sistema.html

http://bpa.peru-v.com/ingenieria_requerimientos.htm

http://www.scribd.com/doc/15117381/Requerimientos- delusuariositemasfuncionales

http://www.ldc.usb.ve/~abianc/materias/ci4712/docrequerimientos.doc

http://www.gestiopolis.com/administracion-estrategia/requerimientos-de- software-por-administradores-de-software.htm#

17

http://www.gestiopolis.com/administracion-estrategia/requerimientos-de-software-por-administradores-de-software.htm#

http://www.gestiopolis.com/administracion-estrategia/requerimientos-de-software-por-administradores-de-software.htm#

http://www.ldc.usb.ve/~abianc/materias/ci4712/docrequerimientos.doc

http://www.scribd.com/doc/15117381/Requerimientos-delusuariositemasfuncionales

http://www.scribd.com/doc/15117381/Requerimientos-delusuariositemasfuncionales

http://bpa.peru-v.com/ingenieria_requerimientos.htm

http://html.rincondelvago.com/documento-de-requerimientos-del-sistema.html

http://html.rincondelvago.com/documento-de-requerimientos-del-sistema.html

http://www.mitecnologico.com/Main/EspecificacionesDeRequerimientos

http://iteso.mx/~juanjo/IEEE_Std1233_1998_esp_desarrollo_de_especificacion_de_reque.pdf

http://iteso.mx/~juanjo/IEEE_Std1233_1998_esp_desarrollo_de_especificacion_de_reque.pdf

Unidad I Requerimientos de SoftwareUnidad Curricular Ingeniería de Software II; Modulo: FUNDAMENTOS DE INGENIERÍA DE REQUISITOS Y ANÁLISIS

MINISTERIO POPULAR PARA LA EDUCACION SUPERIORUNIVERSIDAD POLITECNICA MARACAIBO MARACAIBO EDO. ZULIADEPARTAMENTO DE INFORMATICA.UNIDAD CURRICULAR: INGENIERIA DE REQUERIMIENTOSMÓDULO: FUNDAMENTOS DE INGENIERIA DE REQUISITOS Y ANALISIS

GUIA DE LA UNIDAD IIESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE

PROFESOR: ALFONSO R. GALEA BRACHO

requerimientos funcionales y no funcionales

Documents