Brainscape's Knowledge GenomeTM

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


See full index

TM354 2021 > Block 1 Glossary > Flashcards

Block 1 Glossary Flashcards

These cards are a copy of the glossary provided by TM354. Except where definitions are 'see x', these cards have been omitted.

1
Q

Abstraction

A

The process of describing the essential features of a problem and ignoring other details. It permits you to concentrate on a problem at some level of generalisation, without regard to irrelevant detail. It also permits you to work with concepts, terms and models that are familiar in the problem environment (or domain).

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 (contrast with action) within a state machineor within an activity diagram; in a given context, activities result in one or more actions.

In a software development process, it is a unit of work comprising one or more tasks that someone may be asked to perform.

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

Activity Diagram

A

A representation of a workflow through activity states or action states and in which most or all of the transitions are triggered by completion of an activity in the source states; an activity diagram can be used to represent the workflows within the business domain.

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

Actor

A

A representation of users of a software system in a particular role, when interacting with use cases. An actor can also represent the role of an external system that interacts with a software system.

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

Aglie

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

Agile UP

A

A version of UP where the initial disciplines (business/domain model, requirements, analysis and design) are collapsed into a single ‘model’ discipline and where iterations are short (weeks rather than months) and frequent; product is delivered incrementally if at all possible; design and implementation do not wait until all the requirements are found.

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

Ambiguity

A

Open to several interpretations.

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

Analysis

A

The term analysis is often used as a generic term for the activities that precede design, the process of eliciting the requirements of a system from the user (requirements elicitation), and then generating the requirements specification document that identifies (among other things) what the software should do (its functional requirements) and the environment in which it must work. In this module we use the term analysis to refer specifically to a set of activities that follow an initial requirementsphase: modelling how the structure and behaviour of the system will meet its specification from a user’s perspective. (See also requirements, design, implementation and testing).

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

Analysis Model

A

An initial representation of the structure of a software solution by a class diagram; it represents analysis classes, their associations and constraints.

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

Association

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

Business Event

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

Business Process

A

Definition of what gets done in the business: by whom, in what order, needing what and with what consequences.

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

Business Rule

A

A constraint on how the business is run; that is, a constraint on the business processes.

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

Caller

A

Component that makes a procedure call in a call-return architecture.

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

Circular Dependency

A

A series of two or more dependencies between different things (typically modules within a software system) that form a closed loop. If module A depends on module B which depends on module C, then a circular dependency arises if module C depends on module A.

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

Client

A

In software development, the term refers to the person (or company) who commissions and pays for a piece of software to be developed or to be purchased as a package (in this context the term client is synonymous with the term customer).

In programming, the term often refers to the method/class/object that uses the methods of another class/object (the supplier or server).

In network programming, the term refers to a program/process running on one computer that can obtain services from a server program running (usually) on another computer.

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

Cohesion

A

A way of describing how closely the activities within a single module are related to each other. A cohesive module should, ideally, do just one thing. In software development, high cohesion is preferred to low cohesion as it results in a more flexible software system because each module performs clearly defined operations/tasks.

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

Commitment

A

A move of the planning game that decides what to do next.

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

Communication Diagram

A

A UML interaction diagram that focuses on the structural aspect (instances and links) of an interaction. In previous versions of UML a communication diagram was known as a collaboration diagram.

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

Complexity

A

A complex system consists of a number of parts with a large number of relationships between them. A complex program is one that is difficult to understand.

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

Component

A

In general, this refers to an identifiable part of a system. For its use in connection with software systems, see software component.

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

CASE

A

Computer-aided Software Engineering

The use of specialised application programs (tools) that provide some form of automated support during the development of a software system for the benefit of its eventual implementation. Consequently, it includes one or more methods, as well as their accompanying techniques and notations, used for activities such as analysis and design.

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

Concept(ual) Model

A

The structural model that represents the static part of the domain: the concepts and their relationships.

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

Configuration

A

All the modules (components) which together make up an executable software system. It is also a term for the collection of configuration items.

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

Configuration Item

A

