Software Requirement Specifications

• Software Requirements Specifications (SRS) (also

called a requirements document). This report lays
a foundation for software engineering activities
and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which
acts as a representation of software that enables
the customers to review whether it (SRS) is
according to their requirements. Also, it comprises
user requirements for a system as well as detailed
specifications of the system requirements.
First, the SRS could be written by the client of a system. Second, the SRS could be
written by a developer of the system. The two methods create various situations
and establish different purposes for the document altogether. The first case, SRS, is
used to define the needs and expectation of the users. The second case, SRS, is
written for various purposes and serves as a contract document between customer
and developer.
• Properties of a good SRS document
The essential properties of a good SRS document are the following:
1. Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
decrease readability and also increase error possibilities.
2. Structured: It should be well-structured. A well-structured document is simple
to understand and modify. In practice, the SRS document undergoes several
revisions to cope up with the user requirements. Often, user requirements
evolve over a period of time. Therefore, to make the modifications to the SRS
document easy, it is vital to make the report well-structured.
3. Black-box view: It should only define what the system should do and refrain
from stating how to do these. This means that the SRS document should define
the external behavior of the system and not discuss the implementation issues.
• Verifiable: All requirements of the system, as documented in the SRS document,
should be correct. This means that it should be possible to decide whether or not
requirements have been met in an implementation.
• Requirements Analysis
• Requirement analysis is significant and essential activity after elicitation. We
analyze, refine, and scrutinize the gathered requirements to make consistent and
unambiguous requirements.
• Draw the context diagram: The context diagram is a simple model that
defines the boundaries and interfaces of the proposed systems with the
external world. It identifies the entities outside the proposed system that
interact with the system. The context diagram of student result management
system is given below:
(ii) Development of a Prototype (optional): One effective way to find out what the
customer wants is to construct a prototype, something that looks and preferably acts
as part of the system they say they want.
We can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed system
and increase the understanding of the requirements. When developers and users are
not sure about some of the elements, a prototype may help both the parties to take
a final decision.

(iii) Model the requirements: This process usually consists of various graphical
representations of the functions, data entities, external entities, and the relationships
between them. The graphical view may help to find incorrect, inconsistent, missing,
and superfluous requirements. Such models include the Data Flow diagram, Entity-
Relationship diagram, Data Dictionaries, State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will have a better
understanding of the system behavior. The inconsistencies and ambiguities have been
identified and corrected. The flow of data amongst various modules has been analyzed.
Elicitation and analyze activities have provided better insight into the system. Now we
finalize the analyzed requirements, and the next step is to document these
requirements in a prescribed format.
Functional Requirements
• Functional requirements define a function that a system or system
element must be qualified to perform and must be documented in
different forms. The functional requirements describe the behavior of the
system as it correlates to the system's functionality.
• Functional requirements should be written in a simple language, so that it
is easily understandable. The examples of functional requirements are
authentication, business rules, audit tracking, certification requirements,
transaction corrections, etc.
These requirements allow us to verify whether the application provides all
functionalities mentioned in the application's functional requirements. They
support tasks, activities, user goals for easier project management.

Non-functional requirements
• Non-functional requirements are not related to the software's functional
aspect. They can be the necessities that specify the criteria that can be
used to decide the operation instead of specific behaviors of the system.
Basic non-functional requirements are - usability, reliability, security,
storage, cost, flexibility, configuration, performance, legal or regulatory
requirements, etc.
 The 3 C’s of Decision-Making

• Clarify= Clearly identify the decision to be made or the

problem to be solved.

• Consider=Think about the possible choices and what

would happen for each choice.
• Think about the positive and negative consequences
for each choice.
• Get additional information if you need it

• Choose=Choose the best choice!

 FECTORS OF SRS
Correctness
• How do you ensure accuracy while typing? The term Correctness indicates analysis
editing, that is, in simpler terms, checking all the mandatory elements such as
front matter [title, author by-line, affiliation, correspondence information with
correct contact details, summary/abstract, key terms, history dates, etc.], body
matter [setting head levels properly, citations, placements, etc.], and back matter
[acknowledgments, funding, conflict of interest, supplementary information,
references, notes, etc.] by cross-checking with the submitted raw material.
Consistency
• The second important factor is editing for consistency throughout the
work. Consistency means rule-based editing, following in-house styles to avoid
ambiguity. A publication looks unprofessional if there is inconsistency in the work.
By rule-based editing, we mean checking for all in-house style-related points.
Completeness
• The third vital factor in copy editing is checking for Completeness of a
sentence with clarity in the content. Copy editors should focus on
correcting the sentence for grammatical errors such as checking for
subject–verb agreement and rephrasing improper or incorrect sentences
for better clarity.
 SRS DOCUMENT INCLUDED
• Project requirements
• Before you choose a model, take some time to go through the project requirements
and clarify them along side your organization’s or team’s expectations. Will the user
need to specify requirements in detail after each iterative session? Will the
requirements change during the development process?
• Project size
• Consider the size of the project you will be working on. Larger projects mean bigger
teams, so you’ll need more extensive and elaborate project management plans.
• Project complexity
• Complex projects may not have clear requirements. The requirements may change
often, and the cost of delay is high. Ask yourself if the project requires constant
monitoring or feedback from the client.
• Cost of delay
• Is the project highly time-bound with a huge cost of delay,
or are the timelines flexible?
• Customer involvement
• Do you need to consult the customers during the process?
Does the user need to participate in all phases?
• Familiarity with technology
• This involves the developers’ knowledge and experience
with the project domain, software tools, language, and
methods needed for development.
• Project resources
• This involves the amount and availability of funds, staff,
and other resources.