3.1 What is Requirement Analysis?

Requirements analysis is a software engineering task that bridges the gap between system level
requirements engineering and software design.

Requirements analysis provides the software designer with a representation of information,

function, and behaviour that can be translated to data, architectural, interface, and component-
level designs.

It also indicates software's interface with other system elements, and establish constraints that
software must meet.

Requirements analysis allows the software engineer (sometimes called analyst in this role) to
refine the software allocation and build models of the data, functional, and behavioural domains
that will be treated by software.

Software requirements analysis may be divided into five areas of effort:

1) Problem recognition

2) Evaluation and synthesis

3) Modelling

4) Specification

5) Review.

1) Problem Recognition:

Initially, the analyst studies the System Specification (if one exists) and the Software Project Plan
inorder to understand software in a system context and to review the software scope.

Next, communication for analysis must be established so that problem recognition is ensured. The
goal is recognition of the basic problem elements as perceived by the customer/users.

2)Problem evaluation and solution synthesis is the next major area of effort for analysis. The
analyst must define all externally observable data objects, evaluate the flow and content of
information, define and elaborate all software functions, understand software behavior in the
context of events that affect the system, establish system interface characteristics, and uncover
additional design constraints. Each of these tasks serves to describe the problem so that an overall
approach or solution may be synthesized.

Throughout evaluation and solution synthesis, the analyst's primary focus is on "what," not "how."
What data does the system produce and consume, what functions must the system perform, what
behaviours does the system exhibit, what interfaces are defined and what constraints apply?

3) Modeling: During the evaluation and solution synthesis activity, the analyst creates models of
the system in an effort to better understand data and control flow, functional processing,
operational behaviour, and information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the software.

4) Specification: Here requirements are specified in the document which is called as Software
Requirement Specification.(SRS)

5) Review: After that document is reviewed with client.

3.2 Requirement Gathering Techniques

Software requirements analysis always begins with communication between two or more parties.
A customer has problem that may be open to to a computer-based solution. A developer responds
to the customer’s request for help. The steps in analysis process are:

1) Initiating the process

2) Facilitated Application specification techniques (FAST)

3) Quality Function Deployment (QFD)

4) Use-Case Scenarios

3.2.1) Initiating the process:-

The most commonly used requirements gathering technique is to conduct a meeting or interview.

The first meeting between a software engineer (the analyst) and the customer is full of confusions.

Neither person knows what to say or ask; both are worried that what they do say will be
misinterpreted; both are thinking about where it might lead (both likely have radically different
expectations here); both want to get the thing over with, but at the same time, both want it to be
a success.
The analyst should start by asking “context free questions”. That is, a set of questions that will lead
to a basic understanding of the problem, the people who want a solution, the nature of the
solution that is desired, and the effectiveness of the first encounter itself. The first set of context-
free questions focuses on the customer, the overall goals, and the benefits.

For example, the analyst might ask:

 Who is behind the request for this work?

 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that you need?
The next set of questions enables the analyst to gain a better understanding of the problem and
the customer to voice his or her perceptions about a solution:

 How would you characterize "good" output that would be generated by a successful
solution?
 What problem(s) will this solution address?
 Can you show me (or describe) the environment in which the solution will be used?
 Will special performance issues or constraints affect the way the solution is approached?
 The final set of questions known as “Meta-questions” focuses on the effectiveness of the
meeting propose the following list:
 Are you the right person to answer these questions? Are your answers "official"?
 Are my questions relevant to the problem that you have?
 Am I asking too many questions?
 Can anyone else provide additional information?
 Should I be asking you anything else?
These questions will help to “break the ice” (to initiate a friendly conversation) and initiate the
communication that is essential to successful analysis.

3.2.2) Facilitated Application Specification Techniques (FAST)(Collaborative Requirements

Gathering):-

1) Why FAST is required?

History has shown that communication through paper, documents, Question and answer doesn't
help customers and develpers effectively in understanding the problems.
There may be some misunderstanding. To avoid that FAST is used

FAST approach encourages the creation of a joint team of customers and developers, who work
together to

A. To identify problems
B. Propose elements of solution
C. Negotiate different approaches.
D. Specify preliminary set of solution requirements.
This approach is similar to brainstorming session. The objective of the approach is to bridge the
expectation gap – a difference between what developers think they are supposed to build and
what customers think they are going to get.

2) Basic guidelines for approaching FAST are as follows:

 A meeting is conducted at a neutral site and attended by both developers and customers.
 Rules for preparation and participation are established.
 An agenda is suggested that is formal enough to cover all-important points but informal
enough to encourage the free flow of ideas.
 A “facilitator” (who can be a customer, a developer or an outsider) controls the meeting.
 A “definition mechanism”(which can be work sheets, flip charts, or a wall board) is used.
 The goal is to identify the problems, propose elements of the solution, negotiate different
approaches, and specify a preliminary set of solution requirements in an atmosphere that
is conducive to the accomplishment of the goal.
 The FAST team is composed of representatives from marketing, software and hardware
engineering, and manufacturing.

3) Before the Meeting

1. Customer and developers are asked to write one or two page product request. This
product request is distrubuted to all team members before the meeting.
2. Each FAST members is asked to make :
a. Objects that are part of environment or system.
b. List of services.
c. List of constraints, cost, size, business rules, performance, criteria, accuracy.

3. The members are informed that list must not be in very detail but it should show each
person's perception about the system.

4) In the Meeting

 As the FAST meeting begins, the first topic of discussion is the need and justification
for the new product – everyone should agree that the product justified.
 Once agreement has been established, each participant presents his or her list of
 objectives and services required, and these lists are displayed in the meeting.
 Discussions are held on these objectives and services. And after this, combined lists
for these topics are prepared by eliminating redundant entries and adding new
ideas.
 The combined list is shortened, lengthened, or reworded to properly reflect the
product or system to be developed. The objective is to develop a consensus list in
each topic area.
 After that team is divided into smaller subteams. Each team develop mini
specification for one or more entries on each of the list.
 Each sub team then present mini specification to all fast members for discussion,
addition,deletion and further elaboration.
 Development of mini specification will uncover new objects, services, constraints
and performance requirement that will be added to the original list.
 During all the discussion, team may raise an issue which was not resolve during the
meeeting. After that FAST members make list of validation criteria for the product
and present to the team.
 Common validation list is prepared.

5) After Meeting

 Finally one or two participants(members) are assigned the task of writing the complete
specification using all input from the FAST meeting.
 In FAST team approach provide benefit to many point of view, create discussions and
refinement. So through fast we can collect requirement very easily.

3.2.3 Quality Function Deployment:-

 Quality function deployment is a quality management technique that translates the

needs of the customer into technical requirements for the software.
 It concentrates on maximizing the customer satisfaction. To accomplish this, QFD
emphasizes understanding of what is valuable to the customer and then deploying
these values throughout the engineering process.

QFD identifies three types of requirements:

1. Normal requirements. Objectives and goals are stated for a product or system
during meetings with the customer. If these requirements are present, the customer
is satisfied. Examples of normal requirements might be requested types of graphical
displays, specific system functions, and defined levels of performance.

2. Expected requirements. These requirements are implicit to the product or system

and may be so fundamental that the customer does not explicitly state them. Their
absence will be cause for significant dissatisfaction. Examples of expected
 requirements are: ease of human/machine interaction, overall operational
correctness and reliability, and ease of software installation.
3. Exciting requirements. These features go beyond the customer’s expectations and
prove to be very satisfying when present. For example, word processing software is
requested with standard features. The delivered product contains a number of page
layout capabilities that are quite pleasing and unexpected.

 In actuality, QFD spans the entire engineering process.

 In meetings with the customer, function deployment is used to determine the value
of each function that is required for the system.
 Information deployment identifies both the data objects and events that the system
must consume and produce. These are tied to the functions.
 Finally, task deployment examines the behaviour of the system or product within
the context of its environment.
 Value analysis is conducted to determine the relative priority of requirements
determined during each of the three deployments.

4. Use-Cases:-
 As requirements are gathered as part of informal meetings, FAST, or QFD, the
software engineer (analyst) can create a set of scenarios that identify a thread of
usage for the system to be constructed. The scenarios, often called use-cases,
provide a description of how the system will be used.
 To create a use-case, the analyst must first identify the different types of people (or
devices) that use the system or product. These actors actually represent roles that
people (or devices) play as the system operates. Defined somewhat more formally,
an actor is anything that communicates with the system or product and that is
external to the system itself.
 Once actors have been identified, use-cases can be developed. The use-case
describes the manner in which an actor interacts with the system.
 The following are the suggested questions that should be answered by the use-case:
