SAS 1-4 and 6, now with unfucked spacing

sas.txt

1. Introduction
The purpose of this document is to describe and clearly define the creation process of Project BOLO. It will give a clear timeline for the development and release of each deliverable, and inform the client about the requirements of the project.

2. Scope  
2.1 Identification
System Analysis Specification
SAS-001
Revision 1
November 18, 2013

2.2. Bounds
The product being described in this SRS is BOLO, short for “Bugs Only Live Once”. This software will continuously run on an integration server, and will allow developers to define a set of actions to perform against an external test server and describe the expected results. BOLO will continuously perform these actions and alert the developers if any failed, thus detecting functionality regression before the regression is pushed to a production server. BOLO will not be responsible for updating the external test server. 

2.3. Objectives
This project will be treated as a medium priority project. It will be developed using an incremental life cycle, and using the agile methodology. The initial milestone delivery dates are listed below.

//patrick this shit is a table
Deliverable Product	Estimated Date of Delivery
Project Proposal	9/25
Software Requirements Specification (SRS)	10/23
Software Project Management Plan (SPMP)	11/6
Software Analysis Specification (SAS)	11/18
Software Design Document (SDD)	12/2

2.4. System Overview
The system to be produced is a continuously running server that allows developers to define both a set of actions to perform and certain criteria for the expected results of these actions. It them performs these actions constantly against an intermediate deployment environment and compares their results to the expected results. In this way, functionality regression could be detected before code made it to production.

2.5. Document Overview
//patrick these should be bulleted or a list or something
Business Requirements: Which goals the software is being designed to achieve
Logical Architectural Specification: The workings of the software
Non-Functional/Operational Specifications: Requirements for the project that don't directly relate to its structure
System Test Plan Requirements: The test plans, with scenario testing and required simulators
Qualification Provisions: How quality assurance will be performed on the project
Requirements Traceability: This section describes how requirements will be met throughout the construction of the product.
Rationale
Notes
Appendices

3. Reference Documents
//patrick these look just like in the SPMP
Project Proposal
Version	2
Date	25 September, 2013
Software Requirements Specification (SRS)
Version	2
Date	25 October, 2013
Software Project Management Plan (SPMP)
Version 1
Date	9 November, 2013

4. Business Requirements
4.1. Technology
The purpose of BOLO is to help streamline the development process of the division’s developers. BOLO will improve the quality of the existing product and reduce development time by detecting regressions in functionality much earlier in the development cycle.

4.2. Economics
The main product being produced by the division was originally conceived as being contracted to external sources. Upon the realization that it could be produced by a specialized team in-house at a fraction of the cost, the project was handed to the division. Since the goal is to stay far below the original projected cost, BOLO is being developed for the purpose of reducing the billable man-hours required to test the main product.

4.3. Regulatory and Legal
This project has no regulatory or legal drivers.

4.4. Market Considerations
This project is specifically being targeted towards the developers of the Division of Operations, Technical, and Support Services at New York University.

4.5. Risks and Alternatives
One risk is that BOLO reports incorrectly. In such a case instead of saving the developers time, it will instead waste it as now the developers must not only verify the bugs for themselves, but also dig through BOLO to see if the problems are with BOLO itself or with the scenario descriptions given to it for testing purposes.
Another risk is that one of the developers of BOLO may leave the team; this is, however, not a major problem  as the division has other skilled developers that can be moved to work on BOLO.  Since we are using an incremental update process, this will not have significant impact on the update cycle.

4.6. Human Resources and Training
All members of the team are already trained and adept in the various technological requirements required. The team will continue to be paid by the division by which they are employed, and will have access to division resources including servers and workstations.

6. Non-Functional/Operational Specifications
6.1. System External Interface Requirements
The system must be accessible, user-friendly, and allow users to fully specify tests.

6.2. Safety Requirements
N/A

6.3. Security and Privacy Requirements
N/A

6.4. System Environment Requirements
M/A

6.5. Computer Resource Requirements
6.5.1. Computer Hardware Requirements
N/A

6.5.2. Computer Hardware Resource Requirements
N/A

6.5.3. Computer Software Requirements
The software must be written in C++.
The software must run on a Linux-based operating system.

6.5.4. Computer Communications Requirements
The system must have constant access to whichever external product is being tested.

6.6. System Quality Factors
The product must be easily usable by software developers.

6.7. Design and Construction Constraints
The software's development team will use an iterative life cycle model.
The development team must follow C++ coding standards and best programming practices.

6.8. Personnel-Related Requirements
N/A

6.9. Training-Related Requirements
N/A

6.10. Logistics-Related Requirements
N/A

6.11. Packaging Requirements
N/A

6.12. Precedence and Criticality Requirements
N/A

6.13. Other Requirements
N/A