se Module 1

7/31/2019 se Module 1

1/34

RT 602 Software Engineering

1

Lecture 1

1) Synopsis

Introduction to Software engineeringIntroduction Software and software Engg. - Phases in software development

2) Target: At the completion of this lecture you should be able to answer questions like

(a)What is meant by software?

(b) What is software engineering?

(c) List the phases of software development.

3) Introduction

Before introducing this subject let us begin with the basics what is software? Software is not merely

a collection of computer programs. There is a distinction between a program and a programming systems

product. In this course, I will be introducing you to what is software engineering and what are the phases of

software development. You can define software to be a collection of computer programs, procedures, rules,

and associated documentation and data. The software development process is divided into phases. Each

phase has got a defined output. The major phases of a software cycle are analysis, design, coding and

testing. Due time through the course I will be discussing on these phases in detail. In this lecture I will

discuss on what is software and on the basics of software engineering. In particular we will discuss on the

following:

(i) Software

(ii) Software Engineering

(iii) Phases in software development

4) Revision/Prerequisites

Read through the basics of what is meant by software and the evolution of software engineering.

You can refer the following books:

i) Software Engineering - Roger S. Pressman, Tata McGraw Hill

ii) Software Engineering - Ian Sommervilla, Pearson Education.

Module-1 Prepared by Simi Joseph, Lecturer in

DCE

7/31/2019 se Module 1

2/34


2

There is immense information available in Internet, which may help you explore the depth of this

subject.

An Integrated Approach to Software Engineering , Pankaj Jalote is your prescribed textbook.

You can refer these books for all the coming lectures. Please refer to pages 1 to 21 of your textbook

for the portions I will be covering in this lecture.

5) Concepts:

Introduction

I think the foremost knowledge you must have in order to study the subject is to know what is

meant by software? As told earlier, you can define software as the collection of computer programs,

procedures, rules, and associated documentation and data. This implies that the discipline dealing with the

development of software should not only deal with developing programs, but with developing all the things

that constitute the software.

Software Engineering is the systematic approach to the development, operation, maintenance and

retirement of software.

Software Engineering is the application of science and mathematics by which the capabilities of computer

equipment are made useful to man via computer programs, procedures, and associated documentation.

Software Engineering Approach:The basic software engineering approach is to: Develop methods and procedures for software

development that can scale up for large systems and that can be used to consistently produce high-quality

software at low cost and with a small cycle time. The key objectives are consistency, low cost, high

quality, small cycle time, and scalability. The basic approach that software engineering takes is to separate

the development process from the development process from the developed product. Design of proper

software processes and their control then becomes the primary goal of software engineering.

Phased Development Process:

A development process consists of various phases, each phase ending with a defined output. The

phases are performed in an order specified by the process model being followed. The main reason for

having a phased process is that it breaks the problem of developing software into successfully performing a


DCE

7/31/2019 se Module 1

3/34


3

set of phases, each handling a different concern of software development. This ensures that the cost of

development is lower than what it would have been if the whole problem were tackled together. It also

helps in proper checking for quality and progress at some defined points during the development.

Requirement Analysis: Requirement analysis is done in order to understand the problem the software

system is to solve. Why we need requirement analysis? It helps us in identifying what is needed from the

system, not how the system will achieve its goals. The developer has to satisfy the clients needs. The

requirement phase ends with a document describing all the requirements. The goal of this phase is to

develop a SRS. The two major activities in this phase: problem understanding or analysis and requirement

specification.

Software design: The purpose of the design phase is to plan a solution of the problem specified by the

requirements document. It specifies how to satisfy the needs. The output of this phase is the design

document. The design activity is divided into two separate phases system design and detailed design.

System design, also called as top level design, aims to identify the modules that should be in the system,

the specifications of these modules, and how they interact with each other to produce the desired results

.During detailed design, the internal logic of each of the modules specified in system design is decided

.During this phase further details of the data structures and algorithmic design of each of the modules is

specified.

Coding: The goal of the coding phase is to translate the design of the system into code in a given

programming language. The aim of this phase is to implement the design in the best possible manner. Thecoding phase affects both testing and maintenance profoundly. Well-written code can reduce the testing

and maintenance effort. Hence, during coding the focus should be on developing programs that are easy to

read and understand, and not simply on developing programs that are easy to write. Simplicity and clarity

should be strived for during the coding phase. An important concept that helps the understandability of

programs is structured programming.

Testing: Testing is the major quality control measure used during software development. Its basic function

is to detect errors in the software. Testing not only has to uncover errors introduced during coding, but also

errors introduced during the previous phases. Different levels of testing are used:

-The starting point of testing is unit testing. In this, a module is tested separately and is often performed by

the coder himself simultaneously along with the coding of the module. The purpose is to exercise the

different parts of the module code to detect coding errors.


DCE

7/31/2019 se Module 1

4/34


4

-After this, the modules are gradually integrated into subsystems, which are then integrated to eventually

form the entire system. During integration of modules, integration testing is performed to detect design

