UNIT-3 REQUIREMENT ANALYSIS

What is Software Requirement?

• Requirement is a condition or capability possessed by a software or system component in
order to solve a real-world problem.
• IEEE defines requirement as :
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component
to satisfy a contract, standard, specification or other formally imposed document.

• Requirement describe how a system should act, appear or perform. Requirements differ from
one user to another and from one business process to another.
• Requirements help to understand the behaviour of a system, which is describe by various
tasks of the system.
• For example, some of the tasks of a system are to provide a response to input values,
determine the state of data objects and so on.
• Requirements are considered prior to the development of the software.
• Requirements are classified into following three categories.

1. Functional requirements
2. Non-function requirements
3. Domain requirements

1. Functional Requirement
• The functional requirements also known as behavioural requirements. It describe the
functionality or services that software should provide.
• So, function requirement describe the interaction of software with its environment and
specify the inputs, outputs, external interfaces and the other functions that should be included
in the software.
• Its services provided by functional requirements specify the procedure by which software
should react to particular inputs or behave in particular situations.
• So IEEE defined function requirements as “a function that a system or component must be
able to perform”.
• Example : Online Banking System
o The user of the bank should able to search the desired services from the available
ones.
o There should be appropriate documents for users to read. This implies that when a
user wants to open an account in the bank, the forms must be available so that the
user can open an account.

1
UNIT-3 REQUIREMENT ANALYSIS

o After registration, the user should be provided with a unique acknowledgement

number so that he can later be given an account number.
• Therefore mentioned functional requirements describe the specific services provided by the
online banking system.
• These requirements indicate user requirements and specify that functional requirements may
be describe at different levels of detail in an online banking system and with the help of
these functional requirements, users can easily view, search and download registration forms
and other information about the bank.
• On the other hand, if requirements are not stated properly, they are misinterpreted by software
engineers and user requirements are not met.

2. Non-Functional Requirements
• The non-functional requirements also known as quality requirements and it is related to
attributes such as reliability and response time.
• Non-functional requirements arise due to user requirements, budget constraints, and
organizational policies and so on.
• These requirements are not related directly to any particular function provided by the system.
• Non-functional requirements should be accomplished in software to make it perform
efficiently for example, if an airplane is unable to fulfil reliability requirements then it is not
approved for safe operation.
• Following three are non-functional requirements.
1. Product requirements
2. Organizational requirements
3. External requirements

Product requirements
• These requirements specifies how a software product performs.

• Efficiency requirements : it describe the extent to which the software makes optimal use of
resources, the speed with which the system executes and the memory it consumes for its
operations
• For example: the system should be able to operate at least three times faster than the existing
system.

• Reliability requirements: it describe the acceptable failure rate of the software.

• For example: software should be able to operate even if a hazard occurs.

• Portability requirements: it describe the ease with which software can be transferred from
one platform to another.
• For example: it should be easy to port the software to a different operating system without
the need to redesign the entire software.

• Usability requirements: it describe the ease with which users are able to operate the
software.
• For example: the software should be able to provide access to functionality with fewer
keystrokes and mouse clicks.

2
UNIT-3 REQUIREMENT ANALYSIS

Organizational Requirements

• These requirements are derived from the policies and procedures of an organization.

• Delivery Requirements: it specify when the software and its documentation are to be
delivered to the user.

• Implementation Requirements: it describe requirements such as programming language

and design method.

• Standards requirements: it describe the process standards to be used during software

development.
• For example: the software should be developed using standards specified by the ISO
(international Organization for Standardization) and IEEE standards.

External Requirement
• These requirements include all the requirements that affect the software or its development
process externally.

• Interoperability requirements: it define the way in which different computer-based system

interact with each other in one or more organizations.

• Ethical requirements: it specify the rules and regulations of the software so that they are
acceptable to users.

• Legislative requirements: it ensure that the software operates within the legal jurisdiction.
• For example, pirated software should not be sold.

• Non-functional requirements are difficult to verify. Hence, it is essential to write non-

functional requirements quantitatively so that they can be tested.

3. Domain Requirements
• Requirements which are derived from the application domain of a system instead from the
needs of the users are known as domain requirements.
• These requirements may be new functional requirements of specify a method to perform
some particular computations.
• In addition, these requirements include any constraint that may be present in the existing
functional requirements.
• As domain requirements reflect he fundamentals of the application domain, it is important to
understand these requirements. And also, if these requirements are not fulfilled, it may be
difficult to make the system work as desired.
• A system can include a number of domain requirements. For example, it may comprise a
design constraint that describe the user interface, which is capable of accessing all the
database used in a system.
• It is important for a development team to create databases and interface designs as per
established standards.
• Similarly, the requirements of the user, such as copyright restrictions and security mechanism
for the files and documents used in the system are also domain requirements.