The configuration items are the items produced during the development and maintenance of software, which are stored, retrieved, changed, stored again, and so on. These include: use case diagrams and other UML diagrams; individual Java programs or classes, or the compiled versions of these; architectures and patterns; test plans and test cases.

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

Configuration Management

A

The task of managing configuration items, which involves identifying the components of a continuously evolving system (the configuration) at discrete points in time, for the purposes of controlling changes to the configuration, and maintaining integrity and traceability throughout the system’s lifetime.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
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
28
Q

Construction

A

In UP, phase when the final product is implemented.

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

Context Dependency

A

A service required by a module in order for it to work.

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

Contract

A

A legal document describing the obligations of two parties entering into an agreement; important contract issues include confidentiality and intellectual property rights. In a software project, a contract exists between the customer (client) and developer (supplier) for the provision of a software product. Also, a way of describing what each task, activity or operation commits to achieve by stating the pre- and postconditions. (See also Design by Contract.)

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

Coupling

A

A measure of interconnection among modules in a software system. In software development, low coupling is preferred to high coupling as it results in a more flexible software system. (See also encapsulation.)

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

Culural Requirement

A

A non-functional requirement 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
33
Q

Decision Nodes

A

In an activity diagram a node that is used to indicate alternative transitions that can be made when leaving an activity; it is represented by a diamond shape. A decision node has a single incoming transition; the guards on outgoing transitions are mutually exclusive.

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

Decomposition

A

Splitting a problem into smaller and smaller parts or chunks until each one can be comprehended or dealt with by an individual. In software we identify a number of different activities or tasks that an individual or a group of individuals might perform.

(See also partition.)

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

Deliverable

A

An output, such as a design document or source code, of some software development activity whose production gives evidence of the completion of the activity.

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

Denial of Use of Service

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
37
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
38
Q

Deployment View

A

The identification of all the nodes that comprise a distributed software system, the components that are stored on each node and the objects that are stored there.

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

Derivation

A

A version of a configuration item based on other configuration items, which might have to be changed if the original item changes.

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

Design

A

The process of determining how to build an artefact that meets a set of objectives that are normally identified during analysis. It is one of the four basic technical activities within a software development process (see also analysis, implementation and testing).

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

DbC

A

Design by Contract

The process of developing software based on the notion of contracts between objects, which are expressed as assertions.

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

Design Model

A

A representation of the structure of a software solution by a class diagram; it represents classes, their associations and constraints and their responsibilities in terms of operations.

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

Development Process

A

A set of rules that define how a software development project should be carried out. It incorporates a life cycle and involves a number of methods and procedures.

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

UML Diagram

A

In UML, a diagram is a graphical presentation of a collection of model elements.

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

Disclosure

A

Attack of private information or the unauthorised release of information.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
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. (See also service and service-oriented architecture.)

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

Domain

A

An area or field of knowledge characterised by a set of concepts and terminology that is understood by practioners in that area.

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

Domain Analysis

A

A form of requirements elicitation in which existing systems in the domain are examined and domainexperts are consulted.

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

Domain Modelling

A

Modelling what already exists.

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

Dynamic Model

A

Describes the behaviour of a software system over time.

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

DSDM

A

Dynamic Systems Development Method

An agile software development method.

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

Elaboration

A

In UP, phase most analysis and design occur.

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

Element

A

In UML, an element is an atomic constituent of a model.

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

Encapsulation

A

Hiding from the clients of a class the details of how the class is implemented. In other words, it is 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
55
Q

Engineering

A

A systematic approach to efficiently developing products which are fit for purpose, based on a body of knowledge.

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

Enterprise Beans

A

Another name for EJB components. They are server-side components, that is to say, they are distributed entities that provide remote services to clients distributed throughout the network.

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

EJB

A

Enterprise JavaBeans

A component technology, based on the Java programming language. It defines a standard that allows organisations to build their own components or acquire components from third-party vendors.

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

Exploration

A

A move of the planning game that finds out new things that can be done.

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

Extension

A

A form of inheritance in which the child class adds functionality to the parent class but does not change any inherited behaviour.

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

Extension Points

A

