Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Semestre 4 > REQUISITOS > Flashcards

REQUISITOS Flashcards

1
Q

Skate holders

A

Business management: Is the bridge to the development team to customers.
Project Management: Is the person that manages the team. “How are we doing?”
Development Team: This includes requirements gathering, software architecture and design, testing, configuration management.
Customers: Are responsible for purchasing the software
End-Users: The people who interact with and use software after it is finished being developed

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q
  • 4P
A

People: Are the stakeholders. This is the most important part.
Process: Is all part that realizes in the process.

Project: Is the structure of the development of everything project, the times, the activities.

Product: Is the part finally, that is given to users or client.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Artifact:

A

Component for a software deliverable. For example, a database.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Certification

A

The validation of knowledge.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

JIRA

A

Software that allows you to manage the entire project process.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Spring:

A

Short period of time to do activities.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Modularity

A

It allows us to solve the project because the problem is divided into a sequence of activities.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

MoSCoW

A

Must have, Should have, Could have, Will not have. Direction structure to divide the.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

UML

A

: Unified Modeling Language, Creating diagrams to support the relationship of POO.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Abstraction:

A

It does not specify the attributes and defines the behaviors.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Polymorphism:

A

The object can change, according to the characteristics.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q
  • Inheritance:
A

It is an attribute that is extracted and placed on others

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q
  • Object:
A

Instance of a class.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q
  • Class:
A

Template or model to create an object.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q
  • SaaS:
A

Providing software over the internet as a service.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

AWS:

A

Cloud storage.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q
  • GitHub
A

: Allows collaborative logical work.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q
  • StartUp
A

: A team of people where an application is developed that will eventually be bought by a large company.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Agile methodology:

A

It is a methodology that uses incremental requirements, they are interactive and this helps to carry out the processes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q
  • Traditional methodology:
A

It has a process where if a stage has already passed, the process should not be returned.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Difference beetween agile and traditional methodology is that

A

is the times and costs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Software Fails:

A

It’s when reports fail (CHAOS REPORT).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Specification:

A

: Details about the functions of the program. Example: In specific language, Java.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q
  • Requirement:
A

They encompass the entire project, they are the abstraction and generalities. OR Description that software unions also are the restrictions that the product must have.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q
  • Requirements Engineering:
A

Systematic process that indicates supporting us with some methodology that allows us to create certain software products or generate software artifact components, databases.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Elicitation:

A

Process by which we collect the requirements through interviews, analysis, practices.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q
  • Public Elicitation:
A

Transparent process, where the elicitation bases on the government project are published.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q
  • Ethnography:
A

Uses qualitative research method to systematically describe the culture of different human groups.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q
  • FIGMA:
A

It is used to create prototypes, and so the client can see the project process to give feedback.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q
  • Engineering discipline:
A

The design, analysis, and construction of an artifact for some practical purpose.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q
  • Software Engineering:
A

Is the application of a systematic, disciplined, quantifiable approach “Development, operation, and maintenance of software.”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q
  • Ambiguity:
A

It is the quality of having several interpretations, the characteristics that have not been clarified.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q
  • Technical Jargon:
A

This refers to the technical language of engineering.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q
  • SRS:
A

It is the document that is in the middle of user requirements (descriptions), this document is made to document the entire process.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q
  • User Req:
A

It is written in natural language, a specification from the user’s perspective. Example: User registration, colors, also being able to log in.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q
  • System Req:
A

It is written in machine language, a specification from the system’s perspective. Example: User information is stored in a database.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q
  • System management:
A

Those who maintain the application.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q
  • System owners:
A

Those who invest in the company.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q
  • External and Stakeholders:
A

the competition or indirectly affected.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q
  • Use Case:
A

It is an abstract representation of how stakeholders interact in the scenario. It is abstract because it is the first general representation, it does not enter specifically into the attributes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Errors in Software Engineering:

A

Deviations from the process.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q
  • Agile methodologies:
A

They help reduce time and costs, and these are interactive, while traditional methodologies, do not return to the previous process.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q
  • Functional Requirement:
A

Statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q
  • Non-functional Requirement:
A

Constraints on the services or functions offered by the system such as timing constraints, the development process, standards, etc.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q
  • Organizational:
A

These requirements rewrite restrictions that the company has. Example: Applications that are old developed from 2005 to 2008, for example, the company outsourcing, infrastructure, Microsoft.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q
  • Environmental:
A

These are specific restrictions on how the system will operate. Example: The system must be available during the working period.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Development:

A

Constraints derived from the development process standards set by the organization. Such as the language or others.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q
  • Operational:
A

Describe constraints derived from how the system should be used on a day-to-day basis. Such as calibrating a pressure artifact.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q
  • External Legislative:
A

These describe guidelines that must be followed to comply with the law. Such as copyright, Spotify, YouTube

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q
  • External Regulatory:
A

These describe the guidelines that must be followed for the system to be approved for use by a regulator. Such as Blood Platelets that require many requirements.

51
Q
  • External Ethical:
A

Ensure that the system is socially acceptable for use by its users and the general public. Example: Voice recognition using AI, but the data it is analyzing.

52
Q

Difference between legislative and regulatory

A
  • Legislative must follow a law and regulatory must be approved. Legislative must comply with a law by a country, and regulatory must comply only with the regulatory entity.
53
Q
  • Security Requirements:
A

Are specifications based on protecting system data.

54
Q
  • Dependability Requirements:
A

Refers to consistency, error-free. Mounting services in the cloud buy cloud services, have another in case one fails, because they are.

55
Q

Discovery:

A

Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.

56
Q

Classification and Organization:

A

Groups related requirements and organizes them into coherent clusters. Backlog: Refers to the classification of activities and the schedule and priority.

57
Q
  • Prioritization and negotiation:
A

Prioritizing requirements and resolving requirements conflicts.

58
Q

Specifications:

A

Requirements are documented and input into the next round of the spiral.

59
Q

Interview:

A

These are questions to stakeholders to streamline the RE process.

60
Q

Closed interview:

A

Prepared questions. These are better when there is no experience in the field.

61
Q
  • Open Interviews:
A

There is an opportunity to make software. When stakeholders when end users do not know what they want.

62
Q

Figma:

A

Visual prototype where the user can see and give feedback.

63
Q
  • Project management:
A

Understanding how to use project management software in a professional environment.

64
Q
  • Observations:
A

Observing a team used by the software manager for tasks and collaborations.

65
Q
  • Surprising observation:
A

When for a project implication, it’s not within the metrics. For example, they don’t use the chat included in the software, like Messenger. So, a bad conclusion is that the chat doesn’t work, but a good conclusion is they prefer another chat because it’s more familiar.

66
Q
  • Stories and scenarios:
A

Real-life examples of how a system can be used. A description of how a system may be used for a particular task.

67
Q

Scenario:

A

A structured form of user story.

68
Q
  • Natural language
A

: It’s the way we communicate. Example: The system must have all employees and record new products in inventory.

69
Q
  • Structured Natural Language:
A

It’s a way to order requirements using a more formal form. This helps to standardize, words like must, shall, shall not.

70
Q
  • Design description language:
A

Formal systems used to describe and specify software design. UML, use cases.

71
Q

Graphical notations:

A

These are visual representation systems that use symbols, diagrams, and charts to communicate information in a more intuitive and understandable way than written text.

72
Q

Mathematical Specifications:

A

It’s a precise and formal way to describe the behavior of a system using mathematical concepts and notations.

73
Q

Guideline for writing requirements:

A
  1. Invent a standard format anduse it for all requirements, 2. Use language in a consistent way shall, should.
  2. Use text highlighting to identify key parts of the requirement.
  3. Avoid the use of computer jargon.
  4. Include an explanation (rationale) of why a requirement is necessary
74
Q
  • Problems with natural language
A

Lack of clarity: Precision is difficult without making the document difficult to read.

Requirements confusion: Functional and non-functional requirements tend to be mixed up.

Requirements mix-up: Several different requirements can be expressed together.

75
Q
  • Pre:
A

The first condition that must be met.

76
Q

Post:

A

When the pre-condition is met, this is the one that continues.

77
Q

Side effects (if any):

A

The sensor does not work correctly.

78
Q
  • Tabular Specification:
A

Particularly useful when defining a series of possible alternative courses of action.

79
Q
  • Difference Diagram:
A

It is a diagram where specific characteristics can be made.

80
Q
  • System customer:
A

The one who wants the requirements.

81
Q

Managers:

A

Make the plan for the system and the development process.

82
Q

System engineers:

A

Develop the requirements for this program.

83
Q
  • System test engineers:
A

Ensure that documents are validated. If an email was sent but not received correctly.

84
Q
  • System maintenance engineers:
A

What can be managed to make an improvement? Create a new function, where tokens will be made to improve the token.

85
Q
  • structure of requirements document: Preface:
A

Describe its version history, including a justification for creating a new version and a summary of the changes made in each version.

86
Q
  • structure of requirements document: Glossary:
A

This should define the technical terms used in the document. It should not make assumptions about the reader’s experience.

87
Q
  • structure of requirements document: User requirements definition:
A

Diagrams are placed here so that all readers of this document understand it. System requirements must be described.

