FAQ on Software Engineering (Unit 2)
Multiple Choice Questions:
1. Which one of the following is not a step of requirement engineering?
a) Elicitation
b) Design
c) Analysis
d) Documentation
2. Which of the following property doesn't correspond to a good Software Requirements Specification (SRS)?
a) Verifiable
b) Ambiguous
c) Complete
d) Traceable
3. Which of the following is included in SRS?
a) Cost
b) Design Constraints
c) Staffing
d) Delivery Schedule
4. "Consider a system, where a heat sensor detects an intrusion and alerts the security company." What kind of requirement specification is this?
a) Functional
b) Non-functional
5. System Requirement is written for ______________ (User/Developer).
6. SRS is a document intended for ___________________.
a) Analysts
b) Designers
c) Users
d) All the above
7. Which one of the following is NOT desired in a good SRS document?
a) Functional Requirements
b) Non-functional Requirements
c) Goals of Implementation
d) Algorithms for Software Implementation
8. Why is Requirements Management Important ? It is due to the changes ________________
a) to the environment
b) in technology
c) in customer’s expectations
d) All the above
Question 1:
What is the significance of Requirements Engineering in developing software?
- Requirements Engineering is a systematic process of discovering, documenting, analysing, and managing software requirements.
- Its significance lies in ensuring that the software to be developed meets the actual needs of its users and stakeholders.
Question 2:
Paint the role of Requirements Engineering in the process of Software Engineering.
- Requirements engineering is a crucial part of software development that focuses on discovering, analyzing, documenting, and managing the requirements for a software system.
- Its role is to bridge the gap between the customer's needs and the technical specifications of the software.
- It ensures that the software being built actually solves the problem the customer wants to be solved.
Question 3:
What are the various activities involved in Requirements Engineering process? (or) List all the tasks involved in Requirements Engineering.
Requirements Engineering has four sub tasks. They are:
- Requirements Elicitation
- Requirements Analysis
- Requirements Documentation
- Requirements Validation
- Requirements Management
Question 4:
What the various steps involved in 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 life cycle.
- 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.
Question 5:
Write noes on Requirements Elicitation?
- Requirements Elicitation is the most important sub process of Requirements Engineering.
- It is aimed at finding the following information:
- Defining objectives and goals of software to be developed
- Understanding organisational background
- Collecting requirements from the user
- Techniques used for requirements elicitation include: interviewing, brainstorming, prototyping, scenario generation and use case creation, etc.
Question 6:
Define Requirements Specification.
A requirement specification is a detailed document that outlines what a project, product, or system must do, including its functions, features, and constraints. It is also known as Software Requirements Specification (SRS) or Requirements Specification Document (RSD). It serves as a blueprint and communication tool between stakeholders, ensuring everyone has a shared understanding of the objectives and expectations. This document defines the "what" of the project, distinguishing it from a "design specification," which defines the "how".
Question 7:
List the characteristics of good SRS Document.
- SRS document preparation is the starting point of software development process
- SRS is being prepared based on the input given by the user and then user requirements are converted into system requirements having two parts: functional requirements and non-functional requirements
- A high quality SRS document has the following characteristics:
- Correctness
- Completeness
- Unambitious
- Traceable
- Verifiable
Question 8:
What is the role of Requirement Analysis?
Requirements analysis is an activity involved in Requirements Engineering process that does the following:
- Clarifies the required features and overall vision of the software
- Clarifies expectations of the stakeholder on the software to be developed
- Prevents conflict and communication gaps during development and testing.
- Ensures that the final product conforms to requirements, i.e., prevents scope creep.
Question 1:
Explain the importance of collecting requirements. Paraphrase user requirements and system requirements.
- Collecting requirements is the foundational step in software engineering.
- It ensures that 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: user requirements and system requirements. System requirements are further classified into functional and non-functional.
User Requirements:
- These are high-level, abstract statements of the software's functionality and constraints.
- They're written for customers and end-users in natural language and are designed to be easily understood by non-technical people.
- Example for user requirements: "The system shall allow a user to book a flight."
- These are detailed, precise specifications of the system's functions, services, and operational constraints.
- They are written for software developers and designers and are a detailed breakdown of the user requirements.
- Here is an example for system requirements, "The system shall validate the user's credit card number against the Luhn algorithm before processing the payment."
Question 2:
What are functional and non-functional requirements?
Functional Requirements:
- These requirements describe what the software must do.
- They define the specific functions, behaviours, 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 web page 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 3:
Journalize the structure of a Software Requirements Document.
A Software Requirements Document (SRD), also known as a Software Requirements Specification (SRS), is a formal document that provides a complete description of the software to be developed. A typical structure includes:
Introduction: Provides an overview of the document, the purpose of the software, and the scope of the project.
- General Description: Describes the software's general functions, user characteristics, and assumptions and dependencies.
Specific Requirements: This is the core of the document, detailing all functional and non-functional requirements. It may be broken down into sections for:
Functional Requirements (what the software must do)
Non-functional Requirements (performance, security, usability, etc.)
System Constraints
- Appendices: Includes supplementary information like a glossary of terms or data flow diagrams.
Question 4:
Briefly explain Requirements Engineering Process. (or) Explain the tasks involved in Requirements Engineering in detail.
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 5:
What are the problems Analysts face during the formation of requirements?
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.
- 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.
- 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 6:
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.
- 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 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 7:
What is Requirements Analysis? Explain the steps involved in it with illustration.
- 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 analysing them to ensure that they are clear, complete, consistent, and feasible.
- This task involves the following two activities:
- 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.")
- 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.")
- 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."
