Requisitos de software

Los requisitos de software son la descripción de las características y funcionalidades del sistema objetivo. Los requisitos transmiten las expectativas de los usuarios del producto de software. Los requisitos pueden ser obvios u ocultos, conocidos o desconocidos, esperados o inesperados desde el punto de vista del cliente.

Ingeniería de requisitos

El proceso para recopilar los requisitos de software del cliente, analizarlos y documentarlos se conoce como ingeniería de requisitos.

El objetivo de la ingeniería de requisitos es desarrollar y mantener un documento sofisticado y descriptivo de ‘Especificación de requisitos del sistema’.

Proceso de ingeniería de requisitos

Es un proceso de cuatro pasos, que incluye –

• Estudio de viabilidad
• Recogida de requisitos
• Especificación de requisitos de software
• Validación de requisitos de software

Veamos el proceso brevemente –

Estudio de viabilidad

Cuando el cliente se acerca a la organización para conseguir el producto deseado desarrollado, se trata de una idea aproximada sobre las funciones que el software debe realizar y las características que se esperan del software.

En base a esta información, los analistas realizan un estudio detallado sobre si el sistema deseado y su funcionalidad son factibles de desarrollar.

Este estudio de viabilidad está enfocado hacia el objetivo de la organización. Este estudio analiza si el producto de software puede materializarse en la práctica en términos de implementación, contribución del proyecto a la organización, limitaciones de costes y según los valores y objetivos de la organización. Explora los aspectos técnicos del proyecto y del producto como la usabilidad, la mantenibilidad, la productividad y la capacidad de integración.

El resultado de esta fase debe ser un informe de estudio de viabilidad que debe contener comentarios y recomendaciones adecuadas para la dirección sobre si el proyecto debe llevarse a cabo o no.

Recogida de requisitos

Si el informe de viabilidad es positivo para emprender el proyecto, la siguiente fase comienza con la recogida de requisitos del usuario. Los analistas e ingenieros se comunican con el cliente y los usuarios finales para conocer sus ideas sobre lo que debe proporcionar el software y qué características quieren que incluya.

Especificación de los requisitos del software

La especificación de los requisitos del software es un documento creado por el analista del sistema después de recoger los requisitos de las distintas partes interesadas.

La especificación de requisitos de software define cómo el software previsto interactuará con el hardware, las interfaces externas, la velocidad de funcionamiento, el tiempo de respuesta del sistema, la portabilidad del software a través de varias plataformas, la capacidad de mantenimiento, la velocidad de recuperación después de un fallo, la seguridad, la calidad, las limitaciones, etc.

Los requisitos recibidos del cliente están escritos en lenguaje natural. Es responsabilidad del analista de sistemas documentar los requisitos en lenguaje técnico para que puedan ser comprendidos y útiles por el equipo de desarrollo de software.

El SRS debe presentar las siguientes características:

• Los requisitos del usuario se expresan en lenguaje natural.
• Los requisitos técnicos se expresan en lenguaje estructurado, que se utiliza dentro de la organización.
• La descripción del diseño debe escribirse en Pseudocódigo.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:



• Recogida de requisitos – Los desarrolladores discuten con el cliente y los usuarios finales y conocen sus expectativas del software.
• Organización de los requisitos – Los desarrolladores priorizan y organizan los requisitos por orden de importancia, urgencia y conveniencia.
• Discusión de la negociación & – Si los requisitos son ambiguos o hay algunos conflictos en los requisitos de varias partes interesadas, si lo son, entonces se negocia y se discute con las partes interesadas. Los requisitos pueden entonces ser priorizados y razonablemente comprometidos.

  Los requisitos provienen de varias partes interesadas. Para eliminar la ambigüedad y los conflictos, se discuten para que sean claros y correctos. Los requisitos no realistas se comprometen razonablemente.

• Documentación – Todos los requisitos formales & informales, funcionales y no funcionales se documentan y se ponen a disposición para su procesamiento en la siguiente fase.

Técnicas de elicitación de requisitos

La elicitación de requisitos es el proceso para averiguar los requisitos de un sistema de software previsto mediante la comunicación con el cliente, los usuarios finales, los usuarios del sistema y otros que tienen un interés en el desarrollo del sistema de software.

Hay varias maneras de descubrir los requisitos

Entrevistas

Las entrevistas son un medio fuerte para recoger los requisitos. La organización puede realizar varios tipos de entrevistas como:

• Entrevistas estructuradas (cerradas), donde cada información a recopilar se decide de antemano, siguen el patrón y el tema de discusión firmemente.
• Entrevistas no estructuradas (abiertas), donde la información a recopilar no se decide de antemano, más flexibles y menos sesgadas.
• Entrevistas orales
• Entrevistas escritas
• Entrevistas individuales que se realizan entre dos personas a través de la mesa.
• Entrevistas grupales que se realizan entre grupos de participantes. Ayudan a descubrir cualquier requisito que falte ya que participan numerosas personas.

Encuestas

La organización puede llevar a cabo encuestas entre varias partes interesadas preguntando sobre sus expectativas y requisitos del próximo sistema.

