System Requirements
‘System Requirements’ is often the initial step in the system designing process. They provide the implementation details of the user requirements. Hence, they are more detailed than user requirements. The data within the system requirements should be complete as well as consistent.
System requirements should only consider the description of the operational as well as behavioral aspects of the systems. It should not include the implementation as well as the design details of the system. But, whenever large and complex systems are considered the design details are avoided in the system requirements. There are many reasons supporting this occasion. Few of them are quoted below.
If the system is distributed in nature (i.e., the system supporting interoperability), the design of a given system should be focused on the system requirements.
In order to ensure that the current system satisfies nonfunctional requirements, system architecture need to be considered.
However, there many other factors which can create complexities while documenting the system requirements. The fundamental factor is the usage of natural language while documenting these requirements.
They not only make the text difficult to understand, but they are often confusing.
Following is a list of reasons supporting the illustration
(i)
As the requirements are specified by a developer in his own notion, it rests with the end user to properly make the distinction between the available requirements from the given volumes of text. This is because, given requirement may be grammatically analogous to other available text or given requirements may look similar but refer to two different facts etc.).
(ii)
It is often impractical to associate the requirements under different side headings. Hence, a single requirement will drive through the entire system requirements set.
(iii)
If the writer is addicted to using certain or desired phrases on different occasions, then readers may misunderstand the concept. This may deviate them from the actual requirements. Sometimes these facts are analyzed during final phases of the software development. On those occasions the costs of development will eventually rise. When these problems were analyzed by the scientists, they concluded to use a language (while writing the requirements) which can be easily grasped by all the individuals involved.
This provides a full opportunity to the writers to express their views in the most appropriate manner.
Using the language, the requirements are framed in a well planned format with suitable models used based on the requirements. The structure can also have models exchanging dialogues and other perspectives.
Following are the set of notations which can be used for the requirement specifications
Specifying system requirements
Notation: Graphical notations
Illustration: This refers to representation consisting of certain graphical objects along with appropriate text inscribed at suitable locations. Good examples of such notations are SADIT, use case diagrams and sequence diagrams.
Notation: Structured natural language
Illustration: This notation facilitates the writers to utilize certain predefined formats as well as templates while expressing a scenario in the form of requirement.
Notation: Mathematical specifications
Illustration: These notations use the mathematical concepts like sets or finite state machines. Even though these notations minimize customer – contractor arguments, customers hesitate to accept it as a system contract.
Notation: Design description language
Illustration: In this case, the writers can utilize certain programming languages, in narrating the given requirements in terms of an operational model, if the model reflects only the abstract notion of the requirement.
Structured natural language specifications
Structured Natural Language was initially proposed by Heninger with an intention of providing certain standards while writing the system requirements for an aircraft software system.
According to him, structured natural language is a decent style of writing system requirements which privileges the writers with well defined standards. It also helps in curbing writers independency of using their own visualizations. Hence, there will be high degree of expressibility but this expressibility can be adhered with equal measures of uniformity.
Structured natural language helps in decreasing the number of words used in describing the context of the system. It allows to look forward for usage of templates whenever necessary. Also focus on some of these requirements (which remains extremely essential), structured natural languages highlight them. Hence, in other words, the structured natural language expresses the system requirements in certain standard forms,
While dealing with these form-based writing of system requirements, following illustrations must be considered
(i)
There should be significant description corresponding to a function or a given entity.
(ii)
Significant description corresponding to the inputs of the system as well as the source producing them. Also the description of outputs and the entities using them.
(iii)
Illustrations related to the actions to be performed.
(iv)
Illustration corresponding to generation of side effects while performing a given operation.
(v)
Illustration on initial, as well as final conditions existing before and after a given function, if the applications consisting of functions.
Domain analysis
Domain Analysis plays an important role in specifying whether the system can function properly or not. This is because domain requirements focus on the system’s application domain and not on the user’s and system’s requirements. While performing requirement engineering, the analysis pattern is performed repeatedly across several applications with respect to a particular business domain. If analysis pattern can be defined or categorized in a way that helps in identifying and reusing the pattern, then it is possible to create an analysis model. The impact of such a creation is that the use of reusable design pattern and executable software component increases. This intern enhances the time-to-market and decreases the cost associated with the development of the pattern.
Domain Analysis contains the information required for recognizing, defining and categorizing the analysis pattern.
According to Firesmith, software domain analysis is defined as a process of identifying, analyzing and specifying the common reusable requirements from a specific application domain.
Firesmith also defined object oriented domain analysis as a process of identifying, analyzing and specifying the common reusable capabilities present in a specific application domain.
These capabilities are defined in terms of classes, objects and frameworks.
The specific application domain can be of wider range i.e., it basically ranges from avionics to banking or from multimedia video games to software embedded systems. The objective of domain analysis is to identify, create analysis classes, functionality that are mainly applied for making them reusable. The information about expert advice, customer surveys and existing applications are extracted from sources of domain knowledge and are provided as inputs to domain analysis. Once the given inputs are processed, the outputs generated are class taxonomies, reuse standard and domain languages. These outputs are intum supplied as input to domain analysis model. The main purpose of using domain knowledge is to identify reusable objects across the specific application domain.
The entire process of domain analysis is characterized based on the context related to the object oriented software engineering. This process can be applied not only to the software engineering model but also to the traditional object oriented design models.
The following are the steps carried out while performing the domain analysis process
The domain that needs to be analyzed must be defined.
The items retrieved from sources of domain knowledge must be categorized.
The sample of application defined in the domain must be collected.
Every individual application in the sample is analyzed. Based on this, analysis class must be defined.
An analysis model forth class must be developed.