Software engineering has many schools of thought ranging from traditional waterfall approaches to more Agile approaches like Scrum. The terminology may vary but these systems all share the common goal of identifying project requirements.
Requirements dictate the features a system requires in order to be deemed functional. As software projects evolve they will undoubtedly reveal additional requirements to be considered by project stakeholders and developers.
What are Project Requirements
Various quality modeling frameworks provide project owners, managers, and developers a toolset by which project requirements can be identified, discussed, and adjusted as necessary.
In many cases, requirements can be defined in broad terms agnostic to considerations of which programming languages to be used, whether an application will have network capability or even the specifics of how the information will be presented.
Requirements Analysis
Modern Agile approaches celebrate the emergence of newly-realized project requirements and integrate approaches for dealing with such into core ideologies. Different systems of software engineering approach requirements analysis in different ways. In some cases, similar phases of software development cycles may share concepts but differ significantly in naming conventions.
For example, Scrum has a formalized requirements gathering stage during which project owners, managers, and developers identify the nature and scope of software products. Insights during this stage are formalized into a requirements specification and analysis model. These components of requirements analysis are dynamic and evolve throughout the course of a project.
Types of Requirements
Requirements gathering results in different types of project requirements, separable largely by their specificity. These requirements can be broadly categorized as either Functional Requirements or Non-Functional Requirements.
Functional Requirements
Functional requirements are specific project specifications that describe the exact operations required in order for a software system to be considered functional. These are broader specifications that may resemble some of the following items:
- The system provides a user profile service to store user information
- The system displays the current date on the login screen
- The system validates user-generated passwords for security
In simple terms, functional requirements specify what the system does, not how it does things. Functional requirements can be defined using the following formula:
Non-Functional Requirements
Non-Functional requirements are often identified and implemented at later stages of the software development cycle. These requirements specify how the system accomplishes certain features. The following are examples of non-functional requirements:
- The system uses the Python programming language to integrate with the Acme data API
- The time will be displayed on the home page of the web application in Coordinated Universal Time (UTC)
- User data will be downloadable in a .json format file
Quality Models & Requirements Categorization
Product requirements can be further categorized beyond functional and non-functional. Many software engineering quality models have presented many different categorization systems throughout the years. Briefly, these are some of the more popular quality models (Al-Qutaish, 2010):
- McCall’s Quality Model
- Boehm’s Quality Model
- Dromey’s Quality Model
- FURPS Quality Model
- ISO 9126 Quality Model
Each of these quality models provides a granular means of categorizing requirements. As an example, let us consider the different requirements categorizations provided by the FURPS model (Grady, 1992):
- Functionality – Capability, reusability, and security measures
- Usability – User interfaces, visual presentation styles, documentation
- Reliability – System availability, backup/restore points, autosaving
- Performance – Page load speeds, search delays, UI responsiveness
- Supportability – Testing, extensibility, maintainability, etc.
This model was extended in 1999 and thereafter known as the FURPS+ model (Jacobson, 1999) which specified the following additional requirements categories:
- Design constraints
- Implementation
- Physical
Other Requirements
Project requirements are not always easily distinguished such that they can be clearly categorized. In many cases, a project requirement may be argued to belong in one of several categories. In addition to the requirements mentioned thus far, additional types of requirements (varying in denotation among quality model systems) include the following:
- Legal requirements
- Packaging requirements
- Interface requirements
Final Thoughts
Software engineering is a broad multidisciplinary field with many philosophies–many in strong conflict with core ideals. Regardless of one’s approach to software engineering there are undoubtedly going to be goals seeking to accomplish similar tasks. Identifying and understanding the requirements of a project are among the most universal.
References
- Al-Qutaish, Rafa E. “Quality models in software engineering literature: an analytical and comparative study.” Journal of American Science 6.3 (2010): 166-175.
- Grady, R. B. “Practical Software Metrics for Project Management and Process Improvement.” Prentice Hall, Englewood Cliffs, NJ, USA, 1992
- Jacobson, I., Booch, G., Rumbaugh, J. “The Unified Software Development Process”. Addison Wesley, 1999
