COE 691 FINAL

Study online at https://quizlet.com/_cv0c7p

1. the behaviour of an entity is not only a direct consequence of its inputs

but it also depends on _______________: its preceding state
2. state machine diagram is traditionally called an: automata
3. state machine diagrams show..: -the different states of an entity
- how an entity responds to various events
4. state machine diagrams model...: the dynamic nature of a system
5. state machine diagrams typically are used to describe...: the state depen-
dent behaviour for an object
6. T/F an object responds differently to the same event depending on what
state it is in: true
7. state machine diagrams are usually applied to...: objects but can be applied
to any element that has behaviour to other entities such as actors, use case,
methods, subsystems
8. state machine diagrams are usually used in conjunction with...: interaction
diagrams
9. objects have ...: behaviours and states
10. the state of an object depends on ...: its current activity or condition
11. state machine diagram is what type of graph?: directed graph where the
nodes are states and edges are transitions
12. the most important purpose of a state machine diagram is to...: model
lifetime of an object from creation to termination
13. WHEN? state machine diagrams are good at describing ....: the behaviour
of an object across several use cases
14. you should only use state diagrams: for those classes that show interesting
behaviour, regularly the main classes of the system
15. WHY? state machine diagrams provide hints on: which attributes are nec-
essary for a given class
16. a state is ...: an abstraction of the attribute values and links of an object. set
of values are grouped together into a state according to properties that affect the
gross behaviour of the object
-round cornered rectangle
17. T/F a state is a condition of being at a certain time: true
18. Origin state: state of an object before transition
1 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
19. destination state: state to which the object moves after the transition
20. a state can have ....: actions
21. an action is a _______ execution: atomic
22. 4 triggers for actions:: on entry, on exit, do, on event
23. characteristics of states: - state occupies an interval of time
- state is often associated with abstraction of attribute values of entity satisfying
some conditions
- entity changes its state not only as direct consequence of current input but it is
also dependent on some past history of its inputs
24. transitions may have..: trigger, a guard and an effect
- lines w/ arrowheads
25. transitions typically take place...: in response to an event
26. trigger: is the cause of a transition
27. examples of a trigger(4): signal, event, change in some condition, passage
of time
28. guard: a boolean condition that may optionally be present on a transition
29. T/F a guard must be true in order for the the trigger to cause the transi-
tion: true
30. effect: action invoked directly on the object that owns state as result of transi-
tion
31. event: significant occurrence that has a location in time and space and can
trigger a state transition
32. types of events: call event, signal event, change event, time event
33. call event: occurs when a method or operation in an object is invoked
34. signal event: occurs when an object sends a signal to another object
35. change event: occurs when a boolean condition is changed
- labels are preceded by keyword when
36. time event: occurs when a time limit has reached
- labels are preceded by keyword after
37. constraint: a boolean expression on attributes of the actual object
38. when object is created it enters the...: initial state
39. T/F you can have more that one initial state: false, there should only be one

2 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
40. final state indicates ...: the end of life for an object
41. T/F a final state is mandatory: false, it is optional
42. T/F more than one final state may exist: true
43. steps to create a state machine diagram: 1. define states
2. describe states
3. define transitions
4. define events that trigger transitions
5. define constraints on transitions(guards)
44. self transitions: A state can have a transition that returns to itself.
• This is most useful when an effect is associated with the transition.
45. compound state: state machine may include substate diagrams
46. concurrent regions: state may be divided into regions containing substates
that exist and execute concurrently
47. choice pseudo state: choice dynamic conditional branch
48. history states: used to remember previous state of an state machine when it
was interrupted
- History state symbol, should resume where it last left-off
49. inheritance: mechanism allows to re-define behaviours of a superclass
- every state of a superclass object is also a valid state of the subclass object
50. T/F the state diagram of a superclass can be inherited into the state
diagram of a subclass: true
51. risk: probability of incurring some net loss while pursuing a goal
52. positive risk: - usually called an opportunity
- ex: financial investment
- net gain or loss
53. reducible risk: One which is predictable or within our control
54. irreducible risks: - Unpredictable
we know the risks can occur but have no basis open which to estimate their
probability of occurrence
- Beyond our control
may be unprecedented or exceptionally unpredictable
55. risk management: - systematic approach to reducing the harm due to risks
- making a project less vulnerable to challenge or failure (e.g., cost or schedule

3 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
overruns, scope decrease, quality reduction)
- resulting product more robust
56. types of risks: known, unknown, unknowable
57. known risks: risks that can be uncovered after careful evaluation of the project
plan
58. predictable risks: Risks that can be extrapolated from past projects.
59. unpredictable risks: joker risks that are hard to predict
60. unknowable risks: - Outside the scope of historical or probabilistic models for
the project
- Beyond the scope of risk management
crisis or disaster management
61. entity relationship modeling: - models the data aspects of a system and how
they relate to one another
62. weak entity: entity that is dependant on another
63. key attributes: underlined
64. T/F an attribute can be multivalued: true
65. relationships: - describe how entities interact
- labeled using verbs
- may be recursive
66. cardinality:

