Unit 3: Software Requirements and Specifications

3.1 Identify Software Requirements

The foundation of any successful software project lies in accurately identifying and understanding what needs to be built. Software requirements describe the features, functionalities, and constraints of the proposed system. Identifying these requirements is a crucial phase in the software development life cycle.

Requirement Gathering – Collect Requirements from Stakeholders

Requirement gathering, also known as requirement elicitation, is the process of collecting the needs and expectations of the stakeholders. Stakeholders include clients, end-users, project managers, domain experts, and anyone else who has a vested interest in the software.

Techniques for Requirement Gathering:

1. Interviews: One-on-one or group discussions with stakeholders to understand their needs, expectations, and the problems they face with the current system.
2. Surveys and Questionnaires: Useful for gathering information from a large number of distributed users. They consist of structured questions to gather specific data.
3. Brainstorming Sessions: Collaborative meetings where stakeholders and developers generate ideas, discuss possibilities, and identify potential requirements in a free-flowing environment.
4. Observation: Spending time with users in their working environment to understand how they perform their tasks and identify areas where software can improve their workflow.
5. Document Analysis: Reviewing existing documentation, manuals, or previous system reports to understand the current processes and identify gaps.
6. Prototyping: Creating a basic, interactive model of the software to help stakeholders visualize the final product and provide concrete feedback.

Analyze the Requirements

Once the raw requirements are gathered, they must be analyzed to ensure they are clear, consistent, complete, and feasible. Requirement analysis involves refining the collected information and resolving any conflicts.

Key Steps in Requirement Analysis:

1. Categorization: Grouping similar requirements together (e.g., user interface requirements, database requirements).
2. Prioritization: Determining which requirements are essential (must-have), important (should-have), or optional (nice-to-have) based on stakeholder needs and project constraints.
3. Conflict Resolution: Identifying and resolving contradictory requirements. For example, a stakeholder might request a feature that violates a security constraint. Such conflicts must be discussed and resolved.
4. Feasibility Study: Assessing whether the requirements can be implemented within the given time, budget, and technological constraints.
5. Refinement: Breaking down high-level requirements into smaller, detailed, and actionable specifications.

---

3.2 Prepare Software Requirement Specifications (SRS)

A Software Requirement Specification (SRS) is a formal document that comprehensively describes the intended purpose, behavior, and environment of the software system to be developed. It acts as a contract between the development team and the stakeholders.

Importance of SRS

1. Clear Communication: It establishes a common understanding among all stakeholders, reducing the risk of miscommunication and unmet expectations.
2. Project Planning: It provides a solid foundation for estimating project cost, time, and resources required for development.
3. Design Reference: It serves as a blueprint for system architects and designers to create the software architecture.
4. Testing Basis: Quality Assurance (QA) teams use the SRS to develop test plans and test cases to verify that the software meets its requirements.
5. Scope Management: It helps in controlling feature creep by clearly defining what is included in the project scope and what is not.

Users of SRS

The SRS document is utilized by various roles throughout the software development life cycle:

• Clients and Customers: To verify that their needs and expectations are accurately captured.
• System Analysts: To ensure all requirements have been documented and analyzed correctly.
• Software Developers: As a primary reference to understand what needs to be coded and implemented.
• System Testers (QA): To create test scenarios, test cases, and validate the final product against the specified requirements.
• Project Managers: To track progress, manage project scope, and ensure the project stays on schedule and within budget.
• Maintenance Team: To understand the system's intended functionality when performing future updates or bug fixes.

Characteristics of Good & Bad SRS

Characteristics of a Good SRS:

• Correct: Every requirement stated must accurately reflect what the software shall do.
• Unambiguous: Each requirement must have only one interpretation. Clear and precise language should be used.
• Complete: It should include all necessary requirements, addressing all possible scenarios, inputs, and outputs.
• Consistent: Requirements should not contradict each other.
• Verifiable (Testable): There must be a way to objectively verify whether the software meets the requirement through testing.
• Modifiable: The structure and style of the document should allow for easy updates and changes without altering existing requirements inadvertently.
• Traceable: The origin of each requirement must be clear, and it should be easy to track the requirement through design, implementation, and testing phases.

Characteristics of a Bad SRS:

• Vague or Ambiguous Language: Using words like "fast," "user-friendly," or "robust" without defining what they mean in measurable terms.
• Incomplete Information: Missing crucial details or failing to account for edge cases and error handling.
• Contradictory Requirements: Stating conflicting features that cannot be implemented simultaneously.
• Implementation Details Included: Specifying how the system should be built rather than what it should do.
• Untestable Requirements: Stating requirements that cannot be verified objectively.

---

3.3 Types of Requirements in SRS

Software requirements are broadly categorized into two main types: Functional Requirements and Non-functional Requirements. Both are essential for a complete and effective SRS.

Functional Requirements

Functional requirements describe the specific behaviors, functions, or features of the software system. They define what the system should do in response to specific inputs or conditions.

Examples of Functional Requirements:

• User Authentication: "The system shall allow users to log in using a valid email address and password."
• Data Processing: "The software shall calculate the total order amount, including applicable taxes and shipping costs."
• Reporting: "The system shall generate a monthly sales report in PDF format."
• Data Management: "The application shall allow administrators to add, update, and delete user profiles."
• Notifications: "The system shall send an email confirmation to the user upon successful registration."

Functional requirements are typically captured using use cases, user stories, and functional specifications.

Non-functional Requirements

Non-functional requirements (NFRs) specify the quality attributes, performance goals, constraints, and operational characteristics of the system. They define how well the system should perform its functions.

Categories and Examples of Non-functional Requirements:

1. Performance: "The system shall load the homepage within 2 seconds under normal network conditions."
2. Scalability: "The database must support up to 10,000 concurrent user sessions without performance degradation."
3. Security: "All user passwords must be encrypted using AES-256 before being stored in the database."
4. Usability: "The user interface shall comply with WCAG 2.1 AA accessibility standards."
5. Reliability/Availability: "The system shall have an uptime of 99.9% during business hours."
6. Portability: "The web application must be fully functional on the latest versions of Chrome, Firefox, Safari, and Edge."
7. Maintainability: "The source code shall follow established coding standards and include comprehensive comments to facilitate future updates."

While functional requirements are about the system's features, non-functional requirements are about the system's overall quality and user experience. Failing to meet non-functional requirements can lead to a functional system that is practically unusable.