Análisis de requisitos de software con ejemplo
Charles moore
Por ejemplo, en el contexto de la aplicación bancaria, el requisito funcional será que cuando el cliente seleccione "Ver saldo", deberá poder consultar el último saldo de su cuenta.
Los requisitos de software también pueden ser no funcionales, pueden ser un requisito de rendimiento. Por ejemplo, un requisito no funcional es que cada página del sistema sea visible para los usuarios en 5 segundos.
Así que básicamente El requisito de software es un
- funcional o
- No funcional
necesite que debe implementarse en el sistema. Los requisitos de software generalmente se expresan como declaraciones.
Tipos de requisitos
- Requisitos del negocio:Son requisitos de alto nivel que se toman del caso de negocio de los proyectos. Por ejemplo, un sistema de servicio bancario móvil proporciona servicios bancarios al sudeste asiático. El requisito de negocio que se decide para la India es el resumen de cuenta y la transferencia de fondos, mientras que para China se decide como requisito de negocio el resumen de cuenta y el pago de facturas.
| País | Empresa proveedora de Funcionalidades o servicios Bancarios |
|---|---|
| India | Resumen de cuenta y transferencia de fondos |
| China | Resumen de cuenta y Bill Informacion de |
- ArchiRequisitos estructurales y de diseño.:Estos requisitos son más detallados que los requisitos comerciales. Determinan el diseño general necesario para implementar el requisito comercial. Para nuestra organización educativa, los casos de uso de diseño y arquitectura serían inicio de sesión, detalles del curso, etc. El requisito sería el que se muestra a continuación.
| Caso de uso bancario | Requisito |
|---|---|
| Bill Informacion de | Este caso de uso describe cómo un cliente puede iniciar sesión en Net Banking y utilizar el Bill Facilidad de Pago.
El cliente podrá ver un panel de control de facturas pendientes de los facturadores registrados. Puede agregar, modificar y eliminar detalles de un facturador. El cliente puede configurar alertas por SMS y correo electrónico para diferentes acciones de facturación. Puede ver el historial de facturas pagadas anteriormente. Los actores que inician este caso de uso son clientes del banco o personal de soporte. |
- Requisitos del sistema y de integración:En el nivel más bajo, tenemos los requisitos del sistema y de integración. Es una descripción detallada de todos y cada uno de los requisitos. Puede presentarse en forma de historias de usuario que en realidad describen el lenguaje comercial cotidiano. Los requisitos están detallados en abundancia para que los desarrolladores puedan comenzar a codificar. Aquí, en el ejemplo de Bill Módulo de pago donde se mencionará el requisito de agregar un Biller
| Bill Informacion de | Requisitos |
|---|---|
| Agregar BillERS |
|
A veces, para algún proyecto es posible que no recibas ningún requisito o documento con el que trabajar. Pero aún así existen otras fuentes de requisitos que puede considerar para el requisito o la información, de modo que pueda basar su software o diseño de prueba en estos requisitos. Entonces, las otras fuentes de requisitos en las que puede confiar son
Otras fuentes de requisitos
- Transferencia de conocimientos de colegas o empleados que ya trabajan en ese proyecto.
- Hable sobre el proyecto con analistas de negocios, gerentes de productos, líderes de proyectos y desarrolladores.
- Analizar la versión anterior del sistema que ya está implementada en el sistema.
- Analizar el documento de requisitos anterior del proyecto.
- Mire los informes de errores anteriores, algunos de los informes de errores se convierten en solicitudes de mejora que pueden implementarse en la versión actual.
- Consulte la guía de instalación si está disponible para ver cuáles son las instalaciones necesarias.
- Analizar el dominio o el conocimiento de la industria que el equipo está tratando de implementar.
Cualquiera que sea la fuente de requisitos que tenga, asegúrese de documentarlos de alguna forma y haga que otros miembros del equipo con experiencia y conocimientos los revisen.
Cómo analizar los requisitos
Considere un ejemplo de un sistema de software educativo donde un estudiante puede registrarse en diferentes cursos.
Estudiemos cómo analizar los requisitos. Los requisitos deben mantener una calidad estándar de su requisito, diferentes tipos de calidad de requisitos incluyen
- Atomic
- Identificado de forma única
- Rutina de Belleza completa con
- Consistente e inequívoco
- Rastreable
- Priorizado
- Comprobable
Entendamos esto con un ejemplo, hay tres columnas en la tabla que se muestra aquí,
- La primera columna indica: "calidad requerida"
- La segunda columna indica: "requisito incorrecto con algún problema"
- La tercera columna es igual que la segunda columna pero “convertida en un buen requisito”.
| Calidad de requisitos | Ejemplo de mal requisito | Ejemplo de buen requisito |
|---|---|---|
| Atomic |
|
|
| Identificado de forma única | 1- Los estudiantes podrán matricularse a cursos de pregrado1- Los estudiantes podrán matricularse a cursos de posgrado |
|
| Rutina de Belleza completa con | Un usuario profesor iniciará sesión en el sistema proporcionando su nombre de usuario, contraseña y otra información relevante. | Un usuario profesor iniciará sesión en el sistema proporcionando su nombre de usuario, contraseña y código de departamento. |
| Consistente e inequívoco | Un estudiante tendrá cursos de pregrado o de posgrado, pero no ambos. Algunos cursos estarán abiertos tanto a estudiantes de pregrado como de posgrado. | Un estudiante tendrá pregrado o posgrado, pero no ambos. |
| Rastreable | ¿Mantener la información del estudiante asignada al ID de solicitud de BRD? | Mantener la información del estudiante: asignada a BRD req ID 4.1 |
| Priorizado | Estudiante registrado-Prioridad 1Mantener información del usuario-Prioridad 1Inscribir cursos-Prioridad 1Ver boleta de calificaciones-Prioridad 1 | Registrar estudiante-Prioridad 1Mantener información del usuario-Prioridad 2Inscribir cursos-Prioridad 1Ver boleta de calificaciones-Prioridad3 |
| Comprobable | Cada página del sistema se cargará en un plazo de tiempo aceptable. | Las páginas de registro de estudiantes e inscripción de cursos del sistema se cargarán en 5 segundos |
Ahora entendamos cada uno de estos requisitos en detalle comenzando con Atomic
Atomic
Por lo tanto, todos y cada uno de los requisitos que tenga deben ser atómicos, lo que significa que deben tener un nivel de detalle muy bajo y no debe ser posible separarlos en componentes. Aquí veremos los dos ejemplos de requisitos, en AtomNiveles de requisitos ic y claramente identificados.
Así que continuemos con el ejemplo de la creación de un sistema para el ámbito educativo. Aquí, el requisito incorrecto es “Los estudiantes podrán inscribirse en cursos de pregrado y posgrado”. Este es un requisito incorrecto porque no es un requisito atómico, ya que habla de dos entidades diferentes: cursos de pregrado y posgrado. Por lo tanto, obviamente no es un buen requisito, sino un mal requisito, por lo que un buen requisito de correspondencia sería separarlo en dos requisitos. Por lo tanto, uno habla de la inscripción en cursos de pregrado, mientras que el otro habla de la inscripción en cursos de posgrado.
Identificado de forma única
De manera similar, el siguiente requisito de calidad es verificar si hay una identificación única; aquí tenemos dos requisitos separados pero ambos tienen el mismo ID#1. Entonces, si nos referimos a nuestro requisito con referencia al número de identificación, pero no está claro a qué requisito exacto nos referimos al documento u otra parte del sistema, ya que ambos tienen el mismo número de identificación 1. Por lo tanto, al separar con identificaciones únicas, el buen requisito se volverá a devolver como sección 1: inscripciones a cursos, y tiene dos requisitos: 1.1 la identificación es la inscripción a cursos de pregrado, mientras que 1.2 la identificación es la inscripción a cursos de posgrado.
Rutina de Belleza completa con
Además, todos y cada uno de los requisitos deben estar completos. Por ejemplo, aquí el requisito incorrecto dice que "un usuario profesor iniciará sesión en el sistema proporcionando su nombre de usuario, contraseña y otra información relevante". En este caso, la otra información relevante no está clara, por lo que la otra información relevante debe detallarse correctamente para completar el requisito.
Consistente e inequívoco
A continuación, todos y cada uno de los requisitos deben ser coherentes e inequívocos, por lo que aquí, por ejemplo, tenemos los requisitos "Un estudiante tendrá cursos de pregrado o de posgrado, pero no ambos". Este es un requisito. Hay algún otro requisito que dice "Algunos cursos estar abierto tanto a estudiantes de pregrado como de posgrado”.
El problema en este requisito es que desde el primer requisito parece que los cursos se dividen en dos categorías: cursos de pregrado y cursos de posgrado y el estudiante puede optar por cualquiera de dos pero no por ambos. Pero cuando lees otro requisito, entra en conflicto con el primer requisito y dice que algunos cursos estarán abiertos tanto a estudiantes de posgrado como a estudiantes universitarios.
Por lo tanto, es obvio convertir este mal requisito en un buen requisito, que es "Un estudiante tendrá cursos de pregrado o de posgrado, pero no ambos". Lo que significa que cada curso será calificado ya sea como curso de pregrado o curso de posgrado.
Rastreable
Todos y cada uno de los requisitos deben ser rastreables porque ya hay diferentes niveles de requisitos, ya vimos que en la parte superior teníamos requisitos de negocio, y luego teníamos requisitos de arquitectura y diseño seguidos de requisitos de integración del sistema.
Ahora bien, cuando convertimos los requisitos empresariales en requisitos arquitectónicos y de diseño o los convertimos en requisitos de integración de sistemas, tiene que haber trazabilidad. Esto significa que deberíamos poder tomar todos y cada uno de los requisitos empresariales y asignarlos a los requisitos arquitectónicos y de diseño de software correspondientes. Por lo tanto, aquí hay un ejemplo de un requisito incorrecto que dice "Mantener la información del estudiante - ¿asignado al ID de requisito de BRD?" El ID del requisito no se proporciona aquí.
Entonces, al convertirlo en un buen requisito, dice lo mismo pero está asignado con el ID de requisito 4.1. Por lo tanto, el mapeo debe estar disponible para todos y cada uno de los requisitos. De la misma manera que tenemos requisitos de mapeo de alto y bajo nivel, el mapeo también existe entre el sistema y el requisito de integración con el código que implementa ese requisito y también hay un mapeo entre el sistema y el requisito de integración con el caso de prueba que prueba ese requisito en particular. .
Entonces esta trazabilidad se extiende a todo el proyecto.
Priorizado
| Priorizado | Estudiante matriculado-Prioridad 1 Mantener información de usuario: prioridad 1 Inscribir cursos-Prioridad 1 Ver boleta de calificaciones: prioridad 1 |
Registrarse Estudiante-Prioridad 1 Mantener información de usuario: prioridad 2 Inscribir cursos-Prioridad 1 Ver boleta de calificaciones-Prioridad3 |
Luego, se debe priorizar cada uno de los requisitos, de modo que el equipo tenga una guía para determinar qué requisito se puede implementar primero y cuál se puede implementar más adelante. Aquí se puede ver que la prioridad incorrecta es registrar estudiantes, mantener la información del usuario y que a cada uno de los requisitos se le ha asignado la prioridad 1. No se puede dar a todos la misma prioridad, por lo que se puede priorizar a los requisitos. Por lo tanto, el ejemplo de requisito bueno aquí es que registrar estudiantes e inscribir cursos tiene la prioridad más alta 1, mientras que mantener la información del usuario viene a continuación en la prioridad 2 y luego tenemos ver la tarjeta de calificaciones en la prioridad 3.
Comprobable
| Comprobable | Cada página del sistema se cargará en un plazo de tiempo aceptable. | Las páginas de registro de estudiantes e inscripción de cursos del sistema se cargarán en 5 segundos |
Todos y cada uno de los requisitos deben ser comprobables; aquí el requisito malo es "cada página del sistema se cargará en un período de tiempo aceptable". Ahora bien, hay dos problemas con este requisito: el primero es que cada página significa que puede haber muchas páginas, lo que arruinará los esfuerzos de prueba. El otro problema es que dice que la página se cargará en un plazo aceptable. ¿Cuál es el plazo aceptable? Aceptable para quién. Por lo tanto, tenemos que convertir el argumento no comprobable en un argumento comprobable, que indique específicamente de qué página estamos hablando "páginas de registro de estudiantes e inscripción de cursos" y también se proporciona el marco de tiempo aceptable, que es de 5 segundos.
Conclusión
Así es como debemos analizar cada uno de los requisitos en el nivel adecuado. Por ejemplo, si vamos a crear un software en relación con los requisitos de integración y del sistema, debemos analizar los requisitos de integración y del sistema que se indican en las especificaciones de requisitos del software o en las historias de usuario y aplicar la calidad a cada uno de ellos. Luego, comprobar si cada uno de los requisitos es atómico, está identificado de forma única y es completo, etc.
