defenicion de producto de software_ok

Calidad de Software Ing. Alonso Morales

2011Definicin del Producto de Software

Atoche Huaspa Gustavo. Ayala Espino Erick. Cueva Ramos Daniel. Muoz Lpez Jorge. zzzzzz

Definicin del Producto de Software

Calidad de Software

Facultad de Ingeniera de Sistemas - UNICA

1


Calidad de Software

ContenidoINTRODUCCION. ............................................................................................................................ 4 1. DEFINICIN DEL PRODUCTO SOFTWARE. ............................................................................. 5 1.1. Necesidades de los usuarios. ........................................................................................ 5 Un cliente es la persona o grupo que.................................................................... 6 El usuario final es la persona o grupo que. ........................................................... 6

1.1.1. 1.1.2. 1.2. 1.3.

Requisitos del producto. ............................................................................................... 6 Requerimiento del software. ....................................................................................... 7 Clasificacin de requerimientos. ........................................................................... 7 Caractersticas de los requerimientos. .................................................................. 8 Dificultades para definir los requerimientos......................................................... 8 Dimensiones de los requerimientos...................................................................... 9 Diferencias entre requerimiento de usuario y de sistemas. ............................. 10

1.3.1. 1.3.2. 1.3.3. 1.3.4. 1.3.5. 2.

MECANISMOS PARA LA DOCUMENTACIN DE REQUERIMIENTOS. ................................... 11 2.1. Proceso de requerimientos. ........................................................................................ 12 Estudio de viabilidad. .......................................................................................... 12 Obtencin y anlisis de requerimientos.............................................................. 12 Especificacin de Requisitos. .............................................................................. 13 Validacin de requerimientos. ............................................................................ 16

2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.2.

IEEE........................................................................................................................... 17 IEEE 830-1984 Gua de Requisitos de Software Especificaciones. ..................... 18

2.2.1.

2.2.2. IEEE 830-1998 - Prcticas recomendadas para IEEE Requisitos de software Especificaciones. ................................................................................................................. 18 2.2.3. 2.2.4. 2.2.5. 2.3. 2.4. 3. Objetivos de la ERS. ............................................................................................. 18 Caractersticas de una buena ERS. ...................................................................... 19 Esquema de la ERS definida en el IEEE 830-1998................................................ 23

IEEE Computer Society. ............................................................................................... 23 SWEBOK....................................................................................................................... 24

REQUERIMIENTOS FUNCIONALES Y REQUERIMIENTOS NO FUNCIONALES. ...................... 25 3.1. 3.2. Requerimientos Funcionales. ...................................................................................... 25 Requerimientos No Funcionales. ................................................................................ 27 Requerimientos del Producto. ............................................................................ 28 Requerimientos Organizacionales....................................................................... 28 Requerimientos Externos. ................................................................................... 28

3.2.1. 3.2.2. 3.2.3.


2


Calidad de Software

4.

UTILIZACIN DE CASOS DE USO EN LA DEFINICIN DE REQUERIMIENTO DE SOFTWARE. 32 4.1. 4.2. Historia. ....................................................................................................................... 32 Definiciones Bsicas. ................................................................................................... 32 Caso de Uso. ........................................................................................................ 32 Actor. ................................................................................................................... 33 Condiciones. ........................................................................................................ 34 Escenario. ............................................................................................................ 34 Diagramas de Casos de Uso. ............................................................................... 34 Organizacin de Casos de Uso. ........................................................................... 35

4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.2.6. 4.3. 4.4. 4.5.

Comportamiento. ........................................................................................................ 36 Caractersticas. ............................................................................................................ 37 Anlisis de Requerimientos con Casos de Uso. ........................................................... 37 Identificar y Clasificar Requisitos. ....................................................................... 37 Identificar los Actores. ........................................................................................ 38 Identificar Escenarios. ......................................................................................... 39 Identificar los principales Casos de Uso de cada actor. ...................................... 39 Identificar nuevos casos a partir de los existentes. ............................................ 39 Crear descripciones de casos de uso. .................................................................. 41 Definir prioridades y seleccionar casos de la primera iteracin. ........................ 41 Escribir los casos y crear prototipos de interfaces. ............................................. 41

4.5.1. 4.5.2. 4.5.3. 4.5.4. 4.5.5. 4.5.6. 4.5.7. 4.5.8. 4.6. 4.7. 4.8.

Plantilla para descripcin de casos de uso. ................................................................. 42 Plantilla de actores. ..................................................................................................... 43 Documentacin de caso de uso. ................................................................................. 43

5. USO DEL FORMATO DE ESPECIFICACIN DE REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES.............................................................................................................................. 44 5.1. 5.2. Formato de Requerimientos Funcionales. .................................................................. 44 Requerimientos No Funcionales. ................................................................................ 45

Bibliografa. ................................................................................................................................. 47 Conclusiones. .............................................................................................................................. 49 Recomendaciones. ...................................................................................................................... 50


3


Calidad de Software

INTRODUCCION.En este trabajo se intenta analizar las necesidades que tiene un usuario para poder adquirir un determinado producto software determinado este debe satisfacer las necesidades y facilitar el trabajo en una organizacin por ello presenta diferentes requisitos y requerimientos necesarios para poder hacerlo para que se pueda adaptar a las necesidades requeridas esto conlleva a una relacin ms estrecha con los usuarios para ver qu es lo que necesitan. Conocer qu tiene que el software es el punto de partida, y la parte ms importante, del proceso de desarrollo. Si los desarrolladores no conocen de forma precisa el problema a resolver, no es probable que se obtenga una solucin correcta y til. As pues la correcta obtencin de los requisitos es uno de los aspectos ms crticos de un proyecto software, independientemente del tipo de proyecto que se trate, dado que una mala captura de los mismos es la causa de la mayor parte de los problemas que surgen a lo largo del ciclo de vida. La ingeniera de requisitos es la parte de la ingeniera del software que aborda el problema de la definicin de los servicios que el sistema ha de proporcionar y de establecer las restricciones operativas del mismo. Los casos de uso se han convertido en una de las tcnicas de modelado ms utilizadas para la determinacin y documentacin de los requisitos funcionales de un sistema software. En este tema se presentarn los conceptos y principios bsicos de la ingeniera de requisitos. As se dar una visin global de los diferentes tipos de requisitos, para posteriormente presentar con detalle la notacin que UML propone para la tcnica de los casos de uso.


4


Calidad de Software

1. DEFINICIN DEL PRODUCTO SOFTWARE.Es la necesidad que tiene una persona para adquirir ciertos productos para poder facilitar procesos en una organizacin estos se dividen en: Productos genricos. Productos que son producidos por una organizacin para ser vendidos al mercado. Productos hechos a medida. Sistemas que son desarrollados bajo pedido a un desarrollador especfico. La mayor parte del gasto del software es en productos genricos, pero hay ms esfuerzo en el desarrollo de los sistemas hechos a medida.

Figura 1.1 Proceso de Desarrollo de Software Son los pasos que se siguen para poder desarrollar o modificar un software. 1.1. Necesidades de los usuarios. Para prosperar en el mercado, cualquier producto debe satisfacer las necesidades de los usuarios, lo cual no resulta posible si no integra y pone al alcance del consumidor de forma comprensible los fundamentos de todos los aspectos del desarrollo. Para captar las necesidades especficas de los usuarios es indispensable que los documentos que recogen los requerimientos se redacten utilizando mtodos pragmticos. Se debe utilizar una metodologa detallada de definicin de los requerimientos de usuario. Organizar entrevistas destinadas a obtener la mxima informacin posible acerca de los requerimientos de los usuarios. Traducir las oportunidades / necesidades en requerimientos del proyecto. Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crear un documento de requerimientos generales. Conseguir la participacin y confirmacin del


5


Calidad de Software

usuario. Los gerentes y usuarios del sistema tambin poseen un papel importante en le diseo del sistema; no es solamente el proyecto del analista. Durante el diseo, a algunos se les pide que revisen los borradores de los informes, que examinen los formatos de entrada y que ayuden en la escritura de los procedimientos para decirles a otras personas como utilizar el sistema en forma apropiada. La participacin del usuario proporciona al analista una retroalimentacin importante conforme avanza en el diseo; adems asegura a los usuarios tengan un conocimiento no tcnico de lo realizara o no el nuevo sistema.

Figura. 1.2 Los usuarios de un Sistema Tenemos a los actores que nos brindaran la mayor parte de la informacin necesaria para poder desarrollar un producto de software 1.1.1. Un cliente es la persona o grupo que. a. En un inicio solicita el software que se va a construir b. Define los objetivos generales de negocio para el software c. Proporciona los requisitos bsicos del producto d. Coordina los recursos econmicos para el proyecto. 1.1.2. El usuario final es la persona o grupo que. a. En realidad usara el software que se construye para alcanzar un propsito de negocios. b. Definir los detalles operativos del software de forma que el propsito del negocio que pueda alcanzarse. 1.2. Requisitos del producto. Los requisitos del producto especifican el comportamiento del producto final, algunos ejemplos son los requerimientos de rendimiento en la rapidez de Facultad de Ingeniera de Sistemas - UNICA

