UNIT2 Software Requirement Specifications SRS is the starting

UNIT-2 Software Requirement Specifications : -- SRS is the starting point of the software development activity. This phase of system development was not given much importance. The developers could clearly understand the system when it was explained to them. But when systems became more complex, this phase becomes more important. For the large systems now, Requirement Specification is most difficult and error prone.

In this phase, the requirement analyst (developer) has to identify the needs of the system by taking to the clients (users). If some requirements are added into the existing system, then it is called “new features” of the software. “SRS is a process of converting ideas in minds of clients (input), into the formal document (output). ” • There are two basic activities in SRS. 1. Problem Analysis: It is used to understand the problem, goals and constraints. 2. Requirement Specification: It is used to specify that we have found during the analysis.

• NEED of a SRS : -- 1. Create the basis for agreement between client and developer, about software: This basis for agreement is frequently formalized into a legal contract between the client (or the customer) and the developer (the supplier). So, through SRS, the client clearly describes what it expects from the supplier, and the developer clearly understands what capabilities to build in the software. Without such an agreement, it is almost guaranteed that once the development is over, the project with have an unhappy client, which almost always leads to unhappy developers.

2. An SRS provides a reference for validation of the final product : That is, the SRS helps the client determine if the software meets the requirements. Without a proper SRS, there is no way a client can determine if the software being delivered is what was ordered, and there is no way the developer can convince the client that all the requirements have been fulfilled. Providing the basis of agreement and validation should be strong enough reasons for both the client and the developer to do a thorough and rigorous job of requirement understanding and specification, but there are other very practical and pressing reasons for having a good SRS.

3. A high-quality SRS is a prerequisite to high-quality software : • The quality of SRS has an impact on cost (and schedule) of the project. We have already seen that errors can exist in the SRS. We saw earlier that the cost of fixing an error increases almost exponentially as time progresses. That is, a requirement error, if detected and removed after the system has been developed, can cost up to 100 times more than removing it during the requirements phase itself.

4. A high quality SRS reduces the development cost : The quality of the SRS impacts customer (and developer) satisfaction, system validation, quality of the final software, and the software development cost. If SRS contains the perfect information, there is very less chance of problems in final software. Thus there is reduction in cost.

• 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. Frequently the client and the users do not understand or know all their needs. • The basic principle used in analysis is the same as in any complex task: That is, partition the problem into sub problems and then try to understand each sub problem and its relationship to other sub problems in an effort to understand the total problem. • It is used for understanding the needs of clients, and what is required in the software. • In the technique, the information is collected by questionnaires, documents etc. This information must be complete and consistent. For the phase good communication skill is require. One of the standards for analysis is:

• Structuring information: -- During the analysis, getting the information about system is not difficult, but which information should be collected is difficult. There are three principals for structuring the information: 1. Partitioning 2. Abstraction 3. Projection. Partitioning means the system is divided into different parts and the each part of system is explained in detail. For example, the operating system cannot be explained directly, but we can explain all its parts like files, memory management etc.

• Abstraction, the system is defined in general terms, and then the details are provided separately. For example, when file system of O. S. is analyzed, we provide the details of different functions in file system. Here when we want to study the details of one part of the system, there is no need to understand other parts. • Projection is used to many times for structuring information. It is used to define the system with multiple viewpoints. For e. g. seeing the 3 D object form different angles like top and side. Here the system is studied with different projections, like O. S. can be analyzed as per programmer, general user and as per O. S. expert. Advantage of projection is that problem of difficulty and error prone is reduced as we see all aspects for the system.

• Software Requirement Specification : - • The final output is the software requirements specification document (SRS). For smaller problems or problems that can easily be comprehended, the specification activity might come after the entire analysis is complete. However, it is more likely that problem analysis and specification are done concurrently.

• Characteristics of SRS: - The following are characteristics of a good SRS: -- 1. Correct: An SRS is correct if every requirement included in the SRS represents something required in the final system. 2. Understandable: The SRS document must be such that the developer, client and the users can understand. 3. Unambiguous (unmistakable): SRS can be unambiguous only if all the requirement has one and only one interpretation (meaning). Since it is written in natural language, there are possibilities of ambiguity (confusing words). Some formal language must be used to remove it. 4. Complete: SRS is complete if everything of software is specified. It represents the effect of system for all types of data.

