Analysis Phase

Software Requirements
Topics covered
 Functional and non-functional requirements
 User requirements
 System requirements
 The software requirements document
Requirements engineering
 The process of establishing the services that the customer
requires from a system and the constraints under which it
operates and is developed.
 The requirements themselves are the descriptions of the
system services and constraints that are generated during the
requirements engineering process.
What is a requirement?
 It may range from a high-level abstract statement of a service
or of a system constraint to a detailed mathematical functional
specification.
 This 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 (Davis)

“If a comp any w ishes to le t a cont ract for a la rge software deve lopmen t project, it
must define its need s in a suffi cien tly ab stract way that a solution is no t pre-defined.
The requi remen ts must be written so that several cont ractors can b id for the con tract,
offering, pe rhap s, different ways of me eting the c lien t organi sation ’s need s. Once a
contract has been a warded, the cont ractor must write a system definition for the client
in more detail so that the c lient und erstand s and c an val idate what the software will
do. Both o f these docu ment s may be ca lled the requirements document for the
system. ”
Types of requirement
 User requirements
 Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers.
 System 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
User requir emen t definition

1. The so ftware m ust pr ovide a means o f represen tin g an d

1. accessin g e xtern al files crea ted b y oth er too ls.

System requir emen ts specificatio n

1. 1 T h e user sho uld be p r ovided with facilities to defin e the ty pe o f

1. 2 external files.
1. 2 E ach extern al file ty pe may have an asso cia ted too l w hich ma y be
1. 2 app lied to the file.
1. 3 E ach extern al file ty pe may be r epr esen ted as a specific ico n o n
1. 2 th e user’s disp la y.
1. 4 Facilities sh ould be p r o vided for the ico n r epresen tin g an
1. 2 extern al file ty pe to be defined b y the user.
1. 5 W hen a user selects an icon r epr esen tin g an e xtern al file, th e
1. 2 effect of th at selection is to app ly the to ol associated with the ty pe o f
1. 2 th e ex ternal file to the file rep resen ted by th e selected icon .
Requirements readers
Functional and non-functional requirements
 Functional 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.
 Non-functional requirements
 constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
 Domain requirements
 Requirements that come from the application domain of the system and that
reflect characteristics of that domain.
Functional requirements
 Describe functionality or system services.
 Depend on the type of software, expected users and the type
of system where the software is used.
 Functional user requirements may be high-level statements of
what the system should do but functional system requirements
should describe the system services in detail.
Example: The LIBSYS system
 A library system that provides a single interface to a number
of databases of articles in different libraries.
 Users can search for, download and print these articles for
personal study.
Examples of functional requirements
 The user shall be able to search either all of the initial set of
databases or select a subset from it.
 The system shall provide appropriate viewers for the user to
read documents in the document store.
 Every 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
 Problems arise when requirements are not precisely stated.
 Ambiguous requirements may be interpreted in different ways
by developers and users.
 Consider 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
 In principle, requirements should be both complete and consistent.
 Complete
 They should include descriptions of all facilities required.
 Consistent
 There should be no conflicts or contradictions in the descriptions of
the system facilities.
 In practice, it is impossible to produce a complete and consistent
requirements document.
Non-functional requirements
 These define system properties and constraints e.g. reliability,
response time and storage requirements. Constraints are I/O
device capability, system representations, etc.
 Process requirements may also be specified mandating a
particular CASE system, programming language or
development method.
 Non-functional requirements may be more critical than
functional requirements. If these are not met, the system is
useless.
Non-functional classifications
 Product requirements
 Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
 Organisational requirements
 Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation requirements, etc.
 External 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-functi onal
requir ement s

P roduct Organisat ional External

requir ement s requir ement s requir ement s

E fficiency Reli abili ty Porta bili ty Inter oper a bili ty Ethical

requir ement s requir ement s requir ement s requir ement s requir ement s

Usa bili ty Del ivery Implementa ti on Standar ds Legisl ative

requir ement s requir ement s requir ement s requir ement s requir ement s

Performance Space P rivacy Safet y

requir ement s requir ement s requir ement s requir ement s
Non-functional requirements examples

 Product requirement
 The user interface for LIBSYS shall be implemented as simple HTML
without frames or Java applets.
 Organisational requirement
 The system development process and deliverable documents shall conform
to the process and deliverables defined in XYZCo-SP-STAN-95.
 External requirement
 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
 Non-functional requirements may be very difficult to state precisely
and imprecise requirements may be difficult to verify.
 Goal
 A general intention of the user such as ease of use.
 Verifiable non-functional requirement
 A statement using some measure that can be objectively tested.
 Goals are helpful to developers as they convey the intentions of the
system users.
Examples
 A 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.
 A 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

Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Numb er of ROM chips
Ease of use Training time
Numb er of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Numb er of target systems
Requirements interaction
 Conflicts between different non-functional requirements are
common in complex systems.
 Spacecraft 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
 Derived from the application domain and describe system
characteristics and features that reflect the domain.
 Domain requirements be new functional requirements,
constraints on existing requirements or define specific
computations.
 If domain requirements are not satisfied, the system may be
unworkable.
Library system domain requirements
 There shall be a standard user interface to all databases which
shall be based on the Z39.50 standard.
 Because 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.
Domain requirements problems
 Understandability
 Requirements are expressed in the language of the application
domain;
 This is often not understood by software engineers developing the
system.
 Implicitness
 Domain specialists understand the area so well that they do not
think of making the domain requirements explicit.
User requirements
 Should describe functional and non-functional requirements in
such a way that they are understandable by system users who
don’t have detailed technical knowledge.
 User requirements are defined using natural language, tables
and diagrams as these can be understood by all users.
Problems with natural language
 Lack of clarity
 Precision is difficult without making the document difficult to read.
 Requirements confusion
 Functional and non-functional requirements tend to be mixed-up.
 Requirements amalgamation
 Several different requirements may be expressed together.
LIBSYS requirement
LIBSYS shall provide a financial accounting system that
maintains records of all payments made by users of the
system. System managers may configure this system so that
regular users may receive discounted rates.
Editor grid requirement
Grid facilities
To assist in the positioning of entities on a diagram, the user may turn
on a grid in either centimetres or inches, via an
option on the control panel. Initially, the grid is off. The grid may be
turned on and off at any time during an editing session and can be
toggled between inches and centimetres at any time. A grid option
will be provided on the reduce-to-fit view but the number of grid lines
shown will be reduced to avoid filling the smaller diagram
with grid lines.
Requirement problems
 Database 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.
 Grid 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

2.6.1 Grid facilities

The editor shall provide a grid facility wh ere a m atrix of horizontal and
vertical lines provide a background to the edi tor window. This grid shall be a
passive grid where the alignment of entities is the user's responsibility.
Rationale: A grid helps the user to create a tidy diagram with well-spaced
entities. Although an active grid, where entities 'snap-to' grid lines can be useful,
the positioning is imprecise. The user is the best person to decide where entities
should be positioned.
Specification: ECL IPSE/WS/Tools/DE/FS Section 5.6
Source: Ray Wilson, Glasgow Office
Guidelines for writing requirements
 Invent a standard format and use it for all requirements.
 Use language in a consistent way. Use shall for mandatory
requirements, should for desirable requirements.
 Use text highlighting to identify key parts of the requirement.
 Avoid the use of computer jargon.
System requirements
 More detailed specifications of system functions, services and
constraints than user requirements.
 They are intended to be a basis for designing the system.
 They may be incorporated into the system contract.
 System requirements may be defined or illustrated using
system models.
Requirements and design
 In principle, requirements should state what the system
should do and the design should describe how it does this.
 In 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
 Ambiguity
 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.
 Over-flexibility
 The same thing may be said in a number of different ways in the
specification.
 Lack of modularisation
 NL structures are inadequate to structure system requirements.
Alternatives to NL specification

Notation Description
Structured natural This approach depends on defi ning standard forms or templates to exp ress the
language requirements specifi cation.
Design This approach uses a la nguage li ke a programmi ng langu age but with more abstract
description features to specif y the requir ements by defining an op erationa l m odel of the system.
language s This approach is not now widely used although it can be us eful for interface
specification s.
Graphical A graph ic al languag e, supp lemented by text anno tations is used to defi ne the
notations func tiona l requir ements for the system. An early exa mple of such a graphical
language was SADT. Now, use-case descriptions and sequence d iagrams are
comm only u sed .
Mathematical These are no tations based on mathematical concep ts such as finite-state machines or
specification s sets. These una mbiguous specifications reduce the argu ments between customer and
contractor about system func tiona lit y. Howeve r, most cus tomers don’t unde rstand
formal specifications and a re reluctant to accept it as a system contract.
Structured language specifications
 The freedom of the requirements writer is limited by a
predefined template for requirements.
 All requirements are written in a standard way.
 The terminology used in the description may be limited.
 The 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
 Definition of the function or entity.
 Description of inputs and where they come from.
 Description of outputs and where they go to.
 Indication of other entities required.
 Pre and post conditions (if appropriate).
 The side effects (if any) of the function.
Form-based node specification

Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: Safe sugar level
Description Computes the dose of insulin to be delivered wh en the current measured sugar level is in
the safe zone between 3 and 7 units.
Inp uts Current sugar re ading (r2), the previous two readings (r0 and r1)
Source Current sugar re ading from sensor. Other re adings from memory.
Outputs CompDose Ğ the dose in insulin to be delivered
Destination Main control loop
Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of
increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is
computed by dividing the difference between the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then CompDose is set to the mi nimum dose that can
be delivered.
Requires Two previous readings so that the rate of change of sugar level can be comp uted.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condi tion r0 is replaced by r1 then r1 is replaced by r2
Side-effects None
Tabular specification
 Used to supplement natural language.
 Particularly useful when you have to define a number of
possible alternative courses of action.
Tabular specification

Condition Action
Sugar le vel falling (r2 < r1) CompDose = 0
Sugar le vel stable (r2 = r1) CompDose = 0
Sugar le vel increasing and rate of CompDose = 0
increase decreasing ((r2-r1)<(r1-r0))
Sugar le vel increasing and rate of CompDose = round ((r2-r1)/4)
increase stable or increasing. ((r2-r1) • If rounded result = 0 then
(r1-r0)) CompDose = MinimumD ose
Graphical models
 Graphical models are most useful when you need to show
how state changes or where you need to describe a sequence
of actions.
 Different graphical models are explained under System Models.
The requirements document
 The requirements document is the official statement of what is
required of the system developers.
 Should include both a definition of user requirements and a
specification of the system requirements.
 It 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
 Defines 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
 Preface
 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index
Key points
 Requirements set out what the system should do and define
constraints on its operation and implementation.
 Functional requirements set out services the system should provide.
 Non-functional requirements constrain the system being developed
or the development process.
 User requirements are high-level statements of what the system
should do. User requirements should be written using natural
language, tables and diagrams.
Key points
 System requirements are intended to communicate the
functions that the system should provide.
 A software requirements document is an agreed statement
of the system requirements.
 The IEEE standard is a useful starting point for defining
more detailed specific requirements standards.
Requirements Engineering Processes
Topics covered
 Feasibility studies
 Requirements elicitation and analysis
 Requirements validation
 Requirements management
Requirements engineering processes
 The processes used for RE vary widely depending on the
application domain, the people involved and the organisation
developing the requirements.
 However, 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

Requiremen t s
sp ecifi cat io n
Sy st em requiremen t s
sp ecifi cat io n an d
m odelin g

User requi rem ent s

sp ecifi cat io n

Busin ess requirem ent s

sp ecifi cat io n

Sy st em
requi rem ent s Feasibilit y
User st udy
elicit at io n requi rem ent s
elicit at io n
Pro t ot y pi ng

Requiremen t s
elicit at io n Requiremen t s
Rev iews
v al idat i on

Sy s te m re qui re me nts
docum ent
Feasibility studies
 A feasibility study decides whether or not the proposed
system is worthwhile.
 A 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
 Based on information assessment (what is required), information
collection and report writing.
 Questions 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
 Sometimes called requirements elicitation or requirements
discovery.
 Involves 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.
 May involve end-users, managers, engineers involved in maintenance,
domain experts, trade unions, etc. These are called stakeholders.
Problems of requirements analysis
 Stakeholders don’t know what they really want.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting requirements.
 Organisational and political factors may influence the system
requirements.
 The requirements change during the analysis process. New
stakeholders may emerge and the business environment change.
The requirements spiral

Requi rem ent s Requi rem ent s

classificat ion and pri orit i zat io n an d
organi sat i on negot i at i on

Requi rem ent s Requi rem ent s

discov ery documen t at i on
Process activities
 Requirements discovery
 Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
 Requirements classification and organisation
 Groups related requirements and organises them into coherent clusters.
 Prioritisation and negotiation
 Prioritising requirements and resolving requirements conflicts.
 Requirements documentation
 Requirements are documented and input into the next round of the spiral.
Requirements discovery
 The process of gathering information about the proposed and
existing systems and distilling the user and system
requirements from this information.
 Sources of information include documentation, system
stakeholders and the specifications of similar systems.
ATM stakeholders
 Bank customers
 Representatives of other banks
 Bank managers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators
Viewpoints
 Viewpoints are a way of structuring the requirements to
represent the perspectives of different stakeholders.
Stakeholders may be classified under different viewpoints.
 This multi-perspective analysis is important as there is no
single correct way to analyse system requirements.
Types of viewpoint
 Interactor viewpoints
 People or other systems that interact directly with the system. In an ATM, the
customer’s and the account database are interactor VPs.
 Indirect viewpoints
 Stakeholders who do not use the system themselves but who influence the
requirements. In an ATM, management and security staff are indirect viewpoints.
 Domain viewpoints
 Domain characteristics and constraints that influence the requirements. In an
ATM, an example would be standards for inter-bank communications.
Viewpoint identification
 Identify 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

All VPs

Indirect Int eract or Dom ain

Library Art icle Library UI Classifi cat io n

Fi nance Users st andards syst em
m an ager providers st aff

Syst em
St udent s St aff Ex t ern al Cat aloguers
m an agers
Techniques
 Interviews
 Questionnaires
 Observation
 Document / Procedure Analysis
 JAD
 Prototyping
Exercise
 Rate each of the following techniques based on these
