What is Software Requirement? Types of Requirements.

In the software development process, requirement phase is the first software engineering activity. This phase is a user-dominated phase and translates the ideas or views into a requirements document. Note that defining and documenting the user requirements in a concise and unambiguous manner is the first major step to achieve a high-quality product.

The requirement phase encompasses a set of tasks, which help to specify the impact of the software on the organization, customers’ needs, and how users will interact with the developed software. The requirements are the basis of the system design. If requirements are not correct the end product will also contain errors. Note that requirements activity like all other software engineering activities should be adapted to the needs of the process, the project, the product and the people involved in the activity. Also, the requirements should be specified at different levels of detail. This is because requirements are meant for people such as users, business managers, system engineers, and so on. For example, business managers are interested in knowing which features can be implemented within the allocated budget whereas end-users are interested in knowing how easy it is to use the features of software.

What is Software Requirement?

Requirement is a condition or capability possessed by the software or system component in order to solve a real world problem. The problems can be to automate a part of a system, to correct shortcomings of an existing system, to control a device, and so on. IEEE defines requirement as (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).’

Requirements describe how a system should act, appear or perform. For this, when users request for software, they provide an approximation of what the new system should be capable of doing. Requirements differ from one user to another and from one business process to another.

Guidelines for Expressing Requirements

The purpose of the requirements document is to provide a basis for the mutual understanding between the users and the designers of the initial definition of the software development life cycle (SDLC) including the requirements, operating environment and development plan.

The requirements document should include the overview, the proposed methods and procedures, a summary of improvements, a summary of impacts, security, privacy, internal control considerations, cost considerations, and alternatives. The requirements section should state the functions required in the software in quantitative and qualitative terms and how these functions will satisfy the performance objectives. The requirements document should also specify the performance requirements such as accuracy, validation, timing, and flexibility. Inputs, outputs, and data characteristics need to be explained. Finally, the requirements document needs to describe the operating environment and provide (or make reference to) a development plan.

There is no standard method to express and document requirements. Requirements can be stated efficiently by the experience of knowledgeable individuals, observing past requirements, and by following guidelines. Guidelines act as an efficient method of expressing requirements, which also provide a basis for software development, system testing, and user satisfaction. The guidelines that are commonly followed to document requirements are listed below.

1. Sentences and paragraphs should be short and written in active voice. Also, proper grammar, spelling, and punctuation should be used.
2. Conjunctions such as ‘and’ and ‘or’ should be avoided as they indicate the combination of several requirements in one requirement.
3. Each requirement should be stated only once so that it does not create redundancy in the requirements specification document.

Types of Requirements

Requirements help to understand the behavior of a system, which is described by various tasks of the system. For example, some of the tasks of a system are to provide a response to input values, determine the state of data objects, and so on. Note that requirements are considered prior to the development of the software. The requirements, which are commonly considered, are classified into three categories, namely, functional requirements, non-functional requirements, and domain requirements.

IEEE defines functional requirements as ‘a function that a system or component must be able to perform.’ These requirements describe the interaction of software with its environment and specify the inputs, outputs, external interfaces, and the functions that should be included in the software. Also, the services provided byfunctional requirements specify the procedure by which the software should reactto particular inputs or behave in particular situations.

To understand functional requirements properly, let us consider the following example of an online banking system.

1. The user of the bank should be able to search the desired services from the available ones.
2. There should be appropriate documents’ for users to read. This implies that when a user wants to open an account in the bank, the forms must be available so that the user can open an account.
3. After registration, the user should be provided with a unique acknowledgement number so that he can later be given an account number.

The above mentioned functional requirements describe the specific services provided by the online banking system. These requirements indicate user requirements and specify that functional requirements may be described at different levels of detail in an online banking system. With the help of these functional requirements, users can easily view, search and download registration forms and other information about the bank. On the other hand, if requirements are not stated properly, they are misinterpreted by software engineers and user requirements are not met.

The functional requirements should be complete and consistent. Completeness implies that all the user requirements are defined. Consistency implies that all requirements are specified clearly without any contradictory definition. Generally, it is observed that completeness and consistency cannot be achieved in large software or in a complex system due to the problems that arise while defining the functional requirements of these systems. The different needs of stakeholders also prevent the achievement of completeness and consistency. Due to these reasons, requirements may not be obvious when they are,’first specified and may further lead to inconsistencies in the requirements specification.

