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, Desirable content and qualities of a software requirements specification.
Requirements are divided into three:
Functional:
They are statements of the services that the system will provide, The way in which it will respond to particular inputs. In some cases, Functional requirements of systems also explicitly state what the system should not do.
Functional requirements of a system describe the functionality, the services that it is expected to provide. These depend on the type of software and system being developed and on the possible users of the software program. When expressed as user requirements, They are usually described in a common way while the system's functional requirements describe in detail its function, its inputs and outputs, exceptions, and so forth.
Many software engineering problems stem from imprecision in requirements specification. For a system developer it is natural to interpret an ambiguous requirement in order to simplify its implementation. However, often it is not what the client wants. New requirements must be stipulated and changes must be made to the system, delaying its delivery and increasing the cost.
In principle, The functional requirements specification of a system must be complete and consistent. 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, and the delivery requirements that specify when the product and its documentation will be delivered.
• External requirements: They are derived from factors external to the system and its development process. They include interoperability requirements that define how the system interacts with other systems in the organization; the legal requirements that must be followed to ensure the system operates within the law, and ethical requirements. The latter are imposed on the system to ensure that it will be accepted by the user and by the public in general.
A common problem with non-functional requirements is that sometimes they are difficult to verify. They are written to reflect the user's overall goals, 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, in some way, of the other system requirements.
SOFTWARE PROGRAM FEATURES
1. The software program is developed built; it is not manufactured in the classic sense.
Although there are similarities between software development and hardware manufacturing, the two activities would be fundamentally different. In both, high quality is achieved through good design, the hardware manufacturing phase can include quality problems present in the software program.
2. The software program does not wear out.
The software program is immune to environmental harms that wear out 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:
Digital platform on the technological uniqueness of Roko's Basilisk, We promote the artificial intelligence of the future.