Brainscape's Knowledge GenomeTM

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


See full index

Software Design > Software Design Lesson 2-4 > Flashcards

Software Design Lesson 2-4 Flashcards

1
Q

contains a description of what the system will do without
describing how it will do it.

A

Requirements

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

Without _______
– Developers do not know what to build
– Customers do not know what to expect
– What to validate

A

well-written document

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

Crucial Process Steps of requirement engineering

A
  • Problem Statement
  • Requirements Elicitation
  • Requirements Analysis
  • Requirements Documentation
  • Requirements Review
  • SRS
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

the disciplined application of
proven principles, methods, tools, and notations to describe a
proposed system’s intended behavior and its associated
constraints.

A

Requirement Engineering

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

It may act as a contract between developer and customer.

A

SRS

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

Types of Requirements

A
  • Known Requirements
  • Unknown Requirements
  • Undreamed Requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Anyone who should have some direct or indirect
influence on the system requirements.

A

Stakeholder

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

It describes what the software has to
do. They are often called product features.

A

Functional requirements

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

These are mostly quality requirements. That stipulates how well the software does,
what it has to do.

A

Non-Functional requirements

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

These are written for the users and include a functional and non-functional requirement

A

User requirements

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

Derived from User requirements

A

System Requirement

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

The user system requirements are the parts of what document?

A

software requirement and specification (SRS) document

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

TYPES OF INTERFACES

A
  • Procedural interfaces (also called Application Programming Interfaces (APIs)).
  • Data structures
  • Representation of data.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

“evaluation or analysis of the potential impact of a
proposed project or program.”

A

Purpose of feasibility study

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

They introduced Use Case approach for elicitation & modeling

A

Ivar Jacobson & others

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

It is a structured outline or template for the description of user requirements modeled in a structured language like English.

A

Use Cases

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

These are unstructured descriptions of user requirements.

A

Use case Scenarios

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

It lies outside the system model, but interacts with it in some way

A

An actor or external agent

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

He is the one having a goal requiring the assistance of the system.

A

Primary Actor

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

He is the one from which System needs assistance.

A

Secondary Actor

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

It describes the sequence of interactions between actors and the system necessary to deliver the services that satisfies the goal.

A

Use Case

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

Use Case captures who (_____) does what (______) with the system, for what purpose (_____), without dealing with system internals.

A
  1. actor
  2. interaction
  3. goal
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

conditions that need to be satisfied for the use
case to perform

A

Pre conditions

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

Define the different states in which we expect the system to be in, after the use case executes.

A

Post Conditions

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

List the primary events that will occur when this use case is executed.

A

Basic Flow

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

Any Subsidiary events that can occur in the use case should be separately listed.

A

Alternative Flows

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

Requirements Analysis Steps

A
  • Draw the context Diagram
  • Develop prototype (optional)
  • Model the Requirements
  • Finalize the Requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

It show the flow of data through the system.

A

Data Flow Diagrams

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

A source of system inputs or sink of system outputs

A

Source or sink

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

A repository of data, the arrowhead indicate net input and net outputs to store

A

Data Store

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

It called fundamental system model or context model represents entire software element as a single bubble with input and output data indicating by incoming & outgoing arrows.

A

Level 0 DFD

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

These are simply repositories to store information about all data items defined in DFD.

A

Data Dictionaries

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

x= a+b

A

x consists of data element a & b

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

x={a/b}

A

x consists of either a or b

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

x=(a)

A

x consists of an optional data element a

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

x= y{a}

A

x consists of y or more occurrences

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

x={a}z

A

x consists of z or fewer occurrences of a

38
Q

x=y{a}z

A

