##Functional requirements
1. Functional requirements specifies a function that a system or system component must be able to perform. It can be documented in various ways. The most common ones are written descriptions in documents, and use cases.
2. Use cases can be textual enumeration lists as well as diagrams, describing user actions. Each use case illustrates behavioural scenarios through one or more functional requirements. Often, though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive the functional requirements that must be implemented to allow a user to perform each use case.
3. Functional requirements is what a system is **supposed to accomplish**. It may be - Calculations - Technical details - Data manipulation - Data processing - Other specific functionality
4. A typical functional requirement will contain a unique name and number, a brief summary, and a rationale. This information is used to help the reader understand why the requirement is needed, and to track the requirement through the development of the system. ##Non-functional requirements [LBushkin](https://stackoverflow.com/a/16476014/1045444) have already explained more about Non-functional requirements. I will add more.
1. Non-functional requirements are any other requirement than functional requirements. This are the requirements that specifies criteria that can be used to **judge the operation of a system, rather than specific behaviours**.
2. Non-functional requirements are in the form of **"system shall be <requirement>"**, an overall property of the system as a whole or of a particular aspect and not a specific function. The system's overall properties commonly mark the difference between whether the development project has succeeded or failed.
3. Non-functional requirements - can be divided into two main categories:
- **Execution qualities**, such as security and usability, which are observable at run time. - **Evolution qualities**, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system. 4. Non-functional requirements place restrictions on the product being developed, the development process, and specify external constraints that the product must meet. 5. The [IEEE-Std 830 - 1993](http://www.utdallas.edu/~chung/RE/IEEE830-1993.pdf) lists 13 non-functional requirements to be included in a Software Requirements Document.
> 1. Performance requirements > 2. Interface requirements > 3. Operational requirements > 4. Resource requirements > 5. Verification requirements > 6. Acceptance requirements > 7. Documentation requirements > 8. Security requirements > 9. Portability requirements > 10. Quality requirements > 11. Reliability requirements > 12. Maintainability requirements > 13. Safety requirements
Whether or not a requirement is expressed as a functional or a non-functional requirement may depend:
- on the level of detail to be included in the requirements document - the degree of trust which exists between a system customer and a system developer.
Ex. A system may be required to present the user with a display of the number of records in a database. This is a functional requirement. How up-to-date [update] this number needs to be, is a non-functional requirement. If the number needs to be updated in real time, the system architects must ensure that the system is capable of updating the [displayed] record count within an acceptably short interval of the number of records changing.
References:
1. [Functional requirement](https://en.wikipedia.org/wiki/Functional_requirement) 2. [Non-functional requirement](https://en.wikipedia.org/wiki/Non-functional_requirement) 3. [Quantification and Traceability of Requirements](http://www.idi.ntnu.no/grupper/su/fordypningsprosjekt-2005/eide-fordyp05.pdf)

Just some personal experience, I use this architecture mentioned in Eric Even's DDD book: ![enter image description here][1]
In short:
1) Interfaces is consist of components that are responsible for interacting with user(a real endpoint user or a remote machine), web mvc controller, web view object, remote facade for example.
2) Application defines what features your system provide. I think it's highly coupled with the Interfaces layer. If you define a method in Application, often you need to add a Interfaces class/method as well. But several Interfaces class/method may depends on the same Application object, you provide both a web ui and a web service for place order, for example.
3) Domain, the most stable part of your system. For example, in language context, word/sentence are Domain objects that have their own meaning, I oganized them to form this answer. So you could consider me as an Application object although not a good one 'cause I don't speak fluent English :P
4) Infrstructure, actually I don't think this is a layer, it implements all the above three. For example, you have an interface OrderRepository in your domain layer and you could implement it using some orm framework (persistence infrastructure). Most of my infrastructure objects are adapters (implements an interface in Application/Domain/Interfaces layer and adapt to external components like database, messaging provider, mail server and so on).
Hope this helps.
**Update for infrastructure intent:**
This is one of our project's package view.
![enter image description here][2]
There are some adapters in the infrastructure layer:
1.infrastructure.channel.XXX each package contains several adapters to a particular online payment provider.
2.infrastructure.payment contains adapters to a payment system of our organization but it is in another bounded context. We use MakePaymentService (a domain service) to decouple the payment system from other part of this system.
3.infrastructure.messaging contains adapters to messaging provider, we provide a jms implement for PaymentWasMadeNotifier (an application service)
4.infrastructure.persistence contains adapters to database, we provide a iBATIS(a orm framework in Java) for Domain Repositories.
These above adapters all implements some interface s in Application/Domain layers. Below is some "service", but they are generic:
5.infrastructure.mail
6.infrastructure.logging
7.infrastructure.security
These package above expose some interface and implementations. For example, we provide a MailManager interface, it's agnositic to particular features. The subject, content is up to the application layer/domain layer. We provide an implementation using javamail in the same package.
public interface MailManager { void send(String subject, String content); }

8.infrastructure.time this one is special, we have some cron job in this system, so we introduce a Clock to decouple the time from job setting and therefore its friendly to tests (Just imagine that we have a job, it should be launched at 25th, every month, we can test the job by setting current time to 25th, even if it's 1st today). We provide an implementation in persistence package(For some reasons, we need to use database' time in production)
public interface Clock { Date now(); }
So my understanding is: infrastructure provides service/implementations to your other three layers, but they are technology specific. For example, Subject, content, from, to, cc are domain models in mailing context, but they are infrastructures in your domain context. The infrastructure layer separate them for you.

[1]: http://i.stack.imgur.com/qWPgc.jpg [2]: http://i.stack.imgur.com/V4TS2.jpg