What are the key elements of an SRS | Business Analyst Interview Questions

What are the key elements of an SRS?

In this series of posts on business analyst interview questions, I am going to examine the question – What are the key elements of an SRS –  in this post. An interviewer asks this question to check if you have genuinely worked on creating an SRS or BRD.

SRS Vs BRD Vs FSD: These 3 terms are used interchangeably. For me, BRD has a completely different perspective as compared to SRS and FSD. Will cover this in another post. Don’t get into the differences in the interview. Just answer the question considering all the 3 as the same.

Elements of an SRS

System Requirements Specification (SRS) document is written to capture detailed requirements (analyzed, specific and classified) for the following reasons:

  • Developers/Design team can design and develop the software application based on this document
  • Project Management team to manage resources effectively
  • Customers and other stakeholders can use it as a reference document

The essential elements of an SRS are as follows:

Scope of Work

Scope of work section defines the activities to be carried out in the project and what’s not included in the scope. For example, a customer organization outsources the functional testing to another IT company (other than yours which is developing the software). In this case, functional tetsing is out of the scope.

Assumptions, Constraints & dependencies

This section of SRS contains the project related assumptions, constraints and dependencies. These sections help in developing risk management plan for the project.

Requirements Details

This is the largest section of the SRS document. The requirements are classified and described in two different sections:

  • Functional Requirements (Relating to functionality of the system)
  • Non-Functional Requirements (Relating to security, performance, interface etc)

The functional requirements are captured in a hierarchical manner as follows:

  • Scope Model: It defines the overall scope of the system (generally a block diagram/context diagram)
  • Functional Model: This is used to describe the functionalities of the system. You can use use case model, functional decomposition diagram or user stories model to describe the functional model
  • UI model: We must associate each of the functionalities with a user interface (screen) to describe it uniquely.
  • Rules and Constraints: This section is generally captured along with the UI screens to describe the business rules and constraints. For example, whether a field is mandatory.

Data Model

Data model section describes the elements of the screen. For example, we need to explain whether an element on a screen is text or number. What is the size of the field?

Please note that data model does not mean tables. As a business analyst, you don’t need to get into tables design.

Non-Functional Requirements

This section describes non-functional requirements like performance, security and others. This is an important section as it also helps in planning for inter-group co-ordination requirements. For example, if the project needs support from other groups in the organization to fulfill these non-functional requirements, those groups may need to be informed in advance.

Acceptance Criteria

Acceptance criteria is another critical section of an SRS. This is the agreed criteria on the basis of which a customer will accept the software during the UAT (user acceptance testing).

Other Sections

I have explained the most important sections above. There are other sections as well like reporting sections, stakeholder management section and so on….

The interviewer would like to check your understanding of the SRS/FSD document broadly. If you are able to explain the key sections well, that should be good enough.

Other Business Analyst Interview questions

You can check the other questions in the following post:

What are some scenario based and logical questions that are asked in a Business Analyst interview?

About Techcanvass

Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.

We have a Business analyst training course with domain training in-built into it. This training program offers you the opportunity to get certified with ECBA certification as well as have banking domain understanding.

Business Analyst Course | ECBA Certification training

Business Analyst Course | ECBA Certification training

Business Analyst Training with Banking Domain

Business Analyst Training with Banking

Business Analyst Short Courses

Business Analyst Training Self-learning Course

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *