INTRODUCTION Software Engineering is an engineering discipline concerned with all aspects of software production, from the early stages of system specification through to maintaining the system after it has gone into use. Contained in Software Engineering is a further concept – Requirements Engineering.
Requirements engineering is the practice of establishing the services that the customer needs from a system and the constraints under which it operates and is developed. The ‘requirements’ for a system themselves are the descriptions of what the system should do – the services that it provides and the constraints that are generated during the requirements engineering process. These requirements tend to reflect the essential needs of customers for a system that serves a certain specified purpose. Requirements may range from a high-level abstract statement of a service or of a system constraint to a more detailed mathematical functional specification.
Focus is given to two main types of requirements – user requirements and software system requirements. Software system requirements are commonly presented as a structured document that lays out explicit descriptions and explanations of the system’s functions, services and operational constraints. They help define exactly what needs to be implemented in the software to be developed, and therefore they are usually part of a contract signed between the client and the contractor. Software system requirements are often classified as functional requirements or nonfunctional requirements.
1
FUNCTIONAL REQUIREMENTS Functional requirements refer to very important system requirements and statements of services in a software engineering process the system should provide, how the system should behave in reaction to particular inputs and how the system should perform when presented with specific situations. When expressed as user requirements, functional requirements are usually described in an abstract way that can be understood by system users. However, more specific functional requirements may contain calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish, and sometimes might specify what the system should not do. The key goal of determining functional requirements in a software product design and implementation is to capture the required behavior of a software system in terms of functionality and the technology implementation of the business processes.
Normally, the Software Engineer makes use of the Use Cases and Scenarios generally following standard UML notations, in order to capture the functional requirements through a system analysis process. A typical functional requirement will contain a unique name and number, a brief summary, and a rationale. This information is used to help the reader understand why the requirement is needed, and to track the requirement through the development of the system.
As functional requirements must specify particular results of a system, the description of the required behavior needs to be completely clear and readable. The described behavior may come from organizational or business rules, or it may be discovered through elicitation sessions with users, stakeholders, and other experts within the organization. Many requirements may be uncovered during the use case development. When this happens, a placeholder requirement with a name and summary may be created and the details researched later, to be filled in when the requirements are better known.
2
Functional requirements are usually in the form of "system shall do ", an individual action of part of the system, perhaps explicitly in the sense of a mathematical function, a black box description input, output, process and control functional model or IPO Model.
An example of a system using functional requirements is the list of a possible Sales application’s functional requirements as shown:
1. Application shall capture appropriate information and produce Comparative Analysis (current month and year-to-date compared to same month last year and year-to-date last year) and Trend Analysis reports by: Product (units sold and dollars), Product Type, Product Family, Customer, Salesman, Territory, and Discount Type. 2. Application shall show Trend Analysis by Customer and Product, including profitability by customer. 3. Application shall show Trend Analysis by Product and Customer, including profitability by product. 4. Application shall show Monthly Detail by Customer and Invoice. 5. Application shall show Graphic Trend Charts by Customer, Salesman, Product Type and others. 6. Application shall show Sales of Products by Vendor, by Postal Code. 7. Application shall show Sales by Source Code (for Mail Order companies). 8. Application shall show Sales Analysis by province
3
NON-FUNCTIONAL REQUIREMENTS In requirements engineering, a non-functional requirement is a requirement that specifies the standards that can be used to judge a system’s operation, rather than specific behaviors. Basically, non-functional requirements define how a system is supposed to be as opposed to what it is supposed to do. They are generally informally stated, often contradictory, and difficult to enforce during development and evaluate for the customer prior to delivery. They are usually specified or constrained by the characteristic behavior of the required software, system requirements derived from policies and procedures in the customer’s and developer’s organization, or from external sources––which includes all requirements that are derived from factors external to the system and its development process.
Non-functional requirements define system properties and constraints (for example reliability, response time and storage requirements), and requirements instructing a specific IDE, programming language or development method may be detailed. They may be more critical than functional requirements in the sense that if non-functional requirements are not met, the system may be rendered practically useless.
Non-functional requirements drive the technical architecture of a system, which means that they tend to affect the whole architecture of a system, as opposed to only the separate specific components. For instance, to ensure that optimum performance requirements are met, the system might need to be arranged in such a way that communications amid components are lessened, eliminating unnecessary communications. A single non-functional requirement may spawn several related functional requirements that define required system services, and may also generate requirements that restrict existing requirements.
In order to specify efficient non-functional requirements, there are a few merits that must be considered. These include the system's availability or "uptime" (the amount of time that it is
4
operational and available for use), efficiency (specifies how well the software utilizes scarce resources), flexibility (enables the organization to extend the functionality of the software after it is deployed), portability (specifies the ease with which the software can be installed on all necessary platforms, and the platforms on which it is expected to run), integrity (defines the security attributes of the system, restricting access to features or data to certain users and protecting the privacy of data entered into the software), performance (specifies the timing characteristics of the software), reliability (specifies the capability of the software to maintain its performance over time), reusability (indicates the extent to which software components should be designed in such a way that they can be used in applications other than the ones for which they were initially developed), robustness (enables the system to handle error conditions gracefully, without failure), scalability (gives the ability to handle a wide variety of system configuration sizes), and usability (addresses the factors that constitute the capacity of the software to be understood, learned, and used by its intended users).
Non-functional requirements appear in the form of "system shall be ", an overall property of the system as a whole or of a particular aspect and not a specific function. The diagram below provides an example of non-functional requirements as implored in a proposed solution for a general application.
5
CONCLUSION Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system. The functional requirements describe the behavior of the system as it relates to the system's functionality, while the non-functional requirements elaborate the performance characteristic of the system. If there is any one thing any project must have in order not to be doomed to failure, it is a sensible and comprehensive collection of both the functional and non-functional requirements. Any project’s requirements need to be well thought out, balanced and clearly understood by all involved, but perhaps of most importance is that they are not dropped or compromised halfway through the project.
6
REFERENCES Debono, M. (2012, April 5). Functional Requirements vs. Non-Funtional Requirements. Retrieved from ReQTest: http://www.reqtest.com/blog/functional-vs-non-functionalrequirements/
Functional Requirements. (2008, February 6). Retrieved from Toolbox.com: http://it.toolbox.com/wiki/index.php/Functional_Requirements
Sommerville, I. (2011). Software Engineering. Boston, Massachusetts: Pearson Education Inc.
Stellman, A. (2010, February 17). Understanding Nonfunctional Requirements. Retrieved from O'Reilly Community: http://broadcast.oreilly.com/2010/02/nonfunctionalrequirements-how.html
7
