UNIT-III

(Part-1)

Software Process Models

 Software process model
• Process models prescribe a distinct set of activities,
actions, tasks, milestones, and work products
required to engineer high quality software.
• Process models are not perfect, but provide
roadmap for software engineering work.
• Software models provide stability, control, and
organization to a process that if not managed can
easily get out of control.
• Software process models are adapted to meet the
needs of software engineers and managers for a
specific project.
 Why Models are needed?
• Symptoms of inadequacy: the software crisis
– scheduled time and cost exceeded
– user expectations not met
– poor quality
 Prescriptive Model
• Prescriptive process models advocate an orderly approach to software
engineering
– Organize framework activities in a certain order
• Process framework activity with set of software engineering actions.
• Each action in terms of a task set that identifies the work to be accomplished
to meet the goals.
• The resultant process model should be adapted to accommodate the nature
of the specific project, people doing the work, and the work environment.
• Software engineer choose process framework that includes activities like;
– Communication
– Planning
– Modeling
– Construction
– Deployment
 Prescriptive Model
• Calling this model as “Prescribe” because it
recommend a set of process elements,
activities, action task, work product & quality.
• Each elements are inter related to one
another (called workflow).
Waterfall Model or Classic Life Cycle
 Waterfall Model or Classic Life Cycle
• Requirement Analysis and Definition: What - The systems services,
constraints and goals are defined by customers with system users.
• Scheduling tracking -
– Assessing progress against the project plan.
– Require action to maintain schedule.
• System and Software Design: How –It establishes and overall system
architecture. Software design involves fundamental system abstractions
and their relationships.
• Integration and system testing: The individual program unit or programs
are integrated and tested as a complete system to ensure that the
software requirements have been met. After testing, the software system
is delivered to the customer.
• Operation and Maintenance: Normally this is the longest phase of the
software life cycle. The system is installed and put into practical use.
Maintenance involves correcting errors which were not discovered in
earlier stages of the life-cycle.
 Limitations of the waterfall model
❑ The nature of the requirements will not change very much
During development; during evolution
❑ The model implies that you should attempt to complete a
given stage before moving on to the next stage
❑ Does not account for the fact that requirements
constantly change.
❑ It also means that customers can not use anything until
the entire system is complete.
❑ The model implies that once the product is finished,
everything else is maintenance.
❑ Surprises at the end are very expensive
❑ Some teams sit ideal for other teams to finish
❑ Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process. 8
• Problems:
1. Real projects are rarely follow the sequential
model.
2. Difficult for the customer to state all the
requirement explicitly.
3. Assumes patience from customer - working
version of program will not available until
programs not getting change fully.
 Incremental Process Model

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

Delivers software in small but usable pieces, each piece builds on pieces
already delivered
 The Incremental Model
• Rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment delivering
part of the required functionality.
• First Increment is often core product.
– Includes basic requirement
– Many supplementary features (known & unknown) remain
undelivered
• A plan of next increment is prepared
– Modifications of the first increment
– Additional features of the first increment
• It is particularly useful when enough staffing is not available for the whole
project
• Increment can be planned to manage technical risks.
• Incremental model focus more on delivery of operation product with each
increment.
 The Incremental Model
• User requirements are prioritised and the highest priority
requirements are included in early increments.
• Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.
• Customer value can be delivered with each increment so
system functionality is available earlier.
• Early increments act as a prototype to help elicit requirements
for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most
testing.
Rapid Application Development (RAD) Model

Makes heavy use of reusable software components with an extremely short development cycle
 RAD Model
• Communication – to understand business problem.
• Planning – multiple s/w teams works in parallel on diff.
system.
• Modeling –
– Business modeling – Information flow among business is
working.
Ex. What kind of information drives?
Who is going to generate information?
From where information comes and goes?
– Data modeling – Information refine into set of data objects
that are needed to support business.
– Process modeling – Data object transforms to information
flow necessary to implement business.
• Construction – it highlighting the use of pre-existing
software component.
• Deployment – Deliver to customer basis for
subsequent iteration.
• RAD model emphasize a short development cycle.
• “High speed” edition of linear sequential model.
• If requirement are well understood and project
scope is constrained then it enable development
team to create “ fully functional system” within a
very short time period.
 RAD Model
• If application is modularized (“Scalable Scope”), each major
function to be completed in less than three months.
• Each major function can be addressed by a separate team
and then integrated to form a whole.
Drawback:
• For large but scalable projects
– RAD requires sufficient human resources
• Projects fail if developers and customers are not committed
in a much shortened time-frame
• Problematic if system can not be modularized
• Not appropriate when technical risks are high ( heavy use of
new technology)
 Evolutionary Process Model
• Produce an increasingly more complete
version of the software with each iteration.
• Evolutionary Models are iterative.
• Evolutionary models are:
– Prototyping
– Spiral Model
– Concurrent Development Model
– Fourth Generation Techniques (4GT)
Evolutionary Process Models :
Prototyping
 Prototyping cohesive
 Best approach when:
