UNIVERSIDAD SANTO TOMAS, CAU- DUITAMA

FACULTAD DE CIENCIA Y TECNOLOGÍA

INGENIERÍA INFORMÁTICA

DESARROLLO DE SOFTWARE

TECNICAS DE MODELADO

EVALUACIÓN DISTANCIA

ANA ROCIO MOLANO AVELLA

CÒDIGO: 2204528
 
DOCENTE:
CRISMAN MARTINEZ
 
DUITAMA
2020-2
 CUADRO COMPARATIVO DE AUTORES – TEMA Ingeniería de software
Ian Sommerville. Ingeniería de
Software, Edición 9
4. Requirements Engineering
The requirements for a system
are descriptions of what the
system must do: the service it
offers and the restrictions on its
operation. Such requirements
reflect customer needs for a
system that serves a certain
purpose, such as controlling a
device, placing an order, or
searching for information.
Concepto con respecto a cada tarea/actividad
de Roger Steven Pressman. Ingeniería de
Software. Edición 7.
Requirements engineering establishes a solid
foundation for design and construction.
Without it, the resulting software has a high
probability of not meeting customer needs.
Concepto con respecto a cada
tarea/actividad de Requerimientos del
software detallados by Guide to the
software engineering body of knowledge,
SWEBOK version 3.0
The Software Requirements Knowledge
Area (KA) deals with obtaining, analyzing,
specifying, and validating software
requirements as well as managing
requirements throughout the software
product life cycle.
 4.1 Functional and non-functional
requirements
Functional requirements: They are
statements about services that the
system must provide. Non-
functional requirements: These are
limitations on services or functions
offered by the system.
Non-functional requirements
often restrict the system to be
developed and the development
process to use.
The functional requirements are
statements of the services that the
system, or descriptions of how some
calculations should be performed.
Non-functional requirements are
sometimes known as quality
constraints or requirements. The
functional requirements describe
the functions that the software will
perform.
 4.2 The software
requirements document. It is an
official statement of what the
system developers must
implement
4.3 Requirements specification:
states that the requirements is the
process of writing, in a document,
the user and system requirements.
The software requirements document is an
agreed statement of the system requirements. It
should be organized in a way that can be used by
both system clients and software developers.
Requirements specification is the process of
writing, in a requirements document, user and
system requirements.
This document (sometimes known as
the User Requirements Document or
Concept of Operations Document) records
the system requirements. That defines the
high-level system requirements from the
domain perspective.
In software engineering, "software
specification requirements" normally refers
to the production of document that can be
systematically revised, evaluated and
approved
 4.5 Requirements acquisition and analysis
In this activity, software engineers work with
customers and end users of the system to
discover the application domain, what services the system should provide, the required
the system should provide, the required
performance of the system, the hardware
constraints.
4.5.1 Requirements discoveries: is the
process of gathering information about the
required system and existing systems, thus
how to separate, from this information, the
requirements of the user and the system.
4.5.2 Interviews
In these interviews, the requirements
engineering team asks the participants
questions about the system they currently use
and the system to be developed.
In this activity, software engineers work One of the fundamental principles of a process for
with customers and end users of the system to obtaining requirements is the effectiveness of
discover the application domain, what services communication between the different interested
parties. In the analysis detects, elaborates
performance of the system, hardware requirements for the software.
constraints, and so on.
Requirements acquisition: is the process of Requirements have many sources in typical
gathering information about the required software, and it is essential that all potential sources
system and existing systems, as well how to are identified and evaluated for their impact on it.
separate, from this information, the
requirements of the user and the system.
The first set of these focuses on the
client and other stakeholders, on
overall goals and benefits.
Interviews seek to obtain requirements.
 Developers and users create a set of
4.5.3 Scenarios scenarios that identify the nature of Scenarios provide valuable means of
the uses for the system to be built. The
Scenarios are particularly useful for scenarios, which are often called use providing context for the tender user

detailing a description sketch of cases, provide the description of how requirements.

the system will be used.
requirements. These are examples of

interaction session descriptions.

4.5.4 Use cases Use cases are documented using a use  The set of use cases represents all

Represents all possible interactions that case diagram of high level. possible interactions that will be described in
will be described in the system the system requirements.

requirements.

4.5.5. Ethnographic Ethnography is an observational  

It is an observation technique used to technique used to understand operational

understand the processes operational and processes and help derive support

help derive support requirements for these requirements for those processes.

processes
 combines elements of problem
4.6 Requirements validation solving, elaboration, negotiation Process that validates and organizes
and specification.
It is the process of verifying that the the requirements to fulfill that required

requirements really define the system by the user.

that the customer really wants.

4.7 Requirements management It is Many different approaches have Change management is central to
the process of understanding and been proposed to collect requirements analysis. This topic

controlling changes in system describes the role of change

requirements collaboratively.
requirements. management, the procedures that need
.
to be prepared, and the analysis that
should be applied to the proposed

changes.
 4.7.1 Requirements management
planning: This stage establishes the level
of detail that is required in requirements technique that translates customer
management.
4.7.2 Requirements change
management: Requirements change
management should be applied to all
proposed changes to the requirements
of a system, after the requirements
document is approved.
It is a quality management Tracing of requirements refers to the
source of retrieving requirements and
predicting the effects of those
needs into technical requirements
requirements.
for the software.
The work products generated as a It is typically necessary to validate the
consequence of the inquiry into the quality of the models developed during
the analysis.
requirements will vary depending on
the size of the system or product to
be built.
 4.3.1 Natural language specification:
Requirements are written in natural language in
a standard form or template. Each field
provides information on one aspect of the
requirement.
4.3.2 Structured Specifications Structured
language is a way of writing system
requirements, where the freedom of the
requirements writer is limited and all
requirements are written down in a standard
way.
4.4 Requirements engineering processes: In
Sommerville, 2011 a spiral process model is
proposed that includes the activities of the
requirements engineering processes: Feasibility
study: value if it is useful for the company.
Acquisition and analysis: declare the
requirements. Specification: design those
requirements in some standard way. Validation:
seeks that the designed requirements meet the
customer's conditions.
Natural language is used to write the Natural language is the common and
software requirements. It is expressive, universal.
intuitive and universal.
The specification uses programming  The goal of this matter is to provide an
language constructs to show alternatives understanding of that process of
and iteration, and highlights key elements
requirements.
with the use of shading or different fonts.
They focus on assessing whether the It shows how the requirements process
system is useful for the company (feasibility fits into the general software engineering
study), discovering requirements
process.
(acquisition and analysis), converting these
Process models
requirements in some standard form
Process actors
(specification) and check that the
Process management and support
requirements really define the system that
the customer wants (validation). Quality and process improvement