and System Software Requirements Definition (SSRD)
Intelligent CodeCount Superstructure
Team 16
Lead - Robert F. Huber Operation Concept - Sunil C. Raga System Architect - Thomas Ackenhausen Proto-typist - David Naumann UML Modeler - Kevin Sigmund IV&V - Joe Vahabzadeh IV&V - Brad Johnson
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
I
Version Date: 11/21/05
System and Software Requirements Definition (SSRD) 11/21/2005
Version 2.00
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc II
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Version History
Date 09/30/0 5 10/10/0 5 Author Kevin Sigmund Sunil Raga Versio n 1.00 1.01 Changes made 1 LCO Core Draft Release (Sections 1,2,3,4,5) 1 Changed Version Number, Version Date, And Corrected File Name In Header And Footer 2 Added IV&V Members To Team List On Cover 3 Added PR-7 to PR-13 for tool use requirements. 4 Moved PR-4, 5, 6 to CR Requirements. 5 Updated CR Requirement Postconditions To Reflect System State. 6 Updated General Formatting For Appeal (i.e. All Paragraphs Formatted To Full Justified). 7 Replaced Hyperlink Table Of Tables With Proper Word Table of Tables, and Replaced Word Table of Figures Error With Caption No Figures. 8 Updated Section 1.1 To Specify Major Differences Between SSRD and Original EWW Agreements. Rationale Baseline Draft Version Pre LCO Core Release Changes 1 to 5 Made Based Upon Feedback From Grading/Review Of LCO Core. Changes 6 to 10 made to improve technical value of document.
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc III
Version Date: 11/21/05
System and Software Requirements Definition (SSRD) Date 10/22/0 5 Author Kevin Sigmund Versio n 1.02 Changes made Rationale
Version 2.00
1 Corrected Joe Vahabzadeh's misspelled last name on cover sheet. 2 Corrected CR-7 to be more generic and not specifically refer to a "COCOMO II report file" as no such thing exists. 3 Updated LOS-1 description such that it be both more specific and measurable. 4 PR-7 and PR-8 now refer to document formats, as opposed to specific tools. 5 Added reference and hyperlink to Easy Win-Win report. 6 Added PR-16, PR-17, and PR18. 7 Updated CR-3 description and corrected typographical errors. 8 Corrected typographical errors in CR-5. 9 Updated reference to OCD. 10 Corrected typographical errors in section 1.2. 11 Revised previous entry to "Version History" to reflect actual changes made. 12 Added page number to cover sheet. 13 Combined Tables 15 & 16. 14 Combined Tables 18 & 19. 15 Updated header on page V. 16 Noted in 1.1 that major requirements issues have been finalized. 17 Updated PR-2 to include IIV&V effort. 18 Corrected Section 3 title to match MBASE 1.4 Guidelines. 19 Added LOS-3. 20 Included additional stakeholders as possible providers of templates in ER1. 21 Added SIR-2. b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc IV
Changes 2-8 as per ARB comments and recommendations. Changes 1, 9-21 as per IIV&V recommendations.
Version Date: 11/21/05
System and Software Requirements Definition (SSRD) Date 11/10/0 5 Author Kevin Sigmund Versio n 1.03 Changes made 1 Various minor formatting changes, including page numbering. 2 Various typographical changes. 3 Adjusted Table of T ablest to accurately reflect correct page numbers. 4 Included maintainers as success critical stakeholders. 5 Referenced most current versions of OCD, SSAD, and Prototype results. 6 Included IV&V effort in estimated hours. 7 Completed description of PR14. 8 Added PR-18. 9 Added LOS-4. 10 Clarified LOS-1. 11 Included a description of a syntax template. 12 Removed references to obsolete win conditions. 13 Restated PR-16's description. 14 Updated 1.1 and removed statement that requirements had been finalized. 15 Corrected PR-12 to refer to a specific version of UML. 1 Updated references to OCD and Lean MBASE Guidelines. 2 Added justification for 2.2.5. 3 Added PR-17. 4 Added CR-7. 5 Updated post-condition to CR4. 6 Moved CR-5 to LOS-5. 7 Updated CR-5 post-condition. 8 Added justification for 4.2. 9 Added justification for 4.3. 10 Clarified description of SIR-2. Rationale
Version 2.00
All changes made as per IV&V recommendations.
11/21/0 5
Kevin Sigmund
2.0
As per DeWitt
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc V
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Table of Contents
SYSTEM AND SOFTWARE ..............................................................................................I REQUIREMENTS DEFINITION ........................................................................................I (SSRD)................................................................................................................................I VERSION HISTORY.........................................................................................................III TABLE OF CONTENTS...................................................................................................VI TABLE OF TABLES.......................................................................................................VII TABLE OF FIGURES.......................................................................................................IX A.1. SSRD Overview...............................................................................................................1 A.1.1 Status of the SSRD...................................................................................................1 A.1.2 References................................................................................................................2 2. Project Requirements..........................................................................................................3 2.1 Budget and Schedule...................................................................................................3 2.2 Development Requirements........................................................................................4 2.3 Deployment Requirements..........................................................................................7 2.4 Transition Requirements.............................................................................................7 2.5 Support Environment Requirements .............................................................................8 3. Capability (Functional/Product) Requirements..................................................................9 A.2. 4. System Interface Requirements.................................................................................18 4.1 User Interface Standards Requirements....................................................................18 4.2 Hardware Interface Requirements............................................................................18 4.3 Communications Interface Requirements.................................................................18 4.4 Other Software Interface Requirements....................................................................18 5. Level of Service (L.O.S.) Requirements.....................................................................20 6. Versions, States and Modes..............................................................................................23 7. Evolutionary Requirements..............................................................................................24 8. Appendices........................................................................................................................25
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc VI
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Table of Tables
TABLE 1: PR-1 (24-WEEK SCHEDULE).........................................................................3 TABLE 2: PR-2 (DEVELOPMENT COST).......................................................................3 TABLE 3: PR-3 (EASY WIN-WIN TOOL USE)................................................................4 TABLE 4: PR-4 (DART TOOL USE).................................................................................4 TABLE 5: PR-5 (RATIONAL ROSE TOOL USE)...........................................................4 TABLE 6: PR-6 (MS PROJECT TOOL USE)...................................................................4 TABLE 7: PR-7 (MICROSOFT WORD DOCUMENT FORMAT USE).............................5 TABLE 8: PR-8 (ADOBE PORTABLE DOCUMENT FORMAT USE).............................5 TABLE 9: PR-9 (ICARD AND EFFORT REPORTING TOOL USE)................................5 TABLE 10: PR-10 (ANSI C++ COMPILER TOOL USE)..................................................5 TABLE 11: PR-11 (C++ LANGUAGE USE).....................................................................6 TABLE 12: PR-12 (UML LANGUAGE USE)....................................................................6 TABLE 13: PR-13 (HARDWARE PLATFORM INDEPENDENCE).................................6 TABLE 14: PR-14 (CODECOUNT SOFTWARE USE)....................................................7 TABLE 15: PR-15 (USER ABILITY ASSUMPTION)........................................................7 TABLE 16: PR-16 (PROVIDED INSTRUCTIONAL DOCUMENTATION).......................7 TABLE 17: PR-17 (PROVIDE APPLICATION OVERVIEW)............................................8 TABLE 18: PR-18 (CS 599 GRADUATE STUDENT MAINTENANCE)..........................8 TABLE 19: PR-19 (MAINTAINER SKILL LEVEL)...........................................................8 TABLE 20: CR-1 (LEVEL 1 INTELLIGENT COUNTING CAPABILITY).........................9 TABLE 21: CR-2 (LEVEL 2 INTELLIGENT COUNTING CAPABILITY).......................10
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc VII Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
TABLE 22: CR-3 (CODECOUNT CONVERSION FACTORS)......................................12 TABLE 23: CR-4 (RE-FACTOR MAP DRIVEN VALIDATION).....................................14 TABLE 24: CR-5 (NO DOUBLE-COUNTING)................................................................15 TABLE 25: CR-6 (COST ESTIMATION METRICS REPORT FILE)..............................16 TABLE 26: CR-7 (USER-DEFINED BINS).....................................................................17 TABLE 27: SIR-1 (COMMAND LINE INPUT FOR TOOL PARAMETERS)..................18 TABLE 28: SIR-2 (CODECOUNT SOFTWARE INTERFACE)......................................18 TABLE 29: SIR-3 (USER-PROVIDED MAP FILE).........................................................19 TABLE 30: LOS-1 (POLYNOMIAL PERFORMANCE)..................................................20 TABLE 31: LOS-2 (COUNTING ACCURACY)...............................................................21 TABLE 32: LOS-3 (NUMBER OF LANGUAGES SUPPORTED)..................................21 TABLE 33: LOS-4 (C++ REUSABLE CODE FEATURES USE)...................................22 TABLE 34: LOS-5 (MODIFIED CODE BLOCK CRITERION).......................................22 TABLE 35: ER-1 (AUTOMATIC RE-FACTOR MAP GENERATION)............................24
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc VIII
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Table of Figures
No Figures
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc IX
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
A.1.SSRD Overview
This document is the Software and System Requirements Definition (SSRD) for the Intelligent CodeCount Superstructure project developed by Team 16. This document identifies the project, functional, system interface, and level of service requirements for the Intelligent CodeCount Superstructure project. This document will be used to help create a common understanding of the system between the clients and developers, and identify system boundaries. The success critical stakeholders include the customer, end users, developers of both the superstructure and key interfaces, as well as the maintainers. The primary client acting as liaison for the customer is A. Winsor Brown, Assistant Director for CSE, USC.
A.1.1 Status of the SSRD
The following significant differences exist between the Easy Win-Win negotiated agreements and the SSRD: 1. W3 specifies that, "Combining multiple file CodeCount outputs, such as those from all new lines, changed lines and deleted lines, into a single meaningful output". This is no longer valid since new and deleted code is not counted. (Client Meeting Minutes dated 10/10/2005) 2. W5 specifies that, "The system shall provide the user with the ability to specify a threshold for string distance to determine modified verses new". This is no longer valid since there is no need for a string distance algorithm. All code category decisions are 100% deterministic now since they are based on the map file. (Client Meeting Minutes dated 10/10/2005)
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
1
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
A.1.2 References
[1] LeanMBASE Guidelines v1.4. (http://greenbay.usc.edu/csci577/fall2005/site/ guidelines/LeanMBASE_Guidelines_V1.4.pdf) [2] Project Team Website. (http://greenbay.usc.edu/csci577/fall2005/projects/team16/index.html) [3] Client Meeting Minutes. (http://greenbay.usc.edu/csci577/fall2005/projects/team16/files.php? path=CMN/) [4] The Intelligent CodeCount Superstructure Operational Concept Description. (http://greenbay.usc.edu/csci577/fall2005/projects/team16/LCA/OCD_LCA_F 05a_T16__V02.00.doc) [5] Intelligent CodeCount Superstructure System and Software Architecture Document. (http://greenbay.usc.edu/csci577/fall2005/projects/team16/LCO/SSAD_LCO_ F05a_T16__V02.10.pdf) [6] The CodeCount Tools Software. (http://sunset.usc.edu/research/CODECOUNT/index.html) [7] The COCOMO Suite Software. (http://sunset.usc.edu/research/cocomosuite/suite_main.html) [8] The Center for Software Engineering (CSE). (http://sunset.usc.edu/cse/index.html) [9] Easy Win-Win Report (EWW). (http://greenbay.usc.edu/csci577/fall2005/projects/team16/LCO/EWW_LCO_ F05a_T16_V01.01.doc) [10] Initial Prototyping Results (IPR). (http://greenbay.usc.edu/csci577/fall2005/projects/team16/LCO/Prototypes/L CO_PROTOTYPE_F05a_T16__V01.04.pdf)
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
2
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
2. Project Requirements
2.1 Budget and Schedule
Table 1: PR-1 (24-Week Schedule)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-1: 24-Week Schedule (Two 12-Week Development Periods) The development schedule for the project shall not exceed 24 weeks, comprised of two 12-week periods coinciding with the CSCI 577a and 577b semesters. M N/A
Table 2: PR-2 (Development Cost)
Project Requirement: Description:
PR-2: Development Cost The development cost shall only be the efforts put in by stakeholders, in terms of time. There are five developers working an average of 12 hours per week, and a client devoting an average of 3 hours per week to the effort, effectively producing a total development cost of 1500 hours. In addition to these hours IV&V members will spend 240 hours reviewing documents for consistency and correctness. M N/A
Priority: Win-Win Agreement(s):
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
3
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
2.2 Development Requirements
2.2.1 Tools Requirements
Table 3: PR-3 (Easy Win-Win Tool Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-3: Easy Win-Win Tool Use The Success Critical Stakeholders shall use the Easy Win-Win Collaboration Tool For Requirement Negotiations. M N/A
Table 4: PR-4 (DART Tool Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-4: DART Tool Use The Developers shall use DART for risk tracking, prioritization, and management. M N/A
Table 5: PR-5 (Rational Rose Tool Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-5: Rational Rose Tool Use The Developers shall use Rational Rose for analysis and design support software. M N/A
Table 6: PR-6 (MS Project Tool Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-6: MS Project Tool Use The Developers shall use MS Project for project scheduling, and management. M N/A
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
4
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Table 7: PR-7 (Microsoft Word Document Format Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-7: Microsoft Word Document Format Use The Developers shall use the Microsoft Word format (.doc) for documentation of development software. M N/A
Table 8: PR-8 (Adobe Portable Document Format Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-8: Adobe Portable Document Format Use The Developers shall use the Adobe Portable Document format (.pdf) for documentation publishing software. M N/A
Table 9: PR-9 (iCard and Effort Reporting Tool Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-9: iCard and Effort Reporting Tool Use The Developers shall use iCard and the Effort Reporting Tool to log and track effort. M N/A
Table 10: PR-10 (ANSI C++ Compiler Tool Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-10: ANSI C++ Compiler Tool Use The Developers shall use an ANSI C++ compliant compiler such as g+ + for all software development. M N/A
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
5
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
2.2.2 Language Requirements
Table 11: PR-11 (C++ Language Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-11: C++ Language Use The developers shall implement the system using portable ANSI C++. M W14: "Implementation language must be ANSI C++." W16: "The system shall be portable across platforms (ANSI C+ +), and no special O/S specific system calls (L.O.S. Requirement)."
Table 12: PR-12 (UML Language Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-12: UML Language Use The developers shall use UML 1.0 for all analysis and design models. M N/A
2.2.3 Computer Hardware Requirements
Table 13: PR-13 (Hardware Platform Independence)
Project Requirement: Description: Priority: Win-Win Agreement(s): .
PR-14: Hardware Platform Independence The system shall be platform independent with respect to hardware. M See Client Meeting Minutes dated 10/10/2005.
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
6
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
2.2.4 Computer Software Requirements
Table 14: PR-14 (CodeCount Software Use)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-15: CodeCount Software Use The developers shall use CodeCount Tools software to count SLOC for source files. M CodeCount is used to determine the number of logical and physical SLOC for each module so that this ratio can be used to convert physical SLOC to logical SLOC for specific categories of code that appear in each module. See Client Meeting Minutes dated 10/10/2005.
2.2.5 Computer Communication Requirements
There are no computer communication related requirements, as the system does not communicate with any remote resources.
2.3 Deployment Requirements
Table 15: PR-15 (User Ability Assumption)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-16: User Ability Assumption The users shall possess the technical ability to compile and run the Intelligent CodeCount Superstructure source code. M Software distributed by the USC CSE is done so in source code form.
2.4 Transition Requirements
Table 16: PR-16 (Provided Instructional Documentation)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-17: Provided Instructional Documentation The developers shall provide a user's manual detailing the usage of the installation and successful execution of the software. M Lifecycle Plan
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
7
Version Date: 11/21/05
System and Software Requirements Definition (SSRD) Table 17: PR-17 (Provide Application Overview)
Version 2.00
Project Requirement: Description:
PR-17: Provide Application Overview The developers shall provide a one-page overview of the product, aimed at the maintainers. The document shall detail the product's purpose, history, explanation of notable modules, and test cases and the pertinent data to execute them. M Client Meeting Minutes dated 11/21/05
Priority: Win-Win Agreement(s):
2.5 Support Environment Requirements
Table 18: PR-18 (CS 599 Graduate Student Maintenance)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-18: CS 599 Graduate Student Maintenance The software shall be maintained by USC graduate students in return for directed research credit. Many USC-SCE applications are maintained for directed research credit by CS 599 students. M The USC CSE maintains the tools it makes available to its affiliates and to the general public, often granting graduate students "directed research" credit for their services.
Table 19: PR-19 (Maintainer Skill Level)
Project Requirement: Description: Priority: Win-Win Agreement(s):
PR-18: Maintainer Skill Level The system maintainers shall possess a level of C programming knowledge sufficient to successfully maintain the software, as judged by a CS 599 professor. M The USC CSE maintains the tools it makes available to its affiliates and to the general public, often granting graduate students "directed research" credit for their services.
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
8
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
3. Capability (Functional/Product) Requirements
Table 20: CR-1 (Level 1 Intelligent Counting Capability)
Capability Requirement: Priority: Description:
CR-1: Level 1 Intelligent Counting Capability
M The system shall count in units of physical SLOC on a per module basis the carried code with no changes, carried with changes, and new code via the use of a re-factoring map. Input(s): file-list-1 containing list of files for file-set-1 file-list-2 containing list of files for file-set-2 file-set-1 files file-set-2 files re-factoring map file that maps code blocks from file-set-1 to file-set-2 Source(s): End user composes file-list-1 End user composes file-list-2 End user creates re-factoring map (details specified in Initial Prototyping Results) Internal Output(s): physical SLOC counter for code that is carried with no changes Internal physical SLOC counter for code that is carried with changes Destination(s): Internal Working Memory Precondition(s): file-set-1 and file-set-2 are two versions of the same project file-set-1 and file-set-2 are available at the locations specified in the respective list files re-factoring map file correlates changes between file-set-1 and file-set-2 Post file-list-1 and file-list-2 will be unmodified condition(s): file-set-1 and file-set-2 will be unmodified re-factoring map will be unmodified A set of internal counters (one set per module) that corresponds to each code category specified in the description above will have the correct physical SLOC count for the specified category based upon the information in the re-factoring map
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc
9
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Win-Win Agreement(s):
The categories of code to be counted on a per module basis are carried with no changes, Carried with changes, Reused with no changes, and Reused with changes. See Client Meeting Minutes dated 10/10/2005. W4: "Use a human generated table to find re-factored code. Assuming human re-factor table input file is 100% correct then all lines should be accounted for as either moved, or moved and modified."
Table 21: CR-2 (Level 2 Intelligent Counting Capability)
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc 10
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Capability Requirement: Priority: Description:
CR-2: Level 2 Intelligent Counting Capability
M The system shall count in units of physical SLOC on a per module basis the Reuse Code with no changes and Reuse Code with changes via the use of a re-factoring map. Input(s): file-list-1 containing list of files for file-set-1 file-list-2 containing list of files for file-set-2 file-set-1 files file-set-2 files re-factoring map file that maps code blocks from file-set-1 to file-set-2 Source(s): End user composes file-list-1 End user composes file-list-2 End user creates re-factoring map (details specified in Initial Prototyping Results) Output(s): Internal physical SLOC counter for code that is reused with no changes Internal physical SLOC counter for code that is reused with changes Destination(s): Internal Working Memory Precondition(s): file-set-1 and file-set-2 are two versions of the same project file-set-1 and file-set-2 are available at the locations specified in the respective list files re-factoring map file correlates changes between file-set-1 and file-set-2 Post file-list-1 and file-list-2 will be unmodified condition(s): file-set-1 and file-set-2 will be unmodified re-factoring map will be unmodified A set of internal counters (one set per module) that corresponds to each code category specified in the description above will have the correct physical SLOC count for the specified category based upon the information in the re-factoring map Win-Win The categories of code to be counted on a per module basis are Agreement(s): carried with no changes, Carried with changes, Reused with no changes, and Reused with changes. See Client Meeting Minutes dated 10/10/2005. W4: "Use a human generated table to find re-factored code. Assuming human re-factor table input file is 100% correct then all lines should be accounted for as either moved, or moved and modified."
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc 11
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Table 22: CR-3 (CodeCount Conversion Factors)
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc 12
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Capability Win-Win Requirement: Agreement(s): Priority: Description: Input(s):
Source(s): Output(s):
CodeCount is used to determine the number of logical and CR-3: CodeCount Conversion Factors physical SLOC for each module so that this ratio can be used to M convert physical SLOC to logical SLOC for specific categories of The system appear in eachphysical and logical SLOC counts using code that shall count module. CodeCountClient Meeting Minutes dated 10/10/2005. See and determine the logical SLOC to physical SLOC ratios on a per mapped module basis. file-list-2 containing list of files for file-set-2 file-set-2 files Internal physical SLOC counts for code that is carried with no changes Internal physical SLOC counts for code that is carried with changes Internal physical SLOC counts for code that is reused with no changes Internal physical SLOC counts for code that is reused with changes End user composes file-list-2
Internal logical SLOC counts for code that is carried with no changes Internal logical SLOC counts for code that is carried with changes Internal logical SLOC counts for code that is reused with no changes Internal logical SLOC counts for code that is reused with changes Destination(s): Internal Working Memory Precondition(s): file-set-2 is available at the location specified in the respective list file CodeCount Tool is installed and accessible via OS provided TRAP instruction such as exec. A set of internal counters (one set per module) that corresponds to each code category specified in the descriptions for CR-1 and CR-2 above will have the correct physical SLOC count for the specified category based upon the information in the re-factoring map. Post file-list-2 will be unmodified condition(s): file-set-2 will be unmodified A set of internal counters (one set per module) that corresponds to each code category specified in the descriptions for CR-1 and CR-2 above will have the correct logical SLOC count for the specified category based upon the information supplied from executing CodeCount on file-set-2.
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc 13
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Table 23: CR-4 (Re-factor Map Driven Validation)
Capability Requirement: Priority: Description:
CR-4: Re-factor Map Driven Validation
M The system shall validate re-factor map entries for code blocks against actual code blocks for each code category specified in CR1 and CR-2 Input(s): file-list-1 containing list of files for file-set-1 file-list-2 containing list of files for file-set-2 file-set-1 files file-set-2 files re-factoring map file that maps code blocks from file-set-1 to file-set-2 Source(s): End user composes file-list-1 End user composes file-list-2 End user creates re-factoring map (details specified in Initial Prototyping Results) Output(s): Error Message: "rf-n Code Block State Error: Mapped state-x Actual state-y" Where n is the re-factor map entry number, and state-x is the state specified in the re-factor map entry, and state-y is the actual state determined by the software Destination(s): Command Line Precondition(s): file-set-1 and file-set-2 are two versions of the same project file-set-1 and file-set-2 are available at the locations specified in the respective list files re-factoring map file correlates changes between file-set-1 and file-set-2 Post If an error occurs, an error message is displayed to the user condition(s): The code block is counted according to the state (modified, not modified, new) determined by the system Win-Win W7: "Identify potential sources of double counting and explain Agreement(s): how they are avoided" W17: "The system shall treat any re-factored code block that has a single difference between the originating block as a modified refactored block of code." The re-factor map will be validated and error messages will be displayed notifying the user of incorrect entries. See Client Meeting Minutes dated 10/10/2005.
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc 14
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Table 24: CR-5 (No Double-Counting)
Capability Requirement: Priority: Description:
CR-6: No Double-Counting
M The system shall count each unique code block exactly once with respect to code category: carried with no change, carried with change, reuse code with no change, and reuse code with change. Input(s): A code block from a source file from file-set-1 files A code block from a destination file from file-set-2 files A re-factoring map entry from the re-factoring map file that specifies the source code block and its associated destination code block Source(s): End user creates re-factoring map (details specified in Initial Prototyping Results) Output(s): Internal logical SLOC counters for code that is carried with no changes Internal logical SLOC counters for code that is carried with changes Internal logical SLOC counters for code that is reused with no changes Internal logical SLOC counters for code that is reused with changes Destination(s): Internal Working Memory Precondition(s): Two associated code blocks have been isolated using a refactoring entry that specifies each code block The source code block is isolated from a source file The destination code block is isolated from a destination file Post Each unique code block will have been counted once and only once and condition(s): categorized into one of the taxonomies outlined in the description. Win-Win W7: "Identify potential sources and double-counting and explain how Agreement(s): they are avoided."
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc 15
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
Table 25: CR-6 (Cost Estimation Metrics Report File)
Capability Requirement: Priority: Description:
CR-7: Cost Estimation Metrics Report File
M The system shall produce a single output file containing a consolidated listing of metrics per module for each code category specified in CR-1 and CR-2 Input(s): file-list-1 containing list of files for file-set-1 file-list-2 containing list of files for file-set-2 file-set-1 files file-set-2 files re-factoring map file that maps code blocks from file-set-1 to file-set-2 Source(s): End user composes file-list-1 End user composes file-list-2 End user creates re-factoring map (details specified in Initial Prototyping Results) Output(s): report-file containing metrics organized by module (details specified in Initial Prototyping Results) Destination(s): Current Working Directory Precondition(s): file-set-1 and file-set-2 are two versions of the same project file-set-1 and file-set-2 are available at the locations specified in the respective list files re-factoring map file correlates changes between file-set-1 and file-set-2 Post The software application will terminate condition(s): The current working directory will contain a report file containing SLOC metrics, and the %CM parameter for the associated module for COCOMO II's Reuse/Adaptive Code dialogue box file-list-1 and file-list-2 will be unmodified file-set-1 and file-set-2 will be unmodified re-factoring map will be unmodified Win-Win COCOMO II metrics will be output that are relevant to Agreement(s): Reuse/Adaptive Code parameters used by COCOMO II for cost/schedule estimation. See Client Meeting Minutes dated 10/10/2005. W6: "Provide a map of the categories of counted code to the categories of COCOMO's reuse model"
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc 16
Version Date: 11/21/05
System and Software Requirements Definition (SSRD) Table 26: CR-7 (User-Defined Bins)
Version 2.00
Capability Requirement: Priority: Description:
CR-8: User-Defined Bins
M The system shall be able to provide all of its usual metrics, but with reference to specific blocks of code, as defined by the user. Input(s): A code block from a source file from file-set-1 files A code block from a destination file from file-set-2 files A re-factoring map entry from the re-factoring map file that specifies the source code block and its associated destination code block, as well as an integer value representing the user-defined "bin" Source(s): End user creates re-factoring map (details specified in Initial Prototyping Results) Output(s): All of the following categories of code are provided for the useridentified blocks of code Internal logical SLOC counters for code that is carried with no changes Internal logical SLOC counters for code that is carried with changes Internal logical SLOC counters for code that is reused with no changes Internal logical SLOC counters for code that is reused with changes Destination(s): Internal Working Memory Precondition(s): Two associated code blocks have been isolated using a refactoring entry that specifies each code block The source code block is isolated from a source file The destination code block is isolated from a destination file Post Each unique code block will have been counted once and only once and condition(s): categorized into one of the taxonomies outlined in the description. Win-Win COCOMO II metrics will be output that are relevant to Agreement(s): Reuse/Adaptive Code parameters used by COCOMO II for cost/schedule estimation. See Client Meeting Minutes dated 10/10/2005. W6: "Provide a map of the categories of counted code to the categories of COCOMO's reuse model"
b4b2c3efa4bfb7b6ba52c275e809a8cdd621f779.doc 17
Version Date: 11/21/05
System and Software Requirements Definition (SSRD)
Version 2.00
A.2.4. System Interface Requirements
4.1 User Interface Standards Requirements
Table 27: SIR-1...