o What main tasks or functions are performed by the actor?
o What system information will the actor acquire, produce, or change?
o Will the actor have to inform the system about changes in the external
environment?
o What information does the actor desire from the system?
o Does the actor wish to be informed about unexpected changes?
 In general, a use-case is simply a written narrative that describes the role of an actor
as interaction with the system occurs.

3.2 Fact-Finding Techniques

Information gathering in a large and complex organization is not an easy task. It is gathered in an
organized way such that:
 o No system details are left out
o Right problems are identified
o Repetition is avoided
o Wrong or incomplete details are not collected
 To study any system the analyst needs to do collect facts and all relevant information.
These facts when expressed in quantitative form are termed as data. The success of any
project is depended upon the accuracy of available data. Accurate information can be
collected with help of certain methods/ techniques. These specific methods for finding
information of the system are termed as fact finding techniques.
 Fact-finding is the formal process of using techniques such as interviews and
questionnaires to collect facts about systems, requirements, and preferences.
 It establishes what the existing system does and what the problems are, and leads to a
definition of a set of options from which the users may choose their required system.
 It is also called “Information Gathering “or “Data-collection”.

The following are the commonly used Fact-Gathering techniques:

1. Interviewing
2. Questionnaires
3. Record review or Inspection
4. Observations

1) Interviewing:

 Interview is a very important data gathering technique as in this the analyst directly
contacts system and the potential user of the proposed system.
 Analysts can use interviews to collect information about the current system from the
potential users. Here the analysts discover the areas of misunderstanding, unrealistic
exceptions and descriptions of activities and problems along with resistance to the new
proposed system.
The following guidelines are very beneficial for a successful interview:
 Set the stage for the interview.
 Establish rapport; put the interviewee at ease.
 Phrase questions clearly and succinctly.
 Be a good listener; avoid arguments.
 Evaluate the outcome of the interview.
 The information collected is quite accurate and reliable as the interviewer can clear and
cross check the doubts there itself. This method also helps gap the areas of
misunderstandings and help to discuss about the future problems.
 The interviews are of two types namely structured and unstructured:

Structured Interview:
 Structured interviews are those where the interviewee is asked a standard set of
questions in a particular order. All interviewees are asked the same set of questions.
Unstructured Interview:
  The unstructured interviews are undertaken in a question-and-answer format. Here
the respondents are free to answer in their own words. In this way their views are
not restricted. So the interviewer gets a bigger area to further explore the issues
pertaining to a problem.

Following points are to be remembered while conducting interview.

1) Put yourself in other person's place and pause your questions. Appreciate his point of
view.

2) Do not jump directly to the conclusion.

3) Maintain neutral attitude however show genuien interest. so that other person can come
with his problem, taughts and ideas.

4) Let him do the most talking. Listen carefully. Listening is an art.

5) Ask specifications

6) Notice what he or she doesn't say.

Advantages of interviewing:

1. Interviews permit the system analyst to get individual’s views and get the specific
problem work wise operation.
2. Interviews allow the system analyst to obtain a better clarity of the problem due to
feedback from the interviewees.
3. In the process of interviews, the interviewer has time and scope to motivate the
interviewee to respond freely and openly.
4. Interviews allow the system analyst to understand the user requirements and to
know the problems faced by the user with the current system.
5. It is an effective technique to gather information about complex existing systems.

2. Questionnaire:
 Questionnaires are useful when the analyst need to gather information from a large
number of people. It is not possible to interview each individual. Also if the time is very
short, in that case also questionnaires are useful. If the anonymity of the respondent is
guaranteed by the analyst then the respondent answers the questionnaires very
honestly and critically.
 The Questionnaires are of two types namely open-response and closed-structure:
o The objective of open-response questionnaire is to gather information and data
about the essential and critical design features of the system. The open-ended
question requires no response direction or specific response.
o The objective of closed-response questionnaire is to collect the factual
 information of the system. It gives an insight in how the people dealing with the
system behave and how comfortable are they with it. In this case the
respondents have to choose from a set of given responses.
 Advantage of Questionnaires:
1. It is an inexpensive means of collecting the data from a large group of individuals.
2. It requires less skill and experience to administer questionnaires.
3. Proper formulation and interaction with respondents leads to unbiased response
from the customers.
4. Customers can complete it at their convenience.
5. Responses can be tabulated and analyzed quickly.

3. Record Review (Inspection):

 Believe in record than in people! Thus a good analyst always gets the facts from
documents.
 The information related to the system is published in the sources like newspapers,
magazines, journals, documents etc. This record review helps the analyst to get valuable
information about the system and the organization.
 An existing system can be better understood the examining existing documents, forms
and files.
 This record review can take place at the beginning of the system study or later in the
study for comparing actual operations with what the record indicate.
 Records may include:
o Written policy manuals
o Rules and regulations
o Standard operating procedures used in organizations
o Forms and documents
 The following question may be useful in analysis of forms :
1. Who uses these forms?
2. Do they include all necessary information?
3. How readable and easy to follow is the form
4. Is it ideal for analysis for interference? Etc.

4. Observations:
 An analyst must always keep his mental antenna alert! Observation can bring in missed
facts, new ways to improve the existing procedures, duplicate work done inadvertently,
etc.
 The analysts have to identify the right information and choose the right person and look
at the right place to achieve his objective. He should have a clear vision of how each
departments work and work flow between them and for this he should be a good
observer.
 Observation can bring in what other fact finding methods cannot. But this task is delicate
because people do not like to be observed when they work.
 It is not the quantity of time observed is important but the personal angles of
observations of the work content and methods are going to be rewarding.
 Observation can look for:
 1. Operational inefficiencies.
2. Alternate routes and procedures.
3. Interruptions in the normal flow of work.
4. The usage of files and documents
5. Informal communication channels etc
 On site observation provides close view of working of the real system. He can observe
people, objects, documents and occurrences of events. But the analyst’s role should be
strictly to obtain information as a separate observer.

Role of a System Analyst

 For performing requirements analysis activity system analyst collects all relevant data
regarding the product to be developed from the users of the product and from the
customer through interviews and discussions.
 A system analyst identifies all ambiguities and contradictions in the requirements and
resolves them through further discussions with the customer.
 Overlaps business and technical issues.
 Translates business requirements into practical IT projects to meed the needs
 Performs tasks such as
o Building profiles
o Review business process
o Select hardware and software packages
o Design information systems
o Training users
o Planning e-commerce Web sites
o Plans projects
o Develops schedules
o Estimates costs
o Conducts meetings, delivers presentations and writes memos, reports and
documentation

Recording outcomes
 Many system studies fail because of poor data recording. Care must be taken to record
the data, their source, and the time of collection.
 The form of the notebook varies according to the type of study, the amount of data, the
number of analysts, and their individual preferences.
 The notebook may be a card file, a set of carefully coded file folders. It should be bound
and the page numbered.
 Data Capture and the Notebook
1. Originals or duplicate copies of all notes taken during investigation are documented.
They are the chief sources of interview and observational data, as well as
background information on the system. Each page of notes should be numbered
serially, and a running sequential record of them should be kept. The name of the
analyst, the date the notes were taken, and surrounding circumstances are all
important. Since handwritten notes often are not clear to others, it is good to have
 them transcribed or typed soon after they are taken
2. Copies of all information-gathering tools-questionnaires, interview schedules,
observation guides- are placed in the notebook for future reference.
3. Copies of all data –originals or duplicates-are included. Loss of key data, even
temporarily, can be costly.
4. Minutes of all meetings as well as a record of discussions, decisions, and changes in
design all become part of the notebook.

3.3 Effort Distribution

Effort distribution that is expressed in percentage is used distributing effort estimated into effort per
activities of software development project. In addition to the distribution of effort per activity, this research
also obtains the distribution of effort per role/position of the software development team.

3.4 Importance of Requirement Specification

What is specification?

 The specification is directly associated with the quality of software. If the specification is
incomplete its results into frustration and confusion among the software engineer and
ultimately it affects the quality, completeness, timeliness of the software.
 The software specification can be viewed as representation of the requirements which
tends us to successful software implementation.
 Specification is a description of what is desired rather than how it is to be obtained.

There are 3 parties interested in new system.

1) Client
2) Developer
3) User

Client doesn't understand software development process and developer doesn't

understand client problems because of this communication gap between two parties
involved in development project.

So the basic purpose of SRS is to bridge the communication gap between parties.
SRS is medium through which the client and user needs are actually specified to the
developer.
Advantages:

1) An SRS establishes the bases for argument between client and developer on what
 software should do?

