Block 1 - From domain to requirements Flashcards
1
Q
abstraction
A
extacting the essence of a problemDomain or softwareSolution;
2
Q
activity
A
in UML, an activity is an ongoing non-atomic execution (cf. action) within a state machine or an activity diagram;
3
Q
activity diagram
A
a workflow repping the transitions from one activity to another in the problem domain;
4
Q
actor
A
an entity interacting with a UC;
5
Q
agile
A
softwareSolution satisfies customerRequirements(latest);
6
Q
agile UP
A
ADIT-iterations + agile;
7
Q
analysis
A
modelling problemDomain / identifying requirements;
8
Q
communication diagram
A
an interaction diagram that uses numerical labelling to rep the chronological order of messages sent between objects;
9
Q
component
A
an encapsulated set of related functions with an interface and spec;
10
Q
conceptual model
A
reps static part of problemDomain;
11
Q
configuration
A
all the components which together make up an executable SS;
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;
13
Q
configuration management
A
controlling changes, maintaining integrity and ensuring traceability throughout the SS’s lifetime;
14
Q
conformance testing
A
testing that the software product conforms to its requirements;
15
Q
constraint (UML)
A
expresses a rule that governs a model element(s);
16
Q
construction
A
in UP, the phase when the final product is implemented;
17
Q
consumer
A
a client in software oriented architecture (SOA);
18
Q
context dependency
A
a service required by a component for it to work;
19
Q
cultural requirement
A
an NFR relating to the people involved in the product’s development and operation;
20
Q
decision nodes
A
reps alternative transitions that can be made when leaving an activity;
21
Q
decomposition
A
bigProblem / n = n*smallProblems;
22
Q
deliverable
A
an output of a software dev. activity that evidences the activity’s completion;
23
Q
denial of use of service (or loss of access)
A
attack consisting of the denial of service to authorised users;
24
Q
deployment
A
configuring code to give a runnable system;
25
deployment view
all the nodes and constituent components of the distributed SS;
26
derivation
a configuration item based on other configuration items;
27
design
writing a spec for a SS to meet the analysis-outputs;
28
Design by Contract (DbC)
assume(precons = true);
29
design (structural) model
classDiagram with SOs repping softwareSolution;
30
disclosure
unauthorised release of information;
31
discoverable
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?]
32
domain
an area of knowledge characterised by a set of concepts understood by practitioners in that area;
33
domain analysis
where the domain is examined and domain experts are consulted to elicit requirements;
34
domain modelling
modelling the problem domain (not the software solution);
35
dynamic model
describes the behaviour of a SS over time;
36
Dynamic Systems Development Method (DSDM)
an agile method advocating:
- modelling and iterative dev.
- MoSCoW prioritisation
- timeboxing
37
elaboration
the analysis and design phase in UP;
38
element
an atomic constituent of a model;
39
encapsulation
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;
40
engineering
a systematic approach to efficiently developing products which are fit for prupose, based on a body of knowledge;
41
enterprise beans
... are (distributed) server-side components providing remote services to clients throughout the network;
[bean = component];
42
Enterprise JavaBeans (EJB)
a Java-based technology allowing orgs to build / acquire their own components;
43
extension
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]
44
extension points
in the main success scenario of a UC, the condition triggering a subsidiary UC is tested;
45
fit criterion
a specific measurement of an FR or NFR that allows you to determine whether the final product satisfies that requirement;
46
fork node
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]
47
functional (or logical) view
architecturally describes:
- the SS's functional elements
- their responsibilities
- their interfaces
- their interactions
48
functional requirement
an action the SS must perform;
49
further analysis
adding detail to a system spec., viz operations and constraints;
50
glossary
a list of terms (and explanations) relating to a particular domain;
51
guard
a condition that must be satisfied in order to transition from one activity / state to another activity / state;
52
guillemets /'gilehmets/
angled brackets (<>) used in UML to show a stereotype;
53
herioc programming
a single person creates a software solution to a given problem;
54
human factors
the relationship between people and tech;
55
implementation
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]
56
inception
the initial development planning phase in UP;
57
inclusion
when 2+ UCs have a common functionality, which can be factored out as a distinct UC;
58
increment
the work done to a software deliverable by the end of an iteration;
59
initial problem statement
a description of the problem from which development of the software solution proceeds;
60
integration
where components are combined into an executable whole;
61
integrity
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
interaction diagram
a UML [sequence or communication] diagram showing the messages sent in an interaction;
63
interface
the operations that a component provides to clients;
64
interoperability
an SQF determining how easily the SS interfaces with other SSs;
65
iteration
a repeatable sequence of activities resulting in a deliverable;
66
iterative and incremental development (IID)
takes some requirements, does some ADIT iterations, thereby growing the SS by one increment;
67
iterative development
continuously repeating a set of activities, improving the outputs each time;
68
join node
synchronises multiple parallel flows (in an activity diagram);
69
Layer pattern
organises the SS into discrete layers, each with its own responsibilities;
70
legacy system
an old SS still required because it serves a useful purpose to an org.;
71
legal requirement
an NFR concerning the laws the SS must comply with;
72
life cycle
the sequence of activities carried out to develop a SS;
73
look and feel requirement
an NFR about the product's appearance;
74
maintainability
an SQF concerning how easy it is to modify the SS;
75
merge node
a join-diamond;
76
model
a rep of a problemDomain or a softwareSolution;
77
modularity
dividing a SS into separate components,
78
MoSCoW
a scheme in DSDM classifying requirements into:
- Must have
- Should have
- Could have
- Won't have
79
NFR
a quality a SS must have;
80
operational requirement (NFR)
needs of the SS's working environment;
81
oracle
the test case criteria which if met shows a test has been passed;
82
performance requirement
```
an NFR concerning how:
- fast
- safe
- accurate
- available
- reliable
... the SS must be;
```
83
plan-driven development (PDD)
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
Planning Game
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
portability
an SQF concerning the ease with which the SS can transition from one operational environment to another;
86
postcondition
an assertion that must be true after an operation / UC has been completed;
87
precondition
an assertion that must be true before an operation / UC is carried out;
88
process view
achitecturally views concurrent run-time aspects of the SS;
89
product backlog
a Scrum vector covering what work still needs to be done for the SS;
90
prototype
a simplified subset of the eventual SS;
91
provider
the implementation platform of a service (in a service oriented architecture);
92
registry
a mechanism that allows consumers to find services;
93
release
a configured version of the SS delivered at project completion for the customer;
94
reliability
an SQF concerning the probability the SS will fulfil its function;
95
repudiation
where a user falsely claims a message was not received;
96
requirement
a feature that the customer desires the SS to have;
97
requirements analysis
deciding how to solve the problem identified from eliciting the requirements;
98
requirements documentation
written agreement of the requirements;
99
requirements elicitation
identifying the needs and constraints for the SS to be;
100
requirements engineering
consists of requirements elicitation and requirements analysis;
101
Requirements pattern
knowledge used in eliciting requirements;
102
requirements specification
a detailed description of the requirements for the SS;
103
review
listing the SS's major defects along with who will address each defect;
104
risk management
analysing risks and how to reduce them;
105
scenario
a instance of a UC;
106
Scrum
an agile software development method;
107
security
controlling access to programs and data;
108
security requirement
an NFR concerned with maintaining the integrity and confidentiality of the SS;
109
service
a function that can be requested via its published interface;
110
service description
specifies how a consumer can interact with a service;
111
size (of software)
can be measured in terms of:
- lines of code
- number of symbols
- size of source / object files
112
socio-technical systems
the SS considered along with the social structures it operates within;
113
software architecture
the components and their relations in a SS;
114
software development
the process which culminates in a software product;
115
software quality
how staisfied the customer is with the software product;
116
software system
the end-product consisting of both application and system programs;
117
sprint (Scrum)
a 1-month-max timebox resulting in working software being delivered;
118
stakeholder
an entity affected by the SS to be;
119
static modelling
modelling the structure of the problemDomain / softwareSolution;
120
stereotype
an extension mechanism for creating a new kind of modelling element in UML;
121
swimlane
swimlanes show concurrently which entity carries out which threads in an activity diagram;
122
synchronisation bar
indentifies the points at which concurrent threads begin (a fork) or end (a join) in an activity diagram;
123
system
connected components performing a function;
124
technical solution requirements
functionality needed due to the chosen tech;
125
testability
an SQF concerning how easy it is to check the SS performs its intended function;
126
testing
determining whether a component meets its spec.;
127
timeboxing
allocating n-week-long periods to each iteration;
128
traceability
being able to backtrack from operational SS to TIDA;
129
transition
the move from one state / activity to another (in an activity diagram or state machine);
130
Unified Process (UP)
an OO IID process consisting of four phases:
- inception [analysis]
- elaboration [analysis]
- construction [design / implementation / testing]
- transition [deployment]
131
usability
a SQF concerning how satisfying it is for a user to interact the SS;
132
usability requirement
an NFR specifying that the SS should be satisfying for a user to interact with in a particular way;
133
UC
a functionality the SS performs returning a result to an actor;
134
UC diagram
shows the relations between UC(s) and actors;
135
user-centred design
takes into account the users of the SS during analysis and design;
136
user story
As a + ROLE, I can do X when Y because Z;
137
validation
checking that the SS satisfies the most recent version of the customer's requirements;
138
variant
a configuration item derived from slightly modifying another configuration item;
139
verification
checking that the SS satisfies the design specification as framed by the development team;
140
version
a configuration item instance;
141
viewpoint
a specific architectural framing of the SS w.r.t. a stakeholder;
142
Volere template
a specific format for recording the requirements and related issues;
143
waterfall model
carries out ADIT in that order with no iteration (i.e. real waterfalls only flow downwards and can't 'iterate');
144
workflow
reps the sequence of activities taking place to achieve a goal in the problem domain;
