Software Requirement Primary Concept

Software Requirements Specification (SRS) is a comprehensive document that outlines the functional and non-functional requirements of a software system.

It serves as a blueprint for the development team, providing a detailed description of what the software is expected to do, how it should perform, and the constraints within which it must operate.

The SRS is a crucial part of the software development life cycle, guiding the development process by defining the features, behaviors, and characteristics expected from the software.

Key components typically included in a Software Requirements Specification are:

1. Introduction:

An overview of the purpose, scope, and objectives of the software project.

2. Functional Requirements:

A detailed description of the system’s functionality, including input and output  behaviors, processing logic, and system interactions.

3. Non-functional Requirements:

Specifications related to system attributes such as performance, security, reliability, and scalability.

4. User Interfaces:

Descriptions of how users will interact with the software, including interface design and usability considerations.

5. System Constraints:

Any limitations or restrictions on the software design and implementation, including hardware or software dependencies.

6. Assumptions and Dependencies:

Any assumptions made during the specification process and dependencies on external factors or components.

7. Use Cases and Scenarios:

Detailed use cases and scenarios that illustrate how users or external entities interact with the system to achieve specific goals.

8. **Data Requirements:** Specifications regarding the data that the system will handle, including storage, retrieval, and processing.

9. **Testing Requirements:** Criteria and procedures for testing the software to ensure it meets the specified requirements.

10. **Acceptance Criteria:** Criteria that must be met for the software to be accepted by the client or stakeholders.

Creating a well-defined and accurate Software Requirements Specification is crucial for successful software development, as it provides a common understanding of the project’s objectives and serves as a reference throughout the development process.

 

Definition of software requirement engineering?

The process to gather the software requirements from client, analyze and document them is known as software requirement engineering.

What are the steps of requirement engineering?

The steps of requirement engineering are discussed below:

• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation

Feasibility Study: This feasibility study is focused on goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity, and integration ability.

Requirement Gathering: If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide, and which features they want the software to include.

Software Requirement Specification: SRS is a document created by system analyst after the requirements are collected from various stakeholders. SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team. SRS should contain the following features:

• User Requirements are expressed in natural
• Technical requirements are expressed in structured language, which is used inside the
• Design description should be written in Pseudo
• Format of Forms and GUI screen
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation: After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

What are the tasks of requirement engineering?

The tasks of requirement engineering are as follows:

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Requirement management

Inception: Inception is a task where the requirement engineering asks a set of questions to establish a software process. In this task, it understands the problem and evaluates with the proper solution. It collaborates with the relationship between the customer and the developer. The developer and customer decide the overall scope and the nature of the question.

Elicitation: Elicitation means to find the requirements from anybody. The requirements are difficult because the following problems occur in elicitation.

• Problem of scope: The customer gives the unnecessary technical detail rather than clarity of the overall system objective.
• Problem of understanding: Poor understanding between the customer and the developer regarding various aspect of the project like capability, limitation of the computing
• Problem of volatility: In this problem, the requirements change from time to time, and it is difficult while developing the

 

Elaboration: In this task, the information taken from user during inception and elaboration and are expanded and refined in elaboration. Its main task is developing pure model of software using functions, feature and constraints of a software.

Negotiation: In negotiation task, a software engineer decides the how will the project be achieved with limited business resources. To create rough guesses of development and access the impact of the requirement on the project cost and delivery time.

Specification: In this task, the requirement engineer constructs a final work product. The work product is in the form of software requirement specification. In this task, formalize the requirement of the proposed software such as informative, functional and behavioral. The requirement is formalized in both graphical and textual formats.

Validation: The work product is built as an output of the requirement engineering and that is accessed for the quality through a validation step. The formal technical reviews from the software engineer, customer and other stakeholders helps for the primary requirements validation mechanism.

Requirement Management: It is a set of activities that help the project team to identify, control and track the requirements and changes can be made to the requirements at any time of the ongoing project. These tasks start with the identification and assign a unique identifier to each of the requirement. After finalizing the requirement traceability table is developed.The examples of traceability table are the features, sources, dependencies, subsystems and interface of the requirement.

Write down the techniques of eliciting requirement?

Requirement elicitation is the process of collecting information from stakeholders. It serves as a foundation in documenting the requirements for application development. There are a number of elicitation techniques to gather requirements or to collect the information from the stakeholders. Some of the requirement elicitation techniques are as follows.

• Document analysis
• Observation
• Interview
• Prototyping
• Brainstorming
• Workshop
• JAD (Joint Application Development)
• Reverse engineering
• Surveys/Questionnaire

Document Analysis: Document analysis is one of the most helpful elicitation techniques in understanding the current process. Documents like user manuals, software vendor manuals, process documents about the current system can provide the inputs for the new system requirements.

• Steps involved in document analysis are:
• Evaluating whether the existing system and business documents are appropriate to be
• Analyzing the documents to identify relevant business
• Reviewing and confirming identified details with subject matter

There could be a lot of information that can be transferred to a new system requirements document. Evaluating the documentation can assist in making the As-Is process document and conducting GAP analysis for scoping of the project in question.

 

