The purpose of software requirements analysis is to elicit the real needs of the customer, user, and other stakeholders, and to gain a clear and comprehensive understanding of the problem domain and the system's desired features. This enables software requirements to be defined that specify the system's functionality and performance characteristics, interfaces to other sub-systems and modules to be identified, and any design constraints to be determined.

The identification and description of software requirements helps establish and maintain agreement on what the system should do, and why. From this basis, estimations for cost and time to develop the system can be derived. Delimiting the system in this manner, with clearly stated software requirements, helps the development team interpret and better understand the system's functionality and attributes, enabling them to make appropriate trade-offs and design decisions.

Analysing software requirements typically involves the following tasks:

1. Problem recognition - understand the system in context and recognise the fundamental elements, as the customer, user, and other stakeholders perceive them.
2. Problem evaluation and solution synthesis:

• Evaluate the flow and content of information
• Define and elaborate all software functions
• Understand software behaviour in the context of events that affect the system
• Establish system interface characteristics
• Uncover design constraints

Each of these tasks serves to describe the problem so that an overall approach or solution can be synthesised.

1. Software modeling - create models that help understand the data, control flow, functional processing, behavioural operation, and information content.
2. Specification - provide a representation of the system that can be reviewed and approved by the customer. Validation criteria should also be specified and used later as a basis for acceptance testing.

Types of requirements

The following categories provide a template for the elicitation of requirements:

1. Functional requirements specify the actions a system must perform. They are used to describe the behaviour of a system using input and output conditions.
2. Non-functional requirements specify the attributes of a system that are not directly addressed by the business functionality.

• Usability requirements address the human factors, e.g. aesthetics and ease of use, and the consistency of the user interface, user manuals, and other materials.
• Reliability requirements address frequency and severity of failures, recoverability, and predictability.
• Performance requirements impose constraints on the functional requirements, e.g. the transaction rate, availability, response time, recovery time, or the memory usage with which a given action must be performed.
• Supportability requirements address testability, maintainability, and other qualities required to keep the system current once operational.

Specifying requirements with use cases

Use case modeling is a powerful technique used to express the detailed functional requirements of a system using simple threads of user-system interactions. Non-functional requirements can be captured in supplementary specifications, e.g. the user interface design can be visualised using storyboards. The use case model is an ideal medium for communicating the required system functionality among all the project's stakeholders. The use cases are a prevalent source of information used during the analysis, design, implementation, and testing phases of a project.