Unit-1

Software product: Software products are nothing but software systems delivered to customer
with the customer with the documentation that describes how to install and use the system.

Software is classified into two classes: Generic and Customized

i. Generic product is designed for a broad customer market whose requirements are very
common, fairly stable and well understood by the software engineer.
Examples are database products, browsers, CAD/CAM packages, OS and system software
ii. Customized products are those that are developed for a customer where domain,
environment and requirement being unique to that customer cannot be satisfied by generic
software. Examples are traffic management systems, process control systems, hospital
management systems etc.

Software process can be defend as the structured set of activates that are required to develop
the software system.
Software Process is a set of activities, together with ordering constraints among them, such
that if the activities are performed properly and in accordance with the ordering constraints,
the desired result is produced. The desired result is high-quality software at low cost.

Any software process must include the following four activities:

1. Software specification (or requirements engineering): Define the main functionalities of
the software and the constrains around them.
2. Software design and implementation: The software is to be designed and programmed.
3. Software verification and validation: The software must conforms to it’s specification
and meets the customer needs.
4. Software evolution (software maintenance): The software is being modified to meet
customer and market requirements changes.

Characteristics of Software Process is as follows:-

Predictability can be considered as a fundamental property of any process. Predictability of a
process determines how accurately that outcome of following process in a can be predicted
before the project is completed. If process is not predictable, then it is of limited use.
Testability and Maintainability one of the important objectives of the development project
should be to produce that is easy to maintain and the process should be such that it ensures
this maintainability. The second important effort is the testing, which consumes most resources
during development.
Early defect removal and Defect prevention should be continuous process that is done
throughput software development.
Process Improvement is not a static quality. To satisfy the engineering objectives of quality
improvement and cost reduction, the software process must be improved because in the
context of software, the productivity and quality are determined largely by the process.
Difference between methodology and process
A software process is an abstract representation of a process methodology. Waterfall1 is a
process model. Agile is a process model. They don't specify how to do things, but outline the
types of things that are done. For example, Waterfall identifies the phases that a project goes
through - requirements, design, implementation/unit testing, integration testing, system
testing, deployment - without saying what artifacts to produce or what tools to use.
A software process methodology is a specific way of conducting a software project. These are
things like the Rational Unified Process and Scrum. They define exactly what, when, and/or how
various artifacts are produced.

Life cycle model of software development specifies the different activities that need to be
performed to develop a software product and the sequencing of these activities .
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality softwares. The SDLC aims to produce a high-quality software that
meets or exceeds customer expectations, reaches completion within times and cost estimates.
 SDLC is the acronym of Software Development Life Cycle.
 It is also called as Software Development Process.
 SDLC is a framework defining tasks performed at each step in the software development
process.

Explain the problems that might be faced by an organization if it does not follow any
software life cycle model.
Ans.: - The development team must identify a suitable life cycle model for the particular project
and then adhere to it. Without using of a particular life cycle model the development of a
software product would not be in a systematic and disciplined manner. When a software
product is being developed by a team there must be a clear understanding among team
members about when and what to do. Otherwise it would lead to chaos and project failure.
This problem can be illustrated by using an example. Suppose a software development problem
is divided into several parts and the parts are assigned to the team members. From then on,
suppose the team members are allowed the freedom to develop the parts assigned to them in
whatever way they like. It is possible that one member might start writing the code for his part,
another might decide to prepare the test documents first, and some other engineer might
begin with the design phase of the parts assigned to him. This would be one of the perfect
recipes for project failure.
A software life cycle model defines entry and exit criteria for every phase. A
phase can start only if its phase-entry criteria have been satisfied. So without software life cycle
model the entry and exit criteria for a phase cannot be recognized. Without software life cycle
models (such as classical waterfall model, iterative waterfall model, prototyping model,
evolutionary model, spiral model etc.) it becomes difficult for software project managers to
monitor the progress of the project.

Linear sequential model or Classic life cycle model or Waterfall model

The Waterfall Model was the first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear sequential flow.
This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.

 Requirements and definations: The first phase involves understanding what need to be
design and what is its function, purpose etc. Here, the specifications of the input and
output or the final product are studied and marked.
 System Design and software design: The requirement specifications from first phase
