Современные информационные технологии/3.Программное обеспечение

Bilas O.

Lviv Politechnical National University, Ukraine

Requirements attribute and analisys tool for software specification

Requirements analysis is probably the most important, hardest and most defect contained stage of software development. Quality requirements analysis lets effective software develop without significant modification and delays in schedule.

Every software system is defined data converter and output results of converting. Requirements, which define functions and variety types of data processing during execution of this function, are raises to software development process. Requirements are the subject for practical agreement between customer and system developer. In general case as software requirements considered features which system should has for adequate function fulfilment. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user. Requirements are also an important input into the verification process, since tests should trace back to specific requirements.

Requirements are typically divided into following categories [1]:

• Functional requirements describe the functionality that the system is to execute. They are also called capabilities.
• Non-functional requirements describe characteristics of the system that the user cannot affect or perceive. Nonfunctional requirements are sometimes known as quality requirements.
• Constraint requirements impose limits upon the design alternatives or project operations. No matter how the problem is solved the constraint requirements must be adhered to.

In software engineering this categorization is useful because only functional requirements can be directly implemented in software.

Quality requirements are very important for succesful project realization. Requirements should meet following characteristics:

Characteristic	Explanation
Unitary	The requirement addresses one and only one thing.
Complete	The requirement is fully stated in one place with no missing information.
Consistent	The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
Non-Conjugated (Atomic)	The requirement is atomic, i.e., it does not contain conjunctions.
Traceable	The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.
Current	The requirement has not been made obsolete by the passage of time.
Feasible	The requirement can be implemented within the constraints of the project.
Unambiguous	The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation.
Mandatory	The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated. An optional requirement is a contradiction in terms.
Verifiable	The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis.

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders [2]. It is a continuous process throughout a project. Different management tools are used for storing and processing of the requirements. Important feature of such tool is capability to parse a requirements document that has been exported from text file, then elucidate each requirement line and produce a summary of the defects it finds in the requirement. The defect report is a measurement that can be used to assess the quality of a requirement document. Then system analytic should look at the requirements with reported defects and decide if he agrees with observation or not. If the author agrees with remarks, he can edit the requirements.

Requirements management tool should provide a dynamic report of the defects found within the requirements document.

When the requirements are correctly written, the system analytic can assign other requirement information to complete the building of the requirements specification document.

A lot of problems and potential defects can cause indistinct or vague words or phrases [3]. Requirements management tool should parse the documents to detect these indistinct words and identify them to the analytic. System analytics may choose to ignore such identification of the indistinct word, if they feel that the requirement statement is correct. The indistinct words should stores in a file, can be edited and extended. The typical indistinct words are high, low, probably, about, nearly, common, etc. Such words are not allowed in requirements for reason of various defects. It could be recognised the following potential types of defects:

1. Multiple requirements in a line.

2. Possible multiple requirements in a line.

3. Not verifiable or testable.

4. Use of wrong word to define a requirement.

5. User defined defective word.

Fig.1. Defects of requirements report

6. Possible design constraint.

7. Incomplete sentence.

Requirements should be analysed and determined if the items are defective.

Requirement creation wizard helps to build requirements step by step with chosen appropriate atributes and characteristics.

Fig. 2. Form for requirements creation with atributes and characteristics

Sortware requirements specification document is formed on the basis of discrete requirements. Requirements quality and their analisys made effect on efficiency and succesful of whole project. Defects finded on the requirements stage of project are easy and cheaper for correction.

Conclusions. Requirements engenireeng stage is one of the most important and influential software project phase. Requirements document agreed with customer and developers. This document is used as executives during tasks fulfilment on the software development lifecicle.

References:

1. Халл Э., Джексон К., Дик Д. Разработка и управление требованиями. Практическое руководство пользователя.- М.: Telelogic, 2005.-229с.

2. Вигерс К. Разработка требований к программному обеспечению. Пер. с англ.- М.:Издательско-торговый дом «Русская Редакция», 2004.-576с.

3. Standard for Software Verification and Validation Plans(ANSI/IEEE standard 1012-1986).