Introduction to Software Engineering - CSA2030 Dr. Ernest Cachia Department of Computer Science & A....
-
Upload
martina-potter -
Category
Documents
-
view
218 -
download
5
Transcript of Introduction to Software Engineering - CSA2030 Dr. Ernest Cachia Department of Computer Science & A....
Introduction to Software Introduction to Software Engineering - CSA2030Engineering - CSA2030
Dr. Ernest Cachia
Department of Computer Science & A. I.
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
2
Introduction Introduction Generic definition: “The building of
software systems” (coined ~1960s). D. L. Parnas[1987]: “The multi-person
construction of multi-version software”. Software engineering includes programming
but is NOT programming. Therefore…good programmers are not
necessarily good software engineers!
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
3
Summary of CourseSummary of Course(cont…)(cont…)
The aim of this course is to acquaint attendees with some of the fundamental principles of the “still-teething” science of software engineering (SE)
The location and relation of SE with respect to other Computer Science disciplines will be clearly explained
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
4
(...cont.)(...cont.)
Summary of CourseSummary of Course
It is hoped that this course will highlight the major trends, approaches and techniques used in the development of “sound” software systems.
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
5
Who should you be?Who should you be? You should be equipped with the following:
– Interest in the subject area in general– Basic programming skills (nothing fancy)– Normal understanding of structured
programming principles (e.g. CSA1010)– Ability to think in a structured manner– Ability to adhere to discipline in your actions– Ability to keep an open mind in the face of
radically new approaches
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
6
Software Engineering overview Software Engineering overview
The final goal of SE is to build a complete multi-application (usually commercial) software system of considerable complexity and of partial, ideally full, “provability”.
To attain such pretentious aims SE must also be able to effectively bring together the efforts of more than one individual to focus on (usually) one common system.
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
7
The situation (till very lately) The situation (till very lately) Programming made substantial advances:
– Algorithm theory and studies– Data structure theory– Programming language design and application– Introduction of structured programming– Application and design of 4th Generation
languages
BUT…programming only is not enough for the development of large software systems!
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
8
A (then) emerging problemA (then) emerging problem Software development done solely using
traditional programming techniques Computers become more popular - fast Their potential is better recognised Software demands become more serious Software sophistication rockets Sophistication requires more complex s/w Complex s/w is generally large in size Programming is targeted at user-specific
small-scale problems
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
9
The engineering approachThe engineering approach
Comprehend its feasibility
Define it clearly as possible– structure (architecture)– I/O and constraints– working parameters– function
Design its overall structure
Design its components
Design its integration
Implement (actually build) it
Test it (according to thespecified working parameters)
Install it
Test it (on site/in function)
Maintain it
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
10
A specific exampleA specific example Building a tuner (or any electronic device):
– must specify ALL component working parameters and tolerance levels
– rules to correctly locate components on board– ALL specs are standardised– ALL specs are universally understood
Building any software component:– we do not even know which exactly are the
parameters that need to be specified
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
11
Available tools (h/w and s/w)Available tools (h/w and s/w)
Hardware:– Measuring instruments (meters, probes, scopes,
etc.)– Proven mathematical relationships– Adequate established specification standards
Software:– Sparse limited mathematical (formal) tools– Loads of subjective experience and judgment
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
12
Software Engineering in contextSoftware Engineering in context
SE is only a small part of System Engineering
Most modern systems are made up of elements other than simply software
Software on its own is like a mind without a body - it cannot do anything physical
SE only effects the software component of any real-world system
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
13
Diagrams of SE contextDiagrams of SE contextThe system Flight control system
softwarecomponent
All system components that are not software
wires
buttons
indicators
computer h/w
recording media
sensors
servo mechanisms
alarms
controllingsoftware
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
14
Software Engineering roots Software Engineering roots (cont…)(cont…)
Main idea: Make the machine do something usefull BUT a while ago the application of computers was limited
Therefore there was a 1-to-1 (personal) relationship between user and machine to make it do only user-specific tasks– eg. Solve an equation, manipulate an array, etc.
Often ONLY THE USER WAS THE PROGRAMMER
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
15
(...cont)(...cont)
Software Engineering rootsSoftware Engineering roots(cont…)(cont…)
With the introduction of High-level Languages the idea of a “programmer” was created - now the user need not be the machine’s programmer
Nevertheless only specific user-requested tasks were still being programmed– eg. a program for John’s problem would very
likely not interest Mary at all.
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
16
(...cont)(...cont)
Software Engineering rootsSoftware Engineering roots(cont…)(cont…)
This separation of concerns introduced the notion of task specification with its associated mis-interpretation problems
The mid 60s saw the first attempts to build large scientific/commercial systems– OS360 (operating system for IBM 360
mainframe family machines)– UNIX (originally written in assembly language)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
17
(...cont)(...cont)
Software Engineering rootsSoftware Engineering roots Due to this flurry of activity in the mid 60s
serious problems started to emerge regarding the state of software development
The main realisation was that virtually everything associated with computing had a sound scientific basis - apart from software!
Coining of the terms “Software Engineering” and “Software Crisis”
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
18
Problematic areasProblematic areas Tasks not well (or at all) understood by
everyone taking part in the global solution Very large communication overheads -
often exceeding actual coding Coding very subjective (according to
indivdual’s style) Changes in requirements (however small)
often created repercussions throughout every part of the system
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
19
When copying When copying isis right right
Large complex systems were being created continually by engineers with relative ease– eg. bridges, factories, plants, aircraft, etc.
These systems seemed to be much more reliable than software systems
Why not emulate the way in which they are constructed? Why apply basic engineering practices to software development also?
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
20
Basic Engineering PracticesBasic Engineering Practices
Process monitoring and management Process organisation and delegation Application of specific tools Availability/creation of proven theories Application of specific methodologies Development of standardised techniques
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
21
The way aheadThe way ahead
The importance of software will always increase (well at least never decrease)– In the 60s the balance of h/w and s/w costs was
roughly 96% to 4% - no one really took software seriously
– In the early 90s it was 25% to 75% and rising– In 1985 $140 billion spent on software
development– In 1995 $750 billion (estimated)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
22
The basic requirements for a The basic requirements for a good programmergood programmer
Knowledge of data structures and algorithms Knowledge of at least one (preferably more)
programming languages in popular use A minimal ability to abstractly visualise a
specific task
COMPARE THESE WITH….
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
23
The basic requirements for a The basic requirements for a good software engineergood software engineer
Be a decent programmer Understand requirements & translate them into
precise specifications Interface with the user on a non-technical basis Flexible in his/her application background Handle abstraction levels with ease Be able to create different models Have good planning/delegation abilities and be
able to easily communicate his/her thoughts
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
24
SummarySummary The very nature of software itself has and will
change (progress?) Ways and means of developing better software
will result in better harnessing the potential of computing
The mastery of any process will only lead to an improvement in the quality of its product
Better quality usually breeds better productivity
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
25
Attempting to qualify softwareAttempting to qualify software Very difficult if done un-scientifically Akin to qualifying human thought/reasoning Large amount of factors effecting s/w quality Large amount of aspects to a s/w product Very easy to qualify incorrectly Considerable degree of subjectivity in s/w
product S/w product prone to direct (un-specified)
modification
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
26
Some general aspects of s/wSome general aspects of s/w Its development process Its end-products (with all their representative
attributes) Its interaction with humans (users, developers,
process managers, vendors, etc.) The nature of the real-world process it is to
model/simulate End-user feedback (on s/w product)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
27
Some quality aspects of softwareSome quality aspects of software Quality means different things to different
people– User (reliable, efficient, simple to use, etc.)– Producer (maintainable, verifiable, portable, etc.)– Manager (productive and controlled dev., etc.)
Main categories of s/w qualities are:– External (observable by system users)– Internal (structure used to obtain ext. qualities)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
28
The process makes the productThe process makes the product Process: “A series of activities undertaken
to achieve a stipulated entity” Product: “An entity resulting from a given
process” Quality applies to both process and product A software product (typically)
Implementation (executable/s) User manuals “Source” code Requirements statement/Design plan/Test data
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
29
Important s/w process & Important s/w process & product qualitiesproduct qualities
Correctness (i/s) Reliability (e/s/p) Robustness (e/s/p) Efficiency (e/s/p) User friendliness (e/s) Verifiability (i/s) Maintainability (i/s/p)
Reusability (i/s) Portability (e/s) Understandability (i/s) Interoperability (i/s) Productivity (p) Timeliness (p) Visibility (p)
“e”- external quality; “i”- internal quality“s”- product quality; “p”- process quality
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
30
Classification of s/w systemsClassification of s/w systems Batch Processing systems On-line systems Real-Time systems Embedded systems Distributed systems
Quality for each of the above can take on a different meaning.
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
31
Batch-Processing systemsBatch-Processing systems Main elements:
Data Database Transaction Security
transaction 2
transaction 1
transaction n
Important aspects: Data integrity Data availability Data security Transaction efficiency HCI effectiveness
...pre-processing
and local storage
Processing andremote database
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
32
On-line systemsOn-line systems Main elements:
Result time limits Time-slicing Security
Important aspects: Response time range Stimulii to results
relationships Communication
design/security HCI designterminal 1
terminal 2
terminal n
...
localswitching
(no processing) Remoteprocessing
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
33
Real-Time systemsReal-Time systems Main elements:
Stringent timing Control I/O specifications Safety
Important aspects: Response timing
relationships Response time to
activity relationships Control protocol
design Safety mechanisms HCI designUser control
panel(s)
User controlpanel(s)
User controlpanel(s)
Controllingcomputer Controlled
devices
Controlleddevices
Controlleddevices
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
34
Embedded systemsEmbedded systems Main elements:
Stringent timing Control I/O specifications System dependency Safety
Important aspects: Response timing
relationships Response time to
activity relationships Control protocol
design Safety mechanismssystem being controlled
Softwarecomponent
Internalcontrol
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
35
Distributed systemsDistributed systems
Main elements: Process communication Process distribution Data distribution Network links
Important aspects: Communication protocols Logical to physical
process and data mapping Link reliability Individual process
dependencies Data replication and
redundency
process 1
process 2
process n
computer orprocessor n
computer orprocessor 2
computer orprocessor 1
doingonetask
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
36
CorrectnessCorrectness At the basis of many other s/w qualities
eg. Reliability and robustness verifyability and performance
Relative to s/w functional specifications Is a mathematical property Must show equivalence between s/w and its
specification Experimental (through testing) Analytical (through formal verification) Usage of statically analytic tools (HL-languages and
modules of them)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
37
Correctness exampleCorrectness example
systemspecification
systemdesign
systemimplementation
High-levelprogrammin
glanguage
standardlibraries
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
38
ReliabilityReliability
Considered to be a relative quality Direct consequence to system dependability In its complete form considered to be “ideal” Guarantees non-existant / disclaimers many Should imply correctness (not vice-versa) Assumes (ideally) correctly specified
requirements
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
39
RobustnessRobustness
Should always be considered never ignored Not a specifiable quality (usually) Help in better understanding the process
being modelled (eg. sky-scraper technology) Depends considerably on the system’s nature Not included in system specification
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
40
EfficiencyEfficiency Direct result of reliability and robustness Considered to be a relative quantity Can “make or break” a system Highly dependent on technology Effects system scalability Generically measured in terms of extremes
of algorithm time/space/etc. requirements Should be addressed BEFORE system
implementation
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
41
Efficiency evaluation techniquesEfficiency evaluation techniques
Generic: Processing time, required space, data traffic, inter-process message traffic.
Measurement: External system monitors for data collection and subsequent evaluation.
Analysis: Application of queuing theory concepts to analyse model of actual system.
Simulation: Build a use a model to actually perform the same actions as the system.
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
42
User friendliness aspectsUser friendliness aspects
Please note THREE MAIN types of users:
The software
The “normal” user The “operator” user
The “experienced” user
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
43
User friendlinessUser friendliness How a system appeals to (different) users Very subjective software quality Human-Computer Interface is very relevant Software configuration issues (easy?) Performance is also relevant to “friendliness” GUI desgin issues (should be taken seriously) Standardisation increases user friendliness
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
44
VerifiabilityVerifiability
Ease of software quality checking Not all qualities are of equal verifiability Could form part of user requirements Generally implies understandability Should be an implicit value in development
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
45
MaintainabilityMaintainability Applies to “released” products Eats up around 65 to 75% of total s/w
development costs Existing software does not “ware out” - it
evolves! Existing sotware can be improved upon Not akin to hardware maintenance S/w maintenance can be classified as:
Corrective (sorting out persistent errors - 25%) Adaptive (due to changes in working env. - 20%) Perfective (improve system fuctionality - 55%)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
46
Aspects of maintainabilityAspects of maintainability Repairability (ease of defect correction)
– Exists at different levels (like old & modern h/w)– Direct consequence of good (modular) design– Funtional localisation aids repairability– Orthogonal to reliability
Evolvability (change/improve functionality)– Should undergo normal s/w development process– Requires in-depth study of original system– Should not deteriorate in time (i.e. after successive
releases)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
47
ReusabilityReusability Using existing products to construct new ones Important but not often used quality Directly impacts on evolvability Some examples:
The UNIX shell (command language interpreter) Programming language routine libraries Packages, routines, widgets, etc. in X windows Human knowledge reuse (?)
Considered a measure of general development process maturity
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
48
Levels of software reuseLevels of software reuse
Utilities, abstract data struc., GUI functions, PL libraries, system services, I/O functions,
generic database services, etc.
20%
0%
Personnel InformationManagement
Logistics85%
20%
Domain-independent
level
Domain-specific
level
100%
85%
Application-specific
level
usage
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
49
Benefits gained by reuseBenefits gained by reuse
Lower development costs Higher productivity (reduced cycle time) Lower training costs Easier maintenance Lower risk (higher reliability) Better interoperability Better portability
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
50
Internal and external resueInternal and external resue
“Reuse”library A
nother systemsoftware
software
software
Developmentteam
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
51
Reuse metrics (1)Reuse metrics (1) Banker et al. (1993-1994) metric:
Uses software “objects” (modules, routines, etc.) Does not account for object size (could be deceptive)
new objects builtReuse % = 1 - x
100% total objects used
total object usedReuse leverage =
new objects built
( )
(productivity aid index)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
52
Reuse metrics (2) Reuse metrics (2) (cont…)(cont…) Poulin-Caruso (IBM-1992) metric:
RSI Reuse % = x 100%
total statements(where RSI: Reused Source Instruction)
RCA = DCA + SCA(where R/D/SCA: Reuse/Development/Service Cost Avoidance)
DCA = RSI x (1 - RCR) x (new code cost)(where RCR: Relative Cost of Reuse)
SCA = RSI x (error rate) x (error cost)
Note: RSI implies:– Code components in loops count as only one reuse– Code from project/domain-specific libraries– Code from specific reuse libraries– Some code from utility libraries (depending on its nature)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
53
(...cont) (...cont) Reuse metrics (2)Reuse metrics (2)
total source statements + SIRBO RVA =
total source statements - RSI(where RVA: Reuse Value Added, SIRBO: Source Instructions Reused by Others)
SIRBO = (LOC per part) x (organisations using the part)(where LOC: Lines Of Code)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
54
(...cont) (...cont) Reuse metrics (3)Reuse metrics (3)
Balda-Gustafson (Modified COCOMO)(COCOMO = COnstructive COst MOdel)
Original COCOMO: (LM = KDSILM = labour-months of effort
= complexity coefficient
= complexity exponent
KDSI = initial estimate of effort for thousands (K) of
Delivered Source Instructions
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
55
(...cont) (...cont) Reuse metrics (4)Reuse metrics (4)
Balda-Gustafson modifications
LM = 1N1 + 2N2
+ 3N3 + 4N4
1 = KDSI for development of unique code
2 = KDSI for code developed for reuse
3 = KDSI for reused code
4 = KDSI for modified and reused code
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
56
(...cont) (...cont) Reuse metrics (5)Reuse metrics (5)
The Balda-Gustafson simplificationBasic assumption: RCR = 0.1 & RCWR = 2.0This implies 20 times more effort to build for reusethan to actually reuse
(Remember, RCR is Relative Cost of Reuse &
RCWR is Relative Cost of Writing for Reuse)
Therefore: 2 = 203; 2 = 201; 3 = 1
relationship between effort for unique code and effort toreuse code - in the range of .0909 to .1739)
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
57
(...cont) (...cont) Reuse metrics (6)Reuse metrics (6)
Final (B-G) formula:
LM = N1 + 20N2
+ N3
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
58
PortabilityPortability With respect to platform and operating
system characteristics Very dependent on the functional nature of
the software Can be partially achieved through reusability Could entail trade-offs in the form of non-
optimal usage of hardware or system resources
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
59
UnderstandabilityUnderstandability
Has a direct impact on many important software qualities (eg. correctness, verifiability, maintainability, user-friendliness and visibility)
Helps control aspects of complexity Does not guarantee syntactic/semantic or
algorithmic comprehension
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
60
InteroperabilityInteroperability
Common in hardware - not so in software(eg. stereo systems with CD technology vs. operating systems and CD technology)
Has a direct impact on productivity and evolvability
Related to interface standardisation Is the driving force behind the “open
system” approach
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
61
ProductivityProductivity Generally refers to the software production
process Generally assumes team effort Has a direct impact on timeliness Depends considerably on software reuse Can be greatly increased through the use of
automated software engineering tools Calculated in terms of “function points” and
code size
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
62
TimelinessTimeliness Generally refers to the software production
process The main culprit in “software crisis” Relatively not as “bad” as incorrectness Difficult to calculate accurately a priori to
actual software development Directly effected by system structuring to
aid incremental delivery
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
63
VisibilityVisibility Generally refers to the software production
process Synonymous with transparency and
openness Directly effects productivity and timeliness Encourages correct and effective team work Helps qualify the software development
process Should always be up to date
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
64
The overall structure of SEThe overall structure of SE
Tools
Methodologies
Methods + techniques
Principles
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
65
Software Requirements Software Requirements DefinitionDefinition
Some terminology:– Requirements definition: Natural language
description of user services provided by system– Requirements specification: A more detailed
description of the system’s functions in “technical” terms
– Software specification: An abstract description of the software itself. Mainly intended for software designers.
(C) Dr. Ernest Cachia, 1997Dept. of Computer Science and A. I., University of Malta
Slide
No.
66
Specification typesSpecification types
OperationalSpecifies system behaviour in terms of its internal (component) functions
DescriptiveSpecifies the system in terms of a declaration of the its properties