it is important for a software project management to produce an overall description of a system

architecture at an early stage in the system specification.

This is to check all the questions arises

o Do the stated goals and objectives for software remain consistent with system goals and
objectives?
o Have important interfaces to all system elements been described?

o Have all data objects been described? Have all attributes been identified?

o Do major functions remain within scope and has each been adequately described?

o Have functions been refined (elaborated) to an appropriate level of detail?

o Is information flow adequately defined for the problem domain?

o Are diagrams clear; can each stand alone without supplementary text?

o Is the behavior of the software consistent with the information it must process and the functions it
must perform?
o Have events and states been identified?

o Are design constraints realistic?

o Have technological risks been fully defined?

o Have alternative software requirements been considered?

o Have validation criteria been stated in detail; are they adequate to describe a successful system?

o Have inconsistencies, omissions or redundancy been identified and corrected?

o Is the customer contact complete?

o Has the user reviewed the Preliminary User's Manual or prototype?

o How are the Software Project Plan estimates affected?

Architectural Strategies

Describe any design decisions and/or strategies that affect the overall organization
of the system and its higher-level structures. These strategies should provide
insight into the key abstractions and mechanisms used in the system architecture.
Describe the reasoning employed for each decision and/or strategy (possibly
referring to previously stated design goals and principles) and how any design
goals or priorities were balanced or traded-off. Such decisions might concern (but
are not limited to) things like the following:

 Use of a particular type of product (programming language, database,

library, etc. ...)
 Reuse of existing software components to implement various
parts/features of the system
 Future plans for extending or enhancing the software
 User interface paradigms (or system input and output models)
 Hardware and/or software interface paradigms
 Error detection and recovery
 Memory management policies
  External databases and/or data storage management and persistence
 Distributed data or control over a network
 Generalized approaches to control
 Concurrency and synchronization
 Communication mechanisms
 Management of other resources

Each significant strategy employed should probably be discussed in its own

subsection, or (if it is complex enough) in a separate design document (with an
appropriate reference here of course). Make sure that when describing a design
decision that you also discuss any other significant alternatives that were
considered, and your reasons for rejecting them (as well as your reasons for
accepting the alternative you finally chose). Sometimes it may be most effective to
employ the "pattern format" for describing a strategy.

System Architecture

This section should provide a high-level overview of how the functionality and
responsibilities of the system were partitioned and then assigned to subsystems or
components. Don't go into too much detail about the individual components
themselves (there is a subsequent section for detailed component descriptions). The
main purpose here is to gain a general understanding of how and why the system
was decomposed, and how the individual parts work together to provide the
desired functionality.

At the top-most level, describe the major responsibilities that the software must
undertake and the various roles that the system (or portions of the system) must
play. Describe how the system was broken down into its components/subsystems
(identifying each top-level component/subsystem and the roles/responsibilities
assigned to it). Describe how the higher-level components collaborate with each
other in order to achieve the required results. Don't forget to provide some sort of
rationale for choosing this particular decomposition of the system (perhaps
discussing other proposed decompositions and why they were rejected). Feel free
to make use of design patterns, either in describing parts of the architecture (in
pattern format), or for referring to elements of the architecture that employ them.

If there are any diagrams, models, flowcharts, documented scenarios or use-cases

of the system behavior and/or structure, they may be included here (unless you feel
they are complex enough to merit being placed in the  Detailed System
Design section). Diagrams that describe a particular component or subsystem
should be included within the particular subsection that describes that component
or subsystem.
Note:

This section (and its subsections) really applies only to newly developed (or
yet-to-be developed) portions of the system. If there are parts of the
system that already existed before this development effort began, then you
only need to describe the pre-existing parts that the new parts of the
system depend upon, and only in enough detail sufficient to describe the
relationships and interactions between the old parts and the new parts.
Pre-existing parts that are modified or enhanced need to be described only
to the extent that is necessary for the reader to gain a sufficient
understanding of the nature of the changes that were made.

Subsystem Architecture

If a particular component is one which merits a more detailed discussion than what
was presented in the System Architecture section, provide that more detailed
discussion in a subsection of the System Architecture section (or it may even be
more appropriate to describe the component in its own design document). If
necessary, describe how the component was further divided into subcomponents,
and the relationships and interactions between the subcomponents (similar to what
was done for top-level components in the System Architecture section).

If any subcomponents are also deemed to merit further discussion, then describe
them in a separate subsection of this section (and in a similar fashion). Proceed to
go into as many levels/subsections of discussion as needed in order for the reader
to gain a high-level understanding of the entire system or subsystem (but
remember to leave the gory details for the  Detailed System Design section).

If this component is very large and/or complex, you may want to consider
documenting its design in a separate document and simply including a reference to
it in this section. If this is the option you choose, the design document for this
component should have an organizational format that is very similar (if not
identical to) this document.