Brainscape's Knowledge GenomeTM

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


See full index

Software Engineering > Lecture Notes 2 > Flashcards

Lecture Notes 2 Flashcards

1
Q

What are the 4 phases of software engineering?

A

REQUIREMENTS ANALYSIS
SYSTEM DESIGN
VALIDATION
EVOLUTION

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

The task communicating with customers and users to determine what
their requirements are. This is sometimes called Requirements Gathering.

A

Eliciting Requirements

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

Determining whether the stated requirements are unclear, incomplete,
ambiguous, or contradictory, and then resolved these issues.

A

Analyzing Requirements

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

Requirements might be documented in various forms, such as natural-
language documents, use cases, user stories, or process specifications.

A

Recording Requirements

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

High-level abstract requirements written as statements, in a natural language
plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.

A

User Requirements

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

A user shall be able to search the
appointments lists for all clinics.

A

Search Appointment

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

Two kinds of requirements based on the intended purpose and target
audience:

A

User Requirements
System Requirements

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

detailed description of what the system should do including the software system’s
functions, services, and operational constraints.

A

System Requirements-

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

REQUIREMENT Analysis includes three types of activity:

A

Eliciting Requirements
Analyzing Requirements
Recording Requirements

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

The study considers whether the proposed system
will be cost-effective from a business point of view.

A

Feasibility Study

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

An estimate of whether the identified user needs may be satisfied using current software and hardware technologies.

A

Feasibility Study

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

product features or functions that developers must
implement to enable users to accomplish their tasks

A

Functional Requirements

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

describe what the system should do.

A

Functional Requirements

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

what are the 2 examples of Functional Requirements?

A

Search Appointment
Generate Reports

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

The system shall generate each day, for
each clinic, a list of patients who are expected to attend
appointments that day.

A

Generate Reports

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

The system allows the user to create account.

A

Create Account

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

The system allows the user to search books based on title,
publication, etc. and find their location in the library.

A

Search

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

The system allows the user to view the list of books available

A

View

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

The system can print/generate reports such as list of books, list of
borrowers, etc.

A

Generate Reports

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q
  • Specify the characteristics of the system as a whole.
A

Non- Functional Requirements

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

a set of specifications that describe the system’s
operational capabilities and constraints and attempt to
improve its functionality.

A

Non- Functional Requirements

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

More often more critical than individual functional
requirements.

A

Non- Functional Requirements

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

EXAMPLES OF Non- Functional Requirements

A

Reliability, response time

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

If NFRs not addressed properly, the results can include:

  • Users, clients, and developers are unsatisfied.
  • Inconsistent software.
  • Time and cost overrun to fix the software which was
    prepared without keeping NFRs in mind.
A

TRUE

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

The user-interface should be simple enough for everyone to

understand the system.

A

Usability

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

The data stored about books and the fines calculated

should be correct, consistent, and reliable.

A

Accuracy

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

The software should be easily maintainable and adding new
features and making changes to the software must be as

simple as possible.

A

Maintainability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q
  • It is the process of defining the elements of a system such as the

architecture, modules and components, the different interfaces of those

components and the data that goes through that system.

A

SYSTEM DESIGN

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

Systems design implies a systematic approach to the design of a system.

A

SYSTEM DESIGN

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q
  • It is meant to satisfy specific needs and requirements of a business or

organization through the engineering of a coherent and well-running

system

A

SYSTEM DESIGN

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

It may take a bottom-up or top-down approach, but

either way the process is systematic wherein it takes into

account all related variables of the system that needs to

be created—from the architecture to the required

hardware and software, right down to the data and how

it travels and transforms throughout its travel through

the system.

A

SYSTEM DESIGN

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

4 types of SYSTEM DESIGN

A

Architectural Design
Interface Design
Component Design
Database Design

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

Where you identify the overall structure of the system

A

Architectural Design

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

Where you define the interfaces between system components.

A

Interface Design

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

Where you design the system data structures and how these are to
be presented in a database.

A

Database Design

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

Also called “Software Validation and Verification”

A

Validation

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

refers to the process of determining whether or not the products of
a given phase of a software development process fulfill the process
established during the previous phase.

A

Validation

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

Where you take each system component and design how it will
operate.

A

Component Design

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

refers to the process of evaluating software at the end of its
development to ensure that it is free from failures and complies with its
requirements.

A

Validation

19
Q

is defined as an incorrect product behavior.

A

failure

19
Q

are we building the product right

A

VERIFICATION

20
Q

Software V&V Approaches

A

Software Technical Reviews
Software Testing
Proof of Correctness
Simulation and Prototyping
Requirements Tracing

20
Q

checks if the product functions are what the customer really wants

A

Validation

20
Q
  • are we building the right product?
A

Validation

21
Q

-Each component is tested independently without the other sub systems.

A

Development Testing

21
Q

3 STAGES IN THE TESTING PROCESS

A
  1. Development Testing
  2. System Testing
  3. Acceptance Testing/Alpha Testing
21
Q

checks if the products meet the requirements definition

A

VERIFICATION

21
Q

-Components may be simple entities such as functions, objects, or classes

A

Development Testing

22
Q

the test team knows exactly how the software behaves

A

Alpha testing

23
Q

-Concerned with finding errors that result from unanticipated interactions
between components and component interface problems.

A

System Testing

23
Q

-Concerned with showing that the system meets its functional and non-
functional requirements

A

System Testing

23
Q

is the final internal acceptance testing for your software.

A

Alpha testing

24
Q

May reveal errors and omissions in system requirements definitions

A

Acceptance Testing/Alpha Testing

25
Q

it ensures that your software is bug-free, stable, and functioning as expected

A

Alpha testing

25
Q

it aims to test every single user flow end to end

A

Alpha testing

25
Q

PEOPLE IN THE DEVELOPMENT

A
  1. Development Team
  2. End – users
25
Q

The process of developing a software product using software engineering
principles and methods is referred to as software evolution.

A

evolution

26
Q

a white boxQ testing

A

Alpha testing

27
Q

Understands the system

A

Analyst

27
Q

starts from the requirement gathering process.

A

evolution

27
Q

The process of developing a software product using software engineering
principles and methods is referred to as _____ evolution.

A

software evolution

27
Q

evolution processes include:

A

Change Request
Impact Analysis
Release Planning
System Update
System Release

27
Q

This includes the initial development of software and its maintenance and
updates, till desired software product is developed, which satisfies the expected requirements.

A

evolution

28
Q

After which developers create a prototype and show it to the users for their feedback at the early stage of software development.

A

evolution

28
Q

responsible in making the software

A
  1. Development Team
29
Q

The users suggest changes, on which several consecutive updates and maintenance keep on changing.

A

evolution

30
Q

Build/create the software.

A
  1. Development Team
31
Q

Defines the software architecture, components, modules, interfaces.

A

System Designer

32
Q

write codes of the system in a specific programming language

A

Programmer

32
Q
  • Directly Involved in the system
A
  • Operational Job
  • Supervisor
  • Executive
32
Q

reviews faults and errors of the system

A

Tester

32
Q

Development Team

A

Analyst

System Designer

Programmer

Tester

32
Q
  • if it is fit for use
A

Software Quality

32
Q

used/ utilize the system

A
  1. End – users
32
Q

part of quality management focused on
providing confidence that quality requirements
will be fulfilled.(ISO 9000)

A
  • Quality Assurance (QA)
33
Q
  • Performs the daily task/operation of the organization
  • Concern: How does it work?
A
  • Operational Job
33
Q
  • Performs supervisory job
  • Concern: Physical Interface & Performance
A
  • Supervisor
33
Q

Indirectly Involved in the system

A
  • Quality Assurance (QA)
33
Q
  • errors and faults found during the SE process
A
  • dev’t team
34
Q
  • Provides finances and initiatives
  • Outputs/results
  • Concern: global view of the system
A
  • Executive
34
Q

groups and external organizations which set
standards to be followed

A
  • Quality Assurance (QA)
34
Q

ability to evolved and adopt change over time.

A

Maintainability

34
Q
  • is the total characteristics of an entity to satisfy stated and implied needs .
A

Quality

34
Q

Three Perspectives of Software qUALITY

A

Quality of the Product
Quality of the Process
Quality in the context of System Environment

35
Q

capability to use resources efficiently.

A

Efficiency

35
Q
  • in terms of products/services provided by the business in which the software is used.
A

Quality in the Context of business Environment

35
Q
  • relative to the person analyzing quality.
A

Quality of the Product

35
Q
  • failures of task are avoided
  • system development process is improved
A

Quality of the Process

35
Q
  • if it gives what they want and when they want it, all the time.
A

*end-users

36
Q

ensures that the software product complies with user requirements and standards.

A

SOFTWARE QUALITY ASSURANCE

36
Q
  • software adds value to the business
A

Quality in the Context of business Environment

36
Q

Characteristics of a well-engineered Software

A
  • Usability
  • Portability
  • Reusability
  • Maintainability
  • Dependability
  • Efficiency
36
Q

ease with which the user communicates with the system

A

Usability

36
Q

capability of the software to execute in different platforms.

A

Portability

37
Q

ability to transfer from one system to another

A

Reusability

37
Q

characteristics of the software to be reliable, secure, and safe.

A

Dependability

37
Q
  1. Respect your teammates, even when you disagree or they are
    wrong.
  2. Accept group decision even when you disagree.
  3. You must include all group members in decisions.
  4. You should do your best to contribute to your team.
  5. Email or text is not a good medium for resolving problems.
A

INTERPERSONAL COMMUNICATION RULES

Software Engineering (8 decks)

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