A place in the main success scenario of a use case where the condition that triggers a subsidiary use case is tested.

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

Fit Criteria

A

A quantification or a measurement of a requirement expressed in a way that allows you to assess whether or not the final product satisfies, or fits, that requirement.

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

Fork

A

In activity diagrams, a fork node splits control into multiple parallel flows.

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

Functional (or Logical) View

A

In a software architecture it describes the system’s main functional elements, their responsibilities, interfaces and primary interactions. A functional view is the cornerstone of most architectural descriptions.

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

Functional Requirement

A

a specified action that a system has to perform

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

Further Analysis

A

The adding of additional detail to a system specification. In particular, system operations and model constraints.

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

Glossary

A

A list of terms or words relating to a particular domain or text, along with an explanation of each term.

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

Guard

A

A condition that must be satisfied in order to enable an associated transition to fire within a state machine or activity diagram.

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

Guillements

A

Angled brackets (« …») used in UML to show a stereotype. They have other more general uses.

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

Heroic Programming

A

A form of software development where a single person attempts to have in mind everything concerning a given problem and its eventual solution.

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

Human Factors

A

The discipline that deals with the relationship between people and technology.

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

Implementation

A

The process of building a coherent set of instructions for a computer, that will cause it to exhibit a behaviour specified by the artefacts which are normally devised during design. It is one of the four basic technical activities within a software development process (see also analysis, design and testing).

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

Inception

A

In UP, phase when the initial planning of development occurs.

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

Inclusion

A

A relationship between two or more use cases, when there is an overlapping area of functionality – that is, a common task – that can be factored out as a distinct use case. The new use case can then be used by each of the original use cases, so avoiding duplication.

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

Increment

A

The difference between two releases of a (software) deliverable at the end of successive iterations.

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

Incremental Development

A

This development approach partitions the system into a number of independent or reasonably independent ‘chunks’. The process begins by developing one chunk – the core – and adding successive increments to it over time. A significant point about this method is that the core is a functioning item of software that meets some of the requirements. As each increment is added, the resulting software is still functional.

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

Initial Problem Statement

A

An initial statement of a problem from which development proceeds. In order to draw up detailed requirements it will usually be necessary to clarify and expand on the information in the initial problem statement during requirements elicitation. (See also requirements elicitation.)

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

Integration

A

An activity in which individual software modules or components are combined into an executable whole.

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

Integrity

A

in general, the property that data has not been subject to unauthorised change. In particular, a software quality factor affecting product operation requirements which determines the extent to which access to data by unauthorised persons can be controlled, that is, how well the data is secured.

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

Interatction Diagram

A

A UML diagram that shows the sequencing of messages in an interaction. (See also sequence diagram and communication diagram.)

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

Interface

A

In general, this refers to the operations (methods), including their syntax and semantics, that a software system/subsystem/module provides to the clients of the system. In the object-oriented approach, the public operations associated with an object are referred to as its interface, or its interface operations. In Java, an interface is a construct similar to a class, which provides a specification (in the form of method headings but no implementation) of the methods for which classes implementing the interface must provide implementations.

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

Interoperability

A

A software quality factor affecting product transition requirements which determines the effort required to couple one system to another, that is, how easy it is to interface the system with another, should the customer require it.

82
Q

Iteration

A

A distinct sequence of activities within a life cycle that may be repeated. Within a development process, the result is a (software) deliverable that conforms to certain criteria.

83
Q

Iteration Planning Game

A

A planning game for an iteration, played even more frequently, on tasks instead of stories; the players are the programmers.

84
Q

Iterative and Incremental Development

A

This development approach starts with a subset of the requirements and incrementally grows the system with further increments. Each increment is developed over several iterations; an iteration is a complete small project, with a short timeframe, consisting of analysis, design, implementation, testing and integration, and results in a partially working system.

85
Q

Iterative Development

A

This development approach continuously repeats a set of activities improving the outputs each time at the feedback received from a previous iteration.

86
Q

Join

A

In activity diagrams, a join node synchronises multiple parallel flows.

87
Q

Layer

A

A logical partitioning of a system.

88
Q

Layered Architecture

A

An architecture organised using a Layers pattern.

89
Q

Layers Pattern

A

This organises the large-scale functional structure of a system into discrete layers of distinct, related responsibilities, with a clear separation of concerns between the layers.

90
Q

Legacy System

A

An old software system that is still required because it meets some useful purpose to an organisation. It is not considered to be replaceable and so it is maintained, usually on a restricted budget.

91
Q

Legal Requirement

A

A non-functional requirement about laws and standards that apply to the product.

92
Q

Life Cycle

A

The sequence in which a number of different activities are carried out to define an overall process for the development of a software system.

93
Q

Look and Feel Requirement

A

A non-functional requirement about the product’s appearance.

94
Q

Maintainability

A

This is a software quality factor affecting maintainability and portability requirements, which determines the effort required to understand, locate and fix errors in a system, that is, how easily bugs can be found and fixed.

95
Q

Maintainability and Portability Requirement

A

A non-functional requirement about expected changes to a system and allowed time to make them.

96
Q

Maintenance

A

An activity in which the artefacts or products of a software development process are changed. It includes all changes made to a software system after it has been released.

97
Q

Malleability

A

Characteristic of software as being easy to change. Malleability creates a constant pressure for software to be changed rather than be replaced. Every change that is made to the software introduces the possibility of new errors.

98
Q

Merge Node

A

In an activity diagram, this is a node that brings together multiple alternative flows; represented by a diamond shape; a merge node has a single outgoing transition.

99
Q

Method

A

In object-oriented terminology, it is an operation that manipulates an object in some way.

In Java, a method is a member of a class and has a method heading (which incorporates its signature) and a method body.

In software development, it is a collection of integrated techniques, with their associated notations and rules, that takes a set of predefined inputs and converts them to a set of predefined outputs.

100
Q

Model

A

A simplification of reality, created in order to understand an aspect or viewpoint of the system being created. In the MVC, the model the component that does the processing.

101
Q

Modelling

A

A way of thinking about things and ideas in the real world. A model is a way of expressing a particular view of an identifiable system.

102
Q

Modelling Language

A

A way of expressing the various models produced during the development process. A modelling language defines a collection of model elements, which are roughly equivalent to the utterances in a spoken language. (A model is made up of model elements, as sentences are made up of words.) UML is a modelling language.

103
Q

Modification

Loss of Integrity

A

Attack consisting of the unauthorised modification of data.

104
Q

Modularity

A

The division of a software system into separately named and addressable components, called modules, that are integrated to meet the requirements. Modularity is a basic attribute of software that allows the partition of a set of requirements into a number of intellectually manageable subsets.

105
Q

Module

A

A program unit (or component) that is used exclusively through an external interface. It is important for enabling a system to be comprehended at any required level of detail. A software system is a collection of modules.

106
Q

MoSCoW

A

Must have, Should have, Could have, Wont have

A scheme in DSDM classifying requirments

107
Q

Non-Fuctional Requirment

A

A quality that a system must have.

108
Q

OCL

A

Object Constraint Language

109
Q

Operational and Environmental Requirement

A

A non-functional requirement about how the environment on which the product will have to work (under water, for example), and what considerations must be made for this environment.

110
Q

Oracle

A

The criteria in a test case that helps define whether the test is passed.

111
Q

Partition

A

The decomposition of a problem into a number of subproblems that are independent of each other.

112
Q

Performance Requirement

A

A non-functional requirement about how fast, how safe, how accurate, how available and how reliable the product must be.

113
Q

Plan-Driven Development

A

Term used to distinguish traditional, more prescriptive approaches to software development from agile development approaches.

114
Q

Planning

A

The first stage of a formal technical review.

115
Q

Planning Game

A

An XP practice with two participants, the business and the development. This game takes place not only at the beginning of the project but at regular intervals (say every three weeks) to determine the priorities and work for the next release and to define a plan. It is played with story cards. (See iteration planning game.)

116
Q

Portability

A