are studied in this phase and system design is prepared. System Design helps in
specifying hardware and system requirements and also helps in defining overall system
architecture. The software code to be written in the next stage is created now.
 Implementation and unit testing: With inputs from system design, the system is first
developed in small programs called units, which are integrated in the next phase. Each
unit is developed and tested for its functionality which is referred to as Unit Testing.
 Integration and system Testing: All the units developed in the implementation phase
are integrated into a system after testing of each unit. The software designed, needs to
go through constant software testing to find out if there are any flaw or errors. Testing
is done so that the client does not face any problem during the installation of the
software.
 Maintenance: It is the longest life cycle phase. This step occurs after installation.
Maintenance includes correcting errors which were not found in earlier stages of the life
cycle, enhancing the implementation of system units and improving the system’s
services as new requirements are found.

Prototyping model

The basic idea in Prototype model is that instead of freezing the requirements before a design
or coding can proceed, a throwaway prototype is built to understand the requirements. This
prototype is developed based on the currently known requirements. By using this prototype,
the client can get an “actual feel” of the system, since the interactions with prototype can
enable the client to better understand the requirements of the desired system.

Prototyping is an attractive idea for complicated and large systems for which there is no manual
process or existing system to help determining the requirements.
The prototyping model is applied when detailed information related to input and output
requirements of the system is not available.
Prototype model should be used when the desired system needs to have a lot of interaction
with the end users.
1. Requirements gathering and analysis: A prototyping model begins with requirements
analysis and the requirements of the system are defined in detail. The user is interviewed in
order to know the requirements of the system.
2. Quick design: When requirements are known, a preliminary design or quick design for the
system is created. It is not a detailed design and includes only the important aspects of the
system, which gives an idea of the system to the user. A quick design helps in developing the
prototype.
3. Build prototype: Information gathered from quick design is modified to form the first
prototype, which represents the working model of the required system.
4.Customer evaluation: Next, the proposed system is presented to the user/customer for
thorough evaluation of the prototype to recognize its strengths and weaknesses such as what is
to be added or removed. Comments and suggestions are collected from the users and provided
to the developer.
5. Refining prototype: Once the user evaluates the prototype and if he is not satisfied, the
current prototype is refined according to the requirements. That is, a new prototype is
developed with the additional information provided by the user. The new prototype is
evaluated just like the previous prototype. This process continues until all the requirements
specified by the user are met. Once the user is satisfied with the developed prototype, a final
system is developed on the basis of the final prototype.
6. Engineer product: Once the requirements are completely met, the user accepts the final
prototype. The final system is evaluated thoroughly followed by the routine maintenance on
regular basis for preventing large-scale failures and minimizing downtime.

Advantages of Prototype model:

 Users are actively involved in the development
 Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily
 The developer gains experience and insight by developing a prototype

Disadvantages of Prototype model:

A new prototype is developed until a perfect prototype is developed. Thus, this model is time
consuming and expensive.
The developer loses focus of the real purpose of prototype and hence, may compromise with
the quality of the software.

RAD model
RAD model is Rapid Application Development model. It is a type of incremental model. In RAD
model the components or functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working prototype. This
can quickly give the customer something to see and use and to provide feedback regarding the
delivery and their requirements.

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects
that are needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and
created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and the
actual system.
Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD model:
 Depends on strong team and individual performances for identifying business
requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.

When to use RAD model:

 RAD should be used when there is a need to create a system that can be modularized in
2-3 months of time.
 It should be used if there’s high availability of designers for modeling and the budget is
high enough to afford their cost along with the cost of automated code generating tools.
  RAD SDLC model should be chosen only if resources with high business knowledge are
available and there is a need to produce the system in a short span of time (2-3
months).

Evolutionary software models are iterative. They are characterized in manner that enables the
software engineers to develop increasingly more complete version of a software. That is,
initially a rapid version of the product is being developed and then the product is developed to
more accurate version with the help of the reviewers who review the product after each
release and submit improvements.

The ESPM has been categorized into 3 types of models.

Incremental Model
Spiral Model
Component Assembly Model