5. Verifiable: SRS is verifiable, if we can check it to compare with the final software. 6. Consistent (reliable): SRS is consistent, if there are no requirements, which are conflicting (opposing) each other. For e. g. in one process the event A occurs only after B, in some other process, event B occurs only after A. this type of inconsistency is removed. 7. Modifiable: Sometimes we may want to make some changes or add some new features in system. Thus, SRS must be modifiable. 8. Traceable: It means that SRS is clearly converted to software. Forward traceability means requirement must be converted to design & code. Backward traceability means design & code can be traced to requirement.

• Components of SRS: : -- Preparation of SRS is very difficult. There must be some guidelines about what should be there in it. The main issues of SRS are : 1. Functional Requirement: It specifies that what the output for a given input is. It shows the relation between input and output of the system. For e. g. it should give solution to what will happen if invalid data is entered. Also, we should specify that even if the input is valid, which operations are not possible. 2. Performance Requirement: There are two types of performance requirements: Static & Dynamic. Static requirement is fixed (which do not changed) For e. g. Total no. of terminals supported, no. of users and no. of files and its sizes. It is also called capacity requirement. Dynamic requirement means those, which are related to execution of the system. It includes two main aspects: Response time & Throughputs. 3. Design Constraints: it represents the restrictions (limitations), which are present when the developer is designing the system.

• Specification Languages: - • The languages are used in SRS must have the characteristics of SRS. Language should be easy to learn and use. There are many methods for language specifications and the Three of them are as followed: 1. Structured English 2. Regular Expression 3. Decision Table

1. Structured English: -- It is the natural language used for specification. The advantage of it is the understood by both – client and supplier (developer). Initially the requirement is collected verbally (speaking), and when it is described in details, we can’t remember everything, and so it is written in English language. The Disadvantage of this method is that requirement is not precise (exact) and it may be ambiguous (unclear). To remove this disadvantage, formal language (language with some rules) is used instead of natural language. This type of specification is called Structured English. In this language, words like “perhaps”. “may be” etc. are not used because they do not show exact condition.

2. Regular Expressions: -- It is used to specify the structured of string formally. It can be considered as a grammar to specify the valid sequence in the language. The main parts of regular expression are as below: – Atoms: The basic symbol or alphabet of language. – Composition: It represents the concatenation of two regular expression r 1 and r 2. it is given as (r 1 r 2). – Alternation: It represents the either or relations, given as (r 1 | r 2). – Closure: It represents zero or more occurrence of regular expression, given as r*. Example: -- • • Record file = (Name course)* Last. Name = (A|B|C|……Z|a|b|…|z)* Rno = digit Digit = (0|1|2|3|4|5|6|7|8|9)*2

3. Decision Tables: -- It is used to specify the complex decision logic. There are two parts of table. Top Part contains all conditions that may occur in the system and Bottom part contains actions to be carried out. The table essentially specifies under what combinations of conditions what actions are to be performed. • The condition can either true or false. • Each condition on top can have two values “Y” for Yes and “N” for No and a blank means it can be either true or false. Thus for N no. of conditions, the total combinations in table = 2 n. • If an action is to be taken for a particular combination of the conditions, it is shown by • X (for action).

• However not all the combinations of conditions might be feasible. Example: Consider the banking system, in which has following conditions and actions: • C 1: The account no. is correct. • C 2: The signature matches. • C 3: There is enough money in account. • A 1: Give Money. • A 2: Give Statement of less Money. • A 3: Check for fraud.

• For this example: we can prepare decision table, and specify Y and N for condition to be True or False, ‘-‘ means any value is allowed (Y/N), and ‘X’ means action is performed. 1 2 3 4 5 C 1 N N Y Y Y C 2 - N N Y Y C 3 - - N Y N A 1 X A 2 A 3 X X X

Validation: • When requirement Specification is prepared, it should contain no error and it must be correct. If errors are found in later stages of development, the cost of its correction will be more. Due to nature of SRS, there is possibility of misunderstanding and errors. There are certain methods for verification, as follows: Reading: The Goal of reading is to make the persons other than writer (developer) of system to read the SRS document. By reading, we can find problems in the system and solve them. Reading process is effective only if the reader considers the job seriously and reads the document carefully.

