• What is a requirement?

• The requirements for the system are the

description of the services provided by the system
and its operational constraints
• 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;
• Requirements abstraction (Davis):
• If a company wishes to let a contract for a large
software development project, it must define its
needs in a sufficiently abstract way that a solution
is not pre-defined. The requirements must be
written so that several contractors can bid for the
contract, offering, perhaps, different ways of
meeting the client organisation’s needs. Once a
contract has been awarded, the contractor must
write a system definition for the client in more
detail so that the client understands and can
validate what the software will do. Both of these
documents may be called the requirements
document for the system.”
• Requirements engineering:
• The process of finding out, analysing
documenting and checking these services and
constraints is called requirement 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.
• 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.
• 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.
• 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.
 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
• 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(natural language)
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.
INTERFACE SPECIFICATION
• Most systems must operate with other systems and the
operating interfaces must be specified as part of the
requirements.
• Three types of interface may have to be defined
• Procedural interfaces where existing programs or sub-
systems offer a range of services that are accessed by calling
interface procedures. These interfaces are sometimes called
Application Programming Interfaces (APIs)
• Data structures that are exchanged that are passed from one
sub-system to another. Graphical data models are the best
notations for this type of description
• Data representations that have been established for an
existing sub-system
• Formal notations are an effective technique for interface
specification.
THE SOFTWARE 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
 REQUIREMENTS ENGINEERING PROCESSES

• The goal of requirements engineering process is to create

and maintain a system requirements document. The
overall process includes four high-level requirement
engineering sub-processes. These are concerned with
• Assessing whether the system is useful to the
business(feasibility study)
• Discovering requirements(elicitation and analysis)
• Converting these requirements into some standard
form(specification)
• Checking that the requirements actually define the system
that the customer wants(validation) The process of
managing the changes in the requirements is called
requirement management.
 Design engineering encompasses the set of
principals, concepts, and practices that lead to the
development of a high- quality system or product.

• Design principles establish an overriding philosophy

that guides the designer in the work that is
performed.
• Design concepts must be understood before the
mechanics of design practice are applied
• Design practice itself leads to the creation of
various representations of the software that serve
as a guide for the construction activity that follows.
 What is design:
• Design is what virtually every engineer wants
to do. It is the place where creativity rules –
customer’s requirements, business needs, and
technical considerations all come together in
the formulation of a product or a system.
Design creates a representation or model of
the software, but unlike the analysis model,
the design model provides detail about
software data structures, architecture,
interfaces, and components that are
necessary to implement the system.
Why is it important:

• Design allows a software engineer to model

the system or product that Is to be built. This
model can be assessed for quality and
improved before code is generated, tests are
conducted, and end – users become involved
in large numbers. Design is the place where
software quality is established.
 DESIGN PROCESS AND DESIGN QUALITY:
• Software design is an iterative process through which
requirements are translated into a “blueprint” for constructing
the software.

Goals of design:
McGlaughlin suggests three characteristics that serve as a guide for
the evaluation of a good design.
• The design must implement all of the explicit requirements
contained in the analysis model, and it must accommodate all of
the implicit requirements desired by the customer.
• The design must be a readable, understandable guide for those
who generate code and for those who test and subsequently
support the software.
• The design should provide a complete picture of the software,
addressing the data, functional, and behavioral domains from an
implementation perspective.
Quality guidelines:
• In order to evaluate the quality of a design
representation we must establish technical criteria for
good design. These are the following guidelines:

1. A design should exhibit an architecture that

a. has been created using recognizable architectural
styles or patterns
b. is composed of components that exhibit good
design characteristics
c. can be implemented in an evolutionary fashion,
thereby facilitating implementation and testing.
2. A design should be modular; that is, the
software should be logically partitioned into
elements or subsystems.
3. A design should contain distinct
representation of data, architecture, interfaces
and components.
4. A design should lead to data structures that
are appropriate for the classes to be
implemented and are drawn from
recognizable data patterns.
5. A design should lead to components that
exhibit independent functional characteristics.
6. A design should lead to interface that reduce the
complexity of connections between components
and with the external environment.
7. A design should be derived using a repeatable
method that is driven by information obtained
during software requirements analysis.
8. A design should be represented using a notation
that effectively communication its meaning

• These design guidelines are not achieved by chance.

Design engineering encourages good design through
the application of fundamental design principles,
systematic methodology, and thorough review.
Quality attributes:

• The FURPS quality attributes represent a

target for all software design:
• Functionality is assessed by evaluating the feature set and
capabilities of the program, the generality of the functions that are
delivered, and the security of the overall system.

• Usability is assessed by considering human factors, overall

aesthetics, consistency and documentation.

• Reliability is evaluated by measuring the frequency and severity of

failure, the accuracy of output results, and the mean – time –to-
failure (MTTF), the ability to recover from failure, and the
predictability of the program.

• Performance is measured by processing speed, response time,

