Sorry interview coming up in two days, request to please help me in these questions
1. Difference between System requirements specification and Software requirements specification document?
I browsed the net i found this as the correct which i can explain clearly. Is this the correct explanation?
"If the system under design contains multiple components, you will likely have a System Requirements Specification. The system would be decomposed and each piece would have a requirements specification. A software component to the system would have a Software Requirements Specification. Of course, if your system is only software, then you may only have a Software Requirements Specification."
I will get the Requirements Specification from the customer from that i have to create the System Requirement specification. Whether this System requirement specification will be for the customer or the developer? Do i need to create two different documents?
2. What is Control system requirement document, Control software architecture?
3. Application level SW element requirement document , Application level SW architecture?
4. Low level/Base SW element requirement document, Low level/Base SW architecture?
5. Hardware design description document? Will it come under the software domain or hardware domain? What it should contain?
This is basically based on micro controllers in automotive domain and it has so many standards like AUTOSAR etc.
I realize this isn't going to be very helpful but since the post is relatively old, I doubt OP still needs a relevant answer.
This is what I imagine wicked software development professionals are made to do for eternity when they die and go to software development hell. I have seen some of the kinds of development processes that require you to create documents like those described by these questions. I wish OP all the best in finding his way out of whatever soul-crushing environment he seems to have tried so hard to get into.
A System Requirements Specification (SRS) (also known as a Software Requirements Specification) is a document or set of documentation that describes the features and behavior of a system or software application. It includes a variety of elements (see below) that attempts to define the intended functionality required by the customer to satisfy their different users.
Depending on the methodology employed (agile vs waterfall) the level of formality and detail in the SRS will vary, but in general an SRS should include a description of the functional requirements, system requirements, technical requirements, constraints, assumptions and acceptance criteria. Each of these is described in more detail below:
Business Drivers - This section describes the reasons why the customer is looking to build the system. The rationale for the new system is important as it will guide the decisions made by the business analysts, system architects and developers. Another compelling reason for documenting the business rationale behind the system is that the customer may change personnel during the project. Documentation which clearly identifies the business reasons for the system will help sustain support for a project if the original sponsor moves on.The drivers may include both problems (reasons why the current systems/processes are not sufficient) and opportunities (new business models that the system will make available). Usually a combination of problems and opportunities are needed to provide motivation for a new system.
Business Model - This section describes the underlying business model of the customer that the system will need to support. This includes such items as the organizational context, current-state and future-state diagrams, business context, key business functions and process flow diagrams. This section is usually created during the functional analysis phase.
Functional and System Requirements - This section usually consists of a hierarchical organization of requirements, with the business/functional requirements at the highest-level and the detailed system requirements listed as their child items. Generally the requirements are written as statements such as "System needs the ability to do x" with supporting detail and information included as necessary.
Business and System Use Cases - This section usually consists of a UML use case diagram that illustrates the main external entities that will be interacting with the system together with the different use cases (objectives) that they will need to carry out. For each use-case there will be formal definition of the steps that need to be carried out to perform the business objective, together with any necessary pre-conditions and post-conditions. The business use cases are usually derived from the functional requirements and the system use cases are usually derived from the system requirements.
Technical Requirements - This section is used to list any of the "non-functional" requirements that essentially embody the technical environment that the product needs to operate in, and include the technical constraints that it needs to operate under. These technical requirements are critical in determining how the higher-level functional requirements will get decomposed into the more specific system requirements.
System Qualities - This section is used to describe the "non-functional" requirements that define the "quality" of the system. These items are often known as the "-ilities" because most of them end in "ility". They included such items as: reliability, availability, serviceability, security, scalability, maintainability. Unlike the functional requirements (which are usually narrative in form), the system qualities usually consist of tables of specific metrics that the system must meet to be accepted.
Constraints and Assumptions - This section will outline any design constraints that have been imposed on the design of the system by the customer, thereby removing certain options from being considered by the developers. Also this section will contain any assumptions that have been made by the requirements engineering team when gathering and analyzing the requirements. If any of the assumptions are found to be false, the system requirements specification would need to be re-evaluated to make sure that the documented requirements are still valid.
Acceptance Criteria - This section will describe the criteria by which the customer will "sign-off" on the final system. Depending on the methodology, this may happen at the end of the testing and quality assurance phase, or in an agile methodology, at the end of each iteration. The criteria will usually refer to the need to complete all user acceptance tests and the rectification of all defects/bugs that meet a pre-determined priority or severity threshold.
I am working as a System Admin having an experience of 5+ yrs in Hardware and Networking field.Also work as Career Counsellor
Please always say where such content comes from. If you have simply copied somebody else's website, it would be better to link to that website, otherwise there could be problems about copyright and plagiarism.