The incremental model (also known as iterative enhancement model) comprises the features
of waterfall model in an iterative manner. In an Iterative Incremental model, initially, a partial
implementation of a total system is constructed so that it will be in a deliverable state.
Increased functionality is added. Defects, if any, from the prior delivery are fixed and the
working product is delivered. The process is repeated until the entire product development is
completed. The repetitions of these processes are called iterations. At the end of every
iteration, a product increment is delivered. Each stage of incremental model adds some
functionality to the product and passes it on to the next stage.

When to use Incremental models?

 Requirements of the system are clearly understood
 When demand for early release of product arises
 When team resources are not very well skilled or trained
 When high-risk features and goals are involved
 Such model is more in use for web application and product based companies

Why programs that are developed using evolutionary development are likely to be difficult to
maintain.
The specifications of evolutionary development projects are often abstract and as the project
continues the development and validation portions of software engineering overlap one
another. This usually results in the systems being poorly constructed due to a good initial
specification. and on large projects make it more difficult to integrate new systems into the
evolutionary design, Lastly, the documentation for such projects is often lacking, as the designs
are constantly rebuilt to the customer's specifications.

The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. Its one of
the software development models like Waterfall, Agile, V-Model.
Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’
that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement
specifications’.
Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate
solutions. A prototype is produced at the end of the risk analysis phase. If any risk is found
during the risk analysis then alternate solutions are suggested and implemented.
Engineering Phase: In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.
Diagram of Spiral model:

Advantages of Spiral model:

 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
 Specifies a mechanism for software quality assurance activities
 Additional Functionality can be added at a later date.
 Estimation of budget and schedule gets realistic as the work progresses.

Disadvantages of Spiral model:

 Assessment of project risks and itsresolution is not an easy task.
 Difficult to estimate budget and schedule in the beginning as some of the analysis is not
done until the design of the software is developed.
When to use Spiral model:
 When costs and risk evaluation is important
 For medium to high-risk projects
  Long-term project commitment unwise because of potential changes to economic
priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)

Spiral model is called meta model because it encompasses all other life cycle models. It
is called so also because of of the way it comprises of other models of SDLC. Both waterfall and
prototype models are used in it. For example: a single loop spiral actually represents the
waterfall model.

Difference Between Waterfall Model and Spiral Model

SPIRAL MODEL WATERFALL MODEL

1] Spiral model is not suitable for small 1] Waterfall model is suitable for small
projects. projects.

2] Better risk management. 2] High amount of risk and uncertainty.

3] Process is complex. 3] Easy to understand.

4] The process may go indefinitely. 4] Stages are clearly defined.

5] This model is suitable for long and 5] This model is not suitable for long
ongoing projects. and ongoing projects.

6] Iterations are followed 6] Sequence is followed

7] Flexible with user requirements 7] Requirements once fixed cannot be

modified

8] Refinements are easily possible 8] Refinements are not so easy

9] Phases are repeated itself 9] Phases are processed and completed

one at a time.
How does project Risk factor affect the spiral model of software development ?
Ans. : Risk Analysis phase is the most significant part of "Spiral Model". In this phase all possible
(and available) alternatives, which can help in developing a cost effective project are examined
and strategies are decided to use them. This phase has been added specially in order to verify
and resolve all the possible risks in the project development. If risks indicate any type of
uncertainty in needs, prototyping may be used to proceed with the available data and search
out possible solution in order to deal with the potential changes in the requirements.
The spiral model demands considerable risk assessment because if a major risk is not
uncovered and managed, problems will occur in the project and then it will not be acceptable
by end user.
If the implementation of risk analysis will greatly affect the profits of the project, the
spiral model should not be used.

COMPONENT ASSEMBLY MODEL:

Component Assembly Model is just like the Prototype model, in which first a prototype is
created according to the requirements of the customer and sent to the user for evaluation to
get the feedback for the modifications to be made and the same procedure is repeated until
the software will cater the need of businesses and consumers is realized. Thus it is also an
iterative development model.
This model work in following manner:
1. Identify all required candidate component i.e. classes with the help of application data and
algorithm.
2. If these candidate components are used in previous software project then they must be
present in library.
3. Such preexisting component can be extracted from the library and used for further
development.
4. But if required component is not presented in the library then build or create the component
as per requirement.
5. Place the newly created component in library. This makes one iteration of the system.
6. Repeat step 1 to 5 for creating 'n' iteration. Where 'n' denotes the no of iterations required
to develop complete application.
Component Assembly Model Characteristics:
Use of object-oriented technology.
Components — classes that encapsulate both data and algorithms.
Components developed to be reusable.
Paradigm similar to spiral model, but engineering activity involves components.
System produced by assembling the correct components.

Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP)
developed by Scott Ambler.[1] It describes a simple, easy to understand approach to developing
business application software using agile techniques and concepts yet still remaining true to the
RUP. The AUP applies agile techniques including test-driven development (TDD), agile
modeling (AM), agile change management, and database refactoring to improve productivity.