resource consumption, throughput, and efficiency

• Supportability combines the ability to extend the program

(extensibility), adaptability, serviceability- these three attributes
represent a more common term maintainability
DESIGN CONCEPTS:

• M.A Jackson once said:”The beginning of

wisdom for a software engineer is to recognize
the difference between getting a program to
work, and getting it right.” Fundamental
software design concepts provide the
necessary framework for “getting it right.”
• Abstraction
• Architecture
• Patterns
• Modularity
• Information Hiding
• Functional Independence
• Refinement
• Refactoring
• Design classes
• Five different types of design classes, each
representing a different layer of the design
architecture are suggested.
• User interface classes: define all abstractions that
are necessary for human computer interaction. In
many cases, HCL occurs within the context of a
metaphor and the design classes for the interface
may be visual representations of the elements of
the metaphor.
• Business domain classes: are often refinements of
the analysis classes defined earlier. The classes
identify the attributes and services that are
required to implement some element of the
business domain.
• Process classes implement lower – level
business abstractions required to fully
manage the business domain classes.
• Persistent classes represent data stores that
will persist beyond the execution of the
software.
• System classes implement software
management and control functions that
enable the system to operate and
communicate within its computing
environment and with the outside world.
THE DESIGN MODEL:

• The design model can be viewed into

different dimensions.
• The process dimension indicates the evolution
of the design model as design tasks are
executed as a part of the software process.
 USER INTERFACE DESIGN
Interface design focuses on three areas of
concern:
(1) the design of interfaces between software
components,
(2) the design of interfaces between the
software and other nonhuman producers and
consumers of information (i.e., other external
entities), and
(3) the design of the interface between a human
(i.e., the user) and the computer.
What is User Interface Design?

User interface design creates an effective

communication medium between a human
and a computer. Following a set of interface
design principles, design identifies interface
objects and actions and then creates a screen
layout that forms the basis for a user interface
prototype.
Why is User Interface Design important?

If software is difficult to use, if it forces you

into mistakes, or if it frustrates your efforts to
accomplish your goals, you won’t like it,
regardless of the computational power it
exhibits or the functionality it offers. Because
it molds a user’s perception of the software,
the interface has to be right.
THE GOLDEN RULES
Theo Mandel coins three “golden rules”:
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.

These golden rules actually form the basis for

a set of user interface design principles that
guide this important software design activity.
 USER INTERFACE DESIGN

Interface Design Models

Four different models come into play when a user interface
is to be designed.
--The software engineer creates a design model,
--A human engineer (or the software engineer) establishes a
user model,
--The end-user develops a mental image that is often called
the user's model or the system perception, and
--The implementers of the system create a implementation
model.

• The role of interface designer is to reconcile these

differences and derive a consistent representation of the
interface.
The User Interface Design Process: (steps in
interface design)
The user interface design process
encompasses four distinct framework
activities :
1. User, task, and environment analysis and
modeling
2. Interface design
3. Interface construction
4. Interface validation
 User Task and Environmental Analysis
--The interface analysis activity focuses on the
profile of the users who will interact with the
system. Skill level, business understanding, and
general receptiveness to the new system are
recorded; and different user categories are
defined.
Interface Design:
--The goal of interface design is to define a set of
interface objects and actions (and their screen
representations) that enable a user to perform all
defined tasks in a manner that meets every
usability goal defined for the system.
Interface Construction(implementation)

--The implementation activity normally begins

with the creation of a prototype that enables
usage scenarios to be evaluated. As the
iterative design process continues, a user
interface tool kit may be used to complete the
construction of the interface.
Interface Validation:
Validation focuses on
--The ability of the interface to implement
every user task correctly, to accommodate all
task variations, and to achieve all general user
requirements;
--The degree to which the interface is easy to
use and easy to learn; and
--The users’ acceptance of the interface as a
useful tool in their work.
 INTERFACE ANALYSIS
--A Key tenet of all software engineering process
models is this: you better understand the
problem before you attempt to design a solution.
(1) The people who will interact with the system
through the interface
(2) the tasks that tend-users must perform to do
their work
(3) the content that is presented as part of the
inter face, an
(4) the environment in which these tasks will be
conducted. In the sections that follow
 DESIGN EVALUATION
