Requirements Analysis - Requirements Engineering and Management for Software Development Projects - page 58

Table 4.1 Suggested format for enumerating all the requirements

Inputs
(Y/N/Incomplete)

Outputs
(Y/N/
Incomplete)

Feasibility
(Y/N)

design from incomplete requirements. To ensure the completeness of a require-
ment, we ensure that its:

1. Inputs are defined
2. The validations that need to be performed on the input data are defined
3. The process of converting the inputs to outputs is defined
4. The outputs expected from the process are defined
5. All the relevant templates and formats are available

Once we have all this information for a requirement, it can be deemed to be
complete.
Evaluate each Requirement for Its Feasibility—Technical—Technical fea-
sibility includes limitations of hardware, software or algorithmic. Sometimes the
requirements may not be feasible to be achieved with the current state of tech-
nology or the technology available within the organization. Examples include
certain types of analyses that are easily performed by the individuals but cannot be
performed automatically. Response times are examples for technology limitations.
A frequently asked requirement to provide a mechanism to define a new billing
plan in consumer services such as cable and mobile phone services is an example
of algorithmic limitations. Pattern recognition is also not easily achieved by the
software.
Evaluate each Requirement for Its Feasibility—Financial—Sometimes, the
requirements may be technically feasible but in our considered opinion, are too
costly to fit into the available budget. Such possibilities occur when a specialized