1. Historical Background
- In the early days of computing, software was
developed by many individuals following their own
methods. the programmer writes some code and then
tests it to see how it performs. The programmer then
uses the test results to modify or fix the code and tests
again.
- They get by with this type of development for two
reasons:

2. Cont….
1. no better way had been developed.
2. software was not complex.
- software grew more complicated and organizations
relied on computers for more of their operations,
including finances and even human lives.
- The overall framework in which software is
conceived, developed, and maintained is known as
the Software Development Life Cycle (SDLC).

3. Software Development Life Cycle
- Life cycles are usually referred to as models.
- Models define the phases of a software develo-
ment effort.

4. RequirementsRequirements
DesignDesign
ImplementationImplementation
TestingTesting
DeploymentDeployment
MaintenanceMaintenance
Common Life Cycles Phases

5. Water Fall Model
• We will mention the Water Fall Model to
explain the existence of Specification
during software life cycle.
The Figure below can express this:

7. Another View to explain
the Position of Specification

8. Overview
 Some of today’s biggest players in the software
development market will begin to falter. Why?
( there is a functional limit to systems can deliver).
( the size of the systems).
 the size of new systems alone will initiate the
collapse of the companies trying to build them.
 magic amulets and nostrum can not assist to solve
this problem, just you have to work hard.

9. Giza Vs Eiffel
 Giza is 246 m high, weighs some 55,000,000.
 Eiffel tower 300 m high, weighs 7000 tons.
 In Giza engineers stack mud bricks, but they
collapse under their own weight.
 They reached the maximum height permitted by
structural building blocks. If they exceeded it will
be disintegrated.
 Eiffel tower was “engineered”.

10.  We are exactly do the same in the design of
software systems, we simply stack code modules
on top of one another until we reach the functional
limits of the language, then, they crack and break.
 The task for modern software engineers is a simple
one:
“ we must stop building pyramids and learn how
to build very lean, well-engineered systems !!”.
 Gains in computer systems must not come from the
hardware developers, but from software
developers.

11. Specifications Definitions
 Dictionary definition of specification is:
“a detail of design or materials for work to be
undertaken “.
 For example, in the field of Engineering this might
be a set of Technical Drawings, complete with
dimensions, tolerances, parts lists and so on.
 Note:
Try to form your own opinion about software
specification before reading on what others have
defined a software specification.

