Human-Computer Interaction ?

For Question no 3:

An SRS is basically an organization's understanding (in
writing) of a customer or potential client's system
requirements and dependencies at a particular point in
time (usually) prior to any actual design or development
work. It's a two-way insurance policy that assures that both
the client and the organization understand the other's
requirements from that perspective at a given point in
time.

The SRS document itself states in precise and explicit
language those functions and capabilities a software system
(i.e., a software application, an eCommerce Web site, and so
on) must provide, as well as states any required constraints by
which the system must abide. The SRS also functions as a
blueprint for completing a project with as little cost growth
as possible. The SRS is often referred to as the "parent"
document because all subsequent project management documents,
such as design specifications, statements of work, software
architecture specifications, testing and validation plans, and
documentation plans, are related to it.

It's important to note that an SRS contains functional and
nonfunctional requirements only; it doesn't offer design
suggestions, possible solutions to technology or business
issues, or any other information other than what the
development team understands the customer's system requirements
to be.

A well-designed, well-written SRS accomplishes four major
goals:

• It provides feedback to the customer. An SRS is the
  customer's assurance that the development organization
  understands the issues or problems to be solved and the
  software behavior necessary to address those problems.
  Therefore, the SRS should be written in natural language
  (versus a formal language, explained later in this
  article), in an unambiguous manner that may also include
  charts, tables, data flow diagrams, decision tables, and so
  on.
• It decomposes the problem into component parts. The
  simple act of writing down software requirements in a
  well-designed format organizes information, places borders
  around the problem, solidifies ideas, and helps break down
  the problem into its component parts in an orderly
  fashion.
• It serves as an input to the design specification. As
  mentioned previously, the SRS serves as the parent document
  to subsequent documents, such as the software design
  specification and statement of work. Therefore, the SRS
  must contain sufficient detail in the functional system
  requirements so that a design solution can be devised.
• It serves as a product validation check. The SRS also
  serves as the parent document for testing and validation
  strategies that will be applied to the requirements for
  verification.

SRSs are typically developed during the first stages of
"Requirements Development," which is the initial product
development phase in which information is gathered about what
requirements are needed--and not. This information-gathering
stage can include onsite visits, questionnaires, surveys,
interviews, and perhaps a return-on-investment (ROI) analysis
or needs analysis of the customer or client's current business
environment. The actual specification, then, is written after
the requirements have been gathered and analyzed.

Technical Writers be Involved with SRS

Unfortunately, much of the time, systems architects and
programmers write SRSs with little (if any) help from the
technical communications organization. And when that assistance
is provided, it's often limited to an edit of the final draft
just prior to going out the door. Having technical writers
involved throughout the entire SRS development process can
offer several benefits:

• Technical writers are skilled information gatherers,
  ideal for eliciting and articulating customer requirements.
  The presence of a technical writer on the
  requirements-gathering team helps balance the type and
  amount of information extracted from customers, which can
  help improve the SRS.
• Technical writers can better assess and plan
  documentation projects and better meet customer document
  needs. Working on SRSs provides technical writers with an
  opportunity for learning about customer needs
  firsthand--early in the product development process.
• Technical writers know how to determine the questions
  that are of concern to the user or customer regarding ease
  of use and usability. Technical writers can then take that
  knowledge and apply it not only to the specification and
  documentation development, but also to user interface
  development, to help ensure the UI (User Interface) models
  the customer requirements.
• Technical writers, involved early and often in the
  process, can become an information resource throughout the
  process, rather than an information gatherer at the end of
  the process.

In short, a requirements-gathering team consisting solely of
programmers, product marketers, systems analysts/architects,
and a project manager runs the risk of creating a specification
that may be too heavily loaded with technology-focused or
marketing-focused issues. The presence of a technical writer on
the team helps place at the core of the project those user or
customer requirements that provide more of an overall balance
to the design of the SRS, product, and documentation.

A sample of a more detailed SRS outline