Identification Process

1. Functionality modeling: Component identification always starts by decomposing
   the business domain problem structure into a well-defined visual model. Data flow
   diagram is one of the most popular visual models to depict function oriented
   design. .
2. Design module development: The next step is to convert individual elements in
   the DFD into a design module. During this process, the design modules need to be
   designed to ensure high cohesion and loose inter-module coupling. The modules
   that perform similar kind of functionalities and processes qualify for the main
   . design module. Design modules would then become key function component.
3. Sub function development: The main functions need to be broken down into sub
   functions. Utilities such as, data validation, data conversion, information Jogging
   would be good candidates for sub-functions.
4. Interaction modeling: The input and output elements from DFD can be used to
   design the interactions between functions.
   
   Component and Stage Mapping
   The following table indicates the component/association identified at each level of the
   process:
   

Stage	Component/Associativity
Functional modeling	Data flow diagram
Design module development	High level function
Sub function development	Sub functions
Interaction modeling	Input and output data

 i) Hardware Issues

At the hardware level, an additional component called router is used to connect
physically distinct networks as shown in Figure 1. A router connects to the network
in the same way as any other computer. Any computer connected to the network has a
Network Interface Card (NIC), which has the address (network id+host id), hard
coded into it. A router is a device with more than one NICs. Router can connect
incompatible networks as it has the necessary hardware (NIC) and protocols
(TCP/IP).

ii) Software Issues
The routers must agree about the way information would be transmitted to the
destination computer on a different network, since the information is likely to travel
through different routers, there must be a predefined standard to which routers must
confirm. Packet formats and addressing mechanism used by the networks may differ.
One approach could be to perform conversion and reconversion corresponding to
different networks. But this approach is difficult and cumbersome. Therefore, the
Internet communication follows one protocol, the TCP/IP protocol suite. The basic
idea is that it defines a packet size, routing algorithms, error control, flow control
methods universally.

TCP/IP Protocols It would be unwise to club all these features in a single piece of software ─ it would
make it very bulky. Therefore, all these features are logically sub-grouped and then
the sub-groups are further grouped into groups called layers. Each layer has an
interface with the adjacent layers, and performs specific functions.

Need for Layering
Since it is difficult to deal with complex set of rules, and functions required for
computer networking, these rules and functions are divided with logical groups called
layers. Each layer can be implemented interdependently with an interface to other
layers providing with services to it or taking its services like flow control and error
control functions are grouped together and the layer is called data link layer. Speech
in telephone conversation is translated, with electrical segments and vice-versa.
Similarly in computer system the data or pattern are converted into signals before
transmitting and receiving. These function and rules are grouped together in a layer
called physical layer.

 Ans : Identification Process

1. Functionality modeling: Component identification always starts by decomposing
   the business domain problem structure into a well-defined visual model. Data flow
   diagram is one of the most popular visual models to depict function oriented
   design.
   
2. Design module development: The next step is to convert individual elements in
   the DFD into a design module. During this process, the design modules need to be
   designed to ensure high cohesion and loose inter-module coupling. The modules
   that perform similar kind of functionalities and processes qualify for the main
   design module. Design modules would then become key function component.
   
3. Sub function development: The main functions need to be broken down into sub
   functions. Utilities such as, data validation, data conversion, information Jogging
   would be good candidates for sub-functions.
   
4. Interaction modeling: The input and output elements from DFD can be used to
   design the interactions between functions.
   
   
   

Component and Stage Mapping
The following table indicates the component/association identified at each level of the
process:

          Stage                                                                                       Component! Association
Functional modeling                                                                                 Data flow diagram
Design module development                                                                    High level function
Sub function development                                                                            Sub functions
Interaction modeling                                                                               Input and output data

We have seen the positive benefits of SRS in previous section. Let us look at a scenario wherein the SRS is not properly defined and its impact on the project. This will enable us to understand the importance of SRS on the project:

• Impact on cost and schedule: Without a complete and accurate SRS, it
would be difficult to properly estimate and plan the overall cost of the
project. This would have ripple’ effect on resource staffing, milestone
planning and overall project budget. As a result the entire project schedule,
will be in jeopardy.

