Requirements specification
Introduction: - The final production software requirements specification documents (SRS). For small problems or problems that can be easily understood; After complete analysis, specification activity can occur. However, an analyst will usually analyze parts of the problem and then write the requirements of that part. In practice, problem analysis and specification of requirements overlap activities, with movement in both activities from one to another.
The first question is, if formal modeling is done during the analysis, then why are the outputs of modeling - the structures that are manufactured - are not considered as SRS? The main reason is that modeling is usually focused on problem structure, not on its external behavior. As a result, things like the user interface are rarely modeled, while they often make a major component of SRS. Similarly, for ease of modeling, often incorrect situations such as "minor issues" are hardly modeled correctly, while in SRS, behavior has also been specified in such situations. Likewise, lack of performance, lack of design, compliance of standards, recovery, etc. are not included in the model, but should be clearly specified in the SRS, because designers know about them to properly design the system Should be. Therefore it should be clear that the output of a model can not create a desirable SRS.
For these reasons, transition from analysis to specification should not be expected to be straightforward, even if some formal modeling is used during the analysis. It is not that the modeling structures in the specification are only more formally specified. A good SRS requires specifying many things, some of which are not satisfactoryly controlled during modeling. In addition, sometimes structures created during modeling are not responsible for translation into the external behavior of the desired system.
Essentially, whatever needs from analysis activity to specification activity, there is acquired knowledge about the system. Modeling is essentially a tool to help complete and complete knowledge about the proposed system. SRS has been written based on the knowledge gained during the analysis. As converting knowledge into a structured document is not straightforward, the specification itself is a major task, which is relatively independent.
One consequence of this is that it is relatively less important to model "fully" than to fully specify. As the primary objective of the analysis is to understand the problem, while the basic purpose of the phase of requirements is to produce SRS, complete and detailed. Analysis structures are not important In fact, it is possible to develop SRS without using formal modeling techniques. The basic purpose of the structures used in modeling is to help in the knowledge representation and division of problems; Structures themselves are not an end in itself. Keeping this in mind, we begin our discussion on the specifications of the requirements.
Also read.
The first question is, if formal modeling is done during the analysis, then why are the outputs of modeling - the structures that are manufactured - are not considered as SRS? The main reason is that modeling is usually focused on problem structure, not on its external behavior. As a result, things like the user interface are rarely modeled, while they often make a major component of SRS. Similarly, for ease of modeling, often incorrect situations such as "minor issues" are hardly modeled correctly, while in SRS, behavior has also been specified in such situations. Likewise, lack of performance, lack of design, compliance of standards, recovery, etc. are not included in the model, but should be clearly specified in the SRS, because designers know about them to properly design the system Should be. Therefore it should be clear that the output of a model can not create a desirable SRS.
For these reasons, transition from analysis to specification should not be expected to be straightforward, even if some formal modeling is used during the analysis. It is not that the modeling structures in the specification are only more formally specified. A good SRS requires specifying many things, some of which are not satisfactoryly controlled during modeling. In addition, sometimes structures created during modeling are not responsible for translation into the external behavior of the desired system.
Essentially, whatever needs from analysis activity to specification activity, there is acquired knowledge about the system. Modeling is essentially a tool to help complete and complete knowledge about the proposed system. SRS has been written based on the knowledge gained during the analysis. As converting knowledge into a structured document is not straightforward, the specification itself is a major task, which is relatively independent.
One consequence of this is that it is relatively less important to model "fully" than to fully specify. As the primary objective of the analysis is to understand the problem, while the basic purpose of the phase of requirements is to produce SRS, complete and detailed. Analysis structures are not important In fact, it is possible to develop SRS without using formal modeling techniques. The basic purpose of the structures used in modeling is to help in the knowledge representation and division of problems; Structures themselves are not an end in itself. Keeping this in mind, we begin our discussion on the specifications of the requirements.
Also read.
PROTOTYPING
from Technology development http://bit.ly/30oQF9h
Comments
Post a Comment