criteria (high, medium or low):
 Degree of participation with user
 Information "richness" (depth)
 Breadth of information (scope)
 Cost (Analysts' Time)
 Cost (Users’ Time)
 Ability to integrate information
 User involvement w/ system design
Interviews -- Five Basic Steps
 Selecting Interviewees
 Designing the Interview Guide
 Preparing for the Interview
 Conducting the Interview
 Post-Interview Follow-up

Each of these steps is ripe with opportunities for injecting bias.

Is bias a bad thing? Why or why not?
Which step takes the longest?
Interviews
 Selecting Interviewees
 Same guidelines as questionnaires
 Should be representative of all users
 Recall the effects of bias
 Types of samples
 Convenient
 Random sample
 Purposeful sample
 Stratified sample
Interviews

 Designing the Interview

Guide

Sample Interview Guide

Figure 7-2

For whose benefit are interview

guides?
Is it worthwhile to construct them?
What are the benefits?
What about bias?
Interviews
 Designing the Interview Guide
1. Overall Questioning Strategies
 General area, narrowing to specific topic (preferred)
 Tell me about CTI site, then Courses, then Course Information, then
enrollment numbers
 Specific topic, moving to General
 Enrollment numbers on Course Info page to CTI site in general
2. Types of Interview Questions
 Open-Ended
 No pre-specified answers
 Close-Ended
 Respondent is asked to choose from a set of specified responses
Interviews
 Preparing for the Interview
 Confirm place/time
 Review areas to be covered
 Encourage interviewee to bring reference materials
Interviews
 Conducting the Interview
 Gather facts, opinions and speculations
 Avoid bias when phrasing questions, e.g. phrasing in ways that imply a
wrong or right answer
 Never take sides on an issue
 Tape record with individual and organizational permission
Interviews
 Conducting the Interview
 Assume tape recording will not work, which means you must
simultaneously
 Follow the interview guide, and
 Listen very carefully to what is being said, and
 Observe body language and emotions, and
 Separate facts from opinions, and
 Take notes, and
 Plan the next question/flow of the interview
 THIS IS VERY DIFFICULT TO DO CORRECTLY AND MUST BE
PRACTICED.
Interviews
 Conducting the Interview--practical tips
 Don’t worry, be happy
 Pay attention
 Summarize key points
 Be succinct and honest
 Give interviewee time to ask questions
 Be sure to thank the interviewee
 End on time
 And, don’t ask unnecessary questions!
Interviews
 Post Interview
 Consider asking for more time if necessary
 Confirm major points identified with interviewee
 Look for Gaps and New Questions
 “If it isn’t in the field notes, it never happened.”
 Type up notes within 24 hours (preferably immediately after the
interview is over
Interviewing Groups
 Advantages
 More effective use of time
 Enables people to hear opinions of others and to agree or
disagree
 Disadvantages
 Difficulty in scheduling
 Nominal Group Technique
 Facilitated process to support idea generation by groups
 Individuals work alone to generate ideas which are pooled under
guidance of a trained facilitator
Questionnaires
 A questionnaire is similar to a very structured interview
 Many of the same guidelines apply
 Choosing respondents
 Should be representative of all users
 Same types of samples
 Convenient
 Random sample
 Purposeful sample
 Stratified sample
Questionnaires

Response rates to questionnaires are commonly low—

over 15% is sometimes considered very good.
Observation
 Directly Observing Users
 Serves as a good method to supplement interviews
 Often difficult to obtain unbiased data
 People often work differently when being observed
 Be cognizant of normal and abnormal conditions, e.g. entering an
order vs. the end of quarter sales report
Document/Procedure Analysis
 Great starting point
 Gets analyst quickly up to speed with user jargon
 Can create preliminary models, e.g. DFDs or ERDs
 Types of information to be discovered:
 Problems with existing system
 Opportunity to meet new need
 Organizational direction
 Names of key individuals
 Values of organization
 Special information processing circumstances
 Reasons for current system design
 Rules for processing data
Document/Procedure Analysis
 Four types of useful documents
 Written work procedures
 Describes how a job is performed
 Includes data and information used and created in the process of performing
the job or task
 Business form
 Explicitly indicate data flow in or out of a system
 Report
 Enables the analyst to work backwards from the report to the data that
generated it
 Description of current information system
Joint Application Design
 Joint Application Design (JAD)
 Brings together key users, managers and systems analysts
 Purpose: collect system requirements simultaneously from key
people
 Conducted off-site
Joint Application Design
Joint Application Design
 Participants
 Session Leader
 Users
 Managers
 Sponsor
 Systems Analysts
 Scribe
 IS Staff
Joint Application Design
 Supporting JAD with GSS
 Group support systems (GSS) can be used to enable more
participation by group members in JAD
 Members type their answers into the computer
 All members of the group see what other members have been typing
Joint Application Design
 End Result
 Documentation detailing existing system
 Consensus on features of proposed system
 CASE Tools During JAD
 Upper CASE tools are used
 Enables analysts to enter system models directly into CASE
during the JAD session
 Screen designs and prototyping can be done during JAD and
shown to users

What is the apparent drawback with JAD?

Prototyping
 Repetitive process
 Rudimentary version of system is built
 Replaces or augments SDLC
 Goal: to develop concrete specifications for ultimate system
Prototyping
 Quickly converts requirements to working version of system
 Once the user sees requirements converted to system, will ask for
modifications or will generate additional requests
 Is prototyping useful in any of these cases?
 User requests are not clear
 Few users are involved in the system
 Designs are complex and require concrete form
 History of communication problems between analysts and users
 Tools are readily available to build prototype
Prototyping
 Drawbacks
 Tendency to avoid formal documentation
 Difficult to adapt to more general user audience
 Sharing data with other systems is often not considered
 Systems Development Life Cycle (SDLC) checks are often bypassed
Business Process Reengineering (BPR)
 Changes to the underlying Business Process (BP) can vary from
project to project
 Minor changes to process (BP Automation)
 Moderate changes (BP Improvement)
 Major (BP Reengineering)
 BPR is the search for and implementation of radical change in
business processes to achieve breakthrough improvements in
products and services
 Some common BPR Goals
 Reorganize complete flow of data in major sections of an organization
 Eliminate unnecessary steps completely
 Combine steps, or
 Become more responsive to future change
Business Process Reengineering (BPR)
 Identification of processes to reengineer
 Key business processes
 Set of activities designed to produce specific output for a particular
customer or market
 Focused on customers and outcome
 Same techniques are used as were used for requirements determination
Business Process Reengineering (BPR)
 Identify specific activities that can be improved through BPR
 Disruptive technologies
 Technologies that enable the breaking of long-held business rules
that inhibit organizations from making radical business changes
 See table 7-7
Business Process Reengineering (BPR)
Social and organisational factors
 Software systems are used in a social and organisational
context. This can influence or even dominate the system
requirements.
 Social and organisational factors are not a single viewpoint but
are influences on all viewpoints.
 Good analysts must be sensitive to these factors but currently
no systematic way to tackle their analysis.
Requirements validation
 Concerned with demonstrating that the requirements define
the system that the customer really wants.
 Requirements 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
 Validity. Does the system provide the functions which best support
the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the customer included?
 Realism. Can the requirements be implemented given available
budget and technology
 Verifiability. Can the requirements be checked?
Requirements validation techniques
 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping
 Using an executable model of the system to check requirements.
 Test-case generation
 Developing tests for requirements to check testability.
Requirements reviews
 Regular reviews should be held while the requirements
definition is being formulated.
 Both client and contractor staff should be involved in reviews.
 Reviews may be formal (with completed documents) or
informal. Good communications between developers,
customers and users can resolve problems at an early stage.
Review checks
 Verifiability. Is the requirement realistically testable?
 Comprehensibility. Is the requirement properly understood?
 Traceability. Is the origin of the requirement clearly stated?
 Adaptability. Can the requirement be changed without a large
impact on other requirements?
Requirements management
 Requirements management is the process of managing changing
requirements during the requirements engineering process and
system development.
 Requirements 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
 The priority of requirements from different viewpoints
changes during the development process.
 System customers may specify requirements from a business
perspective that conflict with end-user requirements.
 The business and technical environment of the system changes
during its development.
Requirements evolution
Enduring and volatile requirements
 Enduring 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
 Volatile requirements. Requirements which change during
development or when the system is in use. In a hospital,
requirements derived from health-care policy
Requirements classification

Requirement Description
Type
Mutable Requirements that change because of changes to the environme nt in which the
requirements organisation is operating. For example, in hospital systems , the funding of patient
care ma y change and thus require different treatment information to be collected.
Emergent Requirements that emerge as the customer's understanding of the system develops
requirements during the system development. The design process may reveal new emergent
requirements.
Consequential Requirements that result from the introduction of the comp uter system. Introducing
requirements the computer system may change the organisations processes and open up new ways
of working which generate new system requirements
Compatibility Requirements that depend on the particular systems or b usiness processes within an
requirements organisation. As these change, the comp atibility requirements on the commissioned
or delivered system m ay also have to evolve.
Requirements management planning
 During 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;
Requirements change management
 Should apply to all proposed changes to the requirements.
 Principal 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
 The requirements engineering process includes a feasibility
study, requirements elicitation and analysis, requirements
specification and requirements management.
 Requirements elicitation and analysis is iterative involving
domain understanding, requirements collection, classification,
structuring, prioritisation and validation.
 Systems have multiple stakeholders with different
requirements.
Key points
 Social and organisation factors influence system requirements.
 Requirements validation is concerned with checks for validity,
consistency, completeness, realism and verifiability.
 Business changes inevitably lead to changing requirements.
 Requirements management includes planning and change
management.
System models
Topics covered
 Data Flow Models (Data Flow Diagrams)
 Data Dictionaries
 Semantic Data Models (Entity-Relationship Diagrams)
 Object Models
 CASE workbenches
System modelling
 System modelling helps the analyst to understand the functionality
of the system and models are used to communicate with customers.
 Different 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.
What is a Data Flow Diagram?
 Known as DFDs
 A way to model a real world situation
 They are the interface between the real world activities
and an understanding of how this can be converted into a
computer system.
Why do we use DFDs?
 It is a way of taking the physical view and converting it
into a logical view.
 The physical view - all documents involved
 The logical view - the data they contain
 Their main purpose is to communicate with the user,
the analyst’s understanding of the scope of the
required system
Levelling

 DFDs are expanded or decomposed into levels.

 Separating each process into sub processes
 Uncovers more and more detail
Conventions
 Balancing
 Process at lower level should have identical data flows if
they flow out of a process
 Modelling Data Stores
 Only use DATA STORES used within this process on the
diagram
 Numbering
 1 - 1.1 - 1.1.1
 1.2 - 1.2.1
 Labels should carry as much meaning as possible
Decomposition and Abstraction

 Decomposition - Divide and subdivide

into manageable size problems
 Abstraction - Concentrate on the
important issues and ignore the
irrelevant
The Elements
The four main elements of DFDs notation
 Data Flows, with a label to indicate what
data is flowing
 Processes, that handle the data
 Data stores, within the system (diary,
filing cabinet or computer file)
 Outside entities, outside sources of data
Process and Data Stores

A process is made up of Processes

Name
Process Number

Process description Should

be descriptive, starting
with a verb.

Data Stores
Can be M for manual or D for Name of Store
M1
computer base data stores.
Outside Entity

Is anything outside the system that is of interest to the

system. Can be a person, a company or another
system.

Customer
a

Outside entity shows the Name and a

lowercase alpha character is used to Customer
uniquely identify it. a

If an outside entity is repeated for

the purpose of neat layout a line is
added across the top.
Data Flow

Is shown by a line with an arrowhead, indicating the

direction of the flow of data. Each data flow should be
named to indicate what data is being passed. Nouns
or adjectives only no verbs are permitted.
The Levels

 Context - Overview - contains only one process

 Level 1 - Utilises all four elements – a breakdown of
the level 0 process
 Level 2 - A breakdown of a level 1 process
 Level 3 - A breakdown of a level 2 process
 There is no rule as to how many levels of DFD that
can be used.
Rules
Sequence not important - getting the Process correct is
 Context or Level 0 - Identifies the system/
boundary/External Links
 Level 1 - Overview of function
 Level 2 - Breakdown to Understand
 Hard to know where to stop
 Process of Identifying major Processes

Rule of Thumb
If there are more than 8 data flows break it
Constructing DFD’s
 Sketch a document flow diagram of the current situation
 Draw a system boundary around the agencies that are part of
the system
 Draw a context diagram
 Identify processes in the system
 Complete the level 1 current physical DFD
The Document Flow Diagram

The task of Production

Planning
Supplier

modelling a Delivery
business situation Production
Plan
Note
Purchase

can be daunting at
Order

first. It is best to Supplier Details Update Form

Delivery Note
start with Stock Control
Material Requirements List
Purchasing

something simple
such as a Stock
Withdrawal
document flow
Note Bill of
Materials
diagram. Design
Factory
The Context (Level 0) Diagram

 You decide which

agencies are to be part a
Production
b

of the system that you Planning Supplier

are examining
Production Deliv ery
Plan Note

These agencies fall inside

e Stock Control Supplier Details Update Form


c
Bill of Materials Deliv ery Note
Design Maintain Material Requirements List Purchasing

the system boundary and

Stock System

Stock

are reduced to one box

W ithdrawal
Note

in the center Factory

 This is a context diagram

Identifying Processes

 All data flows going into 1 St oc k c lerk

the system must be Maint ain

planned c all-of f

received by a process
 All data flows going out
of the system must be 2 St oc k c lerk

generated by a process Maint ain

s t oc k c ards

 The first task therefore

is to identify these
processes 3 St oc k c lerk

Prepare
m at erial reqm nt s
lis t
Draw the External Entities and Data Stores

1 Stock clerk
a
M1 Bill of materials
Production Maintain
Planning planned call-of f

M2 Stock cards
b

Supplier

c 2 Stock clerk

Factory Maintain
stock cards

3 Stock clerk
d
Prepare
Purchasing
material reqmnts
list
Level 1 Physical DFD - Complete
Finally draw in the data flows to give a complete diagram. Note that a
data flow must have a process at the end
1 Stock clerk
a B O M details
Production
M1 Bill of materials
Production Maintain
Planning Plan
planned call-of f
Planned call-of f
details M2 Stock cards
b

Supplier
Deliv ery note Stock details

c 2 Stock clerk

Factory Maintain
Stock stock cards
withdrawal note
Stock details
Updated
supply details

Deliv ery 3 Stock clerk

d note
Prepare
Purchasing Material requirements material reqmnts
list list
Hairdressing Salon Level 1 DFD
1 Receptionist
New client
Register details
Appointm ent
Existing client
Appointm ent details
details M1 Client card index
Confirmation
Request Appointm ent
details
Confirmation
Details
M2 Appointm ent diary

Confirmation of
a
arrival
Client Appointm ent
details 2 Receptionist

Confirm Appointm ent Change of

arrival details
hairstyle etc.

Change of
hairstyle etc.
3 Hairdresser/Rcptnst

Conduct
appointment
Process 3 Level 2

3 Hair/Reception
Client
a Clie
a 3.1 Hairdresser
Appointment Details
Conduct Appointment
Hair Details M2 Diary

3.2 Hairdresser
Inform Reception

Change of Hair Details

3.3 Receptionist
Complete Appointment M3 Client Card
Naming of DFD processes
Level 0 Level 1 Level 2 Level 3 Level 4
2 2.2 2.1.1
1
Process Elementary
Man 2.1 2.1.1 process
Sub Sub - Sub descriptions.
Process Process
Decision trees
Overall 2 Decision table
Process Process
Process 2.2 Structured
English
Sub 2.1.2
Process
3 Sub - Sub
Process
Process
Man 2.3
Sub
Process

There must be consistency between levels, with all the data appearing
on the higher level DFD. If a data store is used only for one process it
is placed with that process. Outside entities are always shown outside
the boundary of a lower level DFD process, even if they only
communicate with that one process
Data modelling vs Process modelling
 Process modelling (i.e. DFD) shows data stores, how, where, n
when data r used or changed in an IS
 Data modelling (i.e ER) shows d’definition, structure, n
relationship within d’data
Why data model is the most important
part of the statement of SW requirement?
 Characteristics of data captured during data modelling are crucial in
the design of DB, program, computer screen, and reports
 Data rather than processes are the most complex aspects of many
modern IS so require a central role in structuring system
requirement
 The characteristics of data (length, format, relationship) are
reasonably permanent. The paths of data flow are quite dynamic
 Structural information about data is essential for automatic
generation of programs
Conceptual Data Modeling and the E-R Diagram
 Goal
 Capture as much of the meaning of the data as possible
 If you know the rules of normalization, referential integrity, foreign
keys, etc., this is good but not as important now. It is much more
important to get the organizational data model correct, i.e. to
understand the actual data requirements for the organization.
 Result
 A better design that is scalable and easier to maintain
Introduction to Entity-Relationship (E-R)
Modeling
 Notation uses three main constructs
 Data entities
 Attributes
 Relationships
 Entity-Relationship (E-R) Diagram
 A detailed, logical representation of the entities, associations and
data elements for an organization or business
Entity-Relationship (E-R) Modeling
 Entity
 A person, place, object, event or concept in the user environment
about which the organization wishes to maintain data
 Represented by a rectangle in E-R diagrams
 Entity Type
 A collection of entities that share common properties or
characteristics
 Attribute
 A named property or characteristic of an entity that is of interest to
an organization
Entity-Relationship (E-R) Modeling
 Candidate keys and identifiers
 Each entity type must have an attribute or set of attributes that
distinguishes one instance from other instances of the same type
 Candidate key
 Attribute (or combination of attributes) that uniquely identifies each
instance of an entity type
Entity-Relationship (E-R) Modeling
 Identifier
 A candidate key that has been selected as the unique identifying
characteristic for an entity type
 Selection rules for an identifier
1. Choose a candidate key that will not change its value
2. Choose a candidate key that will never be null
3. Avoid using intelligent keys
4. Consider substituting single value surrogate keys for large
composite keys
Notation Guide

 ENTITY TYPE

 WEAK ENTITY TYPE

 RELATIONSHIP TYPE

 IDENTIFYING
RELATIONSHIP TYPE
Notation Guide

 ATTRIBUTE

_____  KEY ATTRIBUTE

 MULTIVALUED ATTRIBUTE

 DERIVED ATTRIBUTE

...  COMPOSITE ATTRIBUTE

Notation Guide

E1 R E2  TOTAL PARTICIPATION OF E2 IN R

 CARDINALITY RATIO 1:N FOR E1:E2

1 N IN R
E1 R E2

 STRUCTURAL CONSTRAINT (min,

max) ON PARTICIPATION OF E IN R
(min,max)
(Alternative Notation)
R E2
ER Diagram Basics

Entity
sname

Store Locations
Relationship
manager

qty Keeps
Attributes
pname

Product price

descrip
Entity

Real-world object distinguishable from other objects

(e.g a student, car, job, subject, building ...)
 An entity is described using a set of attributes
 The same entity may have different prominence in different UoDs
– In the Company database, an employee’s car is of
lesser importance
– In the Department of Transportation’s registration
database, cars may be the most important concept
– In both cases, cars will be represented as entities;
but with different levels of detail
Entity Sets

A collection of similar entities (e.g. all employees)

 All entities in an entity set have the same set of attributes
 Each entity set has a key
 Each attribute has a domain
 Can map entity set to a relation easily

EMPLOYEES

SSN NAME SAL

321-23-3241 Kim 23,000
645-56-7895 Jones 45,000
Entity Type

Defines set of entities that have the same

name attributes (e.g. EMPLOYEE)
 Each Entity Type is described by its
sal
NAME and attributes
SSN
 The Entity Type describes the “Schema” or
“Intension” for a set of entities
EMPLOYEE
 Collection of all entities of a particular
entity type at a given point in time is called
the “Entity Set” or “Extension” of an
Entity Type
 Entity Type and Entity Set are customarily
referred to by the same name
Notation
Attributes

 Key Attributes Notation

 Value Sets of Attributes

 Null Valued Attributes
 Attribute Types
– Composite Vs. Simple Attributes
– Single-valued Vs. Multi-valued Attributes
– Derived Vs. Stored Attributes
Key Attributes: Identifier

 Key (or uniqueness) constraints are

applied to entity types
 Key attribute’s values are distinct for each
individual entity in the entity set
 A key attribute has its name underlined
inside the oval
 Key must hold for every possible
extension of the entity type SSN

 Multiple keys are possible

EMPLOYEE
Null Valued Attributes

 A particular entity may not have an applicable value for an

attribute
– Tertiary-Degree: Not applicable for a person with no
university education
– Home-Phone: Not known if it exists
– Height: Not known at present time
 Type of Null Values
– Not Applicable
– Unknown
– Missing
Composite Vs. Simple Attributes

Composite attributes can be divided into smaller parts

which represent simple attributes with independent
meaning
 Simple Attribute: Aircraft-Type
 Complex Attribute: Aircraft-Location which is
comprised of :
Aircraft-Latitude
Aircraft-Longitude Notation
Aircraft-Altitude

… There is no formal concept of “composite

attribute” in the relational model
Single Vs. Multivalued Attributes

Simple attributes can either be single-valued

or multi-valued
 Single-valued: Gender = F
Notation

 Multivalued: Degree = {BSc, MInfTech}

Notation

… An “attribute” in the relational model is always

single valued - Values are atomic!
Derived Vs. Stored Attributes

Some attribute values can be derived from

related attribute values:
 Age ® Date - B-day Notation
 Y-Sal ® 12 * M-Sal

Age M-sal
B-days Y-sal

EMPLOYEE
Derived Vs. Stored Attributes

Order Total-Value
 Some attribute values can
be derived from attributed
values of related entities
 total-value ® sum (qty *
price) qty

Item price
Representing Attributes

 Parenthesis ( ) for composite attributes

 Brackets { } for multi-valued attributes
Assume a person can have more than one residence and each residence can
have multiple telephones
{AddressPhone
({ Phone ( AreaCode,PhoneNum ) },
Address (StreetAddresss (Number, Street, AptNo),
City,State,PostalCode) ) }
Entity-Relationship (E-R) Modeling
 Relationship
 An association between the instances of one or more entity types
that is of interest to the organization
 Association indicates that an event has occurred or that there is a
natural link between entity types
 Relationships are always labeled with verb phrases
Cardinality

 The number of instances of entity B that can be

associated with each instance of entity A
 Minimum Cardinality
 The minimum number of instances of entity B that may be
associated with each instance of entity A
 This is also called “modality”.
 Maximum Cardinality
 The maximum number of instances of entity B that may be
associated with each instance of entity A
Naming and Defining Relationships
 Relationship name is a verb phrase
 Avoid vague names
 Guidelines for defining relationships
 Definition explains what action is being taken and why it is important
 Give examples to clarify the action
 Optional participation should be explained
 Explain reasons for any explicit maximum cardinality
Naming and Defining Relationships
 Guidelines for defining relationships
 Explain any restrictions on participation in the relationship
 Explain extent of the history that is kept in the relationship
 Explain whether an entity instance involved in a relationship
instance can transfer participation to another relationship instance
Relationships

 Relationship Types and Sets

 Relationship Degree
 Entity Roles and Recursive Relationships
 Relationship Constraints
 Attributes of Relationship Types
Relationship Types and Sets

A Relationship is an association among two or more entities

(e.g John works in Pharmacy department)
 A Relationship Type defines the relationship, and a
Relationship Set represents a set of relationship instances
 A Relationship Type thus defines the structure of the
Relationship Set
Relationship Type and corresponding Set are customarily referred to by
the same name
Relationship Degree
Departments
 The degree of a relationship type is the
number of participating entity types
– 2 entities: Binary Relationship
Works_In Binary
3 entities: Ternary Relationship
n entities: N-ary Relationship
– Same entity type could participate in
multiple relationship types Employees Multiple

Supplier Supply Project Assigned_to

Ternary

Part
Entity Roles

Departments
 Each entity type that
participates in a relationship employer
type plays a particular role
in the relationship type
Role
Works_In
Names
 The role name signifies the
role that a participating
worker
entity from the entity type
plays in each relationship
instance, i.e. it explains what Employees
the relationship means
Recursive Relationships

 Same entity type can participate more than once in the same relationship
type under different “roles”

 Such relationships are called

“Recursive Relationships”

Employees

Recursive Supervisor Subordinate

Relationship

Supervision
Relationship Constraints

What are Relationship Constraints ?

 Constraints on relationships are determined by the UoD, which
these relationships are describing
 Constraints on the relationship type limit the possible
combination of entities that may participate in the
corresponding relationship set
Kinds of Constraints

What kind of constraints can be defined in the ER Model?

 Cardinality Constraints
 Participation Constraints
Together called “Structural Constraints”

Constraints are represented by

specific notation in the ER diagram
Possible Cardinality Ratios

 The “Cardinality Ratio” for a binary

relationship specifies the number of
Departments
relationship instances that an entity can
participate in
– Works-In is a binary relationship
– Participating entities are Works_In
DEPARTMENT : EMPLOYEE
– One department can have
Many employees -
Employees
Cardinality Ratio is 1 : N
Possible Cardinality Ratios
. .
 1–to-1 (1 : 1) . .
– Both entities can . .
participate in only one
1-to-1
relationship instance .
 1-to-Many, Many-to-1
. . . .
. . .
(1 : N, N : 1) . . .
– One entity can . .
participate in many
.
1- to - Many Many - to -
relationship instances 1
 Many-to-Many (N: M) . .
– Both entities can participate in
many relationship instance . .
. .
.
Many-to-Many
Example Cardinality Constraints

How many Employees can work in a Department?

One employee can work in only one department
How many Employees can be employed by a Department?
One department can employ many employees
How many managers can a department have?
One department can have only one manager
How many departments can an employee manage?
One employee can have manage only one department
Representing Cardinality

N Works_In 1

Employees Departments

1 Manages 1

One employee can work in only one department

One department can employ many employees
One department can have only one manager
One employee can manage only one department
Existence Dependency

 Existence dependency indicates whether

the existence of an entity depends on its Departments
relationship to another entity via the
relationship type
– Every employee must work for Works_In
a department - EMPLOYEE is
existentially dependent on
DEPARTMENT via the Works In Employees
relationship type
Kinds of participating constraints

 TOTAL Participation (Existence Dependency)

Constraint : Every employee must work for a department
 PARTIAL Participation
Constraint : Not every employee is a manager
Representing Participation

N Works_In 1

Employees Departments

1 Manages 1

Every employee must work for a department

Every department must have a manager
Every department must have employees
Not every employee is a manager
Data dictionaries
 Data dictionaries are lists of all of the names used in the system
models. Descriptions of the entities, relationships and attributes are
also included.
 Advantages
 Support name management and avoid duplication;
 Store of organisational knowledge linking analysis, design and implementation;
 Many CASE workbenches support data dictionaries.
Data dictionary entries

Name Description Type Date

Details of the published article that may be ordered by
Article Entity 30.12.2002
people using LIBSYS .
The names of the authors of the article who may be due
authors Attribute 30.12.2002
a share of the fee.
The person or organisation that orders a co py of the
Buyer Entity 30.12.2002
article.
A 1:1 relationship between Article and the Copyright
fee- Relation 29.12.2002
Agency who should be paid the copyright fee.
payable-to
The address of the buyer. This is used to any paper
Address Attribute 31.12.2002
billing information that is required.
(Buyer)
Object models
 Object models describe the system in terms of object classes and
their associations.
 An object class is an abstraction over a set of objects with common
attributes and the services (operations) provided by each object.
 Various object models may be produced
 Inheritance models;
 Aggregation models;
 Interaction models.
Object models
 Natural ways of reflecting the real-world entities manipulated
by the system
 More abstract entities are more difficult to model using this
approach
 Object class identification is recognised as a difficult process
requiring a deep understanding of the application domain
 Object classes reflecting domain entities are reusable across
systems
Inheritance models
 Organise the domain object classes into a hierarchy.
 Classes at the top of the hierarchy reflect the common features of
all classes.
 Object classes inherit their attributes and services from one or
more super-classes. these may then be specialised as necessary.
 Class hierarchy design can be a difficult process if duplication in
different branches is to be avoided.
Object models and the UML
 The UML is a standard representation devised by the developers of
widely used object-oriented analysis and design methods.
 It has become an effective standard for object-oriented modelling.
 Notation
 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

Library i t em

Cat alogue n umber

Acquisi t ion da t e
Co st
Typ e
St at us
Number o f cop ies
Acquire ()
Cat alogue ()
Disp ose ()
Issue ()
Ret urn ()

Pub lish ed it em Reco rded i t em

Tit le Tit le
Pub lish er Medium

Bo ok Magazin e Fi lm Co mp ut er
pro gram
Aut ho r Year Direct o r
Edit io n Dat e of release Version
Issue
Pub licat io n da t e Dist ribut or Plat for m
ISBN
User class hierarchy

Library user
Name
Address
Ph on e
Reg ist rat io n #
Reg ist er ()
De-reg ist er ()

Reader Bo rrower
Affili at io n It ems on lo an
Max . lo ans

St aff St udent
Depar t m en t Majo r subject
Depar t m en t p ho ne Hom e ad dress
Multiple inheritance
 Rather 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.
 This can lead to semantic conflicts where attributes/services with
the same name in different super-classes have different semantics.
 Multiple inheritance makes class hierarchy reorganisation more
complex.
Multiple inheritance

Bo ok Vo ice reco rdi ng

Aut ho r Speak er
Edit io n Durat io n
Pub licat io n da t e Reco rding da t e
ISBN

Talki ng boo k

# Tapes
Object aggregation
 An aggregation model shows how classes that are collections
are composed of other classes.
 Aggregation models are similar to the part-of relationship in
semantic data models.
Object aggregation
CASE workbenches
 A coherent set of tools that is designed to support related
software process activities such as analysis, design or testing.
 Analysis and design workbenches support system modelling
during both requirements engineering and system design.
 These 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

St ruct ured Repo r t

Dat a
diag rammi ng gener at io n
dict io nary
t o ols facilit i es

Cen t ral Query

Co de
in fo rmat io n lan gua ge
gener ator
repo sit o ry facilit i es

Fo rms Design, anal y sis

Impo rt /e x po rt
cr ea tion and ch eck ing
facilit i es
t o ols t o ols
Analysis workbench components
 Diagram editors
 Model analysis and checking tools
 Repository and associated query language
 Data dictionary
 Report definition and generation tools
 Forms definition tools
 Import/export translators
 Code generation tools
Key points
 A model is an abstract system view. Complementary types of
model provide different system information.
 Context models show the position of a system in its
environment with other systems and processes.
 Data flow models may be used to model the data processing in
a system.
Key points
 Semantic data models describe the logical structure of data
which is imported to or exported by the systems.
 Object models describe logical system entities, their
classification and aggregation.
THE END