Requirement Gathering & Analysis for Software Development

Requirement Gathering & Analysis

• Requirements of a customer are crucial for software development.
• A system analyst performs the task of gathering and analyzing requirements.
• The analyst collects information from the customer and analyzes it to remove ambiguities and inconsistencies.
• Requirement gathering is typically the first step in software development, forming the foundation for the whole process.
• Its goal is to understand customer needs thoroughly to ensure no incompleteness or inconsistencies.
• This phase involves meetings with customers, market analysis, and examining existing documents.
• Requirement analysis follows requirement gathering.
• Its objective is to thoroughly understand the customer's exact requirements.
• IEEE defines requirement analysis as understanding user needs and refining system requirements (hardware or software).
• Requirement analysis helps to understand, interpret, classify, and organize software requirements, ensuring feasibility, completeness, and consistency.

Requirement Analysis Activities

• Eliciting requirements: understanding customer needs through communication.
• Analyzing requirements: clarifying and making requirements complete, clear, and unambiguous.
• Recording requirements: documenting requirements in different formats (use cases, specifications, etc.).
• Solving questions like: what is the problem? What are the inputs and outputs? What are the complexities?

Requirement Analysis Considerations

• Changes in the environment or technical aspects can impact the process.
• The analyst identifies and resolves problems related to anomalies, inconsistencies, and incompleteness in requirements.

Software Requirement Specification (SRS)

• The output of requirement gathering and analysis is the SRS document.
• It's a detailed description of the software to be developed, describing the system's complete behavior.
• The SRS should define the "what" without describing the "how".
• It serves as a reference document for developers and helps clarify project guidelines.
• It's a contract between the developer and the end-user, mediating potential disagreements.
• It translates customer ideas into formal documents.
• It acts as a black-box specification, focusing on observable behaviors instead of internal details.
• It works as an input to the design phase.
• Enables better communication between customer and developer.
• Facilitates project planning and helps in verification/validation.

Cohesion and Coupling

• Modularity (breaking down a program into smaller modules) is crucial for software development.
• Cohesion measures the internal strength of a module.
• High cohesion means modules focus on a single functionality; low cohesion indicates unnecessary interdependencies within the module.
• Coupling measures the interdependency between modules.
• Low coupling promotes independence among modules.
• High coupling increases the complexity in software development, as modules are highly reliant on each other.
• Types of cohesion include: coincidental, logical, temporal, and procedural, with functional cohesion being the most desirable.
• Types of coupling include: data, stamp, control, common, and content, where data coupling is the least coupled and content coupling is the most coupled.

Characteristics of a Good SRS

• Concise: provides clear, brief information
• Complete: includes all necessary project information
• Consistent: avoids contradictory requirements throughout the project
• Conceptual Integrity: clearly defines and explains the system's concepts
• Structured: well-organized for easy understanding
• Verifiable: able to be confirmed by customers
• Adaptable: permits future changes
• Maintainable: allows for modifications and updates in the future
• Portable: can be applied to similar projects in the future
• Unambiguous: avoids multiple interpretations

Functional and Non-Functional Requirements

• Functional requirements define what the system does.
• Non-functional requirements describe how the system behaves (e.g., quality, reliability).

Communicational Cohesion

• Modules perform multiple, related tasks that operate on the same data. (e.g., functions on an array, queue)

Sequential Cohesion

• Modules perform sequential operations. For instance the input, validation, and output steps in a TPS.

Functional Cohesion

• Modules focus on a single, well-defined task. (e.g., calculation, sorting).