Search This Blog

Sunday, 24 August 2025

Questions and Answers on SE (UNIT 2)

0 comments

 FAQ on Software Engineering (Unit 2)

Question 1

Explain the importance of collecting requirements.  How many types of System Requirements are there in Software Engineering.

  • Collecting requirements is the foundational step in software engineering. 
  • It ensures the final product meets the needs of its users and stakeholders. 
  • Without a clear understanding of what needs to be built, a project is likely to fail, resulting in a product that is either unusable, over budget, or delivered late.
  • There are typically two main types of requirements in software engineering: functional and non-functional.

Functional Requirements:

  • These requirements describe what the software must do
  • They define the specific functions, behaviors, and features of the system. 
  • They are often written as user stories or statements that describe a specific task the user can perform.
  • Without functional requirements, developers don't know what to incorporate in the software being built
  • Some of the examples of functional requirements are:
    • The system shall allow users to log in with a username and password.
    • The system shall generate a sales report.
    • The system shall process a credit card payment.

Non-Functional Requirements (or Quality Attributes) 

  • These requirements describe how the system performs its functions. 
  • They define the quality, constraints, and characteristics of the system, rather than its specific behaviors.
  • They are crucial for ensuring the software is high-quality and reliable. 
  • A system that is slow, insecure, or hard to use, even if it has all the right functions, will be considered a failure. They often define the project's success metrics beyond just functionality.
  • Here are some examples of non-functional products:
    • Performance: The system shall load a webpage in less than 2 seconds.
    • Security: The system shall encrypt all user data.
    • Usability: The system shall have a user-friendly interface that can be learned in under 10 minutes.
    • Scalability: The system shall support up to 10,000 concurrent users.


Question 2

Describe the various steps of Requirements Engineering. Is it essential to follow these steps?

  • Requirements Engineering is the systematic process of gathering, documenting, and managing the needs and constraints of stakeholders throughout a software project's lifecycle.
  • Following these steps is essential as it forms the foundation of a successful project, ensuring that the final product aligns with user expectations and business goals.
  • Skipping or poorly executing these steps can lead to project failure due to issues like scope creep, budget overruns, and missed deadlines.

The Steps of Requirements Engineering:

The Requirements Engineering process is often iterative, meaning the steps may be repeated and revisited as the project evolves. The core steps are:

Requirements Elicitation: 👂 

  • This is the process of gathering information from stakeholders. 
  • It involves understanding their needs, wants, and constraints related to the new software system. 
  • Techniques like interviews, surveys, workshops, and observation are used to uncover both explicit and implicit requirements.

Requirements Analysis: 🧠 

  • Once requirements are gathered, this step involves examining them to identify conflicts, ambiguities, and inconsistencies. 
  • The goal is to refine the raw information into a clear, concise, and complete set of requirements. 
  • This is where the Analysts prioritize and group requirements, as not all of them will have equal importance.

Requirements Specification: ✍️ 

  • This step is about documenting the analyzed requirements in a formal and structured way. 
  • The primary output is typically a Software Requirements Specification (SRS) document. 
  • This document serves as a blueprint for the development team and includes details on both functional requirements (what the system should do) and non-functional requirements (how the system should perform).

Requirements Validation: ✅ 

  • Before development begins, the documented requirements must be validated. 
  • Requirements validation examines the specification to ensure that all software requirements have been stated unambiguously; that means consistencies, omissions, and errors have been detected and corrected in the requirements specification.
  • Validation can involve reviews, prototyping, and generating test cases to ensure the requirements are feasible and testable.

Requirements Management: 🗓️ 

  • Requirements Management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the development proceeds.
  • This is an ongoing activity that has to be performed throughout the  lifecycle of software development. 
  • Requirements management begins with identification.  Each requirement is assigned a unique identifier.  Once requirements have been identified, traceability tables are developed to keep track of the changes that may occur throughout the life of the system.


Question 3

