Requerimientos Funcionales y No Funcionales en Ingeniería de Software, Apuntes de Computación aplicada

¡Descarga Requerimientos Funcionales y No Funcionales en Ingeniería de Software y más Apuntes en PDF de Computación aplicada solo en Docsity!

Requerimientos Funcionales y

no funcionales

Bautista de la Cruz Itzel Arely T

Ingeniería de Software

Requerimientos Funcionales Los requisitos funcionales son declaraciones de los servicios que prestará el sistema, en la forma en que reacciona a determinados insumos. Cuando hablamos de las entradas, no necesariamente hablamos sólo de las entradas de los usuarios. Pueden ser interacciones con otros sistemas, respuestas automáticas, procesos predefinidos. En algunos casos, los requisitos funcionales de los sistemas también establecen explícitamente lo que el sistema no debe hacer. Es importante recordar esto: un RF puede ser también una declaración negativa. Siempre y cuando el resultado de su comportamiento sea una respuesta funcional al usuario o a otro sistema, es correcto. Y más aún, no sólo es correcto, sino que es necesario definirlo. Y eso nos lleva al siguiente punto. Un requisito funcional define una función del sistema de software o sus componentes. Una función es descrita como un conjunto de entradas, comportamientos y salidas. Los requisitos funcionales pueden ser: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que se supone, un sistema debe cumplir. Los requisitos de comportamiento para cada requisito funcional se muestran en los casos de uso. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación. Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los comportamientos del software. Típicamente, un analista de requisitos genera requisitos funcionales después de realizar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requisitos son previos al diseño de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional. Un requisito funcional típico contiene un nombre, un número de serie único y un resumen. Esta información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para seguir al mismo durante el desarrollo del producto. El núcleo del requisitos yace en la descripción del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interacción con usuarios, inversores y otros expertos en la organización. Historia de usuario: Como usuario, quiero que se muestre un tutorial al iniciar sesión por primera vez, para que pueda ver para qué se utiliza cada opción de la pantalla de inicio.

● El sistema también permitirá el registro de facturas manuales no asociadas a pedidos, sin embargo, estas requerirán autorización por parte del grupo de Gerentes antes de ser contabilizadas. Requisitos no funcionales En un primer nivel, los requerimientos no funcionales pueden clasificarse en requerimientos de producto, organizacionales y externos, tal como te mostramos en el artículo sobre clasificación de los requerimientos no funcionales. En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos de usabilidad, eficiencia, dependabilidad y seguridad. A su vez, los requerimientos organizacionales pueden clasificarse en requerimientos de entorno, organizacionales y de desarrollo. Asimismo, los requerimientos externos pueden clasificarse en requerimientos regulatorios, éticos y legislativos. Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de software, un requisito que sabe bien y especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que estos corresponden a los requisitos funcionales. En palabras más sencillas, no hablan de “lo que” hace el sistema, sino de “cómo” lo hace. Alternativamente, definen restricciones del sistema tales como la capacidad de los dispositivos de entrada/salida y la representación de los datos utilizados en la interfaz del sistema. Los requisitos no funcionales se originan en la necesidad del usuario, debido a restricciones presupuestarias, políticas organizacionales, la necesidad de interoperabilidad con otros sistemas de software o hardware, o factores externos tales como regulaciones de seguridad, políticas de privacidad, entre otros. Existen diferentes tipos de requisitos y se clasifican según sus implicaciones. ● Requisitos del producto. Especifican el comportamiento del producto, como los requisitos de rendimiento sobre la velocidad de ejecución del sistema y la cantidad de memoria necesaria, los requisitos de fiabilidad que establecen la tasa de fallos para que el sistema sea aceptable. ● Requisitos organizativos. Se derivan de las políticas y procedimientos existentes en la organización cliente y en la organización del desarrollador. Al igual que hablamos de requisitos funcionales, la generalización nunca es buena, pero en este caso es aún más importante. Los requisitos funcionales y no funcionales deben diferenciarse en el documento de requisitos, ya sea un SRS, una cartera de productos o cualquier artefacto que utilice. En la práctica, esto puede resultar difícil. Si se declara un requisito no funcional por

separado de los requisitos funcionales, a veces es difícil ver la relación entre ellos. Si los RNF se declaran con requisitos funcionales, es difícil separar las condiciones funcionales de las no funcionales e identificar los requisitos que se refieren al sistema en su conjunto. Se debe encontrar un equilibrio adecuado que dependa del tipo de sistema o aplicación que se especifique. Por ejemplo, si está trabajando con un Product Backlog, podría tener Historias de Usuario separadas para RNFs, pero añadir un enlace a ellas en las RFs que puedan ser impactadas por ellas. Esta es una opción común en la mayoría de los sistemas de seguimiento de billetes utilizados en la actualidad. Ejemplos de requerimientos no funcionales ● Rendimiento ● Disponibilidad ● Durabilidad ● Estabilidad ● Funcionalidad ● Accesibilidad ● Adaptabilidad ● Capacidad ● Integridad de datos ● Documentación ● Operabilidad ● Mantenibilidad ● Conformidad ● Auditabilidad ● Portabilidad ● Seguridad ● Elasticidad ● Legibilidad ● Extensibilidad ● Eficiencia ● Privacidad ● Explotabilidad ● Integrabilidad ● Escalabilidad ● Robustez ● Interoperabilidad ● Garantía ● Reusabilidad ● Compatibilidad