AUP is an iterative-incremental process consisting of four sub-processes

1. Model. Understand the business of the organization, the problem domain being
addressed by the project, and identify a viable solution to address the problem domain.
2. Implementation. Transform model(s) into executable code and perform a basic level of
testing, in particular unit testing.
3. Test. Perform an objective evaluation to ensure quality. This includes finding defects,
validating that the system works as designed, and verifying that the requirements are
met.
4. Deployment. Plan for the delivery of the system and to execute the plan to make the
system available to end users.

The Capability Maturity Model (CMM) is a methodology used to develop and refine an
organization's software development process. CMM was developed at the Software
engineering institute in late 80's. Capability Maturity Model is used as a benchmark to measure
the maturity of an organization's software process. CMM can be used to assess an organization
against a scale of five process maturity levels.

Maturity Level 1 – Initial: Organization has no standard process for software development. Nor
does it have a project-tracking system that enables developers to predict costs or finish dates
with any accuracy. At maturity level 1, processes are usually ad hoc and chaotic.
Maturity Level 2 – Managed: Organization has installed basic software management processes
and controls. But there is no consistency or coordination among different groups.
Maturity Level 3 – Defined: Organization has pulled together a standard set of processes and
controls for the entire organization so that developers can move between projects more easily
and customers can begin to get consistency from different groups.
Maturity Level 4 – Quantitatively Managed: In addition to implementing standard processes,
Organization has installed systems to measure the quality of those processes across all projects.
Maturity Level 5 – Optimizing: Organization has accomplished all of the above and can now
begin to see patterns in performance over time, so it can tweak its processes in order to
improve productivity and reduce defects in software development across the entire
organization.

Process metrics are collected across all projects and over long periods of time. They are used
for making strategic decisions.
Process metrics: describe the effectiveness and quality of the processes that produce the
software product.
Process metrics can be used to improve efficiency of an existing process used in software
development and maintenance.
Process metrics are short-term metrics
Examples are:

• effort required in the process

• time to produce the product
• effectiveness of defect removal during development
• number of defects found during testing
• maturity of the process

Product metrics: describe the characteristics of the product such as size, complexity, design
features, performance, efficiency, reliability, portability, etc.

Product Metrics :Focus on the quality of deliverables . Product metrics are combined across
several projects to produce process metrics.

These are metrics that pertain to Product Quality. They are used to measure cost, quality and
the product’s time-to-market.

Product metrics are medium term metrics.

product metrics are those metrics which has more meaning in the perspective of the software
product being developed
 Unit-2
Functional requirements
The functional requirements for a system describes what the system should do(defines a
function of a system or its component). Functional requirements may be calculations, technical
details, data manipulation and processing and other specific functionality that define what a
system is supposed to accomplish. These requirements depend on the type of software being
developed, the expected users of the software and the general approach taken by the
organization when writing requirements. When expressed as user requirements, the
requirements described in a fairly abstract way. However, functional system requirements
describe the system function in detail, its inputs, expectations, behavior and outputs.

Non-functional requirements
Non Functional requirements are mostly quality requirements. That stipulate how well the
software does, what it has to do.
Non-functional requirements are not directly concerned with the specific functions delivered by
the system. It is a requirement that specifies criteria that can be used to judge the operation of
a system, rather than specific behaviors. It defines system properties and constraints like,
reliability, response time and storage requirements. Constraints are I/O device capability,
system representations, etc.
It is concerned with specifying system performance, security, availability, and other emergent
properties. This means they are often more critical than individual functional requirements.
These requirements are not just concerned with the software system to be developed. Some
non-functional requirements may constrain (restrict) the process that should be used to
develop the system.

Requirements Elicitation: the process through which the customers, buyers, or users of a
software system discover, reveal, articulate, and understand their requirements.
Requirements analysis: the process of reasoning about the requirements that have been
elicited; it involves activities such as examining requirements for conflicts or inconsistencies,
combining related requirements, and identifying missing requirements.
Requirements specification: the process of recording the requirements in one or more forms,
including natural language and formal, symbolic, or graphical representations; also, the product
that is the document produced by that process.
Requirements validation: the process of confirming with the customer or user of the software
that the specified requirements are valid, correct, and complete.

Requirement analysis: The process of studying and refining system, hardware or software
requirements.' Requirements analysis helps to understand, interpret, classify, and organize the
software requirements in order to assess the feasibility, completeness, and consistency of the
requirements.
Requirement analysis is a Software engineering task bridging the gap between system
requirements engineering and software design.

Software Requirements Analysis Phases

Problem recognition
Evaluation and synthesis
focus is on what not how
Modeling
Specification
Review
requirements analysis includes three types of activities:[citation needed]
 Eliciting requirements: (e.g. the project charter or definition), business process
documentation, and stakeholder interviews. This is sometimes also called requirements
gathering or requirements discovery.
 Analyzing requirements: determining whether the stated requirements are clear,
complete, consistent and unambiguous, and resolving any apparent conflicts.
 Recording requirements: Requirements may be documented in various forms, usually
including a summary list and may include natural-language documents, use cases, user
stories, process specifications and a variety of models including data models.

After requirement gathering, requirement analysis is done to check on why the product is
needed. Requirement analysis includes:
Necessity checking – requirements that don’t contribute to the business goals of the
organization or specific problem that has to be addressed by the system are checked for
necessity for the development of the system.
Consistency and completeness checking – no contradictions and feasibility checking in terms
of budget and schedule.
Requirement discussion – highlight the requirement and discussion of problematic elements
through introspection and interviews.
Requirement prioritization – requirements are prioritized based on criticality and the highly
complex and critical activities are identified for risk plot and low level activities are considered
for easy implementation.
Requirement agreement – compromised set of requirements based on feasibility checking.

The process to gather the software requirements from client, analyze and document them is
known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes –
 Feasibility Study: This feasibility study is focused towards goal of the organization. This
study analyzes whether the software product can be practically materialized in terms of
implementation, contribution of project to organization, cost constraints and as per values
and objectives of the organization.
 Requirement Gathering: If the feasibility report is positive towards undertaking the
project, next phase starts with gathering requirements from the user. Analysts and
engineers communicate with the client and end-users to know their ideas on what the
software should provide and which features they want the software to include.
 Software Requirement Specification: SRS is a document created by system analyst after the
requirements are collected from various stakeholders.
SRS defines how the intended software will interact with hardware, external interfaces,
speed of operation, response time of system, portability of software across various
platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations
etc.
 Software Requirement Validation: After requirement specifications are developed, the
requirements mentioned in this document are validated. User might ask for illegal,
impractical solution or experts may interpret the requirements incorrectly.

In requirements engineering, Requirements Elicitation is the process to find out the

requirements for an intended software system by communicating with client, end users, system
users and others who have a stake in the software system development. The practice is also
sometimes referred to as "requirement gathering".

Requirement Elicitation Techniques

Interviews
These are conventional ways of eliciting requirements, which help software engineers, users,
and the software development team to understand the problem and suggest solutions for it.
In Interviews, requirements engineering teams put the questions to the stakeholder about the
system that’s currently used, and the system to be developed, and hence they can gather the
requirements from the answers.

Scenarios: These are descriptions of a sequence of events, which help to determine possible
future outcomes before software is developed or implemented. Scenarios are used
to test whether the software will accomplish user requirements. It also helps to provide a
framework for questions to software engineers about users' tasks. These questions are asked
from users about future conditions (what-if) and procedures (how) in which they think tasks
can be completed. Generally, a scenario includes the following information.
1. Description of what users expect when the scenario starts
2. Description of how to handle the situation when the software is not functioning
properly
 3. Description of the state of the software when the scenario ends.

Questionnaires
A document with pre-defined set of objective questions and respective options is handed over
to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.

Prototyping
Prototyping is building user interface without adding detail functionality for user to interpret
the features of intended software product. Prototypes help to clarify unclear requirements.