6


Calidad de Software

ejecucin del sistema y cuanta memoria se requiere, los requerimientos de fiabilidad que fijan la tasa de fallos para que el sistema sea aceptable; los requerimientos de portabilidad y los requerimientos de usabilidad. 1.3. Requerimiento del software. Hay una serie de conceptos acerca evaluar los ms importantes de los requerimientos entonces vamos a

La definicin que aparece en [IEEE, 1990] es la siguiente: Requerimiento (1): a. Una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. b. 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. c. Una representacin en forma de documento de una condicin o capacidad como las expresadas en (a) o en (b). Mientras que la que aparece en [DOD, 1994] es ms concisa: Requerimiento (2): caracterstica del sistema que es una condicin para su aceptacin. Otra posible definicin es la siguiente [GOG, 1994] Requerimiento (3): propiedad que un sistema debera tener para tener xito en el entorno en el que se usar. Sin embargo, a pesar de esta aparente simplicidad del concepto, es frecuente encontrar el trmino requerimiento calificado con adjetivos que pueden resultar confusos en un primer momento: de sistema, hardware, software, de usuario, de cliente, funcional, no funcional, etc. 1.3.1. Clasificacin de requerimientos. Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. 1.3.1.1. Los requerimientos funcionales. Definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. 1.3.1.2. Los requerimientos no funcionales. Tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y Facultad de Ingeniera de Sistemas - UNICA

7


Calidad de Software

espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc. 1.3.2. Caractersticas de los requerimientos. Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Dificultades para definir los requerimientos. Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

1.3.3.


8


Calidad de Software

Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

1.3.4. Dimensiones de los requerimientos. La gran cantidad de calificativos que se aplican al trmino requerimiento muestran distintos aspectos ortogonales que a menudo se consideran aisladamente. Para intentar clarificar la situacin, se puede identificar tres dimensiones en las que se pueden clasificar los requerimientos, Estas tres dimensiones son:

Figura 1.3 Dimensiones de los Requerimientos. mbito: esta dimensin indica en qu mbito se debe entender el requerimiento. En general, y siguiendo entre otras las propuestas de [IEEE, 1997], [DOD, 1994] y [DAV, 1993], un mbito de sistema indica que el requerimiento debe cumplirse a nivel de sistema, entendiendo por sistema un conjunto de hardware y software. Si el mbito es de software quiere decir que el requerimiento slo afecta a la parte software de un sistema, mientras que si es el mbito es de hardware slo afecta a la parte hardware. Caracterstica que define: esta dimensin clasifica los requerimientos en funcin de la naturaleza de la caracterstica del sistema deseada que se especifica. La clasificacin ms habitual suele ser la de requerimientos funcionales (qu funciones debe realizar el sistema) y no funcionales (otras caractersticas del sistema). Audiencia: Esta dimensin fundamental, indica la audiencia a la que est dirigido el requerimiento, es decir, las personas que deben ser capaces de entenderlo. En general, se pueden distinguir dos tipos de


9


Calidad de Software

audiencia, los clientes y usuarios, que no tienen por qu tener formacin en ingeniera del software, y los desarrolladores de software. Cuando la audiencia est formada por clientes y usuarios, la forma ms habitual de definir los requerimientos es mediante lenguaje natural. En el caso de que la audiencia prevista est formada por desarrolladores de software, los requerimientos suelen expresarse mediante un modelo, normalmente utilizando tcnicas estructuradas, orientadas a objetos o formales. 1.3.5. Diferencias entre requerimiento de usuario y de sistemas. Aqu se distinguen utilizando la denominacin requerimientos del usuario para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema para designar la descripcin detallada de lo que el sistema debe hacer. Los requerimientos del usuario y del sistema se pueden definir como se muestra a continuacin: Los requerimientos del usuario son declaraciones, en el lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar. Los requerimientos del sistema establecen las funciones, servicios y restricciones operativas del sistema. El documento de requerimientos del sistema (algunas veces denominado especificacin funcional) debe ser preciso. Debe definir exactamente qu es lo que se va implementar. Puede ser parte del contrato entre comprador el del sistema y los desarrolladores del software.

Requerimientos del Usuario Administradores del sistema Ingenieros clientes Administradores Contratistas Arquitectos del sistema

Requerimientos del Sistema Usuarios finales del sistema Ingenieros clientes Arquitectos del sistema Desarrolladores del Software Figura 1.4 Lectores de los diferentes tipos de especificaciones. 1

1

Imagen que se refiere a los integrantes que intervienen en el requerimiento de usuario como del sistema. Figura obtenida del libro de Ingeniera de Software de Ian Sommerville.


10


Calidad de Software

2. MECANISMOS PARA LA DOCUMENTACIN DE REQUERIMIENTOS.La ingeniera de requerimientos proporciona el mecanismos apropiado para entender lo que desea el cliente, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validar la especificacin y administrar los requerimientos a medida de que se transforman en un sistema funcional. Incluye siete tareas diferentes (segn el libro de Sommerville): concepcin, indagacin, elaboracin, negociacin, especificacin, validacin y administracin. Es importante notar que alguna de estas tareas ocurre en paralelo y que todas se adaptan a las necesidades del proyecto. (I.S de Roger S. Pressman, cap.5.1) La meta del proceso de ingeniera de requerimientos es crear y mantener un documento de requerimientos del sistema. En la figura 2.1 se refieren al descubrimiento, documentacin y verificacin de requerimientos. Sin embargo, en casi todos los sistemas los requerimientos cambian.

Figura 2.1 Proceso de Ingeniera de requerimientos sacada del libro de Ingeniera de software de Sommerville, Cap.7.


11


Calidad de Software

2.1. Proceso de requerimientos. 2.1.1. Estudio de viabilidad. Para todos los procesos nuevos, el proceso de ingeniera de requerimientos debera empezar con un estudio de viabilidad. La entrada de este es un conjunto de requerimientos de negocio preliminares, una descripcin resumida del sistema y de cmo este pretende contribuir a los procesos de negocio. Los resultados del estudio de viabilidad deberan ser un informe que recomiende si merece o no la pena seguir con la ingeniera de requerimientos y el proceso de desarrollo del sistema. Un estudio de viabilidad es un estudio corto y orientado a resolver varias cuestiones:

Contribuye el sistema a los objetivos generales de la organizacin?

Se puede implementar el sistema utilizando la tecnologia actual y dentro de las restricciones de coste y tiempo?

Puede integrarse el sistema con otros sistemas existentes en la organizacin?

Llevar a cabo un estudio de viabilidad comprende la evaluacin y recopilacin de la informacin, y la redaccin de informes. La fase de evaluacin de la informacin identifica la informacin requerida para contestar las tres preguntas anteriores. (I.S de Ian Sommerville, Cap.7.1) 2.1.2. Obtencin y anlisis de requerimientos. La siguiente etapa del proceso de ingeniera de requerimientos es la obtencin y anlisis de requerimientos. En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios finales del sistema para determinar el dominio de la aplicacin2, que servicios debe proporcionar el

2

Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos de del dominio de la aplicacin. Los requerimientos de dominio forma parte de las clases de requerimientos, y pueden ser funcionales y no funcionales (Sommerville).


12


Calidad de Software

sistema, el rendimiento requerido del sistema, las restricciones de hardware, etc. La obtencin y anlisis de requerimientos pueden afectar a varias personas de la organizacin. El termino stakeholder se utiliza para referirse a cualquier persona o grupo que se ver afectado por el sistema, directa o indirectamente. Entre los stakeholder se encuentran a los usuarios finales que interactan con el sistema y todos aquellos en la organizacin que se pueden ver afectados por su instalacin. Otros stakeholder del sistema pueden ser los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los gerentes de negocio, los expertos en el dominio del sistema y los representantes de los trabajadores. (I.S de Ian Sommerville, Cap.7.1) 2.1.3. Especificacin de Requisitos. Para la mayora de las profesiones de ingeniera, el trmino "especificacin" se refiere a la asignacin de valores numricos o lmites a los objetivos de diseo de un producto. Por lo tanto, en la ingeniera de software, "especificacin de requisitos software" se refiere normalmente a la produccin de un documento, o su equivalente electrnico, que puede ser sistemticamente revisado, evaluados y aprobados. Para sistemas complejos, particularmente aquellos que involucran importantes componentes de software, elaboran tres diferentes tipos de documentos que son: la definicin del sistema, requisitos del sistema y los requisitos de software. Para productos de software simple, slo la tercera de las anteriores es requerida. Los tres documentos se describen a continuacin, entendiendo que se pueden combinar, segn corresponda. (Gua SWEBOK, SWEBOK 2004, Cap.2.5) 2.1.3.1. El documento de definicin del sistema. Este documento (conocido a veces como el documento de requisitos de usuario o el concepto de las operaciones) se registran los requisitos del sistema. En l se definen los requisitos del sistema de alto nivel desde la perspectiva de dominio. Sus lectores incluye a representantes del sistema de los usuarios / clientes (marketing puede desempear estas funciones impulsada por el mercado de software), por lo que debe ser su contenido expresado en trminos del dominio. El documento enumera los requisitos del sistema junto con: Informacin de fondo sobre los objetivos generales para el sistema, Su entorno de destino y una declaracin de las limitaciones,


