Requerimientos no funcionales: Una clasificacin

Los requerimientos no funcionales son los que especifican criterios para evaluar la operacin de un servicio de tecnologa de informacin, en contraste con los requerimientos funcionales que especifican los comportamientos especficos de las aplicaciones.

En la primera parte de esta serie, describamos una definicin de requerimientos no funcionales y porque son importantes.

Los requerimientos no funcionales definen las caractersticas o cualidades generales que se esperan de un sistema y establecen restricciones sobre el producto, el proceso de desarrollo de software y establecen restricciones externas que el software debe lograr.

Para poder identificar estas caractersticas durante la ingeniera de requisitos que realizan los Analistas de sistemas e Ingenieros de software en todo proyecto de desarrollo, es til contar con una clasificacin que nos establezca un marco de los tipos de requerimientos funcionales con que nos podemos encontrar.

PMOinformatica presenta una clasificacin de los requerimientos no funcionales a continuacin.

Que son los requerimientos no funcionales?

Si buscas ms informacin sobre el concepto de requerimientos no funcionales, te recomendamos la primera parte de esta serie:

>Requerimientos no funcionales: Porque son importantes

Para ver algunos ejemplos de requerimientos no funcionales consulta el siguiente artculo:

>Requerimientos no funcionales: Ejemplos

Clasificaciones varias de requerimientos no funcionales

Existen diversas fuentes o marcos de referencia para clasificar los requerimientos no funcionales, de hecho, existe un estndar de la IEEE, Std 830 1993 que establece 13 tipos de requerimientos no funcionales que deberan incluirse en toda especificacin de software.

Otro modelo es el propuesto por Jacobson (1999) en el cuales e propone para el Unified Process.

Uno de los modelos ms difundidos es el establecido por Somerville, que presentaremos ms adelante en el artculo.

Formacin en Ingeniera de requisitos

Curso de Ingeniera de requisitos

Se ha hecho muy evidente que una especificacin deficiente de los requisitos del software puede conducir a proyectos fallidos, de all que esta disciplina cada vez adquiera mayor importancia.

El curso de Ingeniera de requisitos esta diseado para ensearte a identificar y analizar requisitos de manera integral, con el cual garantizaras la elaboracin de especificaciones funcionales de calidad.

Conocers tcnicas de levantamiento de requisitos como la revisin de documentacin, observacin y entrevistas, tcnicas para el anlisis como la descomposicin funcional, modelado de procesos, MoSCoW, TimeBoxing, as como actividades de gestin de requisitos para su organizacin, priorizacin y gestin de alcance.

La clasificacin de requerimientos no funcionales de Somerville

La figura presenta la clasificacin de requerimientos no funcionales definida por Somerville.

Somerville divide los requerimientos no funcionales en tres grandes tipos: Requerimientos de producto, requerimientos organizacionales y requerimientos externos.

Requerimientos no funcionales de producto

Suele referirse a limites o restricciones sobre el comportamiento del sistema, por lo cual establece lmites y restricciones sobre lo que los diseadores (arquitectos de software) e ingenieros de software pueden hacer.

Algunos de estos requerimientos pueden ser fciles de cuantificar, por ejemplo el desempeo y la confiabilidad, pero otros son ms difciles como por ejemplo usabilidad y adaptabilidad.

Los requerimientos de producto pueden clasificarse en (Sommerville): Requerimientos de usabilidad:La usabilidad se define como el esfuerzo que necesita hacer un usuario para aprender, usar, ingresar datos e interpretar los resultados obtenidos de un software de aplicacin. En tiempos recientes, la usabilidad ha adquirido mucha importancia, en especial ante la demanda dedesarrollo de software para mviles y tabletas. Requerimientos de eficiencia:Relacionado con desempeo en cuanto a tiempo de respuesta, nmero de operaciones por segundo, entre otras mediciones, as como consumo de recursos de memoria, procesador, espacio en disco o red. Requerimientos de dependibilidad:Engloba varios atributos Disponibilidad:Disposicin del sistema para prestar servicio correctamente. Confiabilidad:Continuidad del servicio prestado por el sistema. Seguridad industrial:Ausencia de consecuencias catastrficas para el usuario o el ambiente. Integridad:Ausencia de alteraciones inadecuadas al sistema. Mantenibilidad:Posibilidad de realizar modificaciones o reparaciones a un proceso sin afectar la continuidad del servicio. Requerimientos de seguridad:Capacidades funcionales o no funcionales que debe tener un sistema para cumplir atributos en el rea de seguridad de tecnologa de informacin, seguridad de datos, seguridad lgica, control de acceso a informacin (restricciones de acceso), autenticidad de la informacin, privacidad, entre otros aspectos.