67. modality: whether or not an instance of one entity can exist without a related
instance with the other entity
68. not null: an instance in the related entity must exist for an instance in another
entity
69. null: no instance in the related entity is necessary in another entity to be valid
70. business rules: Constraints followed when the system is in operation

4 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
71. referential integrity: property of data which, when satisfied, requires every
value of one attribute(column) of a relation (table)to exist as a value of another
attribute in a different relation(table)
72. T/F every foreign key value exists as a primary key value: true
73. goal: representation of stakeholder objectives
( rounded rectangle)
74. goal model: hierarchical arrangement of goals
- relationship btwn goals (system vs environment)
- useful in earlier phases
- large goals --> small goals
75. functional goals: hard goals- function system will perform
76. non functional goals: soft goals- desired system qualities
77. why use goal models?: -provide rationale for requirements
- identify stable information in system objectives
- guide requirements elaboration/ elicitation
- visual of relationships
78. when to use goal model?: early in requirements engineering process
79. goal model notation types: - i*, GRL
- KAOS
- UML use case
80. i* two kinds of diagrams: - strategic dependency(SD)
relationships btwn roles
- strategic rationale (SR)
analyze goals in SD model
81. i* shows..: each role as a large circle contains goals, tasks and resources
which role owns
82. KAOS: -Knowledge Acquisition in automated specification OR Keep All Objec-
tives satisfied
-goal oriented software requirements, capture approach in req. engineering
- allows for requirements to be calculated from goal diagrams
83. UML goal modeling: provides a simple goal modelling notation
84. goal modelling tools: jUCMNav (GRL), piStar, Creative Leaf, Objectiv-
er(KAOS)

5 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
85. User requirements notation (URN): - focus on early stages of development
w/ goals and scenarios
86. Goal- Oriented Requirements Language (GRL): - graphical notation
- connects requirements to business objectives
- allows reasoning about (non-functional) requirements
- has its roots in i* and the NFR framework
- clarifies ill defined requirements
- finds alternatives
- traceability
- allows reuse of higher-level goals
-WHY
87. Use Case Maps: - graphical scenario notation
- causal relationships between responsibilities
- scenario elements may (optionally) be allocated to components
-WHAT
88. goals are operationalized into ..: tasks and tasks are elaborated in UCM
scenarios
89. three main categories of concepts in GRL: intentional elements, relation-
ships and actors
90. task: used to represent different way of how to accomplish goal
(hexagon )
91. softgoal: non functional requirements
(irregular curvilinear shape)
92. resource: physical or information object (rectangle)
93. belief: assumptions and relevant conditions (ellipse)
94. means ends: relationship shows how the goal can be achieved.
95. decomposition: relationship is used to show the sub-components of a task
96. contribution: relationship describes how one element influence another one
97. correlation: relationship describes side effects of existence of one element to
others.
98. dependency: relationship describe interdependences between agents
99. contribution link: - A contribution describes desired impact or side effects
(positive or negative)