• After the design model has been completed, a
first-level prototype is created. The prototype
is evaluated by the user, who provides the
designer with direct comments about the
efficacy of the interface. In addition, if formal
evaluation techniques are used e.g.,
questionnaires, rating sheets, the designer
may extract information form these data (e.g.,
80percent of all users did not like the
mechanism for saving data files).
Once the first prototype is built, the designer
can collect a variety of qualitative and
quantitative data that will assist in evaluating
the interface. To collect 2qualitaive data,
questionnaires can be distributed to users of
the prototype. Questions can be (1) simple
yes/no response, (2) numeric response, (3)
scaled (subjective) response,(4) Likert
scales(e.g., strongly.
 SOFTWARE ARCHITECTURE:

What Is Architecture?
--Architectural design represents the structure
of data and program components that are
required to build a computer-based system. It
considers
-The architectural style that the system will take,
-- The structure and properties of the
components that constitute the system, and
-- The interrelationships that occur among all
architectural components of a system.
The architecture is a representation that
enables a software engineer to

(1) analyze the effectiveness of the design in

meeting its stated requirements,
(2) consider architectural alternatives at a
stage when making design changes is still
relatively easy,
(3) reducing the risks associated with the
construction of the software.
The design of software architecture considers
two levels of the design pyramid

- data design
Data design enables us to represent the
data component of the architecture.
- architectural design.
Architectural design focuses on the
representation of the structure of software
components, their properties, and
interactions.
 Why Is Architecture Important?
Representations of software architecture are an
enabler for communication between all parties
(stakeholders) interested in the development of a
computer-based system.

The architecture highlights early design decisions that

will have a profound impact on all software engineering
work that follows and, as important, on the ultimate
success of the system as an operational entity.

Architecture “constitutes a relatively small,

intellectually graspable model of how the system is
structured and how its components work together”
 A strategic Approach for Software testing
• Software Testing
• One of the important phases of software
development
• Testing is the process of execution of a
program with the intention of finding errors
• Involves 40% of total project cost
• Testing Strategy
• A road map that incorporates test planning,
test case design, test execution and resultant
data collection and execution
• Validation refers to a different set of activities
that ensures that the software is traceable to
the customer requirements.
• V&V encompasses a wide array of Software
Quality Assurance
• Perform Formal Technical reviews(FTR) to
uncover errors during software development
• Begin testing at component level and move
outward to integration of entire component
based system.
• Adopt testing techniques relevant to stages of
testing
• Testing can be done by software developer
and independent testing group
• Testing and debugging are different activities.
Debugging follows testing
• Low level tests verifies small code segments.
• High level tests validate major system
functions against customer requirements
Testing Strategies for Conventional Software

1)Unit Testing
2) Integration Testing
3)Validation Testing and
4)System Testing
A STRATEGIC APPROACH TO SOFTWARE TESTING
• Testing is a set of activities that can be
planned in advance and conducted
systematically.
• For this reason a template for software testing
—a set of steps into which you can place
specific test case design techniques and
testing methods—should be defined for the
software process.
• To perform effective testing, you should conduct effective
technical reviews(Chapter 15). By doing this, many errors
will be eliminated before testing commences.
• Testing begins at the component level and works
“outward” toward the integration of the entire computer-
based system.
• Different testing techniques are appropriate for different
software engineering approaches and at different points
in time.
• Testing is conducted by the developer of the software and
(for large projects) an independent test group.
• Testing and debugging are different activities, but
debugging must be accommodated in any testing
strategy.
 Verification and Validation

• Software testing is one element of a broader

topic that is often referred to as verification
and validation (V&V).
• Verification refers to the set of tasks that
ensure that software correctly implements a
specific function.
• Validation refers to a different set of tasks that
ensure that the software that has been built is
traceable to customer requirements.
• Verification: “Are we building the product
right?”

• Validation: “Are we building the right

product?”
 Software Testing
• The goal of testing is to find errors, and a good
test is one that has a high probability of
finding an error. The design and implement
should be done on computer based system or
a product with “testability” in mind.
Most errors with a minimum of effort.
• Two major categories of software testing
– Black box testing
– White box testing
 Black box testing
Treats the system as black box whose behavior
can be determined by studying its input and
related output Not concerned with the
internal structure of the program
• It focuses on the functional requirements of
the software ie it enables the sw engineer to
derive a set of input conditions that fully
exercise all the functional requirements for
that program.
• Concerned with functionality and
implementation
1) Graph based testing method
Draw a graph of objects and relations
Devise test cases t uncover the graph such
that each object and its relationship exercised.

2) Equivalence partitioning
Divides all possible inputs into classes such
that there are a finite equivalence classes.
Equivalence class
White Box testing
 Also called glass box testing
 Involves knowing the internal working of a program
 Guarantees that all independent paths will be
exercised at least once.
 Exercises all logical decisions on their true and false
sides
 Executes all loops
 Exercises all data structures for their validity

White box testing techniques

1. Basis path testing
2. Control structure testing
 WHAT IS QUALITY
• An effective software process applied in a
manner that creates a useful product that
provides measurable value for those who
produce it and those who use it.

• user satisfaction = compliant product +good

quality +delivery within budget and schedule
 RISK MANAGEMENT
REACTIVE VS. PROACTIVE RISK STRATEGIES

• At best, a reactive strategy monitors the

project for likely risks. Resources are set
aside to deal with them, should they become
actual problems

• More commonly, the software team does

nothing about risks until something goes
wrong.
RISK MANAGEMENT