BTC 502 Software Engineering 1

Lecture 1
1) Synopsis Introduction to Software engineering Introduction 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

BTC 502 Software Engineering 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

Module-1

BTC 502 Software Engineering 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. The coding 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.

Module-1

BTC 502 Software Engineering 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. These basic 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

Module-1

BTC 502 Software Engineering 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. Coding d. Maintenance v) Which of the following form the first phase in any development process Design b. Coding c. Testing d. None of these

Module-1

BTC 502 Software Engineering 6

Lecture 2
1) Synopsis Software development process models 2) Target: At the completion of this lecture you should be able to answer questions like (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

Module-1

BTC 502 Software Engineering 7

4) Revision/Prerequisites 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

Module-1

BTC 502 Software Engineering 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.

Module-1

BTC 502 Software Engineering 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

Module-1

BTC 502 Software Engineering 10

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

Requirement analysis Design Code Test

Design

Code

Test

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

Module-1

BTC 502 Software Engineering 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.

Design 0

Design 1

Design n

Implement 1 Implement 0

Implement n

Analysis 1 Analysis 0

Analysis n

Module-1

BTC 502 Software Engineering 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 need to 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 1 Acquisition rates too high 2 File format might not be Probability Loss 5 5 Risk Risk Management Approach Develop prototype to demonstrate feasibility Develop benchmarks to show speed of data

Exposure 9 45 3 15

Module-1

BTC 502 Software Engineering 13

efficient 3 Uncertain user interface

10

manipulation 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

Module-1

BTC 502 Software Engineering 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. 7) Exercise Questions 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.

Module-1

BTC 502 Software Engineering 15

a. b. Incremental model Prototyping model

Spiral model Waterfall model

iv) Prototyping based development process will counter the following limitations of waterfall model: i. ii. iii. iv. The waterfall model assumes that the requirements of a system can be frozen before the design begins The waterfall model stipulates that the requirements be completely specified before rest of the development can proceed The waterfall model freezes the hardware and environment specification. 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 plan b. 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?

Module-1

BTC 502 Software Engineering 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 2) Target: At the completion of this lecture you should be able to answer questions like (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) (ii) Role of Management in software development Role of Metrics and measurement

4) Revision/Prerequisites

Module-1

BTC 502 Software Engineering 17

Please refer to pages 46 to 51 of your textbook. 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 has to 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

Module-1

BTC 502 Software Engineering 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.

University Questions 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)

Module-1

BTC 502 Software Engineering 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. 7) Exercise Questions 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 a. Software metrics b. Software measurement c. Planning d. Estimation iii) Metrics have been proposed to quantify things like a. Size b. c. Complexity Reliability software system or the software development process.

d. All of the above

Module-1

BTC 502 Software Engineering 20

Lecture 4
1) Synopsis Software requirement specification (SRS) 2) Target: At the completion of this lecture you should be able to answer questions like (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.

Module-1

BTC 502 Software Engineering 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 4) Revision/Prerequisites Please refer to pages 73 to 83 of your textbook. 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:

Module-1

BTC 502 Software Engineering 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:

Module-1

BTC 502 Software Engineering 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

Module-1

BTC 502 Software Engineering 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, and modify 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.

Module-1

BTC 502 Software Engineering 25

1. Introduction 1.1 Purpose 1.2 Document conventions 1.3 Intended audience 1.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/result 4.1.3 Functional requirements 4.2 System feature B

Module-1

BTC 502 Software Engineering 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 determined Characteristics 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

University Questions 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

Module-1

BTC 502 Software Engineering 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. 7) Exercise Questions 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

Module-1

BTC 502 Software Engineering 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

Module-1

BTC 502 Software Engineering 29

2) Target: At the completion of this lecture you should be able to answer questions like (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 4) Revision/Prerequisites Please refer to pages 83 to 120 and 133 to 137of your textbook.

5) Concepts:

Module-1

BTC 502 Software Engineering 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.

Module-1

BTC 502 Software Engineering 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: errors. Requirement Reviews Omission Inconsistency Incorrect fact Ambiguity

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

Module-1

BTC 502 Software Engineering 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 consistency and 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

Module-1

BTC 502 Software Engineering 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. University Questions 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 your second module, which covers project planning. 7) Exercise Questions 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 a. Testing b. Verification customer requirements is

Module-1

BTC 502 Software Engineering 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.

Module-1