The SRS become the legal agreement or contract between client and developer. So through
SRS the client clearly describe WHAT he expects from developer and developer clearly
understood what lient wants?

2) An SRS provides a reference for validation of final product.

The SRS helps the client to determine if the software meets the requirement. Without a
proper SRS, there is no way a client can determine - the software being delivered WHAT
was ordered and there is no way, developer can convince the client that all
requirements have been fulfill

3) High quality SRS is a pre-requisite to high quality S/W.

Many errors are made during a requirement phase and those errors most likely visible in
the final system.

If SRS document specifies a wrong system then even a correct implementation of incorrect
SRS, will not satisfy a client.

So if we want error free software than we need error free SRS.

4) A high quality SRS reduces development cost.

Errors can exist in the SRS. The cost of fixing the errors increases as time progresses means
the cost of detecting and removing the errors are 100 times more after development
compare to requirement analysis.

We can reduce the project cost by reducing the error in the SRS.
For example, if we spend additional 100 hours in requirement phase than we may find
average of 50 requirements errors. If this errors are not detected in requirement phase
than they will be detected at later stage either in designing or coding or testing and the
cost of correcting those errors will be very high.

So the quality of SRS impact customer satisfaction, system validation, quality of final
software and software development cost.

3.5 SRS Characteristics

The final output of the requirement analysis phase is the software requirements
specification document it is also known as SRS document. To properly satisfy the basic goals
and SRS should contain different types of the requirements following are some of the desirable
characteristics of SRS.
 1) Correct

An SRS is correct if every requirement included in the SRS represents something required
in the final system.

2) Complete

An SRS is complete when it is documented after,

 Involvement of all types of concerned staff(user).

 Focusing on all problems, goals and objectives, functions(task) and features.
 Correct definitions(task) and features.
 Correct definition of scope and boundaries of software and system.

3) Unambiguous (unmistakable)

An SRS is unambiguous if and only is every requirements stated or written has one and only one
interpretation.

Ambiguous requirements may have more than one meaning and can confuse developers.

4) Verifiable.

An SRS is verifiable if every stated requirement is verifiable because final software is checked
against these requirements.

The requirements should have as little subjectivity as possible because subjective requirements
are difficult to varify.

5) Consistent.

The consistency in the SRS is essential to achieve correct result across the system.
This is achieved by
1) The use of standard terms and definitions.
2) Consistent application of business rule in all functionality.
3) The use of data dictionary.

6) Ranked for importance and stability.

Generally all the requirements for software are not of equal importance. Some are critical others
are important but not critical and there are some which are desirable but not very important
Similarly some requirements are CORE(main) requirements which are not likely to be changed as
time passed while others are dependent on time. An SRS is ranked for importance, for stability and
for consistency.

7) Modifiable

They are later modified as the needs of the clients change. SRS should be easy to modify. SRS is
modifiable if its structures and style are such that any necessary change can be made easily while
continuing completeness and consistency.

8) Traceable

An SRS is traceable if the origin of each of its requirement is clear and if it fulfill the reference of
each requirement. In future development, Requirements should be traceable to some design and
code element and back word traceability requirement.

3.6 Software Requirement Specification Document

Component of SRS.

There are 4 types of requirements.

1) Functional Requirements.
2) Performance Requirements.
3) Design Constraints.
4) External Interface requirements.

1) Functional Requirements.

Functional Requirements Specified which output should be produce from the given
input.
They describe the relationship between the input and output of the system. for each
functional requirement a detail description of all the data input and their source the unit
of measure and the range of valid output must be Specified.
All the operations to be performed on the input data to obtain the output should be
specified. This include specified the validity checks on the input or output data
parameters effected by the operations and other legal operations used to transfer input
into the output.

The functional requirements must state or explain WHAT system should do if invalid
input or error occurs means It should specify behavior of the system.
An important part of the specification is the system behavior in abnormal situation like
invalid input or error during computation. The function requirement must clearly state
that what the system should the do in such situation. . Ex of the situation is an airline
reservation system where a reservation cannot be made even for valid passenger if the
airline is fully full in sort the system behavior for input or all possible stacks should be
specified.
2) Performance Requirement
This part of an SRS specified the performance constraints on the software system. The
entire requirement relating to the performance characteristics of the system must be
clearly specified there are two types of performance requirements.
i) Static
ii) Dynamic