Quality function deployment (QFD): This deployment translates user requirements into
technical requirements for the software. For this, QFD facilitates the development team to
understand what is valuable to users so that quality can be maintained throughout software
development. QFD identifies the following user requirements.

1. General requirements: These requirements describe the system objectives, which are
determined by various requirements elicitation techniques. Examples of general
requirements are graphical displays requested by users, specific software functions, and
so on.
2. Expected requirements: These requirements are implicit to software as users consider
them to be fundamental requirements, which will be accomplished in the software and
hence do not express them. Examples of expected requirements are ease of software
installation, ease of software and user interaction, and so on.
3. Unexpected requirements: These requirements specify the requirements that are
beyond user expectations. These requirements are not requested by the user but if
added to the software, they become an additional feature of the software. An example
of unexpected requirements is to have word processing software with additional
capabilities such as page layout capabilities along with the earlier features.

Analysis model operates as a link between the 'system description' and the 'design model'.
In the analysis model, information, functions and the behaviour of the system is defined and
these are translated into the architecture, interface and component level design in the 'design
modeling'.

Elements of the analysis model

Data Dictionary :Repository that contains descriptions of all data objects consumed or
produced by the software.
Entity Relation Diagram (ERD) :Depicts relationships between data objects.
Data Flow Diagram (DFD) : Presents how data is transformed as it moves through a system.
State Transition Diagram (STD) :Presents how the system behaves as a consequence of
external events.
Data Object Description: Presents the attributes of each object in the ERD.
Process Specification: Presents a description of each function in the DFD.
Control Specification: Contains information about the control aspects of the software

Function Modeling & Information Flow

• Information is transformed as it flows through a computer based system. The system accepts
input in a variety of forms; applies hardware, software, and human elements to transform it;
and produces output in a variety of forms
• Structured analysis began as an information flow modeling technique.
• A rectangle is used to represent an external entity (software, hardware, a person)
• A circle (sometimes called a bubble) represents a process or transform that is applied to data
(or control) and changes it in some way.
An arrow represents one or more data items (data objects) and it should be labeled.
• All arrows on a data flow diagram should be labeled.
• The double line represents a data store—stored information that is used by the software.

Difference Functional-oriented Approach v/s Object-oriented Design

1.FOD: The basic abstractions, which are given to the user, are real world functions.
OOD: The basic abstractions are not the real world functions but are the data abstraction where
the real world entities are represented.

2.FOD: Functions are grouped together by which a higher level function is Page on
obtained.an eg of this technique isSA/SD.
OOD: Functions are grouped together on the basis of the data they operate since the classes
are associated with their methods.

3.FOD: In this appproach the state information is often represented in a centralized shared
memory.
OOD: In this approach the state information is not represented in a centralized memory but is
implemented or distributed among the objects of the system.

4.FOD approach is mainly used for computation sensitive application,

OOD: whereas OOD approach is mainly used for evolving system which mimicks a business
process or business case.

5. In FOD - we decompose in function/procedure level

OOD: - we decompose in class level

6. FOD: TOp down Approach

OOD: Bottom up approach
7. FOD: It views system as Black Box that performs high level function and later decompose it
detailed function so to be maaped to modules.
OOD: Object-oriented design is the discipline of defining the objects and their interactions to
solve a problem that was identified and documented during object-oriented analysis.

8. FOD: Begins by considering the use case diagrms and Scenarios.

OOD: Begins by identifiying objects and classes

Software requirement specification (SRS) is a document that completely describes what the
proposed software should do without describing how software will do it. The basic goal of the
requirement phase is to produce the SRS, Which describes the complete behavior of the
proposed software. SRS is also helping the clients to understand their own needs.
Advantages
Software SRS establishes the basic for agreement between the client and the supplier on what
the software product will do.
• A SRS provides a reference for validation of the final product.
• A high-quality SRS is a prerequisite to high-quality software.
• A high-quality SRS reduces the development cost.

Characteristics of good srs

1). Correct

An SRS is correct if every requirement if every requirement included in the SRS represents
something required in the final system.

2). Complete

An SRS is complete if every this software is supposed to do the responses of the software to all
classes of input data are specified data into SRS. Correctness ensure that what is specified is
done correctly, completeness ensures that everything is indeed specified.