A software quality factor affecting product transition requirements which determines the effort required to transfer the system from one hardware platform and/or software environment to another, that is, how easily the system can be used on another machine should the customer change their platform or should other customers require it.

117
Q

Postcondition

A

A constraint that must be true at the completion of an operation, or use case.

118
Q

Precondition

A

A constraint that must be true when an operation is invoked, or when a use case is carried out.

119
Q

Procedure

A

In general, a procedure is a prescribed set of steps for carrying out a task. In programming, it refers to a block of code that carries out a specified programming task and may or may not have input and output parameters. In object-oriented systems, methods are used to implement procedures.

120
Q

Process

A

In program execution, a process is a dynamic (abstract) entity that executes a program on a processor. It is associated with resources such as a main memory and files. In this context, processes are also sometimes referred to as tasks.

In software development, a process is a set of activities or operations that takes one or more inputs, such as a design document, and results in one or more products, such as a software module and its test cases.

121
Q

Process Improvement

A

The idea that an organisation should learn from difficulties encountered with their existing processes, and improve as a result.

122
Q

Process View

A

In a system architecture, this view addresses concurrent aspects of the system at run-time, including all system processes and system start-up and shut-down.

123
Q

Product Backlog

A

An artefact in Scrum (an agile method) that consists of an ordered structured list of what needs to be done to a system.

124
Q

Project Management

A

The activity concerned with ensuring that a software project is completed within the estimated time. It involves determining the work involved, assigning work units to people or teams for periods of time, and giving a work plan for the project.

125
Q

Project Plan

A

A plan breaking down the development of a system into stages and showing how much resource is required at each stage.

126
Q

Prototype

A

A simplified software system that is a subset of the eventual product.

127
Q

Provider

A

In SOA the platform on which a service is implemented.

128
Q

Quality Management

A

An activity that takes place throughout the software development process to ensure the quality of the final product.

129
Q

Registry

A

A mechanism that allows clients to find services.

130
Q

Release

A

A configuration version delivered on completion of the project for use by the customer.

131
Q

Reliability

A

A software quality factor affecting product operation requirements which determines the likelihood with which a system can be expected to perform its intended function, that is, how well the software does what it is supposed to do.

132
Q

Repudiation

A

Attack consisting of (false) claim by legitimate user that a message was not sent or received.

133
Q

Requirement

A

A desired feature, property or behaviour of a software system.

134
Q

Requirement Analysis

A

An activity undertaken to decide what needs to be done to solve the problem that has been articulated during requirements elicitation. The result is a deliverable that forms the basis for a solution to be implemented. It is expressed in technical terms that are understandable to the developers.

135
Q

Requirements Documentation

A

An activity undertaken to record agreed requirements.

136
Q

Requirements Elicitation

A

An activity undertaken to discover, identify, review, articulate and understand the users’ needs and constraints on the software and its development. The result is a clear statement of the problem to be addressed.

137
Q

Requirements Engineering

A

An activity in the process of developing software that aims to elicit and specify the requirements of the client(s)/user(s) in a form that can be used in the design of the software and in assessing its quality once it is built. It can be divided into two main activities: requirements elicitation and requirements analysis.

138
Q

Requirements Negotiation

A

An activity undertaken to agree requirements.

139
Q

Requirements Pattern

A

A description of knowledge used in the elicitation of requirements.

140
Q

Requirements Specification

A

A detailed description of the requirements for a system.

141
Q

Requirements Validation

A

A careful check of a requirements document, usually following a checklist.

142
Q

Review

A

A software inspection meeting to confirm and list major defects, and to determine who will be responsible for addressing each defect.

143
Q

Risk Managment

A

Analysis of risks in a development process and determination of steps to reduce them.

144
Q

Role

A

The behaviour of an entity participating in a particular context. It may also refer to the behaviour of people in a domain.

145
Q

Scenario

A

A specific sequence of actions that illustrates how a task can be performed. It is also a textual description of a specific instance of a use case or interaction with a user interface.

146
Q

Scrum

A

An agile software development method.

147
Q

Security

A

A term used in connection with controlling access to the data stored in computers and in connection with the availability of mechanisms that control or protect programs and data.

