Scribd
Upload
16 views6 pages

Q1) Requirement Review and Management

Bbb

Uploaded by

manyatasoni66
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
16 views6 pages

Q1) Requirement Review and Management

Bbb

Uploaded by

manyatasoni66
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

Q1) Requirement Review and Management

Requirement Review is a quality assurance activity where stakeholders (e.g., clients,


developers, testers) systematically examine the documented requirements to identify issues such
as ambiguity, incompleteness, inconsistencies, or contradictions.

Requirement Management involves organizing and controlling changes to requirements


throughout the software development lifecycle. It includes activities like requirement
prioritization, traceability, change management, and version control.

Importance:

 Ensures stakeholders have a shared understanding of the project goals.


 Reduces scope creep and miscommunication.
 Helps in tracking and adapting to changes efficiently.
 Maintains project quality and reduces rework.

Q2) Requirement Documentation

Requirement documentation refers to the process of recording all software requirements in a


structured format. It acts as a reference for developers, testers, and clients.

Key Elements:

 Purpose and Scope: Defines the intent of the system and its boundaries.
 Functional Requirements: Specific behaviors or functions (e.g., "System shall send
email notifications").
 Non-Functional Requirements: Constraints like performance, usability, and security
(e.g., "System shall load pages within 3 seconds").
 Use Cases/User Scenarios: Describes how different users will interact with the system.
 Assumptions and Dependencies: External factors affecting the system.
 Acceptance Criteria: Conditions under which a requirement is accepted.
Q3) Requirement Analysis

Requirement Analysis is the process of gathering, refining, validating, and prioritizing software
requirements. It helps in understanding the client’s needs and preparing the foundation for design
and development.

Types of Requirements:

 Functional Requirements: Define the system's behavior.


Example: "User can reset password via email link."
 Non-Functional Requirements: Define how the system performs.
Example: "The system must handle 10,000 concurrent users."

It involves techniques like interviews, surveys, prototyping, and document analysis.

Q4) Feasibility Study

A Feasibility Study is an early phase in the software development lifecycle to assess whether
the proposed solution is practical and achievable.

Types:

 Technical Feasibility: Is the technology available to build the system?


 Economic Feasibility: Is the project cost-effective and within budget?
 Operational Feasibility: Will end users adopt the system?
 Legal Feasibility: Are there legal barriers or compliance issues?
 Schedule Feasibility: Can the project be completed within the deadline?

Significance: Prevents investment in impractical or unprofitable projects.


Q5) Entity-Relationship Diagram (ERD)

An ERD is a graphical representation of entities (objects) and their relationships within a system.
It is used in database design.

Components:

 Entities: Real-world objects (e.g., Student, Course).


 Attributes: Characteristics of entities (e.g., Name, Roll No).
 Relationships: Connections between entities (e.g., Enrolls).

Example: A student enrolls in a course.


Entities: Student, Course
Relationship: Enrolls
Attributes: Student_ID, Course_ID, Name

Uses: Ensures normalized data, avoids redundancy, and supports efficient querying.

Q6) Information Modelling

Information Modelling represents the structure, relationships, and constraints of data within a
system. It is used to model how data is created, stored, and used.

Helps in:

 Identifying key entities and their attributes.


 Understanding data flow and storage mechanisms.
 Improving communication between stakeholders.
 Forming the basis of database and software design.

Common Models: ER models, Class diagrams, Object-role models.

Q7) IEEE Standards for SRS

The IEEE 830 standard defines the format and content of a Software Requirements Specification
(SRS) document.

Advantages:
 Ensures completeness and clarity.
 Makes validation and verification easier.
 Promotes standardization across projects.

Limitations:

 May not be flexible enough for agile environments.


 Can be time-consuming for small-scale projects.
 Requires trained personnel for accurate documentation.

Q8) Characteristics of a Good SRS Document

 Correct: Accurately reflects user needs.


 Unambiguous: Clear and precise.
 Complete: Includes all significant requirements.
 Consistent: No conflicting or duplicate entries.
 Verifiable: Each requirement can be tested.
 Modifiable: Easy to update with changes.
 Traceable: Each requirement can be linked to design and test cases.

Example:
Bad: “The system should be fast.”
Good: “The system shall respond to search queries within 2 seconds.”

Q9) Software Quality Assurance (SQA)

SQA is a set of activities for ensuring software processes and products conform to defined
quality standards.

Verification: Checks if the product is being developed correctly (reviews, inspections).


Validation: Ensures the final product meets user expectations (testing, user acceptance tests).

Contribution to Quality:
 Reduces bugs and errors.
 Ensures consistency and reliability.
 Improves customer satisfaction.

Q10) Verification Techniques

 Reviews: Informal or formal evaluation of documents/code.


 Inspections: Detailed peer review with defined roles and checklists.
 Walkthroughs: Author-led presentation of design or code to a group.
 Testing: Execution-based verification (unit, integration, system testing).

These help catch defects early, reduce cost, and improve overall quality.

Q11) Software Quality Frameworks

 ISO 9000 Series: Focuses on quality management and assurance processes. Emphasizes
documentation, audit, and process control.
 SEI-CMM (Capability Maturity Model): Provides a structured approach to improve
software process maturity.

CMM Levels:

1. Initial: Ad hoc processes.


2. Repeatable: Basic project management.
3. Defined: Documented standard processes.
4. Managed: Metrics-based decision making.
5. Optimizing: Continuous process improvement.

Q12) Capability Maturity Model (CMM)

CMM is a framework that describes five levels of process maturity for software development
organizations.
Levels:

1. Initial (Chaotic): Unpredictable processes.


2. Repeatable: Project tracking is possible.
3. Defined: Standard practices organization-wide.
4. Managed: Quantitative quality control.
5. Optimizing: Continuous process refinement.

Impact: As maturity increases, software becomes more reliable, predictable, and cost-effective
to develop and maintain.

You might also like