• Quality Impact: Incomplete requirements specification would manifest
itself into incomplete test plan and impacts the quality of all project
deliverables. This negatively impacts the project by re-testing, re-coding and
re-design efforts leading to cost and effort overruns.

• Impact on overall customer/user satisfaction: An improperly translated
user requirements would damage the customer confidence on the software
product and reduces the usability ilrrd overall satisfaction index.

• Impact on maintenance: Without proper traceability, it would be difficult
to extend the software, enhance it and to fix the issues. ‘

 • Correct: SRS should specify the functionality correctly from all aspects. It

also be continually updated to reflect all the software updates and
enhancements.

• Unambiguous: As SRS is written iri natural language, it is possible for it to
be interpreted in multiple ways based on the context, cultural background
etc. So, SRS should consider these things and define and refine in most
unambiguous fashion as possible. This would include providing references,
elaborating any abstract requirement with example scenarios etc. It is a good
practice to get a proof read of SRS by another person to weed out an)'
ambiguous descriptions.

• Precise: The description should not contain fizzy words so as to make it
precise.

• Complete: SRS should provide all the details required by software
.designers for design and implementation of the intended software.

• Consistent: The terminologies, definitions and others used throughout the
SRS should be consistent. It is a good practice to pre-define all definitions,
abbreviations and refer them consistently throughout SRS.

• Verifiable: This supplements the unambiguous characteristic. All
requirements should be quantified with exact and verifiable numbers. For
instance "The home page should load quickly" is non-verifiable as "quickly"
is subjective; it is also not mentioned if the page should load quickly across
all geographies. Instead of these subjective terms the requirement should
quantify it with the exact response time: "The home page should load within
2 seconds in North America region".

• Modifiable: The requirements should be detailed only once throughout the
document so that it is easy to modify and maintain the document in long run.
To ensure that SRS is modifiable it should:
1. Be coherent, well-organized and contain cross-referencing
2. Avoid redundancy
3. State each requirement separately

• Traceable: SRS should map the requirements to other business/user
requirement documents so that it is possible to trace the requirements. It
should also support backward-traceability and forward traceability.

• Ranked for importance/stability: The requirements should be ranked
based on its deemed business/user importance. Ranking is done based on:
1. Degree of stability: Stability is related to number of changes required
for implementing functionality.
2. Degree of importance: In this case, the requirements are classified
into categories such as essential, conditional and optional.

Few other characteristics of a good SRS are that it should be understandable by people
of varied backgrounds and it should be design independent. That is, without favoring
any particular design.

• Functionality: Complete details of the software.

• External Interfaces: Details of how the software interacts with external
systems, and end users.

• Performance: Provides details of transaction speed, software availability,
response time, failover conditions, disaster recovery scenarios, etc.

• Attributes: Provides details about portability, correctness, maintainability,
security, extensibility, flexibility, etc.

• Constraints: All applicable architecture and design constraints including
the maximum load supported, supported browsers, JavaScript dependency
and others should be detailed.

 • Forms the basis of agreement between customers and suppliers about ,

the software functionality: SRS serves as a structured contract between these parties specifying all functionalities along with constraints and mentions the behavior of the intended software. End user/customer can verify if the intended software meets all the needs and requirements stated in user requirements document.

• Optimizes development effort: 
As the requirements are fully specified beforehand, the implementation team can design the system accurately
thereby reducing the effort in re-design, re-work, re-testing and defect fixing.

• Forms basis for cost and schedule estimation: Using the functional and' non-functional requirements specified in SRS, the project management team can estimate the overall project cost and schedule in more accurate fashion
and make informed decisions about risk identification and mitigation.

• Forms basis for verification and validation: Quality team can design the validation and testing strategy including various kinds of test cases based on the requirements specified in SRS.

• Helps software portability and installation: The software usability information contained in SRS helps to transfer the software across various locations including multiple inter-company departments and other external customers.

• Helps in enhancement: As SRS specifies each requirement in fullest details, it would be easier to assess the impact of any enhancement planned providing the cost and schedule estimate of the enhancement