Functional – Non-Functional Requirements


Bennett and Farmer (2002) explained that the functional requirements describe what expected from the system to do and it is referred to as system functionality. The function may represent the unit around which the system will be structured. The functional requirements include the following:

  • Describe a process within the system.
  • Describe the details input or/and output of the system.
  • Describe the details of the data that can be held in the system.

Bennett and Farmer (2002) also explained that the non-functional requirements on the other hand represent the description aspects of the system that explain how well it provides the functional requirements (e.g. business rules, performance requirements, number of users or system availability/system scalability). These include the following:

  • Performance requirement criteria where a desired response time for retrieving data from the system or updating data in the system.
  • Anticipated volumes of data either in terms of what must be stored or in terms of throughput.
  • Security consideration.

During the system analysis process, Bennett and Farmer (2002) explained that the usability requirements should be considered where it enables to ensure that there is a good match between the system that is developed and both the users of that system and the tasks that will undertake when using it. Usability can be specified in terms of measurable objectives. In order to build usability into the system from starting point, the following type of information will be required to be gathered:

  • Characteristics of the users who will use the system.
  • Goals that users are trying to achieve in a system or undertake.
  • A description of the situation that could arise during the system use.
  • Acceptance criteria by which users will judge the system deliverables.

Collecting Requirements

Malik (2009) explained that it’s important for the requirements for a system to be directly driven from the needs of the business process, and as such; insuring the existing of the process model for business in the areas where a particular capability is required to be improved or developed is very critical to achieve success. The advantage of having this model exists for the business is that the requirements collection will be more quickly and more effective in such process. With such approach, the starting point will be the business objectives, methods and quickly found scenarios that required details instead of starting with task-level technical function and work up to describe the user interface that required to be used.

Bridges (2010) explained that a business analyst elicit requirements not gathering requirements since gathering requirements implies to the stakeholders that the business analyst already know the solution to the problem, however in the actual fact is by collecting information, the business analyst is trying to understand the real problem. Once the problem is known, the analysis phase will move into the development requirements phase. That said; it’s important for the analyst to have an elicitation plan that will guide the analyst to the process of requirements development.

Liles (2009) explained that the word elicit expresses more of the job that required from the business analyst since it explains the active roles of such position in collecting requirements. There are many ways to elicit requirements from stakeholders some of these ways are: workshops, interviews, brainstorming, survey/questionnaires or observation. These methods involve three basic activities:

  • Preparation – Where some steps should be designed to prepare for one of the above methods.
  • Conducting – Ensure that the participant understand the purpose of such method to be ready for details and materials that can answer the questions.
  • Follow-up – Where whatever happened in one of the above methods are published to the stakeholders, and to help cover any missing parts from the collection of the requirements process.

In order to start any software development, it is important to understand the problem by defining the functional and non-functional requirements where the functional requirements will be represented in a form that can be easily understood by the developers, stakeholders and software engineers. The most common form of presentation in such stage is using the Unified Modeling Language (UML) where the Use Cases Diagrams will be represented to explain the basic functionalities of the system. Functional requirements focus on the basic functionalities of the system to be developed. Functional requirements may represent data manipulation, calculation, technical details and processing and other specifications that can explain what the system is suppose to achieve. These requirements are related to the Use Case presentation that explains via diagrams what the system is supposed to accomplish. On the other hand, non-functional requirements define how the system must work not what the system actually does (Sales, 2006).

Requirements gathering can use any method that can work and produces the required results which covers the answers to all the questions that can describe the problem. There is no perfect technique for the requirements gathering, however producing clear documentations that can describe the requirements; will give the best chance for the project to be successful. To achieve such goal, the common mistakes that can arise from a lack of understanding or lack of communication should be eliminated (Bauer, 2005). 


Analysts investigating an organization’s requirements should consider the usability requirements list that can be used in many situations to help in the process of collecting requirements and measuring objectives. It is also important for analysts to be able to differentiate between functional requirements and non-functional requirements. While functional requirements describe what a system does, the non-functional requirements describe how well such requirements will be delivered by the system. Finally requirement gathering is a very important process for any successful project, and once such process is complete, it is important that the functional requirements represent in a form that can be easily understood by all the members of the project, and one of these forms is the Use Case via UML diagrams.


Bauer, M. (2005) Requirements Gathering Essentials [Online]. Available from: (Accessed: 12 February 2011).

Bennett, S. & Farmer, R. (2002) Object-Oriented Systems Analysis and Design Using UML. 2nd  ed. UK: McGraw-Hill Education.

Bridges, G. (2010) Requirements Gathering? Elicitation? [Online]. Available from: 12 February 2011).

Liles, J. (2009) Methods for Eliciting – Not Gathering – Requirements [Online]. Available from: (Accessed: 12 February 2011).

Malik, N. (2009) Collecting requirements from business processes [Online]. Available from: (Accessed: 12 February 2011).

Sales, M. (2006) Gathering Requirements Specification: The first steps [Online]. Available from: (Accessed: 12 February 2011).



  1. Fantastic site you have here but I was curious about if you knew of any
    discussion boards that cover the same topics talked about in this article?
    I’d really love to be a part of group where I can get comments from other experienced individuals that share the same interest. If you have any suggestions, please let me know. Kudos!

  2. 2
    qantrim Says:

    Heya i’m for the first time here. I came across this board and I find It really helpful & it helped me out a lot. I’m
    hoping to provide something back and aid others like you aided me.

RSS Feed for this entry

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: