¿Cuál es la diferencia entre requisitos y especificaciones? [cerrado]

122

Me encargaron desarrollar requisitos y especificaciones para un proyecto que nuestro grupo está comenzando.

Me di cuenta de que no sé la diferencia; una búsqueda en Google simplemente me confundió más: parece que algunas personas dicen que las especificaciones son requisitos, pero en un nivel inferior.

requirements specifications

Estoy de acuerdo con las respuestas de alto voto, pero también creo que el término especificación a veces se usa como un término más genérico en la industria del software que se refiere a cualquier documento que describa un sistema o pieza de software. Como prueba - google "especificación de requisitos". Cuando se usa de esa manera, significa un documento que especifica algo, es decir: especifica los requisitos para una pieza de software. No juzgaré si es un uso correcto de la palabra o no, solo quería señalar que la especificación no siempre significa lo mismo para todos.

— Shane Wealti

1

Sí, por eso la gente debería decir "Requisitos comerciales" y "Especificación de diseño" / "Especificación técnica" o algo así. Las palabras en sí mismas son bastante vagas.

— user606723

Piénselo de esta manera (en términos generales): Requisitos = requisitos de documentación y especificaciones = caso de uso / documentos de diseño

— PhD

44

¿Por qué no le preguntas a la (s) persona (s) para la que estás haciendo esto? Solo ellos pueden responder lo que se necesita en su caso específico .

— Jaap

Este artículo ofrece una respuesta completa: ece.cmu.edu/~koopman/des_s99/requirements_specs

— Julien-L

129

La respuesta correcta es que los requisitos son lo que debe hacer su programa, las especificaciones son cómo planea hacerlo.

Otra forma de verlo es que los requisitos representan la aplicación desde la perspectiva del usuario o del negocio en general. La especificación representa la aplicación desde la perspectiva del equipo técnico. Las especificaciones y requisitos comunican aproximadamente la misma información, pero a dos audiencias completamente diferentes.

— Bryan Oakley
fuente

44

La mordida de sonido qué / cómo es correcta, más o menos; pero confuso, porque también puede ver la especificación de un programa que describe lo que debe hacer, y el diseño es cómo debe hacerlo. Otro es el declarativo pl (como prolog y SQL), en el que se indica qué no, cómo . Una resolución es que son una jerarquía jerárquica de abstracciones, con un padre que dice qué y los niños que dicen cómo (afuera versus adentro). Prefiero su segunda vista, que está más cerca de " para qué sirve " frente a "para qué sirve ", es decir, beneficio versus función.

— 13ren

En general, estaría de acuerdo con usted, pero es solo 'otra' opinión y no la respuesta correcta. Por ejemplo, eche un vistazo a la página Wiki para Requisitos ( en.wikipedia.org/wiki/Requirement ). Hay requisitos no funcionales, que por definición son para el equipo técnico. O requisitos arquitectónicos y de restricciones, nuevamente técnicos, pero no los llaman 'especificaciones'. Creo que no hay una respuesta correcta y siempre será "borrosa" de una compañía a otra y de un desarrollador a otro.

— Jeach

1

Eche un vistazo a la respuesta de 'Adam Wuerl' a continuación, creo que esa es la declaración más precisa de la pregunta publicada.

— Jeach

1

@Jeach: "bramido" [sic] es relativo. Puede estar debajo de esta publicación en este momento, pero podría moverse arriba, haciendo que su comentario sea más difícil de entender

— Bryan Oakley

1

Otra perspectiva ... Wikipedia define las especificaciones como un "conjunto de requisitos". Esto significa que una especificación puede ser solo 1 requisito, s: = {r1}. Parece más que los "requisitos" coloquiales son requisitos de "alto nivel", mientras que las "especificaciones técnicas" son requisitos de bajo nivel, algo LOD.

— Lance Pollard

38

Los requisitos documentan lo que se necesita: no deben especificar el cómo, sino el qué.

Las especificaciones documentan cómo lograr los requisitos; deben especificar el cómo.

En muchos lugares, estos documentos no están separados y se usan indistintamente.

— Oded
fuente

2

En mi empresa, normalmente usamos los términos "especificación de requisitos" para el qué (usted especifica, escribe los detalles, de qué es qué) y "especificación de diseño" para el cómo (especifica, escribe los detalles, cómo plan para implementarlo).

— Giorgio

16

Soy ingeniero de sistemas en el campo aeroespacial, donde ambos términos se usan ampliamente. La distinción es clara y no tan compleja como la hacen los demás.