errors by focusing on testing the interconnection between modules.

-After the system is put together, system testing is performed. Here the system is tested against the system

requirements to see if all the requirements are met and if the system performs as specified by the

requirements.

- Finally acceptance testing is performed to demonstrate to the client, on the real life data of the client,

the operation of the system.

The testing process starts with a test plan that identifies all the testing related activities that must be

performed and specifies the schedule, allocates the resources, and specifies guidelines for testing. The test

plan specifies conditions that should be tested, different units to be tested, and the manner in which

modules will be integrated. Then for different test units, a test case specification document is produced

which lists all the different test cases, together with expected outputs. The final output of this phase is error

report and test report.

University Questions:

a. BTech Degree Examination, May 2005, Prior to 2002

1.Explain the phases in software development. (12 marks)

2. Give a brief account of evolution of software engineering. (12 marks)

6) Summary: I think from the above you might have got an idea about the basic concepts of the subject.

Thesebasic details are going to be useful in the subjects you are going to learn in the higher semesters. The

details you will be coming across in the next lectures will help you in future while working in a software

industry. In my next lecture I will be discussing on various software process models. You can observe that

the phases you have learnt in these models.

7) Exercise Questions

i) What is software engineering?

a. Set of computer programs, procedures and possibly associated document concerned with

the operation of data processing


DCE

7/31/2019 se Module 1

5/34


5

b. Software engineering implement a single independent function

c. Software engineering is the establishment and use of sound engineering practice in order to

produce economical and reliable software that will perform efficiently on real machine

d. Software engineering is a step that encompasses the method, tools, procedure used in

software

ii) System design aims to:

a. Identify the modules that should be in the system

b. The specification of modules

c. Identify how modules interact with each other to produce desired output

d. All of these

iii) The program specifications are translated into a machine-readable form by the process of coding.

a. Detailed design

b. System design

c. Testing

d. Coding

iv) Which is the last step in classic life cycle paradigm?

a. System engineering

b. Analysis

c. Codingd. Maintenance

v) Which of the following form the first phase in any development process

Design

b. Coding

c. Testing

d. None of these


DCE

7/31/2019 se Module 1

6/34


6

Lecture 2

1) Synopsis

Software development process models


(a) What are the different software process models?

3) Introduction

Now that you are familiar with the phases of software cycle. Let me discuss the various software

process models. There are different kinds of software process models each with its set of advantages and

disadvantages. Choosing a process model depends on your work environment. Initially I will be discussing

on the waterfall model, which is a linear model. Then you have got prototyping. Finally spiral model. As

you read through the rest of the lectures, you will start getting an idea on when and how you select a

process model, and the necessity of each and every model. In particular we will discuss on the following:

Software Process Models

-Waterfall Model

- Prototyping

-Iterative Enhancement

-Spiral Model


DCE

7/31/2019 se Module 1

7/34


7


Please refer to pages 23 to 46 of your textbook.

5) Concepts:

A 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.

Software Processes

Software development concerns with many processes simultaneously executing. Business process models,

social process models, and training models are all examples of processes that come under this.

The process that deals with the technical and management issues of software development is called a

software process.

Software Development Process

In the software development process the activities we focus on are design, coding and testing. A

development process model specifies some activities that, according to the model, should be performed,

and the order in which they should be performed. Now let us discuss some common process models that

have been proposed.i) Waterfall Model: This is the simplest process model, which states that the phases are organized in a

linear order. The project begins with feasibility analysis. On successfully demonstrating the feasibility of a

project, the requirement analysis and project planning begins. The design starts after the requirements

analysis is complete, and coding begins after the design is complete. Then the code is integrated and testing

is done.

With the waterfall model, the sequence of activities performed in a software development project

is: requirement analysis, project planning, system design, detailed design, coding and unit testing, system

integration and testing. Linear ordering of activities helps to clearly identify the end of a phase and the

beginning of the next; some certification mechanism has to be employed at the end of each phase. The

consequence of the need for certification is that each phase must have some defined output that can be


DCE

7/31/2019 se Module 1

8/34


8

evaluate and certified. The goal of a phase is to produce this product. The outputs of the earlier phases are

called its work products, which are usually in the form of documents.

There are two basic assumptions for justifying the linear ordering of phases in the manner proposed by the

model:

a. For a successful project resulting in a successful product, all phases listed in the waterfall model must be

performed anyway.

b. Any different ordering of the phases will result in a less successful software product.

Project Outputs in Waterfall model :

There are a number of intermediate outputs that must be produced to produce a successful product.

The following set of documents should be produced in each project:

Requirements document

Project Plan

System design document

Detailed design document

Test plan and test reports

Final code

Software manuals

Review reports

Limitations of the Waterfall Model:

a. The waterfall model assumes that the requirements of a system can be frozen before the design

begins. For new systems, determining the requirements is difficult, as the user does not even know

the requirements.

b. Freezing the requirements usually requires choosing the hardware .A large project may require

