# etiqueta del producto
una especificación de requisitos de software (documento SRS) describe cómo debe desarrollarse un sistema de software. En pocas palabras, un SRS proporciona a todos los involucrados una hoja de ruta para ese proyecto.
ofrece definiciones de alto grado para las especificaciones funcionales y no funcionales del software, y también puede incluir casos de uso que ilustran cómo un usuario interactuaría con el sistema al completarlo.,
Nota: permítanos ayudarlo a escribir una especificación de requisitos de Software. Solicite una llamada con nuestro CTO rellenando este formulario.
Tabla de Contenidos
¿por Qué es un SRS Documento Importante?
supongamos que desea crear una aplicación de chat con una apariencia y funcionalidad específicas y desea que esté orientada específicamente a las empresas. Siente que puede eliminar las funciones adicionales que las aplicaciones de chat comerciales usan para atraer al público y centrarse en las funciones que las empresas necesitan. Pero no eres un desarrollador.,
por lo que es necesario externalizar el desarrollo de la aplicación. Pero también necesitas asegurarte de que quien sea que contrates para convertir tu idea en realidad sepa exactamente lo que estás tratando de lograr. Sin todos los detalles para terminar la aplicación, el tiempo y el costo pueden salirse rápidamente de las manos. Los desarrolladores pueden tomar un giro equivocado y tener que refactorizar el código si el producto terminado no coincide con la imagen que tenía en su cabeza.
un documento SRS te obliga a poner la idea en papel para cubrir todos estos detalles. Debes traducir esta idea a un lenguaje que los desarrolladores entiendan., Un documento SRS describe lo que un cliente quiere y lo que los desarrolladores proporcionarán. Es el acuerdo escrito sobre cada detalle de la aplicación.
tener un conjunto claro de requisitos garantiza que un equipo de desarrollo cree software que satisfaga las necesidades de los clientes. Un SRS ayudará a estimar el costo del trabajo y a cubrir el alcance del proyecto. También les da a los programadores una idea de la pila tecnológica que necesitarán y les ayuda a planificar su trabajo, pero eso no es todo:
- Los diseñadores obtienen información del proyecto a través de documentos SRS para que puedan hacer coincidir el diseño con el caso de uso.,
- Los evaluadores obtienen las pautas para crear casos de prueba que coincidan con las necesidades del negocio.
- Los usuarios finales utilizan el SRS para entender el software.
- proporciona a los inversores una visión general de las características del sistema para que puedan tomar decisiones de inversión.
Un SRS es importante porque es una única fuente de información y expectativas, lo que evita malentendidos entre los gerentes de proyecto, desarrolladores, diseñadores y probadores.
¿Qué Hace un SRS Incluir?,
Un SRS debe tener suficiente información para que los desarrolladores completen el software descrito. No solo establece la descripción del software en desarrollo, sino también el propósito que servirá: lo que se supone que debe hacer el software y cómo debe funcionar.,del software o lo que se supone que debe hacer
la diferencia entre los requisitos funcionales y no funcionales
los requisitos funcionales son los objetivos del nuevo sistema que está diseñando., Describen el sistema y cómo funcionará para ayudar con las tareas de un usuario. Definen cómo responderá el sistema a la entrada del usuario y tienen detalles sobre los cálculos, la entrada de datos y los procesos de negocio. Puede considerar los requisitos funcionales una descripción detallada de las características de la aplicación y las necesidades del usuario. Si no se cumplen los requisitos funcionales, el sistema no funcionará.
mientras que los requisitos funcionales especifican lo que hace un sistema, los requisitos no funcionales describen cómo lo hará el sistema. Los requisitos no funcionales no afectan la funcionalidad de la aplicación., Incluso sin cumplir con los requisitos no funcionales, el sistema realizará las tareas deseadas.
los requisitos no funcionales también son importantes porque definen las características generales que afectan la experiencia del usuario. En lugar de centrarse en los requisitos del Usuario, se centran en las expectativas del usuario y cubren temas como el rendimiento, la seguridad, la fiabilidad, la disponibilidad y la usabilidad.,
Cómo escribir un documento de especificación de requisitos de Software
lo mejor es organizar el proceso que utiliza para escribir un documento SRS comenzando con un esqueleto e información general sobre el software que está desarrollando, y terminando agregando detalles para desarrollar su borrador. Aquí hay seis pasos involucrados en la creación de un documento SRS:
obtener documento de especificación de requisitos de Software
ayudamos a más de 200 empresas a construir sus productos de software. Contrate a nuestro analista de negocios con 6 años de experiencia para escribir un SRS para usted.,
Solicitar SRS
Crear un Esquema
El primer paso en el proceso es crear un esquema para su SRS. Puede crear esto usted mismo o usar una plantilla SRS existente como punto de partida. Aquí hay un ejemplo básico de un esquema de SRS:
Descargar el ebook
- Introducción
- Propósito
- la Intención de Audiencia
- la Intención de Uso
- Alcance
- Definiciones
- Descripción General
- las Necesidades del Usuario
- Suposiciones y Dependencias
- Las Características del sistema y los Requisitos de
- Requisitos Funcionales
- Interfaz Externa Requisitos
- Características del Sistema
- Requisitos No funcionales
Definir el Propósito
una Vez que tenga un esquema, que debe carne a cabo., Comience definiendo el propósito del producto en la introducción de su SRS. Aquí describirá la audiencia prevista y cómo utilizarán el producto. Así es como debe estructurar el propósito:
- Definir el alcance del producto
- describir el valor que entregará
- mostrar quién usará el software
- detalle cómo ayudará con el trabajo de los usuarios previstos
dar una visión general
después de definir el propósito del producto, resumir cómo funcionará., Aquí se dará una descripción general de las características del software y cómo se ajustan a las necesidades del usuario.
también describirá las suposiciones que está haciendo sobre la funcionalidad del producto y cualquier cosa de la que dependa en el ecosistema tecnológico actual.
describa los requisitos funcionales y no funcionales
ahora que ha escrito la información general, es hora de ser más específico. Completar su visión general antes de trabajar en los requisitos funcionales y no funcionales le da una referencia para asegurarse de que cumple con las necesidades básicas del usuario mientras rellena los detalles.,
esta descripción detallada de los requisitos del sistema es el componente más esencial de un documento SRS. Describa los requisitos funcionales con suficiente detalle para que los desarrolladores puedan ponerse a trabajar y los requisitos no funcionales, como las especificaciones de seguridad y el rendimiento.
Aquí es donde agrega casos de uso para describir vívidamente cómo un usuario interactuará con su sistema. Es donde se detallan los objetivos de su proyecto y medirá cómo progresa el proyecto durante el desarrollo.,
agregar detalles suplementarios
El último paso para crear el borrador de su Documento SRS es agregar cualquier detalle que pueda ayudar a los desarrolladores a terminar el trabajo en forma de apéndices, glosarios de términos y referencias.
obtener aprobación
Una vez que haya agregado suficientes detalles al SRS para describir lo que se supone que debe hacer el sistema, es hora de que las partes interesadas aprueben el documento.
lo más probable es que tenga que hacer una presentación a las personas involucradas en el proceso de desarrollo., Es posible que soliciten cambios, y usted tendrá que actualizar el documento SRS basado en los comentarios de las partes interesadas antes de la aprobación final.
esto es una buena señal. Significa que tanto los desarrolladores como las partes interesadas están haciendo que el documento sea más preciso, por lo que el proyecto no se sale del camino.
Cómo escribir casos de uso de Software en un SRS
un caso de uso describe cómo un usuario interactuará con el sistema. Describirá el producto desde el punto de vista del usuario final en un formato de historia simple. Escribir casos de uso lo obliga a pensar en lo que los usuarios harán con el software y cómo responderá., Es la visualización de la vida real de los requisitos funcionales.
Estos son los pasos que puedes seguir para escribir un caso de uso:
- Describe a los usuarios finales de tu producto.
- Centrarse en uno de estos usuarios.
- divide las interacciones de este usuario en casos de uso. Cada interacción es un caso de uso.
- Describir la secuencia de eventos para cada caso de uso.
- escriba una descripción detallada de las acciones del usuario y cómo debe responder el sistema.
- expanda cada caso de uso con acciones de usuario alternativas y respuestas del sistema.
- repita 1-6 para cada tipo de usuario final.,
¿cuáles son las características de un gran SRS?
hay características específicas que cada SRS debe tener. Al revisar esta lista y compararla con su SRS, puede asegurarse de que será un documento útil para todas las partes interesadas.
explícito
un documento SRS debe ser fácil de entender. Nada debe ser vago, para que no haya malentendidos entre las partes interesadas.,
medible
los requisitos en su Documento SRS deben ser medibles, por lo que el producto terminado se puede validar y verificar contra las especificaciones.
Complete
un documento SRS debe tener suficiente información para que su equipo de Desarrollo termine el producto y para que los probadores validen que el producto satisface las necesidades del usuario sin errores.
Viable
los requisitos deben ajustarse a la realidad del entorno actual, incluidos el presupuesto, el calendario y la tecnología. No deberían depender de los próximos avances tecnológicos.,
Flexible
debido a que las cosas podrían cambiar en el entorno de trabajo, su Documento SRS debe ser lo suficientemente flexible como para permitir actualizaciones. No agregue información redundante a varias secciones que deben actualizarse con cada cambio.
verificable
todos en el equipo de desarrollo deben tener acceso al documento para que puedan referenciarlo con la frecuencia que sea necesaria. Los requisitos deben ser precisos para que los miembros del equipo no tengan que pedir más detalles. Todos ellos deben estar disponibles en el documento SRS.,
consistente
los requisitos deben ajustarse entre sí. Una sección de su Documento de requisitos no debe entrar en conflicto con otra. El documento debe tener un formato coherente y utilizar la misma terminología en todo el documento.
sin restricciones de implementación
un documento SRS debe ser lo suficientemente detallado como para terminar el trabajo, pero no debe ser demasiado específico, porque eso podría restringir el desarrollo. Gran parte del desarrollo depende de servicios de terceros sobre los que los desarrolladores no tienen control.,
preciso
Los objetivos en un documento de requisitos deben ser precisos para evitar confusiones. Evite lo siguiente:
- Lagunas: «la aplicación debe cargarse en 3 segundos si se puede hacer.»
- Ambiguity: «el producto MVP debe lanzarse lo antes posible.»
- subjetividad: «la interfaz de usuario debe ser fácil de usar.»
- superlativos: «esta debería ser la mejor aplicación de su clase.»
- Comparative: «esta aplicación debería ser mejor que Slack.,»
un ejemplo de especificación de requisitos de Software (SRS)
Aquí hay un ejemplo recortado de un documento SRS para una aplicación de chat empresarial llamada eChat:
Introducción
Este documento detalla el plan del proyecto para el desarrollo de «eChat.»
está destinado a desarrolladores, diseñadores y probadores que trabajan en «eChat», así como a inversores de proyectos., Este plan incluirá un resumen de:
- cómo funcionará el sistema
- El alcance del proyecto desde el punto de vista del desarrollo
- La tecnología utilizada para desarrollar el proyecto, y
- las métricas utilizadas para determinar el progreso del proyecto
- Descripción general
Las empresas necesitan herramientas de comunicación remota, especialmente ahora que más personas están trabajando desde casa. El problema es que la mayoría de las empresas terminan utilizando múltiples aplicaciones para lograr esto: una para chat de texto, otra para chat de video y otra para conferencias y reuniones., «eChat» resolverá este problema combinando estas características en una sola aplicación.
Descargar el documento
Clientes
Los clientes serán las empresas. No se dirigirá al público en general.
funcionalidad
- Los usuarios deben poder registrarse con cuentas Enterprise LDAP.,
- Los usuarios deben poder crear grupos de chat ad hoc que comprendan conjuntos de usuarios y enviar mensajes privados a usuarios individuales.
- Los usuarios deben poder tener chats de texto que puedan dividir en hilos.
- La aplicación debe ser capaz de manejar el chat de video grupal de hasta 100 usuarios a la vez.
Platform
La aplicación se desarrollará en React Native para permitir la creación de una aplicación basada en web, una aplicación móvil iOS y una aplicación móvil Android.
estas aplicaciones se conectarán a una API REST construida con.,Net Core para almacenar y recuperar datos de una base de datos MySQL.
la autenticación será a través de instalaciones LDAP existentes.
responsabilidades de desarrollo
los desarrolladores del equipo «eChat» serán responsables de escribir todo el código para la aplicación, desarrollar la base de datos y administrar las versiones.,
clase de usuario y características
habrá una clase de usuarios llamada admin que tendrá permisos para acceder a todas las funcionalidades de la aplicación, incluyendo:
- crear canales donde múltiples usuarios pueden interactuar
- Hacer que estos canales sean públicos para toda la empresa o privados para un grupo de personas
- eliminar estos canales
- archivar estos canales
los usuarios estándar tendrán acceso a listed above.,
características del sistema
requisitos funcionales
- Los usuarios deben poder crear grupos de chat ad hoc que comprendan conjuntos de usuarios y enviar mensajes privados a otros usuarios.
- Los usuarios deben poder tener chats de texto que puedan dividir en hilos.
- Los Chats deben poder archivarse indefinidamente para que los usuarios puedan hacer referencia a chats anteriores.
- Los usuarios deben poder subir archivos a los chats como referencia.
- requisitos de interfaz externa
Interfaces de usuario
- Software Front-end: React Native
- Software Back-end: .,sistemas operativos a través de su navegador web predeterminado
- iPhone
- Android
- requisitos no funcionales
requisitos de rendimiento
- La aplicación debe cargarse y ser utilizable en 3 segundos
- La aplicación debe actualizar la interfaz en interacción en 2 segundos
- La base de datos debe normalizarse para evitar datos redundantes y mejorar el rendimiento
- La base de datos debe distribuirse para evitar li>
requisitos de seguridad
- Las bases de datos deben usar sharding para ser redundantes y evitar la pérdida de datos.,
- Las copias de seguridad de las bases de datos deben hacerse cada hora y mantenerse durante una semana.
requisitos de seguridad
- Cualquier clave utilizada para la API REST debe almacenarse de forma segura.
- solo la API REST debería poder conectarse a las bases de datos.
- Las bases de datos deben estar detrás de un firewall.
atributos de calidad de Software
- disponibilidad: debido a que esta aplicación es crítica para la comunicación comercial, tendremos un objetivo de disponibilidad de cuatro nueves(99.99%).,
- corrección: la aplicación nunca debe permitir que nadie lea mensajes o discusiones que no estén destinados a esa persona.
- Capacidad de mantenimiento: la aplicación debe utilizar la integración continua para que las características y las correcciones de errores se puedan implementar rápidamente sin tiempo de inactividad.
- usabilidad: la interfaz debe ser fácil de aprender sin un tutorial y permitir a los usuarios lograr sus objetivos sin errores.
resumen
un documento SRS es una parte necesaria para completar un proyecto de desarrollo de software., Es la hoja de ruta que da dirección a todos los involucrados en el proyecto, para que el producto final satisfaga las necesidades del usuario.
sin un documento SRS completo en su lugar antes de iniciar un proyecto, será difícil saber cuándo se termina un proyecto y podría desviar el desarrollo hacia la creación de características no deseadas. Un documento SRS le da la capacidad de estimar un proyecto con precisión y asignar tareas de manera eficiente.
crear un documento SRS puede ser un proceso largo y meticuloso., Afortunadamente, el equipo de Relevant ha ayudado a más de 200 empresas a crear documentos SRS y lanzar nuevos productos. Estamos listos para ayudar con su próximo proyecto de software, solo envíenos una línea.