148
Q

Security Requirement

A

A non-functional requirement concerned with aspects of a product such as security and confidentiality.

149
Q

Service

A

A unit of reuse corresponding to a piece of functionality, described in a standard language, with published interfaces through which the service execution can be requested.

An abstract description of some unit of business functionality, usually described in terms that are meaningful from both a business and a technical perspective. (See also service-oriented architecture.)

150
Q

Service Description

A

Specifies how a consumer can interact with a service.

151
Q

Size (of Software)

A

This can be measured in terms of lines of code, number of symbols, size of source or object files etc.

152
Q

Socio-Technical Systems

A

A system seen as a whole, including the software, the hardware where it is installed and running, and the wider context that involves other technical components, but also people, organisations and other social structures.

153
Q

Software Architecture

A

‘… the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.’ (Bass, Clements and Kazman, 2012.)

154
Q

Software Component

A

In the context of testing, the minimal software item for which a separate specification is available. In the context of reuse, usually a routine, a class (consisting of a collection of routines), or a collection of classes (a package), which has a specification (including interfaces) and a list of its underlying principles and concepts, as well as quality information such as levels of proof and testing.

155
Q

Software Development

A

The process whose end product is a software product.

156
Q

Software Quality

A

At a general level, this defines the extent to which the customer is satisfied with the software product delivered at the end of the development process. At a more detailed level, it involves conformance to explicitly stated requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.

157
Q

Software System

A

A general term referring to the end-product of software development. It embraces both application software and system software.

158
Q

Sprint

A

In Scrum, a timeboxed period of to a maximum of a month where useable software is delivered.

159
Q

Stakeholder

A

An individual and/or an organisation affected by the success or failure of a software system.

160
Q

Static Model

A

A model that describes structure rather than behaviour. See structural model.

161
Q

Static Modelling

A

Modelling of structure as opposed to behaviour.

162
Q

Steering

A

A move of the planning game that updates the plan based on reality.

163
Q

An extension mechanism in UML; it allows the creation of a new category of modelling element.

A

Stereotype

164
Q

Supplier

A

In software development, the term refers to the person (or company) who develops a piece of software as a package.

In programming, the term often refers to the method/class/object that is used by methods of another class/object (the client).

In network programming, the term refers to a program/process running on one computer that provides services to another program running (usually) on another computer.

165
Q

Swimlane

A

A means of indicating a role’s responsibilities in an activity diagram. Swimlanes show the concurrent activities of actors as separate partitions.

166
Q

Synchroisation Bar

A

A means of describing the coordination of activities. Once all the activities leading to the synchronisation bar have completed, the transitions leaving it will be fired. Thus, it is a point where the flow of control may change. A synchronisation bar is used to identify the points at which concurrent threads begin (a fork) or end (a join).

167
Q

System

A

An assembly of components that are connected in an organised way to perform some activity, that is, they behave dynamically.

168
Q

System Boundary

A

A conceptual division between the system to be studied and ‘everything else’.

169
Q

System Operation

A

An operation executed by a software system as a response to an external event.

170
Q

System Requirement

A

‘…are a more detailed description of the functionality to be provided.’ (Somerville, 2011.)

171
Q

Task

A

A single path of execution through a program, dynamic model or other representation of control flow such as an activity diagram. In general, it is a piece of work to be done by someone, such as an actor involved in a use case. It is also used as a synonym for process.

172
Q

Techical Solution Requirements

A

These relate to functionality that is needed purely because of the chosen technology.

173
Q

Testability

A

A software quality factor affecting product revision requirements which determines the effort required to test a system to ensure that it performs its intended function, i.e. how easily the system can be tested to show that the customer’s requirements have been met.

174
Q

Testing

A

The process of determining if an artefact meets a given specification. It is one of the four basic technical activities within a software development process (see also analysis, design and implementation). In practice, it is the use of techniques for the validation or verification of products or the processes by which they are made.

175
Q

Timeboxed

A

Within a short time frame.

176
Q

Timeboxing

A

Allocating short fixed periods – for example, three to four weeks – to each iteration.