years to get completed. If the hardware is selected early, it is likely that the final software will use a

hardware technology on the verge of becoming obsolete.

c. The waterfall model stipulates that the requirements be completely specified before the rest of the

development can proceed. In some situations it might be desirable to first develop a part of the

system completely and then later enhance the system in phases.


DCE

7/31/2019 se Module 1

9/34


9

d. It is a document driven process that requires formal documents at the end of each phase. This

approach tends to make the process documentation heavy and is not suitable for many

applications, particularly interactive applications.

ii) Prototyping:

One of the main problems with the waterfall model is that the requirements often are not

completely understood in the early development stages. When you reach the design or coding stages, you


DCE

7/31/2019 se Module 1

10/34


10

begin to see how everything works together, and you can discover that you need to adjust the requirements.

Prototyping is an effective tool for demonstrating how a design meets a set of requirements. You

can build a prototype, adjust the requirements, and revise the prototype several times until you have a clear

picture of the overall objectives. In addition to clarifying the requirements, a prototype also defines many

areas of the design simultaneously.

The pure waterfall model allows for prototyping in the later architectural design stage and

subsequent stages but not in the early requirements stages.

However, prototyping has its drawbacks. Because it appears that you have a working system,

customers may expect a complete system sooner than is possible. In most cases, prototypes are built on

compromises that allow it to come together quickly but prevent the prototype from being an effective basis

for future development. You need to decide early if you want to use the prototype as a basis for future

development. All parties need to agree with this decision before development begins.

Be careful that prototyping does not become a disguise for a code and fix development cycle.

Before you begin prototyping, gather clear requirements and create a design plan. Limit the amount of time

you spend prototyping before you begin. Time limits help to avoid overdoing the prototyping phase. As

you incorporate changes, update the requirements and the current design. After you finish prototyping,

consider returning to one of the other development models. For example, consider prototyping as part of

the requirements or design phases of the waterfall model.

iii) Iterative Enhancement


DCE

Requirement

analysis

Design

Code

Test

Code TestDesign

7/31/2019 se Module 1

11/34


11

The iterative enhancement model counters the third limitation of the waterfall model and tries to

combine the benefits of both prototyping and the waterfall model. The basic idea is that the software

should be developed in increments, each increment adding some functional capability to the system is

implemented. At each step, extension and modifications can be made. An advantage of this approach is

that it can result in better testing because testing each increment is likely to be easier than testing the entire

system as in the waterfall model.

In this step of this model, a simple initial implementation is done for a subset of the overall

problem. This subset is one that contains some key aspects of the problem. A project list that contains all

the tasks that must be performed to obtain the final implementation .Each step consists of removing the

next task from the list, designing the implementation for the selected task, coding and testing the

implementation, performing an analysis of the partial system obtained after this step, and updating the list

as a result of the analysis. These three phases are called the design phase, implementation phase, and

analysis phase. The process is iterated until the project control list is empty, at which time the final

implementation is available.


DCE

Design 0Design 1

Design n

Analysis 1

Implement 1

Analysis n

Implement n

Implement 0

Analysis 0

7/31/2019 se Module 1

12/34


12

iv) Spiral Model

The spiral model is a popular alternative to the waterfall model. It emphasizes risk management so

you find major problems earlier in the development cycle. In the waterfall model, you have to complete the

design before you begin coding. With the spiral model, you break up the project into a set of risks that needto be dealt with. You then begin a series of iterations in which you analyze the most important risk,

evaluate options for resolving the risk, deal with the risk, assess the results, and plan for the next iteration.

The following figure illustrates the spiral lifecycle model.

Risks are any issues that are not clearly defined or have the potential to affect the project adversely. For

each risk, consider the following two things:

The likelihood of the risk occurring (probability) .

The severity of the effect of the risk on the project (loss) .

You can use a scale of 1 to 10 for each of these items, with 1 representing the lowest probability or loss

and 10 representing the highest. Risk exposure is the product of these two rankings.

Use something such as the following table to keep track of the top risk items of the project.

ID Risk Probability LossRisk

ExposureRisk Management Approach

1 Acquisition rates too high 5 9 45 Develop prototype to demonstrate feasibility

2 File format might not be 5 3 15 Develop benchmarks to show speed of data


DCE

7/31/2019 se Module 1

13/34


13

efficient manipulation

3 Uncertain user interface 2 5 10 Involve customer; develop prototype

In general, deal with the risks with the highest risk exposure first. In this example, the first spiral

deals with the potential of the data acquisition rates being too high. If after the first spiral, you demonstrate

that the rates are high, you can change to a different hardware configuration to meet the acquisition

requirements. Each iteration can identify new risks. In this example, using more powerful hardware can

introduce higher costs as a new risk.

For example, assume you are designing a data acquisition system with a plug-in data acquisition

card. In this case, the risk is whether the system can acquire, analyze, and display data quickly enough.

Some of the constraints in this case are system cost and requirements for a specific sampling rate and

precision.

After determining the options and constraints, you evaluate the risks. In this example, create a

