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