MODULE -II:

Requirements Gathering-Objective- Important requirements gathering ways-Requirement

Analysis-Purpose, Requirement problem types-SRS Document-Users, Characteristics,
Categories of requirements-Design-Issues associated with design, Classification of design
activities-Characteristics of good design- Cohesion-Definition, Classifications. Coupling-
Definition, Classifications-Design approaches-Function Oriented, Object Oriented Features
and Concepts
User Interface Design-characteristics and types

Requirements Gathering

Requirements gathering activity is also popularly known as requirements elicitation.

The primary objective of the requirements gathering task is to collect the requirements from the
stakeholders.

Gathering requirements turns out to be especially challenging if there is no working model of the
software being developed.

Requirements gathering activity is started by studying the existing documents to collect all possible
information about the system to be developed.

Different methods of requirement gathering

1. Studying existing documentation:

The analyst usually studies all the available documents regarding the system to be developed
Customers usually provide statement of purpose (SoP) document to the analyst.

2. Interview: Typically, there are many different categories of users of a software. Each category of
users typically requires a different set of features from the software. Therefore, it is important for
the analyst to first identify the different categories of users and then determine the requirements of
each.

3. Task analysis:

A service supported by a software is also called a task. The analyst tries to identify and understand
the different tasks to be performed by the software.

For each identified task, the analyst tries to formulate the different steps necessary to realise the
required functionality in consultation with the users.

4. Scenario analysis:

A task can have many scenarios of operation. The different scenarios of a task may take place when
the task is invoked under different situations. For different scenarios of a task, the behaviour of the
software can be different

5. Form analysis:
Form analysis is an important and effective requirements gathering activity that is undertaken by the
analyst, when the project involves automating an existing manual system. In form analysis, the
exiting forms and the formats of the notifications produced are analysed to determine the data input
to the system and the data that are output from the system.

Requirements Analysis
After requirements gathering is complete, the analyst analyses the gathered requirements to form a
clear understanding of the exact customer requirements. it is necessary to identify all the problems
in the requirements and resolve them through further discussions with the customer.

SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

The SRS document usually contains all the user requirements in a structured form.

Users of SRS Document

• Users, customers, and marketing personnel

• Software developers
• Test engineers
• User documentation writers
• Project managers
• Maintenance engineers

Characteristics of a Good SRS Document

Concise: The SRS document should be concise and at the same time unambiguous, consistent, and
complete. Irrelevant descriptions reduce readability and also increase the possibilities of errors in
the document.

Implementation-independent: The SRS should be free of design and implementation decisions

unless those decisions reflect actual requirements. It should only specify what the system should do
and refrain from stating how to do these. This means that the SRS document should specify the
externally visible behaviour of the system and not discuss the implementation issues.
the SRS document describes the output produced for the different types of input

Traceable: It should be possible to trace a specific requirement to the design elements that
implement it and vice versa. Similarly, it should be possible to trace a requirement to the code
segments that implement it and the test cases that test this requirement and vice versa. Traceability
is also important to verify the results of a phase with respect to the previous phase and to analyse
the impact of changing a requirement on the design elements and the code.

Modifiable: Customers frequently change the requirements during the software development due to
a variety of reasons. Therefore, in practice the SRS document undergoes several revisions during
software development. Also, an SRS document is often modified after the project completes to
accommodate future enhancements and [Link] cope up with the requirements changes, the
SRS document should be easily modifiable. For this, an SRS document should be well-structured. A
well-structured document is easy to understand and modify.

Identification of response to undesired events: The SRS document should discuss the system
responses to various undesired events and exceptional conditions that may arise.

Verifiable: All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to design test cases based on the description of the
functionality as to whether or not requirements have been met in an implementation.

Attributes of Bad SRS Documents

Over-specification: It occurs when the analyst tries to address the “how to” aspects in the SRS
document.

Forward references: One should not refer to aspects that are discussed much later in the SRS
document. Forward referencing seriously reduces readability of the specification.
Wishful thinking: This type of problems concern description of aspects which would be difficult to
implement.

Noise: The term noise refers to presence of material not directly relevant to the software
development process.

Categories of Customer Requirements

Functional requirements

The functional requirements capture the functionalities required by the users from the system. The
functional requirements of the system should clearly describe each functionality that the system
would support along with the corresponding input and output data set.

Non-functional requirements

The non-functional requirements are non-negotiable obligations that must be supported by the
software. The non-functional requirements capture those requirements of the customer that cannot
be expressed as functions. Non-functional requirements usually address aspects concerning external
interfaces, user interfaces, maintainability, portability, usability, maximum number of concurrent
users, timing, and throughput.

Categories of non-functional requirements

Design and implementation constraints:

External interfaces required:

Other non-functional requirements:

Structure of SRS / Organisation of the SRS Document