Observation: This elicitation technique helps in collecting requirements by observing users or stakeholders. This can provide information about the exiting process, inputs and outputs. There are two kinds of observations — active and passive. In active observation, the business analyst directly observes the users or stakeholders, whereas in passive observation the business analyst observes the subject matter experts. This helps the business team understand the requirements when users are unable to explain requirements clearly.

Interview: An interview is a systematic approach to elicit information from a person or group of people. In this case, the business analyst acts as an interviewer. An interview provides an opportunity to explore and/or clarify requirements in more detail. Without knowing the expectations and goals of the stakeholders it is difficult to fulfil requirements.

Prototyping: Screen mockups can support the requirement gathering process, when introduced at the correct time. Mockups help stakeholders visualize the functionality of a system. This can be an advantage to business analysts and stakeholders since this allows them to identify gaps/problems early on.

Brainstorming: Brainstorming is an efficient way to define their requirements. Users can come up with very innovative ideas or requirements. This can help gather ideas and creative solutions from stakeholders in a short time. Users or stakeholders can come up with ideas that they have seen or experienced elsewhere. These ideas can be reviewed, and the relevant ones can then be included in the system requirements.

Workshop: Workshops comprise a group of users or stakeholders working together to identify requirements. A requirement workshop is a structured way to capture requirements. Workshops

are used to scope, discover, define, and prioritize requirements for the proposed system. They are the most effective way to deliver high-quality requirements quickly. They promote mutual understanding and strong communication between users or stakeholders and the project team.

JAD (Joint Application Development): Joint Application Development (JAD) technique is an extended session to the workshop. In the JAD session stakeholders and project team works together to identify the requirements. These sessions allow the business team to gather and consolidate large amounts of information. Identification of stakeholders is the critical to the overall success of the JAD session. The JAD team includes business process owners, client representatives, seers or stakeholders, business analysts, project managers, IT experts (developers, quality assurance, designers, and security).

Reverse engineering: This elicitation technique is generally used in migration projects. If an existing system has outdated documentation, it can be reverse engineered to understand what the system does. This is an elicitation technique that can extract implemented requirements from the system.

There are two types of reverse engineering techniques.

• Black box reverse engineering: The system is studied without examining its internal structure (function and composition of software).
• White box reverse engineering: The inner workings of the system are studied (analysing and understanding of software code)

Surveys/Questionnaires: Questionnaires are useful when there is a lot of information to be gathered from a larger group of stakeholders. This enables the business team to gather requirements from stakeholders remotely. The design of the questionnaire is very important, since it can influence the answers that people provide. In addition to the above-mentioned elicitation techniques, there are many more are on the market. It is very difficult to say that which elicitation technique is suitable for all projects. Not all elicitation techniques can be executed for every project. When selecting an elicitation method, factors such as the nature of the project, organizational structure and type of stakeholders are taken into account by the business team before deciding which technique works best. Having said that, brainstorming, document analysis, interviews, prototyping, and workshops are the most widely used requirement elicitation techniques.

Write down the classification of software requirements?

A software requirement can be of 3 types:

• Functional requirements
• Non-functional requirements
• Domain requirements

Functional Requirements: These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation performed, and the output expected. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements. For example, in a hospital management system, a doctor should be able to retrieve the information of his patients. Each high-level functional requirement may involve several interactions or dialogues between the system and the outside world. In order to accurately describe the functional requirements, all scenarios must be enumerated.

Non-functional requirements: These are basically the quality constraints that the system must satisfy according to the project contract. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements. They basically deal with issues like:

• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

NFR’s are classified into following types:

• Interface constraints
• Performance constraints: response time, security, storage space,
• Operating constraints
• Life cycle constraints: maintainability, portability,
• Economic constraints

 

The process of specifying non-functional requirements requires the knowledge of the functionality of the system, as well as the knowledge of the context within which the system will operate.

Domain requirements: Domain requirements are the requirements which are characteristic of a particular category or domain of projects. The basic functions that a system of a specific domain must necessarily exhibit come under this category. For instance, in an academic software that maintains records of a school or college, the functionality of being able to access the list of faculty and list of students of each grade is a domain requirement. These requirements are therefore identified from that domain model and are not user specific.

Write down the difference between functional and nonfunctional requirement?

Difference between functional and nonfunctional requirement are discussed below:

Functional Requirements	Non Functional Requirements
1. A functional requirement defines a system or its component.	1. A non-functional requirement defines the quality attribute of a software system.
2. It is mandatory.	2. It is not mandatory.
3. Defined at a component level.	3. Applied to a system.
4. Helps you verify the functionality of the software.	4. Helps you to verify the performance of the software.
5. Functional Testing like System, Integration, End to End, API testing, etc. are done.	5.Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done.
6. Usually easy to define.	6. Usually more difficult to define.
7. Example 1)   Authentication of user whenever he/she logs into the system. 2)  System shutdown in case of a cyber-attack. 3)   A Verification email is sent to user whenever he/she registers for the first time on some software system.	7. Example 1)   Emails should be sent with a latency of no greater than 12 hours from such an activity. 2)   The processing of each request should be done within 10 seconds 3)   The site should load in 3 seconds when the number of simultaneous users are > 10000

 

