metodo de especificación de requisitos
Páginas: 6 (1275 palabras)
Publicado: 11 de marzo de 2014
1. RESUMEN
La especificación de requisitos de software es constantemente hecha ambiguamente e incompletamente incluso por personas expertas en el campo, debido a la mala interpretación de los requisitos. Para solucionar esto se crean metodologías basadas en usar lenguaje natural para derivar especificaciones formales e informales.
Aunque existen diferentesmétodos propuestos, como, el método basado en reglas, el método de procesamiento de lenguaje natural, etc. La mayoría de estos métodos tienen una deficiencia en la consideración de los aspectos dinámicos de sistemas de software, la cual es una parte inseparable a la especificación de requisitos de software.
La solución a la falta de soporte a los aspectos dinámicos del software es derivar losrequisitos de los stakeholders mediante el uso del lenguaje natural limitado, para cada una de las entidades que requiere la solución, se crea una serie de requerimientos de tal forma que :
Requerimiento = Entidad + verbo + objetivo : cómo
Lo que quiere decir la fórmula es que un requerimiento está compuesto por un evento general que se desata mientras una entidad está en cierto estado y luegoesta entidad pasa a realizar una acción con un objetivo específico y unos medios específicos. Limitando la especificación de requerimientos a estos componentes provee mayor facilidad al trasladarlos de lenguaje natural a lenguajes formales.
La segunda fase del método propuesto es definir una estructura para especificar los requisitos. La estructura es una estructura de escenarios, lo que quieredecir que los requisitos se basan en usos que tendrá el sistema, Ósea:
Un usuario se conecta a una página web, al conectarse la página no se muestra en la página home.html si no en aboutus.html.
Para estas especificaciones se usa la forma de evento-estado-acción. Así pues, el evento es algo que causa que se ejecute la acción teniendo un estado previo o posterior. El estado previo es unapre-condición para ejecutar la acción y el estado posterior es una post-condición. En el ejemplo anterior se ve claramente esta estructura:
El usuario se conecta a la página web (Evento) , al conectarse a la página se lanza un pedido a la página aboutus en vez de home (precondición) y finalmente se muestra la página (acción).
Generalmente los requisitos que se van generando surgen a partir delescenario anterior.
2. DISCUSIÓN
La metodología propuesta en el documento aunque es simple resulta bastante acertada y con muchas fortalezas, pues desde la experiencia propia y la ajena, el modelamiento de requisitos en un lenguaje formal (ej. UML) puede resultar ambiguo dadas las diferencias entre consumidor y diseñador de software o analista.
Generalmente, por muy bueno y experimentadoque sea el diseñador o analista, al tener que trasladar las especificaciones que le pide el consumidor en lenguaje natural a un lenguaje formal, puede dar resultados ambiguos si tanto consumidor como analista no están al unísono en los requerimientos.
Algo que faltó en el documento fue como hacer la traducción o traslado de lenguaje formal a lenguaje natural. Aunque con las reglas que ofrece lametodología debería ser bastante fácil implementar un framework que a partir de una serie genere un modelo en lenguaje formal.
La especificación de requisitos por medio de escenarios de uso, está bien y es de gran relevancia porque así es como se entiende mucho mejor el problema, lo cual facilita a un framework o a un analista generar los requisitos a partir de una tabla de escenarios porejemplo. Pienso que esta segunda fase de la especificación debería ofrecer una mejor sintaxis y semántica para el modelado de las tablas de escenarios.
Algo más estandarizado.
3. APLICACIÓN / COMPARACIÓN
Caso Sistema de despacho de ambulancia:
El sistema de despacho de ambulancia se encarga de que las ambulancias sean despachadas de tal forma que cumplan todos los mandatos...
1. RESUMEN
La especificación de requisitos de software es constantemente hecha ambiguamente e incompletamente incluso por personas expertas en el campo, debido a la mala interpretación de los requisitos. Para solucionar esto se crean metodologías basadas en usar lenguaje natural para derivar especificaciones formales e informales.
Aunque existen diferentesmétodos propuestos, como, el método basado en reglas, el método de procesamiento de lenguaje natural, etc. La mayoría de estos métodos tienen una deficiencia en la consideración de los aspectos dinámicos de sistemas de software, la cual es una parte inseparable a la especificación de requisitos de software.
La solución a la falta de soporte a los aspectos dinámicos del software es derivar losrequisitos de los stakeholders mediante el uso del lenguaje natural limitado, para cada una de las entidades que requiere la solución, se crea una serie de requerimientos de tal forma que :
Requerimiento = Entidad + verbo + objetivo : cómo
Lo que quiere decir la fórmula es que un requerimiento está compuesto por un evento general que se desata mientras una entidad está en cierto estado y luegoesta entidad pasa a realizar una acción con un objetivo específico y unos medios específicos. Limitando la especificación de requerimientos a estos componentes provee mayor facilidad al trasladarlos de lenguaje natural a lenguajes formales.
La segunda fase del método propuesto es definir una estructura para especificar los requisitos. La estructura es una estructura de escenarios, lo que quieredecir que los requisitos se basan en usos que tendrá el sistema, Ósea:
Un usuario se conecta a una página web, al conectarse la página no se muestra en la página home.html si no en aboutus.html.
Para estas especificaciones se usa la forma de evento-estado-acción. Así pues, el evento es algo que causa que se ejecute la acción teniendo un estado previo o posterior. El estado previo es unapre-condición para ejecutar la acción y el estado posterior es una post-condición. En el ejemplo anterior se ve claramente esta estructura:
El usuario se conecta a la página web (Evento) , al conectarse a la página se lanza un pedido a la página aboutus en vez de home (precondición) y finalmente se muestra la página (acción).
Generalmente los requisitos que se van generando surgen a partir delescenario anterior.
2. DISCUSIÓN
La metodología propuesta en el documento aunque es simple resulta bastante acertada y con muchas fortalezas, pues desde la experiencia propia y la ajena, el modelamiento de requisitos en un lenguaje formal (ej. UML) puede resultar ambiguo dadas las diferencias entre consumidor y diseñador de software o analista.
Generalmente, por muy bueno y experimentadoque sea el diseñador o analista, al tener que trasladar las especificaciones que le pide el consumidor en lenguaje natural a un lenguaje formal, puede dar resultados ambiguos si tanto consumidor como analista no están al unísono en los requerimientos.
Algo que faltó en el documento fue como hacer la traducción o traslado de lenguaje formal a lenguaje natural. Aunque con las reglas que ofrece lametodología debería ser bastante fácil implementar un framework que a partir de una serie genere un modelo en lenguaje formal.
La especificación de requisitos por medio de escenarios de uso, está bien y es de gran relevancia porque así es como se entiende mucho mejor el problema, lo cual facilita a un framework o a un analista generar los requisitos a partir de una tabla de escenarios porejemplo. Pienso que esta segunda fase de la especificación debería ofrecer una mejor sintaxis y semántica para el modelado de las tablas de escenarios.
Algo más estandarizado.
3. APLICACIÓN / COMPARACIÓN
Caso Sistema de despacho de ambulancia:
El sistema de despacho de ambulancia se encarga de que las ambulancias sean despachadas de tal forma que cumplan todos los mandatos...
Leer documento completo
Regístrate para leer el documento completo.