◦ Objectives defines by customer are general but does not have details like input,
processing, or output requirement.
◦ Developer may be unsure of the efficiency of an algorithm, O.S., or the form
that human machine interaction should take.
 It can be used as standalone process model.
 Model assist software engineer and customer to better understand what is to be
built when requirement are fuzzy.
 Prototyping start with communication, between a customer and software
engineer to define overall objective, identify requirements and make a boundary.
 Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
 Quick design leads to prototype construction.
 Prototype is deployed and evaluated by the customer/user.
 Feedback from customer/end user will refine requirement and that is how
iteration occurs during prototype to satisfy the needs of the customer.
 Prototyping (cont..)
 Prototype can be serve as “the first system”.
 Both customers and developers like the prototyping paradigm.
◼ Customer/End user gets a feel for the actual system
◼ Developer get to build something immediately.

Problem Areas:
 Customer cries foul and demand that “a few fixes” be applied to make
the prototype a working product, due to that software quality suffers
as a result.
 Developer often makes implementation in order to get a prototype
working quickly without considering other factors in mind like OS,
Programming language, etc.

Customer and developer both must be agree that the prototype is built to
serve as a mechanism for defining requirement.
Evolutionary Model: Spiral Model
 Spiral Model
❑Couples iterative nature of prototyping with the controlled
and systematic aspects of the linear sequential model
 It provide potential for rapid development of increasingly
more complete version of the software.
 Using spiral, software developed in as series of evolutionary
release.
◦ Early iteration, release might be on paper or prototype.
◦ Later iteration, more complete version of software.
 Divided into framework activities (C,P,M,C,D). Each activity
represent one segment.
 Evolutionary process begins in a clockwise direction,
beginning at the center risk.
 First circuit around the spiral might result in development of
a product specification. Subsequently, develop a prototype
and then progressively more sophisticated version of
software.
 Unlike other process models that end when software is
delivered.
 It can be adapted to apply throughout the life of software.
Spiral Model
 Spiral Model (cont.)
Concept Development Project:
• Start at the core and continues for multiple iterations until it is complete.
• If concept is developed into an actual product, the process proceeds outward on
the spiral.
New Product Development Project:
• New product will evolve through a number of iterations around the spiral.
• Later, a circuit around spiral might be used to represent a “Product Enhancement
Project”
Product Enhancement Project:
• There are times when process is dormant or software team not developing new
things but change is initiated, process start at appropriate entry point.
• Spiral models uses prototyping as a risk reduction mechanism but, more
important, enables the developer to apply the prototyping approach at
each stage in the evolution of the product.

• It maintains the systematic stepwise approach suggested by the classic

life cycle but also incorporates it into an iterative framework activity.
• If risks cannot be resolved, project is immediately terminated
Problem Area:
• It may be difficult to convince customers (particularly in contract
situations) that the evolutionary approach is controllable.
• If a major risk is not uncovered and managed, problems will
undoubtedly occur.
Concurrent Development Model
•
Concurrent Development Model
It represented schematically as series of major technical activities, tasks,
and their associated states.
• It is often more appropriate for system engineering projects where
different engineering teams are involved.
• The activity-modeling may be in any one of the states for a given time.
• All activities exist concurrently but reside in different states.
E.g.
• The analysis activity (existed in the none state while initial customer
communication was completed) now makes a transition into the under
development state.
• Analysis activity moves from the under development state into the
awaiting changes state only if customer indicates changes in
requirements.
• Series of event will trigger transition from state to state.
E.g. During initial stage there was inconsistency in design which was
uncovered. This will triggers the analysis action from the Done state into
Awaiting Changes state.
 Concurrent Development (Cont.)

• Visibility of current state of project

• It define network of activities
• Each activities, actions and tasks on the
network exists simultaneously with other
activities ,actions and tasks.
• Events generated at one point in the process
network trigger transitions among the states.
Fourth Generation Techniques(4GT)
 Component Based Development
• component-based development (CBD) model incorporates
many of the characteristics of the spiral model.
• It is evolutionary by nature and iterative approach to create
software.
• CBD model creates applications from prepackaged software
components (called classes).
CBD Model
 CBD model (cont.)
• Modeling and construction activities begin with identification
of candidate components.
• Classes created in past software engineering projects are
stored in a class library or repository.
• Once candidate classes are identified, the class library is
searched to determine if these classes already exist.
• If class is already available in library extract and reuse it.
• If class is not available in library, it is engineered or developed
using object-oriented methods.
• Any new classes built to meet the unique needs of the
application.
• Now process flow return to the spiral activity.
 CBD Model (cont.)
• CBD model leads to software reusability.
• Based on studies, CBD model leads to 70 %
reduction in development cycle time.
• 84% reduction in project cost.
• Productivity is very high.
 UNIT-III
(Part-2)

Software Requirements
 Objectives
• To introduce the concepts of user and system
requirements
• To describe functional and non-functional
requirements
• To explain two techniques for describing
system requirements
• To explain how software requirements may be
organised in a requirements document
 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
 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 services. Written as a