177
Q

Tool

A

Software used to support the software development process.

178
Q

Traceability

A

The ability to trace the history of each requirement from problem description through conceptual and specification models to the implementation and deployment models in order to reconstruct the significant events that led to the final operational software system. The ability to record information that will allow any investigation to reconstruct events, changes and reasons for change.

179
Q

Trade

A

‘A job, especially needing a special skill with the hands: Being a printer is a trade; being a lawyer is a profession.’ (Longman Dictionary of Contemporary English, 1987.)

180
Q

Training

A

A process which assists in enabling new users to use a system effectively. It may include manuals, self-study modules or face-to-face lecturing.

181
Q

Transition

A

In state machines or activity diagram, the movement between states or activities triggered by an event. In UP, phase when the final product is tested and deployed.

182
Q

UML

A

Unified Modeling Langauage

A language for visualising, specifying, constructing and documenting the artefacts of a software-intensive system. (See also modelling language.)

183
Q

UP

A

Unified Process

A popular iterative and incremental process for building enterprise systems based on an object-oriented approach. It consists of four phases: inception, elaboration, construction and transition.

184
Q

Usability

A

The effectiveness, efficiency and satisfaction with which users can achieve tasks in a particular environment. High usability means a system is easy to learn and remember; efficient, visually pleasing and fun to use; and quick to recover from errors. Also, usability is a software quality factoraffecting product operation requirements which determines the effort required to learn about, to operate, to prepare input for, and to interpret the output of a system, that is, how easy the system is to use.

185
Q

Usability Requirement

A

A non-functional requirement about the product’s ease of use or other usability considerations.

186
Q

Use Case

A

A description, of a piece of functionality that a system performs to yield an observable result of some value to an actor. (See also task.)

187
Q

Use Case Diagram

A

A diagram that shows a set of use cases and actors and their associations.

188
Q

User

A

A person who uses the software system on a day-to-day basis.

189
Q

User-Centered Design

A

During analysis and design, a way of taking into account the different perspectives of different userswhen looking at the tasks that they perform; typically found in techniques used for requirements engineering.

190
Q

User Requirements

A

‘… abstract statements of the software requirements for the customer and end-user of the system.’ (Somerville, 2004.)

191
Q

User Story

A

A story written by an intended user of a system; it describes some functionality that is of value to the person(s) writing the story. It represents a user’s expectation of the system.

192
Q

Validation

A

The process of checking that a software system is consistent with the customer’s requirements; that is, the developer is building the ‘right’ product. (See also verification.)

193
Q

Variables

A

In Java, a data field that holds a particular type of value or refers to a particular type of object. Unlike a data field declared as static, the value associated with a variable data field may be changed. (See also class variable and instance variable.)

194
Q

Variant

A

In a configuration management system, two configuration items which are essentially the same but differ in some well defined sense are called variants. Variants are distinguished by having different descriptive names, and also have descriptions characterising them. Variants themselves undergo revisions and thus have versions.

195
Q

Verification

A

A process of ensuring that the design of a system corresponds to its specification, and that the system is correctly coded according to its design; that is, all the different system descriptions are consistent and complete with respect to each other. If validation is about building the ‘right’ product, then verification is about the product being built ‘right’.

196
Q

Version

A

An ‘instance’ of a configuration item. Also referred to as a revision.

197
Q

Viewpoint

A

A perspective on a system from the point of view of a particular person or group of people.

198
Q

Volere Template

A

This is a template for a document that collates all the requirements of a system, together with other issues that may affect those requirements. The template provides a sort of container, in which the information can be organised systematically.

199
Q

Waterfall Model

A

A particular life cycle that uses the analysis, design, implementation and testing activities in a simple sequence with little or no iteration. Some versions append the maintenance activity.

200
Q

Workflow

A

The steps that people go through when doing their jobs. A workflow may contain a number of activities that must be coordinated and arranged in a specified order to achieve a goal. A workflow can be used to represent the flow of activities that takes place in a business process.

201
Q

XP

A

Extreme Programming

TM354 2021 (6 decks)

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