Jump to content

User:Metteduijnhouwer

From Wikipedia, the free encyclopedia

Functional requirements capture the system’s intended behavior in software engineering and systems engineering [1]. It defines a function of a system or its component, where a function is described as a specification of behavior between inputs and outputs [2]. This behavior may be expressed as services, tasks, or functions the system is required to perform [1].

"A Procedure for Requirements Analysis" indicates that functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a system is supposed to accomplish [3]. Behavioral requirements describe all the cases where the system uses the functional requirements, these are captured in use cases.

Use case

[edit]
Example of an use case diagram

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 [4]. An actor may be a class of users, roles users can play, or other systems. These can be separated into primary and secondary actors [5]. 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].

The use case structure is graphically summarized in a use case diagram [4], 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 [6].

Functional vs non-functional requirements

[edit]

As said before, functional requirements define a function of a system or its component. 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). Generally, functional requirements are expressed in the form "system must do <requirement>," while non-functional requirements take the form "system shall be <requirement>"[7]. The plan for implementing functional requirements is detailed in the system design, whereas non-functional requirements are detailed in the system architecture [7] [8].

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 [8].

See also

[edit]

References

[edit]
  1. ^ a b c d 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. ^ "Supplement 4-A, A Procedure for Requirements Analysis". Systems Engineering Fundamentals (PDF). United States Government US Army. 2001. ISBN 978-1484120835. Archived from the original (PDF) on 31 January 2017. Retrieved 10 January 2023.
  4. ^ a b UML Specification. http://www.rational.com/ We have referenced V1.3 Alpha R5, March 1999 in this paper.
  5. ^ Cockburn, Alistair, “Structuring Use Cases with Goals”, Journal of Object-Oriented Programming, Sep- Oct, 1997 and Nov-Dec, 1997.
  6. ^ A. Egyed. A scenario-driven approach to traceability. In ICSE, pages 123–132, 2001.
  7. ^ 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.
  8. ^ 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.
[edit]
  • Use Cases at GSA's Usability.gov
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Metteduijnhouwer&oldid=1133139001"