SOFTWARE ENGINEERING
MODULE 2
IMPORTANT CATEGORIES OF CUSTOMER REQUIREMENTS
A good SRS document, should properly categorize and
organise the requirements into different sections [IEEE830].
As per the IEEE 830 guidelines, the important categories of
user requirements are the following.
An SRS document should clearly document the following
aspects of a software:
Functional requirements
Non-functional requirements
Design and implementation constraints
External interfaces required
Other non-functional requirements
Goals of implementation.
Functional requirements
• The functional requirements capture the functionalities required by the
users from the system.
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 (i.e., accepting input data
and producing output data).
• Non-functional requirements usually address aspects concerning external
interfaces, user interfaces, maintainability, portability, usability, maximum
number of concurrent users, timing, and throughput (transactions per
second, etc.).
ð The different categories of nonfunctional requirements that
are described under three different sections:
Design and implementation constraints:
• Design and implementation constraints are an important category of non-
functional requirements describe any items or issues that will limit the
options available to the developers.
External interfaces required:
• Examples of external interfaces are— hardware, software and
communication interfaces, user interfaces, report formats, etc.
• To specify the user interfaces, each interface between the software and
the users must be described.
• The description may include sample screen images, any GUI standards or
style guides that are to be followed, screen layout constraints, standard
buttons and functions (e.g., help) that will appear on every screen,
keyboard shortcuts, error message display standards, and so on.
Other non-functional requirements:
• This section contains a description of non- functional requirements that
are neither design constraints and nor are external interface requirements.
• An important example is a performance requirement such as the number
of transactions completed per unit time.
• other non-functional requirements may include reliability issues, accuracy
of results, and security issues.
Goals of implementation
• The ‘goals of implementation’ part of the SRS document offers some general suggestions regarding
the software to be developed.
• These are not binding on the developers, and they may take these suggestions into account if
possible.
• For example, the developers may use these suggestions while choosing among different design
solutions.
• A goal, in contrast to the functional and non-functional requirements, is not checked by the
customer for conformance at the time of acceptance testing.
REQUIREMENTS SPECIFICATION:
This activity is used to produce formal software requirement models.
All the requirements including the functional as well as the non-
functional requirements and the constraints are specified by these
models in totality.
During specification, more knowledge about the problem may be
required which can again trigger the elicitation process. The models
used at this stage include ER diagrams, data flow diagrams(DFDs),
function decomposition diagrams(FDDs), data dictionaries, etc.
Requirements specification is the process of documenting the
requirements identified in the analysis step in a clear, consistent,
and unambiguous manner. This step also involves prioritizing and
grouping the requirements into manageable chunks.
REQUIREMENTS VALIDATION:
The work products produced as a consequence of requirements engineering are
assessed for quality during a validation step.
Requirements validation examines the specification to ensure that all software
requirements have been stated unambiguously and that the work products
conform to the standards established for the process, the project, and the
product.
The primary requirements validation mechanism is the technical review.
The review team that validates requirements includes software engineers,
customers, users, and other stakeholders who examine the specification
looking for errors in content or interpretation, areas where clarification may
be required, missing information, inconsistencies (a major problem when large
products or systems are engineered), conflicting requirements, or unrealistic
(unachievable) requirements.
REQUIREMENTS CHANGE
In many projects, requirements evolve over time. As work proceeds, you may
discover that something you thought would be easy is hard. Or you may
stumble across a technique that lets you add a high‐value feature with little
extra work.
Often changes are driven by the customers. After they start to see working
pieces of the application, they may think of other items that they hadn’t
thought of before.
Depending on the kind of project, you may accommodate some changes, as
long as they don’t get out of hand. You can help control the number of
changes by creating a change control board.
Customers (and others) can submit change requests to this board (which
might actually be a single person) for approval. The board decides whether a
change should be implemented or deferred to a later release.
ORGANIZATION OF THE SRS DOCUMENT
► In this section, we discuss the organization of an SRS
document as prescribed by the IEEE 830 standard[IEEE
830].
