Requirement Analysis is critical to the success of any project but even more important for custom software. In capturing business requirements for customized software development the most difficult part is not the act of recording what the users want; it is the exploratory, developmental activity of helping users figure out what they want.

Conceptually, Requirements Analysis includes three types of activities:

• Requirement Capture: the task of communicating with all stakeholders to determine what their requirements are.
• Requirement Analysis: the task of making the stated and unstated requirements clear, complete, unambiguous and detailed enough.
• Documenting Requirements: Requirements may be documented in various forms, such use cases, process specifications, software requirements specification (SRS), Functional Specifications (FS) etc…

Analyzing Business requirements for software development is a process during which all stakeholders are identified and the following are understood for each of them

•  Why the need for the software development?

•  Relationships between people and their environments

•  Implications of the new systems

•  Behavioral requirements from the custom software (Functional )

•  Operational Requirements from the custom software (Non-Functional)

Business Analysts / Requirement Analyst can employ several techniques to elicit business requirements from the customer for the items mentioned above. This includes things as holding interviews, holding focus groups, creating requirements lists, prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact business requirements of the all stakeholders involved, so that software that meets the business needs is produced.

Business requirements for software development must be measurable, testable, and defined to a level of detail sufficient for system design. Business requirements can be Functional and Non Functional.

Functional Requirements

Functional requirements specify specific behaviors of a system. They define the internal workings of the custom software: that is, the technical details, data manipulation and processing, work flow and other specific functionality.

Some Typical examples of Functional Requirements are:

• Source of input and destination of output
• exact sequencing of operations
• Screen formats and organization 
• validity checks on inputs 
• responses to abnormal situations, including error handling and recovery
• units of measure
• interaction with other external systems / softwares

Non Functional Requirements

Non functional requirements  are those which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. Non-functional requirements are often called "constraints", "quality attributes" and "quality of service requirements".

Some Typical examples of Non-Functional Requirements are:

• Availability
• Dependency on other parties
• Documentation
• Efficiency (resource consumption for given load)
• Extensibility (adding features, and carry-forward of customizations at next major version upgrade)
• Legal and licensing issues
• Maintainability
• Performance / Response time
• Platform compatibility
• Reliability
• Resource constraints (processor speed, memory, disk space, etc…)
• Robustness
• Scalability (horizontal, vertical)
• Security
• Software, tools, standards etc. Compatibility
• Stability
• Support issues
• Usability by target user community