3
UNIT-3 REQUIREMENT ANALYSIS

Requirement Gathering techniques

• A requirement gathering is carried out to obtain the requirements from system users,
customers and other stakeholders.
• The procedure is also sometimes referred to as requirements elicitations.
• Before requirements can be analysed, modelled, or specified they must be gathered through
an elicitation process. Some requirement gathering techniques are as following:
1. Interviews
2. Questionnaires
3. Record Review
4. Observation
5. Joint Application Development
6. FAST

1. Interviews
• Interview is fact finding technique, where two parties work together, one person act as an
interviewer and other as interview.
• The person who collects information is known as system analyst, who plays the role of
interviewer.
• System analyst collects fact from individuals who are known as interviewees. The
interviewees are usually present user of the existing system or possible user of the proposed
system.
• The interviewees may be manager or employee who offer data for the proposed system.
• There are two type of interview
o Structured
o Unstructured
Structured: 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: the unstructured interviews are undertaken in a question and answer
format. This is of a much more flexible nature than the structured interview and can be
very rightly used to gather general information about the system.
• Advantages:
o Beneficial for those individuals who cannot communicate effectively in wrting.
o Allow the analyst to determine areas of confusion, impractical prospect and even
indicates to the points for resistance to the proposed system.
o It is considered as the best qualitative(opinions, policies and subjective description)
source of information gathering.
o Permits the interviewees to reply freely and openly to any ype of questions.
• Disadvantages:
o Interviews are considered as time consuming and costly fact finding technique.
o Interviews can be subject to bias if the interviewer has a closed mind about the
difficulty.
o This technique fails if suitable environment is not provided for conduction interview.

4
UNIT-3 REQUIREMENT ANALYSIS

2. Questionnaires
• Questionnaires are a further method of information gathering where the potential user of the
system are given questionnaires to be filled up and returned to the analyst.
• Questionnaires are special purpose documents that allow the analyst to collect information
and opinions from respondents.
• Questionnaires can help you collect information about what people do, what they have, what
they think, know, feel or want. Using this techniques we gather facts about the existing
system from number of persons.
• There are two types of questionnaires
o Structured
o Unstructured

Structure: in structured questionnaires, respondent needs to select from possible

options for answer and thus the range of answer is limited. Example of structured
questionnaires are – multiple choice, selection or ranking scale, selection of a rating
and filling the blanks.
Unstructured: in such method, respondents are made to answer freely. Such
questions are open ended. An open ended questionnaire just includes a question and
has a sufficient space for an unstructured reply.

• Advantages
o Questionnaires is considered as an economical way of collecting facts from a huge
number of people.
o If it is well formatted and designed, then the results can be easily analysed and
computerized.
o Respondents get time to think over the questions and provide more accurate data.

• Disadvantages
o Good questionnaires are difficult to construct.

3. Record Review (Recording outcome)

• Records and reports are the gathering of information and data collected over the time by the
users about the system and its operations.
• For better understanding of any existing system is to review its related records, existing
records or record review.
• It start at the preliminary stage of the system study or later on in the study for measuring
actual operations with what the records indicate.

4. Observation
• Another information gathering technique used by the system analyst is known as one site
observation or direct observation, where the analyst personally goes to the site and discovers
the functioning of the system.
• As an observer, the analyst can gain direct knowledge of the activities, operations, processes
of the system on site. Hence here the role of an analyst is of an information seeker.
• This technique is useful when on needs to actually observe how documents are handled, how
operations and activities are carried out.

5
UNIT-3 REQUIREMENT ANALYSIS

• Advantages
o Facts gathered using this technique is highly reliable.
o Inexpensive way of collecting data.
o Using this technique, the system analyst can make out tasks that have been missing
or wrongly illustrated by other fact finding techniques.
• Disadvantages
o This technique is too time-consuming and the analyst should not jump to conclusions
or draw assumption from minute samples of observation rather the analyst should be
more patient in gathering the information.

5. Joint Application Development

• JAD was developed by Chuk Morris of IBM Raleigh and Tony Crawford of IBM Toronto in
the late 1970’s.
• Originally, JAD was designed to bring system developers and users of varying backgrounds
and opinions together in a productive and creative environment.
• JAD is a technique that allows the developments, management and customer group to wok
jointly to build a product. It is a series of highly structured interviewed sessions aimed at
reaching on a project’s goal and scope. A typical JAD project is from 3 to 6.
• JAD concepts is based on 4 ideas,
o The users who do the job have the best understanding of that job.
o The developers have the best understanding of how technology works.
o The business process and the software development process work the same basic way.
o The best software comes out of a process that all groups work as equal and as on.