13


Calidad de Software

Supuestos y requisitos no funcionales.

Se pueden incluir modelos conceptuales diseados para ilustrar el contexto del sistema, los escenarios de uso y las entidades de dominio principal, as como los datos, informacin y flujos de trabajo. IEEE Std1362, Concepto de documento de Operaciones, ofrece asesoramiento sobre la elaboracin y el contenido de dicho documento. (IEEE1362-98) 3. (Gua SWEBOK, SWEBOK 2004, Cap.2.5.1) 2.1.3.2. Especificacin de Requisitos del sistema En l caso los desarrolladores de sistemas basados en componentes de software y non-software, por ejemplo, un avin de pasajeros moderno, separa a menudo la descripcin de los requisitos del sistema de la descripcin de los requisitos del software. En este documento, se especifican los requisitos del sistema, en donde los requisitos software se derivan de los requisitos del sistema, y por lo tanto los requisitos de los componentes de software son especificados. En sentido estricto, la especificacin de requisitos del sistema es una actividad de la ingeniera de sistemas y est fuera del alcance de esta gua. IEEE Std 1233 es una gua para los requisitos del sistema que se convierten. (IEEE1233-98). (Gua SWEBOK, SWEBOK 2004, Cap.2.5.2) 2.1.3.3. Requerimientos de Software. La especificacin de requisitos de Software establecen las bases para un acuerdo entre los clientes y contratistas o proveedores (en los proyectos impulsados por el mercado, estas funciones se puede jugar por las divisiones de marketing y desarrollo) en lo que el producto de software tiene que hacer, as como lo que no se espera que hacer. Para los lectores no tcnicos, el documento de especificacin de requisitos de software es a menudo acompaado de un documento de definicin de requisitos de software. Especificacin de requisitos de software permite hacer una evaluacin rigurosa de los requisitos de diseo que puede comenzar antes y despus reduce el rediseo. Tambin debe proporcionar una base realista para la estimacin de los costos del producto, riesgos, y los horarios.

3

El IEEE Std 1362, se refiere al est|ndar del IEEE referente del tema Gua de Tecnologa de la Informacin-De definicin del sistema-Concepto de Operaciones (CONOPS) Documento.


14


Calidad de Software

Las organizaciones tambin pueden utilizar un documento de especificacin de requisitos de software para desarrollar su propia validacin y verificacin de los planes de forma ms productiva. La Especificacin de requisitos de software ofrece una base de informacin para la transferencia de un producto de software a los nuevos usuarios o nuevas mquinas. Por ltimo, puede servir de base para la mejora de software. Los requisitos de software son a menudo escritos en un lenguaje natural, pero, en la especificacin de requisitos software, esto puede ser complementado con descripciones formales o semi-formales. La Seleccin de las anotaciones apropiadas, permite los requisitos y aspectos particulares de la arquitectura de software, que se describan con ms precisin y concisin que en lenguaje natural. La regla general es que se debe utilizar notaciones que permitan a los requisitos, ser descrito con la mayor precisin posible. Esto es especialmente importante para otros tipos de seguridad crtica y algunos tipos de software confiable. Sin embargo, la eleccin de la notacin es a menudo limitada por la formacin, habilidades y preferencias de los autores del documento y los lectores. Una serie de indicadores de calidad se han desarrollado, lo que se puede utilizar para relacionar la calidad de la especificacin de requisitos del software a las variables de otros proyectos, tales como: el costo, la aceptacin, el rendimiento, el horario, la reproducibilidad, los indicadores de calidad, etc. IEEE tiene un estndar, IEEE Std 830 [IEEE830-98], para la produccin y el contenido de la especificacin de requisitos de software. Adems, IEEE 1465 (similar a la ISO / IEC 12119) es un estndar de tratamiento de los requisitos de calidad en los paquetes de software. (IEEE1465-98). (Gua SWEBOK, SWEBOK 2004, Cap.2.5.3) 2.1.3.4. El documento de requerimientos del software. El documento de requerimientos del software (algunas veces denominado especificacin de requerimientos del software o SRS) es la declaracin oficial de que deben implementar los desarrolladores del sistema. Debe incluir 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 del usuario se pueden integrar en una nica descripcin. En otros, los requerimientos del usuario se definen en una introduccin a la especificacin de los requerimientos del sistema. Si existe un gran nmero de Facultad de Ingeniera de Sistemas - UNICA

15


Calidad de Software

requerimientos, los detalles de los requerimientos del sistema se pueden presentar en un documento separado. El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los altos cargos de la organizacin que pagan por el sistema, hasta los ingenieros responsables de desarrollar el software4.Clientes del SistemaEspecifican los requerimientos y los leen para verificar que cumplen sus necesidades. Los clientes especifican los cambios en los requerimientos. Utilizan el documento de requerimientos para planificar una oferta por el sistema y para planificar el proceso de desarrollo de sistemas. Utilizan los requerimientos para comprender que sistema debe desarrollarse.

Administradores

Ingenieros de Sistemas

Ingenieros probadores del sitema

Utilizan los requerimientos para comprender que sistema debe desarrollarse.

Ingenieros encargados del mantenimiento del sistema

Utilizan los requerimientos para comprender el sistema y las relaciones entre sus partes.

Figura 2.2 Usuarios de un documento de requerimientos (Libro SE de Sommerville, Cap.6) 2.1.4. Validacin de requerimientos. La validacin de requerimientos trata de mostrar que estos realmente definen el sistema que el cliente desea. Coincide parcialmente con el anlisis ya que este implica encontrar problemas con los requerimientos. La validacin de requerimientos es importante debido a que los errores en el documento de requerimientos pueden conducir a importantes costos al repetir el trabajo cuando son descubiertos durante el desarrollo o despus de que el sistema est en uso. El coste de arreglar un problema en los requerimientos haciendo un cambio en el sistema es mucho mayor que reparar los errores de diseo o los de codificacin.

4

La diversidad de posibles usuarios significa que el documento de requerimientos tienen que presentar un equilibrio entre la comunicacin de los requerimientos a los clientes, la definicin de los requerimientos en el detalle exacto para los desarrolladores y probadores, y la inclusin de informacin sobre la posible evolucin del sistema.


16


Calidad de Software

Durante el proceso de validacin de requerimientos, se deben llevar a cabo verificaciones sobre requerimientos en el documento de requerimientos. Estas verificaciones comprenden: 2.1.4.1. Verificaciones de validez. Un usuario puede pensar que se necesita un sistema para llevar a cabo ciertas funciones. Pero el anlisis puede identificar que se requiere funciones adicionales o diferentes. Los sistemas tienen diversos stakeholders con diferentes necesidades. 2.1.4.2. Verificaciones de consistencia. Los requerimientos en el documento no deben contradecirse. 2.1.4.3. Verificaciones de completitud. El documento de requerimientos debe incluir requerimientos que definan todas las funciones y restricciones propuestas por el usuario del sistema. 2.1.4.4. Verificaciones de realismo. Los requerimientos deben verificarse para asegurar que se pueden implementar. 2.1.4.5. Verificalidad. Esto significa que debe poder escribir un conjunto de pruebas que demuestren que el sistema a entregar cumple con cada uno de los requerimientos especificados. (I.S de Ian Sommerville, Cap.7.1) 2.2. IEEE. Siglas que corresponde como, El Instituto de Ingenieros Elctricos y Electrnicos. IEEE es la asociacin ms grande del mundo profesional que se dedica a la innovacin tecnolgica y avanzar en la excelencia en beneficio de la humanidad. IEEE y sus miembros inspirar a una comunidad global a travs de publicaciones ms citadas del IEEE, conferencias, estndares de tecnologa y las actividades profesionales y educativas. 5 La denominada I-triple-E es una sin fines de lucro asociacin profesional con sede en los Estados Unidos que se dedica a promover la innovacin tecnolgica

5

Fuente de IEEE: http://www.ieee.org/about/index.html


17


Calidad de Software