6 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
- Qualitative (symbols) or quantitative (numbers)contribution types are used for
these links
100. decomposition link: defines what an intentional element needs to be satis-
fied
101. dependency link: The source of the dependency cannot be more satisfied
than its target
102. actor: active object that carries out actions to achieve the goal (circle)
103. strategies can be compared with each other for: trade off analysis
104. evaluations of GRL graphs show: the impact of qualitative decisions on
high level soft goals
105. propagation is usually: bottom up
106. GRL evaluation types: qualitative and quantitative
107. actor evaluation is computed from: importance level
108. requirements analysis: - specifies software's operational characteristics
- indicates software's interface with other system elements
- establishes constraints that software must meet
109. purpose of requirements analysis: specifies the softwares operational
characteristics
110. 3 primary objectives of analysis phase: - describe what customer requires
- to establish a basis for creation of a software design
- define a set of requirements that can be validated once the software is built
111. analysis model should focus on requirements that are: visible within the
problem of business domain
- minimize coupling
etccc
112. domain analysis: identification, analysis and specification of common,
reusable capabilities w/in a specific application domain
113. flow oriented modelling: provides an indication of how data objects are
transformed by a set of processing functions
114. scenario based modelling: represents the system from the user's point of
view
115. class based modelling: defines objects, attributes, and relationships

