Lec 04, 06.pdf

1 Contents and Characteristics of SRS Lec 04, 06 REQUIREMENTS DOCUMENTATION 2  Documentation is the descriptive information (e-g hardcopy manuals, online help files, web sites) that portrays the use and/or operation o...

1 Contents and Characteristics of SRS Lec 04, 06 REQUIREMENTS DOCUMENTATION 2  Documentation is the descriptive information (e-g hardcopy manuals, online help files, web sites) that portrays the use and/or operation of the system.  Requirements documentation is essential as this is the only lasting impression of the requirements elicitation and analysis process that is available to the development team, users and the customer as the system progresses to the later parts of the software lifecycle. Who uses SRS? 3  The requirements document usually called the software requirements specification (SRS). It forms the basis for development as well as testing activities. The SRS is typically used by the following entities:  Customers for understanding what they are expected to get.  Project Managers to estimate and plan the project to deliver the system.  Designers and programmers to know what to build.  Testers to prepare for testing activities.  Maintenance team for understanding the system that they will maintain.  Trainers to prepare the training material for training the end users.  End Users to understand the proposed system and prepare for the change over. Software Requirements Specification 4 (SRS)  The software requirements specification (SRS) is produced at the end of the elicitation and analysis tasks. The SRS may be documented in a combination of natural language textual narrative, interleaved with graphical models, schematic and formal specification languages. The SRS needs to include all requirements and the authors should not assumed that certain requirements are “obvious”.  The objective of documentation is to allow an independent person to review the system and to understand the basis for its coding. Software documentation is intended to help scientists, engineers and programmers who develop or review software to deal with the complexity of software products. Characteristics Of SRS Document 5  A “good” SRS document has the following characteristics:  Completeness  Clarity  Correctness  Consistency  Modifiability  Traceability  Feasibility  Testability  Completeness 6  This is the one of the most difficult to spot. If requirements elicitation doesn’t involve representatives of different types of users the complete set of requirements may not be elicited. Missing requirements are difficult to track since they are not visible. We can aim for high degree of completeness of requirements by ensuring the following:  Elicitation of the requirements from all the “Stakeholders”.  Focusing on user tasks, problems, bottlenecks and improvements required.  Ranking or prioritizing each requirement (functional as well as non-functional) for importance. Prioritizing requirements guide customers to get more careful considerations to each requirements, and this brings to surface any hidden assumptions that they may have made.  Marking areas where requirements are not known as “To Be Determined” (TBD), along with a description of why the requirement is still TBD and a description of what needs to be done to eliminate the TBD (including who and when). Resolving all TBDs before the design phase. Clarity 7  The documented requirements should need to only a single interpretation, independent of the person or the time when the interpretation is done. Here are some issues related to clarity:  One way of avoiding ambiguity is to write the SRS in a requirement specification language, which has a processor that detects many of the semantic, syntactic and lexical errors.  The requirements may also be expressed using requirements analysis and modeling techniques (dataflow diagrams, use-cases, etc).  Semantic meaning. Word might not have meaning  Syntactic  Lexical: words, vocab  Correctness and Consistency 8 Correctness  The SRS can be considered as correct if every requirement stated in the SRS is required in proposed system. There are no real tools or procedures that ensure correctness. If there are any preceding documents then the “requirements” from those earlier documents need to be traced to the SRS. In addition all stakeholders specially users need to review the SRS and confirm that the requirements stated in the SRS correctly reflect their needs. Consistency  Requirements at all levels must be consistent with each other. Any conflict between requirements within the SRS must be identified and resolved. The types of conflicts that are likely to be found in an SRS are:  Characteristics (format, details) of a real world entity interacting with the system may be conflicting.  There may be a logical or temporal conflict between two specified items.  The terminology used for some entities/events may be different. Modifiability, Minimal Redundancy and labelling 9  Modifiability  The SRS needs to be documented in such a manner that a history of changes can be contained in the document. It will also be necessary to be able to highlight and trace the changes to the requirements as we progress through the project. Certain good practices that can lead to high modifiability are:  Minimal Redundancy Though redundancy itself is not an error, it can lead to inconsistencies when changes are incorporated.  Labeling If requirements are labeled (or numbered), it is easy to pinpoint the requirements that have changed. This includes labels and references to figures, tables, diagrams and appendices in the SRS. Traceability 10 Traceability  Labeling or numbering of requirements provides a mechanism to trace each requirement through the design, into the test plans, test cases and source code. Expected traceability is of two types:  Backward traceability to the documentation and other work products created prior to the requirements phase. This will depend upon how well referencing and labeling has been provided in the earlier documents/ work products.  Forward traceability this will depend upon how each requirement in the SRS is labeled/number. Forward traceability is extremely important as this is one of the ways of tracing a requirement to its implementation. Feasibility and Testability 11 Feasibility  Though it may not be possible to confirm the feasibility of implementation of all requirements, any requirement which is apparently infeasible, should be eliminated from the SRS, after giving the reasoning. Testability  The SRS needs to be stated in such a way that it is possible for the tester to create test plan and confirm whether the requirements are met or not. Typical statements in a SRS which may be non testable or statements which contain phrases like “user friendly”, “reasonable response” , “fairly accurate”. Statements that are non testable and non verifiable need to be identified and removed or revised.  12 Requirement Engineering Requirements engineering can be divided into two main set of activities:  Requirements Definition  Requirements Management 13 Contents Of SRS Document 14  Introduction  Purpose of this document  Scope  Overview  Business-Context  System Description  Product-Functions  Similar-System-Information  User-Characteristics  User-Problem-Statement  User-Objectives  General-Constraints  Functional Requirements 15  Non-Functional Requirements  Performance Availability  Resource Utilization Reliability Efficiency Accuracy  Security Reusability  Safety Ease of Use  Capacity Interoperability  Interfaces Portability  Privacy 16 Design Constraints  Expandability Project  Maintainability Requirements  Testability Preliminary  Interface Schedule Requirements Preliminary Budget  User Interfaces Appendices  Hardware Interfaces Definitions,  Communications Acronyms, Interfaces Abbreviations References  Software Interfaces