Brainscape's Knowledge GenomeTM

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


See full index

TM354 > Block 1 - From domain to requirements > Flashcards

Block 1 - From domain to requirements Flashcards

1
Q

abstraction

A

extacting the essence of a problemDomain or softwareSolution;

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

activity

A

in UML, an activity is an ongoing non-atomic execution (cf. action) within a state machine or an activity diagram;

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

activity diagram

A

a workflow repping the transitions from one activity to another in the problem domain;

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

actor

A

an entity interacting with a UC;

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

agile

A

softwareSolution satisfies customerRequirements(latest);

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

agile UP

A

ADIT-iterations + agile;

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

analysis

A

modelling problemDomain / identifying requirements;

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

communication diagram

A

an interaction diagram that uses numerical labelling to rep the chronological order of messages sent between objects;

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

component

A

an encapsulated set of related functions with an interface and spec;

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

conceptual model

A

reps static part of problemDomain;

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

configuration

A

all the components which together make up an executable SS;

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

configuration items

A

modifiable items produced during the development and maintainance of software, which include:

  • UML diagrams;
  • programs / classes;
  • architectures and patterns;
  • test plans and cases;
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

configuration management

A

controlling changes, maintaining integrity and ensuring traceability throughout the SS’s lifetime;

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

conformance testing

A

testing that the software product conforms to its requirements;

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

constraint (UML)

A

expresses a rule that governs a model element(s);

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

construction

A

in UP, the phase when the final product is implemented;

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

consumer

A

a client in software oriented architecture (SOA);

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

context dependency

A

a service required by a component for it to work;

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

cultural requirement

A

an NFR relating to the people involved in the product’s development and operation;

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

decision nodes

A

reps alternative transitions that can be made when leaving an activity;

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

decomposition

A

bigProblem / n = n*smallProblems;

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

deliverable

A

an output of a software dev. activity that evidences the activity’s completion;

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

denial of use of service (or loss of access)

A

attack consisting of the denial of service to authorised users;

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

deployment

A

configuring code to give a runnable system;

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

deployment view

A

all the nodes and constituent components of the distributed SS;

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

derivation

A

a configuration item based on other configuration items;

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

design

A

writing a spec for a SS to meet the analysis-outputs;

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

Design by Contract (DbC)

A

assume(precons = true);

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

design (structural) model

A

classDiagram with SOs repping softwareSolution;

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

disclosure

A

unauthorised release of information;

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

discoverable

A

the property of a service in a service oriented architecture that allows the architecture to identify services on behalf of a consumer;

[i.e. the service needs to have a handle?]

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

domain

A

an area of knowledge characterised by a set of concepts understood by practitioners in that area;

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

domain analysis

A

where the domain is examined and domain experts are consulted to elicit requirements;

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

domain modelling

A

modelling the problem domain (not the software solution);

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

dynamic model

A

describes the behaviour of a SS over time;

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

Dynamic Systems Development Method (DSDM)

A

an agile method advocating:

  • modelling and iterative dev.
  • MoSCoW prioritisation
  • timeboxing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

elaboration

A

the analysis and design phase in UP;

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

element

A

an atomic constituent of a model;

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

encapsulation

A

hiding from the clients of a class the details of how the class is implemented;

i.e. the process of hiding (making private) all the methods and data fields of a class used in the implementation of the public methods (or interface) of the class;

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

engineering

A

a systematic approach to efficiently developing products which are fit for prupose, based on a body of knowledge;

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

enterprise beans

A

… are (distributed) server-side components providing remote services to clients throughout the network;

[bean = component];

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

Enterprise JavaBeans (EJB)

A

a Java-based technology allowing orgs to build / acquire their own components;

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

extension

A

a form of inheritance;

the child class adds functionality to the parent class but does not change any inherited behaviour;

[i.e. does not override any methods]

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

extension points

A

in the main success scenario of a UC, the condition triggering a subsidiary UC is tested;

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

fit criterion

A

a specific measurement of an FR or NFR that allows you to determine whether the final product satisfies that requirement;

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

fork node

A

in activity diagrams, a fork node splits control into multiple parallel flows;

[it is the opening sync-bar; the merge node is the closing sync-bar]

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

