Any software/application development project ends up in the creation of a unique product or a service. However, for the project to succeed, shouldnât the features and functionalities expected in the system uniquely identified?
Yes, they should and are called Functional Requirements!
Â
What are Functional Requirements â Quick Overview
Functional Requirements describes the functionalities, capabilities and activities a system must be able to perform and they specify the overall behavior of the system to be developed.
At a basic level, they specify what any service/product should be able to perform.
Letâs try to understand it better with some simple examples. Functional Requirement for a:
- âKeyâ â Shall be able to lock and open a door
- âPenâ â Should be able to apply ink on a surface
However, since functional requirements are expected to describe all the âfunctionalityâ related aspects of the solution to be developed, they are usually not as simple as the examples above and consists a lot within themselves. For instance – business rules, processes and flows, authorization and security needs, legal/compliance requirements. Since functional requirements define the features and capabilities expected from the solution, they are sometimes called as Solution Requirements.
Functional requirements are generally written in the format “system shall do/perform <followed by the description of the requirement>”.
Examples of functional Requirements
Letâs assume Rob is the owner of RobRolls, a company which manufactures basketballs. Now, Rob wishes to expand his products range and produce baseballs and footballs as well. This requires better management at his manufacturing plant and thus Rob wants an âInventory management systemâ.
The functional requirements for the âInventory management systemâ will be:
- The system shall save the details of the goods available in the warehouse by dividing them into different categories
- The system should maintain tracking of sales of products and inventory levels
- The system should provide alerts when an item in the inventory goes below a threshold level.
- Maintain the balance between too much and too little inventory
- Only authorized persons will have access to the system and the role of the administrator shall be assigned to only one person at a time
- The system should reduce wastage of raw materials while improving cost savings
- The system should provide weekly/monthly selling trend details by analyzing past data
Characteristics of Functional Requirements
- Are given by the users/business stakeholders
- only states âwhatâ the system is expected to do/perform and not âhowâ the system is expected to do that (thatâs in Application design document)
- Are written from the perspective of the system and not from the viewpoint of the user (remember the prefix âThe system should âŚ.â)
- Deal exclusively with the functionalities and features and do not contain any technical requirements within them
- Should be crisp, non-ambiguous and written in non-technical language
- Form the basis of the âfunctional scopeâ of any application or product
Where are Functional Requirements captured?
Functional requirements are documented in a Functional requirement specification (FRS)/ Functional Specification Document (FSD)
Functional requirement specification or Functional Specification Document describes the intended behavior of a system including data, operations, input, output and the properties of the system.
A functional specification document is prepared by a Business Analyst and itâs a detailed, descriptive and precise requirement document. Owing to their NON-technical nature, FRS/FSD are equally used by developers, testers and the business stakeholders of a project.
Donât you wish to take a peek into what all the Functional requirement specification (FRS)/Functional Specification Document (FSD) contain? Hereâs what one contains –
- Product Context: Description of the product or application being developed along with its background and other associated details
- Data Requirements: what type of data could be entered into the system? What is the format of the data? How should this data be stored?
- Business Rules: What are the rules that define the expected functioning of the system? What operations should the system handle? What are the work-flows typical to the system?
- User Interface Requirements: How shall an external user interact with the system? What are the different actions possible on screen? What are the fields and icons available on the screen?
- Authorization and Security Requirements: What all users could interact with the system? What are the different user roles? What are their access permissions?
- Legal/Compliance Requirements: What are the standards and protocols the system must comply with? Are there any government laws applicable? Are there any regulations that must be imposed on the system?
- Performance: How fast the system should perform? What is the maximum load system could handle? What are the factors that might affect performance?
- Dependencies: Is the system dependent upon any external systems? What is the level of interaction between them? How severe are those dependencies?
- Assumptions: A listing of things that are supposed to be true for the system being developed
- Constraints: The known restrictions you have while developing the product. These could be budget constraints, technological constraints or even environmental constraints.
The format of an FRS/FSD could be altered based on the organization policies and needs and sections could be added and deleted based on the system being developed.
Who documents Functional Requirements?
Itâs the sole responsibility of a Business Analyst to elicit and document the functional requirements in a Functional requirement specification (FRS) document / Functional Specification Document (FSD) / Use case / User story.
The general flow of activities performed by a Business Analyst to documents functional requirements is:
- Make a listing of all the functionalities, features and capabilities of the application being developed by studying the artifacts of the project. These artifacts include â Project charter, Project vision document, Statement of work (SOW), Business requirement document (BRD)
- Identify the key business stakeholders of the project – These are the people who decide and defines the functionalities of the application/product being developed
- Discuss each feature and functionality with the business stakeholders, in-depth
- Elicit any hidden requirements while gaining consensus and approval on the identified functional requirements
- Record each functional requirement in the document appropriate as per the organization policies
- Share the documents with the project stakeholders for feedback and approvals
Accurately defining and documenting the Requirements is very critical for the success of any project. Learn more about the Key documents prepared by a Business Analyst followed by this Short guide on Business Requirements.