{"id":505,"date":"2018-10-23T06:43:02","date_gmt":"2018-10-23T06:43:02","guid":{"rendered":"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/?post_type=chapter&#038;p=505"},"modified":"2019-01-15T06:23:49","modified_gmt":"2019-01-15T06:23:49","slug":"system-requirement-specifications","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/chapter\/system-requirement-specifications\/","title":{"rendered":"System Requirement Specifications"},"content":{"raw":"<div><span style=\"float: right\"><a href=\"https:\/\/youtu.be\/m5UQQpZJwBk\" target=\"_blank\" rel=\"noopener\"><img src=\"http:\/\/epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/2018\/11\/download.png\" alt=\"epgp books\" width=\"75px\" height=\"75px;\" \/><\/a>\r\n<\/span><\/div>\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n<ol>\r\n \t<li><strong>Learning Outcome:<\/strong><\/li>\r\n<\/ol>\r\n<ul>\r\n \t<li style=\"text-align: justify\">Comprehend what is system requirement specification.<\/li>\r\n \t<li style=\"text-align: justify\">Understand the need of drafting the SRS before designing the MIS.<\/li>\r\n \t<li style=\"text-align: justify\">List the various users who require the SRS document.<\/li>\r\n \t<li style=\"text-align: justify\">Discuss the various components of the SRS document.<\/li>\r\n \t<li style=\"text-align: justify\">Understand what are software requirements and their types.<\/li>\r\n \t<li style=\"text-align: justify\">Discuss attributes of a SRS document.<\/li>\r\n<\/ul>\r\n<ol start=\"2\">\r\n \t<li><strong>Introduction<\/strong><\/li>\r\n<\/ol>\r\n&nbsp;\r\n<p style=\"text-align: justify\">A well executed and planned life cycle model suggests that before initiating software development, the exact requirements of the customer must be understood and documented. Without proper understanding and documentation of the system requirements the system development should not be started. Else, it would lead to iterative changes in the later life cycle stages and surge up the development cost. Therefore, the requirement analysis and specification stage is considered to be a crucial phase of the software development life cycle. It is important for a team of experts to sit together with the customer and outline the requirements. These experts who work in the domain of capturing the client requirements and writing specification documents are called system analysts.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\">The system analysts capture relevant data to articulate the requirements and identify any redundancies.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\">Exhibit 1 highlights the different touch points with whom the system analysts interact.<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-508 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-296.png\" alt=\"\" width=\"552\" height=\"439\" \/>\r\n<p style=\"text-align: justify\">The SRS document states in a clear manner all functions the new software is expected to perform keeping in mind limiting conditions and assumptions. The SRS is a precursor to all further system documents like system specifications, bill of material, system architecture, product manuals etc. It serves as a blue print drafted with as little cost as possible.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\">Developing an information system requires the end to end life cycle of a process it intends to fulfill. It requires data base integration, transaction processing, application interface with other programs. It is the platform between the client and developer in realizing an automated process. It clearly outlines what activities are in scope of the system and what are not.<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-509 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-297.png\" alt=\"\" width=\"620\" height=\"180\" \/>\r\n\r\n&nbsp;\r\n\r\n<strong>2.1 Why an SRS document is needed?<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">Preparation of the SRS document before the formal MIS design has various advantages. The advantages of an SRS document are listed below:<\/p>\r\n\r\n<ul>\r\n \t<li style=\"text-align: justify\">Requirements in SRS documents enable to rectify omissions, misunderstandings, and inconsistencies early in stages of the MIS development cycle.<\/li>\r\n \t<li style=\"text-align: justify\">Provide a basis for estimating costs and schedules and can be used to obtain the approval of technical bids or price estimates.<\/li>\r\n \t<li style=\"text-align: justify\">Provide a basis for validation and verification.<\/li>\r\n \t<li style=\"text-align: justify\">As part of the development contract MIS, SRS provides a basic document compliance with requirements that can be measured.<\/li>\r\n<\/ul>\r\n<img class=\"size-full wp-image-510 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-298.png\" alt=\"\" width=\"553\" height=\"243\" \/>\r\n<p style=\"text-align: justify\">A well drafted SRS Document finds a variety of usage other than primary intended usage as a basis for starting the primary intended usage as a basis for starting software development work.<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-511 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-299.png\" alt=\"\" width=\"325\" height=\"297\" \/>\r\n<ul>\r\n \t<li style=\"text-align: justify\"><em>Agreement between Customer and the Developers <\/em>\u2013 A competent SRS Document sets the platform for the customers to build their expectation about the software and developers about what is expected from the software.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Reduces Rework <\/em>\u2013 SRS Document requires brainstorming and forces stakeholders to think about all requirements before design and development get underway. This reduces the investment in redesign, rework and retesting.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-512 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-300.png\" alt=\"\" width=\"594\" height=\"288\" \/>\r\n<ul>\r\n \t<li style=\"text-align: justify\"><em>Cost Estimation and Scheduling <\/em>\u2013 Project managers usually estimate volume of work required on software from an analysis of the SRS requirement. Based on this they make further estimations such as the efforts required to develop the software and total cost of development. The project managers use the SRS document as a reference for project planning and work scheduling.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Validation and Verification <\/em>\u2013 It provides a basis against which the compliance of the software can be checked. It further helps to verify if the system is being developed as per specifications.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Facilitates incremental usage <\/em>\u2013 The document serves as a basis for planning future enhancements and scalability as business grows and customer base increases.<\/li>\r\n<\/ul>\r\n<ol start=\"3\">\r\n \t<li><strong>Users of the SRS Document<\/strong><\/li>\r\n<\/ol>\r\n&nbsp;\r\n<p style=\"text-align: justify\">Different people use the SRS Document for different purposes. Various categories of users are listed in exhibit 5 below :<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-513 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-301.png\" alt=\"\" width=\"536\" height=\"330\" \/>\r\n<div>\r\n<ul>\r\n \t<li style=\"text-align: justify\"><em>Users, Customers and Marketing Personnel <\/em>\u2013 These stakeholders refer to the SRS document to ensure the system as described in the document adheres to their needs. Customers may not be the direct users of the SRS document but may rely on it to know what product they can expect. Marketing professionals need the understanding of requirements that they can further pass on to the customers.<\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Software Developers <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 The developers refer to the SRS document to make sure they are developing exactly what is required by the customer. Each requirement as a line item here is to be wetted and agreed prior to the start of the development activity.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Test Engineers, Maintenance and Product Support Staff <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 The support staff need SRS to understand what software products are supposed to do. The engineers use the document to understand functionalities and based on this they write the test cases to validate the working. The required functionality should be clearly described in terms of input and output identified properly.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Technical Writers <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 They use the SRS to ensure the features of the product are understood well enough to be able to write the user\u2019s manuals. Technical writers are skilled information gatherers and are ideal for articulating customer requirements. They know how to determine the questions that are of concern to the user or customer regarding ease of usability.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Project Managers \u2013 <\/em><span style=\"text-align: initial;font-size: 1em\">They refer to the SRS document to for cost estimation as it contains all the information required to plan the project.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Maintenance Engineers <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 To develop an understanding of functionality supported by the system, the SRS is necessary. This enables them to understand the design and the code. It further enables\u00a0<\/span>them to determine the specific modifications to the system\u2019s functionalities needed for a specific purpose.<\/li>\r\n<\/ul>\r\n<\/div>\r\n&nbsp;\r\n<p style=\"text-align: justify\">It can be said that the SRS document serves as a contract or binding between the development team and the customer. It is used to resolve any disagreements between developers and customers that may arise in future. Once the SRS document is agreed upon by the customer and development team it is essential to ensure all requirements are conformed before delivering the solution.<\/p>\r\n\r\n<ol start=\"4\">\r\n \t<li style=\"text-align: justify\"><strong> Characteristics of a good SRS Document<\/strong><\/li>\r\n<\/ol>\r\n<ul>\r\n \t<li style=\"text-align: justify\">A good SRS document is drafted with the experienced gained over a period of time by writing for varied projects. The analyst should be aware of the desirable qualities possessed by a good SRS Document. IEEE (Institute of Electrical and Electronics Engineers) recommends the Practices for Software Requirement Specifications. These should be incorporated while drafting the SRS. Various characteristics of a good SRS are as follows:<\/li>\r\n<\/ul>\r\n<img class=\"size-full wp-image-514 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-302.png\" alt=\"\" width=\"515\" height=\"198\" \/>\r\n\r\n&nbsp;\r\n<div>\r\n<ul>\r\n \t<li style=\"text-align: justify\"><em>Concise <\/em>\u2013 The SRS document is expected to be concise at the same time unambiguous, consistent and complete. It should define all possibilities that shall be encountered and the system\u2019s capability to address them. It should ensure that the SRS capability functions and performance levels are compatible and the required quality features do not negate the capability functions. An unambiguous document suggests that it must contain requirements statements that can be interpreted in one way only.<\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Implementation Independent <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 The document should be independent of implementation decisions. It should only specify what the system should do instead of stating how to do these. The SRS Document should describes the output produced for the different types of input and a description of processing required to produce the output from input and the internal working of the software is not discussed at all.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Requirement Centric <\/em><span style=\"text-align: initial;font-size: 1em\">- Each requirement in SRS must be uniquely identified to a source E.g, use cases, government requirements etc. in other words it should be possible to trace a specific requirement to the design elements that implement it and vice versa. Traceability is\u00a0<\/span>important to verify the results of a phase with respect to the previous phase and to analyze the impact of changing a requirement o the design elements and the code.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Modifiable <\/em>\u2013 Customers frequently change the requirements during the software development in line with changing business needs. Therefore in practice the SRS document undergoes several iterations during software development. The SRS is often modified after the project completes to accommodate future enhancements and evolution. To cope up with the requirements changes, SRS document should be easily modifiable.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Well structured <\/em>\u2013 The document should be well structured. Having the description of a requirement mentioned across many places in the SRS may not be wrong but it tends to make the requirements difficult to understand and any modifications would become difficult as it would require changes to be made at large number of places in the document.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Verifiable \u2013 <\/em>A verifiable SRS is consistent from one level of abstraction to another. It should be possible to design test cases based on the description of the functionality as to whether or not requirements have been met in an implementation. Any feature of the required system that is not verifiable should be listed separately in the goals of the implementation section of the SRS Document.<\/li>\r\n<\/ul>\r\n<\/div>\r\n<ol start=\"5\">\r\n \t<li><strong>Components of SRS Documents<\/strong><\/li>\r\n<\/ol>\r\n&nbsp;\r\n<p style=\"text-align: justify\">Several standard organizations like the IEEE identify the nine components that must be addressed when designing and writing SRS. The IEEE 830 standard intends to serve only as a guideline for organizing a requirements specification document into sections and allows the flexibility of customizing it as require for specific projects. The components and structure of the SRS document to a large extent depends upon the preferences of the system analyst himself and is often guided by policies and standards followed by the development company. The structure also depends upon the type of product it caters to.<\/p>\r\n&nbsp;\r\n\r\n<strong style=\"text-align: initial;font-size: 1em\">1. Introduction<\/strong>\r\n<div>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Purpose - <\/em>This describes where the software should be deployed and how the software would be used.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Project Scope - <\/em>This should briefly describe the overall context within which the software is being developed. E.g, the parts of the problem that are being automated and parts that would need to be automated during future evolution of the software.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Environmental Characteristics <\/em>\u2013 This section briefly outlines the internal and external integration interfaces (hardware and other software) with which the software will interact.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><strong>2. Overall Description<\/strong><\/p>\r\n\r\n<\/div>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Product Perspective <\/em>\u2013 It briefly states as to whether the software is intended to be a replacement for a certain existing system or it is new software. If software being developed would be used as a component of a larger system, a schematic diagram can be given to show the major components of the overall system, subsystem interconnections and external interfaces.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Product Features <\/em><strong>\u2013<\/strong> It summaries the major ways in which the software would be used. A brief summary of the product is presented here.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>User Classes <\/em><strong>\u2013<\/strong> Various user classes that are expected to use this software are identified and described here. The different classes of users are identified by types of functionalities that they are expected to involve or their levels of expertise in using computers.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Operating Environment <\/em>\u2013 it describes in detail the hardware platform on which the software would run, the operating system and other application software with which the developed software would interact.<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-515 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-303.png\" alt=\"\" width=\"499\" height=\"230\" \/>\r\n<p style=\"text-align: justify\"><em>Design and Implementation Constraints <\/em><strong>\u2013<\/strong> Here the various constraints on design and implementation are discussed. These tend to include the corporate or regulatory policies, hardware limitations, interfaces to other applications, databases, programming language to be used, communication protocols, and security considerations or programming standards.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>User Documentation <\/em><strong>\u2013<\/strong> User manuals, on line help, trouble shooting manuals that will be delivered to the customer with the software.<\/p>\r\n\r\n<ol style=\"text-align: justify\" start=\"3\">\r\n \t<li><strong> External Interface Requirements<\/strong><\/li>\r\n<\/ol>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>User Interface <\/em>\u2013 This section describes a broad outline of various interfaces and various principles to be followed. The user interface description may include sample screen images, GUI standards or style guides to be followed, screen layout constraints, push buttons, keyboard shortcuts, and error display messages. These should be documented in a separate user interface specification document.<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-516 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-304.png\" alt=\"\" width=\"454\" height=\"235\" \/>\r\n<p style=\"text-align: justify\"><em>Hardware Interfaces <\/em>\u2013 It describes the interface between the hardware and software components of the system. Description of supported device types, nature of data and control interactions between software and hardware and communication protocols that are to be used.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Software Interfaces <\/em>- Connections between the software and its components, databases, operating systems, tools, libraries and integrated commercial components etc. The data items that would be input to the software and that would be output should be identified and purpose of each should be described.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Communication Interfaces <\/em>\u2013 this describes the requirements associated with any type of communications required b the software, email, web access, network server, communication protocols etc. It shall also identify and state the communication standards that will be used such as Transmission Control Protocol, File Transfer Protocol, Hypertext Transfer Protocol, and Hypertext Transfer Protocol Secure. Any relevant communication security or encryption issues, data transfer rates may be specified.<\/p>\r\n\r\n<ol start=\"4\">\r\n \t<li><strong> System Features<\/strong><\/li>\r\n<\/ol>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Functional Requirements <\/em><strong>-<\/strong> This section lists the functional requirements in ranked order. Functional requirements describe the possible effects of a software system. It describes what the system must accomplish.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\">Each functional requirement should be specified in a format similar to:<\/p>\r\n\r\n<ol>\r\n \t<li style=\"text-align: justify\"><em>Description <\/em>\u2013 This refers to a full description of the requirement.<\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Criticality <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 It describes how essential this requirement is to the overall system.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em>Technical Issues <\/em>\u2013 Describe any design or implementation issues involved in satisfying this requirement.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Cost &amp; Schedule <\/em>\u2013 Describe the relative or absolute costs associated.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Risks <\/em>\u2013 These describe the circumstances under with this requirements might not be able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Dependencies <\/em>- These describe interactions with other requirements.<\/li>\r\n<\/ol>\r\n<ol start=\"5\">\r\n \t<li style=\"text-align: justify\"><strong> Other Non Functional Requirements<\/strong><\/li>\r\n<\/ol>\r\n&nbsp;\r\n<p style=\"text-align: justify\">The various Non Functional Requirements refer to:<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Performance Requirements <\/em>\u2013 Aspects pertaining to number of transactions to be completed per second should be specified here. Some performance requirements may be specific to individual functional requirements or features.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Safety Requirements <\/em>\u2013 Those safety requirements that are concerned with possible loss or damage that could result from the use of the software are specified here. To exemplify, recovery from power failure, handling software and hardware failure may be documented here.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Security Requirements <\/em>\u2013 This section specifies any requirements regarding security or privacy requirements on the data used or created by the software. Any user identity authentication requirements should be well described in this section. It should carry reference to external policies or regulations concerning security issues. Define any security or privacy certifications that must be satisfied.<\/p>\r\n\r\n<ol style=\"text-align: justify\" start=\"6\">\r\n \t<li><strong> Other Requirements<\/strong><\/li>\r\n<\/ol>\r\n&nbsp;\r\n<p style=\"text-align: justify\">This section specifies other useful information for understanding the requirements. All SRS documents must include at least the following two appendices:<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Appendix A: <\/em>It lists out definitions, acronyms, abbreviations. It provides definitions of unfamiliar definitions, terms and acronyms.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><em>Appendix B: <\/em>It provides complete citations to all documents and meetings referenced or used in the preparation of this document.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><strong>5.1 Software Requirements and its types.<\/strong><\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\">As per IEEE, a requirement is a condition or a capability needed by the user to solve a problem or achieve an objective. Software requirements are defined during requirements analysis phase of a software lifecycle.<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-517 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-305.png\" alt=\"\" width=\"539\" height=\"243\" \/>\r\n\r\n&nbsp;\r\n\r\nSoftware requirements fall into four classes. These are explained as under:\r\n<ul>\r\n \t<li style=\"text-align: justify\"><em>Functional requirements <\/em>- Should clearly describe each functionality that the system would support along with the corresponding input and output data set. It specifies the actions the system must be able to perform without taking physical constraints into consideration. These are best described in context of the use case model.<\/li>\r\n<\/ul>\r\n&nbsp;\r\n<p style=\"text-align: justify\">E.g., A medical store inventory software, shall have a high level functional requirement such as search \u2013 medicine. This involves accepting a set of keywords from the user, running a matching algorithm on the medicine list and finally responding as output to the matched medicine. The generated system response could be in several forms E.g, display on the terminal, a print out, some data transferred to the other systems etc<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-518 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-306.png\" alt=\"\" width=\"540\" height=\"337\" \/>\r\n<ul>\r\n \t<li style=\"text-align: justify\"><em>Non functional requirements <\/em>\u2013 These describe only attributes of the system or attributes of the system environment. These are the non negotiable obligations that must be supported by the software. The non functional requirements capture those requirements that cannot be expressed as functions. Although some of these may be captured in use cases, those that cannot may be specified in supplementary specifications. The non functional requirements can be critical in the sense that any failure by the developed software to achieve some minimum defined level in these requirements can be considered as a failure and make the software unacceptable. Are usually global in nature. These include performance, reliability, efficiency, usability, portability, testability etc.<\/li>\r\n \t<li style=\"text-align: justify\"><em>Inverse requirements <\/em>\u2013 These are the requirements that specify what the software system should not do. And are usually found in safety or security requirements.<\/li>\r\n<\/ul>\r\n<img class=\"size-full wp-image-519 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-307.png\" alt=\"\" width=\"482\" height=\"252\" \/>\r\n<ul>\r\n \t<li style=\"text-align: justify\"><em>Design &amp; constraints requirements <\/em>- Design constraints such as specifying specific hardware and software or specific architectures i.e client- server. They describe items or issues that will limit the options available to the developers. Some constraints can be corporate or regulatory policies that need to be honored, hardware limitations, and interfaces with other applications, specific technologies, tools and databases to be used, specific communications protocols to be used.<\/li>\r\n<\/ul>\r\n<img class=\"size-full wp-image-520 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-308.png\" alt=\"\" width=\"629\" height=\"464\" \/>\r\n<ol start=\"6\">\r\n \t<li><strong> Attributes of an ambiguous SRS document<\/strong><\/li>\r\n<\/ol>\r\n&nbsp;\r\n<p style=\"text-align: justify\">SRS document written by inexperienced personnel may pose a variety of problems such as incompleteness, ambiguity and contradictions. There are many other areas that may be left if documents are drafted by novices.<\/p>\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-521 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-309.png\" alt=\"\" width=\"554\" height=\"274\" \/>\r\n\r\n&nbsp;\r\n<div>\r\n<ul>\r\n \t<li style=\"text-align: justify\"><em>Over Specification <\/em>- It occurs during the phase when the analyst tries to address the \u201chow to\u201d aspects in the SRS Document. This aspect restricts the freedom of the designers in arriving at a good design solution.<\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Forward References <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 One should avoid referring to aspects that are discussed much later in the SRS documents. Forward referencing reduces the readability of the specifications.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Wishful Thinking \u2013 <\/em><span style=\"text-align: initial;font-size: 1em\">These problems concern description of aspects which would be difficult to implement.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Noise \u2013 <\/em><span style=\"text-align: initial;font-size: 1em\">It refers to material which is not relevant to the subject matter and software development process. It information only tends to clutter the SRS document diverting the attention from the crucial points.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Contradictory <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 If the same information is described at different places in different ways, it may lead to misinterpretation and contradictions in the context they refer to.<\/span><\/li>\r\n \t<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Safety actions \u2013 <\/em><span style=\"text-align: initial;font-size: 1em\">An SRS is incompetent if it fails to address all failure modes and protection requirements. Actions of function do not actually achieve safe state. The measurement may be too slow to pick-up and prevent accident. It does not define all operating regimes, start-up, shut-down and all environmental conditions.<\/span><\/li>\r\n<\/ul>\r\n&nbsp;\r\n\r\n<strong>7.\u00a0 <\/strong><strong>Summary<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">A software requirements specification is an exhaustive line wise description of the underlying purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform. An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost. The SRS document states in precise and explicit manner the functions and capabilities a software should possess 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 investment 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,<span style=\"text-align: initial;font-size: 1em\">software architecture specifications, testing and validation plans, and documentation plans, are related to it. A good SRS defines how an application will interact with interfaces such as hardware, programs and human users in a wide variety of routine situations. Parameters such as operating speed, response time, availability, portability, maintainability, footprint, security and speed of recovery from adverse events are evaluated. Methods of defining an SRS are described by the IEEE Specification 830-1998.<\/span><\/p>\r\n\r\n<\/div>\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td><strong>you can view video on System Requirement Specifications<\/strong><\/td>\r\n<td><a href=\"https:\/\/youtu.be\/m5UQQpZJwBk\" target=\"_blank\" rel=\"noopener\"><img class=\"alignnone wp-image-120\" src=\"http:\/\/epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/2018\/11\/download.png\" alt=\"\" width=\"36\" height=\"36\" \/><\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n\r\n<strong>Web Resources<\/strong>\r\n<ol>\r\n \t<li style=\"text-align: justify\">http:\/\/www.nitc.ac.in\/mis_srs_detailed_2.0.pdf<\/li>\r\n<\/ol>","rendered":"<div><span style=\"float: right\"><a href=\"https:\/\/youtu.be\/m5UQQpZJwBk\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" src=\"http:\/\/epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/2018\/11\/download.png\" alt=\"epgp books\" width=\"75px\" height=\"75px;\" \/><\/a><br \/>\n<\/span><\/div>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<ol>\n<li><strong>Learning Outcome:<\/strong><\/li>\n<\/ol>\n<ul>\n<li style=\"text-align: justify\">Comprehend what is system requirement specification.<\/li>\n<li style=\"text-align: justify\">Understand the need of drafting the SRS before designing the MIS.<\/li>\n<li style=\"text-align: justify\">List the various users who require the SRS document.<\/li>\n<li style=\"text-align: justify\">Discuss the various components of the SRS document.<\/li>\n<li style=\"text-align: justify\">Understand what are software requirements and their types.<\/li>\n<li style=\"text-align: justify\">Discuss attributes of a SRS document.<\/li>\n<\/ul>\n<ol start=\"2\">\n<li><strong>Introduction<\/strong><\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">A well executed and planned life cycle model suggests that before initiating software development, the exact requirements of the customer must be understood and documented. Without proper understanding and documentation of the system requirements the system development should not be started. Else, it would lead to iterative changes in the later life cycle stages and surge up the development cost. Therefore, the requirement analysis and specification stage is considered to be a crucial phase of the software development life cycle. It is important for a team of experts to sit together with the customer and outline the requirements. These experts who work in the domain of capturing the client requirements and writing specification documents are called system analysts.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The system analysts capture relevant data to articulate the requirements and identify any redundancies.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Exhibit 1 highlights the different touch points with whom the system analysts interact.<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-508 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-296.png\" alt=\"\" width=\"552\" height=\"439\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-296.png 552w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-296-300x239.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-296-65x52.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-296-225x179.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-296-350x278.png 350w\" sizes=\"auto, (max-width: 552px) 100vw, 552px\" \/><\/p>\n<p style=\"text-align: justify\">The SRS document states in a clear manner all functions the new software is expected to perform keeping in mind limiting conditions and assumptions. The SRS is a precursor to all further system documents like system specifications, bill of material, system architecture, product manuals etc. It serves as a blue print drafted with as little cost as possible.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Developing an information system requires the end to end life cycle of a process it intends to fulfill. It requires data base integration, transaction processing, application interface with other programs. It is the platform between the client and developer in realizing an automated process. It clearly outlines what activities are in scope of the system and what are not.<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-509 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-297.png\" alt=\"\" width=\"620\" height=\"180\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-297.png 620w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-297-300x87.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-297-65x19.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-297-225x65.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-297-350x102.png 350w\" sizes=\"auto, (max-width: 620px) 100vw, 620px\" \/><\/p>\n<p>&nbsp;<\/p>\n<p><strong>2.1 Why an SRS document is needed?<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Preparation of the SRS document before the formal MIS design has various advantages. The advantages of an SRS document are listed below:<\/p>\n<ul>\n<li style=\"text-align: justify\">Requirements in SRS documents enable to rectify omissions, misunderstandings, and inconsistencies early in stages of the MIS development cycle.<\/li>\n<li style=\"text-align: justify\">Provide a basis for estimating costs and schedules and can be used to obtain the approval of technical bids or price estimates.<\/li>\n<li style=\"text-align: justify\">Provide a basis for validation and verification.<\/li>\n<li style=\"text-align: justify\">As part of the development contract MIS, SRS provides a basic document compliance with requirements that can be measured.<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-510 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-298.png\" alt=\"\" width=\"553\" height=\"243\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-298.png 553w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-298-300x132.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-298-65x29.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-298-225x99.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-298-350x154.png 350w\" sizes=\"auto, (max-width: 553px) 100vw, 553px\" \/><\/p>\n<p style=\"text-align: justify\">A well drafted SRS Document finds a variety of usage other than primary intended usage as a basis for starting the primary intended usage as a basis for starting software development work.<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-511 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-299.png\" alt=\"\" width=\"325\" height=\"297\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-299.png 325w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-299-300x274.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-299-65x59.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-299-225x206.png 225w\" sizes=\"auto, (max-width: 325px) 100vw, 325px\" \/><\/p>\n<ul>\n<li style=\"text-align: justify\"><em>Agreement between Customer and the Developers <\/em>\u2013 A competent SRS Document sets the platform for the customers to build their expectation about the software and developers about what is expected from the software.<\/li>\n<li style=\"text-align: justify\"><em>Reduces Rework <\/em>\u2013 SRS Document requires brainstorming and forces stakeholders to think about all requirements before design and development get underway. This reduces the investment in redesign, rework and retesting.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-512 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-300.png\" alt=\"\" width=\"594\" height=\"288\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-300.png 594w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-300-300x145.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-300-65x32.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-300-225x109.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-300-350x170.png 350w\" sizes=\"auto, (max-width: 594px) 100vw, 594px\" \/><\/p>\n<ul>\n<li style=\"text-align: justify\"><em>Cost Estimation and Scheduling <\/em>\u2013 Project managers usually estimate volume of work required on software from an analysis of the SRS requirement. Based on this they make further estimations such as the efforts required to develop the software and total cost of development. The project managers use the SRS document as a reference for project planning and work scheduling.<\/li>\n<li style=\"text-align: justify\"><em>Validation and Verification <\/em>\u2013 It provides a basis against which the compliance of the software can be checked. It further helps to verify if the system is being developed as per specifications.<\/li>\n<li style=\"text-align: justify\"><em>Facilitates incremental usage <\/em>\u2013 The document serves as a basis for planning future enhancements and scalability as business grows and customer base increases.<\/li>\n<\/ul>\n<ol start=\"3\">\n<li><strong>Users of the SRS Document<\/strong><\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Different people use the SRS Document for different purposes. Various categories of users are listed in exhibit 5 below :<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-513 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-301.png\" alt=\"\" width=\"536\" height=\"330\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-301.png 536w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-301-300x185.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-301-65x40.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-301-225x139.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-301-350x215.png 350w\" sizes=\"auto, (max-width: 536px) 100vw, 536px\" \/><\/p>\n<div>\n<ul>\n<li style=\"text-align: justify\"><em>Users, Customers and Marketing Personnel <\/em>\u2013 These stakeholders refer to the SRS document to ensure the system as described in the document adheres to their needs. Customers may not be the direct users of the SRS document but may rely on it to know what product they can expect. Marketing professionals need the understanding of requirements that they can further pass on to the customers.<\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Software Developers <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 The developers refer to the SRS document to make sure they are developing exactly what is required by the customer. Each requirement as a line item here is to be wetted and agreed prior to the start of the development activity.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Test Engineers, Maintenance and Product Support Staff <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 The support staff need SRS to understand what software products are supposed to do. The engineers use the document to understand functionalities and based on this they write the test cases to validate the working. The required functionality should be clearly described in terms of input and output identified properly.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Technical Writers <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 They use the SRS to ensure the features of the product are understood well enough to be able to write the user\u2019s manuals. Technical writers are skilled information gatherers and are ideal for articulating customer requirements. They know how to determine the questions that are of concern to the user or customer regarding ease of usability.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Project Managers \u2013 <\/em><span style=\"text-align: initial;font-size: 1em\">They refer to the SRS document to for cost estimation as it contains all the information required to plan the project.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Maintenance Engineers <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 To develop an understanding of functionality supported by the system, the SRS is necessary. This enables them to understand the design and the code. It further enables\u00a0<\/span>them to determine the specific modifications to the system\u2019s functionalities needed for a specific purpose.<\/li>\n<\/ul>\n<\/div>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">It can be said that the SRS document serves as a contract or binding between the development team and the customer. It is used to resolve any disagreements between developers and customers that may arise in future. Once the SRS document is agreed upon by the customer and development team it is essential to ensure all requirements are conformed before delivering the solution.<\/p>\n<ol start=\"4\">\n<li style=\"text-align: justify\"><strong> Characteristics of a good SRS Document<\/strong><\/li>\n<\/ol>\n<ul>\n<li style=\"text-align: justify\">A good SRS document is drafted with the experienced gained over a period of time by writing for varied projects. The analyst should be aware of the desirable qualities possessed by a good SRS Document. IEEE (Institute of Electrical and Electronics Engineers) recommends the Practices for Software Requirement Specifications. These should be incorporated while drafting the SRS. Various characteristics of a good SRS are as follows:<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-514 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-302.png\" alt=\"\" width=\"515\" height=\"198\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-302.png 515w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-302-300x115.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-302-65x25.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-302-225x87.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-302-350x135.png 350w\" sizes=\"auto, (max-width: 515px) 100vw, 515px\" \/><\/p>\n<p>&nbsp;<\/p>\n<div>\n<ul>\n<li style=\"text-align: justify\"><em>Concise <\/em>\u2013 The SRS document is expected to be concise at the same time unambiguous, consistent and complete. It should define all possibilities that shall be encountered and the system\u2019s capability to address them. It should ensure that the SRS capability functions and performance levels are compatible and the required quality features do not negate the capability functions. An unambiguous document suggests that it must contain requirements statements that can be interpreted in one way only.<\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Implementation Independent <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 The document should be independent of implementation decisions. It should only specify what the system should do instead of stating how to do these. The SRS Document should describes the output produced for the different types of input and a description of processing required to produce the output from input and the internal working of the software is not discussed at all.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Requirement Centric <\/em><span style=\"text-align: initial;font-size: 1em\">&#8211; Each requirement in SRS must be uniquely identified to a source E.g, use cases, government requirements etc. in other words it should be possible to trace a specific requirement to the design elements that implement it and vice versa. Traceability is\u00a0<\/span>important to verify the results of a phase with respect to the previous phase and to analyze the impact of changing a requirement o the design elements and the code.<\/li>\n<li style=\"text-align: justify\"><em>Modifiable <\/em>\u2013 Customers frequently change the requirements during the software development in line with changing business needs. Therefore in practice the SRS document undergoes several iterations during software development. The SRS is often modified after the project completes to accommodate future enhancements and evolution. To cope up with the requirements changes, SRS document should be easily modifiable.<\/li>\n<li style=\"text-align: justify\"><em>Well structured <\/em>\u2013 The document should be well structured. Having the description of a requirement mentioned across many places in the SRS may not be wrong but it tends to make the requirements difficult to understand and any modifications would become difficult as it would require changes to be made at large number of places in the document.<\/li>\n<li style=\"text-align: justify\"><em>Verifiable \u2013 <\/em>A verifiable SRS is consistent from one level of abstraction to another. It should be possible to design test cases based on the description of the functionality as to whether or not requirements have been met in an implementation. Any feature of the required system that is not verifiable should be listed separately in the goals of the implementation section of the SRS Document.<\/li>\n<\/ul>\n<\/div>\n<ol start=\"5\">\n<li><strong>Components of SRS Documents<\/strong><\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Several standard organizations like the IEEE identify the nine components that must be addressed when designing and writing SRS. The IEEE 830 standard intends to serve only as a guideline for organizing a requirements specification document into sections and allows the flexibility of customizing it as require for specific projects. The components and structure of the SRS document to a large extent depends upon the preferences of the system analyst himself and is often guided by policies and standards followed by the development company. The structure also depends upon the type of product it caters to.<\/p>\n<p>&nbsp;<\/p>\n<p><strong style=\"text-align: initial;font-size: 1em\">1. Introduction<\/strong><\/p>\n<div>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Purpose &#8211; <\/em>This describes where the software should be deployed and how the software would be used.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Project Scope &#8211; <\/em>This should briefly describe the overall context within which the software is being developed. E.g, the parts of the problem that are being automated and parts that would need to be automated during future evolution of the software.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Environmental Characteristics <\/em>\u2013 This section briefly outlines the internal and external integration interfaces (hardware and other software) with which the software will interact.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><strong>2. Overall Description<\/strong><\/p>\n<\/div>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Product Perspective <\/em>\u2013 It briefly states as to whether the software is intended to be a replacement for a certain existing system or it is new software. If software being developed would be used as a component of a larger system, a schematic diagram can be given to show the major components of the overall system, subsystem interconnections and external interfaces.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Product Features <\/em><strong>\u2013<\/strong> It summaries the major ways in which the software would be used. A brief summary of the product is presented here.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>User Classes <\/em><strong>\u2013<\/strong> Various user classes that are expected to use this software are identified and described here. The different classes of users are identified by types of functionalities that they are expected to involve or their levels of expertise in using computers.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Operating Environment <\/em>\u2013 it describes in detail the hardware platform on which the software would run, the operating system and other application software with which the developed software would interact.<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-515 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-303.png\" alt=\"\" width=\"499\" height=\"230\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-303.png 499w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-303-300x138.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-303-65x30.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-303-225x104.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-303-350x161.png 350w\" sizes=\"auto, (max-width: 499px) 100vw, 499px\" \/><\/p>\n<p style=\"text-align: justify\"><em>Design and Implementation Constraints <\/em><strong>\u2013<\/strong> Here the various constraints on design and implementation are discussed. These tend to include the corporate or regulatory policies, hardware limitations, interfaces to other applications, databases, programming language to be used, communication protocols, and security considerations or programming standards.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>User Documentation <\/em><strong>\u2013<\/strong> User manuals, on line help, trouble shooting manuals that will be delivered to the customer with the software.<\/p>\n<ol style=\"text-align: justify\" start=\"3\">\n<li><strong> External Interface Requirements<\/strong><\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>User Interface <\/em>\u2013 This section describes a broad outline of various interfaces and various principles to be followed. The user interface description may include sample screen images, GUI standards or style guides to be followed, screen layout constraints, push buttons, keyboard shortcuts, and error display messages. These should be documented in a separate user interface specification document.<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-516 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-304.png\" alt=\"\" width=\"454\" height=\"235\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-304.png 454w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-304-300x155.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-304-65x34.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-304-225x116.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-304-350x181.png 350w\" sizes=\"auto, (max-width: 454px) 100vw, 454px\" \/><\/p>\n<p style=\"text-align: justify\"><em>Hardware Interfaces <\/em>\u2013 It describes the interface between the hardware and software components of the system. Description of supported device types, nature of data and control interactions between software and hardware and communication protocols that are to be used.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Software Interfaces <\/em>&#8211; Connections between the software and its components, databases, operating systems, tools, libraries and integrated commercial components etc. The data items that would be input to the software and that would be output should be identified and purpose of each should be described.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Communication Interfaces <\/em>\u2013 this describes the requirements associated with any type of communications required b the software, email, web access, network server, communication protocols etc. It shall also identify and state the communication standards that will be used such as Transmission Control Protocol, File Transfer Protocol, Hypertext Transfer Protocol, and Hypertext Transfer Protocol Secure. Any relevant communication security or encryption issues, data transfer rates may be specified.<\/p>\n<ol start=\"4\">\n<li><strong> System Features<\/strong><\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Functional Requirements <\/em><strong>&#8211;<\/strong> This section lists the functional requirements in ranked order. Functional requirements describe the possible effects of a software system. It describes what the system must accomplish.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Each functional requirement should be specified in a format similar to:<\/p>\n<ol>\n<li style=\"text-align: justify\"><em>Description <\/em>\u2013 This refers to a full description of the requirement.<\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Criticality <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 It describes how essential this requirement is to the overall system.<\/span><\/li>\n<li style=\"text-align: justify\"><em>Technical Issues <\/em>\u2013 Describe any design or implementation issues involved in satisfying this requirement.<\/li>\n<li style=\"text-align: justify\"><em>Cost &amp; Schedule <\/em>\u2013 Describe the relative or absolute costs associated.<\/li>\n<li style=\"text-align: justify\"><em>Risks <\/em>\u2013 These describe the circumstances under with this requirements might not be able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.<\/li>\n<li style=\"text-align: justify\"><em>Dependencies <\/em>&#8211; These describe interactions with other requirements.<\/li>\n<\/ol>\n<ol start=\"5\">\n<li style=\"text-align: justify\"><strong> Other Non Functional Requirements<\/strong><\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The various Non Functional Requirements refer to:<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Performance Requirements <\/em>\u2013 Aspects pertaining to number of transactions to be completed per second should be specified here. Some performance requirements may be specific to individual functional requirements or features.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Safety Requirements <\/em>\u2013 Those safety requirements that are concerned with possible loss or damage that could result from the use of the software are specified here. To exemplify, recovery from power failure, handling software and hardware failure may be documented here.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Security Requirements <\/em>\u2013 This section specifies any requirements regarding security or privacy requirements on the data used or created by the software. Any user identity authentication requirements should be well described in this section. It should carry reference to external policies or regulations concerning security issues. Define any security or privacy certifications that must be satisfied.<\/p>\n<ol style=\"text-align: justify\" start=\"6\">\n<li><strong> Other Requirements<\/strong><\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">This section specifies other useful information for understanding the requirements. All SRS documents must include at least the following two appendices:<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Appendix A: <\/em>It lists out definitions, acronyms, abbreviations. It provides definitions of unfamiliar definitions, terms and acronyms.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><em>Appendix B: <\/em>It provides complete citations to all documents and meetings referenced or used in the preparation of this document.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><strong>5.1 Software Requirements and its types.<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">As per IEEE, a requirement is a condition or a capability needed by the user to solve a problem or achieve an objective. Software requirements are defined during requirements analysis phase of a software lifecycle.<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-517 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-305.png\" alt=\"\" width=\"539\" height=\"243\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-305.png 539w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-305-300x135.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-305-65x29.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-305-225x101.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-305-350x158.png 350w\" sizes=\"auto, (max-width: 539px) 100vw, 539px\" \/><\/p>\n<p>&nbsp;<\/p>\n<p>Software requirements fall into four classes. These are explained as under:<\/p>\n<ul>\n<li style=\"text-align: justify\"><em>Functional requirements <\/em>&#8211; Should clearly describe each functionality that the system would support along with the corresponding input and output data set. It specifies the actions the system must be able to perform without taking physical constraints into consideration. These are best described in context of the use case model.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">E.g., A medical store inventory software, shall have a high level functional requirement such as search \u2013 medicine. This involves accepting a set of keywords from the user, running a matching algorithm on the medicine list and finally responding as output to the matched medicine. The generated system response could be in several forms E.g, display on the terminal, a print out, some data transferred to the other systems etc<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-518 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-306.png\" alt=\"\" width=\"540\" height=\"337\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-306.png 540w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-306-300x187.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-306-65x41.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-306-225x140.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-306-350x218.png 350w\" sizes=\"auto, (max-width: 540px) 100vw, 540px\" \/><\/p>\n<ul>\n<li style=\"text-align: justify\"><em>Non functional requirements <\/em>\u2013 These describe only attributes of the system or attributes of the system environment. These are the non negotiable obligations that must be supported by the software. The non functional requirements capture those requirements that cannot be expressed as functions. Although some of these may be captured in use cases, those that cannot may be specified in supplementary specifications. The non functional requirements can be critical in the sense that any failure by the developed software to achieve some minimum defined level in these requirements can be considered as a failure and make the software unacceptable. Are usually global in nature. These include performance, reliability, efficiency, usability, portability, testability etc.<\/li>\n<li style=\"text-align: justify\"><em>Inverse requirements <\/em>\u2013 These are the requirements that specify what the software system should not do. And are usually found in safety or security requirements.<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-519 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-307.png\" alt=\"\" width=\"482\" height=\"252\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-307.png 482w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-307-300x157.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-307-65x34.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-307-225x118.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-307-350x183.png 350w\" sizes=\"auto, (max-width: 482px) 100vw, 482px\" \/><\/p>\n<ul>\n<li style=\"text-align: justify\"><em>Design &amp; constraints requirements <\/em>&#8211; Design constraints such as specifying specific hardware and software or specific architectures i.e client- server. They describe items or issues that will limit the options available to the developers. Some constraints can be corporate or regulatory policies that need to be honored, hardware limitations, and interfaces with other applications, specific technologies, tools and databases to be used, specific communications protocols to be used.<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-520 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-308.png\" alt=\"\" width=\"629\" height=\"464\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-308.png 629w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-308-300x221.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-308-65x48.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-308-225x166.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-308-350x258.png 350w\" sizes=\"auto, (max-width: 629px) 100vw, 629px\" \/><\/p>\n<ol start=\"6\">\n<li><strong> Attributes of an ambiguous SRS document<\/strong><\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">SRS document written by inexperienced personnel may pose a variety of problems such as incompleteness, ambiguity and contradictions. There are many other areas that may be left if documents are drafted by novices.<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-521 aligncenter\" src=\"http:\/\/mgmtp06.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-309.png\" alt=\"\" width=\"554\" height=\"274\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-309.png 554w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-309-300x148.png 300w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-309-65x32.png 65w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-309-225x111.png 225w, https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-content\/uploads\/sites\/71\/2018\/10\/Untitled-309-350x173.png 350w\" sizes=\"auto, (max-width: 554px) 100vw, 554px\" \/><\/p>\n<p>&nbsp;<\/p>\n<div>\n<ul>\n<li style=\"text-align: justify\"><em>Over Specification <\/em>&#8211; It occurs during the phase when the analyst tries to address the \u201chow to\u201d aspects in the SRS Document. This aspect restricts the freedom of the designers in arriving at a good design solution.<\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Forward References <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 One should avoid referring to aspects that are discussed much later in the SRS documents. Forward referencing reduces the readability of the specifications.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Wishful Thinking \u2013 <\/em><span style=\"text-align: initial;font-size: 1em\">These problems concern description of aspects which would be difficult to implement.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Noise \u2013 <\/em><span style=\"text-align: initial;font-size: 1em\">It refers to material which is not relevant to the subject matter and software development process. It information only tends to clutter the SRS document diverting the attention from the crucial points.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Contradictory <\/em><span style=\"text-align: initial;font-size: 1em\">\u2013 If the same information is described at different places in different ways, it may lead to misinterpretation and contradictions in the context they refer to.<\/span><\/li>\n<li style=\"text-align: justify\"><em style=\"text-align: initial;font-size: 1em\">Safety actions \u2013 <\/em><span style=\"text-align: initial;font-size: 1em\">An SRS is incompetent if it fails to address all failure modes and protection requirements. Actions of function do not actually achieve safe state. The measurement may be too slow to pick-up and prevent accident. It does not define all operating regimes, start-up, shut-down and all environmental conditions.<\/span><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>7.\u00a0 <\/strong><strong>Summary<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">A software requirements specification is an exhaustive line wise description of the underlying purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform. An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost. The SRS document states in precise and explicit manner the functions and capabilities a software should possess 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 investment as possible. The SRS is often referred to as the &#8220;parent&#8221; document because all subsequent project management documents, such as design specifications, statements of work,<span style=\"text-align: initial;font-size: 1em\">software architecture specifications, testing and validation plans, and documentation plans, are related to it. A good SRS defines how an application will interact with interfaces such as hardware, programs and human users in a wide variety of routine situations. Parameters such as operating speed, response time, availability, portability, maintainability, footprint, security and speed of recovery from adverse events are evaluated. Methods of defining an SRS are described by the IEEE Specification 830-1998.<\/span><\/p>\n<\/div>\n<table>\n<tbody>\n<tr>\n<td><strong>you can view video on System Requirement Specifications<\/strong><\/td>\n<td><a href=\"https:\/\/youtu.be\/m5UQQpZJwBk\" target=\"_blank\" rel=\"noopener\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-120\" src=\"http:\/\/epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/2018\/11\/download.png\" alt=\"\" width=\"36\" height=\"36\" \/><\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Web Resources<\/strong><\/p>\n<ol>\n<li style=\"text-align: justify\">http:\/\/www.nitc.ac.in\/mis_srs_detailed_2.0.pdf<\/li>\n<\/ol>\n","protected":false},"author":3,"menu_order":24,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["ms-vinodini-kapoor"],"pb_section_license":""},"chapter-type":[],"contributor":[60],"license":[],"class_list":["post-505","chapter","type-chapter","status-publish","hentry","contributor-ms-vinodini-kapoor"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/pressbooks\/v2\/chapters\/505","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/wp\/v2\/users\/3"}],"version-history":[{"count":10,"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/pressbooks\/v2\/chapters\/505\/revisions"}],"predecessor-version":[{"id":906,"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/pressbooks\/v2\/chapters\/505\/revisions\/906"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/pressbooks\/v2\/chapters\/505\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/wp\/v2\/media?parent=505"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/pressbooks\/v2\/chapter-type?post=505"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/wp\/v2\/contributor?post=505"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/mgmtp06\/wp-json\/wp\/v2\/license?post=505"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}