88
Q
  • structure of requirements document: System architecture:
A

A high-level overview of the anticipated architecture of the system, showing the distribution of functions among the system’s modules.

89
Q
  • structure of requirements document: System requirements specification:
A

Details about the project, about the requirements.

90
Q

structure of requirements document

A

System models: A prototype Sigma model is used here (Figma).

91
Q
  • structure of requirements document: System evolution:
A

Any anticipated changes due to hardware evolution. These are requirements that make an assumption about what the hardware should have.

92
Q

structure of requirements document: Appendix:

A

These should provide detailed and specific information related to the application being developed. Investigating the client’s process, their computer is very old, or they don’t maintain it. So, it will be a problem.

93
Q
  • structure of requirements document: Index:
A

Separate by sections alphabetically.

94
Q
  • Verification:
A

If what is being done is being done correctly. Part of development.

95
Q
  • Validation:
A

Are we building the final project correctly? Part of the client.

96
Q
  • Validity:
A

Does the system provide functions that best meet the needs of the client?

97
Q
  • Consistency:
A

There should be no discrepancies in the requirements given, they should be coherent and not contradictory.

98
Q
  • Completeness:
A

We must ask ourselves if the requirement is completely complete, but it is not clear to me if it should be this way or that.

99
Q
  • Realism:
A

The analysis of the bases to know if the requirements can be used. Time, human capital. It must be possible, in time, form, and human capital.

100
Q
  • Verifiability:
A

A verifiable requirement is one that provides specific characteristics and what is asked for.

101
Q
  • Requirements review “TEMPLATE”: Preparation:
A

Everyone will have a copy of the requirements.

102
Q
  • Requirements review “TEMPLATE”: Individual review:
A

Each member reviews the criteria individually.

103
Q
  • Requirements review “TEMPLATE”: Review meeting:
A

Ambiguities, inconsistencies are identified.

104
Q
  • Requirements review “TEMPLATE”: Problem log:
A

Analysis of problems, questions.

105
Q
  • Requirements review “TEMPLATE”: Problem resolution:
A

Responsibilities are assigned and problems are correctly identified.

106
Q

Prototypes:

A

It is the model of the system and use it so that end users and clients can see if it meets their needs and expectations. User interface Prototype (UI).

107
Q
  • Process flow prototype:
A

FIGMA, interactions. Visual paradigm. Report or output prototype.

108
Q

Review checks: Verifiability:

A

Is the requirement realistically testable?

109
Q
  • Review checks: Comprehensibility:
A

Was the requirement understood well?

110
Q
  • Review checks: Traceability:
A

Is the origin of the requirement clearly indicated?

111
Q
  • Review checks: Adaptability:
A

Can the requirements be changed without a major impact on other requirements?

112
Q
  • Review checks: User difference in client:
A

When you enter Amazon, you have an account, you are a user, but if you are a client, you buy.

113
Q
  • Review checks: Traceability:
A

Estimate the time and costs based on changes or process, or investments.

114
Q

Difference between traceability, verifiability, and usability:

A

Traceability must be understood from its origin estimating time and costs, verifiability is if the requirement can be done, and usability is if the public can easily use it.

115
Q

Requirements change: Business Needs:

A

Customer demands.

116
Q
  • Requirements change: Stakeholders Feedback:
A

Developers understand through use cases, a change could be to automate. Proactivity.

117
Q
  • Requirements change: Project scope clarification:
A

Better understanding of project objectives and limitations.

118
Q

Requirements change: Identification of requirements:

A

Each requirement must be uniquely identified so that it can be cross-referenced with other requirements.

119
Q
  • Requirements change: Change management process:
A

This is the set of activities that evaluate the impact and cost of changes. I will discuss this process in more detail in the following section.

120
Q

Requirements change: Traceability policies:

A

These policies define the relationships between each requirement and between the requirements and the system design that must be recorded.

121
Q

Requirements change: Tool support:

A

The tools that can be used range from specialized requirements management systems to spreadsheets and simple database systems.

122
Q

Requirements change: Analysis of problems and specification of changes:

A

During this stage, the problem or proposed change is analyzed to verify that it is valid. This analysis is returned to the change requester, who may respond with a more specific requirement change proposal, or decide to withdraw the request.1

123
Q
  • Requirements change: Analysis of changes and costs:
A

The effect of the proposed change is evaluated using traceability information and general knowledge of the system requirements. Once this analysis is complete, the decision to proceed or not with the requirement change is made.2

124
Q

Requirements change: Implementation of changes:

A

The requirements document is modified and, when necessary, the design and implementation of the system. Ideally, the document should be organized so that changes can be easily implemented.3

Semestre 4 (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions