programming languages<\/a> to be used, whether an application will have network capability or even the specifics of how the information will be presented.<\/p>\nRequirements Analysis<\/h2>\n
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.<\/p>\n
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<\/strong> and analysis model<\/strong>. These components of requirements analysis are dynamic and evolve throughout the course of a project.<\/p>\nTypes of Requirements<\/h2>\n
Requirements gathering results in different types of project requirements, separable largely by their specificity. These requirements can be broadly categorized as either Functional Requirements<\/strong> or Non-Functional Requirements<\/strong>.<\/p>\nFunctional Requirements<\/h3>\n
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:<\/p>\n
\n- The system provides a user profile service to store user information<\/li>\n
- The system displays the current date on the login screen<\/li>\n
- The system validates user-generated passwords for security<\/li>\n<\/ul>\n
In simple terms, functional requirements specify what the system does<\/strong>, not how it does things. Functional requirements can be defined using the following formula:<\/p>\nNon-Functional Requirements<\/h3>\n
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<\/strong>. The following are examples of non-functional requirements:<\/p>\n\n- The system uses the Python programming language to integrate with the Acme data API<\/li>\n
- The time will be displayed on the home page of the web application in Coordinated Universal Time (UTC)<\/li>\n
- User data will be downloadable in a .json format file<\/li>\n<\/ul>\n
Quality Models & Requirements Categorization<\/h2>\n
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):<\/p>\n
\n- McCall\u2019s Quality Model<\/li>\n
- Boehm\u2019s Quality Model<\/li>\n
- Dromey’s Quality Model<\/li>\n
- FURPS Quality Model<\/li>\n
- ISO 9126 Quality Model<\/li>\n<\/ul>\n
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):<\/p>\n
\n- Functionality<\/strong> – Capability, reusability, and security measures<\/li>\n
- Usability<\/strong> – User interfaces, visual presentation styles, documentation<\/li>\n
- Reliability<\/strong> – System availability, backup\/restore points, autosaving<\/li>\n
- Performance <\/b>– Page load speeds, search delays, UI responsiveness<\/li>\n
- Supportability\u00a0<\/strong>– Testing, extensibility, maintainability, etc.<\/li>\n<\/ul>\n
This model was extended in 1999 and thereafter known as the FURPS+ model (Jacobson, 1999) which specified the following additional requirements categories:<\/p>\n
\n- Design constraints<\/li>\n
- Implementation<\/li>\n
- Physical<\/li>\n<\/ul>\n
Other Requirements<\/h2>\n
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:<\/p>\n