|
Requirement Engineering
Part 2 3. Requirment Documentation
For having a better understanding of requirements, a document is used. This document is known as different names like Requirement Document, System’s Requirement Specifications. This Requirement Document plays critical role in software development. Apparently it seems that requirement document is only used by the system developers and Engineers. But in reality almost all the stakeholders are concerned with the requirement document. 1) Different stakeholders are involved with the requirement document in different ways.
- System Customer: System Customer is someone who makes the demand of new software application. System customer conveys his requirement to business analyst in requirement elicitation process. Business analyst negotiates and analyzes those requirements and compiles a requirement document. When the document is compiled then system customer reads requirement document to check that requirements in requirement document represents actual needs. - System Manager: A System manager makes estimates in terms of cost, time and resources and plans the system development process. Requirement Document is very critical to System managers because if requirement document is having some vague, invalid or unrealistic requirements then cost, time and resource estimated will not be up to the mark and whole plan of system development process will suffer. - System Engineers: System engineers are people who design and develop the whole system. Requirement Document is important to system engineer as well because it tells them what system is to be developed. Any invalid requirement in requirement document may lead to delays in system development. Moreover if the invalid requirement is not identified then system may provide some invalid functionality as well. - System Test Engineers: System test engineer test the system and ensure the quality of system. They need requirement documents for the creation of validation tests to ensure that system is doing exactly what it is expected to do. - System Maintenance Engineers: System maintenance engineers are responsible for the maintenance of system. They need requirement document to understand the system and to understand the relationships between different parts of systems. 2) Types of Requirments
In general requirements can be divided in many types like “User Requirements”, “System Requirements”, “System Specification” and etc but generally requirements can be categorized in three different categories:
- Functional Requirements - Non Functional Requirements - Domain Requirements 3) Functional Requirements: Functional requirement is the statement of a service that software is supposed to provide. In other words, we can say that a function requirement tell that how system will react on a specific input and in a specific situation. Functional requirement are used to describe the functionally of the system. Functional requirement depend on several parameters like: types of software, expected users of software and the environment/system where software will be used.
4) Non Functional Requirements: Non functional requirements are not requirements. They have no concern with the functionality or operation of system. Non functional requirements are the constraints on the service of software. Non functional requirement are further divided in three more types:
- Production Requirements: Requirements that tell that delivered system must behave in specific way. For example: execution speed, performance constrains and etc. - Organizational Requirements: These requirements are result of organizational policies and procedures. For example: usage of standards processes for software developments and etc. - External Requirements: These requirements arise from the factors which are external to system and development process. For example: Legal Constrains, interoperatablity requirements and etc. 5) Domain Requirements:
These requirements can be functional and non functional as well. But these requirements always emerge from the application domain of the system. These domain requirements are very important if these domain requirements are not satisfied then system may not be workable.
After identifying all the functional, non functional and domain requirements the most important step comes. In this step all the requirements are documented in a formal document. This requirement document is used to communicate requirements to customers, system and software engineers and managers of the systems engineering process. A good requirement document should describe the following:
- Requirement Document should explain the services and functions that the system is expected to perform. - Requirement Document must give the details about the constraints under which system will operate. - Requirement Document must provide the definition of other systems with which the system is expected to integrate. - Requirement Document must provide information about the application domain of the system. - Requirement Document must provide the knowledge of constraints on the process used to develop the system. According to IEEE standard Requirement Document a requirement document must contain the following chapters: ch1. Introduction
ch2. General description ch3. Specific Requirements
ch4. Appendices
ch5. Index
|
|
|
来自： hildaway > 《references》