Cuestionarios

Se entrega un documento con un conjunto predefinido de preguntas objetivas y sus respectivas opciones a todas las partes interesadas para que las respondan, las cuales se recogen y recopilan.

Una de las deficiencias de esta técnica es que, si no se menciona una opción para alguna cuestión en el cuestionario, ésta puede quedar desatendida.

Análisis de tareas

El equipo de ingenieros y desarrolladores puede analizar la operación para la que se necesita el nuevo sistema. Si el cliente ya dispone de algún software para realizar determinada operación, se estudia y se recogen los requisitos del sistema propuesto.

Análisis de dominio

Todo software entra en alguna categoría de dominio. Las personas expertas en el dominio pueden ser de gran ayuda para analizar los requisitos generales y específicos.

Brainstorming

Se lleva a cabo un debate informal entre varias partes interesadas y se registran todas sus aportaciones para el posterior análisis de los requisitos.

Prototipado

El prototipado es la construcción de la interfaz de usuario sin añadir funcionalidad detallada para que el usuario interprete las características del producto de software previsto. Ayuda a dar una mejor idea de los requisitos. Si no hay ningún software instalado en el extremo del cliente para la referencia del desarrollador y el cliente no es consciente de sus propios requisitos, el desarrollador crea un prototipo basado en los requisitos inicialmente mencionados. El prototipo se muestra al cliente y se anota su opinión. El feedback del cliente sirve como entrada para la recopilación de requisitos.

Observación

El equipo de expertos visita la organización o el lugar de trabajo del cliente. Observan el funcionamiento real de los sistemas instalados existentes. Observan el flujo de trabajo en el cliente y cómo se resuelven los problemas de ejecución. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

En términos generales, los requisitos de software deben clasificarse en dos categorías:

Requisitos funcionales

Los requisitos, que están relacionados con el aspecto funcional del software caen en esta categoría.

Definen las funciones y la funcionalidad dentro y desde el sistema de software.

Ejemplos –

• Opción de búsqueda dada al usuario para buscar entre varias facturas.
• El usuario debe ser capaz de enviar por correo cualquier informe a la dirección.
• Los usuarios pueden dividirse en grupos y se puede dar a los grupos derechos separados.
• Debe cumplir con las reglas de negocio y las funciones administrativas.
• El software se desarrolla manteniendo intacta la compatibilidad hacia abajo.

Requisitos no funcionales

Los requisitos, que no están relacionados con el aspecto funcional del software, entran en esta categoría. Son características implícitas o esperadas del software, que los usuarios asumen.

Los requisitos no funcionales incluyen.

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Proporcionar información de ayuda
• Enfoque centrado en el usuario
• Configuración de la vista basada en el grupo.

Analista de sistemas de software

El analista de sistemas en una organización de TI es una persona, que analiza los requisitos del sistema propuesto y se asegura de que los requisitos se conciben y documentan correctamente &. El papel de un analista comienza durante la fase de análisis de software del SDLC. Es responsabilidad del analista asegurarse de que el software desarrollado cumple con los requisitos del cliente.

Los analistas de sistemas tienen las siguientes responsabilidades:

• Analizar y comprender los requisitos del software previsto
• Entender cómo el proyecto contribuirá en los objetivos de la organización
• Identificar las fuentes de los requisitos
• Validar los requisitos
• Desarrollar e implementar el plan de gestión de requisitos
• Documentar los requisitos de negocio, técnicos, proceso y requisitos del producto
• Coordinación con los clientes para priorizar los requisitos y eliminar y ambigüedad
• Finalización de los criterios de aceptación con el cliente y otras partes interesadas

Métricas y medidas de software

Las medidas de software pueden entenderse como un proceso de cuantificación y simbolización de varios atributos y aspectos del software.

Las métricas de software proporcionan medidas para varios aspectos del proceso de software y del producto de software.

Las medidas de software son un requisito fundamental de la ingeniería de software. No sólo ayudan a controlar el proceso de desarrollo de software, sino que también ayudan a mantener la calidad del producto final excelente.

Según Tom DeMarco, un (Ingeniero de Software), «No puedes controlar lo que no puedes medir». Por su dicho, está muy claro lo importante que son las medidas de software.

Veamos algunas métricas de software:

• Métricas de tamaño – LOC (Líneas de Código), mayormente calculadas en miles de líneas de código fuente entregadas, denotadas como KLOC.

  El recuento de puntos de función es la medida de la funcionalidad proporcionada por el software. El recuento de puntos de función define el tamaño del aspecto funcional del software.

• Métricas de complejidad – La complejidad ciclomática de McCabe cuantifica el límite superior del número de caminos independientes en un programa, que se percibe como complejidad del programa o de sus módulos. Se representa en términos de conceptos de teoría de grafos mediante el uso de grafos de flujo de control.
• Métricas de calidad – Los defectos, sus tipos y causas, la consecuencia, la intensidad de la gravedad y sus implicaciones definen la calidad del producto.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.
Advertisements