Constructing Scenarios: Scenarios means it defines how system will work once it is operational. The main part of this method is system–user interaction, which means that how the user sees the system as per his own view. By constructing scenario also, we can clear the misunderstanding. Requirement Reviews: It is the most common method used for validation. The review of requirement is done by a group of people. This group consists of author of SRS document, person who understands needs of clients, person of design team, person responsible of maintaining document & also some persons who are indirectly involved in system.

• By this method, we are incompleteness, inconsistency, unfeasibility and incorrect translation. – Incompleteness means that there may be some functions or modules which are not described completely in detail. – Inconsistency means that there is contradiction (opposing statement) within document like in starting it is written that code must be less than 5 char. , and afterwards it say that code must have 6 chars. – Unfeasibility means that requirement is not feasible. Incorrect translation means that when document is prepared, the information of system is written incorrectly, may be due to some misunderstanding. • Checklist is used for this method, which is list of questions which are confusing about system.

• Automated Cross Referencing: It is the used to check the document automatically that there are some standard languages like PSL (Problem Statement Languages) and SADT (Structured Analysis and Design Techniques). We can compare document with standard and remove errors if any. • Prototyping: Prototype can be created and we can verify requirement It is very much useful for clients & developers, but the disadvantage of this method is that cost occurred is very high.

Planning a Software Project • For a successful project, both good project management and good engineering are essential. Lack of either one can cause a project to fail. • Project management activities can be viewed as having three major phases: – Project planning – Project monitoring and control – Project termination. 9/25/2020 Unit-2 24

• Planning entails all activities that must be performed before starting the development work. • Once the project is started, project control begins. • In other words, during planning all the activities that management needs to perform are planned, while during project control, the plan is executed and updated. • Without a proper plan, no real monitoring or controlling of the project is possible. 9/25/2020 Unit-2 25

• The basic goal of planning is to look into the future, identify the activities that need to be done to complete the project successfully, and plan the scheduling and resources. • A very detailed requirements document is not essential for planning, but for a good plan all the important requirements must be known. 9/25/2020 Unit-2 26

Project Planning • For a project, during planning, a key activity is to plan and specify the process that should be used in the project. • This means specifying the various stages in the process, the entry criteria for each stage , the exit criteria, and the verification activities that will be done at the end of the stage. • Hence the process planning activity mostly leads to select a standard process and tailoring it for the project. 9/25/2020 Unit-2 27

• Cost Estimation • For a given set of requirements it is desirable to know how much it will cost to develop the software, and how much time the development will take. • These estimates are needed before development is initiated. • The primary reason for cost and schedule estimation is cost-benefit analysis, and project monitoring and control. 9/25/2020 Unit-2 28

• By properly including the "overheads" (i. e. , the cost of hardware, software, office space, etc. ) in the cost of a person-month, effort estimates can be converted into cost. • Estimates can be based on subjective opinion of some person or determined through the use of models. 9/25/2020 Unit-2 29

Uncertainties in Cost Estimation • As the cost of the project depends on the nature and characteristics of the project, at any point, the accuracy of the estimate will depend on the amount of reliable information about the final product. • At this time, we have only some idea of the classes of data the system will get and produce and the major functionality of the system. • There is a great deal of uncertainty about the actual specifications of the system. 9/25/2020 Unit-2 30

• Specifications with uncertainty represent a range of possible final products, not one precisely defined product. • The system more fully and accurately, then uncertainties are reduced and more accurate cost estimates can be made. • For example, once the requirements are completely specified, more accurate cost estimates can be made compared to the estimates after the feasibility study. • Once the design is complete, the estimates can be made still more accurately. • The obtainable accuracy of the estimates as it varies with the different phases is shown in Figure Unit-2

9/25/2020 Unit-2 32

• This figure is simply specifying the limitations of cost estimating strategies—the best accuracy a cost estimating strategy can hope to achieve. It does not say anything about the existence of strategies that can provide the estimate with that accuracy. 9/25/2020 Unit-2 33

Building Cost Estimation Models • Any cost estimation model can be viewed as a "function" that outputs the cost estimate. • As the cost of a project depends on the nature of the project, clearly this cost estimation function will need inputs about the project, from which it can produce the estimate. 9/25/2020 Unit-2 34