prototype or benchmark to test acquisition rates. After you see the results, you can evaluate whether to

continue with the approach or choose a different option. You do this by reassessing the risks based on the

new knowledge you gained from building the prototype.

In the final phase, you evaluate the results with the customer. Based on customer input, you can

reassess the situation, decide on the next highest risk, and start the cycle over. This process continues until

the software is finished or you decide the risks are too great and terminate development. It is possible that

none of the options are viable because the options are too expensive, time-consuming, or do not meet the

requirements.

The advantage of the spiral model over the waterfall model is that you can evaluate which risks to

handle with each cycle. Because you can evaluate risks with prototypes much earlier than in the waterfall

process, you can deal with major obstacles and select alternatives in the earlier stages, which is less

expensive. With a standard waterfall model, assumptions about the risky components can spread

throughout the design, and when you discover the problems, the rework involved can be very expensive.

University Questions

a. BTech Degree Examination, May 2005, New Scheme-2002 Admission onwards


DCE

7/31/2019 se Module 1

14/34


14

1. What are the project outputs in a waterfall model of a software development?(4marks)

b. BTech Degree Examination, Nov 2005, Prior to 2002

1. Briefly explain process models for Software development. (12 marks)

c. BTech Degree Examination, Nov 2005, New Scheme-2002 Admission onwards

1. What are the limitations of waterfall model of software development? (4marks)

1. Explain the various software development process models. (12 marks)

d. B Tech Degree examination, October /November 2004

1. Explain Evolutionary prototyping technique with block diagram. Bring out advantages and

problems with evolutionary prototyping.(12 marks)

6) Summary: You might have got an idea about various life cycle models. The one fact you can observe

concerning these models is that all of them have got similar phases. Only slight variations are observed.

Each model has got its advantages and disadvantages. Choosing each model depends on your project. You

will learn to choose among these models in due course of time. In my next lecture, I will be discussing on

project management and software metrics.


i) A lifecycle model, also called as process model, is

a. An abstract description of the software development and modification process.b. A description of various levels to design and code the system.

c. A detailed description of the design and implementation of a process

d. None of these

ii) The output of the earlier phases of a development process, which are not the final output, are frequently

called __________

a. Work products

b. Partial products

c. Partial outputs

d. Intermediate outputs

iii)_________ Process model states that the phases are organized in a linear order.


DCE

7/31/2019 se Module 1

15/34


15

a. Spiral model

b. Waterfall model

Incremental model

Prototyping model

iv) Prototyping based development process will counter the following limitations of waterfall model:

i. The waterfall model assumes that the requirements of a system can be frozen before the

design begins

ii. The waterfall model stipulates that the requirements be completely specified before rest of

the development can proceed

iii. The waterfall model freezes the hardware and environment specification.

iv. The waterfall model is a document driven model that require formal documents at the end

of every phase

Which of the above statements are true?

a. (i) and (ii)

b. (ii), (iii) and (iv)

c. (i) and (iii)

d. All the above

v) The ________ guides the iteration steps and keeps track of all tasks that must be done.

a. Process work planb. Product control list

c. System process list

d. None of these

vi) The ________ emphasizes on the need to go back and re look at earlier stages, i.e. requirements and

design, as number of times as required till the projects stake holders are completely satisfied with all the

aspects of the system.

a. Spiral model

b.Waterfall model

c. Incremental model

d. Prototyping model

vii) Which among the following model is not suitable for customized software development?


DCE

7/31/2019 se Module 1

16/34


16

Prototyping

Iterative Enhancement

Spiral

Waterfall

viii) Second phase of the spiral model is reserved for

a. Finding objective

b. Coding

c. Risk analysis

d. None of these

Lecture 3

1) Synopsis

Role of Management in software development Role of Metrics and measurement


(a) What is the role of management in software development?

3) Introduction

In the previous session, I have discussed about the basic of software engineering and the life cycle

models. Here in this session I will discuss about project management and metrics and measurement. As in

every field, management is important in this field also. Project managers are designated for the purpose He

supervises the various tasks in the development process. It takes place all throughout the project. In

particular we will discuss on the following:

(i) Role of Management in software development(ii) Role of Metrics and measurement



DCE

7/31/2019 se Module 1

17/34


17


5) Concepts:

Project management Process

A large software development project involves many people working for a long period of time. To

meet the cost, quality, and schedule objectives, resources have to be properly allocated to each activity for

the project, and progress of different activities has to be monitored and corrective actions taken, if needed.

All these activities are part of the project management process.

Phases of management Process

The activities in the management process for a project can be grouped broadly into three phases:

planning, monitoring and control, and termination analysis.

Project management begins with planning. Here we prepare a plan for the software development. A

software plan is usually produced before the development activity begins and is updated as development

proceeds and data about progress becomes available. During planning the major activities are cost

estimation, schedule and milestone determination, project staffing, quality control plans, and controlling

and monitoring plans. In cost and schedule estimation, the total cost and time needed for successfully

