Importance of Software Requirement Specifications (SRS) in System Development

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

2. 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. Problem Analysis: It is used to understand the problem, goals and constraints. Requirement Specification: It is used to specify that what we have found during the analysis.

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

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

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

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

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

8. 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: • Partitioning • Abstraction • Projection. Partitioningmeans 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.

9. 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. • Projectionis used to many times for structuring information. It is used to define the system with multiple viewpoints. For e.g. seeing the 3D 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.

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

11. Characteristics of SRS: - The following are characteristics of a good SRS:-- • 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.

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

13. 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 : • 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. • 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. • Design Constraints: it represents the restrictions(limitations), which are present when the developer is designing the system.

14. 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:- • Structured English • Regular Expression • Decision Table

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

16. 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 r1 and r2. it is given as (r1r2). • Alternation: It represents the either or relations, given as (r1 | r2). • Closure: It represents zero or more occurrence of regular expression, given as r*. Example: -- • Record file = (Name course)* • LastName = (A|B|C|……Z|a|b|…|z)* • Rno = digit digit digit • Digit = (0|1|2|3|4|5|6|7|8|9)*2

17. 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 = 2n. • If an action is to be taken for a particular combination of the conditions, it is shown by • X (for action).

18. However not all the combinations of conditions might be feasible. Example: Consider the banking system, in which has following conditions and actions: • C1: The account no. is correct. • C2: Thesignature matches. • C3: There is enough money in account. • A1: Give Money. • A2: Give Statement of less Money. • A3: Check for fraud.

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

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

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

22. 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. Checklistis used for this method, which is list of questions which are confusing about system.

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

24. 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. Unit-2

25. 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. Unit-2

26. 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. Unit-2

27. 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. Unit-2

28. 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. Unit-2

29. 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. Unit-2

30. 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. Unit-2

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

32. Unit-2

33. 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. Unit-2

34. 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. Unit-2

35. 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 Unit-2

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

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

38. 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 systemsfall 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:

40. 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:

42. 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:

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

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

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

48. (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.

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