Static Requirement
Static requirement are those that impose constraints on the execution characteristics of
the system. This includes requirement like the number of terminal to be supported the
number of simultaneous users to be supported and the number of files that the system
has to process and their sizes. These are also called capacity requirement of the system.

Dynamic Requirement

Dynamic requirement specification constraints on the execution behavior of the system

this includes response and through put constrains on the system. Response time is
expected time for the completion of an operation under specified situation or
condition.

Throughput : It is the expected number of operations that can be performed at unit

time.

The SRS may specify the number of transaction must be process for time. What the
response time for a particular command should be requirement such as response time
should be good or the system must be able to process all the transaction quickly are not
describe because they are depended on machine can verified according to the machine.

3) Design Constraints

There are number of factors in client environment that may restrict the choice of design
such factors are,

a) Standard Compliance.
b) H/w limitations
c) Reliability and Fault Tolerance
d) Security

a) Standard Compliance:
This specifies the requirement for the standard system. The standard may include the
report format and accounting procedure.
There maybe audit, tracing requirement which require certain kind of recording of
operations in audit file.

b) Hardware Limitations.

The software may have to operate on some existing or predetermine hardware.

Hardware limitations may include types of machines to be used, operating system available
on system, language supported and limits on primary and secondary storage.

c) Reliability and Fault tolerance:

Fault tolerance requirement can place a major constraints on how system is to be design.
Fault tolerance requirements often make the system more complex and expensive.

Requirement about system behavior should be specified.

Recovery requirement are also very important and should be specified.

Recovery requirements are integrate part of software and it gives detail about what the
system should do of some failure occurs to ensure certain properties.

d) Security

Security requirements are necessary in defense, financial and other database systems.
Security requirement places restrictions on the use of certain commands, control access to
data, provide different types of access requirements for different people, require use of
password and use of cryptography techniques.

It should also maintain LOG of activity. They may also require proper assessment of security
threats and use of tools to detect errors.

4 External Interface Requirements

 All the possible interaction of the software with people, hardware and other
software should be clearly specified.
 For the user interface the characteristics each user interface of the software
product should be specified.
 User interface is become an important and must be given proper attention .A
preliminary user manual should be created with all user commands, screen
formats.
 An explanation of how the system will appear to the user and feedback and error
messages for hardware interface requirement the SRS should specified the
logical characteristics of each interface between the software product and
 hardware components.
 If the software is to execute on existing hardware or on predetermine hardware
all the characteristics of the hardware including memory restriction should be
specified.
 The interface requirement should specify the interface with other software the
system will use or that will use the system. These include the interface with the
operating system and other applications.

The structure of SRS

Software requirement specification (SRS) is produced at the end of analysis task. The
following is the general outlines for SRS, which is suggested by National Bureau of Standards
and U.S. Departments of defense.
I. Introduction
A. System reference
B. Overall description
C. Software project constraints
II. Information Description
A. Information content representation
B. Information flow representation
1. Data flow
2. Control flow
III. Functional Description
A. Functional partitioning
B. Functional Description
1. Processing narrative
2. Restrictions / Limitations
3. Performance requirements
4. Design constraints
5. Supporting diagrams
IV. Behavioral Description
A. System states
B. Events and actions
V. Validation criteria
A. Performance bounds
B. Classes of tests
C. Expected software response
D. Special considerations
VI. Bibliography
VII. Appendix
 The Introduction states the goals and objectives of the software, describing it in the
context of the computer based system.
The Information Description provides a detailed description of the problem that
software must solve.

A description of each function required to solve the problem is presented in the

Functional Description. A processing narrative is provided for each function; design constraints
are stated and justified; performance characteristics are stated.
The Behavioral Description section examines the operation of the software as a
consequence of external events and internally generated control characteristics.
The most important section of SRS is Validation Criteria.

The Bibliography contains references to all documents that relate to the software.
These include other software engineering documentation, technical references, vendor
literature, and standards.
The Appendix contains information that supplements the specification. Tabular data,
detailed description of algorithms, charts, graphs, and other material are presented as
appendixes.
In many cases SRS may be accompanied by an executable prototype, paper prototype,
or preliminary user’s manual.
The preliminary user’s manual presents the software as a black box. That is, heavy
emphasis is placed on user input and resultant output. The manual can serve as a valuable tool
for uncovering problems at the human-machine interface.