Una especificación es un documento que especifica un sistema o producto, por ejemplo, una especificación de desarrollo de elemento principal para un F-14. Hay muchas secciones / contenido en una especificación: requisitos, definiciones, documentos de referencia, glosario, información de verificación, etc.

Un requisito es una declaración única de algo que el producto o sistema debe hacer. Una especificación puede tener cientos de requisitos. La metodología de la vieja escuela dice que la declaración de requisitos debe usar la palabra "deberá", para separar los requisitos de las declaraciones de hechos o definiciones. (No estoy seguro de si los nuevos y ágiles niños ágiles cumplen con todo esto o no; la fastidiosidad tiene su uso, pero a veces es un poco quisquilloso).

Por lo tanto, una especificación es un documento lleno de requisitos, además de alguna otra información de soporte y auxiliar.

— Adam Wuerl
fuente

44

Como dije en otro comentario, es muy borroso para todos y probablemente siempre lo será. Pero según mi propia investigación MUY extensa sobre este tema exacto, diría que su respuesta es la más precisa para mis propios hallazgos / conclusiones.

— Jeach

2

Siempre útil para obtener el aporte de un ingeniero real. ¡Gracias!

— LeWoody

Alternativamente, una especificación puede tener 0 requisitos. Su ejemplo es realmente bueno para una disciplina de ingeniería aeronáutica muy específica. No estoy tan seguro de que generalmente sea aplicable al dominio de programación / desarrollo de software. Cuando la mayoría del software está impulsado por las demandas comerciales, tiene sentido comenzar con un Documento de requisitos comerciales detallado antes de evaluar las limitaciones técnicas y diseñar una solución. La especificación técnica seguiría el BRD, documentaría las restricciones y proporcionaría un enfoque detallado y específico para satisfacer los requisitos comerciales en el BRD.

— Bryan 'BJ' Hoffpauir Jr.

1

@ Bryan'BJ'Hoffpauir Estoy seguro de que hay casos en los que los documentos están etiquetados como especificaciones y no tienen requisitos, pero diría que es un mal uso del término. Una especificación es un documento de requisitos: fin de la historia. Es un término de arte ampliamente aceptado en más campos que el aeroespacial y de defensa y no se puede cuestionar dentro de la ingeniería de sistemas, que es la disciplina responsable de los requisitos y la verificación. Incluso en el caso de que describa el término se aplica: el BRD es una especificación, la especificación técnica también suena como una, solo con diferentes tipos de requisitos.

— Adam Wuerl

13

Requisitos:

Determine las necesidades o condiciones que se deben cumplir para un producto nuevo o alterado, teniendo en cuenta los requisitos posiblemente conflictivos de los distintos interesados.

Especificaciones:

Proporcionan una idea precisa del problema a resolver para que puedan diseñar eficientemente el sistema y estimar el costo de las alternativas de diseño. Proporcionan orientación a los evaluadores para la verificación (calificación) de cada requisito técnico.

La cita es de "Fundamentos de ingeniería de sistemas ^* ".

Los requisitos se basan en las necesidades de las partes interesadas, las especificaciones son más un documento interno detallado y técnico. Son diferentes, pero hablan de lo mismo.

_{* Defense Acquisition University Press, 2001. Versión en PDF del texto.}

— talabes
fuente

Creo que es importante que su definición diga que las especificaciones definen el PROBLEMA. De esa manera, una especificación PROBLEMA es un requisito. Una especificación de SOLUCIÓN o DISEÑO es parte del diseño.

— LeWoody

6

Los requisitos son la descripción de los usuarios de lo que el producto terminado, a sus ojos, debe hacer.

La especificación es la descripción técnica de la solución en general, que cubre los requisitos y mucho más, por ejemplo, costo, tecnicismos, problemas, etc.

Por lo tanto, uno de los puntos principales es que los Requisitos deben venir primero antes de que se pueda escribir una Especificación.

(Observe la terminología - producto y solución - lo mismo pero desde diferentes perspectivas ...)

— Arj
fuente

1

Cambiaría los términos "producto" y "solución", porque una solución generalmente es en términos del problema del cliente, mientras que un producto generalmente es en términos del vendedor (es decir, el implementador técnico). Un contraste similar es beneficio / característica, donde el beneficio está en términos del cliente (para qué les sirve), y la característica está en términos de implementación (qué es realmente , para que podamos lograrlo).

— 13ren

1

Veo su punto, pero creo que cualquiera de los ángulos describe adecuadamente la situación. Asumí que un cliente compraría un producto, como usted cuando va a una tienda. Un proveedor de software estaría ofreciendo su solución al problema subyacente. Si tuviera que salir a buscar una solución a mi problema, probablemente pensaría, "Necesito un producto que funcione xyz", no, "Necesito una solución a mi problema de abc". Es solo una cuestión de preferencia, creo.

— Arj

interesante. Puedo ver a los clientes "buscando un producto", cuando hay una categoría de producto establecida. Pero buscan ese producto porque ya han resuelto que resolverá su problema, es decir, buscan ese producto, no por su propio bien, sino como una solución. También es cierto que un proveedor comercializa su producto como una "solución", pero eso se debe a que están tratando de comunicarse con los clientes (que buscan soluciones a sus problemas) y construir algo que se querrá. Realmente construyendo el producto (es decir, la cosa en sí y sus características independientemente de por qué se necesitan)

— 13ren

Puedo ver a los clientes "buscando un producto", cuando hay una categoría de producto establecida, pero lo buscan como una solución a un problema / necesidad que tienen. Los proveedores comercializan sus productos como "soluciones", porque se comunican con los clientes (que tienen problemas para solicitar soluciones). Al construir el producto (la cosa en sí y sus características, no por qué los están construyendo). Un argumento es que un problema puede tener soluciones muy diferentes, pero un producto es una cosa específica.

— 13ren

[explicando por qué dos comentarios]: los comentarios SO son tan dolorosos: presionar "regresar" enviará el comentario, a pesar de que es un área de texto de varias líneas. Y si te toma más de 5 minutos terminarlo después de eso, no aceptará la edición. Entonces debes enviarlo como un segundo comentario. Estaba editando solo para que se ajustara a la longitud. suspiro . La próxima vez lo explicaré dos comentarios en primer lugar ... [de todos modos, estoy de acuerdo en que el punto de vista - comprador / vendedor - es la principal distinción. Me preocupa su terminología, pero creo que profundiza mi comprensión al tratar de articular por qué.]

— 13ren

4

Requisito: qué debe (debe) hacer el sistema o subsistema.

Especificación: cuál es el componente, subsistema o sistema.

Esto es crítico en la industria de fabricación de dispositivos médicos, ya que debe llevar a cabo una verificación en función de sus requisitos (entradas) para demostrar que tiene especificaciones válidas (salidas). Las dificultades típicas en esta industria es que las empresas (1) se olvidan de definir los requisitos (porque no entienden la diferencia entre los requisitos y las especificaciones); (2) Verificación de conducta solo con respecto a las especificaciones y (3) No asegúrese de que los Requisitos se traduzcan con precisión en las especificaciones de subconjuntos y componentes.

Una vez hecho todo esto, deberá validar que se hayan cumplido los requisitos del usuario para el producto.

— Paul Bacchus
fuente

3

Quizás la confusión es que he escuchado que las especificaciones se refieren a documentos de Especificación de Requisitos Comerciales o documentos SRS (Especificación de Requisitos de Software) estándar IEEE.

Ejemplo de plantilla SRS estándar IEEE

También he escuchado que el término especificaciones se refiere más informalmente a las Especificaciones técnicas que explican las decisiones de diseño y un plan de implementación.

EDITAR: acabo de notar que el enlace es incorrecto ... publicaré un enlace correcto en breve.

— árbol de arce
fuente

1

Buen punto sobre el término SRS!

— LeWoody

2

El enlace ahora está completamente roto. No estoy seguro de lo que señaló ni de qué material debería señalar.

3

Una especificación es un requisito que pasó la factibilidad y está listo para implementarse. Es un requisito que ha evolucionado hasta la fase de diseño.

En otras palabras:

Un requisito es el comportamiento (o no comportamiento) "según lo planeado" o "según lo deseado"
Una especificación es comportamiento (o no comportamiento) "para ser construido" o "como construido"

Ejemplo:

requisito: 1. el usuario presiona el botón OK 2. el sistema imprime la factura
especificación: 1. el usuario presiona el botón OK 2. el sistema imprime la factura

Como puede ver, el contenido de ambos puede ser el mismo. La diferencia es que el requisito es un artefacto de análisis. La especificación es un artefacto de diseño.

En una documentación final tal como está construida, normalmente encontrará la palabra "especificación", en lugar de "requisito", ya que los requisitos se han convertido en especificaciones.

Observación: el ejemplo anterior contiene elementos de diseño, debido a la restricción de diseño.

