 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | |
| By N2H | ||||||||||||||||||||||
Requirements Engineering
October 30, 2007
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting and have a nice day!
REQUIREMENTS ENGINEERING
Requirements engineering is the process of establishing what the new system should do. The requirements may be functional requirement or non functional requirement.
Functional requirement is one that describes the systems function or service while non functional requirement is a constraint placed on a system (e.g. Response time) or the development process.
These requirements can be said to evolve in 3 stages from requirements definition, to requirement specification and software specification.
-
Requirements Definition:
This is a high level abstract description of requirements. It can also be said to be a statement in natural language plus diagrams of what services the system is expected to provide and constraints under which it must operate.
-
Requirement specification:
This is a structured document which sets out the systems functions in detail i.e. detailed description of what the system should do.
-
Software specification
This is an abstract description of the software which is a basis for design and implementation. This is a document for the design team used for system development.
The requirements engineering process should normally involve writing a requirements definition then expanding this to requirements specification.
-
Different levels of system specification are useful because they communicate information about the system to different types of users.
-
Requirements information should be targeted to managerial level, it must be understandable by both client and contractor management who will not have a detailed technical knowledge of the system.
-
The requirement specification should be targeted at senior technical level staff and project managers.
-
Software specification is an implementation oriented document. It should be written for software engineers who will be involved in developing the system.
Requirements Engineering Process:
This process is the set of activities that lead to the production of the requirements definition and requirements specification. The 4 principle stages are:
-
Feasibility study:
This study should be relatively cheap and quick. It is an estimate of whether the identified user needs may be satisfied using current software and hardware technologies.
The study will decide whether the system (proposed system) will be cost effective from a business point of view and if it can be developed with the existing budgetary constraints.
The result of this study should form the decision of whether to go ahead with a more detailed analysis.
-
Requirements Analysis:
This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis and so on.
It may involve development of system models to help the analyst understand the system to be specified.
-
Requirements definition:
This is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. This should accurately reflect what the user wants. The document must be written so that it can be understood by end-user and system customer.
-
Requirements Specification:
A detailed and precise description of the system requirements is set out to act as a basis for a contract between client and the developer. During the development of the requirements specification, errors in requirements definition are discovered and they must be corrected.
The above activities are carried out in iteration i.e. the requirements analysis continues during definition and specification and new requirements arise during the process, thus the documents are suspect to frequent changes and should be placed under the control of a configuration management system.
Software Requirements Document:
This document is a combination of software definition and software specification. It is not a design document and it should set out what the system should do without specifying how it should be done.
-
The requirements should be stated so that there is traceability between these requirements and the final system design i.e. it should be possible to take each specified requirement and map it on to the part of the system design that implements that requirement.
-
The requirements set out on this document ought to be complete and consistent. All system functions should be specified and requirements should not conflict.
-
The document should be structured so that it can be easy to change: it should be split into chapters and sections.
-
Cross references from one requirement to another should be kept to a minimum.
Software requirement document should satisfy the following:
-
It should only specify external system behaviour
-
It should be easy to change
-
It should specify constraints on the implementation
-
It should record forethought about the lifecycle of the system.
-
It should characterize acceptable responses to undesired results.
The structure for a requirements document is
Introduction
-
should describe the need for the system briefly
-
its functions and how it will work with other systems briefly
-
it should describe how the system fits into the organization’s business or strategic objectives.
Functional Requirements:
Describe the functions the system is to achieve. The description should use diagrams, natural languages and other notations understandable by users.
Non Functional requirements:
It should define constraints imposed on the software and restrictions imposed on the designer should be described and related to functional requirements. It might include memory requirements, response time, and data representation.
System Models:
The document should set out one or more system models, showing the relationship between the system components and the system and its environment. This might include object models, dataflow models, and semantic data models.
System Evolution:
This should describe the fundamental assumptions on which the system is based and anticipated changes due to hardware evolution, changing user needs etc.
Requirements specification:
This should describe the functional requirements in more detail and also add more detail to non-functional requirements.
Glossary: This defines the technical terms used in the document.
Comments
Got something to say?
Powered by FireStats