Functional Requirements, at one time, were very popular. They were included as part of the original Rational
Unified Process (RUP) developed by a company called Rational Software
Corp. When IBM acquired Rational Software (2002 / 2003) IBM removed the functional
requirements from RUP. This approach created a communication gap between the stakeholders and the technical team implementing the requirements. Without the functional requirements inaccurate assumptions were made on both sides (i.e., stakeholders assumed developers were thinking like them; developers assumed stakeholders were thinking like them).
This post provides information on functional requirements including what a functional requirement is, how functional requirements are managed and the document (referred to as the Software Requirements Specification or SRS) used to describe functional requirements.
A functional requirement is the lowest-level of software requirement among the software requirement types. It should not be confused with a non-functional requirement. Non-functional requirements do NOT convey software functionality, which is why they are called non-functional requirements.
A functional requirement states a single action that software can perform. However, unlike a use case, the functional requirement states a more specific system behavior or limitation as it pertains to user-to-system interaction or system-to-system interaction. The single action can be derived from a:
Let's use an example where a stakeholder communicates the following business rule: All employee timesheets must be submitted by COB (Close of Business) on Friday. And, let's say we are building a Time Management System. Employees will use the Time Management System to add the following to their timesheets: project name (i.e., US Gov Intranet), project task (i.e., Gather Requirements, Manage Requirements, Analyze Requirements, Design, etc.,) and hours spent on a task by date. The organization is building the Time Management System because the CIO wants to manage project costs associated with the number of hours employees spend on a project. Currently not all employees submit a timesheet by COB. With 150 employees on staff it's time-consuming for HR to figure out who didn't submit a timesheet.
We'll begin this portion of the project by adding "BR1. All employee timesheets must be submitted by COB (Close of Business) on Friday" to our requirements management system as a business rule. We have a use case named: UC3. Submit a Timesheet. We trace BR1 to UC3. And, UC3 is already traced to the following feature: FE1. Manage Project Task Hours & Approvals. FE1 includes all requirements that pertain to submitting and approving timesheets. (Note, additional information about tracing requirements is included in the Requirements & Traceability post.)
The Time Management System cannot force every employee to submit his/her timesheet by COB Friday. But, the stakeholder wants us to define requirements so the System will enforce the business rule. We can use functional requirements to help the stakeholder achieve her objective, which is to ensure a timecard is submitted for every employee by COB Friday. Below is a list of requirements that will ensure the business rule is met:
1. After 7:00 pm (EST) every Friday, the System shall access the online company calendar to identify every IT Department staff member out on vacation AND who did not submit a timesheet.
1.1. The system shall create a timesheet for every person on vacation who did not submit a timesheet.
1.2. The System shall record a 40-hour work week for each employee out on vacation for the week.
1.3. The System shall set the Project code to "Vacation – Paid time off."
2. After creating timesheets for employees on vacation, the System shall create timesheets for all other employees who did not submit a timesheet.
2.1. The System shall record a 40-hour work week for each employee who did not submit a timesheet.
2.2. The System shall set the project code to "Miscellaneous – Unpaid time off."
3.3. The System shall automatically mark these timesheets as "not approved".
3. The System shall send a notification to all employees for whom a timesheet is created.
4. The system shall send a notification to the project manager associated with all employees for whom a timesheet was created and the timesheet was marked "not approved".
5. The System shall send HR a list of all persons for whom a timesheet was created and the timesheet was marked "not approved"
Notice that each requirement states an action that can be performed using the software. And, lastly, notice the difference between a use case and a functional requirement. A functional requirement states a single specific action at a lower level than a use case.
Functional requirements are added to the requirements management software just like use cases, features and business rules. In this example, IBM Rational RequisitePro is used to manage the functional requirements. The functional requirements are traced to use cases. In addition, a shorter name is assigned to the functional requirements to easily tell on functional requirement from the next. And, the letter ID used for the functional requirement is "FR".
Functional requirements are added to the requirements management system and traced to the applicable use case. If the functional requirement is used to enforce or implement a business rule the functional requirement is traced to the same use case to which the business rule is traced. In this example, the functional requirements are traced to UC3. Submit a Timesheet . Tracing is what shows everyone on the team the relationship amongst requirements (see the Requirements & Traceability post).
While use cases are usually defined in a use case specification, functional requirements are typically added to the Software Requirements Specification (SRS). Or, an organization using the SDLC may add them to a different document. If creating the SRS, it usually includes a chapter called System Design. Under System Design is a heading that includes the Feature name. In this example, the second-level heading under System Design would be FE1. Manage Project Task Hours & Approvals. The third-level heading is the use case, which in this example is UC3. Submit a Timesheet. The functional requirement is then added as the fourth-level heading. Following is a screen capture that shows a partial table of contents.
-------------------------
-------------------------
The functional requirements are added as headings to make document review easier for stakeholders. Notice a stakeholder can review the table of contents and choose what functional requirements he or she wishes to review in detail. This is particularly useful as requirements are changed and only select requirements must be reviewed.
Under the functional requirement heading the Priority is indicated along with the Stimulus/Response Sequences and the Requirement Details. The Stimulus/Response Sequences table defines the stimulus that starts the process for the functional requirement. Next, the response to the stimulus is added to the Response column. The stimulus/response details are added until the functional requirement is met. The Requirement Details section is used to add any additional information about the functional requirement. The following picture shows the sections under the functional requirement heading.
-------------------------
-------------------------
With functional requirements added, the test team or Systems Analyst would create not just a Test Case Specification but also a Test Procedure Specification. This approach ensures all of the requirements are tested for correct implementation
While functional requirements define functionality associated with software; non-functional requirements are just the opposite. Non-functional requirements are requirements that do not add functionality to the software product. In other words, if you read a requirement that you CANNOT sit in front of a software application and perform--it is most likely a non-functional requirement.
This post provides information on functional requirements including what a functional requirement is, how functional requirements are managed and the document (referred to as the Software Requirements Specification or SRS) used to describe functional requirements.
Functional Requirements Overview
A functional requirement is the lowest-level of software requirement among the software requirement types. It should not be confused with a non-functional requirement. Non-functional requirements do NOT convey software functionality, which is why they are called non-functional requirements.
A functional requirement states a single action that software can perform. However, unlike a use case, the functional requirement states a more specific system behavior or limitation as it pertains to user-to-system interaction or system-to-system interaction. The single action can be derived from a:
- Business rule the software must enforce or support; or,
- A system behavior stakeholders want the software to support or enforce (i.e., limit the number of characters that can be entered into a textbox, display a confirmation message when the cancel button is clicked, set the request to Submitted when the record is saved, etc.)
Let's use an example where a stakeholder communicates the following business rule: All employee timesheets must be submitted by COB (Close of Business) on Friday. And, let's say we are building a Time Management System. Employees will use the Time Management System to add the following to their timesheets: project name (i.e., US Gov Intranet), project task (i.e., Gather Requirements, Manage Requirements, Analyze Requirements, Design, etc.,) and hours spent on a task by date. The organization is building the Time Management System because the CIO wants to manage project costs associated with the number of hours employees spend on a project. Currently not all employees submit a timesheet by COB. With 150 employees on staff it's time-consuming for HR to figure out who didn't submit a timesheet.
We'll begin this portion of the project by adding "BR1. All employee timesheets must be submitted by COB (Close of Business) on Friday" to our requirements management system as a business rule. We have a use case named: UC3. Submit a Timesheet. We trace BR1 to UC3. And, UC3 is already traced to the following feature: FE1. Manage Project Task Hours & Approvals. FE1 includes all requirements that pertain to submitting and approving timesheets. (Note, additional information about tracing requirements is included in the Requirements & Traceability post.)
Translating Business Rules into Functional Requirements
The Time Management System cannot force every employee to submit his/her timesheet by COB Friday. But, the stakeholder wants us to define requirements so the System will enforce the business rule. We can use functional requirements to help the stakeholder achieve her objective, which is to ensure a timecard is submitted for every employee by COB Friday. Below is a list of requirements that will ensure the business rule is met:
1. After 7:00 pm (EST) every Friday, the System shall access the online company calendar to identify every IT Department staff member out on vacation AND who did not submit a timesheet.
1.1. The system shall create a timesheet for every person on vacation who did not submit a timesheet.
1.2. The System shall record a 40-hour work week for each employee out on vacation for the week.
1.3. The System shall set the Project code to "Vacation – Paid time off."
2. After creating timesheets for employees on vacation, the System shall create timesheets for all other employees who did not submit a timesheet.
2.1. The System shall record a 40-hour work week for each employee who did not submit a timesheet.
2.2. The System shall set the project code to "Miscellaneous – Unpaid time off."
3.3. The System shall automatically mark these timesheets as "not approved".
3. The System shall send a notification to all employees for whom a timesheet is created.
4. The system shall send a notification to the project manager associated with all employees for whom a timesheet was created and the timesheet was marked "not approved".
5. The System shall send HR a list of all persons for whom a timesheet was created and the timesheet was marked "not approved"
Notice that each requirement states an action that can be performed using the software. And, lastly, notice the difference between a use case and a functional requirement. A functional requirement states a single specific action at a lower level than a use case.
Managing Functional Requirements
Functional requirements are added to the requirements management software just like use cases, features and business rules. In this example, IBM Rational RequisitePro is used to manage the functional requirements. The functional requirements are traced to use cases. In addition, a shorter name is assigned to the functional requirements to easily tell on functional requirement from the next. And, the letter ID used for the functional requirement is "FR".
Documenting Functional Requirements - the SRS
Functional requirements are added to the requirements management system and traced to the applicable use case. If the functional requirement is used to enforce or implement a business rule the functional requirement is traced to the same use case to which the business rule is traced. In this example, the functional requirements are traced to UC3. Submit a Timesheet . Tracing is what shows everyone on the team the relationship amongst requirements (see the Requirements & Traceability post).
While use cases are usually defined in a use case specification, functional requirements are typically added to the Software Requirements Specification (SRS). Or, an organization using the SDLC may add them to a different document. If creating the SRS, it usually includes a chapter called System Design. Under System Design is a heading that includes the Feature name. In this example, the second-level heading under System Design would be FE1. Manage Project Task Hours & Approvals. The third-level heading is the use case, which in this example is UC3. Submit a Timesheet. The functional requirement is then added as the fourth-level heading. Following is a screen capture that shows a partial table of contents.
-------------------------
-------------------------
The functional requirements are added as headings to make document review easier for stakeholders. Notice a stakeholder can review the table of contents and choose what functional requirements he or she wishes to review in detail. This is particularly useful as requirements are changed and only select requirements must be reviewed.
Under the functional requirement heading the Priority is indicated along with the Stimulus/Response Sequences and the Requirement Details. The Stimulus/Response Sequences table defines the stimulus that starts the process for the functional requirement. Next, the response to the stimulus is added to the Response column. The stimulus/response details are added until the functional requirement is met. The Requirement Details section is used to add any additional information about the functional requirement. The following picture shows the sections under the functional requirement heading.
-------------------------
-------------------------
With functional requirements added, the test team or Systems Analyst would create not just a Test Case Specification but also a Test Procedure Specification. This approach ensures all of the requirements are tested for correct implementation
Functional Requirements versus Nonfunctional Requirements
While functional requirements define functionality associated with software; non-functional requirements are just the opposite. Non-functional requirements are requirements that do not add functionality to the software product. In other words, if you read a requirement that you CANNOT sit in front of a software application and perform--it is most likely a non-functional requirement.
Examples of non-functional requirements include requirements that
outline the requirements for the technical documentation. Another example is
training requirements for the end-user. System requirements are another type of
non-functional requirements. System requirements state the minimum version of an
operating system or minimum hardware requirements needed to run a software product.
For example, a software product might require Windows XP or higher as the
operating system. Notice in each example, it is not possible for a user or system to perform the stated requirements. There are also non-functional requirements that define that allowed downtime for software maintenance and so on. Most non-functional requirements are added to the Supplementary Specification. Although some may be included in the Vision document and the Software Requirements Specification.