— fox.bailey
fuente

0

Los requisitos son los que hace la aplicación

Las especificaciones son CÓMO la aplicación hace lo que hace.

¡Deben ser ortogonales!

Los gerentes de producto escriben los requisitos, los ingenieros principales escriben las especificaciones.

— jayunit100
fuente

2

No estoy seguro de que sean completamente ortogonales, al menos en la práctica. Desafortunadamente, hay mucho gris.

— LeWoody

Solo son grises si deja de lado los modificadores: los requisitos comerciales, los requisitos funcionales y los requisitos no funcionales se refieren a la capacidad del sistema (LO QUE hace). Las especificaciones técnicas son ortogonales a los requisitos comerciales (el CÓMO lo hace).

— Bryan 'BJ' Hoffpauir Jr.

0

Una forma, tal vez no la correcta, de verlo:

Los requisitos son cosas (capacidades, características, comportamientos, etc.) que producen valor para el usuario. No le preocupan las partes internas; aquí solo son importantes las entradas y salidas de la caja (y tal vez el tamaño, la forma y el color).

Las especificaciones son cosas (capacidades, características, comportamientos, etc.) que permiten ese valor para el usuario. Aquí los elementos internos de la caja son importantes, porque junto con las interfaces externas y las características mencionadas anteriormente definen todo el sistema.

— Berad
fuente

¿Es esta solo tu opinión o puedes respaldarla de alguna manera?

— mosquito

2

@gnat, pensé que se abordó en la línea de apertura? Claro, esto es por experiencia y no estoy reclamando nada más; por lo que deduzco, esta es una pregunta un tanto subjetiva en un foro bastante subjetivo, y esta publicación sugiere que las preguntas deberían ser lo más objetivas posibles, pero hace poca mención de las respuestas . Pero tengo uno por mi nombre y tú tienes mucho más, así que estoy abierto a ser educado :-)

— berad

0

En mi investigación, he encontrado especificaciones para ser utilizadas para patentes y construcción de viviendas (como parte de un contrato).

La definición de un requisito del diccionario Webster's Unbridged (3rd New Int'l Ed.) Es:

a) algo que se quiere o se necesita: Necesidad b) algo que se pide o se exige: una condición necesaria o esencial: una calidad, curso o tipo de capacitación requerida

Creo que lo anterior muestra que son claramente diferentes. Supongo que podría llamar requisitos de nivel inferior de especificaciones, pero creo que es una perversión del término requisito en mi humilde opinión.

— LeWoody
fuente

0

En una empresa anterior que creaba productos comerciales teníamos la siguiente distinción:

Los requisitos son lo que debe hacer el sistema. Pueden ser de menor nivel, requisitos detallados y pueden ser funcionales o no funcionales.

Las especificaciones son aquellas cosas que hace el sistema tal como está construido. Por ejemplo, podría tener un requisito que establece que el sistema tendrá un comportamiento X a –10 ° C. La especificación real del sistema puede ser que el sistema hace X a –5 ° C; esto estaría en la hoja enviada a los clientes potenciales cuando quieran comprar el sistema.

Nota: en este caso, la especificación no es igual al requisito.

— RoyD
fuente

-1

Piensa, vas a construir un edificio de gran altura en un terreno.

Ahora debe tener en cuenta los Requisitos antes de comenzar, como:

Ingeniero de Arquitectura o Diseño
Ingeniero de pruebas de suelos
Equipo de prueba de presión de viento
Demoledor
Cavador
Hombre poder
Suministro de agua
Trabajadores que viven / área de descanso
Suficiente fondo
Gestión de proyectos
Gestión de la calidad
Seguridad y control de seguridad

Etc.

Ahora los contenidos anteriores son parte de los Requisitos para construir un edificio de gran altura. Del equipo anterior, obtienes el resultado técnico, que tienen como parte de la profesión.

Esto es exactamente lo que está sucediendo en la industria del software, un grupo de personas profesionales involucradas para proporcionar conocimiento para construir la especificación técnica, como alguien que trabaja en diseño de interfaz de usuario, diseño de OO, diseño de bases de datos, diseño gráfico, diseño de casos de prueba, codificación, integración , equipo de despliegue, etc.

El párrafo anterior formará parte del manual, al que puede llamar Especificación técnica.

— Mohammed Hoq
fuente

1

Creo que confunde los requisitos con los recursos ( en.wikipedia.org/wiki/Resource_%28project_management%29 ).

— Jay Elston el