Determining Customer Requirements in Infrastructure Management
Customer Requirements:
A good SRS document, should properly categorize and organise the requirements into different sections (IEEE 830). As per the IEEE 830 guidelines, there are two important categories of user requirements are the following:
- Functional requirements
- Non-functional requirements
Functional Requirements:
The functional requirements capture the functionalities required by the users from the system. It is very useful to consider software as offering a set of functions {fi} to the user. These functions can be considered similar to a mathematical function f: I → O, It means that a function transforms an element (ii) in the input domain (I) to a value (oi) in the output (O). Each function fi of the system can be considered as reading certain data ii and then transforming a set of input data (ii) to the corresponding set of output data (oi).
The functional requirements of the system should clearly describe each functionality that the system would support along with the corresponding input and output data set. Considering that the functional requirements are a crucial part of the SRS document.
Non-Functional Requirements:
The non-functional requirements are non-negotiable obligations that must be supported by the software. The non-functional requirements capture those requirements of the customer that cannot be expressed as functions. Non-functional requirements usually address aspects concerning external interfaces, user interfaces, maintainability, portability, usability, the maximum number of concurrent users, timing, and throughput.
The non-functional requirements can be critical in the sense that any failure by the developed software to achieve some minimum defined level in these requirements can be considered as a failure and make the software unacceptable by the customer.
i. Design and implementation constraints:
Design and implementation constraints are an important category of non-functional requirements describe any items or issues that will limit the options available to the developers.
ii. External interfaces required:
Examples of external interfaces are hardware, software and communication interfaces, user interfaces, report formats, etc. To specify the user interfaces, each interface between the software and the users must be described.
iii. Goals of implementation:
The ‘goals of implementation’ part of the SRS document offers some general
suggestions regarding the software to be developed. These are not binding on the developers, and they may take these suggestions into account if possible.