Discuss the significance and use of Requirements Engineering. What are the problems Analysts face during the formation of requirements?

  • Requirements Engineering is a systematic process of discovering, documenting, analyzing, and managing software requirements. 
  • Its significance lies in ensuring that the software to be developed meets the actual needs of its users and stakeholders.

Analysts, or requirements engineers, often face several significant challenges during the requirements-gathering process:

Stakeholder Communication Issues:
  • Unclear or Conflicting Needs: Different stakeholders may have conflicting requirements, and it's the analyst's job to resolve these disputes.
  • Tacit Knowledge: Users might not be able to articulate their needs because they are so familiar with their work. They often struggle to describe what they do and need until they see something concrete.
Incomplete or Ambiguous Requirements:
  • Vague Language: Requirements are often written using vague terms like "fast," "easy to use," or "secure." These are subjective and can be interpreted differently by team members.
  • Missing Requirements: Sometimes, critical requirements are simply forgotten or assumed, only to be discovered late in the development cycle when they are much more expensive to fix.
Scope Creep: 

This is a major problem where new requirements are continuously added after the project has started. It can derail the project, leading to delays and increased costs.

Organizational and Political Factors:
  • Resistance to Change: Stakeholders may resist new systems, making it difficult to get their full cooperation and honest input.
  • Political Agendas: Different departments or individuals may have hidden agendas that influence the requirements, sometimes to the detriment of the project's overall success.


Question 4

What do you understand with the term "Requirements Elicitation"?  Discuss any two techniques of requirements elicitation.

  • The process of investigating and learning about a system's requirements from users, clients, and other stakeholders is known as requirements elicitation.
  • Requirement Elicitation can be successful only through an effective customer-developer partnership; It is needed to know what the users require.
  • Requirements elicitation involves the identification, collection, analysis, and refinement of the requirements for a software system.
There are several requirements elicitation methods. Two them are listed below:
Interviews

  • The objective of conducting an interview is to understand the customer's expectations of the software. 
  • It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and credibility. 
  • Interviews may be open-ended or structured:
    • In open-ended interviews, there is no pre-set agenda. Context-free questions may be asked to understand the problem.
    • In a structured interview, an agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview.

Brainstorming Sessions
  • Brainstorming Sessions is a group technique
  • It is intended to generate lots of new ideas hence providing a platform to share views
  • A highly trained facilitator is required to handle group bias and conflicts.
  • Every idea is documented so that everyone can see it.
  • Finally, a document is prepared which consists of the list of requirements and their priority if possible.


Question 5

What is Requirements Analysis? Explain various steps involved in it with illustration.

  • Requirements Analysis is a crucial step in Requirements Engineering that focuses on understanding, documenting, and managing the needs and expectations for a new or modified system. 
  • The main goal of Requirements Analysis is to create a complete and accurate representation of all requirements before design and development begin, ensuring the final product meets the customer's needs and business goals.
  • Once requirements are gathered, this step focuses on analyzing them to ensure they are clear, complete, consistent, and feasible. This involves the following:

Categorizing Requirements:
 

Sorting the gathered information into logical groups, typically into two main types:
  • Functional Requirements: What the system must do. (e.g., "The system shall allow users to create a new account.")
  • Non-Functional Requirements: How the system should perform. These are quality attributes. (e.g., "The website must load in under 3 seconds on a standard broadband connection.")

Modeling Requirements: 

Using diagrams and visual representations to clarify and validate the requirements with stakeholders. Common techniques include:
  • Use Case Diagrams: Illustrating how different users will interact with the system.
  • Data Flow Diagrams (DFDs): Showing the flow of information through the system.
  • User Stories: Short, simple descriptions of a feature told from the perspective of the user. (e.g., "As a customer, I want to add an item to my cart so I can purchase it.")

Illustration: 
  • For the online store, the analyst would identify functional requirements like "The system must process credit card payments" and non-functional requirements like "The payment processing must be secure and encrypted." 
  • They would then create a use case diagram showing the "Customer" actor interacting with functions like "Browse Products," "Add to Cart," and "Checkout."

Leave a Reply