completing the project are estimated. The project plan plans for all the software quality assurance activities.

Project monitoring and control phase of the management process is the longest in terms of duration;

it encompasses most of the development process. It includes all the activities the project management hasto perform while the development is going on to ensure that project objectives are met and the

development proceeds according to the developed plan.

Monitoring a development process requires proper information about the project. Such information

is typically obtained by the management process from the development process.

Whereas monitoring and control lasts the entire duration of the project, the last phase termination

analysis is performed when the development process is over. The basic reason for performing this phase

is to provide information about the development process. Using the predictability property of the process,

this data about the process can be used to make predictions and estimations about future projects.

Metrics, Measurement and Models

For effective project monitoring, the information coming from the development process to the

management process should be objective and quantitative data about the project. If the information


DCE

7/31/2019 se Module 1

18/34


18

obtained is not quantitative, then subjective judgment will have to be used, which an engineering discipline

needs to minimize. The need for quantitative data from the process requires that software metrics be used.

Software metrics are quantifiable measures that could be used to measure different characteristics of a

software system or the software development process.

A number of metrics have been proposed to quantify things like the size , complexity and reliability

of a software product.

Another term related to metrics is measurement. Metrics provide the scale for quantifying qualities;

actual measurement must be performed on a given software system in order to use metrics for quantifying

characteristics of the given software. Values for some metrics can be directly measured; others might have

to be deduced by other measurement. If a metric is not measured directly, we can call it indirect.

For estimating, models are needed. A model is a relationship of the predicted variable that other

variables can be measured. The model may be determined based on empirical data or it may be analytic.

Building a model is an issue that concerns management.

Metrics provide quantification of some property, measurements provide the actual value for the

metrics, and models are needed to get the value for indirect metrics. All metrics must have a purpose.

Some metrics is of academic interest only.

For example, total frequency of different characters in the code. Many metrics are used for measuring the

complexity of code or design.


a. BTech Degree Examination, May 2005, New Scheme 2002 Admission onwards)

1. Explain quality metrics. (4 marks)

2. Explain the role of metrics and measurement in software development. (12 marks)

b. BTech Degree Examination, Nov 2005, Prior to 2002

1. Briefly explain the role of management in software development. (12 marks) .

c. BTech Degree Examination, Nov 2005, New Scheme-2002 Admission onwards

1. Explain the role of management in software development (5marks)

d. BTech Degree Examination, Oct/Nov 2004

1. Clearly bring out the role of management in software development. (12marks)


DCE

7/31/2019 se Module 1

19/34


19

6) Summary: Here in this lecture, I have discussed to you on project management and the role of metrics

adopted. A good manager is responsible for the proper development of the project. In the next lecture, I

will discuss on SRS, which plays an important role in software specification.


i) Which are the phases of project management?

a. Planning

b. Monitoring and control

c. Termination analysis

d. All of the above

ii) are quantifiable measures that could be used to measure different characteristics of a

software system or the software development process.

a. Software metrics

b. Software measurement

c. Planning

d. Estimation

iii) Metrics have been proposed to quantify things like

a. Sizeb. Complexity

c. Reliability

d. All of the above


DCE

7/31/2019 se Module 1

20/34


20

Lecture 4

1) Synopsis

Software requirement specification (SRS)


(a) What is a SRS?

(b) What should a SRS include?

(c) What are the characteristics of a good SRS?

3) Introduction

In the previous session, I have discussed about project management. In this lecture I am going to

discuss about SRS.SRS refers to Software Requirement Specification. I think it is a very important

activity in software development. Only if you are able to specify the requirements beforehand, you will be

able to manage the project with minimum risk. Basically a SRS will consist of an introduction, functional

requirements, system requirements, interface requirements, etc. You will also learn to identify a good SRS.


DCE

7/31/2019 se Module 1

21/34


21

At the end of this lecture you should be able to write a SRS for a simple system.In particular we will

discuss on the following:

(i) Software Requirement Specification

- Information SRS Includes

- Template of a SRS

- Characteristics of a good SRS



5) Concepts:

Software Requirement Specification

An SRS is basically an organization's understanding (in writing) of a customer or potential client's

system requirements and dependencies at a particular point in time (usually) prior to any actual design or

development work. It's a two-way insurance policy that assures that both the client and the organization

understand the other's requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a

software system (i.e., a software application, an eCommerce Web site, and so on) must provide, as well as

states any required constraints by which the system must abide. The SRS also functions as a blueprint for

completing a project with as little cost growth as possible. The SRS is often referred to as the "parent"

document because all subsequent project management documents, such as design specifications, statements

of work, software architecture specifications, testing and validation plans, and documentation plans, are

related to it.

It is important to note that an SRS contains functional and nonfunctional requirements only; it

doesn't offer design suggestions, possible solutions to technology or business issues, or any other

information other than what the development team understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:


DCE

7/31/2019 se Module 1

22/34


22

It provides feedback to the customer. An SRS is the customer's assurance that the development

organization understands the issues or problems to be solved and the software behavior necessary

to address those problems. Therefore, the SRS should be written in natural language (versus a

formal language, explained later in this article), in an unambiguous manner that may also include

charts, tables, data flow diagrams, decision tables, and so on.

It decomposes the problem into component parts. The simple act of writing down software

requirements in a well-designed format organizes information, places borders around the problem,

solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

It serves as an input to the design specification. As mentioned previously, the SRS serves as the

parent document to subsequent documents, such as the software design specification and statement

of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so

that a design solution can be devised.

It serves as a product validation check. The SRS also serves as the parent document for testing and

validation strategies that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development," which is the initial

product development phase in which information is gathered about what requirements are needed--and not.

This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps

a return-on-investment (ROI) analysis or needs analysis of the customer or client's current business

environment. The actual specification, then, is written after the requirements have been gathered and

analyzed.

Why Technical Writers should be Involved with Software Requirements Specifications?

Unfortunately, much of the time, systems architects and programmers write SRSs with little (if any) help

from the technical communications organization. And when that assistance is provided, it's often limited to

an edit of the final draft just prior to going out the door. Having technical writers involved throughout the

entire SRS development process can offer several benefits:


DCE

7/31/2019 se Module 1

23/34


23

Technical writers are skilled information gatherers, ideal for eliciting and articulating customer

requirements. The presence of a technical writer on the requirements-gathering team helps balance

the type and amount of information extracted from customers, which can help improve the SRS.

Technical writers can better assess and plan documentation projects and better meet customer

document needs. Working on SRSs provides technical writers with an opportunity for learning

about customer needs firsthand--early in the product development process.

Technical writers know how to determine the questions that are of concern to the user or customer

regarding ease of use and usability. Technical writers can then take that knowledge and apply it not

only to the specification and documentation development, but also to user interface development, to

help ensure the UI (User Interface) models the customer requirements.

Technical writers involved early and often in the process, can become an information resource

throughout the process, rather than an information gatherer at the end of the process.

In short, a requirements-gathering team consisting solely of programmers, product marketers, systems

analysts/architects, and a project manager runs the risk of creating a specification that may be too heavily

loaded with technology-focused or marketing-focused issues. The presence of a technical writer on the

team helps place at the core of the project those user or customer requirements that provide more of an

overall balance to the design of the SRS, product, and documentation.

What Kind of Information Should an SRS Include?

You probably will be a member of the SRS team (if not, ask to be), which means SRS development will be

a collaborative effort for a particular project. In these cases, your company will have developed SRSs

before, so you should have examples (and, likely, the company's SRS template) to use. But, let's assume

you'll be starting from scratch. Several standards organizations (including the IEEE) have identified nine

topics that must be addressed when designing and writing an SRS:

1. Interfaces

2. Functional Capabilities

3. Performance Levels

4. Data Structures/Elements


DCE

7/31/2019 se Module 1

24/34


24

5. Safety

6. Reliability

7. Security/Privacy

8. Quality

9. Constraints and Limitations

But, how do these general topics translate into an SRS document? What, specifically, does an SRS

document include? How is it structured? And how do you get started? An SRS document typically includes

four ingredients, as discussed in the following sections:

1. A template

2. A method for identifying requirements and linking sources

3. Business operation rules

4. A traceability matrix

Begin with an SRS Template

The first and biggest step to writing an SRS is to select an existing template that you can fine tune for your

organizational needs (if you don't have one already). There's not a "standard specification template" for all

projects in all industries because the individual requirements that populate an SRS are unique not only

from company to company, but also from project to project within any one company. The key is to select

an existing template or specification to begin with, and then adapt it to meet your needs.

In recommending using existing templates, I'm not advocating simply copying a template from available

resources and using them as your own; instead, I'm suggesting that you use available templates as guides

for developing your own. It would be almost impossible to find a specification or specification template

that meets your particular project requirements exactly. But using other templates as guides is how it's

recommended in the literature on specification development. Look at what someone else has done, andmodify it to fit your project requirements. (See the sidebar called "Resources for Model Templates" at the

end of this article for resources that provide sample templates and related information.) Table 1 shows

what a basic SRS outline might look like.


DCE

7/31/2019 se Module 1

25/34


25

1. Introduction

1.1 Purpose

1.2 Document conventions

1.3 Intended audience1.4 Additional information

1.5 Contact information/SRS team members

1.6 References

2. Overall Description

2.1 Product perspective

2.2 Product functions

2.3 User classes and characteristics

2.4 Operating environment

2.5 User environment

2.6 Design/implementation constraints

2.7 Assumptions and dependencies

3. External Interface Requirements

3.1 User interfaces

3.2 Hardware interfaces

3.3 Software interfaces

3.4 Communication protocols and interfaces

4. System Features

4.1 System feature A

4.1.1 Description and priority

4.1.2 Action/result4.1.3 Functional requirements

4.2 System feature B


DCE

7/31/2019 se Module 1

26/34


26

5. Other Nonfunctional Requirements

5.1 Performance requirements

5.2 Safety requirements

5.3 Security requirements

5.4 Software quality attributes

5.5 Project documentation

5.6 User documentation

6. Other Requirements

Appendix A: Terminology/Glossary/Definitions list

Appendix B: To be determinedCharacteristics of a Good SRS:

Before winding up the topic SRS let me list the characteristics of a good SRS.It should be:

Correct

Unambiguous

Complete

Consistent

Ranked for importance and/or stability

Verifiable

Modifiable

Traceable


a.BTech Degree Examination, May 2005, New Scheme-2002 Admission onwards

1. Discuss the various desirable characteristics of an SRS. (8 marks)

b.BTech Degree Examination, Nov 2005,Prior to 2002 Admission-syllabus

1.List out software requirement specifications. (4 marks)

c.BTech Degree Examination, May 2005, Prior to 2002


DCE

7/31/2019 se Module 1

27/34


27

1.Explain problem analysis and requirement specifications. (4marks)

d. BTech Degree Examination, Nov 2005, New Scheme-2002 Admission onwards

1. What are the components of SRS? Explain them briefly. (7 marks)

e. BTech Degree Examination, October/November 2004

1. What is requirement specification? Explain. (4 marks)

6) Summary: By now you are familiar with what a SRS is and what is the need for it. SRS development

will be a collaborative effort for a particular project. You might also be able to prepare SRS for any simple

system. Look through the format of the SRS that will help you through the process. In the next lecture I

will be discussing on problem analysis and validation.


i) SRS refers to

a. Software Recurring System

b. Software Resource Specification

c. Software Requirements Specification

d. Software Requirement System

ii) A SRS consists of

a. System Requirements

b. External Interface Specifications

c. Introduction

d. All of the above

(iii) Which of the following are the characteristics of a good SRS?

a. Correct

b. Unambiguous

c. Modifiable


DCE

7/31/2019 se Module 1

28/34


28

d. All of the above

8) Programming / Computational assignments

i) Read through the case study given in your textbook. It concerns with a system to be developed for

scheduling the courses in computer science department, based on the input about class rooms, lecture

times, and time preferences of the different instructors. Different conditions have to be satisfied by the final

schedule. Analyze the SRS and prepare a report based on your understanding.

Lecture 5

1) Synopsis

Problem Analysis-validation


DCE

7/31/2019 se Module 1

29/34


29


(a) How is problem analysis done?

(b) What are the different methods for validation?

3) Introduction

Now that you have learned how to write a SRS, in this lecture I will be discussing on problem

analysis and validation. Now what is analysis? I have already discussed on that in my introductory lectures.

The basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and the

users, what exactly is desired from the software, and what the constraints on the solution are. Customer

satisfaction should be the prime objective while developing a project. After all for whom are we

developing the project? The basic objective of the requirements validation activity is to ensure that the SRS

reflects the actual requirements accurately and clearly .I will be discussing on various methods of detecting

requirement errors. You will be learning on the various analysis issues and also various validation

methods. In particular we will discuss on the following:

(i) Problem Analysis

-Analysis Issues

-Informal Approach

-Structured Analysis(ii) Validation

-Requirement Reviews

-Other methods


Please refer to pages 83 to 120 and 133 to 137of your textbook.

5) Concepts:


DCE

7/31/2019 se Module 1

30/34


30

Problem analysis

The basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and

the users, what exactly is desired from the software, and what the constraints on the solution are. Analysis

involves interviewing the clients and end users. These people and the existing documents about the current

mode of operation are the basic source of information for the analysis. Analysts not only collect and

organize information about the clients organization and its processes, but they also ct as consultants.

Analysis issues

It is essential that during analysis a complete and consistent set of specification emerge for the system. The

first major problem is to obtain the necessary information. The second major issue is how to organize the

information obtained so the information can be effectively evaluated for completeness and consistency.

The third major problem is resolving the contradictions that may exist in the information from different

phases.

The fourth major problem is avoiding internal design.

There are three basic approaches to problem analysis:

Informal approaches based on structured communication and interaction

Conceptual modeling based approaches

Prototyping

Here I will be discussing on the first two approaches.

Informal Approach

Here no defined methodology is used. The information about the system is obtained by interaction with the

client, end users, questionnaires, study of existing documents, etc. The problem and the system model are

essentially built in the minds of the analysts and are directly translated to the SRS .In such an approach, the

analyst will have a series of meetings with the clients and end users.

Structured analysis

It uses a function-based decomposition while modeling the problem. It focuses on the functions performed

in the problem domain and the data consumed and produced by these functions. This method helps an

analyst decide what type of information to obtain at different points in analysis, and it helps organize

information so that the analyst is not overwhelmed by the complexity. It is a top down approach.


DCE

7/31/2019 se Module 1

31/34


31

The basic system view of this approach is that each system can be viewed as transformation function

operating within an environment that takes some inputs from the environment and produces outputs for the

environment. The data will be transformed from the input to output in a series of transformations starting

from the input and culminating in the desired output. In this approach, we make use of DFDs.

Now what is a DFD?

Data flow diagrams or DFDs shows the flow of data through a system. It views a system as a function that

transforms the inputs into desired outputs.

-The first step in this method is to study the physical environment. A DFD of the current nonautomated

system is drawn. While drawing the DFD for the physical environment, an analyst has to interact with the

users to determine the overall process from the point of view of the data. This step is considered complete

when the entire physical DFD has been described and the user has accepted it.

-The next step is to draw the logical equivalents of the DFD.

-The next step is to develop the logical model of the new system after the changes have been incorporated,

and a DFD is drawn to show how data will flow in the new system.

-The next step is to establish the man-machine boundary what will be automated and what will remain

manual in the DFD for the new system.

-The next two steps are evaluating the different options and then packaging the specifications.

There are various other approaches. One important among them is object oriented modeling. You

will study in detail about the model in your higher semesters.Validation

The basic objective of the requirements validation activity is to ensure that the SRS reflects the

actual requirements accurately and clearly. We need to check if the SRS is of good quality. The types of

errors that typically occur in a SRS are:

Omission

Inconsistency

Incorrect fact

Ambiguity

Besides improving the quality of the SRS itself the validation should focus on uncovering these types of

errors.

Requirement Reviews


DCE

7/31/2019 se Module 1

32/34


32

Requirement reviews in which the SRS is carefully reviewed by a group of people including

representatives of the clients and the users are the most common method for validation. Reviews can be

used throughout software development for quality assurance and data collection, and there is considerable

data now to suggest that reviews and inspections are one of the most effective methods of detecting errors.

Requirement review is a review by a group of people to find errors and point out the matters of concern in

the requirements specifications of a system. The review group includes the author of the requirements

document, someone who understands the needs of the client, a person of the design team, and the person

responsible for maintaining the requirements documents.

-One way to organize the review meeting is to have each participant go over the requirements before the

meeting and mark the items he has doubts about checklists can be useful in identifying such items. In the

meeting, as the member asks questions, the author give clarifications.

-Alternatively, the meeting can start with the analyst explaining each of the requirements in the document.

The participants can ask questions, share doubts, or seek clarifications.

Requirements reviews are probably the most effective means for detecting requirement errors.

Other methods

There are other approaches that may be applicable for some systems or parts of systems.

i) Automated Cross-Referencing

It uses processors to verify some properties of requirements .any automated processing of requirements is

possible if it is written in a formal specification language. These tools can check for internal consistencyand completeness. But these tools cannot directly check for external completeness.

ii) Reading

The goal in reading is to make someone other than the author read the requirements specification document

to identify potential problems. Reading is effective only if the reader takes the job seriously. Even with

serious reading, the reading is limited in scope for catching completeness and consistency errors.

iii) Constructing Scenarios

The most common area for scenario construction is that of the system-user interaction. It helps in clarifying

misunderstandings in the human-computer interaction area. They are of limited value for verifying the

consistency and completeness of the requirements.

iv) Prototyping


DCE

7/31/2019 se Module 1

33/34


33

A prototype can be built to verify the feasibility of the requirements. A prototype that has been built during

problem analysis can also aid validation.


a. BTech Degree Examination, May 2005, Prior to 2002

1.Discuss validation techniques. (4marks) .

b.BTech Degree Examination, May 2005, New Scheme 2002 Admission onwards

1. What do you mean by problem analysis? (4marks)

c.BTech Degree Examination, May 2005, Prior to 2002

1.Explain problem analysis and requirement specifications. (4marks)

d.BTech Degree Examination, Nov 2005, Prior to 2002 Admission -Syllabus

1.Write short note on validation.(4marks)

6) Summary: In this lecture, we have seen through what is an analysis. Analysis is done by interviews

with clients. It is getting into an agreement with the client on the requirements of the project. Afterall

customer satisfaction is the most important part. No client should later be dissatisfied with the project you

will be providing him or her with. We have seen through the validation methods. Validation helps in

writing a good quality SRS. We also discussed about reviews, structured analysis, etc. Next you must

learn about monitoring a project, scheduling a project ,etc. In my next lecture, I will be discussing yoursecond module, which covers project planning.


e. The set of activities that ensure that the software correctly implements a specific function is

i. Testing

b. Verification

c. Validation

d. None of these

ii) Set of activities that ensure that the software has been built is traceable to customer requirements is

a. Testing

b. Verification


DCE

7/31/2019 se Module 1

34/34


34

c. Validation

d. None of these

iii) Data store is a

a. Passive Object

b. Active Object

c. Depends

d. None of the above

iv) Which among the following errors dominate in a software project

a. Omission

b. Ambiguity

c. Inconsistency

d. Cannot specify

8) Programming / Computational assignments

i) Develop a DFD for a banking system. Specify the dataflow, datastores, processes, inputs and outputs for

it.

se Module 1

Documents

Transcript of se Module 1