y la excelencia. Cuenta con ms de 400.000 miembros en ms de 160 pases, alrededor del 45% de los cuales residen fuera de los Estados Unidos.6 2.2.1. IEEE 830-1984 Gua de Requisitos de Software Especificaciones. Analiza la informacin de base para escribir un buen software de especificacin de requisitos (SRS). Las caractersticas de un buen SRS es que es inequvoca (de ah el uso de especificaciones de requisitos formales de idiomas debido a dificultades en el lenguaje natural), completa, verificable y coherente, modificable, rastreable, y utilizables durante la operacin y la fase de mantenimiento. La evolucin de la preparacin y las herramientas para el desarrollo de una SRS se describen. Los mtodos utilizados para expresar los requerimientos de software, es decir las especificaciones de entrada / salida y el tiempo matemtico, funcionales, y otros modelos se discuten, tambin la anotacin de trampas requisito comn y en su expresin. Por ltimo, existe un esquema prototipo de SRS, que incluye una descripcin general y requisitos de las especificaciones.7 2.2.2. IEEE 830-1998 - Prcticas recomendadas para IEEE Requisitos de software Especificaciones. El contenido y las cualidades de un buen software de especificacin de requisitos (SRS) se describen, y varios ejemplos de esquemas SRS se presentan. Esta prctica se recomienda cuyo objetivo es especificar los requisitos de software a desarrollar, pero tambin se puede aplicar para ayudar en la seleccin interna y productos de software comercial. Directrices para el cumplimiento con los estndares IEEE / EIA estndar 12207.1-1997 tambin se proporcionan.8 2.2.3. Objetivos de la ERS. Los principales objetivos que se identifican en la especificacin de requisitos software son [Chalmeta, 2000]: a. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software: El cliente debe participar activamente en la especificacin de requisitos, ya que ste tiene una

6

fuente Wikipedia: http://en.wikipedia.org/wiki/IEEE

Fuente IEEE Xplore: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&arnumber=2782537 8

Fuente IEEE: http://standards.ieee.org/findstds/standard/830-1998.html


18


Calidad de Software

visin mucho ms detallada de los procesos que se llevan a cabo. Asimismo, el cliente se siente partcipe del propio desarrollo. b. Ayudar a los desarrolladores a entender qu quiere exactamente el cliente: En muchas ocasiones el cliente no sabe exactamente qu es lo que quiere. La ERS permite al cliente definir todos los requisitos que desea y al mismo tiempo los desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena especificacin de requisitos, los costes de desarrollo pueden incrementarse considerablemente, ya que se deben hacer cambios durante la creacin de la aplicacin. c. Servir de base para desarrollos de estndares de ERS particulares para cada organizacin: Cada entidad puede desarrollar sus propios estndares para definir sus necesidades. Una buena especificacin de requisitos software ofrece una serie de ventajas entre las que destacan el contrato entre cliente y desarrolladores (como ya se ha indicado con anterioridad), la reduccin del esfuerzo en el desarrollo, una buena base para la estimacin de costes y planificacin, un punto de referencia para procesos de verificacin y validacin, y una base para la identificacin de posibles mejoras en los procesos analizados. La ERS es una descripcin que debe decir ciertas cosas y al mismo tiempo debe decirlas de una determinada manera. En este documento se presentar una de las formas que viene especificada por el estndar IEEE 830. Una ERS forma parte de la documentacin asociada al software que se est desarrollando, por tanto debe definir correctamente todos los requerimientos, pero no ms de los necesarios. Esta documentacin no debera describir ningn detalle de diseo, modo de implementacin o gestin del proyecto, ya que los requisitos se deben describir de forma que el usuario pueda entenderlos. Al mismo tiempo, se da una mayor flexibilidad a los desarrolladores para la implementacin. As pues, el grado y el lenguaje utilizado para la documentacin de los requisitos estarn en funcin del nivel que el usuario tenga para entender dichas especificaciones. 2.2.4. Caractersticas de una buena ERS. Las caractersticas deseables para una buena especificacin de requisitos software que se indican en el IEEE son las siguientes [Chalmeta, 2000] [Piattini, 1996]: Correcta No ambigua


19


Calidad de Software

a.

Completa Verificable Consistente Clasificada Modificable Explorable Utilizable durante las tareas de mantenimiento y uso Correccin

La ERS es correcta si y slo si todo requisito que figura en ella refleja alguna necesidad real. La correccin de la ERS implica que el sistema implementado ser el sistema deseado. b. Ambigedad

Un documento es no ambiguo si y solo si cada requisito descrito tiene una nica interpretacin. Cada caracterstica del producto final debe ser descrita utilizando un trmino nico y, en caso de que se utilicen trminos similares en distintos contextos, se deben indicar claramente las diferencias entre ellos. Incluso se puede incluir un glosario en el que indicar cada significado especficamente. Los analistas deben poner un cuidado especial a la hora de especificar los requisitos. El hecho de utilizar el lenguaje natural para hacer la ERS comprensible a los usuarios supone un riesgo muy elevado, porque el lenguaje natural puede llegar a ser muy ambiguo. Ejemplo:

Todos los clientes tienen el mismo campo de control 1.- Todos tienen el mismo valor en el campo de control? 2.- Todos los campos de control tienen el mismo formato? 3.- Un campo de control se usa para todos los clientes?

En trminos generales, el lenguaje natural es de los ms ambiguos. Por el contrario existen los lenguajes formales que no son ambiguos, pero son ms difciles de aprender y menos comprensibles para el que no los conoce.


20


Calidad de Software

c.

Completitud

Una ERS es completa si: Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecucin, diseo, atributos de calidad o interfaces externas). Existe una definicin de respuestas a todas las posibles entradas, tanto vlidas como invlidas, en todas las posibles situaciones. Cumple con el estndar utilizado. Si hay alguna parte del estndar que no se utiliza, se debe razonar suficientemente por qu no se ha utilizado dicho apartado. Aparecen etiquetadas todas las figuras, tablas, diagramas, etc., as como definidos todos los trminos y unidades de medida empleados.

La ERS debe ser siempre completa, aunque en ocasiones esto no ser posible. Por ejemplo si todava no se han determinado los formatos de los informes finales o por cualquier razn se est esperando la publicacin de un Real Decreto o un reglamento sobre impuestos. d. Verificabilidad

Un requisito se dice que es verificable si existe algn proceso no excesivamente costoso por el cual una persona o una mquina puedan chequear que el software satisface dicho requerimiento. Ejemplo No verificables: El producto debera funcionar bien El producto debera tener una buena interfaz de usuario Verificable: La salida se suministra dentro de los 20 segundos siguientes al evento E el 60% de las veces, y en los 30 segundos siguientes en el 100% e. Consistencia

Una ERS es consistente si y slo si ningn conjunto de requisitos descritos en ella son contradictorios o entran en conflicto. Se pueden dar tres casos: Requisitos que describen el mismo objeto real utilizando distintos trminos. Las caractersticas especificadas de objetos reales. Un requisito establece que todas las luces son verdes y otro que son azules.


21


Calidad de Software

Conflicto lgico o temporal entre dos acciones determinadas. Se llega a un punto en el que dos acciones seran perfectamente vlidas (sumar o multiplicar?). Clasificacin

f.

No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios: Importancia: Pueden ser esenciales, condicionales u opcionales. Estabilidad: Cambios que pueden afectar al requisito.

Lo ideal es el establecimiento de prioridades, de modo que la implementacin de un requisito de menor prioridad no emplee excesivos recursos. g. Modificabilidad

Una ERS es modificable si cualquier cambio puede realizarse de manera fcil, completa y consistente. Para ello, es deseable tener una organizacin coherente y fcil de usar en la que aparezca el ndice o una tabla de contenidos fcilmente accesible. Tambin es deseable evitar la redundancia, es decir que no aparezca un mismo requisito en ms de un lugar de la ERS. No es un error, pero si se tiene que modificar alguna cosa ser mucho ms cmodo si no tenemos que buscar el mismo requisito en varios lugares. h. Explorabilidad (traceability)

Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrs (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito). Cuando un requisito de la ERS representa un desglose o una derivacin de otro requisito, se debe facilitar tanto las referencias hacia atrs como hacia adelante en el ciclo de vida. Las referencias hacia delante de la ERS son especialmente importantes para el mantenimiento del software. Cuando el cdigo y los documentos son modificados, es esencial poder comparar el conjunto total de requisitos que puedan verse afectados por estas modificaciones. i. Utilizable durante las tareas de mantenimiento y uso

En la ERS tambin se deben tener en cuenta las necesidades de mantenimiento. El personal que no ha intervenido directamente en el


22


Calidad de Software

desarrollo debe ser capaz de encargarse de su mantenimiento. As, dicha ERS acta a modo de plano de la aplicacin, permitiendo incluso modificaciones que no requieran un cambio en el diseo. En ocasiones, el equipo de desarrollo supone unos conocimientos que el personal que se encargue del mantenimiento no tiene por qu tener. Por esta razn es necesaria una correcta documentacin de las funciones, ya que si no se conoce en detalle su origen, difcilmente podrn ser modificadas. 2.2.5. Esquema de la ERS definida en el IEEE 830-1998. La siguiente figura muestra la estructura de la ERS propuesta por el IEEE en su estndar 830 [IEEE, 1998]. 1 Introduccin 1.1 Propsito 1.2 mbito del Sistema 1.3 Definiciones, Acrnimos Abreviaturas 1.4 Referencias 1.5 Visin general del documento 2 Descripcin General 2.1 Perspectiva del Producto 2.2 Funciones del Producto 2.3 Caractersticas de los usuarios 2.4 Restricciones 2.5 Suposiciones y Dependencias 2.6 Requisitos Futuros 3 Requisitos Especficos 3.1 Interfaces Externas 3.2 Funciones 3.3 Requisitos de Rendimiento 3.4 Restricciones de Diseo 3.5 Atributos del Sistema 3.6 Otros Requisitos 4 Apndices 5 ndice Figura 2.3 Estructura de una ERS 2.3. IEEE Computer Society. La IEEE Computer Society (a veces abreviado Computer Society o CS) es una organizacin profesional de IEEE. Su finalidad y el alcance son "para avanzar en la teora, prctica y aplicacin de la ciencia informtica y procesamiento de la

