Session VI: Software Requirements & IEEE Std 830-1998 Session VI : Software Requirements and IEEE | Session Vi Objectives | Std 830-1998 Topics 1. Understand the application of IEEE |. What is a software requirement? | Std 830, |i, Contents of IEEE Std 830 - 1998 2. Lean how to write good | Wl, Standards in Writing Requirements requirements based on. IV. Classification of Requirements international standards and. V. Requirements Traceability Matrix practices, Software Requirements Software Requirements contains functional and non-functional requirements that reflect the quantitative ‘and qualitative aspects of the solution + Behavioral - describe the external, visible functionality of the system ‘+ Algorithmic - describe the internal, hidderi functionality of the system IEEE Standard for SRS re Sea Definitions, acronyms, 2 Overall Description limitations, paralletism, etc.) Assumptions and Dependencies 3 Specific Requirements isis the __]airrretirementsscinere ‘Appendices body of the document). IEEE STD provides «lifferent templates for this section ‘Describes all external interfaces: system, user, hhardvrare, software; also operations and site adaption, and hardware constraints Index ‘SRS Contents Software Requirements Specification should address: ‘= Functionality. ‘© What is the software supposed to do? ‘+ Extornal Interfaces. ‘© How does the software interact with people, the system's hardware, other hardware, and other software? ‘©. What assumptions can be made about these external enti + Required Performance. ‘© What is the speed, availability, response time, recovery time of various software functions, and soon? Revision Code: 01 Page 20 of 26+ Quality attributes. © What are the portability, correctness, maintainability, security, and other considerations? ‘+ Design constraints imposed on an implementation. (© Are there any required standards in effect, implementation language, pi integrity, resource limits, operating environment(s) and so on? jes for database SRS should not include. ‘+ Project development plans © E.g. cost, staffing, schedules, methods, tools, etc. © Lifetime of SRS is until the software is made obsolete ‘© _ Lifetime of development plans is much shorter + Product assurance plans ‘© Configuration Management, Verification and Validation, Test Plans, Quality Assurance, te. © Different audiences © Different lifetimes + Designs: (© Requirements and designs have different audiences, © Analysis and design are different areas of expertise ‘+ Le. requirements analysts shouldn't do designs! © Except where application domain constrains design "Eq limited communication between different subsystems for security reasons Standards in Writing Requirements 1 Structure of a good requirement Defines a user type To be verb Ae tn ete Defines a positive end result Statement Structuring Poorly structured indi lual requirement statements will result in confusing specifications that are prone to incorrect interpretations. 2. Words and Phrases ‘+ Use the simplest words appropriate to the intent of the statement. Hide is defined as "to put out of sight". Obscure is defined as “lacking light or dim". Don't use obscure if you mean hide. * Use imperatives correctly and be consistent. Remember, shall "prescribes", will "describes", must & must not "constrain’, and should "suggests" Avoid weak phrases such as “as a minimum", "be able to", “capable of", and "not limited to" Do not use words or terms that give the provider an option on the extent that the requirement is to be satisfied such as "may’, “if required”, “as appropriate", or "if practical’ + Do not use generalities where numbers are really required such as "large", "rapid", "many", "timely", “most”, or “close”. © Avold fuzzy words that have relative meanings such as "easy", "normal", "adequate", or fective’. Revision Code: 01 Page 21 of 26A a i i i i i ; i i a i i ' i i i | ' Providing Examples + Immediately follow whet is to be illustrated with the example. * Repeat an example ifit is not already located on the same page. Its better to be repelitive than to divert the reader's attention = Ensure that the example is not mistaken as part of the specification by the use of italics, quotes, of being explicit. For example: “This is an example.” Indicators of Strengths and Weaknesses Categories of indicators related to individual specification statements: A. Imperatives Imperatives are those words and phrases that command that something must be provided. (© Shall is usually used to dictate the provision of a functional capability. Must or must not is most often used to establish performance requirements or constraints. ‘0. Is required to is often used as an imperative in specifications statements written in the passive voice. 0 Are applicable" is normally used to include, by reference, standards or other documentation {as an addition to the requirements being specified. © Responsible for is frequently used as an imperative in requirements doouments that are written for systems whose architectures are already defined. As an example, “The XYS function of the ABC subsystem is responsible for responding to PDQ inputs. © Will is generally used to cite things that the operational or development environment will provide to the capability being specified. For example, “The building's electrical system will power the XYZ system.” © Should is not frequently used as an imperative in requirement specification statements. However, when it is used, the specifications statement is always found to be very weak. For example, *Within reason, data files should have the same time span to facilitate ease of use ‘and data comparison.” B. Continuances Continuances are phrases such as those listed below that follow an imperative and introduce the specification of requirements at a lower level. The extent that continuances were used was found to be an indication that requirements were organized and structured. These characteristics ‘vonttibute to the tractability and maintenance of the subject requirement specification. However, in some instances, extensive use of continuances was found to indicate the presence of very ‘complex and detailed requirements specification statements. Sample continuances are listed below in the order most frequently found in requirements documents. below: as follows: following: listed: in particular: support co00e ©. Directives Directives is the category of words and phrases that point to illustrative information within the requirements document. The data and information pointed to by directives strengthens the document's specification statements and makes them more understandable. A high ratio of the fotal count for the Directives category to the documents total lines of text appears to be an indicator of how precisely requirements are specified within the document, Sample directives are listed below in the order that they are most often encountered in requirements specifications. © figure © table © forexample © note Revision Code: 01 Page 22 of 26D. Options Options is the category of words that give the developer latitude in satisfying the specification statements that contain them. This category of words loosens the specification, reduces the ‘acquirer's control over the final product, and establishes a basis for possible cost and schedule risks. Sample words identified as options are listed in the order that they are most frequently used in requirements documents. © can ° may © optionally E. Weak Phrases Weak Phrases Is the category of clauses that are apt to cause uncertainty and leave room for ‘multiple interpretations. Use of phrases such as "adequate" and "as appropriate” indicate that ‘what is required is either defined elsewhere or, worse, that the requirement is open to subjective interpretation. Phrases such as “but not limited to” and “as a minimum" provide a basis for expanding a requirement or adding future requirements. The total number of weak phrases found ina document is an indication of the extent that the specification is ambiguous and incomplete. ‘The weak phrases are: © adequate © capability to © asaminimum © capability of ©. as applicable © effective © easy © if practical © 8S appropriate © normal © beable to © provide for © be capable © timely © but not limited to © thd Classification of Requirements (based on FURPS) ‘The FURPS acronym represents a portion of the requirement types for which we should be searching; it reminds us to get non-functional (URPS) as well as functional (behavioral) requirements. F = unctionality, U--sabilty R- eliability P -erformance 'S - upportabilty Components of FURPS+ Revision Code: 04 Page 23 of 26,Session VII: Test Case Design Approaches/Techniques | Session Vil = jjectives | fechniques | Topics: 4. Understand the validation methods. |. Validation Methods 2 Learn the application of Il. Equivalence Partitioning equivalence partitioning Il Boundary Value (BV) Analysis Understand boundaries and the IV. White-box Testing Practices different uses of boundary values 4, Understand —white-box testing practices: fest Case Design Approaches | Session Vil Validation Mettiods Black-box methods for function-based tests ‘The following methods are commonly used: 1. Equivalence partitioning 2. Boundary-value analysis, 3. Error guessing 4. Invalid Combinations and Processes The following are lesser-used methods: Cause-effect graphing Inventoriesftrace Matrix State transition diagram Decision Table Domain Analysis Orthogonal Arrays ‘¢ Identifies ranges of inputs and initial conditions that are expected to produce the same result ‘+ If situations are equivalent, or essentially similar, to one another, itis adequate to test only one of them, not all ‘+The aim is to minimize the number of test cases required to cover these input conditions. Application of Equivalence Partitioning + A password field allows 8 digits; any more are invalid. Since values that are on the same side of a boundary are members of the same "equivalence class,” there is no point to testing many ‘members of the same equivalence class (2.g., passwords with 10 digits, 11 digits, 12 digits, etc), since they will produce the same result Equivalence Classes © Valid data (© User supplied commands © Responses to system prompts ©. File names © Computational data "Physical parameters, * Bounding values * Initiation values Output data formatting commands Responses to error messages © Graphical data (e.g., mouse picks) 0° Revision Code: 01 Page 24 of 26ee ee ee ee ee ee ee ee ee ee ee es © Invalid data ‘© data outside bounds of the program ‘© physically impossible data ‘© proper value supplied in wrong place ng Equivalence Classes Input condition is a range: one valid and two invalid classes are dofined Input condition requires specific value: one valid and two invalid classes are defined Input condition is boolean: one valid and one invalid class are defined Boundary Value (BV) Analysis + Used mostly for testing input edit logic * Checks that the processes for fillering out invalid data are working acceptably. Boundary conditions should be determined as part of designing effective BV test cases, since many defects ‘occur on the boundaries. Boundaries : Boundaries define three sets or classes of data: ‘+ Good (in-bounds) + Bad (out-of-bounds) + Borderline (on-bounds) Example: Consider an application that checks an input to ensure that itis greater than 10. Value Explanation In-bounds 13 ‘This value is greater than 10 Outofbounds | 5 This value is less than 10 on-bounds 10 This value Is not greater than nor less than 10 Other Uses of Boundary Values When defining the test-input values for a numeric input, one could consider the following: ‘© Does the field accept numeric values only, as specified, or does it accept alphabetic values? + What happens if alphabetic values are entered? Does the system accept them? If so, does the system produce an error message? = What happens if the input field accepts characters that are reserved by the application or by a particuler technology, e.g. special characters such as ampersands in Web applications? Does the application crash when the user inputs these reserved characters? ‘The system should either not allow out-of-bounds characters to be entered, or instead should handle them gracefully by displaying an appropriate error message. Boundary Value Testing © Range a..b (© test cases: a, b, just below a, just above b + Number of values: ‘© test cases: max, min, just below min, just above max Output bounds should be checked Boundaries of data structures shall be checked (e.9. orthogonal arrays) Revision Code: 01 Page 25 of 26eee eee White-box Testing Practices * Also called structural testing (uses the internal structure of the code to derive test cases. It is 2 selective testing technique that focuses on the procedural logic. Its applied at the detailed design stage to a procedural design. + Three white box test techniques: © Basic Path Testing © Graph Matrices © Loop Testing Session Vill: System Test Design Preparing Test Design Specifications © Completing test cases © Writing test procedures * Defining test data ‘+ Updating the RTM Revision Code: 01 Page 26 of 26