• The cost for a project is a function of many parameters, it is generally agreed that the primary factor that controls the cost is the size of the project, that is, the larger the project, the greater the cost and resource requirement. • Other factors that affect the cost includes: – Programmer ability – Experience of the developers in the area – Complexity of the project – Reliability requirement 9/25/2020 Unit-2 35

• COCOMO Model: -- • A top-down model can depend on many different factors, giving rise to multivariable models. • One approach for building multivariable models is to start with an initial estimate determined by using the static single-variable model equations, which depend on size, and then adjusting the estimates based on other variables. • This approach implies that size is the primary factor for cost.

• The Constructive Cost Model also estimates the total effort in terms of person-months. The basic steps in this model are: 1. Obtain an initial estimate of the development effort from the estimate of thousands of delivered lines of source code (KLOC). 2. Determine a set of 15 multiplying factors from different attributes of the project. 3. Adjust the effort estimate by multiplying the initial estimate with all the multiplying factors.

• The initial estimate (nominal estimate) is determined by an equation of the form used in the static single-variable models, using KLOC as the measure of size. • To determine the initial effort Ei in person-months the equation used is of type: Ei = a * ( KLOC ) ^ b • In COCOMO, projects are categorized into three types – Organic, semidetached, and embedded. • Organic projects are those that are relatively straightforward and developed by a small team. • The semidetached systems fall between these two types. For ex. Developing a new operating system, a database system (DBMS) and a complex inventory management system. • Embedded projects are those that ambitious and novel, with rigid constraints from the environment and high requirements for such aspects as interfacing and reliability. • The constants a and b for different systems are:

• There are 15 different attributes, called cost driver attributes, that determine the multiplying factors. • These factors depend on product, computer, personnel and technology attributes. For example, product complexity, Analyst’s capability, modern tools etc. • Each cost driver has a rating scale, and for each rating, a multiplying factor is provided as below:

• The multiplying factors for all 15 cost drivers are multiplied to get the effort adjustment factor (EAF). • The final effort estimate E is obtained by multiplying the initial estimate by the EAF. E = EAF * Ei • By this method, the overall cost of the project can be estimated. • Effort for a phase is a defined percentage of the overall effort. • The percentage of total effort spent in a phase varies with the type and size of the project. • The percentages for an organic software project are given in table:

• In COCOMO, the detailed design and code and unit testing are sometimes combined into one phase called the programming phase.

Project Scheduling & Milestone • Once we have already known the cost & time duration for project, we required the scheduling so that we can monitor the program of a project. • In this chart we are drawing the bar which represents all the phases along with its starting data and ending data. • Alternatively we can also draw another chart which represents the actual time taken in different phases. • The second technique for scheduling is PERT (Project Scheduling & Review Technique) chart. This chart is based on creating a network and finding critical path. This technique is useful for large projects.

Quality Assurance Plans • The goal of SQAP (S/w Quality Assurance Plan) is to produce the high quality software. The purpose of SQAP is: – To specify all documents required. – To specify all activities to be performed, and – Tools and methods required to improve the quality of software. • The SQAP process is implemented by following two operations: (1) Verification and Validation (V & V): Both the terms are generally used interchangeably, but the meanings are different. – The verification is the process of determining whether the given phase is fulfilling the requirement of the previous phase. – The validation is process of evaluating the software at the end of the software development. This step is also known as V & V activities.

(2) Inspection and reviews: For increasing the productivity & improving the quality of software, the inspection is required. – Review and Inspection are the terms used interchangeably. In the starting the inspection of the code was carried out. But afterwards, it was found that not only the coding, but the design also requires the review (inspection). – Also, sometimes the problems are present in the requirement analysis itself. Thus, review is widely used nowadays for all the phases. – The advantages of review are • Removal of the defect in system. • Increasing the productivity. • It provides the information for project monitoring.

• The review process is carried out in following manner: • The term is created with the group of people, which consists of – – The author of the product. Quality control engineer. A person from each phase before and after the current phase. The moderator, who is responsible for running review process smoothly. • All the members come prepared with the checklist, which is a set of possible questions about the system. • The meeting starts with the reader, who reads the document about the system. • The questions about the defects in the system will be discussed. In this process. • After the meeting, the moderator creates a report about the inspection, and issues raised during the meeting. The moderator may suggest another review, if required.

