TI0020_M1AA1_Requerimientos

TI0020_M1AA1_Requerimientos

"#$%#&'('#)*+, -# ,',*#(., -# ')/+&(.0'1) por Leticia Pureco Reyes

Durante la primera etapa del desarrollo de un proyecto de sistemas, una de las partes esenciales es la obtención y definición de requerimientos.

En este punto se identifica lo que esperan los usuarios y clientes del sistema, además de las necesidades reales de la organización. Figura 1. Shaking (UVEG, 2012).

En muchas ocasiones los clientes piensan que el software resolverá resolverá problemáticas no relacionadas con la implementación de tecnología, de ahí la importancia de mantener una comunicación efectiva entre todos los participantes del proyecto y llevar a cabo una propuesta apegada a lo que la organización requiere. Como parte de la determinación de requerimientos, es importante identificar los alcances y limitaciones del sistema para informar de manera oportuna a los clientes, evitando así problemas futuros. Pfleeger (2002) define los requerimientos como “una característica del sistema o algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito del sistema” (p.156).

!"# %&%'()"* Juan es un trabajador de una tienda de zapatos que al final de cada mes genera un reporte de las ventas obtenidas. Para Juan el tener ese reporte es una necesidad. Dado lo anterior, un requerimiento del sistema será permitir a Juan generar el reporte de las ventas mensuales. Dentro del desarrollo de sistemas existen diferentes necesidades por atender. Por lo tanto, se han clasificado los requerimientos en función del aspecto que buscan satisfacer, para de esa manera asegurar que el producto terminado cumpla con las especificaciones. Otra causa por la que se han catalogado los requerimientos es para poder realizar las pruebas y determinar si el software desarrollado satisface a la organización, además de considerar la gran 1 ©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por escrito de la Universidad Virtual del Estado de Guanajuato.


diversidad de personas que tendrán acceso a la información y para las cuales debe quedar muy claro lo que se desea realizar. Otras razones por las cuales se catalogan los requerimientos, son las de realizar las pruebas y determinar si el software desarrollado satisface a la organización, además de considerar la gran diversidad de personas que tendrán acceso a la información y para las cuales debe quedar muy claro lo que se desea realizar. Sommerville (2005), en su libro Ingeniería del software indica que los principales tipos de requerimientos que podemos encontrar durante el desarrollo de un proyecto son: “de usuario” (p. 109), “tecnológicos” (p. 109), “de dominio” (p. 109),” de sistema” (p. 118),” funcionales” (p. 110) y “no funcionales” (p. 111). En la figura 2 se describen cada uno de ellos.

De usuario

Se refieren a necesidades que tienen las personas que utilizarán el sistema, tales como cajeras, empleados de mostrador, capturistas.

Tecnológicos

Especifican las características del hardware, software, redes, equipo de telecomunicaciones y demás elementos que requiera el sistema.

De dominio

Determinan las características de la aplicación del sistema. Pueden ser restricciones o aspectos funcionales nuevos. Funcionales

De sistema

Describen las funciones y servicios que el sistema debe realizar. No Funcionales

Indican lo que el sistema debe hacer.

Describen aspectos no relacionados con la funcionalidad como: seguridad, legislación, eficiencia, rendimiento, tiempos, espacio.

Figura 2. Tipos de requerimientos (Sommerville, 2005).

Dentro de los requerimientos no funcionales tenemos la siguiente clasificación: 2 ©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por escrito de la Universidad Virtual del Estado de Guanajuato.


Figura 3. Requerimientos No Funcionales. (Sommerville, 2005, p.112).

Como observamos en la figura 3, los requerimientos no funcionales cuentan con una clasificación muy amplia. En la tabla 1 se presentan algunos ejemplos de requerimientos. Tipo de requerimiento Usuario

Situación actual

-

El vendedor debe generar un reporte cada seis meses.

-

El sistema debe imprimir un reporte de las ventas semestrales.

-

El capturista ingresa 10 datos para un registro, uno de ellos es el mes.

-

El sistema necesita tener la opción de autocompletar en los meses del año.

-

El responsable de almacén tiene que contactar a los proveedores cuando la existencia sea de 3 productos.

-

El sistema requiere mostrar una alerta cuando únicamente queden tres productos en existencia.

-

En ocasiones las personas que registran a los estudiantes colocan letras en la edad quedando la información incompleta. La organización no cuenta con lectores de códigos de barras.

-

Que el sistema no permita capturar letras en el espacio asignado para la edad.

-

Adquirir un lector de código de barras compatible con computadoras Mac.

-

Tecnológicos

Requerimiento

3 ©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por escrito de la Universidad Virtual del Estado de Guanajuato.


Dominio

Actualizar el sistema operativo al más reciente.

-

El ancho de banda deberá incrementarse a por lo menos 1Gb. debido a la cantidad de datos que se requiere transferir.

-

Las computadoras de la organización cuentan con sistema operativo Windows 98.

-

El ancho de banda actual es 128kb.

-

El sistema actual permite a todos los usuarios conectarse de manera remota.

-

El nuevo software no permitirá conexiones remotas.

-

Se cuentan con 3 impresoras en la organización.

-

Todos los reportes impresos desde el sistema deberán enviarse exclusivamente a la impresora instalada en la dirección.

-

El navegador utilizado actualmente es Internet Explorer.

-

Las páginas de la aplicación deberán abrirse con Firefox.

-

Actualmente la factura se realiza de forma manual.

-

Facturar de manera automática con la fecha del servidor.

-

La visualización de los reportes no debe empalmarse con otra información.

-

Abrir en una nueva ventana nueva los reportes.

-

Los reportes contienen texto e imágenes. -

Permitir guardar los reportes en archivos PDF.

-

Funcionar en ambientes de red.

-

Asignar roles y permisos a los usuarios.

-

Las pruebas deben iniciarse el 25 de noviembre para entregar el sistema operando en la fecha pactada.

-

Permitir la impresión en impresora láser y de matriz de puntos.

Sistema (funcionales)

-

-

Sistema (no funcionales)

-

La organización tiene una red y r equieren compartir información. El sistema actual no cuenta con controles de acceso.

-

La fecha de entrega fue planeada para el 15 de agosto.

-

La organización cuenta con una impresora láser y dos de matriz de puntos.

-

El servidor actual cuenta con 10 Gb. de espacio disponible.

-

La base de datos a desarrollar debe ocupar un máximo de 2Gb.

-

Los sistemas no tienen seguridad al acceder a ellos.

-

Las claves de acceso serán definidas por el administrador del sistema y los usuarios no podrán modificarlas.

Tabla 1. Ejemplos de tipos de requerimientos.

Para identificar los requerimientos podemos llevar a cabo un proceso que nos permita asegurar una correcta definición. A continuación se te presenta una propuesta para la determinación de requerimientos. 4 ©UVEG. Derechos reservados. Esta obra no puede ser reproducida, modificada, distribuida, ni transmitida, parcial o totalmente, mediante cualquier medio, método o sistema impreso, electrónico, magnético, incluyendo el fotocopiado, la fotografía, la grabación o un sistema de recuperación de la información, sin la autorización por escrito de la Universidad Virtual del Estado de Guanajuato.


1.- Conocer la organización

2.- Hablar con los clientes y usuarios

3.- Identificar la problemática

4.- Definir requerimientos

"# $%& '( )()*+,".%/0 (' '% 1*'*234 5*'*23 6 789(:*57";%& <=7+('7' :*(3(3".217 '73 07' >0%97' )( *3>7=1,+*23";%*&3(' <,=:*+*<,3 (3 +,), <=7+('7";%& =(+%='7' '( *3570%+=,3 (3 07' <=7+('7'-

";%& '( ('<(=, )(0 <=76(+:7";%& ,+:*5*),)(' =(,0*?, +,), <(='73,"@3 $%& <7)=A, ,6%),=0( (0 '*':(1,".%/3:7 <%()( *35(=:*=-

";%& <=7+('7' 6 :&+3*+,' :*(3(3 ,+:%,01(3:(".%(3:,3 +73 ,0BC3 '*':(1, 6, *3':,0,)7".217 '( <%()( 1(97= 07 (D*':(3:("@3 $%& 1()*), %3 !"#$%&'( <7)=A, ,<76,=";%& ,'<(+:7' )(8( +%8=*= (0 '*':(1, <,=, ',:*'>,+(= 0,' 3(+('*),)(' )( 07' %'%,=*7'4 +0*(3:(' 6 0, 7=B,3*?,+*23";%& ,'<(+:7' 37 <%()( '70%+*73,= (0 '*':(1,"@3 $%& <7=+(3:,9( (0 '*':(1, <%()( '70%+*73,= 0, <=780(1/:*+, *)(3:*>*+,),-

5.- Clasificar y validar los requerimientos

";%& :*<7 )( =($%(=*1*(3:7' :*(3( (0 '*':(1,";%& ,'<(+:7' '( ('<(=,3 ',:*'>,+(=".%8=*=(17' 0,' 3(+('*),)('-

6.- Documentar los requerimientos

.73'*':( (3 =(),+:,= 6 <73(= (3 %3 )7+%1(3:7 07' =($%(=*1*(3:7' *)(3:*>*+,)7' <,=, $%( '(,3 ,+(<:,)7' <7= 07' <,=:*+*<,3:(' (3 (0 <=76(+:7 6 '( >*=1(3E

Figura 4. Proceso para identificación de requerimientos.



Los requerimientos siempre deben ser: •

Verificables: es decir que se puedan revisar.

•

No ambiguos: contar con una redacción clara y comprensible.

•

Factibles: capaces de llevarse a cabo.

•

Correctos: haber sido definidos de una manera apropiada y alineados con la organización.

•

Necesarios: apegados a las necesidades de la organización.

•

Completos: que cuenten con todos los elementos necesarios para servir de base al diseño y desarrollo.

Una vez que tengamos los requerimientos, deberemos informar a nuestro cliente y al equipo de desarrollo para dar paso a la siguiente etapa del ciclo de vida del software .

!"#"$"%&'() Pfleeger, S. L. (2002). Ingeniería de software, teoría y práctica . Buenos Aires, Argentina: Pearson Education. Sommerville, I. (2005). Ingeniería del software (7a. ed.). Madrid, España: Pearson Educación. [Versión en línea]. Recuperado el 16 de marzo de 2012, de http://books.google.com.mx/books?id=gQWd49zSut4C&printsec=frontcover&dq=ingenier%C 3%ADa+de+software&hl=en&sa=X&ei=HXdjT9CZG8ni2QXujO3cCA&ved=0CDEQ6AEwAA# v=onepage&q=ingenier%C3%ADa%20de%20software&f=false


TI0020_M1AA1_Requerimientos

Recommend Documents