functional (or logical) view

A

architecturally describes:

  • the SS’s functional elements
  • their responsibilities
  • their interfaces
  • their interactions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

functional requirement

A

an action the SS must perform;

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

further analysis

A

adding detail to a system spec., viz operations and constraints;

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

glossary

A

a list of terms (and explanations) relating to a particular domain;

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

guard

A

a condition that must be satisfied in order to transition from one activity / state to another activity / state;

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

guillemets /’gilehmets/

A

angled brackets (<>) used in UML to show a stereotype;

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

herioc programming

A

a single person creates a software solution to a given problem;

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

human factors

A

the relationship between people and tech;

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

implementation

A

writing code for the SS so that it will exhibit the structure and behaviour specified by the design artefacts;

[the four technical activities in software development are:

  • analysis
  • design
  • implementation
  • testing]
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

inception

A

the initial development planning phase in UP;

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

inclusion

A

when 2+ UCs have a common functionality, which can be factored out as a distinct UC;

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

increment

A

the work done to a software deliverable by the end of an iteration;

59
Q

initial problem statement

A

a description of the problem from which development of the software solution proceeds;

60
Q

integration

A

where components are combined into an executable whole;

61
Q

integrity

A

when data has not been subject to unauthorised change;

is an SQF affecting ‘product operation requirements’, i.e. how well the data is secured;

62
Q

interaction diagram

A

a UML [sequence or communication] diagram showing the messages sent in an interaction;

63
Q

interface

A

the operations that a component provides to clients;

64
Q

interoperability

A

an SQF determining how easily the SS interfaces with other SSs;

65
Q

iteration

A

a repeatable sequence of activities resulting in a deliverable;

66
Q

iterative and incremental development (IID)

A

takes some requirements, does some ADIT iterations, thereby growing the SS by one increment;

67
Q

iterative development

A

continuously repeating a set of activities, improving the outputs each time;

68
Q

join node

A

synchronises multiple parallel flows (in an activity diagram);

69
Q

Layer pattern

A

organises the SS into discrete layers, each with its own responsibilities;

70
Q

legacy system

A

an old SS still required because it serves a useful purpose to an org.;

71
Q

legal requirement

A

an NFR concerning the laws the SS must comply with;

72
Q

life cycle

A

the sequence of activities carried out to develop a SS;

73
Q

look and feel requirement

A

an NFR about the product’s appearance;

74
Q

maintainability

A

an SQF concerning how easy it is to modify the SS;

75
Q

merge node

A

a join-diamond;

76
Q

model

A

a rep of a problemDomain or a softwareSolution;

77
Q

modularity

A

dividing a SS into separate components,

78
Q

MoSCoW

A

a scheme in DSDM classifying requirements into:

  • Must have
  • Should have
  • Could have
  • Won’t have
79
Q

NFR

A

a quality a SS must have;

80
Q

operational requirement (NFR)

A

needs of the SS’s working environment;

81
Q

oracle

A

the test case criteria which if met shows a test has been passed;

82
Q

performance requirement

A 
an NFR concerning how:
- fast
- safe
- accurate
- available
- reliable 
... the SS must be;
83
Q

plan-driven development (PDD)

A

where all requirements are set in stone at the outset, a spec. is designed based on the requirements, and the SS is built based on the spec.;

84
Q

Planning Game

A

an agile phase with two programmers where they:

  • find out new things to do (exploration)
  • decide what to do next (commitment)
  • update plan based on reality (steering)
85
Q

portability

A

an SQF concerning the ease with which the SS can transition from one operational environment to another;

86
Q

postcondition

A

an assertion that must be true after an operation / UC has been completed;

87
Q

precondition

A

an assertion that must be true before an operation / UC is carried out;

88
Q

process view

A

achitecturally views concurrent run-time aspects of the SS;

89
Q

product backlog

A

a Scrum vector covering what work still needs to be done for the SS;

90
Q

prototype

A

a simplified subset of the eventual SS;

91
Q

provider

A

the implementation platform of a service (in a service oriented architecture);

92
Q

registry

A

a mechanism that allows consumers to find services;

93
Q

release

A

a configured version of the SS delivered at project completion for the customer;

