Especificaciones De Requerimiento, Características Y Limitaciones Del Software program

Recent Posts
LIMITATIONS
If we compare a software solution to a solution provided by the human mind, the most evident limitation is that a software program does not have intelligence by itself, I mean, it only has predefined functions that cover a set of solutions which, for certain applications, can be limited.
Although a software program does not have intelligence, it can be emulated. This is what is known as artificial intelligence. But emulating intelligence is costly in computational terms, since a large amount of working memory is required. Therefore, many say that the human brain has infinite memory.
Currently, artificial intelligence can emulate neural networks and many things, but it still cannot emulate human thought, since the software program acts under conditions that, are completely true, completely false.
Another common limitation of software is that, due to the fact that software that provides feedback with alternative solutions and low execution time to a problem necessarily requires greater effort and this is not cost-effective, there are solutions to certain problems that involve high execution times, and this is always attempted to be compensated by running the software on higher-capacity machines. This can be noted in problems that require characteristics of human thought, in which a 'mechanical' procedure to find a solution is inefficient.
SOFTWARE REQUIREMENTS SPECIFICATION
A software requirements specification is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions that users are expected to have with the software. It also contains non-functional requirements ( supplementary). Non-functional requirements are requirements that impose constraints on the design and operation of the system (such as performance requirements, quality standards, design requirements).
The recommended strategies for specifying software program requirements are described by the IEEE 830-1998 standard. This standard describes the possible structures, contenido deseable y calidades de una especificación de requisitos del software.
Los requisitos se dividen en tres:
Funcionles:
Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. In some cases, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen la funcionalidad los servicios que se espera que éste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software program. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma common mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, and so forth.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. However, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo.
In principle, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. Completion means that all services requested by the user are defined. Consistency means that the requirements do not have contradictory definitions. In practice, for large and complex systems, it is impossible to fulfill the requirements of consistency and completion. The reason for this is partly due to the inherent complexity of the system and partly because different viewpoints have inconsistent needs. These inconsistencies are obvious when the requirements are first specified. Problems emerge after a deep analysis. Once these have been discovered in the different reviews in the later phases of the life cycle, they must be corrected in the requirements document.
E.g.. the system must issue a receipt when generating the delivery of merchandise.
Non-functional:
They are restrictions of the services functions offered by the system. Include time restrictions, on the development process, standards, and so on.
These are requirements that do not refer directly to the specific functions delivered by the system, but to the emergent properties of it such as reliability, response time and storage capacity. Alternatively, they define the system constraints such as the capacity of input/output devices and the data representation used in the system interface.
Many non-functional requirements refer to the system as a whole rather than to particular features of it. Esto significa que a menudo con más críticos que los requerimientos funcionales particulares. Mientras que el incumplimiento de este último degradará el sistema, una falla en un requerimiento no funcional del sistema lo inutiliza.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software program hardware a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.
E.g.: el soporte de almacenamiento a usar debe ser MySQL.
Empresariales u Organizacionales: son el marco contextual en el cual se implantaría el sistema para conseguir un objetivo marco. Ej: abaratar costos de expedición.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.
• Requerimientos del producto: Especifican el comportamiento del producto; como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.
• Requerimientos organizacionales: Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de implementación como los lenguajes de programación el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.
• Requerimientos externos: Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario y por el público en basic.
Un problema común con los requerimientos no funcionales es que algunas veces son difíciles de verificar. Se redactan para reflejar las metas generales del usuario, such as ease of use, the system's ability to recover from failures artificial intelligence quick response to the user. These requirements cause problems for system developers since they leave room for interpretation, which leads to subsequent discussions once the system is delivered.
Excellently, non-functional requirements should not be expressed quantitatively using metrics that can be objectively tested.
In practice, quantitative specification of requirements is difficult. Clients are not able to translate their goals into quantitative requirements; for some of these, such as maintenance, there are no metrics that can be used; el costo de verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy alto.
In principle, los requerimientos funcionales y no funcionales se diferencian en el documento de requerimientos. In practice, esto es difícil. Si un requerimiento no funcional se declara de forma separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con los requerimientos funcionales, es difícil separar las condiciones funcionales y no funcionales e identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un steadiness apropiado que dependa del tipo de sistema a especificar. However, los requerimientos que claramente se refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocándolos en una sección aparte diferenciándolos, de alguna forma, de los otros requerimientos del sistema.
CARACTERISTICAS DEL SOFTWARE PROGRAM
1. El software program se desarrolla construye; no se manufactura en el sentido clásico.
A pesar de que existen similitudes entre el desarrollo del software y la manufactura del hardware, las dos actividades serian diferentes en lo fundamental. En ambas la alta calidad se alcanza por medio del buen diseño, la fase de manufactura del hardware puede incluir problemas de calidad existentes en el software program.
2. El software program no se desgasta.
El software program es inmune a los males ambientales que desgasten el hardware. Therefore, the failure rate curve for the program software should have the shape of the idealized curve. Undiscovered defects cause high failure rates in the early stages of a program's life. However, Errors are corrected and the curve flattens: Software does not wear out, but it does deteriorate.
3. Although the industry has a tendency towards component-based construction, most program software is still custom-built.
A software component should be designed and implemented so that it can be used in many different programs.
Modern reusable components encapsulate both the data and the process applied to it, lo que permite al ingeniero de software program crear nuevas aplicaciones nuevas a partir de partes reutilizables.
Share this:
%d bloggers like this: