Menu

Requirement Analysis in SDLC

Requirement Analysis in SDLC

Functional vs Non-Functional Requirements

Aspect

Functional Requirements

Non-Functional Requirements

DefinitionDescribe what the system should do, including its features and functions.Describe how the system should perform, including quality, performance, and constraints.
FocusSystem functionality and business operations.System performance, reliability, usability, security, and other quality attributes.
Example (Shopping App)Users can log in, search products, add items to the cart, and place orders.The app should load quickly, remain secure, and support many users at the same time.
TestingEasier to test because you can verify whether a feature works as expected.More difficult to test because aspects like usability, scalability, and performance often require specialized testing.
PurposeEnsures the system provides the required features.Ensures the system delivers a good user experience and meets quality standards.
ImportanceDefines the core functionality of the application.Ensures the application is fast, reliable, secure, and easy to use.

How to Gather and Document Requirements

Step 1: Talk to Stakeholders

Meet with the people who will use, manage, or fund the software to understand what they need.

Step 2: Gather Requirements Using Different Techniques

Technique

Purpose

InterviewsTalk directly with stakeholders or users to understand their needs and expectations.
SurveysSend questionnaires to collect feedback from a larger group of users.
WorkshopsConduct group sessions to discuss ideas, brainstorm features, and gather feedback.

Step 3: Document the Requirements

After gathering all the information, document it in a Software Requirements Specification (SRS).

The SRS serves as the main reference document for the entire development team throughout the project.

Step 4: Write Clear and Specific Requirements

When creating the SRS:

  • Use simple and clear language.
  • Be specific about each requirement.
  • Avoid vague or ambiguous statements that could lead to misunderstandings between stakeholders and developers.

Step 5: Add Visual Representations

To make requirements easier to understand, many teams include:

  • Diagrams to visualize the system.
  • Use cases to show how users interact with the system.
  • User stories to describe features from the user's perspective.

These visuals help ensure everyone interprets the requirements in the same way.