1.1.Characteristics of good software requirements
To ensure that software with exactly the same functionality as demanded by the client is delivered, it is necessary that the requirement has good characteristics. The following characteristics of requirement are generally acknowledged [11]:
Correct and clarity
For the correctness of software requirement, each requirement must accurately and correctly describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement is not correct. It is necessary to include user representatives in requirement inspection since only the user can determine the correctness of user requirements. Requirements inspections that do not involve users can lead to developers interpret the requirement wrongly.
Feasible
Another quality of good requirement is that it must be feasible. This implies that it must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, the developer should work with the requirements analysts or marketing personnel throughout the elicitation process. This developer can provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost or with other tradeoffs.
Necessary
Each requirement should document something the customers really need or something that is required for conformance to an external requirement, an external interface, or a standard. What is meant by necessary is that each requirement originated from a source you recognize as having the authority to specify requirements. Therefore, each requirement traceable back to its origin, such as a use case, system requirement, regulation, or stakeholders. If any requirement cannot be identified with the origin, perhaps the requirement is not really necessary.
Prioritized
Although a requirement may be necessary, but by assigning an implementation priority to each requirement, feature, or use case, it may appear that its priority level may be below other requirement and therefore may not be essential to be included in a particular product release [10]. Meanwhile, customers or stakeholders may have the upper hand in share of the responsibility for establishing priorities. If all the requirements are regarded as equally important, the project manager is less able to react to new requirements added during development, budget cuts, schedule overruns, or the departure of a team member. Priority is a function of the value provided to the customer, the relative cost of implementation, and the relative technical risk associated with implementation. I use three levels of priority. High priority means the requirement must be incorporated in the next product release. Medium priority means the requirement is necessary but it can be deferred to a later release if necessary. Low priority means it would be nice to have, but we realize it might have to be dropped if we have insufficient time or resources.
Unambiguous
It is expected that a good requirement should have only one meaning. Therefore, the reader of a requirements statement should be able to draw only one interpretation of it. In another case, multiple readers of a requirement should arrive at the same interpretation [12]. However, natural language is highly prone to ambiguity. For that reason, subjective words like user-friendly, easy, simple, rapid, efficient, several, state-of-the-art, improved, maximize, and minimize are always avoided during requirement. Sometimes, words that are clear to the requirement engineer and user may not be clear to readers. Due to this, each requirement is written in succinct, simple, straightforward language of the user domain, not on computers. Effective ways to reveal ambiguity include formal inspections of the requirements specifications, writing test cases from requirements, and creating user scenarios that illustrate the expected behavior of a specific portion of the product.
Verifiable
It is necessary that each requirement must be verifiable. For that reason, methods can be devised for the testing requirement or use other verification approaches, such as inspection or demonstration, to determine whether each requirement is properly implemented in the product. If a requirement is not verifiable, determining whether it was correctly implemented is a matter of opinion. Requirements that are not consistent, feasible, or unambiguous also are not verifiable.
Complete
For good requirements, no requirement or necessary information should be missing. Completeness is also a desired characteristic of an individual requirement [10]. It is hard to spot missing requirements because they are not there. To determine if requirement or information is missing, the requirements are organized hierarchically to help reviewers understand the structure of the functionality described, so it will be easier for them to tell if something is missing. It should be noted that it is better to pay attention to system functions during requirements elicitation, instead of user tasks to ensure that it is less likely both to overlook requirements and to include requirements that are not really necessary. The use case method works well for this purpose. Graphical analysis models that represent different views of the requirements can also reveal incompleteness.
Consistent
It is necessary that the requirements should be consistent. Consistent requirements do not conflict with higher order requirements in the same software. Disagreements among requirements must be resolved before development can proceed. It may not be possible to know which requirement is correct some research are conducted. It is important to be careful when modifying the requirements, as inconsistencies can slip in undetected if you review only the specific change and not any related requirements.
Traceable
Since the source of every requirement is needed to clarify if the requirement is found ambiguous, it is necessary that each software requirement should be able to link to its source, which could be a higher-level system requirement, a use case, or a voice-of-the-customer statement. Also link each software requirement to the design elements, source code, and test cases that are constructed to implement and verify the requirement. Traceable requirements are uniquely labeled and are written in a structured, fine-grained way, as opposed to large, narrative paragraphs or bullet lists.