y


23


Calidad de Software

informacin y la tecnologa" y "la capacidad profesional de sus miembros." La Computer Society patrocina talleres y conferencias, pblica una variedad de publicaciones revisadas por homlogos, opera comits tcnicos, y desarrolla estndares IEEE computacin. Es compatible con ms de 200 captulos en todo el mundo y participa en actividades educativas en todos los niveles de la profesin, incluida la educacin a distancia, la acreditacin de programas de educacin superior en ciencias de la computacin, y la certificacin profesional en ingeniera de software.9 Con cerca de 85.000 miembros, el IEEE Computer Society es la organizacin lder a nivel mundial de profesionales de la informtica. Fundada en 1946, y el ms grande de la IEEE de 38 sociedades, la Sociedad de Computacin se dedica a promover la teora y la aplicacin de la informtica y la tecnologa de la informacin. La Sociedad de Computacin responde a las necesidades de informacin y desarrollo de la carrera de los investigadores de computacin de hoy y profesionales con los libros, conferencias, publicaciones de conferencias, revistas, cursos en lnea, las certificaciones de desarrollo de software, normas y publicaciones tcnicas.10 2.4. SWEBOK. Software Engineering Body of Knowledge, es un documento creado por la Software Engineering Coordinating Committee, promovido por la IEEE Computer Society, que se define como una gua al conocimiento presente en el rea de la Ingeniera del Software. Supone un paso esencial hacia el desarrollo de la profesin porque representa un amplio consenso respecto a los contenidos de la disciplina.11

9

Fuente de Wikipedia: http://en.wikipedia.org/wiki/IEEE_Computer_Society10

Fuente de IEEE Computer: http://www.computer.org/portal/web/about Fuente de SWEBOK: http://www.computer.org/portal/web/swebok/home

11


24


Calidad de Software

3. REQUERIMIENTOS FUNCIONALES Y REQUERIMIENTOS NO FUNCIONALES.A menudo, los requerimientos de sistemas de software se clasifican en funcionales y no funcionales. Los requerimientos funcionales: son declaraciones de los servicios que debe de proporcionar el sistema, de la manera en que este debe reaccionar a entradas particulares y de cmo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin pueden declarar explcitamente lo que el sistema no debe hacer. Los requerimientos no funcionales son restricciones de los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estndares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a caractersticas o servicios individuales del sistema. 3.1. Requerimientos Funcionales. Un requerimiento funcional define el comportamiento interno del software: clculos, detalles tcnicos, manipulacin de datos y otras funcionalidades especficas que muestran cmo los casos de uso sern llevados a la prctica. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseo o la implementacin. Wikipedia. Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organizacin al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo, los requerimientos funcionales del sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc. Los requerimientos funcionales para un sistema software se pueden expresar de diferentes formas. A continuacin se presentan algunos ejemplos de estos requerimientos funcionales para un sistema de biblioteca universitaria denominado BibliotecaUnica. El usuario deber tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella. Facultad de Ingeniera de Sistemas - UNICA

25


Calidad de Software

El sistema deber proporcionar visores adecuados para que el usuario lea documentos en el almacn de documentos. A cada pedido se le deber asignar un identificador nico (Id_Pedido), que el usuario podr copiar al rea de almacenamiento permanente de la cuenta. Estos requerimientos funcionales del usuario definen los recursos especficos que el sistema debe proporcionar. Dichos requerimientos se toman del documento de requerimientos del usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los requerimientos funcionales. La impresin en la especificacin de requerimientos es la causa de muchos de los problemas de la ingeniera del software. 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 deben establecer nuevos requerimientos y hacer cambios en el sistema. Por supuesto, esto retrasa la entrega de este e incrementa los costes. Considere el segundo ejemplo de los requerimientos funcionales para el sistema BibliotecaUnica que se refiere a los Visores Adecuados que debe proporcionar el sistema. El sistema de biblioteca puede mostrar documentos en diferentes formatos; la intencin de este requerimiento es que los visores para todos estos formatos estn disponibles. Sin embargo, el requerimiento esta ambiguamente redactado; no clarifica que se deben proporcionar los visores de cada formato. Un desarrollador bajo la presin del tiempo sencillamente podra proporcionar un visor de texto y afirmar que se ha cumplido el requerimiento. En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar definidos. La consistencia significa que los requerimientos no deben tener definiciones contradictorias. En la prctica, para sistemas grandes y complejos, es prcticamente imposible alcanzar los requerimientos de consistencia y completitud. Una razn de esto es que es fcil cometer errores y omisiones cuando se redactan especificaciones grandes y complejos. Otra razn es que los stakeholders del sistema tienen necesidades diferentes, a menudo contradictorias. Estas contradicciones pueden no ser obvias cuando los requerimientos se especifican por primera vez, por lo que se incluyen requerimientos contradictorios en la especificacin. Es posible que los


26


Calidad de Software

problemas surjan solamente despus de un anlisis ms profundo o, a veces, despus de que se termine el desarrollo y el sistema se entregue al cliente. 3.2. Requerimientos No Funcionales. Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones especficas que proporciona el sistema, sino a las propiedades emergentes de este como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/ salida y las representaciones de datos que se utilizan en las interfaces del sistema. Los requerimientos no funcionales rara vez se asocian con caractersticas particulares del sistema. Ms bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Por lo tanto, pueden especificar el rendimiento del sistema, la proteccin, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son ms crticos que los requerimientos funcionales particulares. Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una funcin del sistema que realmente no cumple sus necesidades. Sin embargo, el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable. Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificara como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionaran correctamente. Los requerimientos no funcionales no solo se refieren al sistema de software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificacin que el diseo debe producir con una herramienta CASE particular y una descripcin del proceso a seguir. Los requerimientos no funcionales surgen de las necesidades del usuario, debido a las restricciones en el presupuesto, a las polticas de organizacin, a la necesidad de interoperabilidad con otros sistemas software o hardware, o a factores externos como regulaciones de seguridad o legislaciones sobre la privacidad.


27


Calidad de Software

Figura 3.1 Clasificacin de Requerimientos No Funcionales La figura 3.1 es una clasificacin de los requerimientos no funcionales. Puede verse en este diagrama que los requerimientos no funcionales pueden venir de las caractersticas del software (requerimiento del producto), de la organizacin que desarrolla el software (requerimiento Organizacionales) o de fuentes externas. Los tipos de requerimientos no funcionales son: 3.2.1. Requerimientos del Producto. Estos requerimientos especifican el comportamiento del producto. Algunos ejemplos son los requerimientos de rendimiento en la rapidez de ejecucin del sistema y cuanta memoria se requiere; los requerimientos de fiabilidad que fijan la tasa de fallos para que el sistema sea aceptable; los requerimientos de portabilidad, y los requerimientos de usabilidad. 3.2.2. Requerimientos Organizacionales. Estos requerimientos se derivan de las polticas y procedimientos existentes en la organizacin del cliente y en la del desarrollador. Algunos ejemplos son los estndares en los procesos que deben utilizarse; los requerimientos de implementacin, como los lenguajes de programacin o el mtodo de diseo a utilizar, y los requerimientos de entrega que especifican cuando se entregar el producto y su documentacin. 3.2.3. Requerimientos Externos. Este gran apartado incluye todos los requerimientos que se derivan de los factores externos al sistema y de su proceso de desarrollo. Estos pueden incluir los requerimientos de interoperabilidad que definen la manera en Facultad de Ingeniera de Sistemas - UNICA

28


Calidad de Software

que el sistema interacta con sistemas de otras organizaciones; los requerimientos legislativos que deben seguirse para asegurarse que el sistema funcione dentro de la ley, y los requerimientos ticos. Estos ltimos son puestos en un sistema para asegurar que ser aceptado por sus usuarios y por el pblico en general.La interfaz de usuario de BibliotecaUnica se implementara como HTML simple sin marcos o applets Java El proceso de desarrollo del sistema y los documentos a entregar debern ajustarse al proceso y a los productos a entregar definidos en XYZco-SP-STAN-95 El sistema no deber revelar al personal que lo utilice ninguna informacin personal de los usuarios aparte de su nombre y numero de referencia.

Requerimiento del Producto

Requerimiento Organizacional

Requerimiento Externo