The non-functional requirements (also known as quality requirements) are related to system attributes such as reliability and response time. Non-functional requirements arise due to user requirements, budget constraints, organizational policies, and so on. These requirements are not related directly to any particular function provided by the system.

Non-functional requirements should be accomplished in software to make it perform efficiently. For example, if an aeroplane is unable to fulfill reliability requirements, it is not approved for safe operation. Similarly, if a real time control system is ineffective in accomplishing non-functional requirements, the control functions cannot operate correctly.

The description of different types of non-functional requirements is listed below.

1. Product requirements: These requirements specify how software product performs. Product requirements comprise the following.
2. Efficiency requirements: Describe the extent to which the software makes optimal use of resources, the speed with which the system executes, and the memory it consumes for its operation. For example, the system should be able to operate at least three times faster than the existing system.
3. Reliability requirements: Describe the acceptable failure rate of the software. For example, the software should be able to operate even if a hazard occurs.
4. Portability requirements: Describe the ease with which the software can be transferred from one platform to another. For example, it should be easy to port the software to a different operating system without the need to redesign the entire software.
5. Usability requirements: Describe the ease with which users are able to operate the software. For example, the software should be able to provide access to functionality with fewer keystrokes and mouse clicks.
6. Organizational requirements: These requirements are derived from the policies and procedures of an organization. Organizational requirements comprise the following.
7. Delivery requirements: Specify when the software and its documentation are to be delivered to the user.
8. Implementation requirements: Describe requirements such as programming language and design method.
9. Standards requirements: Describe the process standards to be used during software development. For example, the software should be developed using standards specified by the ISO and IEEE standards.
10. External requirements: These requirements include all the requirements that affect the software or its development process externally. External requirements comprise the following.
11. Interoperability requirements: Define the way in which different computer based systems will interact with each other in one or more organizations.
12. Ethical requirements: Specify the rules and regulations of the software so that they are acceptable to users.
13. Legislative requirements: Ensure that the software operates within the legal jurisdiction. For example, pirated software should not be sold.

Non-functional requirements are difficult to verify. Hence, it is essential to write non-functional requirements quantitatively, so that they can be tested. For this, non-functional requirements metrics are used. These metrics are listed in Table.

                               Metrics for Non-functional Requirements

Requirements which are derived from the application domain of the system instead from the needs of the users are known as domain requirements. These requirements may be new functional requirements or specify a method to perform some particular computations. In addition, these requirements include any constraint that may be present in the existing functional requirements. As domain requirements reflect the fundamentals of the application domain, it is important to understand these requirements. Also, if these requirements are not fulfilled, it may be difficult to make .the system work as desired.

A system can include a number of domain requirements. For example, it may comprise a design constraint that describes the user interface, which is capable of accessing all the databases used in a system. It is important for a development team to create databases and interface designs as per established standards. Similarly, the requirements of the user such as copyright restrictions and security mechanism for the files and documents used in the system are also domain requirements. When domain requirements are not expressed clearly, it can result in the following difficulties.

Problem of understandability: When domain requirements are specified in the language of application domain (such as mathematical expressions), it becomes difficult for software engineers to understand them.

Problem of implicitness: When domain experts understand the domain requirements but do not express these requirements clearly, it may create a problem (due to incomplete information) for the development team to understand and implement the requirements in the system.

Requirements Engineering Process

This process is a series of activities that are performed in the requirements phase to express requirements in the Software Requirements Specification (SRS)document. It focuses on understanding the requirements and its type so that an appropriate technique is determined to carry out the Requirements Engineering (RE) process. The new software developed after collecting requirements either replaces the existing software or enhances its features and functionality. For example, the payment mode of the existing software can be changed from payment through hand-written cheques to electronic payment of bills.

An RE process is shown, which comprises various steps including feasibility study, requirements elicitation, requirements analysis, requirements specification, requirements validation, and requirements management.

The requirements engineering process begins with feasibility study of the requirements. Then requirements elicitation is performed, which focuses on gathering user requirements. After the requirements are gathered, an analysis is performed, which further leads to requirements specification. The output of this is stored in the form of software requirements specification document. Next, the requirements are checked for their completeness and correctness in requirements validation. Last of all, to understand and control changes to system requirements, requirements management is performed.