REQUISITOS Flashcards
(124 cards)
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
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.
3
Q
Artifact:
A
Component for a software deliverable. For example, a database.
4
Q
Certification
A
The validation of knowledge.
5
Q
JIRA
A
Software that allows you to manage the entire project process.
6
Q
Spring:
A
Short period of time to do activities.
7
Q
Modularity
A
It allows us to solve the project because the problem is divided into a sequence of activities.
8
Q
MoSCoW
A
Must have, Should have, Could have, Will not have. Direction structure to divide the.
9
Q
UML
A
: Unified Modeling Language, Creating diagrams to support the relationship of POO.
10
Q
Abstraction:
A
It does not specify the attributes and defines the behaviors.
11
Q
Polymorphism:
A
The object can change, according to the characteristics.
12
Q
- Inheritance:
A
It is an attribute that is extracted and placed on others
13
Q
- Object:
A
Instance of a class.
14
Q
- Class:
A
Template or model to create an object.
15
Q
- SaaS:
A
Providing software over the internet as a service.
16
Q
AWS:
A
Cloud storage.
17
Q
- GitHub
A
: Allows collaborative logical work.
18
Q
- StartUp
A
: A team of people where an application is developed that will eventually be bought by a large company.
19
Q
Agile methodology:
A
It is a methodology that uses incremental requirements, they are interactive and this helps to carry out the processes.
20
Q
- Traditional methodology:
A
It has a process where if a stage has already passed, the process should not be returned.
21
Q
Difference beetween agile and traditional methodology is that
A
is the times and costs.
22
Q
Software Fails:
A
It’s when reports fail (CHAOS REPORT).
23
Q
Specification:
A
: Details about the functions of the program. Example: In specific language, Java.
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.
25
* Requirements Engineering:
Systematic process that indicates supporting us with some methodology that allows us to create certain software products or generate software artifact components, databases.
26
Elicitation:
Process by which we collect the requirements through interviews, analysis, practices.
27
* Public Elicitation:
Transparent process, where the elicitation bases on the government project are published.
28
* Ethnography:
Uses qualitative research method to systematically describe the culture of different human groups.
29
* FIGMA:
It is used to create prototypes, and so the client can see the project process to give feedback.
30
* Engineering discipline:
The design, analysis, and construction of an artifact for some practical purpose.
31
* Software Engineering:
Is the application of a systematic, disciplined, quantifiable approach "Development, operation, and maintenance of software."
32
* Ambiguity:
It is the quality of having several interpretations, the characteristics that have not been clarified.
33
* Technical Jargon:
This refers to the technical language of engineering.
34
* SRS:
It is the document that is in the middle of user requirements (descriptions), this document is made to document the entire process.
35
* User Req:
It is written in natural language, a specification from the user's perspective. Example: User registration, colors, also being able to log in.
36
* System Req:
It is written in machine language, a specification from the system's perspective. Example: User information is stored in a database.
37
* System management:
Those who maintain the application.
38
* System owners:
Those who invest in the company.
39
* External and Stakeholders:
the competition or indirectly affected.
40
* Use Case:
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.
41
Errors in Software Engineering:
Deviations from the process.
42
* Agile methodologies:
They help reduce time and costs, and these are interactive, while traditional methodologies, do not return to the previous process.
43
* Functional Requirement:
Statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations.
44
* Non-functional Requirement:
Constraints on the services or functions offered by the system such as timing constraints, the development process, standards, etc.
45
* Organizational:
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.
46
* Environmental:
These are specific restrictions on how the system will operate. Example: The system must be available during the working period.
47
Development:
Constraints derived from the development process standards set by the organization. Such as the language or others.
48
* Operational:
Describe constraints derived from how the system should be used on a day-to-day basis. Such as calibrating a pressure artifact.
49
* External Legislative:
These describe guidelines that must be followed to comply with the law. Such as copyright, Spotify, YouTube
50
* External Regulatory:
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
* External Ethical:
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
Difference between legislative and regulatory
* 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
* Security Requirements:
Are specifications based on protecting system data.
54
* Dependability Requirements:
Refers to consistency, error-free. Mounting services in the cloud buy cloud services, have another in case one fails, because they are.
55
Discovery:
Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
56
Classification and Organization:
Groups related requirements and organizes them into coherent clusters. Backlog: Refers to the classification of activities and the schedule and priority.
57
* Prioritization and negotiation:
Prioritizing requirements and resolving requirements conflicts.
58
Specifications:
Requirements are documented and input into the next round of the spiral.
59
Interview:
These are questions to stakeholders to streamline the RE process.
60
Closed interview:
Prepared questions. These are better when there is no experience in the field.
61
* Open Interviews:
There is an opportunity to make software. When stakeholders when end users do not know what they want.
62
Figma:
Visual prototype where the user can see and give feedback.
63
* Project management:
Understanding how to use project management software in a professional environment.
64
* Observations:
Observing a team used by the software manager for tasks and collaborations.
65
* Surprising observation:
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
* Stories and scenarios:
Real-life examples of how a system can be used. A description of how a system may be used for a particular task.
67
Scenario:
A structured form of user story.
68
* Natural language
: It's the way we communicate. Example: The system must have all employees and record new products in inventory.
69
* Structured Natural Language:
It's a way to order requirements using a more formal form. This helps to standardize, words like must, shall, shall not.
70
* Design description language:
Formal systems used to describe and specify software design. UML, use cases.
71
Graphical notations:
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
Mathematical Specifications:
It's a precise and formal way to describe the behavior of a system using mathematical concepts and notations.
73
Guideline for writing requirements:
1. Invent a standard format anduse it for all requirements, 2. Use language in a consistent way shall, should.
3. Use text highlighting to identify key parts of the requirement.
4. Avoid the use of computer jargon.
5. Include an explanation (rationale) of why a requirement is necessary
74
* Problems with natural language
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
* Pre:
The first condition that must be met.
76
Post:
When the pre-condition is met, this is the one that continues.
77
Side effects (if any):
The sensor does not work correctly.
78
* Tabular Specification:
Particularly useful when defining a series of possible alternative courses of action.
79
* Difference Diagram:
It is a diagram where specific characteristics can be made.
80
* System customer:
The one who wants the requirements.
81
Managers:
Make the plan for the system and the development process.
82
System engineers:
Develop the requirements for this program.
83
* System test engineers:
Ensure that documents are validated. If an email was sent but not received correctly.
84
* System maintenance engineers:
What can be managed to make an improvement? Create a new function, where tokens will be made to improve the token.
85
* structure of requirements document: Preface:
Describe its version history, including a justification for creating a new version and a summary of the changes made in each version.
86
* structure of requirements document: Glossary:
This should define the technical terms used in the document. It should not make assumptions about the reader's experience.
87
* structure of requirements document: User requirements definition:
Diagrams are placed here so that all readers of this document understand it. System requirements must be described.
88
* structure of requirements document: System architecture:
A high-level overview of the anticipated architecture of the system, showing the distribution of functions among the system's modules.
89
* structure of requirements document: System requirements specification:
Details about the project, about the requirements.
90
structure of requirements document
System models: A prototype Sigma model is used here (Figma).
91
* structure of requirements document: System evolution:
Any anticipated changes due to hardware evolution. These are requirements that make an assumption about what the hardware should have.
92
structure of requirements document: Appendix:
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
* structure of requirements document: Index:
Separate by sections alphabetically.
94
* Verification:
If what is being done is being done correctly. Part of development.
95
* Validation:
Are we building the final project correctly? Part of the client.
96
* Validity:
Does the system provide functions that best meet the needs of the client?
97
* Consistency:
There should be no discrepancies in the requirements given, they should be coherent and not contradictory.
98
* Completeness:
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
* Realism:
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
* Verifiability:
A verifiable requirement is one that provides specific characteristics and what is asked for.
101
* Requirements review "TEMPLATE": Preparation:
Everyone will have a copy of the requirements.
102
* Requirements review "TEMPLATE": Individual review:
Each member reviews the criteria individually.
103
* Requirements review "TEMPLATE": Review meeting:
Ambiguities, inconsistencies are identified.
104
* Requirements review "TEMPLATE": Problem log:
Analysis of problems, questions.
105
* Requirements review "TEMPLATE": Problem resolution:
Responsibilities are assigned and problems are correctly identified.
106
Prototypes:
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
* Process flow prototype:
FIGMA, interactions. Visual paradigm. Report or output prototype.
108
Review checks: Verifiability:
Is the requirement realistically testable?
109
* Review checks: Comprehensibility:
Was the requirement understood well?
110
* Review checks: Traceability:
Is the origin of the requirement clearly indicated?
111
* Review checks: Adaptability:
Can the requirements be changed without a major impact on other requirements?
112
* Review checks: User difference in client:
When you enter Amazon, you have an account, you are a user, but if you are a client, you buy.
113
* Review checks: Traceability:
Estimate the time and costs based on changes or process, or investments.
114
Difference between traceability, verifiability, and usability:
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
Requirements change: Business Needs:
Customer demands.
116
* Requirements change: Stakeholders Feedback:
Developers understand through use cases, a change could be to automate. Proactivity.
117
* Requirements change: Project scope clarification:
Better understanding of project objectives and limitations.
118
Requirements change: Identification of requirements:
Each requirement must be uniquely identified so that it can be cross-referenced with other requirements.
119
* Requirements change: Change management process:
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
Requirements change: Traceability policies:
These policies define the relationships between each requirement and between the requirements and the system design that must be recorded.
121
Requirements change: Tool support:
The tools that can be used range from specialized requirements management systems to spreadsheets and simple database systems.
122
Requirements change: Analysis of problems and specification of changes:
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
* Requirements change: Analysis of changes and costs:
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
Requirements change: Implementation of changes:
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