x consists of between y & z occurrences of a{

39
Q

It is a detailed logical representation of data for an organization and uses three main constructs.

A

Entity-Relationship Diagrams

40
Q

basic modeling notation contains three main
constructs

A
  • data entities
  • relationships
  • attributes
41
Q

the description of all entities to which a common definition and common relationships and attributes apply

A

Entity Type

42
Q

These are represented by diamond notation in a ER diagram.

A

Relationships

43
Q

Degree of relationships

A
  • Unary
  • Binary
  • Ternary
44
Q

an attribute or combination of attributes that
uniquely identifies each instance of an entity type.

A

candidate key

45
Q

What is SRD?

A

Structured requirements definition

46
Q

Characteristics of a good SRS

A

✓ Correct
✓ Unambiguous
✓ Complete
✓ Consistent
✓ Ranked for important and/or stability
✓ Verifiable
✓ Modifiable
✓ Traceable

47
Q

An SRS is correct if and only if every

A

every requirement stated therein is one that the software shall meet.

48
Q

An SRS is unambiguous if and only if

A

every requirement stated therein has only one interpretation.

49
Q

An SRS is complete if and only if

A

it includes the following elements
(i) All significant requirements, whether related to functionality, performance, design constraints, attributes or external interfaces. (ii) Responses to both valid & invalid inputs.
(iii)Full Label and references to all figures, tables and diagrams
in the SRS and definition of all terms and units of measure.

50
Q

An SRS is consistent if and only if

A

no subset of individual requirements described in it conflict.

51
Q

An SRS is verifiable, if and only if

A

every requirement stated therein is verifiable.

52
Q

An SRS is modifiable, if and only if,

A

its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining structure and style.

53
Q

An SRS is traceable, if

A

the origin of each of the requirements is clear and if it facilitates the referencing of each requirement in future development or enhancementdocumentation.

54
Q

Process of understanding and controlling changes to system requirements.

A

Prototyping

55
Q

They are core requirements & are related to main activity of the organization

A

Enduring requirements

56
Q

likely to change during the software development lifer cycle or after delivery of the product

A

Volatile requirements

57
Q
  • Product is constructed without specifications or any attempt at
    design
  • Adhoc approach and not well defined
  • Simple two phase model
A

Build & Fix Model

58
Q

Suitable for small programming exercises of 100 or 200 lines

A

Build & Fix Model

59
Q

This model is easy to understand and reinforces the notion of “define before design” and “design before code”.

A

Waterfall Model

60
Q

The model expects complete & accurate requirements early in the process, which is unrealistic

A

Waterfall Model

61
Q

After every cycle a useable product is given to the customer.

A

Incremental Process Models

62
Q

This model has the same phases as the waterfall model, but with fewer restrictions. Generally the phases occur in the same order as in the waterfall model, but they may be conducted in several cycles. Useable product is released at the end of the each cycle, with each release providing additional functionality.

A

Iterative Enhancement Model

63
Q
  • Developed by IBM in 1980
  • User participation is essential
  • Build a rapid prototype
  • Give it to user for evaluation & obtain feedback
  • Prototype is refined
A

The Rapid Application Development (RAD) Model

64
Q

This model differs from iterative enhancement model in the sense that this does not require a useable product at the end of each cycle. In evolutionary development, requirements are implemented by category rather than by priority.

A

Evolutionary Process Models

65
Q

This model is useful for projects using new technology that is not
well understood. This is also used for complex projects where all
functionality must be delivered at one time, but the requirements
are unstable or not well understood at the beginning.

A

Evolutionary Process Models

66
Q
  • Linear model
  • “Rapid”
A

Prototyping
Model

67
Q

Barry Boehm recognized this and tired to incorporate the “project
risk” factor into a life cycle model

A

Spiral Model

68
Q

The radial dimension of the model represents the cumulative costs.
Each path around the spiral is indicative of increased costs.

A

Spiral Model

69
Q

each phase is completed with a review by the people concerned with the project (designers and programmers)

A

Spiral Model

70
Q
  • Developed by I.Jacobson, G.Booch and J.Rumbaugh.
  • Software engineering process with the goal of producing good
    quality maintainable software within specified time and budget.
A

The Unified Process

71
Q

The Unified Process Model was developed through a series of fixed length mini projects called what?

A

iterations

72
Q

defines scope of the project.

A

Inception

73
Q

the objectives are translated in design &
architecture documents.

A

Construction

74
Q

involves many activities like delivering, training,
supporting, and maintaining the product.

A

Transition

75
Q

2 TYPES OF DATA DICTIONARY

A
  1. Yourdon
  2. Warnier-Orr
76
Q

a group of smaller structures and elements

A

Data structures

77
Q

used to represent the data structure.

A

algebraic notation

78
Q

defined with descriptive information, length and type of
data information, validation criteria, and default values

A

Data elements

79
Q

This is an optional entry that allows the analyst to build
automated data dictionary entries

A

Element ID

80
Q

A graphic picture of a logical system from the viewpoint of its
data

A

DATA FLOW DIAGRAM

81
Q

a group of interrelated procedures used for a business
function, with an identifiable boundary, working together for some purpose

A

System

82
Q

separation of a whole into its component parts

A

Analysis

83
Q

to create, fashion, execute, or construct according to plan

A

Design

84
Q

show how the current system flows

A

PHYSICAL DATA FLOW DIAGRAMS

85
Q

show the data flow, structure, and requirements of a new system

A

LOGICAL DATA FLOW DIAGRAMS

86
Q

2 TYPES OF DATA FLOW DIAGRAM

A
  • DeMarco & Yourdon
  • Gane & Sarson
87
Q

Either a) receive info from
system, b) trigger system into
motion, or c) provide new
information to system

A

Entity

88
Q

are the activities (manual and
automated) that transform the
inputs, transport data from
process to process, stores the
data, and produce the outputs
of a system.

A

Process

89
Q

is the resting place of the data
in a system.

A

Data Store

90
Q

processes transform the data in data store

A

store, add, delete, update

91
Q

Is the data in motion. Data can move from the outside (source) into a process.

A

Data Flow

92
Q

7 steps in CREATING DFD

A
  1. Create a preliminary Context Diagram
  2. Identify Use Cases, i.e. the ways in which users most commonly use the system
  3. Create DFD fragments for each use case
  4. Create a Level 0 diagram from fragments
  5. Decompose to Level 1,2,…
  6. Go to step 1 and revise as necessary
  7. Validate DFDs with users.

Software Design (1 decks)

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