Requisitos Del Software

INGENIERA DE REQUISITOS DEL SOFTWARE
ING. CECILIA HINOJOSA RAZA
Sangolqu Ecuador Agosto - Diciembre, 2013

Documento de uso exclusivo para la asignatura Tcnicas de Desarrollo de Sistemas Ing. Cecilia Hinojosa Raza
Contenido
1. Introduccin .......................................................................................................................... 3 2. La importancia de la Ingeniera de Requisitos ...................................................................... 3 3. Definiciones ........................................................................................................................... 5 3.1 Requisito.......................................................................................................................... 5 3.2 Requisito en el mbito Informtico................................................................................. 5 3.3 Stakeholder ..................................................................................................................... 5 3.4 Ingeniera de Requisitos .................................................................................................. 6 3.5 Objetivos de la Ingeniera de Requisitos ......................................................................... 7 3.6 Proceso de Ingeniera de Requisitos ............................................................................... 8 Caractersticas de la Especificacin de Requerimientos de Software................................. 11 4. Tipos de Requisitos.......................................................................................................... 12 4.1 Requisitos Funcionales.................................................................................................. 13 4.2 Requisitos No Funcionales ............................................................................................ 13 4.3 Requisitos de Clientes y Usuarios ................................................................................. 14 4.4 Requisitos de Desarrolladores ....................................................................................... 14 5. Caractersticas de los ingenieros de requisitos ................................................................... 15 5.1 Capacidad para trabajar de manera colaborativa ........................................................... 15 5.2 Capacidad para trabajar efectivamente con clientes y usuarios en la gestin del cambio de nuevos requerimientos .................................................................................................... 16 5.3 Aptitud para investigar nuevas tecnologas ................................................................... 17 5.4 Propiciar el reuso de artefactos del proyecto y cumplir con la replicabilidad............... 17 Bibliografa ............................................................................................................................. 18
1. Introduccin
Una fase crucial en el proceso de desarrollo de software es la Ingeniera de requisitos (IR) (Zapata, 2009). Es fundamental que los diferentes mundos, de donde provienen los clientes, los usuarios y los tcnicos, esto es, los involucrados en el proceso de requisitos, armonicen y lleguen a acuerdos sobre lo que necesitan y esperan del producto software resultante, por lo tanto, se requiere de un proceso formal que permita asegurar que los requisitos son recopilados con precisin, revisados, documentados y aprobados (Info-Tech Group Research, 2007) . Para obtener requisitos de calidad, es preciso seguir un proceso bien definido, as tambin utilizar en cada fase las tcnicas que aporten a la calidad de los resultados y a la eficiencia del proceso.
2. La importancia de la Ingeniera de Requisitos
La calidad de los requisitos puede determinar la diferencia entre el xito o el fracaso de un proyecto, independientemente del grado de complejidad del mismo. Para Capers Jones los requisitos deficientes son la principal causa del fracaso de proyectos de software. Luego de analizar cientos de organizaciones, lleg a determinar que el proceso de ingeniera de requisitos es deficiente en ms del 75 por ciento de las mismas (Jones, 1996). El informe "Chaos Report 2009" publicado por StandishGroup, cita que tan solo el 32% de los proyectos de desarrollo de software, se pueden considerar exitosos, ya que fueron entregados a tiempo, dentro del presupuesto, con las caractersticas necesarias y la funcionalidad pactada, el 44% se entregaron fuera de plazo, excedieron su presupuesto no cubrieron la totalidad de las caractersticas y funciones y el 24% de los proyectos fueron cancelados. (Group, 2009). En este mismo estudio se puntualiza que el principal factor para el fracaso de un proyecto de desarrollo de software radica en de mala calidad de los requerimientos.
Algunos de los desafos que se presentan al momento de realizar la IR son: la dificultad intrnseca que reviste la identificacin de los requisitos, la comprensin de la complejidad del dominio del problema, la difcil interaccin entre usuarios y desarrolladores, la falta de precisin en las expresiones de los usuarios, la perspectiva con que cada involucrado visualiza el problema, la terminologa propia de cada persona, a esto se suma la calidad de las fuentes de informacin. Con todas estas variables, realizar el anlisis de requisitos resulta una tarea compleja que requiere del apoyo de tcnicas adecuadas que permitan alcanzar el objetivo de una manera eficiente. De las fases del proceso de desarrollo de software la Ingeniera de Requisitos es la ms crtica y difcil de un proyecto (Pandey, Suman, & Ramani, 2010)
(Hofman & Lehner, 2001). Su objetivo es recoger de manera correcta las
necesidades de los interesados. La IR es la base para planificar el proyecto, para disear el software, para la entrega recepcin del producto, en resumen, se constituye en los cimientos para determinar la calidad del producto software. Si se analizan los costes relativos a la correccin de errores en el proceso desarrollo de software, tomando como referencia los datos recopilados por (Boehm, 1981) , se puede apreciar que los costos relacionados con la deteccin y correccin guardan una estrecha relacin con la fase del proceso en la que son detectados, como se aprecia en la figura 1.1. Esto, es si se previene y detectan errores en la fase de IR, los beneficios directos para el proyecto sern la disminucin de costos y tiempo y mejorar la satisfaccin del cliente en general.
Costos relativos de corregir un error
1200 1000 800 600 400 200 0
1 3-6 10 15 - 40 30 - 70 40 - 1000
Requisitos
Diseo
Cdigo
Pruebas de desarrollo
Pruebas de sistema
Fase de explotacin
Figura 1.1 : Costos relativos de corregir un error (Boehm, 1981)
3. Definiciones
3.1 Requisito
Segn la Real Academia Espaola de la Lengua requisito es Circunstancia o condicin necesaria para algo (RAE, 2012). 3.2 Requisito en el mbito Informtico
En el mbito Informtico la definicin del trmino requisito no se ha consensuado, as se pueden encontrar varias definiciones, inclusive en documentos de un mismo organismo, en este caso de la IEEE. Para (IEEE, 2002), requisito es:
(1) Una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. (2) 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. (3) Una representacin en forma de documento de una condicin o capacidad como las expresadas en (1) o en (2).
Para (IEEE, 1998), requisito es:
Una declaracin que identifica las caractersticas o restricciones operativas, funcionales, o de diseo de un producto o proceso, las cuales deben ser: no ambiguas, verificables o cuantificables, y que son necesarias para que el
producto o proceso sea aceptado por los clientes o que concuerde con las directrices internas de garanta de calidad. 3.3 Stakeholder
Este trmino en particular, tiene varias traducciones al espaol, tales como: partes interesadas, o involucrados y se refiere a personas que tengan inters directo o indirecto en el sistema. Los stakeholders son la principal fuente de informacin para la educcin, anlisis de requisitos y posteriormente son actores importantes para la validacin de los mismos. Los stakeholders son las personas que van a interactuar con el sistema, ya sea como usuarios o administradores; tambin pueden ser profesionales especializados que deben involucrarse, segn de la naturaleza del sistema (Young, 2004). Por ejemplo, en un sistema bancario un stakeholder puede ser un hacker, ya que ayudar a detectar las vulnerabilidades del sistema y disear los controles respectivos; tambin pueden ser profesionales especializados en el dominio del problema. Entonces, se puede decir que los stakeholders son las personas que tienen intereses directos o indirectos en el sistema y que pueden influir al momento de: identificar, determinar y validar los requisitos.
3.4 Ingeniera de Requisitos
En la literatura se pueden encontrar diversas definiciones de Ingeniera de Requisitos, a continuacin se citan algunas, las cuales aportan elementos relevantes para la definicin que se formula posteriormente. Para (Hsia, Davis, & Kung, 1993) la Ingeniera de Requisitos se define como: Todas las actividades relacionadas con: Identificacin y documentacin de las necesidades de clientes y usuarios. Creacin de un documento que describe la conducta externa y las restricciones asociadas que satisfar dichas necesidades. Anlisis y validacin del documento de requisitos para asegurar consistencia, complecin y viabilidad. Evolucin de las necesidades.
Para (Pohl, 1994), la ingeniera de requisitos es:

un proceso participativo, iterativo e incremental de construccin de los requisitos, en el que se avanza desde especificaciones iniciales, que no poseen las propiedades deseadas, hasta especificaciones finales que tienen
caractersticas ideales, esto es: completas, acordadas entre los involucrados y documentadas con un nivel adecuado de formalidad. Para (Loucopoulos & Karakostas, 1995), la ingeniera de requisitos es: un proceso sistemtico de desarrollo de requerimientos, a travs de un proceso iterativo, cooperativo de analizar del problema, documentar las observaciones resultantes en una variedad de representaciones y comprobar la exactitud de la comprensin obtenida. Para (Pohl, 2010) la Ingeniera de Requisitos es el proceso de la obtencin de las necesidades individuales y las necesidades de las partes interesadas, creando una documentacin detallada, de los requisitos acordados y especificados, de tal manera que puedan servir de base para todas las otras actividades de desarrollo del sistema. Para (Hull, Jackson, & Dick, 2011) la Ingeniera de Requisitos es: el subconjunto de la Ingeniera de Sistemas que se ocupa del descubrimiento, desarrollo, seguimiento, anlisis, clasificacin, comunicacin y gestin de requisitos que definen el sistema y los niveles sucesivos de abstraccin. La Ingeniera de Requisitos es un proceso cooperativo, iterativo e incremental, en el cual se descubren, analizan, documentan, comunican, validan y gestionan las caractersticas o restricciones operativas y funcionales que se esperan del sistema, las cuales deben ser: documentadas, completas y acordadas entre los involucrados (stakeholders); de tal manera que sean la base para las posteriores fases del desarrollo del sistema. 3.5 Objetivos de la Ingeniera de Requisitos
Para (Pohl, 2011) la Ingeniera de Requisitos es un enfoque sistemtico y disciplinado, mediante el cual se obtienen y gestionan los requisitos para conseguir los siguientes objetivos: a. Conocer los requisitos relevantes, logrando la participacin activa de los stakeholders y asegurarse que ese conocimiento sea explcito. b. Lograr un acuerdo entre los stakeholders sobre los requisitos del sistema. c. Documentar los requisitos, al nivel de detalle adecuado, conforme a los formatos y normas acordados. d. Gestionar los requisitos de manera sistemtica. e. Minimizar el riesgo de desarrollar un sistema que no satisfaga a los stakeholders.
3.6 Proceso de Ingeniera de Requisitos El proceso de requisitos de software, es un proceso iterativo e incremental, mediante el cual se logran identificar, documentar y gestionar los requisitos del producto software que se requiere. En la figura 1, se pueden apreciar los tpicos que propone Software Engineering Body of Knowledge SWEBOK (IEEE Computer Society, 2004) para el rea de conocimiento de Requisitos del Software. De ste se puede inferir que las fases genricas de este proceso son: Elicitacin, Anlisis, Especificacin y Validacin.
Figura 2: Temas del rea de conocimiento Requisitos del Software (IEEE Computer Society, 2004)
3.7 Elicitacin de requisitos Esta es una actividad fundamentalmente humana. Tambin se la conoce como captura de requisitos, descubrimiento de requisitos o adquisicin de requisitos En esta fase se cumplen las siguientes actividades: Comprender el problema que resolver el software Identificar a los involucrados
Es importante que el especialista en requisitos tenga la capacidad de comunicarse eficazmente ya que debe mediar entre los involucrados y armonizar las necesidades que se originan en los diferentes niveles de la organizacin.
3.8 Anlisis de requisitos En la elicitacin, se pudo haber recolectado informacin que no constituyen verdaderos requisitos, en el anlisis se deben realizar las actividades tendientes a asegurar la calidad de los mismos, lo cual constituye una tarea compleja, ya que los requisitos deben responder a las diferentes personas, a los diferentes niveles de la organizacin y al entorno con el que interactuar y en el cual operar.
El objetivo principal del anlisis de requisitos es garantizar la calidad de los mismos. Los objetivos que se persiguen en esta fase estn:
Determinar la informacin til: Resulta muy beneficioso en esta fase clasificar la informacin, separando aquella que verdaderamente constituye una caracterstica deseable del producto software que se desarrollar, de aquella que no lo es.
Gestionar el conocimiento del dominio del problema: mediante un proceso claramente definido llegar a que todos los involucrados, esto clientes, usuarios y personal tcnico tengan el mismo nivel de conocimiento del producto a desarrollar, tanto de la parte funcional como de los aspectos no funcionales.
Detectar conflictos en los requisitos: Debido a que la informacin proviene de distintas fuentes, se pueden presentan contradicciones o ambigedades, las cuales debern resolverse oportunamente aplicando las tcnicas necesarias para este fin.
Establecer las bases para el diseo: los modelos conceptuales utilizados en el anlisis resultan una importante gua para el desarrollo de los modelos del sistema.
Las tcnicas que se utilizan para el anlisis de requisitos son:
Modelo conceptual. Se caracterizan porque favorecen la comprensin de las necesidades del usuario y de los requisitos del software. Describen el
entorno que rodea al software, esto es: datos, tareas, reglas del negocio.
Checklist de anlisis. Se puede utilizar para cualquier tipo de sistema. Consiste en un conjunto de preguntas que son planteadas por el analista y se refieren a los criterios o atributos de calidad de los requisitos. El objetivo que
se persigue es localizar y comunicar los errores en la descripcin de los requisitos.
Matriz de interaccin. Al igual que la tcnica anterior, se puede utilizar para cualquier tipo de sistema y consiste en una matriz de doble entrada, donde se van comparando todos los requisitos entre s, permitiendo de esta manera detectar contradicciones o conflictos entre los requisitos.
3.9 Especificacin de requisitos En esta fase se documentan los requisitos resultantes del anlisis. El resultado es un documento llamado especificacin de requisitos del software, las buenas prcticas recomiendan seguir una norma para el desarrollo de este documento, por ejemplo la norma IEEE 830, la cual indica las caractersticas que debe cumplir cada requisito. Caractersticas de la Especificacin de Requerimientos de Software La norma IEEE 830 (IEEE, 1998) determina las caractersticas deseables de una buena especificacin de requerimientos del software (ERS). Si bien la norma establece los atributos que debe cumplir el documento de ERS, como tal, tambin la mayora de ellos son aplicables a cada requisito, de manera individual.
Correcto: Debe reflejar las necesidades reales de los involucrados.
No Ambiguo: Debe estar expresado de manera que tenga una nica interpretacin.
Completo: se refiere al conjunto de requisitos y debe incluir todos los requisitos significativos del software (relacionados con la funcionalidad, ejecucin, diseo, atributos de calidad o interfaces externas).
Verificable: Debe garantizar que existe algn proceso no costoso por el cual una persona o una mquina puedan chequear que el software satisface cada requerimiento.
Consistente: Una ERS es consistente si y slo si, ningn conjunto de requisitos descritos en ella son contradictorios o entran en conflicto.
Clasificado: Los requisitos deben estar clasificados, ya sea por importancia, estabilidad u otros criterios.
Modificable: Debe garantizar que cualquier cambio puede realizarse de manera fcil, completa y consistente.
Trazable: Debe permitir identificar las referencias hacia atrs, esto es el origen y hacia adelante, cuando un requisito se desglosa o deriva de otro requisito. Estas referencias son especialmente importantes, para el mantenimiento del software y evitar la degradacin del mismo.
Mantenible: Deben estar expresados de tal manera que sean utilizables durante las tareas de mantenimiento y uso, lo cual supone una correcta documentacin.
3.10 Verificacin y validacin de requisitos En esta fase los involucrados revisan los productos obtenidos, verifican que reflejen sus expectativas y necesidades, que se exprese claramente y defina el producto deseado, a fin de que se cuente con una base slida para las siguientes fases del proceso de desarrollo.
4. Tipos de Requisitos De las mltiples propuesta que se han planteado para la clasificacin de los requisitos, se ha tomado aquella que considera tres dominios: por el mbito, por la caracterstica y por la audiencia, como se puede apreciar en la siguiente figura.
mbito
Hardware
Caracterstica
Funcional
Audiencia
Clientes y usuarios
Software
No funcional Desarrolladores
Sistema
De Informacin
Figura No.3 Clasificacin de los requisitos
4.1 Requisitos Funcionales
Son declaraciones detalladas de los servicios que el sistema debera proporcionar. Los requisitos funcionales de un sistema, deben describir claramente cada una de las funciones que el sistema proveer. Constituyen una parte crucial del documento de especificacin de requisitos del software.
4.2 Requisitos No Funcionales
Los requisitos no funcionales se refieren a las caractersticas de un sistema, las cuales no se pueden expresar como funciones, se refieren a aspectos relativos a los atributos de calidad del producto, como por ejemplo: los requisitos de mantenibilidad, portabilidad, facilidad de uso, el nmero mximo de usuarios simultneos, el tiempo y rendimiento Los requisitos no funcionales tambin pueden incluir problemas de fiabilidad, precisin de los resultados, interfaz hombre-mquina temas y limitaciones en la implementacin del sistema.
Los requisitos no funcionales, a menudo crticos, ya que el incumplimiento de alguno de ellos puede ser considerado como un fallo y por le tanto el cliente puede considerarlo como un sistema inaceptable. Los requisitos no funcionales son obligaciones no negociables que deben ser soportadas por el sistema. La norma IEEE 830 detalla cuatro tipos de requisitos no funcionales: Requisitos de interfaz externa requisitos de desempeo Restricciones Atributos de software del sistema.
4.3 Requisitos de Clientes y Usuarios
Los requisitos de clientes y usuarios son los proporcionados por el cliente al inicio de un sistema o esfuerzo de desarrollo de software, por ejemplo, en una solicitud de informacin, propuesta o cotizacin o en una declaracin de trabajo (SOW).
4.4 Requisitos de Desarrolladores
Los requisitos reales deben ser establecidos por los desarrolladores y deben garantizar que reflejan las necesidades y expectativas comprobadas de los usuarios para un determinado sistema. Los requisitos deben ser filtrados por un proceso de clarificacin de su significado mediante un esfuerzo conjunto de clientes, usuarios y el personal tcnico. Por su parte los clientes y los usuarios necesitan el apoyo de profesionales tcnicamente capacitados y con experiencia, para garantizar una comunicacin eficaz. Los desarrolladores necesitan tener esa comprensin de manera que la solucin que definan responda a las necesidades de todos los involucrados. Los malentendidos agregan al proyecto esfuerzo intil y retrabajo.
Si bien unos requisitos son fcilmente identificados en las fases iniciales, otros resultan "incognoscibles" en el comienzo de un esfuerzo de desarrollo, ya que se ven afectados por las nuevas capacidades que se incluir en el nuevo sistema. Esto sugiere la necesidad de planificar los nuevos requisitos y mantener un adecuado control de cambios para proporcionar un grado de flexibilidad. La identificacin de las necesidades reales requiere un proceso interactivo e incremental, con el apoyo de: prcticas eficaces, procesos, mecanismos, mtodos, tcnicas y herramientas. Una estrategia sugerida: Escribir un plan de requisitos Disear o adaptar un proceso de requisitos para su proyecto La inversin en los requisitos relacionados con las actividades del ciclo de vida del sistema, y La utilizacin de las prcticas eficaces requisitos, mecanismos, mtodos, tcnicas, herramientas y capacitacin.
5. Caractersticas de los ingenieros de requisitos

Para (Young, 2004) el ingeniero de requisitos debe tener un conjunto de caractersticas y habilidades, las cuales le permitirn tener un desempeo adecuado. Sugiere tener presente las siguientes: capacidad para trabajar de manera colaborativa, capacidad para trabajar efectivamente con clientes y usuarios en la gestin del cambio de nuevos requerimientos, aptitud para investigar nuevas tecnologas y propiciar el reuso de artefactos del proyecto. A continuacin un detalle de las mismas: 5.1 Capacidad para trabajar de manera colaborativa
nicamente mediante el trabajo colaborativo entre clientes, usuarios, arquitectos de sistemas y diseadores, es posible identificar los requerimientos reales de un sistema. El principal problema que debe afrontar la IR, es la dificultad de identificar los requerimientos reales antes de iniciar las actividades del desarrollo de sistemas. Una
prctica comn del personal informtico es apresurarse e iniciar tempranamente el trabajo de programacin, constituyndose en la causa raz de retrabajo. Al respecto, el ingeniero de requisitos necesita tomar ms conciencia y definir una estrategia para desterrarla. Para enfrentar este problema, se sugiere articular los requisitos iniciales de los clientes y usuarios con los objetivos del negocio y buscar la evolucin de los mismos, de tal manera de conseguir los requisitos reales y priorizar las necesidades del sistema. Las actividades relacionadas con el desarrollo de este trabajo son: Identificar las principales necesidades de los clientes y usuarios: Revisar documentacin escrita del sistema propuesto Entrevistar a clientes y usuarios Revisar la legislacin existente. Estudiar los objetivos del negocio para el sistema propuesto. Colaborar con los clientes y usuarios, propiciando un entorno cooperativo de trabajo y las herramientas tecnolgicas correspondientes. Involucrar a arquitectos de sistemas en el desarrollo de los sistemas, iterando los requerimientos propuestos. Documentar utilizando diagrama de flujos de alto nivel, IDEF0 y diagramas de casos de uso de alto nivel.
5.2 Capacidad para trabajar efectivamente con clientes y usuarios en la gestin del cambio de nuevos requerimientos
Para que el proyecto est bajo control, es imperativo gestionar los cambios. Este es un elemento crtico para el xito del proyecto. Los datos de la industria indican que el 20% de los cambios en los requerimientos, duplicarn el costo del desarrollo del proyecto, por lo tanto, sin un efectivo mecanismo de control de cambios de los requerimientos, el proyecto estar fuera de control en trminos de agenda y de costos, por lo tanto se deben considerar las siguientes acciones: La importancia de control de cambios de los requerimientos deber ser explicada a clientes, usuarios y desarrolladores.
Los desarrolladores deben ser capacitados para no aceptar cambios de requisitos no autorizados. Todos los pedidos de cambios, deben ser canalizados por el control de cambios, sin importar lo triviales que sean. El mecanismo de control de cambios debe contar con un equipo conjunto que incluya tomadores de decisiones empoderados que representen a clientes y desarrolladores. El equipo conjunto deben reunirse con la frecuencia suficiente para tener un nmero considerable de cambios a considerar. Asegurarse que el contrato provee tiempo adicional y presupuesto para todos los cambios. Este es un mecanismo para mantener buenas relaciones a lo largo del contrato. Los cambios cuestan tiempo y dinero. Esto debe ser reconocido y reflejado en el contrato.
5.3 Aptitud para investigar nuevas tecnologas
El equipo que realice el anlisis de requisitos podra desempearse de mejor manera si est al tanto de la evolucin de las herramientas tecnolgicas actuales y cmo sus bondades pueden aprovecharse en la mejora del trabajo. Tambin puede resultar
beneficioso incorporar diseadores de sistemas que revisen requisitos, costos, agenda e impactos de riesgo, as tambin considerar el uso de estudios tcnicos para desarrollar alternativas. As tambin, es importante mantener al cliente involucrado en estas actividades, de tal manera que cuando sea necesario, el cliente estar dispuesto a trabajar con el equipo, para realizar recomendaciones y tomar decisiones en conjunto.
5.4 Propiciar el reuso de artefactos del proyecto y cumplir con la replicabilidad Se puede considerar a los requerimientos como artefactos reutilizables. Muchos
requerimientos no son nicos, ya que fueron identificados en otro ambiente y dominio de problema y se puede considerar beneficioso partir con un trabajo de ejemplo, el cual aporte ideas y referencias.
2. Bibliografa
Al-Ghassani, A., Carrillo, P., & Anumba, C. R. (2001). Software requirements for knowledge management in construction organizations. 17th Annual ARCOM Conference (pgs. 199-206). Salford: Association of Researchers in Construction. Biggs, J. (2007). Teaching for quality learning at university. London: Open University Press. Boehm, B. (1981). Software Engineering Economics. Prentice Hall. Carrizo, D. (2004). Seleccin de las tcnicas de educcin de requisitos: una visin conjunta de la Ingeniera de Software y la Ingeniera del Conocimiento. Proceedings JIISIC '04. Madrid. Chikh, A. (2011). A knowledge Management Framework in Software REquirements Engineering Based on the SECI Model. 4(12). Group, T. S. (23 de 04 de 2009). Standish Group report. (The Standish Group) Recuperado el 30 de 08 de 2011, de http://www1.standishgroup.com/newsroom/chaos_2009.php Hofman, H., & Lehner, F. (2001). Requirements Engineering as a Success Factor in Software Projects. IEEE Software, 58.66. Hsia, P., Davis, A., & Kung, D. (1993). Status report: requirements engineering. IEEE Software, 75-79. Hull, E., Jackson, K., & Dick, J. (2011). Requirements Engineering. London: Springer. IIEEE. (1998). IEEE Recommended Practice for Software Requirements Specifications. New York: IEEE. IEEE. (2002). IEEE Standard Glossary of Software Engineering Terminology. New York: The Institute of Electrical and Electronics Engineers, Inc. IEEE Computer Society. (2004). Guide to the Software Engineering Body of Knowledge. California: IEEE. Loucopoulos, P., & Karakostas, V. (1995). System Requrements Engineering. McGraw-Hill. Pandey, D., Suman, U., & Ramani, A. (2010). An Effective Requirement Engineering Process Model for Software Development and Requirements Management. 1(978-1-42448093-7). Pohl, K. (2010). Requirements Engineering. London: Springer. Pohl, K. (2011). Title Requirements Engineering Fundamentals. London: Rocly Nook.
Young, R. (2004). The Requirements Analyst's Handbook. Norwood (Massachusetts): Artech House Publishers. Zapata, C. (2009). Una propuesta de metaontologa para la educcin de requisitos. 18(1).

Requisitos Del Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Requisitos Del Software

Cargado por

Copyright:

Formatos disponibles

INGENIERA DE REQUISITOS DEL SOFTWARE

ING. CECILIA HINOJOSA RAZA

Sangolqu Ecuador Agosto - Diciembre, 2013

2. La importancia de la Ingeniera de Requisitos

Figura 1.1 : Costos relativos de corregir un error (Boehm, 1981)

Para (IEEE, 1998), requisito es:

3.4 Ingeniera de Requisitos

Para (Pohl, 1994), la ingeniera de requisitos es:

Las tcnicas que se utilizan para el anlisis de requisitos son:

se persigue es localizar y comunicar los errores en la descripcin de los requisitos.

Correcto: Debe reflejar las necesidades reales de los involucrados.

Figura No.3 Clasificacin de los requisitos

4.1 Requisitos Funcionales

4.2 Requisitos No Funcionales

4.3 Requisitos de Clientes y Usuarios

4.4 Requisitos de Desarrolladores

5. Caractersticas de los ingenieros de requisitos

5.3 Aptitud para investigar nuevas tecnologas

También podría gustarte