94
Q

reliability

A

an SQF concerning the probability the SS will fulfil its function;

95
Q

repudiation

A

where a user falsely claims a message was not received;

96
Q

requirement

A

a feature that the customer desires the SS to have;

97
Q

requirements analysis

A

deciding how to solve the problem identified from eliciting the requirements;

98
Q

requirements documentation

A

written agreement of the requirements;

99
Q

requirements elicitation

A

identifying the needs and constraints for the SS to be;

100
Q

requirements engineering

A

consists of requirements elicitation and requirements analysis;

101
Q

Requirements pattern

A

knowledge used in eliciting requirements;

102
Q

requirements specification

A

a detailed description of the requirements for the SS;

103
Q

review

A

listing the SS’s major defects along with who will address each defect;

104
Q

risk management

A

analysing risks and how to reduce them;

105
Q

scenario

A

a instance of a UC;

106
Q

Scrum

A

an agile software development method;

107
Q

security

A

controlling access to programs and data;

108
Q

security requirement

A

an NFR concerned with maintaining the integrity and confidentiality of the SS;

109
Q

service

A

a function that can be requested via its published interface;

110
Q

service description

A

specifies how a consumer can interact with a service;

111
Q

size (of software)

A

can be measured in terms of:

  • lines of code
  • number of symbols
  • size of source / object files
112
Q

socio-technical systems

A

the SS considered along with the social structures it operates within;

113
Q

software architecture

A

the components and their relations in a SS;

114
Q

software development

A

the process which culminates in a software product;

115
Q

software quality

A

how staisfied the customer is with the software product;

116
Q

software system

A

the end-product consisting of both application and system programs;

117
Q

sprint (Scrum)

A

a 1-month-max timebox resulting in working software being delivered;

118
Q

stakeholder

A

an entity affected by the SS to be;

119
Q

static modelling

A

modelling the structure of the problemDomain / softwareSolution;

120
Q

stereotype

A

an extension mechanism for creating a new kind of modelling element in UML;

121
Q

swimlane

A

swimlanes show concurrently which entity carries out which threads in an activity diagram;

122
Q

synchronisation bar

A

indentifies the points at which concurrent threads begin (a fork) or end (a join) in an activity diagram;

123
Q

system

A

connected components performing a function;

124
Q

technical solution requirements

A

functionality needed due to the chosen tech;

125
Q

testability

A

an SQF concerning how easy it is to check the SS performs its intended function;

126
Q

testing

A

determining whether a component meets its spec.;

127
Q

timeboxing

A

allocating n-week-long periods to each iteration;

128
Q

traceability

A

being able to backtrack from operational SS to TIDA;

129
Q

transition

A

the move from one state / activity to another (in an activity diagram or state machine);

130
Q

Unified Process (UP)

A

an OO IID process consisting of four phases:

  • inception [analysis]
  • elaboration [analysis]
  • construction [design / implementation / testing]
  • transition [deployment]
131
Q

usability

A

a SQF concerning how satisfying it is for a user to interact the SS;

132
Q

usability requirement

A

an NFR specifying that the SS should be satisfying for a user to interact with in a particular way;

133
Q

UC

A

a functionality the SS performs returning a result to an actor;

134
Q

UC diagram

A

shows the relations between UC(s) and actors;

135
Q

user-centred design

A

takes into account the users of the SS during analysis and design;

136
Q

user story

A

As a + ROLE, I can do X when Y because Z;

137
Q

validation

A

checking that the SS satisfies the most recent version of the customer’s requirements;

138
Q

variant

A

a configuration item derived from slightly modifying another configuration item;

139
Q

verification

A

checking that the SS satisfies the design specification as framed by the development team;

140
Q

version

A

a configuration item instance;

141
Q

viewpoint

A

a specific architectural framing of the SS w.r.t. a stakeholder;

142
Q

Volere template

A

a specific format for recording the requirements and related issues;

143
Q

waterfall model

A

carries out ADIT in that order with no iteration (i.e. real waterfalls only flow downwards and can’t ‘iterate’);

144
Q

workflow

A

reps the sequence of activities taking place to achieve a goal in the problem domain;

TM354 (3 decks)

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