Software
Requirements
Objectives
lTo introduce the concepts of user
and system requirements
lTo describe functional and
non-functional requirements
lTo explain how software requirements
may be organised in a requirements document
Topics
covered
lFunctional and non-functional
requirements
lUser requirements
lSystem requirements
lInterface specification
lThe software requirements document
Requirements
engineering
lThe process of establishing the
services that the customer requires from a system and the constraints under
which it operates and is developed.
lThe requirements themselves are the
descriptions of the system services and constraints that are generated during
the requirements engineering process.
What is a
requirement?
lIt may range from a high-level
abstract statement of a service or of a system constraint to a detailed
mathematical functional specification.
lThis is inevitable as requirements
may serve a dual function
•May be the basis for a bid for a
contract - therefore must be open to interpretation;
•May be the basis for the contract
itself - therefore must be defined in detail;
•Both these statements may be called
requirements.
Requirements
abstraction (
Types of
requirement
lUser requirements
•Statements in natural language plus
diagrams of the services the system provides and its operational constraints.
Written for customers.
lSystem requirements
•A structured document setting out
detailed descriptions of the system’s functions, services and operational
constraints. Defines what should be implemented so may be part of a contract
between client and contractor.
Definitions
and specifications
Requirements
readers
Functional
and non-functional requirements
lFunctional requirements
•Statements of services the system should provide,
how the system should react to particular inputs and how the system should
behave in particular situations.
lNon-functional requirements
•constraints on the services or functions offered by the
system such as timing constraints, constraints on the development process,
standards, etc.
lDomain requirements
•Requirements that come from the application domain of the system and
that reflect characteristics of that domain.
Functional
requirements
lDescribe functionality or system
services.
lDepend on the type of software,
expected users and the type of system where the software is used.
lFunctional user requirements may be
high-level statements of what the system should do but functional system requirements
should describe the system services in detail.
The LIBSYS system
lA library system that provides a single interface to a number of databases of articles in different libraries.
lUsers can search for, download and print these articles for personal study.
Examples of
functional requirements
lThe user shall be able to search
either all of the initial set of databases or select a subset from it.
lThe system shall provide appropriate
viewers for the user to read documents in the document store.
lEvery order shall be allocated a
unique identifier (ORDER_ID) which the user shall be able to copy to the
account’s permanent storage area.
Requirements
imprecision
lProblems arise when requirements are
not precisely stated.
lAmbiguous requirements may be
interpreted in different ways by developers and users.
lConsider the term ‘appropriate
viewers’
•User intention - special purpose
viewer for each different document type;
•Developer interpretation - Provide a
text viewer that shows the contents of the document.
Requirements
completeness and consistency
lIn principle, requirements should be
both complete and consistent.
lComplete
•They should include descriptions of
all facilities required.
lConsistent
•There should be no conflicts or
contradictions in the descriptions of the system facilities.
lIn practice, it is impossible to
produce a complete and consistent requirements document.
Non-functional
requirements
lThese define system properties and
constraints e.g. reliability, response time and storage requirements.
Constraints are I/O device capability, system representations, etc.
lProcess requirements may also be
specified mandating a particular CASE system, programming language or
development method.
lNon-functional requirements may be
more critical than functional requirements. If these are not met, the system is
useless.
Non-functional
classifications
lProduct requirements
•Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
lOrganisational requirements
•Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation requirements, etc.
lExternal requirements
•Requirements which arise from factors which are external to the system
and its development process e.g. interoperability requirements, legislative
requirements, etc.
Non-functional
requirement types
Non-functional
requirements examples
lProduct requirement
8.1 The user
interface for LIBSYS shall be implemented as simple HTML without frames or Java
applets.
lOrganisational requirement
9.3.2 The system development process and
deliverable documents shall conform to the process and deliverables defined in
XYZCo-SP-STAN-95.
lExternal requirement
7.6.5 The system shall not disclose any personal
information about customers apart from their name and reference number to the
operators of the system.
Goals and
requirements
lNon-functional requirements may be
very difficult to state precisely and imprecise requirements may be difficult
to verify.
lGoal
•A general intention of the user such as ease of use.
lVerifiable non-functional
requirement
•A statement using some measure that can be objectively tested.
lGoals are helpful to developers as
they convey the intentions of the system users.
Examples
lA system goal
•The system should be easy to use by experienced controllers and should
be organised in such a way that user errors are minimised.
lA verifiable non-functional
requirement
•Experienced controllers shall be able to use all the system functions
after a total of two hours training. After this training, the average number of
errors made by experienced users shall not exceed two per day.
Requirements
measures
Requirements
interaction
lConflicts between different
non-functional requirements are common in complex systems.
lSpacecraft system
•To minimise weight, the number of
separate chips in the system should be minimised.
•To minimise power consumption, lower
power chips should be used.
•However, using low power chips may
mean that more chips have to be used. Which is the most critical requirement?
Domain
requirements
lDerived from the application domain
and describe system characteristics and features that reflect the domain.
lDomain requirements be new
functional requirements, constraints on existing requirements or define
specific computations.
lIf domain requirements are not
satisfied, the system may be unworkable.
Library
system domain requirements
lThere shall be a standard user
interface to all databases which shall be based on the Z39.50 standard.
lBecause of copyright restrictions,
some documents must be deleted immediately on arrival. Depending on the user’s
requirements, these documents will either be printed locally on the system
server for manually forwarding to the user or routed to a network printer.
Train
protection system
lThe deceleration of the train shall
be computed as:
•Dtrain = Dcontrol
+ Dgradient
where Dgradient is
9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2
/alpha are known for different types of train.
Domain
requirements problems
lUnderstandability
•Requirements are expressed in the
language of the application domain;
•This is often not understood by
software engineers developing the system.
lImplicitness
•Domain specialists understand the
area so well that they do not think of making the domain requirements explicit.
User
requirements
lShould describe functional and
non-functional requirements in such a way that they are understandable by
system users who don’t have detailed technical knowledge.
lUser requirements are defined using
natural language, tables and diagrams as these can be understood by all users.
Problems
with natural language
lLack of clarity
•Precision is difficult without
making the document difficult to read.
lRequirements confusion
•Functional and non-functional
requirements tend to be mixed-up.
lRequirements amalgamation
•Several different requirements may
be expressed together.
LIBSYS
requirement
Editor grid
requirement
Requirement
problems
lDatabase requirements includes both
conceptual and detailed information
•Describes the concept of a financial accounting system that is to be
included in LIBSYS;
•However, it also includes the detail that managers can configure this
system - this is unnecessary at this level.
lGrid requirement mixes three
different kinds of requirement
•Conceptual functional requirement (the need for a grid);
•Non-functional requirement (grid units);
•Non-functional UI requirement (grid switching).
Structured
presentation
Guidelines
for writing requirements
lInvent a standard format and use it
for all requirements.
lUse language in a consistent way.
Use shall for mandatory requirements, should for desirable requirements.
lUse text highlighting to identify
key parts of the requirement.
lAvoid the use of computer jargon.
System
requirements
lMore detailed specifications of
system functions, services and constraints than user requirements.
lThey are intended to be a basis for
designing the system.
lThey may be incorporated into the
system contract.
lSystem requirements may be defined
or illustrated using system models discussed in Chapter 8.
Requirements
and design
lIn principle, requirements should
state what the system should do and the design should describe how it does
this.
lIn practice, requirements and design
are inseparable
•A system architecture may be
designed to structure the requirements;
•The system may inter-operate with
other systems that generate design requirements;
•The use of a specific design may be
a domain requirement.
Problems
with NL specification
lAmbiguity
•The readers and writers of the
requirement must interpret the same words in the same way. NL is naturally
ambiguous so this is very difficult.
lOver-flexibility
•The same thing may be said in a
number of different ways in the specification.
lLack of modularisation
•NL structures are inadequate to
structure system requirements.
Alternatives
to NL specification
Structured language specifications
lThe freedom of the requirements writer is limited by a predefined template for requirements.
lAll requirements are written in a standard way.
lThe terminology used in the description may be limited.
lThe advantage is that the most of the expressiveness of natural language is maintained but a degree of uniformity is imposed on the specification.
Form-based
specifications
lDefinition of the function or
entity.
lDescription of inputs and where they
come from.
lDescription of outputs and where
they go to.
lIndication of other entities
required.
lPre and post conditions (if
appropriate).
lThe side effects (if any) of the
function.
Form-based
node specification
Tabular specification
lUsed to supplement natural language.
lParticularly useful when you have to define a number of possible alternative courses of action.
Tabular specification
Graphical models
lGraphical models are most useful when you need to show how state changes or where you need to describe a sequence of actions.
lDifferent graphical models are explained in Chapter 8.
Sequence diagrams
lThese show the sequence of events that take place during some user interaction with a system.
lYou read them from top to bottom to see the order of the actions that take place.
lCash withdrawal from an ATM
•Validate card;
•Handle request;
•Complete transaction.
Sequence
diagram of ATM withdrawal
Interface
specification
lMost systems must operate with other
systems and the operating interfaces must be specified as part of the
requirements.
lThree types of interface may have to
be defined
•Procedural interfaces;
•Data structures that are exchanged;
•Data representations.
lFormal notations are an effective
technique for interface specification.
PDL
interface description
The
requirements document
lThe requirements document is the
official statement of what is required of the system developers.
lShould include both a definition of
user requirements and a specification of the system requirements.
lIt is NOT a design document. As far
as possible, it should set of WHAT the system should do rather than HOW it
should do it
Users of a requirements document
IEEE
requirements standard
lDefines a generic structure for a
requirements document that must be instantiated for each specific system.
•Introduction.
•General description.
•Specific requirements.
•Appendices.
•Index.
Requirements
document structure
lPreface
lIntroduction
lGlossary
lUser requirements definition
lSystem architecture
lSystem requirements specification
lSystem models
lSystem evolution
lAppendices
lIndex
Key points
lRequirements set out what the system
should do and define constraints on its operation and implementation.
lFunctional requirements set out
services the system should provide.
lNon-functional requirements
constrain the system being developed or the development process.
lUser requirements are high-level
statements of what the system should do. User requirements should be written
using natural language, tables and diagrams.
Key points
lSystem requirements are intended to
communicate the functions that the system should provide.
lA software requirements document is
an agreed statement of the system requirements.
lThe IEEE standard is a useful
starting point for defining more detailed specific requirements standards.
Requirements
Engineering Processes
Objectives
lTo describe the principal
requirements engineering activities and their relationships
lTo introduce techniques for
requirements elicitation and analysis
lTo describe requirements validation
and the role of requirements reviews
lTo discuss the role of requirements
management in support of other requirements engineering processes
Topics covered
lFeasibility studies
lRequirements elicitation and
analysis
lRequirements validation
lRequirements management
Requirements
engineering processes
lThe processes used for RE vary
widely depending on the application domain, the people involved and the
organisation developing the requirements.
lHowever, there are a number of
generic activities common to all processes
•Requirements elicitation;
•Requirements analysis;
•Requirements validation;
•Requirements management.
The
requirements engineering process
Requirements engineering
Feasibility
studies
lA feasibility study decides whether
or not the proposed system is worthwhile.
lA short focused study that checks
•If the system contributes to
organisational objectives;
•If the system can be engineered
using current technology and within budget;
•If the system can be integrated with
other systems that are used.
Feasibility
study implementation
lBased on information assessment
(what is required), information collection and report writing.
lQuestions for people in the
organisation
•What if the system wasn’t implemented?
•What are current process problems?
•How will the proposed system help?
•What will be the integration problems?
•Is new technology needed? What skills?
•What facilities must be supported by the proposed system?
Elicitation
and analysis
lSometimes called requirements
elicitation or requirements discovery.
lInvolves technical staff working
with customers to find out about the application domain, the services that the
system should provide and the system’s operational constraints.
lMay involve end-users, managers,
engineers involved in maintenance, domain experts, trade unions, etc. These are
called stakeholders.
Problems of
requirements analysis
lStakeholders don’t know what
they really want.
lStakeholders express requirements in
their own terms.
lDifferent stakeholders may have
conflicting requirements.
lOrganisational and political factors
may influence the system requirements.
lThe requirements change during the
analysis process. New stakeholders may emerge and the business environment
change.
The
requirements spiral
Process
activities
lRequirements discovery
•Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
lRequirements classification and
organisation
•Groups related requirements and organises them into coherent clusters.
lPrioritisation and negotiation
•Prioritising requirements and resolving requirements conflicts.
lRequirements documentation
•Requirements are documented and input into the next round of the spiral.
Requirements discovery
lThe process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.
lSources of information include documentation, system stakeholders and the specifications of similar systems.
ATM
stakeholders
lBank customers
lRepresentatives of other banks
lBank managers
lCounter staff
lDatabase administrators
lSecurity managers
lMarketing department
lHardware and software maintenance
engineers
lBanking regulators
Viewpoints
lViewpoints are a way of structuring
the requirements to represent the perspectives of different stakeholders.
Stakeholders may be classified under different viewpoints.
lThis multi-perspective analysis is
important as there is no single correct way to analyse system requirements.
Types of
viewpoint
lInteractor viewpoints
•People or other systems that interact directly with the system. In an
ATM, the customer’s and the account database are interactor
VPs.
lIndirect viewpoints
•Stakeholders who do not use the system themselves but who influence the
requirements. In an ATM, management and security staff are indirect viewpoints.
lDomain viewpoints
•Domain characteristics and constraints that influence the requirements.
In an ATM, an example would be standards for inter-bank communications.
Viewpoint identification
lIdentify viewpoints using
•Providers and receivers of system services;
•Systems that interact directly with the system being specified;
•Regulations and standards;
•Sources of business and non-functional requirements.
•Engineers who have to develop and maintain the system;
•Marketing and other business viewpoints.
LIBSYS viewpoint hierarchy
Interviewing
lIn formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed.
lThere are two types of interview
•Closed interviews where a pre-defined set of questions are answered.
•Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
Interviews in practice
lNormally a mix of closed and open-ended interviewing.
lInterviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system.
lInterviews are not good for understanding domain requirements
•Requirements engineers cannot understand specific domain terminology;
•Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.
Effective interviewers
lInterviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements.
lThey should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.
Scenarios
lScenarios are real-life examples of how a system can be used.
lThey should include
•A description of the starting situation;
•A description of the normal flow of events;
•A description of what can go wrong;
•Information about other concurrent activities;
•A description of the state when the scenario finishes.
LIBSYS scenario (1)
LIBSYS scenario (2)
Use cases
lUse-cases are a scenario based
technique in the UML which identify the actors in an interaction and which
describe the interaction itself.
lA set of use cases should describe
all possible interactions with the system.
lSequence diagrams may be used to add
detail to use-cases by showing the sequence of event processing in the system.
Article printing use-case
LIBSYS use cases
Article printing
Print
article sequence
Social and
organisational factors
lSoftware systems are used in a
social and organisational context. This can influence or even dominate the
system requirements.
lSocial and organisational factors
are not a single viewpoint but are influences on all viewpoints.
lGood analysts must be sensitive to
these factors but currently no systematic way to tackle their analysis.
Ethnography
lA social scientists spends a considerable
time observing and analysing how people actually work.
lPeople do not have to explain or
articulate their work.
lSocial and organisational factors of
importance may be observed.
lEthnographic studies have shown that
work is usually richer and more complex than suggested by simple system models.
Focused
ethnography
lDeveloped in a project studying the
air traffic control process
lCombines ethnography with
prototyping
lPrototype development results in
unanswered questions which focus the ethnographic analysis.
lThe problem with ethnography is that
it studies existing practices which may have some historical basis which is no
longer relevant.
Ethnography
and prototyping
Scope of
ethnography
lRequirements that are derived from
the way that people actually work rather than the way I which process
definitions suggest that they ought to work.
lRequirements that are derived from
cooperation and awareness of other people’s activities.
Requirements
validation
lConcerned with demonstrating that
the requirements define the system that the customer really wants.
lRequirements error costs are high so
validation is very important
•Fixing a requirements error after
delivery may cost up to 100 times the cost of fixing an implementation error.
Requirements
checking
lValidity. Does the system provide
the functions which best support the customer’s needs?
lConsistency. Are there any
requirements conflicts?
lCompleteness. Are all functions
required by the customer included?
lRealism. Can the requirements be
implemented given available budget and technology
lVerifiability. Can the requirements
be checked?
Requirements
validation techniques
lRequirements reviews
•Systematic manual analysis of the
requirements.
lPrototyping
•Using an executable model of the
system to check requirements. Covered in Chapter 17.
lTest-case generation
•Developing tests for requirements to
check testability.
Requirements
reviews
lRegular reviews should be held while
the requirements definition is being formulated.
lBoth client and contractor staff
should be involved in reviews.
lReviews may be formal (with
completed documents) or informal. Good communications between developers,
customers and users can resolve problems at an early stage.
Review
checks
lVerifiability. Is the requirement
realistically testable?
lComprehensibility. Is the
requirement properly understood?
lTraceability. Is the origin of the
requirement clearly stated?
lAdaptability. Can the requirement be
changed without a large impact on other requirements?
Requirements
management
lRequirements management is the
process of managing changing requirements during the requirements engineering
process and system development.
lRequirements are inevitably
incomplete and inconsistent
•New requirements emerge during the process as business needs change and
a better understanding of the system is developed;
•Different viewpoints have different requirements and these are often
contradictory.
Requirements
change
lThe priority of requirements from
different viewpoints changes during the development process.
lSystem customers may specify
requirements from a business perspective that conflict with end-user
requirements.
lThe business and technical
environment of the system changes during its development.
Requirements
evolution
Enduring
and volatile requirements
lEnduring requirements. Stable
requirements derived from the core activity of the customer organisation. E.g.
a hospital will always have doctors, nurses, etc. May be derived from domain
models
lVolatile requirements. Requirements
which change during development or when the system is in use. In a hospital,
requirements derived from health-care policy
Requirements
classification
Requirements
management planning
lDuring the requirements engineering
process, you have to plan:
•Requirements identification
• How requirements are individually identified;
•A change management process
•The process followed when analysing a requirements change;
•Traceability policies
•The amount of information about requirements relationships that is
maintained;
•CASE tool support
•The tool support required to help manage requirements change;
Traceability
lTraceability is concerned with the
relationships between requirements, their sources and the system design
lSource traceability
•Links from requirements to stakeholders who proposed these requirements;
lRequirements traceability
•Links between dependent requirements;
lDesign traceability
•Links from the requirements to the design;
A
traceability matrix
CASE tool
support
lRequirements storage
•Requirements should be managed in a secure, managed data store.
lChange management
•The process of change management is a workflow process whose stages can
be defined and information flow between these stages partially automated.
lTraceability management
•Automated retrieval of the links between requirements.
Requirements
change management
lShould apply to all proposed changes
to the requirements.
lPrincipal stages
•Problem analysis. Discuss
requirements problem and propose change;
•Change analysis and costing. Assess
effects of change on other requirements;
•Change implementation. Modify
requirements document and other documents to reflect change.
Change management
Key points
lThe requirements engineering process
includes a feasibility study, requirements elicitation
and analysis, requirements specification and requirements management.
lRequirements elicitation and
analysis is iterative involving domain understanding, requirements collection,
classification, structuring, prioritisation and validation.
lSystems have multiple stakeholders
with different requirements.
Key points
lSocial and organisation factors
influence system requirements.
lRequirements validation is concerned
with checks for validity, consistency, completeness, realism and verifiability.
lBusiness changes inevitably lead to
changing requirements.
lRequirements management includes
planning and change management.
System
models
Objectives
lTo explain why the context of a
system should be modelled as part of the RE process
lTo describe behavioural modelling,
data modelling and object modelling
lTo introduce some of the notations
used in the Unified Modeling Language (UML)
lTo show how CASE workbenches support
system modelling
Topics
covered
lContext models
lBehavioural models
lData models
lObject models
lCASE workbenches
System
modelling
lSystem modelling helps the analyst
to understand the functionality of the system and models are used to
communicate with customers.
lDifferent models present the system
from different perspectives
•External perspective showing the system’s context or environment;
•Behavioural perspective showing the behaviour of the system;
•Structural perspective showing the system or data architecture.
Model types
lData processing model showing how
the data is processed at different stages.
lComposition model showing how
entities are composed of other entities.
lArchitectural model showing
principal sub-systems.
lClassification model showing how
entities have common characteristics.
lStimulus/response model showing the
system’s reaction to events.
Context
models
lContext models are used to
illustrate the operational context of a system - they show what lies outside
the system boundaries.
lSocial and organisational concerns
may affect the decision on where to position system boundaries.
lArchitectural models show the system
and its relationship with other systems.
The context
of an ATM system
Process
models
lProcess models show the overall
process and the processes that are supported by the system.
lData flow models may be used to show
the processes and the flow of information from one process to another.
Equipment
procurement process
Behavioural
models
lBehavioural models are used to
describe the overall behaviour of a system.
lTwo types of behavioural model are:
•Data processing models that show how
data is processed as it moves through the system;
•State machine models that show the
systems response to events.
lThese models show different
perspectives so both of them are required to describe the system’s
behaviour.
Data-processing
models
lData flow diagrams (DFDs) may be used to model the system’s data
processing.
lThese show the processing steps as
data flows through a system.
lDFDs are an intrinsic part of many
analysis methods.
lSimple and intuitive notation that
customers can understand.
lShow end-to-end processing of data.
Order
processing DFD
Data flow
diagrams
lDFDs model the system from a functional
perspective.
lTracking and documenting how the
data associated with a process is helpful to develop an overall understanding
of the system.
lData flow diagrams may also be used
in showing the data exchange between a system and other systems in its
environment.
Insulin
pump DFD
State
machine models
lThese model the behaviour of the
system in response to external and internal events.
lThey show the system’s
responses to stimuli so are often used for modelling real-time systems.
lState machine models show system
states as nodes and events as arcs between these nodes. When an event occurs,
the system moves from one state to another.
lStatecharts are an integral part of the UML and
are used to represent state machine models.
Statecharts
lAllow the decomposition of a model
into sub-models (see following slide).
lA brief description of the actions
is included following the ‘do’ in each state.
lCan be complemented by tables
describing the states and the stimuli.
Microwave
oven model
Microwave
oven state description
Microwave
oven stimuli
Microwave
oven operation
Semantic
data models
lUsed to describe the logical
structure of data processed by the system.
lAn entity-relation-attribute model sets out the entities in the
system, the relationships between these entities and the entity attributes
lWidely used in database design. Can
readily be implemented using relational databases.
lNo specific notation provided in the
UML but objects and associations can be used.
Library
semantic model
Data
dictionaries
lData dictionaries are lists of all
of the names used in the system models. Descriptions of the entities,
relationships and attributes are also included.
lAdvantages
•Support name management and avoid duplication;
•Store of organisational knowledge linking analysis, design and
implementation;
lMany CASE workbenches support data
dictionaries.
Data
dictionary entries
Object
models
lObject models describe the system in
terms of object classes and their associations.
lAn object class is an abstraction
over a set of objects with common attributes and the services (operations)
provided by each object.
lVarious object models may be
produced
•Inheritance models;
•Aggregation models;
•Interaction models.
Object
models
lNatural ways of reflecting the
real-world entities manipulated by the system
lMore abstract entities are more
difficult to model using this approach
lObject class identification is
recognised as a difficult process requiring a deep understanding of the
application domain
lObject classes reflecting domain
entities are reusable across systems
Inheritance
models
lOrganise the domain object classes
into a hierarchy.
lClasses at the top of the hierarchy
reflect the common features of all classes.
lObject classes inherit their
attributes and services from one or more super-classes. these
may then be specialised as necessary.
lClass hierarchy design can be a
difficult process if duplication in different branches is to be avoided.
Object
models and the UML
lThe UML is a standard representation
devised by the developers of widely used object-oriented analysis and design
methods.
lIt has become an effective standard
for object-oriented modelling.
lNotation
•Object classes are rectangles with the name at the top, attributes in
the middle section and operations in the bottom section;
•Relationships between object classes (known as associations) are shown
as lines linking objects;
•Inheritance is referred to as generalisation and is shown
‘upwards’ rather than ‘downwards’ in a hierarchy.
Library
class hierarchy
User class
hierarchy
Multiple inheritance
lRather than inheriting the
attributes and services from a single parent class, a system which supports
multiple inheritance allows object classes to inherit
from several super-classes.
lThis can lead to semantic conflicts
where attributes/services with the same name in different super-classes have
different semantics.
lMultiple inheritance
makes class hierarchy reorganisation more complex.
Multiple inheritance
Object
aggregation
lAn aggregation model shows how
classes that are collections are composed of other classes.
lAggregation models are similar to
the part-of relationship in semantic data models.
Object
aggregation
Object
behaviour modelling
lA behavioural model shows the
interactions between objects to produce some particular system behaviour that
is specified as a use-case.
lSequence diagrams (or collaboration
diagrams) in the UML are used to model interaction between objects.
Issue of
electronic items
Structured
methods
lStructured methods incorporate
system modelling as an inherent part of the method.
lMethods define a set of models, a
process for deriving these models and rules and guidelines that should apply to
the models.
lCASE tools support system modelling
as part of a structured method.
Method
weaknesses
lThey do not model non-functional
system requirements.
lThey do not usually include
information about whether a method is appropriate for a given problem.
lThe may produce too much
documentation.
lThe system models are sometimes too
detailed and difficult for users to understand.
CASE
workbenches
lA coherent set of tools that is
designed to support related software process activities such as analysis,
design or testing.
lAnalysis and design workbenches
support system modelling during both requirements engineering and system
design.
lThese workbenches may support a
specific design method or may provide support for a creating several different
types of system model.
An analysis
and design workbench
Analysis
workbench components
lDiagram editors
lModel analysis and checking tools
lRepository and associated query
language
lData dictionary
lReport definition and generation
tools
lForms definition tools
lImport/export translators
lCode generation tools
Key points
lA model is an abstract system view.
Complementary types of model provide different system information.
lContext models show the position of
a system in its environment with other systems and processes.
lData flow models may be used to
model the data processing in a system.
lState machine models model the
system’s behaviour in response to internal or external events
Key points
lSemantic data models describe the
logical structure of data which is imported to or exported by the systems.
lObject models describe logical
system entities, their classification and aggregation.
lSequence models show the
interactions between actors and the system objects that they use.
lStructured methods provide a
framework for developing system models.