contract between client and contractor
• Software specification
– A detailed software description which can serve as a
basis for a design or implementation. Written for
developers
 Definitions and specifications
Requirements definition

1. The software must provide a means of repr esenting and

1. accessing external files created by other tools.

Requirements specification

1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
 Requirements readers
Client managers
System end-users
User requirements Client engineers
Contractor managers
System architects

System end-users
Client engineers
System requirements
System architects
Software developers

Client engineers (perhaps)

Software design
System architects
specification
Software developers
 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
 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
• 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-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements
 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 K Bytes
Number of RAM chips
Ease of use Training time
Number 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
Number 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 characterisics and features
that reflect the domain
• May 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.
 Train protection system

• The deceleration of the train shall be

computed as:
– Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated
gradient/alpha and where the values of
9.81ms2 /alpha are known for different
types of train.
 Domain requirements problems
• 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 so that they are understandable
by system users who don’t have detailed
technical knowledge
• User requirements are defined using natural
language, tables and diagrams
 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
 Database requirement
4.A.5 The database shall support the generation and control of
configuration objects; that is, objects which are themselves
groupings of other objects in the database.

The configuration control facilities shall allow access to the objects

in a version group by the use of an incomplete name.
 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 user
requirements
• Serve as a basis for designing the system
• May be used as part of the system contract
• System requirements may be expressed 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 This approach depends on defining standard forms or
natural templates to express the requirements specification.
language
Design This approach uses a language like a programming
description language but with more abstract features to specify the
languages requirements by defining an operational model of the
system.
Graphical A graphical language, supplemented by text annotations is
notations used to define the functional requirements for the system.
An early example of such a graphical language was SADT
(Ross, 1977; Schoman and Ross, 1977). More recently,
use-case descriptions.
Mathematical These are notations based on mathematical concepts
specifications such as finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer
and contractor about system functionality. However, most
customers don’t understand formal specifications and are
reluctant to accept it as a system contract.
Structured language specifications
• A limited form of natural language may be
used to express requirements
• This removes some of the problems resulting
from ambiguity and flexibility and imposes a
degree of uniformity on a specification
• Often best supported using a forms-based
approach
 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)
 Form-based node specification
ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Function Add node

Description Adds a node to an existing design. The user selects the type of node, and its position.
When added to the design, the node becomesthe current selection. The user chooses the node position by
moving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier.
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
Destination The design database. The design is committed to the database on completion of the
operation.
Requires Design graph rooted at input design identifier.
Pre-condition The design is open and displayed on the user's screen.
Post-condition The design is unchanged apart from the addition of a node of the specified type
at the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
PDL-based requirements definition
• Requirements may be defined operationally using a language like a
programming language but with more flexibility of expression
• Most appropriate in two situations
– Where an operation is specified as a sequence of
actions and the order is important
– When hardware and software interfaces have to be
specified
• Disadvantages are
– The PDL may not be sufficiently expressive to define
domain concepts
– The specification will be taken as a design rather than
a specification
 Part of an ATM specification
class ATM {
// declarations here
public static void main (String args[]) throws InvalidCard {
try {
[Link] () ; // may throw InvalidCard exception
pin = [Link] () ; attempts = 1 ;
while ( ![Link] (pin) & attempts < 4 )
{ pin = [Link] () ; attempts = attempts + 1 ;
}
if (![Link] (pin))
throw new InvalidCard ("Bad PIN");
thisBalance = [Link] () ;
do { [Link] (" Please select a service ") ;
service = [Link] () ;
switch (service) {
case [Link]:
receiptRequired = true ;
 PDL disadvantages
• PDL may not be sufficiently expressive to
express the system functionality in an
understandable way
• Notation is only understandable to people
with programming language knowledge
• The requirement may be taken as a design
specification rather than a model to help
understand the system
 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
– Data structures that are exchanged
– Data representations
• Formal notations are an effective technique for
interface specification
 PDL interface description

interface PrintServer {

// defines an abstract printer server

// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;

void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
 The requirements document
• The requirements document is the official
statement of what is required of the system
developers
• Should include both a definition and a
specification of 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
 Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

Use the requirements to

System engineers understand what system is to
be developed

System test Use the requirements to

engineers develop validation tests for
the system

Users of a
System Use the requirements to help requirements
maintenance understand the system and
the relationships between its
document
engineers
parts
Requirements document requirements

• Specify external system behaviour

• Specify implementation constraints
• Easy to change
• Serve as reference tool for maintenance
• Record forethought about the life cycle of the
system i.e. predict changes
• Characterise responses to unexpected events
 IEEE requirements standard
• Introduction
• General description
• Specific requirements
• Appendices
• Index
• This is a generic structure that must be
instantiated for specific systems
 Requirements document structure
• 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
 Key points
• User requirements should be written in natural
language, tables and diagrams
• System requirements are intended to communicate
the functions that the system should provide
• System requirements may be written in structured
natural language, a PDL or in a formal language
• A software requirements document is an agreed
statement of the system requirements