Brainscape's Knowledge GenomeTM

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


See full index

Spring 2018 > csci 387 quiz 2 > Flashcards

csci 387 quiz 2 Flashcards

1
Q

requirements engineering

A

the process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed

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

system requirements

A

the descriptions of the system services and constraints that are generated during the RE process / structured document defining what should be implemented

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

requirement

A

may range from a high-level abstract statement of a service or system constraint to a detailed mathematical functional specification

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

types of requirements

A

user and system

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

user requirements

A

statements in natural language with diagrams; written for customers

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

system stakeholders

A

any person or organization affected by the system in some way and so who has legitimate interest

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

types of system stakeholders

A

end users, system managers, system owners, external stakeholders

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

functional requirement

A

services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations; may state what the system should not do; depends on the type of software

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

nonfunctional requirement

A

constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.; often apply to the system as a whole rather than individual features or services

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

domain requirement

A

constraints on the system from the domain of operation

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

problems arise when functional requirements are…

A

not precisely stated (may be interpreted in different ways by developers and users)

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

requirements should be both

A

complete and consistent (but this is impossible)

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

complete

A

include description of all facilities required

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

consistent

A

no conflicts or contradictions in description

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

a system may be useless without what kind of requirements and why?

A

nonfunctional - may affect overall architecture; a single NFR may generate functional requirements that define requirement system services

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

non-functional classifications

A

product requirements, organizational requirements, external requirements

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

product requirements

A

delivered product must behave in a particular way (e.g. speed, reliability)

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

organizational requirements

A

organizational policies, procedures (e.g. standards, implementation)

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

external requirements

A

arise from external factors (e.g. interoperability, legislative)

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

goal

A

a general intention of the user (such as ease of use); helpful to developers because conveys the intentions of users

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

metrics for specifying nonfunctional requirements

A

speed, size, ease of use, reliability, robustness, portability

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

generic activities in RE process

A

elicitation, analysis, validation, management

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

stages of requirements elicitation and analysis

A

discovery, classification and organization, prioritization and negotiation, specification

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

problems with requirements elicitation and analysis

A

stakeholders don’t know what they really want, express requirements in their own terms; different stakeholders may have conflicting requirements; organizational and political factors may influence system requirements; requirements change during analysis process

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

discovery

A

interacting with stakeholders to discover their requirements; also discover domain requirements

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

classification and organization

A

group related requirements and organize into cohesive clusters

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

prioritization and negotiation

A

prioritize requirements and resolve requirement conflicts

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

specification

A

document requirements and input into next round of spiral

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

interviewing

A

can be formal or informal; with stakeholders; part of RE process

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

types of interviewing

A

closed (predetermined questions) and open (explore various issues)

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

effective interviewing

A

be open-minded, prompt interviewee to get discussions going

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

problems with interviews

A

language gap between application specialists and requirements engineer; not good for understanding domain requirements

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

ethnography

A

work is usually richer and more complex than suggested by simple system models; effective for understanding existing processes but cannot identify new features

34
Q

focused ethnography combines

A

ethnography with prototyping

35
Q

stories

A

real-life examples of how a system can be used for a particular task; stakeholders can relate and comment

36
Q

scenarios

A

a structured form of a user story

37
Q

scenarios should include

A 
description of starting situation
description of normal flow of events
description of what can go wrong
information about concurrent events
description of state where scenario finishes
38
Q

requirements specification

A

the process of writing down user and system requirements in a requirements document

39
Q

user requirements have to be

A

understandable by end-users and customers with no technical background

40
Q

ways of wring requirements

A 
natural language
structured natural language
design description languages
graphical notations
mathematical specifications
41
Q

requirements and ? are inseparable

A

design

42
Q

use cases

A

a kind of scenario included in UML; identify actors in an interaction and describe the interaction; a set of use cases should describe all possible interactions with the system

43
Q

software requirements document

A

official statement of what is required of system developers; WHAT system should do rather than how

44
Q

structure of requirements document

A

preface, intro, glossary, user requirements definition, system architecture, system requirements specification, system models, system evolution, appendices, index

45
Q

requirements validation

A

demonstrating that the requirements define the system the customer really wants; important because of the high cost of requirements error

46
Q

requirements checking

A

validity, consistency, completeness, realism, verifiability

47
Q

requirements validation techniques

A

requirements reviews (systematic manual analysis of the requirements; involves client and contractor), prototyping, test-case generation

48
Q

review checks

A

verifiability, comprehensibility, traceability, adaptability

49
Q

requirements evolution

A

initial understanding of problem > initial requirements > changed understanding of problem > changes requirements

50
Q

requirements management

A

the process of managing changing requirements; keep track of requirements and maintain links between dependent requirements

51
Q

requirements management planning

A

identification, change management process, traceability policies, tool support

52
Q

deciding if a requirements change should be accepted

A

problem analysis and change specification, change analysis and costing, change implementation

53
Q

database entity

A

any object in the system we want to model and store information about; usually recognizable concepts, either concrete or abstract (person, place, thing, etc.)

54
Q

database attribute

A

properties or features of an entity (can be single or a set)

55
Q

database tuple

A

members of an entity (a set - order doesn’t matter)

56
Q

in a database, entity is ?, attributes are ?, and tuples are ?

A

entity is the table
attributes are the columns
tuples are the rows

57
Q

primary key

A

special attribute of an entity designated to uniquely identify all tuples (unique for each tuple, cannot be null, generally undefined; try to generate automatically)

58
Q

foreign key

A

an attribute (or collection of attributes) in one entity that uniquely identifies a tuple of another entity or the same entity (refers to the primary key or a unique key from a second table; can connect to the same table)

59
Q

types of database relationships

A

one to one, one to many, many to many, self referencing

60
Q

CRUD operations

A

Create, Read (select-from-where), Update, Delete

61
Q

web pages are written in

A

HTML

62
Q

web server

A

a program running on a computer that delivers web pages in response to requests

63
Q

do as much as possible on the ? side because ?

A

client; communication b/w client and server is costly

64
Q

HTML stands for

A

Hypertext Markup Language

65
Q

HTML (is/is not) a programming language

A

is not

66
Q

HTML describes

A

content and structure

67
Q

HTML is made up of building blocks called

A

elements

68
Q

CSS stands for

A

Cascading Style Strucure

69
Q

CSS describes the

A

appearance and layout of a web page

70
Q

HTML + CSS yields a webpage that

A

doesn’t do anything

71
Q

JavaScript

A

a programming language; no connection to java; no other options for web pages

72
Q

HTML can embed JavaScript files with what tag

A
73
Q

JavaScript has no ? and no ?

A

main method and no compilation (runs top to bottom)

74
Q

const (cannot/can) be reassigned

A

cannot

75
Q

don’t use ?, use let and const as much as possible

A

var

76
Q

== and != are essentially broken in JS so use

A

=== and !==

77
Q

event-driven programming

A

executes after some event fires (function known as event handler)

78
Q

DOM

A

Document Object Model; tree of nodes corresponding to HTML elements on page

79
Q

defer attribute will cause JavaScript to

A

execute after DOM

80
Q

either use ? or ? to cause JavaScript to execute after the DOM

A

defer attribute or put the tag at the bottom

Spring 2018 (23 decks)

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