Considerar los requerimientos de producto es vital para lograr la integracin continua de aplicaciones y el desarrollo de cambios que sean rpidos pero sostenibles en el tiempo.

Este nuevo paradigma es necesario para implementar lasnuevas tecnologa de informacin y aplicaciones de softwarecomo la movilidad, internet de las cosas, analtica avanzada de datos (Big Data), evolucin de los sistemas a la nube y tecnologa de informacin escalable.

Requerimientos no funcionales organizacionales

Se derivan de las polticas y procedimientos de la organizacin como por ejemplo estndares de procesos o requerimientos de implementacin.

Pueden incluir metodologas de desarrollo de software, estndares de programacin (codificacin) y herramientas de soporte al desarrollo de software (por ej. Herramientas CASE) que deben usarse (siguiendo las polticas de la organizacin), tambin reportes a la gerencia que deben proveerse, entre otros.

Lasherramientas para la gestin de desarrollo de softwareque conocemos, se definen como requerimientos no funcionales organizacionales.

Los requerimientos organizacionales pueden clasificarse en (Sommerville): Requerimientos de entorno:Describen el ambiente operativo en el que se debe desenvolver el sistema. Requerimientos operacionales:Procedimientos operativos que describen como ser usado el sistema dentro del contexto de la organizacin. Requerimientos de desarrollo:Lenguaje de programacin a usar, estndares de codificacin,patrones (y antipatrones) de diseo y programacin, herramientas para gestionar el desarrollo de software, entorno de desarrollo de software (ambiente de desarrollo), entorno de pruebas de software (ambiente de pruebas), entre otros aspectos.

Uno de los aspectos que se documentan como requerimientos funcionales organizacionales son los entorno, especficamente losprocedimientos de mantenimiento y administracin del ambiente de desarrollo de software.

Esta administracin tambin incluye losprocedimientos para gestionar los ambientes de pruebas integrales.

Requerimientos no funcionales externos

Estos derivan del entorno organizacional (no entorno tcnico) en el cual se desarrolla el sistema y pueden hacerse tanto sobre el producto (el software desarrollado) o tambin sobre el proceso de desarrollo de software.

Este tipo de requerimientos incluyen limitaciones de ndole econmica, como por ejemplo elpresupuesto del proyecto de software, interaccin o necesidad del sistema de inter-operar con otros sistemas, requerimientos regulatorios en el rea de salud, seguridad industrial o proteccin de datos, requerimientos legales concernientes con licencias, regulaciones o certificaciones que necesita el producto segn la industria en el que se desempee, entre otros.

Somerville a su vez clasifica estos requerimientos en: Requerimientos regulatorios:Leyes y reglamentos que establecen que debe hacer el sistema y como debe hacerlo para cumplirlas. El foco de un sistema o nueva funcionalidad puede ser exclusivamente para cumplir una regulacin. Requerimientos ticos:Requerimientos que aseguran que el sistema ser aceptable para el usuario, pblico en general y se adapta a las costumbres de la sociedad en la que se desenvuelve o a la que presta servicios. Requerimientos legislativos:Caractersticas que debe cumplir el sistema para cumplir con la ley, por ejemplo en el rea de contabilidad (normas contables y estndares financieros), requerimientos de seguridad industrial (para sistemas crticos), entre otros aspectos.

Importancia de clasificar los requerimientos no funcionales

El especificar requerimientos no funcionales de forma incompleta o inexacta puede ocasionar el fracaso de tu proyecto de ingeniera de software.

De hecho no gestionar los requerimientos no funcionales es uno de loserrores clsicos en la gestin de desarrollo de software definida por Steve McConnell.

Lograr clasificar adecuadamente cada requerimiento no funcional identificado es muy importante para garantizar este proceso.

Errores clsicos en la gestin de desarrollo de software

Imagen obtenida de:comerecommended.com

En 1996, Steve McConnel, uninfluyente consultor de la industria del desarrollo del software,pblico su obra Desarrollo Rpido: Domesticando Cronogramas Salvajes de Software (Rapid Development: Taming Wild Software Schedules).

