The document provides an overview of how to write a Software Requirements Specification, including describing the purpose and scope of the system, constraints and assumptions, functional requirements for different user classes, and recommendations for including UML diagrams to further specify requirements. Sections should define the intended audience, what the software will and won't do, and factors limiting developer options, with functional requirements organized by user class and use cases.

1. Practical Apps in SWI

3. SRS

4. SRS

5. ● 1. Introduction
The following subsections of the Software Requirements Specifications (SRS) document should provide an overview of the
entire SRS. The thing to keep in mind as you write this document is that you are telling what the system must do – so that
designers can ultimately build it. Do not use this document for design!!!
– 1.1 Purpose
Identify the purpose of this SRS and its intended audience. In this subsection, describe the purpose of the particular SRS
and specify the intended audience for the SRS.
– 1.2 Scope
In this subsection:
Identify the software product(s) to be produced by name
Explain what the software product(s) will, and, if necessary, will not do
Describe the application of the software being specified, including relevant benefits, objectives, and goals
Be consistent with similar statements in higher-level specifications if they exist
This should be an executive-level summary. Do not enumerate the whole requirements list here.

7. – Overview
In this subsection:
Describe what the rest of the SRS contains
Explain how the SRS is organized
Don’t rehash the table of contents here. Point people to the parts of the document they are most concerned with.
Customers/potential users care about section 2, developers care about section 3.
– Constraints
Provide a general description of any other items that will limit the developer's options. These can include:
(1) Regulatory policies
(2) Hardware limitations (for example, signal timing requirements)
(3) Interface to other applications
(4) Higher-order language requirements
Signal handshake protocols (for example, XON-XOFF, ACK-NACK) A simple handshaking protocol might only involve
the receiver sending a message meaning "I received your last message and I am ready for you to send me another
one." A more complex handshaking protocol might allow the sender to ask the receiver if he is ready to receive or
for the receiver to reply with a negative acknowledgement meaning "I did not receive your last message correctly,
please resend it.
Reliability requirements
(5) Criticality of the application
(6) Safety and security considerations This section captures non-functional requirements in the
customers language.

10. – Assumptions and Dependencies
List each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but
are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption might be that a specific
operating system would be available on the hardware designated for the software product. If, in fact, the operating system were not
available, the SRS would then have to change accordingly.
This section is catch-all for everything else that might influence the design of the system and that did not fit in any of the categories
above.
3.2 Functional requirements
This section includes the requirements that specify all the fundamental actions of the software system.
3.2.1 User Class 1 - The User
3.2.1.1 Functional requirement 1.1
ID: FR1
TITLE: Download mobile application
DESC: A user should be able to download the mobile application through either an application store or similar service on the mobile
phone. The application should be free to download.
RAT: In order for a user to download the mobile application.
DEP: None
3.2.1.2 Functional requirement 1.2
ID: FR2
TITLE: Download and notify users of new releases
DESC: When a new/updated version or release of the software is released, the user should check for these manually. The download
of the new release should be done through the mobile phone in the same way as downloading the mobile application.
RAT: In order for a user to download a new/updated release.
DEP: FR1

11. UML Diagrams
● Use case diagrams
● Activity Diagrams
● Sequence diagrams
● Class Diagrams
● Object Diagram
● https://www.gliffy.com
● Star UML http://staruml.io/download
● Visual Paradigm for UML
● Software Ideas Modeler

12. Use Case
The purposes of use case diagrams can be as follows:
– Used to gather requirements of a system.
– Used to get an outside view of a system.
– Identify external and internal factors influencing the system.
– Show the interacting among the requirements are actors.
● Actors
● Functional requirements
● Relationships among the use cases and actors.

17. Use Case Scenario

18. Task
● Draw a use case diagram for your project idea

23. Task
● Draw an activity diagram for your project idea