1. SYSTEM ANALYSIS AND DESIGN

2. SOFTWARE SPECIFICATIONS AND REQUIREMENT ANALYSIS :

3. Software Specification: A document that describes what the software will do (e.g., how it works, what the screens look like, what happens when a button is clicked, etc.) Generally this is the first step of software programming. Software Requirement Specification: A software requirements specification (SRS) is a comprehensive description of the intended purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform.

4. Introduction to SRS: An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost. A good SRS defines how an application will interact with system hardware, other programs and human users in a wide variety of real-world situations. Parameters such as operating speed, response time, availability, portability, maintainability, footprint, security and speed of recovery from adverse events are evaluated.

5. Requirements Analysis: Part-I
What is it?
The process by which customer needs are understood and documented.
Expresses “what” is to be built and NOT “how” it is to be built.
Customer wants and needs; expressed in language understood by the customer.
For the developers; may be more formal

6. Requirements Analysis: Part-II
Why document requirements?
Serves as a contract between the customer and the developer.
Serves as a source of test plans.
Serves to specify project goals and plan development cycles and increments

7. Requirements Analysis: Part-III
Identify the customer.
Interview customer representatives.
Review with customer, and update when necessary.

8. SRS’s components:
Functional requirements: A function of a SW-system or its component. Include a set of use case that describe all of d’interactions that the users will have with d’SW
Nonfunctional requirements: Requirements which impose contraints on the design or implementation (such as performance req., quality standards, or design constraints)
Doesn’t offer design suggestions, possible solution to tech or business issues, or any other information

9. The Goals of SRS:
It provides feedback to the customer. SRS is customer's assurance that development organization understands issues or problems to be solved and behavior necessary to address those problems and written in natural language.
It decomposes problem into component parts.
It serves as a product validation check. SRS serves as parent document for testing n validation strategies that will be applied to requirements for verification.

10. Information should an SRS include:
Interface
Functional capabilities
Performance level
Data structures/elements
Safety
Reliability
Security/privacy
Quality
Constraints and limitations

11. Characteristics of a quality SRS:
Complete: SRS defines precisely all the go-life situations that will be encountered n the system’s capability to address them.
Consistent: SRS capability functions n performance level r compatible, n the features don’t negate those capability functions.
Accurate: SRS precisely defines the system’ capability in a real-world environment.
Modifiable: the logical, hirarchical structure of SRS should facilitate any necessary modifiable as per need of the user.
Ranked: individual requirement of SRS are hierarchically arranged according to stability, security, perceived ease/difficulty of implementation, or other parameters that help in design.

12. Testable: SRS must be stated in such a manner that unambiguous
assessment criteria.
Traceable: Each requirement in SRS must be uniquely identified to a
source (use case, gov reg, industry standard, etc)
Unambiguous: SRS must contain requirement statement that can be
interpreted in one way only.
Valid: All parties n project participants can understand, analyze, accept, or approve the SRS
Verifiable: SRS is consistent from 1 level of abstraction to another