Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

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
discovery
interacting with stakeholders to discover their requirements; also discover domain requirements
26
classification and organization
group related requirements and organize into cohesive clusters
27
prioritization and negotiation
prioritize requirements and resolve requirement conflicts
28
specification
document requirements and input into next round of spiral
29
interviewing
can be formal or informal; with stakeholders; part of RE process
30
types of interviewing
closed (predetermined questions) and open (explore various issues)
31
effective interviewing
be open-minded, prompt interviewee to get discussions going
32
problems with interviews
language gap between application specialists and requirements engineer; not good for understanding domain requirements
33
ethnography
work is usually richer and more complex than suggested by simple system models; effective for understanding existing processes but cannot identify new features
34
focused ethnography combines
ethnography with prototyping
35
stories
real-life examples of how a system can be used for a particular task; stakeholders can relate and comment
36
scenarios
a structured form of a user story
37
scenarios should include
``` 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
requirements specification
the process of writing down user and system requirements in a requirements document
39
user requirements have to be
understandable by end-users and customers with no technical background
40
ways of wring requirements
``` natural language structured natural language design description languages graphical notations mathematical specifications ```
41
requirements and ? are inseparable
design
42
use cases
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
software requirements document
official statement of what is required of system developers; WHAT system should do rather than how
44
structure of requirements document
preface, intro, glossary, user requirements definition, system architecture, system requirements specification, system models, system evolution, appendices, index
45
requirements validation
demonstrating that the requirements define the system the customer really wants; important because of the high cost of requirements error
46
requirements checking
validity, consistency, completeness, realism, verifiability
47
requirements validation techniques
requirements reviews (systematic manual analysis of the requirements; involves client and contractor), prototyping, test-case generation
48
review checks
verifiability, comprehensibility, traceability, adaptability
49
requirements evolution
initial understanding of problem > initial requirements > changed understanding of problem > changes requirements
50
requirements management
the process of managing changing requirements; keep track of requirements and maintain links between dependent requirements
51
requirements management planning
identification, change management process, traceability policies, tool support
52
deciding if a requirements change should be accepted
problem analysis and change specification, change analysis and costing, change implementation
53
database entity
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
database attribute
properties or features of an entity (can be single or a set)
55
database tuple
members of an entity (a set - order doesn't matter)
56
in a database, entity is ?, attributes are ?, and tuples are ?
entity is the table attributes are the columns tuples are the rows
57
primary key
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
foreign key
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
types of database relationships
one to one, one to many, many to many, self referencing
60
CRUD operations
Create, Read (select-from-where), Update, Delete
61
web pages are written in
HTML
62
web server
a program running on a computer that delivers web pages in response to requests
63
do as much as possible on the ? side because ?
client; communication b/w client and server is costly
64
HTML stands for
Hypertext Markup Language
65
HTML (is/is not) a programming language
is not
66
HTML describes
content and structure
67
HTML is made up of building blocks called
elements
68
CSS stands for
Cascading Style Strucure
69
CSS describes the
appearance and layout of a web page
70
HTML + CSS yields a webpage that
doesn't do anything
71
JavaScript
a programming language; no connection to java; no other options for web pages
72
HTML can embed JavaScript files with what tag
73
JavaScript has no ? and no ?
main method and no compilation (runs top to bottom)
74
const (cannot/can) be reassigned
cannot
75
don't use ?, use let and const as much as possible
var
76
== and != are essentially broken in JS so use
=== and !==
77
event-driven programming
executes after some event fires (function known as event handler)
78
DOM
Document Object Model; tree of nodes corresponding to HTML elements on page
79
defer attribute will cause JavaScript to
execute after DOM
80
either use ? or ? to cause JavaScript to execute after the DOM
defer attribute or put the tag at the bottom

Spring 2018 (23 decks)

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