Una de las secciones del libro, describen los errores clsico al tratar de acelerar (o hacer Fastrack) de los proyectos, prcticas de desarrollo de software que son seleccionadas con tanta frecuencia y con los mismos malos resultados predecibles, que merecen ser llamadas clsicos, y que siguen estando muy vigentes a pesar que la obra se pblico hace 17 aos.

Algunas de estas prcticas errneas le son familiares?, por ejemplo, Qu hacemos si un proyecto est retrasado?, incorporamos ms gente?, que hacemos si algn integrante est daando la productividad del equipo?, esperamos hasta el final del proyecto para despedirle?, o que hara si le han asignado un proyecto agresivo en fecha?, reclutar a todos desarrolladores disponibles (inclusive si son novatos) e iniciar lo antes posible sin planificacin?.

A continuacin dejamos la lista, si conoces algn error clsico que no est incluido, te invitamos a dejar un comentario.

Los Desarrolladores, Gerentes y Clientes usualmente tienen buenas razones para tomar las decisiones que toman, pero estos errores clsicos se han cometido con tanta frecuencia que hoy en da sus consecuencias son fciles de predecir, y la experiencia ha demostrado que lejos de mejorar la situacin, tienden a agravarla.

A continuacin los errores clsicos en proyectos de desarrollo de software de Steve McConnel

Gestin de PersonalProcesosProductoTecnologa

1.No dar importancia a la motivacin.2.Aceptar personal con debilidades.3.No controlar a empleados problemticos.4.Privilegiar el Heroismo en lugar de el buen desempeo continuo.5.Incorporar personal a un proyecto retrasado.6.Permitir oficinas ruidosas, con muchas personas.7.Permitir la friccin entre desarrolladores y el cliente (los usuarios).8.Comprometer expectativas no realistas.9.Carecer de patrocinio efectivo.10.Carecer de apoyo de interesados (stakeholders).11.No involucrar a los usuarios finales.12.Privilegiar la politiquera sobre los resultados.13.Exceso de optimismo.14.Permitir cronogramas optimistas.15.No gestionar los riesgos o gestionarlos de forma insuficiente.16.Usar contratitas y no gestionarlos.17.Planificar de forma insuficiente.18.Abandonar la planificacin al estar bajo presin.19.No aprovechar el tiempo mientras el proyecto es aprobado.20.Ir directo a la programacin sin hacer anlisis y diseo.21.Disear de forma inadecuada.22.Omitir revisiones, inspecciones de cdigo y pruebas, al estar bajo presin.23.Insuficiente control por parte de la Gerencia.24.Integracin prematura o muy frecuente del producto.25.Omitir tareas esenciales en las estimaciones.26.Planificar para recuperar el retraso despus.27.Programacin alocada (Code Like Hell).

28.Incluir al principio requerimientos no necesarios realmente (Gold Plating).29.Permitir constantes cambios en los requerimientos, sin aplicar controles. (Feature Creep).30.Incluir requerimientos tcnicos no necesarios (Developer Scrope Creep).31.Modificar el cronograma para corregirlo, pero luego agregar ms esfuerzo y tareas.32.Desarrollo orientado a la investigacin (Hacer investigacin de Software en lugar de desarrollo de software).33.Sndrome de la bala de plata. (Asumir que la misma solucin funciona para todo).34.Sobrestimar los ahorros que se pueden obtener al implementar nuevos mtodos o herramientas.35.Cambiar herramientas en el medio del proyecto.36.Carecer de automatizacin de control de cdigo fuente.

Defina que es Estrategia de requerimientos.

Como sabemos, un rea de conocimiento de gran importancia en el desarrollo de software, es la ingeniera de requerimientos. Esta comprende las actividades de obtencin (captura, descubrimiento y adquisicin), anlisis (y negociacin), especificacin, y validacin de requisitos. Adems, establece una actividad de gestin de requerimientos para manejar los cambios, mantenimiento y rastreabilidad de los requerimientos.

El proceso de obtencin de requisitos, cuya finalidad es llevar a la luz los requisitos, no solo es un proceso tcnico, sino tambin un proceso social que envuelve a diferentes personas, lo que conlleva dificultades aadidas a su realizacin.

Existe un gran nmero de tcnicas para obtener requerimientos.