12. Other Definitions
1. A specification describes WHAT a program does,
a design describes HOW the program does it, and
documentation describes WHY it does it.
2. A specification is a document which forms a
contract between the customer and the designer.
3. A Specification is the second phase in the `staged'
model of software development, which consists of:
Requirements; Specification; Design;
Implementation; Testing; Maintenance.

13. Cont…
4. A specification is a document by which we
can judge the correctness of an
implementation.

15. Lecture 2

16. Software Problems
• a phrase “Software is always delivered late, over
budget and full of errors”.
• Examples:
1. cities lost telephone service for almost many hours
due to software errors.
Zain service (4x4).
2. Computers installed in automobiles stop working.
3. A bank, because of a software error, “overspent” its
resources [Chaos Movie].
SOFTWARE SPECIFICATION: A Comparison of Formal Methods
By John D. Gannon, James M. Purtilo, Marvin V. Zelkowitz
Page 1+2

17. Discuss
• the vast majority of expenditures occur at the back
end of the software life cycle.
• Hint:
• These resources could be more wisely spent on the
earlier stages of the software life cycle in the
specification and design of the systems.
• Software Specification and design, John Munson, Page: 4

18. Discuss
• When the code base is changing, did the System Specs
change as well.
• Software Specification and design, John Munson, Page: 10

19. What is a correct software system?
• The program does what it is supposed to do. But what is
that? In order to understand what it is supposed to, we
need a description of what it should do. Right now we
will informally call it the specification. A program is
correct if it meets its specification.
Correct Specification = Correct Software
• SOFTWARE SPECIFICATION: A Comparison of Formal Methods
By John D. Gannon, James M. Purtilo, Marvin V. Zelkowitz
Page 1+2

20. An overview of the Software Development Process
1
• Generally, there are three models that we must use to create
software systems:
• First, The Operational Machine:
• represents the user’s view of the system.
(what the software will do for the user)
• Operational Machine will be represented by:
1. Operational Model.
2. Operations.
• The user will interact with an operational model through a precise
set of operations.
• Software Specification and design, John Munson, Page: xvii,-xx

21. • Second, The Functional Machine:
• The software designer converts the operational model
into a functional description of the system.
• Functional Machine drive operational machine.
• F.M contains:
1. Functional Model.
2. Functionalities.
• This functional model will create an abstract machine
that will determine:
( how each of the operations is to be converted to
functionalities that will drive this abstract machine)

22. • Third, The Language Metaphor:
• once we have a good and clear understanding of
what is to be done and how we wish to achieve this
goal, the final task is to identify the appropriate
language metaphor that provides the best cap-
abilities for mapping the functional model into set
of machine instructions.
• Software Specification and design, John Munson, Page: xvii,-xx

23. Discuss
• the vast majority of expenditures occur at the back
end of the software life cycle. These resources could
be more wisely spent on the earlier stages of the
software life cycle in the specification and design
of the systems.
• Software Specification and design, John Munson, Page: 4

24. An overview of the Software Development Process
2
• Software system begins with a set of requirements. the
system requirements are really an attribute of a user or
customer.
• Requirements can be explicit and well defined, or they
can be implicit and not so well defined.
• Sometimes customers do not really have a good, clear
idea of what their requirements are. So we are going to
work with them to build a suitable abstract machine
that embodies their specific needs.
• Software Specification and design, John Munson, Page: 2-3

26. Requirements Engineering
• The requirements engineer work with the user to
determine what the user’s needs are. And develop a
working set of software specifications that will specify this
system in terms of a basic set of operations.
• There are two objectives of the requirements engineering
process. First, we must work with the user to elicit his
requirements and then develop an operational model for a
system that will best meet the user’s needs or requirements.
• This operational model is the design of the abstract
machine or environment that we are going to work with the
user to create.
• Software Specification and design, John Munson, Page: 10-11

27. • the requirements engineering process is not a
single-cycle process, because the user view of
his own needs will, in all likelihood, change.
Discuss
- If we need to create a computer game(enviro).
- Benjamin Vs TV & Remote Control.
(Buttons = operations)
- Did you know How the TV works?
Software Specification and design, John Munson, Page: 11

28. Summary
• the objective of the requirements engineering
process is to work with a customer (user) to
build an operational model for the user and a
set of operations that will manipulate this
operational model.
Software Specification and design, John Munson, Page: 13

29. Requirements Analysis
• Requirement is an intrinsic property of an entity
not attributes of software documents.
• We interact with the entity to develop an abstract
machine, the operational model that will best fulfill
the user’s requirements. The documentation
surrounding the operational machine that we
develop in response to the user’s requirements is
known as the operational specification. The
customer’s requirements are fulfilled in the
operational specification.
Software Specification and design, John Munson, Page: 35

30. • The process of squeezing out the
requirements
from customers is called requirements
elicitation.
• a specially trained person called a
requirements analyst is needed to work with
customers to match up a set of operational
specifications for a system that can be built
with the requirements or felt needs of these
customers.
Software Specification and design, John Munson, Page: 35

31. Concept of a Customer
• A customer for a software project need not
always be flesh and blood. In the case of
embedded systems, it is best to think of the
customer as the hardware system that the
software is driving. Perhaps a much better
term than “customer” would be the term
“client.” Unfortunately, the notion of a client
has recently acquired many different
meanings, particularly in the area of computer
networks. So, customer it is.
Software Specification and design, John Munson, Page: 35-37

32. Customers
• Customers as:
1. real Person.
• Questions about the operational specifications for the system
that will satisfy the customer’s requirements can be resolved
with direct interaction with the customer.
2. Hardware (embedded systems)
• The operational model, in this case, is a hardware system with
a set of operations that will be used by the customer of the
system to manipulate this real machine.
Software Specification and design, John Munson, Page: 35-37

33. 3. Marketing abstraction
The operational specifications for these systems will be derived from
requirements developed by a staff of professionals in the marketing
division.
4. Stakeholders
two levels of individuals, those who will be direct consumers and those who
will be impacted by second- or third-order effects of the system. As in
decision support system. Requirements must be from all.
Software Specification and design, John Munson, Page: 35-37

34. Requirements Elicitation
• The problem of a Car salesman= RE.
- You must qualify(keep) the customer.
- did the financial ability buy a car (time consuming).
- qualifying within constraints (the range).
-then .problems of colors, styles, engines.
• The main objective of the requirements elicitation
process is to make the customer’s requirements
manifest (clear) in an operational specification that
best describes this need.
Software Specification and design, John Munson, Page: 38

35. Requirements Elicitation Methods
1.Obtrusive (Direct) Observation:
- Questionnaire, Interviews, direct monitoring.
• - the problem is that, it will alter the environment
we are attempting to understand. The presence of the
observer will cause the employee to alter his behavior
to meet the expectations of his job definition.
( What will happen after the observer leaves?)
Software Specification and design, John Munson, Page: 41

36. 1. Unobtrusive Observation:
• -We must learn what a customer says he will do with a
software system and what he will really do. For that The
actual observation of the employee is taken without the
employee’s knowledge, It is unobtrusive.

38. Operational Specification
• This is the user’s view of the system.
• we can create virtually any reality that we wish. The
virtual system that we create for the user is called the
operational model.
• There are three components to the complete operational
specification:
- 1st: operational system overview:
a high-level description of the system and its character-
istics.

39. - 2end: The operational model:
is a very precise description of the abstract machine with
which the user will interact.
• It consists of three parts:
1. a diagram or pictorial representation of the abstract
machine.
2. a general description of what the user must do to
interact or animate the operational machine.
3. constraints on the operational requirements.
- 3rd: set of operations that define the interactions that a
user will have with the operational machine.

40. • There are two major objectives in the development of the
operational specification:
1. construct an abstract machine to validate against
requirements. That means, the documents that
describe this abstract machine a legal contract with a user.
2. ensure that the operational specification will be clear.
• The software must behave exactly in the manner of the
abstract machine outlined in the operational model. It will
do no more than that and it will do no less.

41. Operational System Overview
• It is a concise statement of the basic operation of the
system from the user’s perspective. It gives an overview of
the operation of the system.
• It looks like the thing that printed on the cover of a CD-
ROM containing the software. We will be able to read this
description and know what the system will do for us.
• The OSO constitutes a summary of the purpose of the
system.
Discuss:
- What about the large systems?

42. Operational System Model
• we can create virtually any reality that we want by using
modern software technology.
• It defines very precisely the user’s overview of the system
operation. It answers the question of what the system does.
• E.g.: a calculator:
- define for the user how many decimal places would
maintain for calculations.
- what operations were allow.
- how the data would be entered.
- how the data would be displayed.

43. Constraints on the Operational Model
• every user has some considerations about the software
such as:
- the system to run well.
- have minimal impact on system resources.
- not break when placed into service.
• put in mind that these are not operational issues, but they
describe constraints added to the operational characteristics
of the system.

44. Constraints are:
1. Reliability. A reliable software is one that does not break
when placed into service.
• Reliability is a function of how the software will be used
by that customer.
• Some operations of the software will perform flawlessly
and forever. Other operations of the same software
system will be flawed. Software reliability, then, is
determined by the interaction between the structure of the
code and the user’s operation of the system.
• The failure of a software system depends only on what
the software is currently doing.

45. • Programs are designed to perform a set of mutually exclusive
functions. Some of these functions work quite well, while
others may not work well at all.
• Two users of the same software may have totally different
perceptions as to the reliability of the same system. One user
might use the system on a good manner. Another user might
have continual problems trying to execute exactly the same
program.
Note:
• The reliability of a system is clearly related to the operations
that a user performs on the system.

46. 2. Security. A secure system is one that can repulse all attempts
for misuse.
3. Availability. A system that has been developed for high
availability applications can identify problems as they occur
and seek for solving these problems before the system can
fail.
• Also the ability to change from domain to another.
• 4. Maintainability. A developer is trying to fix a code
problem or solve a design problem. but the user is not, he is
trying to install the software on his computer. This process
must be easy and straightforward without consulting the
software development organization. also it must be east to
remove or uninstall.
• Discuss: - the unseen programs.
- Software Update process

47. • 5. Survivability. most modern software systems are very
fragile. If any faults are encountered during their operation,
the entire system is likely to fail.
• To explain:
- ATM ,can the statement failure stop the system.
- an automobile stop dead in the road due to the failure of a
headlight.
• Attribute of survivability means the system can continue to
operate minus the services of one or more of its operations.
• The problem is that, If the functional components of a system
are tightly woven together, then a system will be very fragile.
• the functional components must be tightly compartment-
alized.

48. • Context is very important to the notion of survivability. lose
of headlight in the middle of the day, is quite different to
fail in the midnight.