[Link]
Purpose: This section should describe where the software would be deployed and how the software would be used.
Project scope: This section should briefly describe the overall context within which the software is being developed.
Environmental characteristics: This section should briefly outline the environment (hardware and other software)
with which the software will interact.

2 Overall description

Product perspective: This section state whether the software is intended to be a replacement for a certain existing
system, or it is a new software.
Product features: This section should summarize the major ways in which the software would be used.
User classes: Various user classes that are expected to use this software are identified and described here.
Operating environment: This section should discuss in some detail the hardware platform on which the software
would run, the operating system, and other application software with which the developed software would interact.
Design and implementation constraints: In this section, the different constraints on the design and implementation
are discussed. These might include—corporate or regulatory policies; hardware limitations (timing requirements,
memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; specific
programming language to be used; specific communication protocols to be used; security considerations; design
conventions or programming standards.
User documentation: This section should list out the types of user documentation, such as user manuals, on-line help,
and trouble-shooting manuals that will be delivered to the customer along with the software.

3. Functional requirements
This section can classify the functionalities either based on the specific functionalities invoked by different users, or the
functionalities that are available in different modes, etc., depending what may be appropriate.

1. User class 1
(a) Functional requirement 1.1
(b) Functional requirement 1.2
2. User class 2
(a) Functional requirement 2.1
(b) Functional requirement 2.2

4. External interface requirements

User interfaces: This section should describe a high-level description of various interfaces and various principles to be
followed. The user interface description may include sample screen images, any GUI standards or style guides that are
to be followed, screen layout constraints, standard push buttons (e.g., help) that will appear on every screen, keyboard
shortcuts, error message display standards, etc. The details of the user interface design should be documented in a
separate user interface specification document.

Hardware interfaces: This section should describe the interface between the software and the hardware components
of the system. This section may include the description of the supported device types, the nature of the data and control
interactions between the software and the hardware, and the communication protocols to be used.

Software interfaces: This section should describe the connections between this software and other specific software
components, including databases, operating systems, tools, libraries, and integrated commercial components, etc.
Identify the data items that would be input to the software and the data that would be output should be identified and the
purpose of each should be described.

Communications interfaces: This section should describe the requirements associated with any type of
communications required by the software, such as e-mail, web access, network server communications protocols, etc.
This section should define any pertinent message formatting to be used. It should also identify any communication
standards that will be used, such as TCP sockets, FTP, HTTP, or SHTTP. Specify any communication security or
encryption issues that may be relevant, and also the data transfer rates, and synchronisation mechanisms.
5. Other non-functional requirements

This section should describe the non-functional requirements other than the design and implementation constraints and
the external interface requirements that have been described in Sections 2 and 4 respectively.
Performance requirements: Aspects such as number of transaction to be completed per second should be specified
here. Some performance requirements may be specific to individual functional requirements or features. These should
also be specified here.
Safety requirements: Those requirements that are concerned with possible loss or damage that could result from the
use of the software are specified here. For example, recovery after power failure, handling software and hardware
failures, etc. may be documented here.
Security requirements: This section should specify any requirements regarding security or privacy requirements on
data used or created by the software.

Cohesion and Coupling:

Cohesion:

Cohesion is a measure that defines the degree of intra dependability within elements of a module.
The greater the cohesion, the better is the program design.

There are seven types of cohesion, namely -

1. Coincidental cohesion - It is unplanned and random cohesion, which might be the result of
breaking the program into smaller modules for the sake of modularization. Because it is unplanned,
it may serve confusion to the programmers and is generally not-accepted.

2. Logical cohesion - When logically categorized elements are put together into a module, it is
called logical cohesion.

3. Temporal Cohesion - When elements of module are organised such that they are processed at a
similar point in time, it is called temporal cohesion.

4. Procedural cohesion - When elements of module are grouped together, which are executed
sequentially in order to perform a task, it is called procedural cohesion.

5. Communicational cohesion - When elements of module are grouped together, which are executed
sequentially and work on same data (information), it is called communicational cohesion.

6. Sequential cohesion - When elements of module are grouped because the output of one element
serves as input to another and so on, it is called sequential cohesion.

7. Functional cohesion - It is considered to be the highest degree of cohesion, and it is highly

expected

Coupling

Coupling is a measure that defines the level of inter dependability among modules of a program.
Lower the coupling better the program.

Content coupling-When a module can directly access or modify or refer to the content of another
module.
Common coupling- When multiple modules have read and write access to some global data.

Control coupling- Two modules are called control coupled if ine of them decides the function of
other module or changes its flow of execution.

Stamp coupling- When multiple modules share common data structure and work on different part of
it.

Data coupling- When two modules interact with each other by means of passing data. If a module
passes data structure as parameter when the receiving module should use all its components