What is the difference between in Functional and non-functional requirements?

 

Aspect	Functional Requirements	Non-functional Requirements
Focus	Describes specific features and functionalities the system must provide.	Describes the qualities and characteristics of the system.
What They Address	Concerned with what the system does.	Concerned with how well the system performs its functions.
Examples	User authentication, data validation, report generation.	Response time, system availability, security measures.
Measurability	Typically measurable and testable.	Often more subjective and may be harder to quantify.
Scope of Impact	Directly impacts the visible behavior of the system.	Impacts the overall performance, usability, and quality of the system.
Change Frequency	More likely to change as user needs evolve.	Tends to be stable and less subject to frequent changes.
Verification	Tested through functional testing.	Tested through performance testing, security testing, etc.
Examples of Documentation	Use cases, user stories, system flow diagrams.	Performance requirements document, security policy document.

 

What is stakeholder in software specification?

In software specification, a stakeholder refers to any individual or group that has an interest or concern in the outcome of a software project. Stakeholders are those who are directly or indirectly affected by the software, and they can influence or be influenced by the project’s goals, requirements, and decisions.

In software specification, a stakeholder is an individual or group with an interest in the software project’s outcome.

This includes end users, customers, product owners, developers, project managers, testers, regulatory bodies, marketing teams, and executives.

Understanding and addressing the needs of these stakeholders is essential for successful software development.

Stakeholders in software specification can include:

1. End Users: The individuals or groups who will ultimately use the software. Their needs and preferences are crucial for defining requirements.

2. Customers/Clients: The entities or organizations that are paying for the development of the software. Their satisfaction is often a primary goal.

3. Product Owners: Individuals responsible for defining and prioritizing features. In agile development, the product owner represents the voice of the customer.

4. Developers/Programmers:** The people responsible for designing, coding, testing, and implementing the software.

5. Project Managers: Individuals overseeing the planning, execution, and closing of the software project. They are concerned with meeting deadlines and staying within budget.

6. Quality Assurance/Testers: Those responsible for ensuring that the software meets the specified requirements and functions correctly.

7. Regulatory Bodies: Organizations or entities that set guidelines and standards which the software must adhere to (e.g., industry regulations).

8. Marketing and Sales Teams: Individuals responsible for promoting and selling the software. Their input can influence the features that make the product marketable.

9. Executives and Leadership: Decision-makers within the organization who may have high-level strategic goals and expectations for the software.

 

What is Actor in software specification?

In software specification, an actor is an external entity that interacts with a system to achieve specific goals.

These external entities could be individuals, other systems, or external components that initiate actions within the software system. Actors are integral to use case modeling, helping to define how the system is used from an external perspective.

In software specification, an actor refers to an external entity that interacts with a system, typically to achieve a specific goal. Actors are not part of the system itself but are entities that initiate actions within the system or respond to system outputs. Actors can be individuals, other systems, or external entities that play a role in the software’s functionality.

For example, in a banking system, actors could include customers, bank tellers, and an external payment gateway. Each of these entities interacts with the system to perform specific tasks. Actors help in defining use cases and scenarios, providing a clear understanding of how the system will be used from an external perspective. They are an essential concept in use case modeling and analysis during the software development process.

 

What is user in software specification?

In software specification, a “user” refers to an individual or entity interacting with the software system.

Users can have various roles and responsibilities, engaging with the software to perform tasks or access specific functionalities. Understanding user needs is crucial for designing a system that meets expectations and provides a positive experience.

The term “user” encompasses end users, administrators, and others interacting with the software in different capacities.

In software specification, a “user” typically refers to an individual or entity that interacts with the software system. Users can have various roles and responsibilities, and they engage with the software to perform specific tasks, achieve goals, or access certain functionalities. The term “user” is broad and can encompass end users, administrators, system operators, or any other individuals who interact with the software in different capacities.

Understanding the needs, preferences, and requirements of users is crucial in software development to design a system that meets their expectations. In the context of user-centered design, developers often create user personas and scenarios to better understand the diverse ways in which users may interact with the software. This information is then used to guide the specification and design process, ensuring that the software aligns with user expectations and provides a positive user experience.

 

What is the different between Stakeholder, user, and actor in software specification?

 

Aspect	Stakeholder	User	Actor
Definition	Individuals or groups with an interest in the software project outcome.	Individuals or entities interacting with the software.	External entities interacting with the system to achieve specific goals.
Involvement	Can influence or be influenced by project goals, requirements, and decisions.	Engages with the software to perform tasks or access functionalities.	Initiates actions within the system or responds to system outputs.
Examples	Customers, end users, project managers, developers.	End users, administrators, system operators.	Customers, external systems, components.
Perspective	Concerned with the success of the entire project.	Focus on using the software for their needs.	External entities impacting system behavior.
Relationship to System	May or may not directly interact with the system.	Directly interacts with the system.	External to the system but interacts with it.
Analysis Purpose	Considered in project planning and decision-making.	Essential for user-centered design and experience.	Used in use case modeling and system analysis.

Thank You!