• Advantages:
o JAD actively involves users and management in the development project.
o JAD helps to avoid the requirements from being too specific and that cause trouble
during implementation and acceptance.
o JAD reduce the amount of time required to develop systems since it eliminates
process delay and misunderstandings and improved system quality.

• Disadvantages:
o Slow communication and long feedback time.
o Weak or no support from upper management.
o Bad documentation.

6. FAST : Facilitate Application Specification Techniques

• FAST is important technique for requirements elicitation. FAST is a technique for gathering
requirements during early stage of analysis and specification.
• The main objective of this technique is to cover the gap between what the developers think
they are going to design and what customer believe they will receive from the particular
program.
• This is team oriented approach for requirement gathering.
• Meeting is conducted and attending by both software engineer and customer.
• Rules for preparation and participation are established.
• The mail goal is to identify the problem, purpose element of the solution, negotiate different
approaches and specify a preliminary set of software requirements in an atmosphere that is
conductive to accomplish the goal.

6
UNIT-3 REQUIREMENT ANALYSIS

What is effort Distribution?

A recommended distribution of effort across the development and definition phases is often
providing to as the 40-20-40 rule.

40 % or more of all effort is allocated to front end design and analysis tasks.

A same % is applied to back-end testing. You can correctly infer which coding is de-emphasized.

40-20-40 rule is best for software/website development

During developing a software/website, most of the software/website developers/engineers use

60-80% of total time for coding and they use rest of his time for project analysis, database design
and testing whereas the traditional software development life cycle follows 40-20-40 rule during
development of software or website which mean developer should spend 40% of total time for
project analysis and design, 20% for programming and rest of 40% for testing.

A real Project Manager, System Analyst or Senior Software developer or engineer will
understand about its benefit deeply.

Because you will not able to design database properly without having proper knowledge of the
project.

Developers will face many difficulties and programming will time consuming without a good
database design.

So, project analysis and design is more important part at the beginning of development. If your
project analysis and database design is good, then your programming time will be reduced.

And after programming, most of the companies deliver software without proper testing.
Thus, client become angry because of lots of errors.

Developers provide lots of time for programming, but they don't provide 20% of programming
time for testing. So result is - client find lots of error after software delivery.

You will able to develop error-free software only if you do proper analysis and design at the
beginning and do a proper testing at the end. So best time distribution is 40-20-40 ratios. This
ratio can vary little bit. But bigger changes will be harmful for you.

7
UNIT-3 REQUIREMENT ANALYSIS

Explain the importance of Requirement Specifications.

• It contains a complete information description, a detailed functional description, a

representation of system behaviour, an indication of performance requirements and design
constraints, appropriate validation criteria, and other information pertinent to requirements.
• Software requirement specification (SRS) is a document that completely describes what the
proposed software should do without describing how software will do it.

Characteristics of SRS
• Software Requirement Specification have following characteristics
Correct
• SRS is correct when all user requirements are stated in the requirements document.
• The stated requirements should be according to the desired system.
• This implies that each requirement is examined to ensure that it (SRS) represents user
requirements.
• Note that there is no specified tool or procedure to assure the correctness of SRS. Correctness
ensures that all specified requirements are performed correctly.
Complete
• SRS is complete when the requirements clearly define what the software is required to do.
• This includes all the requirements related to performance, design and functionality.
Unambiguous
• SRS is unambiguous when every stated requirement has only one interpretation. This
implies that each requirement is uniquely interpreted.
• In case there is a term used with multiple meanings, the requirements document should
specify the meanings in the SRS so that it is clear and easy to understand.
Ranked for importance/stability
• All requirements are not equally important; hence each requirement is identified to make
differences among other requirements.
• For this, it is essential to clearly identify each requirement. Stability implies the probability
of changes in the requirement in future.
Modifiable
• The requirements of the user can change; hence requirements document should be created
in such a manner that those changes can be modified easily, consistently maintaining the
structure and style of the SRS.
Traceable
• SRS is traceable when the source of each requirement is clear and facilitates the reference
of each requirement in future.
• For this, forward tracing and backward tracing are used.
• Forward tracing implies that each requirement should be traceable to design and code
elements.

8
UNIT-3 REQUIREMENT ANALYSIS

• Backward tracing implies defining each requirement explicitly referencing its source.
Verifiable
• SRS is verifiable when the specified requirements can be verified with a cost effective
process to check whether the final software meets those requirements.
• The requirements are verified with the help of reviews. Note that unambiguity is essential
for verifiability.
Consistent

• SRS is consistent when the subsets of individual requirements defined do not conflict with
each other.
• For example, there can be a case when different requirements can use different terms to refer
to the same object.
• There can be logical or time-based conflicts between the specified requirements and some
requirements whose logical or time-based characteristics are not satisfied.
• For instance, a requirement states that an event 'a' is to occur before another event 'b'. But
then another set of requirements states (directly or indirectly by transitivity) that event 'b'
should occur before event 'a'.

Components of SRS
• Following are some components of SRS
1. Functional requirements
2. Performance requirements
3. Design constraints
4. External interface requirements
Functional Requirements
• Functional requirements specify what output should be produced from the given inputs.
• So they basically describe the connectivity between the input and output of the system.
• For each functional requirement:
o A detailed description of all the data inputs and their sources, the units of
measure, and the range of valid inputs be specified:
o All the operations to be performed on the input data obtain the
output should be specified, and
o Care must be taken not to specify any algorithms that are not parts of the
system but that may be needed to implement the system.
o It must clearly state what the system should do if system behaves
abnormally when any invalid input is given or due to
some error during computation. Specifically, it should specify the
behaviour of the system for invalid inputs and invalid outputs.
o
Performance Requirements (Speed Requirements)
• This part of an SRS specifies the performance constraints on the software system. All the
requirements related to the performance characteristics of the system must be clearly
specified.
• Performance requirements are typically expressed as processed transaction s per second or
response time from the system for a user event or screen refresh time or a combination of
these.

9
UNIT-3 REQUIREMENT ANALYSIS

• It is a good idea to pin down performance requirements for the most used or critical
transactions, user events and screens.
Design Constraints
• The client environment may restrict the designer to include some design constraints that
must be followed.
• The various design constraints are standard compliance, resource limits, operating
environment, reliability and security requirements and policies that may have an impact on
the design of the system.
• An SRS should identify and specify all such constraints.
Standard Compliance: It specifies the requirements for the standard the system must
follow. The standards may include the report format and according procedures.
Hardware Limitations: The software needs some existing or predetermined hardware to
operate, thus imposing restrictions on the design. Hardware limitations can includes the
types of machines to be used operating system availability memory space etc.
Fault Tolerance: Fault tolerance requirements can place a major constraint on how the
system is to be designed. Fault tolerance requirements often make the system more complex
and expensive, so they should be minimized.
Security: Currently security requirements have become essential and major for all types of
systems. Security requirements place restriction s on the use of certain commands control
access to database, provide different kinds of access, requirements for different people,
require the use of passwords and cryptography techniques, and maintain a log of activities
in the system.
External Interface Requirements
• For each external interface requirements:
o All the possible interactions of the software with people hardware and other software
should be clearly specified,
o The characteristics of each user interface of the software product should be specified
and
o The SRS should specify the logical characteristics of each interface between the
software product and the hardware components for hardware interfacing.

Software Requirement Specification Documents

1. Introduction
(i) Purpose of this document
(ii) Scope of this document
(iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices

10
UNIT-3 REQUIREMENT ANALYSIS

• Introduction:
(i) Purpose of this Document – At first, main aim of why this document is necessary and
what’s purpose of document is explained and described.
(ii) Scope of this document –In this, overall working and main objective of document and
what value it will provide to customer is described and explained. It also includes a
description of development cost and time required.
(iii) Overview –In this, description of product is explained. It’s simply summary or overall
review of product.

• General description: In this, general functions of product which includes objective of user,
a user characteristic, features, benefits, about why its importance is mentioned. It also
describes features of user community.

• Functional Requirements: In this, possible outcome of software system which includes

effects due to operation of program is fully explained. All functional requirements which
may include calculations, data processing, etc. are placed in a ranked order.

• Interface Requirements: In this, software interfaces which mean how software program
communicates with each other or users either in form of any language, code, or message are
fully described or explained. Examples can be shared memory, data streams, etc.

• Performance Requirements: In this, how a software system performs desired functions

under specific condition is explained. It also explains required time, required memory,
maximum error rate, etc

• Design Constraints: In this, constraints which simply means limitation or restriction are
specified and explained for design team. Examples may include use of a particular
algorithm, hardware and software limitations, etc

• Non-Functional Attributes: In this, non-functional attributes are explained that are

required by software system for better performance. An example may include Security,
Portability, Reliability, Reusability, Application compatibility, Data integrity, Scalability
capacity, etc.

• Preliminary Schedule and Budget: In this, initial version and budget of project plan are
explained which include overall time duration required and overall cost required for
development of project.

• Appendices: In this, additional information like references from where information is

gathered, definitions of some specific terms, acronyms, abbreviations, etc. are given and
explained.

11