Figura 3.2 Ejemplos de Requerimientos no Funcionales En la figura 3.2 muestra ejemplos de requerimientos del producto, organizacionales y externos del sistema BibliotecaUnica. El requerimiento del producto restringe la libertad de los diseadores del sistema BibliotecaUnica e identifica claramente una restriccin del sistema ms que una funcin. Se incluye este requerimiento debido a que simplifica el problema de asegurar que el sistema funcione con navegadores diferentes. El requerimiento organizacional especifica que el sistema se debe desarrollar conforme a un proceso estndar de la compaa definido como XYZco-SP-STAN-95. El requerimiento externo se deriva de la necesidad del sistema de cumplir la legislacin sobre privacidad. Especifica que no se debe permitir al personal de la biblioteca el acceso a los datos, como la direccin de los usuarios del sistema que no necesitan para realizar su trabajo. Un problema comn con los requerimientos no funcionales es que pueden ser difciles de verificar. Los usuarios o clientes declaran a menudo estos requerimientos como metas generales tales como la facilidad de uso, la capacidad del sistema para recuperarse de los fallos o la respuesta rpida al usuario. Estas metas imprecisas causan problemas a los desarrolladores del sistema puesto que dejan abierta la posibilidad a interpretacin, lo que provoca discusiones subsecuentes una vez que el sistema se entregue. Como ilustracin de este problema, considere la figura 3.3. Esta figura muestra una meta del sistema que se refiere a la usabilidad de un sistema de control de trfico areo y es tpico de cmo un usuario puede expresar los requerimientos de usabilidad. Se ha reescrito para mostrar la manera en Facultad de Ingeniera de Sistemas - UNICA

29


Calidad de Software

que la meta se puede expresar como un requerimiento no funcional que se pueda probar. Aunque es imposible verificar objetivamente la meta del sistema, se pueden disear pruebas del sistema para contar los errores cometidos por los controladores utilizando un simulador del sistema.Una Meta del Sistema: Debe ser fcil para los controladores experimentados utilizar el sistema y se debe organizar de tal modo que se minimicen los errores del usuario. Un Requerimiento no Funcional del sistema: Despus de una formacin de dos horas, a los controladores experimentados les deber ser posible utilizar todas las funciones del sistema. Despus de esta formacin la media de errores cometidos por los usuarios experimentados no exceder de dos por da.

Figura 3.3 Metas del Sistema y Requerimientos Verificables Siempre que sea posible, se deben redactar los requerimientos no funcionales de manera cuantitativa para que se puedan probar de un modo objetivo. La figura 3.4 muestra varias mtricas posibles que pueden usarse para especificar las propiedades no funcionales del sistema. Se pueden medir estas caractersticas cuando se prueba el sistema para comprobar si se cumple sus requerimientos no funcionales.

Figura 3.4 Mtricas para especificar requerimientos no funcionales. En la prctica, sin embargo, los clientes de un sistema pueden encontrar prcticamente imposible traducir sus metas en requerimientos


30


Calidad de Software

cuantitativos. Para algunas metas, como las de mantenibilidad, no existen mtricas que se puedan utilizar. En otros casos, aun cuando sea posible la especificacin cuantitativa, es posible que los clientes no puedan relacionar sus necesidades con estas especificaciones. No entienden lo que significa un cierto nmero que define la fiabilidad requerida (por ejemplo) en funcin de su experiencia diaria con los sistemas informticos. Adems, el coste de verificar de forma objetiva los requerimientos no funcionales cuantitativos puede ser muy alto, y los clientes que pagan por el sistema quizs piensen que estos costes no son justificados. Por lo tanto los documentos de los requerimientos a menudo incluyen las declaraciones de las metas mezclada con los requerimientos. Dichas metas pueden ser tiles para los desarrolladores puesto que dan ideas de las prioridades del cliente. Sin embargo siempre se les debe advertir que estn abiertas a interpretaciones errneas y que no se pueden verificar de forma objetiva. A menudo, los requerimientos no funcionales entran en conflicto e interactan con otros requerimientos funcionales o no funcionales. Por ejemplo, puede haber un requerimiento que especifique que la capacidad mxima de memoria utilizada en un sistema no debe ser mayor de 4 Mbytes. Las restricciones de memoria son comunes en los sistemas embebidos donde el espacio y el peso estn limitados y se debe minimizar el nmero de chips de ROM que almacenan el sistema software. Otro requerimiento podra ser que el sistema debe codificarse utilizando Ada, un lenguaje de programacin para el desarrollo de software critico de tiempo real. Sin embargo puede que no sea posible compilar con menos de 4Mbytes un programa en Ada con la funcionalidad requerida. Por lo tanto, tiene que haber un equilibrio entre estos dos requerimientos: un lenguaje alternativo de desarrollo o un aumento en la memoria del sistema. Es de utilidad diferenciar los requerimientos funcionales y no funcionales en el documento de requerimientos. En la prctica, esto es difcil. Si los requerimientos no funcionales se declaran de forma separada de los funcionales, algunas veces es difcil ver la relacin entre ellos. Si se declaran con los requerimientos funcionales, puede resultar difcil separar las consideraciones funcionales y no funcionales e identificar los requerimientos que se refieren al sistema como un todo. Sin embargo, se deben resaltar explcitamente los requerimientos que claramente se refieran a las propiedades emergentes del sistema, como el rendimiento de la fiabilidad. Se puede hacer colocndolos en una seccin aparte o diferencindolos, de alguna forma, de los otros requerimientos del sistema.


31


Calidad de Software

4. UTILIZACIN DE CASOS DE USO EN LA DEFINICIN DE REQUERIMIENTO DE SOFTWARE.Para la utilizacin de casos de uso en la definicin de requerimientos de software primero debemos conocer algunos conceptos bsicos. 4.1. Historia. El concepto de Caso de Uso fue introducido por Ivar Jacobson en 1986, pues fue una importante contribucin al desarrollo de los modelos de UML y proceso unificado (RUP). Sin embargo, la idea de especificar un sistema a partir de su interaccin con el entorno es original de Mc Menamin y Palmer, dos precursores del anlisis estructurado, que escribieron en 1984 un excelente libro Essential Systems Analysis. En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc Menamin y Palmer, un evento es algo que ocurre fuera de los lmites del sistema, ante lo cual el sistema debe responder. Sin embargo, existen diferencias entre los casos de uso y los eventos. La principal es: Los eventos se centran en describir qu hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cmo es el dilogo entre el usuario y el sistema.

4.2. Definiciones Bsicas. 4.2.1. Caso de Uso. Alistair Cockbbum: En su libro Escribir casos de uso eficaces, menciona que "Un caso de uso EVALUAR captura un contrato que describe el EXAMEN comportamiento del sistema en diferentes condiciones mientras ste responde a la peticin de uno de sus usuarios". En esencia, un caso de uso cuenta una historia estilizada de la manera en que un usuario final (el cual desempea uno de varios papeles posibles) interacta con el sistema en un conjunto especfico de circunstancias. Un caso de uso describe qu hace un sistema (o subsistema, clase o


32


Calidad de Software

interfaz) pero no especifica cmo lo hace. Un caso de uso segn UML se denota por un ovalo y se nombra por un verbo m|s un objeto afectado.

CASO DE USO Un caso de uso, es un proceso especfico del sistema con identidad propia que define una secuencia de acciones que el sistema realiza para un actor en particular. El caso de uso es una tcnica de modelado conceptual de captura de requisitos, orientado a objetos.

Importante: Existe una gran diferencia entre los Requerimientos Funcionales y los Casos de Uso, ya que los primeros se describen desde la perspectiva del usuario o cliente del proyecto y los casos de uso se describen desde la perspectiva de la arquitectura del sistema. 4.2.2. Actor. Un actor representa un conjunto de personas, sistemas, mquinas y de roles que los usuarios de los casos de uso juegan cuando interactan con el sistema. Los actores no son parte del sistema, pues ellos viven fuera Cada actor tiene una o ms metas cuando utiliza el sistema. Un actor representa una clase de entidad externa (con frecuencia, pero no siempre, una persona) que desempea slo un papel en el contexto del caso de uso.

Tipos de Actores: o Los actores primarios interactan para lograr la funcin requerida del sistema y obtienen el beneficio que se espera de ste. Ellos trabajan de manera directa y frecuente con el software. o Los actores secundarios dan soporte al sistema de manera que los actores primarios puedan hacer su trabajo. Ya identificados los actores pueden desarrollarse los casos de uso.


33


Calidad de Software

4.2.3. Condiciones. Pre-Condiciones Describe el ambiente bajo el cual el caso de uso es invocado. Post-Condiciones Reflejan el impacto en el ambiente del caso de uso luego de su ejecucin. Requisitos de Calidad (opcional) Por ejemplo, el sistema debe responder en menos de 30 segundos