7 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
116. behavioural modelling: depicts the states of the classes and the impact of
events on these states
117. elements of analysis model: - scenario based elements
- class based elements
- behavioural elements
- flow oriented elements
118. object oriented analysis: Focuses on the definition of classes and the man-
ner in which they collaborate (inter-relationships with one another to fulfill customer
requirements
- UML is predominantly object -oriented
119. structured analysis: Considers data and the processes that transform the
data as separate entities
- model what system must do
120. environmental model: scope of proposed system, boundary and interaction
btwn system and outside world
121. environmental model is composed of: - statement of purpose, context
diagram, event list
122. statement of purpose: intended for top level management, user manage-
ment, and others who are not directly involved in system
123. system context diagram: define boundary btwn system and environment
- most abstract view of a system
124. system context diagrams can be developed with the use of two types of
building blocks...: entities(labelled box) and relationships (labelled lines)
125. SCD single bubble: represents system as a whole, hiding all processing
details
126. SCD data flow: single bubble --> terminator --> shared stores
127. T/F terminator entities are always connected to a single bubble and
shared store(if any): true
128. T/F you can have a terminator to terminator connection: false
129. data store: shows data- table, lists, manuals etc
- shared stores are part of IS boundary
- stores dont talk to each other directly
130. T/F data stores should be named with verbs: false, plural nouns

8 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
131. terminator: Person, organization, another system interacting with the infor-
mation system (sending data / receiving information)
132. steps to draw context diagram: 1. List all the activities.
2. Draw a system as one single bubble.
3. Identifies external entities (terminators) and data flow
- External Entity-> Noun
- Data Flow -> Names of data
4. Recognizes the external data stores.
133. event list: narrative list of the "stimuli" that occur in the outside world.
- specific time/place
134. types of events-> event list:: F- type, T-type
135. F-Type: flow oriented events
- initiated and triggered by terminator
136. T-Type: temporal events
-occur at certain point in time or at certain time intervals
137. behavioural model: internal behaviour and data entities of the system, func-
tional requirements
138. behaviour model is composed of: - data dictionary, data flow diagram,
entity relationship diagram, process specification and state transition diagram
139. data flow diagram (DFD): is a graphical representation of the "flow" of data
through an information system, modelling its process aspects
- high level, boundaries, connections
140. DFD consists of: 1. Sources (originator of data)
2. Processes
3. Data stores (e.g. file or database)
4. Sinks (consumer of data)
5. Data Flow (arrow)
141. process: Activity or function where the transformation of data takes place
(within the system)
A process has a name (verb applied to noun), an identification number and a
description (simple statement).
142. T/F a process always denotes changes in data: true
143. process modelling types (2): logical process models, physical process mod-
els
144. structured english: method of writing process specifications
9 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
145. process rules: - can have more then one output/input
- can be connected to any other symbol, including another process
146. external entity: external to system but interacts with it , source or destination
or data
147. source: entity that supplies data to the system
148. sink: entity that receives data from the system
149. DFD rules: accepted :
process --> process
process--> external entity
process--> data store
not accepted:
external entity--> external entity
external entity--> data store
data store--> data store
150. DFD level 0: system boundaries, external entities, major info flows, process
0 represents system
151. DFD level 1: major processes, data flows, data stores
152. create level 0 DFD: 1. Build the context diagram
2. Create the level 0 diagram using (if necessary) the requirementsdefinition,
summary of business activities, etc.
1. Identify the list of activities / major functions of the system (processes).
2. Identify which process produce data and which process require data producedby
external entities.
3. Identify data flows and data stores and their interaction.
4. Data flow to data store means update, data flow from data store meansretrieve
153. balancing: information presented at one level must be accurately represent-
ed in the next level.
154. functional decomposition: An iterative process which results more details
about a process
155. T/F lowest level DFDs are called primitive DFDs: true
156. T/F Every set of DFD's does not necessarily need a context diagram: -
false needs one
157. SRS Document: clearly and accurately describes each of the essential re-
quirements

10 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
- each should be feasible and verifiable
- basis for contractual agreements
158. 4 major goals of SRS: - It provides feedback to the customer
- It decomposes the problem into component parts
- It serves as an input to design specifications
- It serves as a product validation check
159. SRS objectives: - help software customers to accurately describe what they
wish to obtain
- help software suppliers to understand exactly what the customer wants
- help participants develop template and additional documents
160. SRS benefits: - basis for agreement
- reduce development effort
- basis for validation and verification
- facilitate transfer of sw product to new users or machines
- basis for enhancement
161. contents of SRS: intro, general description, specific requirement, additional
info
162. good SRS: correct, unambiguous, complete, consistent, ranked importance,
verifiable, modifiable, traceable
163. requirements management activities: change control, version control, re-
quirements status tracking, requirements tracing
164. baseline: non modifiable version of document
165. baseline of requirements: represents set of functional and non functional
requirements
166. requirement change factors: -errors, conflicts, inconsistencies
- evolving customer/user knowledge of system
- technical, schedule, cost problems
167. stable requirements: concerned with the essence of asystem and its appli-
cation domain
168. volatile requirements: specific to the instantiation of the system in a partic-
ular environment for a particular customer at a particular time
169. types of volatile requirements: mutable, emergent, consequential, compat-
iblity
170. mutable requirement: These are requirements which change because of
changes to theenvironment in which the system is operating
11 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
171. emergent requirement: These are requirements which cannot be complete-
ly defined when thesystem is specified but which emerge as the system is designed
andimplemented
172. consequential requiremtns: These are requirements which are based on
assumptions about howthe system will be used• Once the system is in place, some
of these assumptions will be wrong
173. compatibility requirements: These are requirements which depend on oth-
er equipment, technology, or processes
174. expectations of requirements management: identification, traceability, im-
pact assessments, controlled access, change control
175. traceability: ability to describe and follow the life of a requirement, in both
forwards and backwards direction
176. T/F traceability is often mandated by contracts and standards: true
177. T/F one can manage what cannot be traced: false you can't manage it
178. T/F traceability info helps assist impact of changes to requirements: true
179. backward traceability: to previous stages of development
180. forward traceability: to all documents spawned by a document
181. T/F the maturity level of an organization is inversely proportional to the
level of detail: false, directly proportional
182. types of traceability: source, rationale, requirements, architecture, design,
interface, feature, tests, code
183. factors to consider during traceability planning: number of requirements,
expected system lifetime, maturity level of organization, size of project and team ,
type of system, additional constraints from customer
184. change management: Concerned with the procedures, processes, and stan-
dardswhich are used to manage changes to a system requirements
185. change management process: requirement problem identified, proposed
changes are analyzed, change is implemented
186. management aspects(3): change, configuration, release
187. risk management planning: addresses how to approach, plan, and execute
all of the project risk management activities
188. T/F the most critical environmental factor are the risk tolerance levels
of the organization and the stakeholders: true

12 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
189. risk management planning inputs: enterprise environmental factors, orga-
nizational process assets, project scope statement
190. risk management planning tool: planning meetings
191. risk management planning output: the risk management plan is the only
output from the risk management planning process
192. RM methodology: how risk management will be performed, including meth-
ods, tools, and sources of data
193. RM roles and responsibilities: Team of people responsible for managing
identified risks and responses, the risk 'owners'
194. RM budgeting: Assign resources and estimate costs of risk management
and its methods
195. RM timing: Timing and frequency of the risk management processes
196. RM risk categories: Develop and review during planning. Used in risk iden-
tification
197. RM definitions of risk probability and impact: Discussed in detail in Qual-
itative Risk Analysis
198. RM probability and impact matrix: Discussed in detail in Qualitative Risk
Analysis
199. RM stakeholder tolerances: Risk planning may result in changes in stake-
holder tolerance
200. RM reporting formats: Describes the content and format of the riskregister,
the dictionary of risks for project
201. RM tracking: Describes how the risk activity history will be documented and
how risk processes will be audited
202. risk categories: - Technical, quality, or performance risks
- Project management risks
- Organizational risks
- External risks
203. Technical, quality, or performance risks: -unproven or complex tech
- unrealistic quality/performance goals
204. project management risk: -improper schedule + resource planning
- poor project planning/management
205. organizational risks: -resource conflicts due to multiple project at same time
- unrealistic scope, time,cost
13 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
206. external risks: - new laws regulations
- weather
- labor issues etc
207. risk breakdown structure (RBS): provide hierarchical decomp. of risk cate-
gories
208. risk identification: determining what risks might have an impact on the
project
- iterative/incremental process
209. 3 types of software risks: project risks, technical risks, business risks
210. project risks: threaten project plan
211. technical risk: threaten quality and timeliness of software to be produced
212. business risks: threaten viability of product to be built
213. project management plan: contains schedule, budget, quality plans which
may be sources of risks
214. risk identification tools: documentation review, info gathering techniques,
interviews, root cause analysis, checklist analysis, assumptions analysis, diagram-
ming techniques
215. cause and effect diagram: -ishikawa(fishbone)
-show relationships btwn effects of problems and their causes
216. flow charts: shows logical steps needed to accomplish an objective
217. influence diagrams: show causal influences among project variables
- risks, uncertainties, impacts
218. risk item checklist subcategories: product size, business impact, customer
characteristics, process definition, development environment, technology to be
built, staff size and experience
219. output of risk identification is: risk register
220. risk register components: -list of identified risks
-list of potential responses
- root causes of risk
- updated risk categories
-probability
-impact
-triggers

14 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
221. risk management paradigm: Identify, analyze, plan, track, control; Cycle
back through/repeat if necessary
222. elements of risk analysis: risk management
-risk analysis
--risk assessment
--risk reduction
-risk control
--risk tracking
--risk reporting
223. qualitative risk analysis: concerned with prioritizing identified risks
- used to determine if quantitative risk analysis is necessary
224. input of qualitative risk analysis: - organizational process assets
- project scope statement
- risk management plan,
- risk register
225. risk projection: - also called risk estimation
- rates each risk in two ways
-- likelihood and probability
--consequences
226. risk exposure (RE): - risk impact
- RE = probability of loss * size of loss
- sum all RE's to get expected overrun
227. risk probability and impact assessment: 1. asses prob. identified risk will
occur
2. determine impact of risk on project.. time, scope, quality, cost
228. probability: potential for the risk event to occur
- determined through expert judgement
229. impact: consequences to the project should risk event occur
230. five point likert scale: 20, 40, 60, 80
highly unlikely, unlikely, about even, likely, highly likely
231. three point scale: 35, 75
high, moderate, low
232. expected value: - risk exposure
- Pr => prob of risk

15 / 16
 COE 691 FINAL
Study online at https://quizlet.com/_cv0c7p
- Lr => total loss
RE = Pr * Lr
233. risk rating: single value to characterize prob, and impact
234. risk response planning: developing options and possible reactions to miti-
gate threats and exploit opportunities
235. strategies for negative risks or threats: - avoidance
- risk transfer
- contracting
- mitigation
- risk acceptance
- risk contingency plan
236. contracting: accept certain aspects of risk
- fixed price contract
--increase cost of contract to compensate level or risk they are accepting
-cost reimbursable contract
--receives compensation for additional costs
237. mitigation: reduce probability of risk event
238. strategies for positive risks or opportunities: - exploitation
- sharing
239. secondary risks: arise as a result of implementing a risk response
240. residual risks: those that cannot be effectively dealt with
241. T/F risks are not the principle concern of the project management
team: false, they are principle concern
242. basic principles of risk: - must be reported
- team meetings
- weekly project review
243. project status report: list all risks for which degree of risk has changed
244. SEVEN principles of risk: 1. maintain global perspective
2. take a forward looking view
3. encourage open communication
4. integrate
5. emphasize continuous process
6. develop shared product vision
7. encourage team work

16 / 16