RESUMEN ESCRITURA DE REQUERIMIENTOS SOFTWARE

Transcripción

1 Brandon Campos Calderón Dr. Jaime Solano Soto Ingeniería en Computación RESUMEN ESCRITURA DE REQUERIMIENTOS SOFTWARE INSTITUTO TECNOLÓGICO DE COSTA RICA

2 Tabla de Contenidos Resumen Escritura de Requerimientos de Software... 2 Qué hace que una especificación de requerimientos de software (ERS) sea correcta?... 2 Beneficios de escribir un correcta ERS... 2 Cuáles son los asuntos que los escritores de ERS deberían abordar?... 3 Características de una ERS... 3 Referencias Bibliográficas

3 Resumen Escritura de Requerimientos de Software Qué hace que una especificación de requerimientos de software (ERS) sea correcta? Actualmente, existen muchas maneras de poder obtener información acerca de cómo es una especificación de requerimientos de software, cómo se escribe y las deficiencias o errores que debemos de evitar, sin embargo, el problema no es la falta de conocimiento para elaborar dichas especificaciones, sino la manera en que se siguen las definiciones propuestas. El artículo menciona algo que a mi parecer merece ser recalcado; Cuántos programadores piensan que documentar es aburrido?, la respuesta pienso que sería mayoritaria, ya que a muchos no les gusta documentar lo que hacen, ni tener un respaldo de cómo se va a desarrollar el proyecto. Claro está que se puede llegar a la meta de desarrollar un gran producto de software sin tener una especificación de software correcta, pero, para qué tomar riesgos de fallos futuros?, además de que una excelente especificación de requerimientos nos ayuda a comprender mejor el diseño del proyecto, tener una visión más clara del sistema y asegurarnos de no tomar riesgos innecesarios que perjudiquen el desarrollo y funcionamiento del software. Para poder escribir una gran especificación de requerimientos, se debería contar con un gran sistema de especificación, es por ello que se recomienda usar el estándar IEEE, ya que es una fuente con excelentes definiciones de sistema y especificación de software. Beneficios de escribir un correcta ERS Establece los acuerdos entre el cliente y el proveedor, en cuanto a las funciones que tiene que realizar el software. Reduce el esfuerzo de desarrollo, ya que aunque muchos lo vean como perder el tiempo no es así, es todo lo contrario. Invertir ese tiempo para que después no hayan problemas como una visión errónea de lo que se quiere realizar o desacuerdos entre stakeholders. Provee una base para estudiar costos y horarios. Calendarizar es una parte muy importante a la hora de especificar requerimientos, ya que permite definir tiempos y costos antes de entrar a la parte de desarrollo del producto. Permite tener una base de verificación y validación. Sirve como referencia para futuras mejoras. Facilita transferencias del software, ya sea entre usuarios o nuevas máquinas. 2

4 Cuáles son los asuntos que los escritores de ERS deberían abordar? Funcionalidad: Se refiere a que es lo que va a realizar el software. Interfaces externas: Indica la manera en que interactúa el sistema con las personas, el hardware u otro software. Rendimiento: Temas como velocidad, disponibilidad, tiempo de respuesta, y recuperación forman parte de esta categoría. Atributos: Toma en cuenta aspecto como seguridad, mantenimiento y portabilidad. Limitaciones de diseño impuestas en una implementación: Indica si es necesario ciertas implementaciones específicas, como por ejemplo lenguajes, límites de recursos o políticas de la integridad de una base de datos. Características de una ERS La IEEE nos propone ciertas características que toda ERS debería cumplir, entre ellas destacan: Correcto: No solo se trata de tener una ERS correcta, sino también de corregir ciertos detalles que no estén con lo establecido, es decir, actualizar ciertos detalles. Sin ambigüedad: Si un requerimiento tiene una sola interpretación, entonces este no puede ser ambiguo, de lo contrario hay que buscar una manera de arreglarlo. Completo: Tiene que contener todo lo necesario para que un diseñador de software pueda empezar a desarrollar y crear un producto. Consistente: La consistencia es vital, y no solo consigo misma, sino también con referencias a otros documentos. Clasificado por importancia o estabilidad: Es importante ver este punto como una lista de deseos, en la cual pongo de primero los que quiero que se cumplan con mayor prioridad y así sucesivamente, hasta tener los de menor prioridad de últimos. Verificable: Se recomienda poner requerimientos cuantitativos, con el fin de saber a lo que quiero llegar y tener un panorama más tangible de lo que se quiere hacer. Modificable: Puede que algunas veces sea necesario tener el mismo requerimiento en más de un lugar a la vez, pero esto puede causar problemas a la hora de dar mantenimiento. Rastreable: Muchas organizaciones ven muy útil el hecho de interconectar los requerimientos de una ERS a un documento de alto nivel, con el objetivo de tener un rastro de donde se encuentran los requerimientos y buscarlos con mayor facilidad. 3

5 Referencias Bibliográficas Japenga, R. (s. f.). How to write a software requirements specification MicroTools IncRecuperado de 4