4.2.4. Escenario. Un escenario es una secuencia especfica de acciones que ilustran el comportamiento de un caso de uso por descripcin no por moldeamiento. Los escenarios son a los casos de uso como los objetos son a las clases, lo que significa que un escenario es bsicamente una instancia de un caso de uso. Los escenarios son una secuencia de pasos que realiza el actor principal o el sistema, en donde cada paso se escribe como una oracin sobre una meta que se cumple. Un escenario tpicamente especifica un flujo de eventos: o Principal Representa el flujo exitoso ms simple o habitual para el caso de uso. o Alternativo Son formas alternativas al camino principal de llegar a las post condiciones del caso de uso. Son caminos distintos al principal pero que nos permiten de todas formas alcanzar el xito. Cada escenario alternativo parte de una condicin que origina la bifurcacin. Luego se indica en qu paso contina o si, por el contrario, el escenario termina. o De Excepcin Un escenario de excepcin es una secuencia de pasos alternativos a los del camino principal que lleva a que el objetivo del caso de uso NO sea alcanzado, es decir que no se logre llegar a las postcondiciones el sistema. Son caminos que hacen que el usuario no pueda cumplir con su objetivo. 4.2.5. Diagramas de Casos de Uso. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los


34


Calidad de Software

usuarios y/o otros sistemas. Muestra la relacin entre los actores y los casos de uso en un sistema. Se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona una respuesta a eventos que se producen en el mismo. El diagrama de casos de uso forma parte del conjunto de herramientas del UML y es muy simple elaborar un diagrama de este tipo. Bsicamente se conforma de dos figuras elementales el ACTOR y el CASO DE USO.

Figura 4.1 Diagrama de casos de uso 4.2.6. Organizacin de Casos de Uso. En la mayora de sistemas, el nmero de casos de uso es lo suficientemente elevado como para que sea oportuno organizarlos de alguna forma en lugar de tener una lista plana por la que no es fcil navegar. Una posible forma de organizar los casos de uso es recurrir a los paquetes descritos en la propuesta de UML [Booch et al. 1999]. De esta forma, los casos de uso pueden organizarse en niveles, facilitando as su comprensin. Cada paquete contiene a otros paquetes o a varios casos de uso. En el caso de que los casos de uso se agrupen por criterios funcionales, los paquetes que los agrupan pueden estereotiparse como subsistemas.

Figura 4.2 Casos de uso divido por paquetes Facultad de Ingeniera de Sistemas - UNICA

35


Calidad de Software

4.3. Comportamiento. Dentro de la ejecucin de un caso de uso pueden encontrarse actividades que se repiten en otros casos de uso. Ests repeticiones se modelan a travs de asociaciones entre casos de uso. ASOCIACIN DE TIPO INCLUSIN (INCLUDE). o Se establece cuando el caso de uso base necesita incluir obligatoriamente la secuencia de acciones descritas por el caso de uso incluido. o Es una relacin de dependencia entre dos casos de uso. o Indica que el comportamiento del caso de uso incluido est explcitamente insertado dentro del comportamiento definido por el caso de uso base. o Parte desde un caso de uso base hacia un caso de uso incluido. o La flecha se orienta de manera que indique que el caso de uso base es el que necesita incluir al caso de uso incluido. o El caso de uso base es el que conoce la asociacin entre ambos y el caso de uso incluido no necesita conocer cules casos de uso lo incluyen. o Se utiliza el estereotipo y se coloca encima de la flecha. ASOCIACIN DE TIPO EXTENSIN (EXTEND). o Se establece cuando el caso de uso extendido ocurre excepcionalmente en el caso de uso base. o El caso de uso extendido ocurre solo cuando ocurra el evento respectivo dentro del caso de uso base. o Es una relacin de dependencia entre dos casos de uso. o Indica que el comportamiento del caso de uso extendido puede ser insertado en el comportamiento definido por el caso de uso base. o La flecha se orienta de manera que indique que el caso de uso extendido constituye la extensin del caso de uso base. o Se utiliza el estereotipo y se coloca encima de la flecha. ASOCIACIN DE TIPO GENERALIZACIN. o Es una relacin de herencia entre casos uso. o Los casos de uso hijos heredan la estructura, comportamiento y asociaciones del caso de uso padre. o El caso de uso padre es abstracto y solo se crean instancias de los casos de uso hijos. o Utilizar la generalizacin cuando existen dos o ms casos de uso que


36


Calidad de Software

poseen un comportamiento y estructura muy comn. o Se utiliza una flecha con cabeza transparente. o La flecha se orienta de manera que indique que los casos de uso hijos necesitan heredar el comportamiento del caso de uso padre.

EJEMPLO DE INCLUDECASO DE USO HIJO 1 CASO DE USO

EJEMPLO DE EXTEND

CASO DE USO HIJO 2

EJEMPLO DE GENERALIZACION 4.4. Caractersticas. Los casos de uso tienen las siguientes caractersticas: Estn expresados desde el punto de vista del actor. Se documentan con texto informal. Describen tanto lo que hace el actor como lo que hace el sistema cuando interacta con l, aunque el nfasis est puesto en la interaccin. Son iniciados por un nico actor. Estn acotados al uso de una determinada funcionalidad claramente diferenciada del sistema.

4.5. Anlisis de Requerimientos con Casos de Uso. A continuacin se describen las actividades a seguir para la especificacin de requerimientos con casos de uso. 4.5.1. Identificar y Clasificar Requisitos. Esta actividad es el punto de partida para las siguientes actividades del proceso de obtencin de requisitos y se refiere a la identificacin de los requisitos del sistema de software a desarrollar. En esta actividad, deberemos responder a los siguientes cuestionamientos:


37


Calidad de Software

que le permitir hacer, el sistema de software, al usuario? y el cliente o usuario me solicita alguna restriccin para construir el sistema de software? Contestando a esas preguntas se deber realizar una lista que contendr los requisitos del sistema. Luego de haber obtenido la lista de requisitos, estos debern ser clasificados en dos grupos: requisitos funcionales y requisitos no funcionales. Los requisitos funcionales son declaraciones de los servicios que proveer el sistema, de la manera en que este reaccionara a entradas particulares y de cmo se comportara en situaciones particulares. En algunos casos, los requisitos funcionales declaran explcitamente lo que el sistema no debe hacer. 4.5.2. Identificar los Actores. El primer paso al escribir un caso de uso consiste en definir el conjunto de "actores" que estarn involucrados en la historia. La primera pregunta que un analista debe hacer a sus usuarios es Para qu es este sistema?, la segunda es claramente Para quines es este sistema? Como mencionamos al hablar sobre los actores, identificar a todos ellos es crtico para un buen anlisis de requerimientos. Por lo tanto, antes de avanzar con los casos de uso, debo tratar de identificar todos los tipos de usuario diferentes que tiene el sistema. A pesar de hacer una identificacin inicial de los actores, tambin debe repetirse a medida que empiezo a describir los casos de uso, ya que al conocer ms detalles del sistema pueden aparecer nuevos tipos de usuarios. Jacobson sugiere varias preguntas que se deberan contestar mediante un caso de uso. Quin(es) es(son) el(los) actor(es) primario{s)? Cules son las metas del actor? Cules son las condiciones previas que deben existir antes de comenzar la historia? Cules son las tareas o funciones principales que realiza el actor? Cules excepciones podran considerarse mientras se describe la historia? cules son las variaciones posibles en la interaccin del actor? Cul es la informacin del sistema que el actor adquirir, producir o cambiar? El actor tendr que informar al sistema acerca de cambios en el medio ambiente externo?


38


Calidad de Software

Cul es la informacin que el actor desea del sistema? El actor quiere ser informado acerca de cambios inesperados? 4.5.3. Identificar Escenarios. Identificar la secuencia de pasos que se produce cuando un actor interacta con el sistema en una situacin especfica y un tiempo determinado. Un ejemplo de escenario para un sistema de biblioteca es el siguiente: Juan Prez se conecta al sistema de la Biblioteca Nacional a travs de Internet. Juan Prez selecciona realizar bsqueda y cuando aparece el formulario ingresa en ttulo de libros la frase especificacin de requisitos. El sistema encuentra un nico libro y lo muestra, el libro de la biblioteca es Especificacin de Requisitos de Software de Alan Davis y cdigo B 73-825. 4.5.4. Identificar los principales Casos de Uso de cada actor. El siguiente paso es enunciar los nombres de los principales casos de uso de cada uno de los actores que identifiqu en el paso anterior. No es necesario especificar cules son las acciones dentro del caso de uso. Tampoco preocuparse si no aparecen muchos casos, ya que existen tcnicas para encontrar nuevos casos de uso a partir de los existentes. Para nombrar casos de uso, usar un verbo para mostrar la accin desarrollada. Cada requerimiento funcional debe estar cubierto por al menos un caso de uso. 4.5.5. Identificar nuevos casos a partir de los existentes. Uno de los principales errores que se pueden cometer al identificar requerimientos es algo que parece obvio, pero que muchas veces ocurre: olvidarse de algn requerimiento! .Como los requerimientos estn en la cabeza de los usuarios, el xito de esta tarea depende de la habilidad del analista. Para ayudar a identificar nuevos casos de uso a partir de los casos existentes, podemos aplicar las mismas tcnicas utilizadas para identificar eventos segn el anlisis estructurado. Esta tcnica se basa en el anlisis de cuatro situaciones posibles a partir de los requerimientos ya identificados. a) Variaciones Significativas de Casos de Uso Existentes. Muchas veces existen variaciones en los casos de uso en funcin del actor que los ejecuta, o del tipo de objeto sobre el que se apliquen. Si especificamos dos casos de uso similares como un nico caso de


