![[Services Banner Image]](images/hservs.gif){kind=small}
| S-MATRIX | THE NEXT GENERATION SYSTEMS |
| Technology Consulting, Contracting, Systems Integration, Project Management, Research and Development (R&D) | |
Home | Contents | Products & Services | News | Feedback | Search | References |
|
Instrumentation Systems | Multi-User Computer Systems | Efficient Energy Use Systems |
|
| Avionics Test Bench | Instrumentation Systems Documentation | Software Documentation | |
The foundation for all of our projects is a Systems Requirements Specifications (SRS) Document. See Reference 3 for a sample "Software Requirements Specifications Document - Table of Contents". This document is jointly created and maintained with our clients. It is a consolidation of all of our experiences. It is a project template and checklist. It insures that every issue and every task is addressed and that every project is a success.
Our first task in any project is to complete enough of the SRS document to help us determine if there is an existing solution that will cost effectively meet a client's needs. If there is such a solution, our objective will be to implement and adapt that solution. If not, we will develop a solution. In either case, the roadmap for the project is the SRS document.
In the SRS Introduction, we identify and describe the product(s) to be produced. We include a description of the application and the software capabilities, including relevant benefits and objectives.
In the SRS General Description, we identify the general factors that affect the product and its requirements. We put the product in perspective with other related products or projects. We summarize the software functions in layperson terms. We describe the eventual users, including their experience and technical expertise. We describe any constraints, such as regulatory policies, hardware limitations, interfaces to other applications, audit functions, control functions, language requirements, communication protocols, criticality of the application, safety issues and security issues which may affect the development options.
In the SRS Specific Requirements section, we describe the functional requirements of the hardware and the software. This includes the computer system components and configuration, operating systems, connections, peripherals, software development environments, languages and tools. We identify the input data, processing and output data for all software functions. We describe the external user, hardware, software and communications interface requirements. We specify all the performance parameters of the software and the users in quantifiable terms. We identify standards compliance and hardware limitations. We compile a system attributes list which includes acceptable system downtime, security restrictions, maintainability methods and portability standards. Other requirements include database, operational modes and site adaptation.
In the SRS Project Management section, we define the plan, organization, and management of tasks and resources to accomplish the defined software objectives within acceptable time and budget constraints. The project is divided into manageable tasks which are scheduled and then tracked as work progresses. Project information is communicated simply and efficiently on an ongoing basis to all participants including clients, management and staff. Project Management can be thought of simply as a disciplined set of procedures to provide answers to the following questions:
What job or project is to be done?
Who and what will be used to perform the tasks to complete the project?
When must the project be completed by and where?
How much will the project cost?
What happens if the project is not completed on time and budget?
In the SRS Capabilities section, we define the resources to be used on the project including personnel and experience, facilities and equipment.
In the SRS Maintenance and Support section, we deal with the issues of ongoing technical assistance and support, system self-tests and maintenance tests, documentation, training and warranties.
And finally in the SRS Quality Standards section, we deal with the issues which tie everything together and which make the difference between a good project and a great project. Quality must be built in to the product by all of the team members. Quality is an ongoing process. The focus of all projects must be user needs and expectations, and not just system requirements specifications lists. Project quality is a blend of product quality and process quality.
Generic product quality characteristics which must be considered are:
Generic process quality characteristics which must be considered are:
Error detection and remedy is particularly important throughout the project. The cost of fixing flaws escalates substantially as the project progresses.
S-MATRIX Quality Standards are a proprietary composite of all standards and experience, and represent an effective blend of product and process quality which is determined primarily by customer needs.
Software operating systems:
At S-MATRIX, "Client Satisfaction is SRS #1"
For any Comments, Suggestions or Requests for Information, please use the Contact Information at the bottom of all S-MATRIX web pages or the convenient
Feedback Form on the Feedback web page
Home | Contents | Products & Services | News | Feedback | Search | References
Instrumentation Systems | Multi-User Computer Systems | Efficient Energy Use Systems
Avionics Test Bench | Instrumentation Systems Documentation | Software Documentation
|
S-Matrix Enterprises Inc #7-9 550 Beatty St Vancouver, BC Canada V6B 2L3 |
Web: www.smatrixgroup.com |
Phone:
1-604-669-4310 Fax: 1-604-669-4311 Email: info@smatrixgroup.com |
| S-MATRIX | THE NEXT GENERATION SYSTEMS | |