3). Unambiguous (unmistakable)

An SRS is unambiguous if and only is every requirements stated or return has one and only one
interpretation.

4).
Verifiable. All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to determine whether or not requirements
have been met in an implementation.

5). Consistent
An SRS is consistent if there is no requirement that conflict with another terminology can cause
in consistency. Ex Different requirements may use different terms to refer to the same object.
There may be logical conflict may be requirement causing inconsistency. Ex A requirements
stays that an event F but than other set of requirement stays that and event F should occur
before event E. In consistency in SRS can be a reflection of major problem.

6). Ranked of importance / Stability

An SRS is ranked for an importance a stable if for each requirement the importance and stability
of a requirements reflect a terms of expected change stability of a requirement reflects in
futures. Writing and SRS is an interactive process, when the requirement systems are specified.

7). Modifiable

They are later modified as the needs of the clients change. SRS should be easy to modify. SRS is
modifiable if its structures and style are such that any necessary change can be made easily
while continuing completeness and consistency.

8). Traceable

An SRS is traceable if the origin of each of its requirement is clear and if it fulfill the reference in
of each requirement in feature development should be traceable to some design and code
element and back word traceability requirement. If be possible to trace design and code
element to the requirement. They support traceability aids verification and validation from all
this characteristics completeness is the most important requirement. One of the most common
problem is requirement specification is when some of the requirement of the client are to
specify.

9. Valid
To validate a requirements specification all the project participants, managers, engineers and
customer representatives, must be able to understand, analyze and accept or approve it. This is
the primary reason that most specifications are expressed in natural language.

10. Testable
A requirement specification must be stated in such as manner that one can test it against
pass/fail or quantitative assessment criteria, all derived from the specification itself and/or
referenced information. Requiring that a system must be “easy” to use is subjective and
therefore is not testable.

Black-box view. It should only specify what the system should do and refrain from stating how
to do these. This means that the SRS document should specify the external behavior of the
system and not discuss the implementation issues. The SRS document should view the system
to be developed as black box, and should specify the externally visible behavior of the system.
For this reason, the SRS document is also called the black-box specification of a system.

An SRS should address, among other things:

1. Functionality of the software: What the software will do
2. External interfaces: How the given software will interact with hardware, other
software(s) and assumptions on these entities
3. Required performance levels: Required performance levels such as response rate,
recovery rate etc. of the software
4. Quality attributes: The non-functional factors that are used to evaluate the
performance of the software, such as security, safety, portability etc
5. Design constraints: Any operating system limitations (e.g.: the stock exchange software
will only run on Windows), implementation language etc that will affect or limit the
design of the software.

Software requirements specification(SRS) is important for developers because it minimizes the

amount of time and effort developers have to expend to achieve desired software goals. It
thus reduces development cost. This also benefits the client company because the lesser the
development cost, the lesser the developers will charge from the client. And, if composed
properly, an SRS ensures that there is less possibility of future redesigns as there is less chance
of mistake on the part of developers as they have a clear idea on the functionalities and
externalities of the software. It also helps clear any communication problems between
the client and the developer. Furthermore, an SRS serves to form a foundation of mutual
agreement between the client and the developer (supplier). It also serves as the document
to verify the testing processes.

The development of software begins once the requirements document is 'ready'. One of the
objectives of this document is to check whether the delivered software system is acceptable.
For this, it is necessary to ensure that the requirements specification contains no errors and
that it specifies the user's requirements correctly. Also, errors present in the SRS will adversely
affect the cost if they are detected later in the development process or when the software is
delivered to the user. Hence, it is desirable to detect errors in the requirements before the
design and development of the software begins. To check all the issues related to
requirements, requirements validation is performed.
In the validation phase, the work products produced as a consequence of requirements
engineering are examined for consistency, omissions, and ambiguity. The basic objective is to
ensure that the SRS reflects the actual requirements accurately and clearly. Other objectives of
the requirements document are listed below.
1. To certify that the SRS contains an acceptable description of the system to be
implemented
2. To ensure that the actual requirements of the system are reflected in the SRS
3. To check the requirements document for completeness, accuracy, consistency,
requirement conflict', conformance to standards and technical errors.