39


Calidad de Software

uso, en el texto del caso tendremos muchos Si pasa X, hago A, si no, hago B. Este hace un poco m|s difcil de seguir la especificacin. Si especifico dos casos de uso con funcionalidad en comn como dos casos de uso distintos, la relacin de uso me puede ayudar a evitar la redundancia. b) Casos de Uso Opuestos Hay dos formas de buscar casos de uso opuestos: La primera es buscar la funcin opuesta a la descrita por el caso. Por ejemplo, en el caso de realizar un pedido, podemos pensar que la funcin opuesta es cancelar ese mismo pedido. Si cancelar pedidos es una funcin que mi sistema debe realizar, y que no haba identificado anteriormente, acabo de evitarme un error que puede ser muy costoso de corregir ms adelante. La otra forma de buscar casos de uso opuestos es pensar en la negacin de la accin principal del caso de uso. Supongamos que tenemos un caso de uso Pagando Pedido, que es realizado por el actor cliente. El caso No Pagando Pedido, puede de nuevo ser significativo. Si el cliente no paga el pedido, tal vez nuestro sistema deba hacer algo, y podemos estar frente a un nuevo caso de uso. c) Casos de Uso que Preceden a Casos Existentes Una buena pregunta para hacer frente a un caso de uso es: Qu es lo que tiene que ocurrir antes de este caso de uso? En el caso del cliente que hace un pedido, son muchas las cosas que pueden ocurrir antes de ese caso: El cliente, por ejemplo, debe ser cliente. En esta situacin tal vez tenga un nuevo caso de uso Ingresando Cliente, que puede o no ser un caso de mi sistema. d) Casos de Uso que Suceden a Casos Existentes Esto es similar al punto anterior. La pregunta que debo hacerme es: Qu ocurre despus de este caso de uso? Por lo tanto, analizar cmo sigue la historia es una buena forma de asegurarme que no estoy dejando requerimientos sin identificar.


40


Calidad de Software

4.5.6. Crear descripciones de casos de uso. Una vez que identificamos todos los casos de uso, empezamos a documentar sus pasos. Esta tarea no es estrictamente secuencial de la anterior: es posible que, mientras empezamos a documentar los casos, sigamos buscando otros nuevos. 4.5.7. Definir prioridades y seleccionar casos de la primera iteracin. Una vez documentados los casos de trazo grueso, es conveniente definir las prioridades de los distintos requerimientos, expresados como casos de uso. Para esto suele ser til usar tres categoras: imprescindible, importante y deseable. Los requerimientos imprescindibles son aquellos que, si no se implementan, hacen que el sistema no tenga sentido. Los importantes son aquellos que haran que el usuario se sienta decepcionado si no se implementan. Los deseables son aquellos que el usuario querra tener, si hubiese tiempo disponible.

Al evaluar un requerimiento se debe tambin analizar su costo o complejidad. Una vez hecha esta categorizacin de los requerimientos, se puede tomar como estrategia general el incluir los imprescindibles, discutir los importantes y descartar los deseables cuyo costo no sea bajo. 4.5.8. Escribir los casos y crear prototipos de interfaces. Una vez seleccionados los casos de uso que pienso implementar en la primera iteracin, empiezo a profundizar sus definiciones. Al mismo tiempo, suele ser una excelente idea crear un prototipo visual de la implementacin de los casos. Con las herramientas existentes actualmente, esto es muy simple de hacer, y nos puede evitar muchos problemas. Cuando creamos prototipos de la implementacin de los casos de uso, debemos tener en cuenta que: Estos son prototipos para descartar: si incluimos algo de cdigo en el prototipo, debe ser descartado o revisado con mucho cuidado si se piensa mantener. Estamos intentando validar el estilo de la interaccin, no toda la interaccin: no debemos dejarnos llevar por el entusiasmo. Si tenemos varios casos de uso que realizan funciones similares, o con una interfaz similar, puede alcanzar con crear un prototipo de slo


41


Calidad de Software

una de ellas. Queremos que el usuario se d una idea sobre cmo se ver el sistema, no que nos apruebe todas sus pantallas y listados. 4.6. Plantilla para descripcin de casos de uso.

Figura 4.3 Plantilla de Caso de Uso. Facultad de Ingeniera de Sistemas - UNICA

42


Calidad de Software

4.7. Plantilla de actores.

Figura 4.4 Plantilla de actores. 4.8. Documentacin de caso de uso. 1. Descripcin Breve 2. Flujo Bsico de Eventos 3. Flujos Alternativos 3.1. 4. Escenarios Claves 5. Precondiciones 5.1. < Precondicin 1 > 6. Post-Condiciones 6.1. < Post-condicin 1 > 7. Puntos de Extensin 7.1. 8. Requerimientos Especiales 8.1. < Requerimiento Especial 1> 9. Informacin Adicional 9.1. Prototipo Visual 10. 9.2Informacin Complementaria Historia de Revisiones Versin Descripcin

Fecha

Autor


43


Calidad de Software

5. USO DEL FORMATO DE ESPECIFICACIN DE REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES.5.1. Formato de Requerimientos Funcionales. Un requisito funcional define el comportamiento interno del software: clculos, detalles tcnicos, manipulacin de datos y otras funcionalidades especficas que muestran cmo los casos de uso sern llevados a la prctica. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseo o la implementacin. Como se define en la ingeniera de requisitos, los requisitos funcionales establecen los comportamientos del sistema. Tpicamente, un analista de requisitos genera requisitos funcionales luego de diagramar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requisitos son previos al diseo de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional. Un formato de especificacin de un requisito funcional tpico contiene: Cdigo: El cual es necesario para poder identificar el requerimiento. Nombre: Que describa de qu funcin se trata. Objetivos Asociados: Nos indica el objetivo al cual va asociado el requerimiento. Requisitos Asociados: Son los requisitos con los cuales comparte informacin e interacta el requisito actual. Descripcin: Describa que es lo que har el requisito funcional. Pre- condicin: Condicin que se debe de cumplir para que el requisito se cumpla. Secuencia Normal: Nos muestra paso a paso como se realizara el requisito. Post- condicin: Una vez terminado el requisito funcional, nos muestra las condiciones que se deben de realizar inmediatamente. Excepciones: Nos muestra las excepciones que se tendran que tomar en cuenta si se cumplen ciertas situaciones. Rendimiento: Nos indica cual vendra a hacer el rendimiento esperado. Frecuencia esperada: Es la frecuencia que se espera que el sistema soportara por unidad de tiempo. Comentarios: son notas, mensajes que para un mayor entendimiento se colocan al final.

Esta informacin se utiliza para ayudar al lector a entender por qu el requisito es necesario, y para seguir al mismo durante el desarrollo del producto. El ncleo del requisito es la descripcin del comportamiento requerido, que Facultad de Ingeniera de Sistemas - UNICA

44


Calidad de Software

debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interaccin con usuarios, inversores y otros expertos en la organizacin. Ejemplo de Formato de Requerimientos Funcionales RF-10 Objetivos Asociados Requisitos Asociados Descripcin Precondicin Secuencia Normal Hacer un Pedido va Web OBJ-05 Gestionar Pedidos RI-02 Informacin sobre Clientes RI-03 Informes sobre Proveedores El sistema permitir al cliente realizar un pedido a travs de la pgina web de la empresa. Ingresar a su cuenta de Usuario. Paso 1 Accin El cliente llena el formulario de pedido con los datos correspondientes. 2 El cliente enva el pedido. 3 El sistema registra el pedido. El usuario encargado gestiona el pedido. Accin --Cota de Tiempo 1 segundo

Postcondicin Excepciones

Paso --Rendimiento Paso 3 Frecuencia 20 veces/semana esperada Comentarios Ninguno

5.2. Requerimientos No Funcionales. Un requisito no funcional o atributo de calidad es, en la ingeniera de sistemas y la ingeniera de software, un requisito que especifica criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus comportamientos especficos, ya que stos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen informacin a guardar, ni funciones a realizar. Ejemplo de Formato de Requerimientos No Funcionales RNF-1 Objetivos asociados Copias de Seguridad --


45


Calidad de Software

Requisitos asociados Descripcin

-El sistema deber incorporar algn mecanismo que permita realizar copias de seguridad de los datos almacenados. Ninguno.

Comentarios


46


Calidad de Software

Bibliografa.Roger S. Pressman 2010. Ingeniera de Software: Un Enfoque Prctico. Sptima Edicin: Mac Graw Hill, 2010. ISBN: 978-607-15-0314-3. Ian Sommerville 2005. Sommerville, I. 2002. Ingeniera de Software. 6 Edicin. s.l. : Addison-Wesley, 2002. Som

defenicion de producto de software_ok

Documents