• If no further meeting is required, it is responsibility of the moderator to check the work is carried out as per the report afterwards. • Cost of inspection: – The main cost spend in this process is of the time spent by the team for inspection. It was estimated that 5 to 10% of total project cost is spent in this process. – The cost is not a big amount for some projects, the inspection process may be considered as useless at the starting, but as the project grows, its importance also increases.

• 50 -80 % of the defects can be detected through inspective. • It provides data to management that can be used to monitor the quality & progress of the project. • Effectiveness of inspections clearly depends on their implementation. • In summary reviews have been found to be extremely effective for detects, improving productivity and lowering cost. • They provide good checkpoints for the management. To study the progress of a particular project. Reviews are also a good for ensuring qualifies control. • “A good plan is useless unless it is properly executed. ”

Project Monitoring Plans • A good plan is useless if it is not executed properly. Consequently, the major management activity during the project is to ensure that the plan is properly executed, and when needed, to modify plans appropriately. • All the methods management intends to use to monitor the project should be planned, so that management is prepared to handle the changes from the plan & can respond quickly. • Some methods for monitoring a project are as under – 1. Time Sheets • It is the most commonly used method for collecting raw data. • The time sheet records how much time different project members are spending on the different identified activities in the project. • It can be filed daily or weekly.

• The data obtained from the time sheet can be used to obtain information regarding the overall expenditure and its breakup among different tasks and different phases. • For example, the effort distribution with phases in a particular organization can be obtained from the time sheets.

– 2. Reviews • One of the purposes of reviews is to provide information for project control. • Reviews provide a definite (sure) and clearly defined milestone. • It forces the author to complete the product before the review. • The review schedule (comparing with its planned schedule) can be used to check the progress of the project. • The review report is used to find difficulties in the development of specific work product. • In addition, the review reports provide insight into the quality of the software being produced & the types of errors being detected.

• 3. Cost – Schedule – Milestone Graph • It represents the planned cost of different milestones. It also shows the actual cost of achieving the milestones. • By having the planned cost versus milestones and actual cost versus milestones on the same graph, the progress of the project can be grasped (seen) easily. • The X-axis of graph shows the time in terms of months, and the Y-axis shows the cost in monitory value or PMs. • Two curves are drawn: One for the planned cost & planned schedule, and another for the actual cost & actual schedule. All the important milestones of the project are marked as a labeled point in the graph. • By comparing both curves in the graph the progress of project can be seen.

• 4. Earned Value Method – It is an effective method for project monitoring. It uses STPS (Summary Task Planning Sheet), which is actually a chart of all the tasks. – Earned value means the value, which we have assumed after the completion of a task. It is in term of Dollars / PM. By checking the earned value with the actual cost, we can monitor each part of project. At last we can know the overall cost by adding the cost of all the parts. – In general, the value of earned value is somewhat less than the actual effort. – At the end of this method, the earned value summary report is produced monthly or weekly.

Risk Management Risk is defined as “exposure to the chance of injury of loss” • • The risk management is used to reduce the risks in the projects related to cost. , quality and schedule. • This progress can be considered as an activity of the project management only. • Most of the projects have risk. This step is used to minimize the risk in it for e. g. When constructing the building, there may be a risk if its collapse due to earth quakes. To solve this problem, one method is that the building should be located in area, which is not earthquake – prone. Another solution is that we can apply the construction methods in which possibility of collapse is reduce, like wooden structures. • Thus, the risk management activity consists of first identifying that what are the risks and what problems may arise in the projects, and also how to control them.

Risk Management Cont. … • Risk management is an attempt to minimize the chances of failure caused by unplanned events. • The aim of risk management is to minimize the impact of risks in the projects that are undertaken. • A Risk is a probabilistic event – it may or may not occur.

Risk Management Concepts • Risk is defined as an exposure to the chance of injury or loss. • A risk implies that there is a possibility that something negative may happen. In the context of software projects, negative implies that there is an adverse effect on cost, quality or schedule. • Risk Management is the area that tries to ensure that the impact of risks on cost, quality and schedule is minimal. • Risk management begins where normal project management ends.

• Risk management has to deal with identifying the undesirable events that can occur, the probability of their occurring, and the loss if an undesirable event does occur. • Once this is known, strategies can be formulated for either reducing the probability of the risk materializing or reducing the effect of risk materializing. • Risk management revolves around risk assessment and risk control.