Entrevistas:es de gran utilidad para obtener informacin cualitativa como opiniones, o descripciones subjetivas de actividades.Desarrollo Conjunto de Aplicaciones ( JAD ):se utiliza para promover la cooperacin y el trabajo en equipo entre usuarios y analistas.Desarrollo de Prototipos:suelen consistir en versiones reducidas, demos o conjuntos de pantallas (que no son totalmente operativos) de la aplicacin pedida.

Observacin:Por medio de esta tcnica el analista obtiene informacin de primera mano sobre la forma en que se efectan las actividades.Estudio de documentacin:Varios tipos de documentacin, como manuales y reportes, pueden proporcionar al analista informacin valiosa con respecto a las organizaciones y a sus operaciones.

Cuestionarios:El uso de cuestionarios permite a los analistas reunir informacin proveniente de un grupo grande de personas.

Tormenta de ideas ( Brainstorming ):Consiste en reuniones con cuatro a diez personas donde como primer paso sugieren toda clase de ideas sin juzgar su validez por muy disparatadas que parezcan, y despus de recopilar todas las ideas se realiza un anlisis detallado de cada propuesta.

ETHICS ( Implementacin Efectiva de Sistemas Informticos desde los puntos de vista Humano y Tcnico ): Constituye un mtodo bastante evolucionado para fomentar la participacin de los usuarios en los proyectos. Puntos de Vista: Cualquier sistema de software no trivial debe satisfacer las necesidades de un grupo diverso de interesados (stakeholders).

Escenarios:Estos se utilizan para documentar el comportamiento del sistema cuando se le presentan eventos especficos.Etnografa: Los sistemas de software no existen de forma aislada; se utilizan en un contexto social y organizacional, y los requerimientos de sistemas de software se derivan y se restringen acorde a ese contexto.

Describa que permite y que evita las siguientes actividades: Hacer - Planear Corregir Revisar.

PlanearConsiste en:

Definir propsito y participantes Definir forma de trabajo Preparar informacin Capacitar a los participantes

Permite:

Conocer el propsito de la Reunin Conocer los temas a tratar Conocer los participantes de la reunin Preparar la documentacin

Evita:

Reuniones sin un claro propsito Ausencias por falta de comunicacin Falta de documentacin

HacerConsiste en:

Preparar el Lugar Comenzar la reunin Conducir la reunin Cerrar la reunin

Permite:

Desarrollar la reunin de la manera planeada

Evita:

No contar con sala para el desarrollo de la reunin Demoras

RevisarConsiste en:

Revisar Asignar tareas Publicar documentacin

Permite:

Ordenar los resultados Organizar el trabajo

Evita:

Falta de acuerdos

CorregirConsiste en:

Planear prximos pasos Medir Valor Agregado Ajustar el proceso

Permite:

Mejorar la forma de trabajo Hacer los ajustes necesarios

Evita:

Repetir Errores

Cite 2 beneficios de aplicar estas actividades en el levantamiento de requerimientos

Este modelo propone planificar, hacer, verificar y actuar. Es comn para proyectos medianos y pequeos.

1. Uno de sus mayores beneficios es evitar el levantamiento de requerimientos y su anlisis sin la planificacin. Para esto, se establecen reuniones con los usuarios, y conversar sobre sus requerimientos.2. Adicionalmente, su mayor fortaleza consiste en organizar el trabajo de una forma que la participacin de todos los involucrados es indispensable.

Bibliografia

Csar Arturo Guerra,17 (Septiembre - Octubre 2007). Obtencin de Requerimientos. Tcnicas y Estrategia. Extrado el 18 de Abril del 2015 desde:http://sg.com.mx/revista/17/obtencion-requerimientos-tecnicas-y-estrategia#.VTLxMubF-3g

Daniel Cabanzo, 16 de octubre de 2014.Estrategias y tcticas en el trabajo con requerimientos 11.Extrado el 18 de Abril del 2015 desde:http://es.slideshare.net/danielcabanzo/estrategias-y-tcticas-en-el-trabajo-con-requerimientos-11

Laura K Botia R, 22 October 2014.Estrategia Y Tcticas En El Trabajo Con Requerimientos.Extrado el 18 de Abril del 2015 desde:https://prezi.com/6f0aou-jfxhx/estrategia-y-tacticas-en-el-trabajo-con-requerimientos/