Jump to content

User:Metteduijnhouwer/Functional requirement

From Wikipedia, the free encyclopedia
Functional requirements
Process typeSoftware requirements
Industrial sector(s)Software development
Product(s)ISO 16175-1 (2020)

Functional requirements capture the system’s intended behavior in software engineering and systems engineering.[1] It describes what kind of service the software must offer. This is done by defining a function of a system or its component. A function is nothing but inputs to the software system, its behavior, and outputs.[2] This behavior may be expressed as services, tasks, or functions the system is required to perform.[1]

By prescribing what services the software-to-be should provide, functional software requirements help you to capture the intended behaviour of the system and the intended software effects on the environment.[3] Functional requirements are a type of software requirement.[4] Software requirements are used to describe the software-to-be and the statements describe shared phenomena. This differs from system requirements, which are related to environmental phenomena and describe the software-to-be together with other system components.

As defined in requirements engineering, functional requirements specify particular results of a system. This should be contrasted with non-functional requirements, which specify overall characteristics such as cost and reliability. Functional requirements drive the application architecture of a system.

Generally, functional requirements are expressed in the form "system must do <requirement>," while non-functional requirements take the form "system shall be <requirement>."[5] The plan for implementing functional requirements is detailed in the system design, whereas non-functional requirements are detailed in the system architecture.

Behavioral-and functional requirements

[edit]

Functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describe all the cases where the system uses the functional requirements, these are captured in use cases. Functional requirements are supported by non-functional requirements (also known as "quality requirements"), which impose constraints on the design or implementation (such as performance requirements, security, or reliability).

The intended behavior of the system is expressed in the functional requirement as services, tasks or functions the system is required to perform. Software product developers make a distinction between necessary functionalities for a system or features which can differentiate the system from competitors’.[1]

A common way to specify the behavior of the system is by generating use cases. In use cases, the behavior between the actors can easily be visualized by generating actions and relationships.[1] Later on, more information will be given about use cases.

Functional vs non-functional requirements

[edit]

Functional requirements define a function of a system or its component. Functional requirements are in contrast with non-functional requirements (also known as "quality requirements"), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). Generally, functional requirements are expressed in the form "system must do <requirement>," while non-functional requirements take the form "system shall be <requirement>".[6] The plan for implementing functional requirements is detailed in the system design, whereas non-functional requirements are detailed in the system architecture.[6][7] As defined in requirements engineering, functional requirements specify particular results of a system. This should be contrasted with non-functional requirements, which specify overall characteristics such as cost and reliability. Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system.[7]

In the table underneath there are a few differences between functional and non-functional requirements.[8]

Differences between functional and non-functional requirements
Parameters Functional Requirement Non-Functional Requirement
What it is Verb Attributes
Requirement It is mandatory It is non-mandatory
Capturing type It is captured in use case It is captures as a quality attribute
End result Product feature Product properties
Capturing Easy to capture Hard to capture
Objective Helps you verify the functionality of the software Helps you to verify the performance of the software
Area of focus Focus on user requirement Concentrates on the user's exprectation
Documentation Describe what the product does Describes how the product works
Type of Testing Functional Testing like System, Integration, End to End, API testing, etc. Non-functional Testing like Performance, Stress, Usability, Security testing, etc.
Test Execution Test Execution is done before non-functional testing After the functional testing
Product Info Product Features Product Properties

Advantages

[edit]

Using functional requirements comes with benefits for the software engineering process.[8]

  • Defining functional requirements helps to clearly decide what the expected system behavior should be.
  • While gathering functional requirements, errors can be caught. In this stage, it is the cheapest to fix errors.
  • After all functional requirements have been documented, it helps to define the functionality of the (sub)system.
  • Writing down functional requirements helps with checking if all the required functionalities are provided by the system.

Disadvantages

[edit]

Using functional requirements can also come with disadvantages to the software engineering process.[9]

  • Unclear requirements lead to a poorly defined scope, which can cause difficulties from the beginning of the project. This could lead to delays and increasing costs.
  • Most of the time, visualizations are necessary to make it understandable for non-technical stakeholders.

Writing functional requirements

[edit]

Functional requirements must always be written down in detail; they cannot simply be assumed by developers or managers as part of their everyday work activities. If you don’t write down your functional specifications explicitly, you risk missing important details that could later lead to misunderstandings between stakeholders and developers or even bugs in the final product. Therefore, all stakeholders involved in software development projects must agree on exactly what functionality their products should have before starting actual development work. This process is called specification definition. Once specification definitions have been agreed upon among all stakeholders involved in a project, they can then serve as guidelines for developers who are tasked with implementing.[10]

Functional specifications are written down as text documents. These documents contain descriptions of all scenarios that must be implemented in a product together with preconditions and postconditions for each scenario. A software requirement specification document is therefore essentially a set of scenarios describing how a product should behave when it is used by its intended users.

Functional requirements are typically captured in the form of user stories or use cases. These terms are sometimes used interchangeably, but they actually mean slightly different things.[11]

User stories

[edit]

User stories are a lightweight method for quickly capturing the “who”, “what” and “why” of a product’s requirements.[11] User stories are short, and each element usually contains less than 10 or 15 words. User stories are “to-do” lists that help you identify the steps along the project path. They help ensure that your process, and the resulting product, meet your requirements. It is also important to state that a user story is singular, only one element is mentioned.

How to make a user story?

[edit]
The format of a user story

User scenario's are set up in a specific way:

  • Who it is for?
  • What it expects from the system?
  • Why it is important (optional?)?

User story consist of 3 different parts:

  • Role – The user should be an actual human who interacts with the system.
  • Action – The behavior of the system should be written as an action.
  • Benefits – The benefit should be a real-world result that is non-functional or external to the system.

Examples

[edit]

To create a better understanding of a functional requirement written down as a user story, a few examples are given: [12]

  • Example #1: "As a customer, I want to view items, so I can have an overview of the possible items to buy."
  • Example #2: “As a customer about to make a purchase, I need to be able to submit my credit card details and get authorization so that I can complete my checkout.”
  • Example #3: "As a customer, I need to authenticate myself so that I can see my account details and past orders."
  • Example #4: "As a security engineer, I want all all customers to authenticate themselves, so that it reduces the chance of security breaches."
  • Example #5: "As someone from the management team, I want my customers to be able to search for products, so that they can find the ones they want to buy."

Use cases

[edit]

Functional requirements can also be written down as use cases. Use cases have quickly become a widespread practice for capturing functional requirements. This is especially true in the object-oriented community where they originated, but their applicability is not limited to object-oriented systems.[1] Use cases capture the functional requirements of the system. Since the architecture must support the functional requirements of current and planned systems, it is important that the architects understand what is required, at least at the level of abstraction relevant to architecture.

Each use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system.[13] An actor may be a class of users, roles users can play, or other systems. These can be separated into primary and secondary actors.[14] A primary actor has a goal requiring the assistance of the system and the secondary actor is one from which the system needs assistance. Thus, use cases capture who (actor) does what (interaction) with the system, and for what purpose (goal), without dealing with system internals.[1] Use cases are often visualized in a use case diagram. Later on, use case diagrams are explained.

Examples

[edit]

To create a better understanding of a functional requirement written down as use cases, a few examples are given: [10]

  • Example #1: A customer shall be able to log into the system using their username and password. The function of this requirement is ‘to log into the system’ and the behavior is “The system shall allow a user to log in using their username and password.”
  • Example #2: The customer shall be able to make a purchase on the webshop. The function of this requirement is 'to be able to buy something' and the behavior is "The system shall allow the user to buy something".
  • Example #3: The system shall send a confirmation email to the user after they have successfully placed an order. The  function is “send confirmation email” and the behavior is “The system shall send a confirmation email to the user after they have successfully placed an order.”

The examples show that a functional requirement is a specific statement of what the system should do.

SMART

[edit]

It doesn't matter in what way you write functional requirements, it is important to adhere to the SMART principles.[15] This means that the requirements should:

  • Specify exactly what you want the system to do
  • Be measurable
  • Be achievable within a given timeframe
  • Be relevant to the business goals
  • Be time-bound

Following the guidelines set by the SMART principle will help to make clear functional requirements, to make sure the development team can build the correct product.

Visualization

[edit]

In some cases, a requirements analyst generates use cases after gathering and validating a set of functional requirements.[16] The hierarchy of functional requirements collection and change, broadly speaking, is: user/stakeholder request → analyze → use case → incorporate. Stakeholders make a request; systems engineers attempt to discuss, observe, and understand the aspects of the requirement; use cases, entity relationship diagrams, and other models are built to validate the requirement; and, if documented and approved, the requirement is implemented/incorporated.

Underneath, a few of these visualizations of the functional requirements are mentioned.

Use case diagram

[edit]
Example of a use case diagram
Example of a use case diagram

When the use cases are made, the structure is graphically summarized in a use case diagram [13], which also shows which actors interact with which use cases. Use case diagrams (UCDs) are widely used to describe software product requirements and desired functionality.[2] UCDs are employed in UML (Unified Modeling Language), a standard notation for modeling real-world objects and systems.[17]

UML class diagram

[edit]

UML (Unified Modeling Language) is the de-facto standard formalism for the analysis and design of the software.[18] One of the most important components of UML are class diagrams, which model the information on the domain of interest in terms of objects organized in classes and relationships between them.[19]

Entity Relationship Diagram (ERM)

[edit]

An entity relationship diagram (ERD), also known as an entity-relationship model, is a graphical representation that depicts relationships among people, objects, places, concepts, or events within an information technology (IT) system.[20]


See also

[edit]

References

[edit]
  1. ^ a b c d e f Malan, R., & Bredemeyer, D. (2001). Functional requirements and use cases. Bredemeyer Consulting.
  2. ^ a b Fulton R, Vandermolen R (2017). "Chapter 4: Requirements - Writing Requirements". Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254. CRC Press. pp. 89–93. ISBN 9781351831420. Retrieved 12 January 2023.
  3. ^ Glinz, M. (2007, October). On non-functional requirements. In 15th IEEE international requirements engineering conference (RE 2007) (pp. 21-26). IEEE.
  4. ^ "Functional documents for computer systems". Science of Computer Programming. 25 (1): 41–61. 1995-10-01. doi:10.1016/0167-6423(95)96871-J. ISSN 0167-6423.
  5. ^ Loucopoulos, P. (2005). "Chapter 4: Requirements Engineering". In Clarkson J, Eckert C (eds.). Design Process Improvement: A Review of Current Practice. Springer-Verlag. pp. 116–139. ISBN 9781846280610.
  6. ^ a b Adams, K.M. (2015). "3.2 Definitions for Functional and Non-Functional Requirements". Non-functional Requirements in Systems Analysis and Design. Springer. pp. 45–50. ISBN 9783319183442.
  7. ^ a b Jönsson P, Lindvall M (2006). "Chapter 6: Impact Analysis". In Aurum A, Wohlin C (eds.). Engineering and Managing Software Requirements. Springer Science & Business Media. pp. 117–42. ISBN 9783540282440.
  8. ^ a b Martin, M. (2022, 26 november). Functional vs Non Functional Requirements. Guru99. https://www.guru99.com/functional-vs-non-functional-requirements.html
  9. ^ Gunsolly, Jacob (2021-07-23). "Functional vs. Non-Functional Requirements". AccelaTest. Retrieved 2023-01-23.
  10. ^ a b Wiegers, K., & Beatty, J. (2013). Software requirements. Pearson Education.
  11. ^ a b vpadmin (2022-02-28). "Capturing Functional Requirements with Use Cases and User Stories". Cybermedian (in Vietnamese). Retrieved 2023-01-21.
  12. ^ "Build an eCommerce Store with a User Story | Object Edge". www.objectedge.com. Retrieved 2023-01-21.
  13. ^ a b UML Specification. http://www.rational.com/ We have referenced V1.3 Alpha R5, March 1999 in this paper.
  14. ^ Cockburn, Alistair, “Structuring Use Cases with Goals”, Journal of Object-Oriented Programming, Sep- Oct, 1997 and Nov-Dec, 1997.
  15. ^ Mannion, M., & Keepence, B. (1995). SMART requirements. ACM SIGSOFT Software Engineering Notes, 20(2), 42-47.
  16. ^ MITRE Corporate Communications and Public Affairs. "Requirements Engineering: Eliciting, Collecting, and Developing Requirements". The MITRE Systems Engineering Guide. MITRE Corporation. pp. 304–13. ISBN 9780615974422. Retrieved 15 June 2018.
  17. ^ A. Egyed. A scenario-driven approach to traceability. In ICSE, pages 123–132, 2001.
  18. ^ M. Fowler, K. Scott, UML Distilled—Applying the Standard Object Modeling Laguage, Addison-Wesley, Reading, MA, 1997.
  19. ^ M. Fowler, K. Scott, UML Distilled—Applying the Standard Object Modeling Laguage, Addison-Wesley, Reading, MA, 1997.
  20. ^ "What is Entity Relationship Diagram (ERD)? | Definition from TechTarget". Data Management. Retrieved 2023-01-23.
[edit]
  • Use Cases at GSA's Usability.gov
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Metteduijnhouwer/Functional_requirement&oldid=1136026658"