This section describes the general factors that affect the product and its requirements. The following five subsections make the requirements easier to understand.

• Product Perspective: It relates the product to other projects, or products. A block diagram showing the major components of the larger system or project, interconnections, and external interfaces is used as an effective explanatory tool.
  
  
• Product Functions: It summarizes the functions of the product. The functions are organized in a manner that makes the list of functions understandable to the customer, or to anyone else reading the document for the first time. Block diagrams showing different functions and their relationships, are used as an effective explanatory tool.
  
  
• User Characteristics: List the general characteristics of the users that will affect the specific requirements. Characteristics such as education level, experience, and technical expertise impose constraints on the systems' operating environment.
  
  
• General Constraints: Provide a general description of the other items that limit the developer’s options for designing the system. These may include regulatory policies, hardware limitations, interface to the other applications etc.

This section contains all the details that a software developer needs to create a design. This is the largest and the most important part of the SRS. In this section, details are defined as individual specific requirements. Specific requirements are organized in the following subsections:

• Functional Requirements: This subsection specifies what the input and output should be, and what operations are required.
  
  
• External Interface Requirements: This subsection of the SRS, contains all the information that the designer needs to adequately develop the interfaces to entities outside of the software specified. Specific interfaces to hardware, other software applications, and communication systems are specified in this subsection.
  
  
• Performance Requirements: This subsection should specify the static and dynamic numerical requirements placed on the software, or on human interaction with the software as whole. Static numerical requirements may include a number of terminals to be supported, a number of concurrent users etc. Dynamic numerical requirements may include a number of transactions and tasks, as well as the amount of data to be processed within certain time periods for both normal, and peak workload conditions.
  
  
• Design Constraints
  
  
  • Standards Compliance: This section specifies the requirements derived from existing standards or regulations. These might include report format, data naming etc.
    
    
  • Hardware Limitations: This section identifies requirements for the software to operate inside various hardware constraints.

• Definitions Abbreviations and Acronyms: This section provides the definitions of all terms, acronyms, and abbreviations required to interpret the SRS correctly.
  
  
• References: This section provides the complete list of documents referenced elsewhere in the SRS.

Business Process Mapping: This process is parallel to the SRS creation. Based on the requirements given by the client, the business analyst maps the business processes to the proposed solution. The business analyst creates activity diagrams to depict the business flow. He explains how the solution proposed in the SRS will solve the client's business problem.

Application Modeling:

Once the requirements are frozen, and the user interface is finalized, the next stage is to model the entire application. Unified Modeling Language ™ (UML®) is extensively used for modeling the application. UML helps you specify, visualize, and document models of software systems, including their structure and design.

Any precise model must first define the key concepts of the application, their internal properties, and their relationship to each other. This set of constructs is the static view. The application concepts are modeled as classes. Each of these classes describe a set of discrete objects that hold information, and communicate to implement behavior. The information they have is modeled as attributes, while the behavior they perform is modeled as methods. Object to object relationships are modeled as associations among the classes. The static view is notated using the class diagram. The static view can be used to generate most data structure declarations in a program. (Source: The Unified Modeling Language Reference Manual)

There are two ways to model behavior. One is the life history of an object as it interacts with the rest of the world; the other is the communication patterns of a set of connected objects, as they interact to implement behavior. The view of an object in isolation is the state machine. It is the view of an object as it responds to events based on its current state; performs actions as part of its response; and transitions to a new state. State machines are displayed in state charts.

The view of a system of interacting objects is collaboration. It is a context-dependant view of objects and their links to each other, together with the flow of messages between objects across data links. This viewpoint unifies data structure, control flow, and data flow in a single view. Collaborations and interactions are shown in sequence, and collaboration diagrams.

To capture fast paced complex businesses, we must consider methods that go beyond traditional ER diagrams. Maximize Technologies depends on Object Role Modeling (ORM) for its data modeling. ORM is a method for designing and querying database models at the conceptual level. Here the application is described in terms readily understood by users, rather than being recast in terms of implementation data structures. The architect develops an information model by interacting with others who are familiar with the application. Because these subject matter experts need not have technical modeling skills, reliable communication occurs by discussing the application at a conceptual level, using natural language, analyzing the information in simple units, and working with instances (sample populations). Like any good modeling method, ORM is far more than a mere notation. It includes various design procedures to develop and evolve conceptual models.

Once all the facts are expressed and an ORM model is created, tables can be generated automatically. The design of the database is automatically normalized to the fifth normal form. All relationships, constraints, and default values are maintained when the database is created.

Creating the Quality and Deployment Document:

During the course of architecting the software, the architect creates the test plans and quality documents. These documents help the Quality Assurance team to test the product thoroughly, and ensure the quality of the product. The architect also generates a deployment plan for the deployment team. The architect uses the deployment diagrams to explain the deployment of the application.

Quality control is based on the principle that all deliverables from the application shall be independently reviewed, so that defects are identified and corrected as soon as possible.