REQUIREMENT

ENGINEERING
Software Requirements
The software requirements are description of features and functionalities of the target
system. The requirements can be obvious or hidden, known or unknown, expected or
unexpected from client’s point of view.
Requirement Engineering
The process to gather the software requirements from client, analyze, and document
them is known as requirement engineering. Requirements engineering provides the
appropriate mechanism for understanding what the customer wants, analyzing need,
assessing feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the requirements as they are
transformed into an operational system

Requirement Engineering Process

It is a four step process, which includes –
 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation
Let us see the process briefly -
Feasibility study / Inception
When the client approaches the organization for getting the desired product developed, it
comes up with a rough idea about what all functions the software must perform and
which all features are expected from the software. The analysts do a detailed study about
whether the desired system and its functionality are feasible to develop.
The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project
should be undertaken
Requirement Gathering / Elicitation
If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the
client and end-users to know their ideas on what the software should provide and which
features they want the software to include.

Software Requirement Specification (SRS)

SRS is a document created by system analyst after the requirements are collected from
various stakeholders. SRS defines how the intended software will interact with
hardware, external interfaces, speed of operation, response time of system, portability of
software
across various platforms, maintainability, speed of recovery after crashing, Security,
Quality, Limitations etc.
The requirements received from client are written in natural language and should come
up with the following features:

 User Requirements are expressed in natural language.

 Technical requirements are expressed in structured language, which is used inside the
organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.
Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements inaccurately.
Requirements can be checked against following conditions -
 If they can be practically implemented
 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
Requirement Elicitation
Requirement elicitation process can be depicted using the following description below:
Requirements gathering - The developers discuss with the client and end users and
know their expectations from the software.
Organizing Requirements - The developers prioritize and arrange the requirements
in order of importance, urgency and convenience.
Negotiation & discussion - If requirements are ambiguous or there are some conflicts
in requirements of various stakeholders, it is then negotiated and discussed with the
stakeholders. Requirements may then be prioritized and reasonably compromised. The
requirements come from various stakeholders. To remove the ambiguity and conflicts,
they are discussed for clarity and correctness. Unrealistic requirements are compromised
reasonably.
Documentation - All formal and informal, functional and non-functional
requirements are documented and made available for next phase processing.
Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the requirements for an intended
software system by communicating with client, end users, system users, and others who
have a stake in the software system development.
There are various ways to discover requirements. namely:-
Interviews
Interviews are strong medium to collect requirements. Organization may conduct..
Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is handed
over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.
Task analysis
Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is
studied and requirements of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert people in the domain can be
a great help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded
for further requirements analysis.

There are a number of problems in requirement elicitation.

• Problems of scope. The boundary of the system is ill-defined or the customers/users
specify unnecessary technical detail that may confuse, rather than clarify, overall system
objectives.
Problems of understanding. The customers/users are not completely sure of what is
needed,
• have a poor understanding of the capabilities and limitations of their computing
environment,
• don’t have a full understanding of the problem domain,
• have trouble communicating needs to the system engineer,
Problems of volatility. The requirements change over time.

However, The System engineers must approach the requirements gathering activity in an
organized manner and has to follow some standard and guidelines
.
The work products produced as a consequence of the requirements elicitation activity
will vary depending on the size of the system or product to be built. For most systems,
the work products include
 A statement of need and feasibility.
 A bounded statement of scope for the system or product.
 A list of customers, users, and other stakeholders who participated in the
requirements elicitation activity.
 A description of the system’s technical environment.
 A list of requirements (preferably organized by function) and the domain
constraints that apply to each.
 A set of usage scenarios that provide insight into the use of the system or product
under different operating conditions.
 Any prototypes developed to better define requirements.
Each of these work products is reviewed by all people who have participated in the
requirements elicitation
Characteristics of a Good Requirement
• Clear and Unambiguous
– Standard structure
– has only one possible interpretation
– Not more than one requirement in one sentence
• Correct– A requirement contributes to a real need
• Understandable– A reader can easily understand the meaning of the requirement
• Verifiable– A requirement can be tested
• Complete
• Consistent
• Traceable

Types of Requirement
Requirement can be broadly classified into two:
Functional Requirements
Requirements, which are related to functional aspect of software . it define the
basic system behaviour. Essentially, they are what the system does or must
not do, and can be thought of in terms of how the system responds to
inputs. Functional requirements are product features and focus on
user requirements. Functional requirements are product features or functions that
developers must implement to enable users to accomplish their tasks. So, it’s important
to make them clear both for the development team and the stakeholders. Generally,
functional requirements describe system behavior under specific conditions. For
instance:

A search feature allows a user to hunt among various invoices if they want to credit an
issued invoice.

They define functions and functionality within and from the software system.

Examples -
 Search option given to user to search from various invoices.
 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given separate rights.
Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this
category. They are implicit or expected characteristics of software, which users
make assumption of.
Non-functional requirements include -
 Security e.g Logging
 Storage
 Configuration
 Performance
 Interoperability
 Flexibility
 Disaster recover
 Security requirements ensure that the software is protected from unauthorized
access to the system and its stored data. It considers different levels of
authorization and authentication across different users roles
 Availability is gauged by the period of time that the system’s functionality and
services are available for use with all operations
 When writing the availability requirements, the team has to define the most critical
components of the system that must be available at all time.

User Interface requirements

User Interface (UI) is an important part of any software or hardware or hybrid
system. User acceptance majorly depends upon how user can use the software. UI is
the only way for users to perceive the system.
A software is widely accepted if it is –
 easy to operate
 quick in response
 effectively handling operational errors
 providing simple yet consistent user interface

A system is said to be good if it provides means to use it

efficiently. User interface requirements are briefly mentioned below –
 Content presentation
 Easy Navigation
 Simple interface
 Responsive
 Consistent UI elements
 Feedback mechanism
 Default settings
 Strategical use of color and texture.
 Provide help information
Requirements management
Requirements management is a set of activities that help the project team to identify,
control, and track requirements and changes to requirements at any time as the project
proceeds. Many of these activities are identical to the software configuration
management techniques. Like SCM, requirements management begins with
identification.
Each requirement is assigned a unique identifier that might take the form
<requirement type><requirement #>
where requirement type takes on values such as
F = functional requirement, D = data requirement,
B = behavioral requirement, I = interface requirement, andP= outputrequirement.
Behavioral R describe all the cases where the system uses the functional requirements
Hence, a requirement identified as F09 indicates a functional requirement assigned
requirement number 9.
Once requirements have been identified, traceability tables are developed. Shown
schematically in Figure 10.4, each traceability table relates identified requirements to one
or more aspects of the system or its environment.
 The system environment can be-:
 Processes.
 Requirements.
 Design.
 Engineering.
 Construction.
 Testing.
 Debugging.
 Deployment.
Software measures are fundamental requirements of software engineering. They
not only help to control the software development process but also aid to keep the
quality of ultimate product excellent.
Size Metrics - Lines of Code (LOC) (), mostly calculated in thousands of
delivered source code lines, denoted as KLOC.
 Function Point Count is measure of the functionality provided by the
software. Function Point count defines the size of functional aspect of the
software.
 Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the
upper bound of the number of independent paths in a program, which is
perceived as complexity of the program or its modules. It is represented in
terms of graph theory concepts by using control flow graph.
 Quality Metrics - Defects, their types and causes, consequence, intensity
of severity and their implications define the quality of the product.
 The number of defects found in development process and number of defects
reported by the client after the product is installed or delivered at clientend,
define quality of the product.
 Process Metrics - In various phases of SDLC, the methods and tools used,
the company standards and the performance of development are software
process metrics.
 Resource Metrics - Effort, time, and various resources used, represents
metrics for resource measurement.

Quality Functional Deployment (QFD)

Quality function deployment (QFD) is a management tool that provides a visual
connective process to help teams focus on the needs of the customers throughout the
total development cycle of a product or process. It provides the means for translating
customer needs into appropriate technical requirements for each stage of a
product/process‐development life‐cycle. It helps to develop more customer‐oriented,
higher‐quality products.

QFD is a technique that translates the needs of the customer into technical requirements for software
engineering. QFD identifies three types of requirements:

Normal requirements: These requirements reflect objectives and goals stated for a product or system
during meetings with the customer. Eg requested types of graphic display, specific system function.

Expected requirements: These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them. Ease of human/computer interaction, ease of
software installation

Exciting requirements: These requirements reflect features that go beyond the customer’s expectations
and prove to be very satisfying when present. Eg. Multitouch screen, visual voice mail delight every user
of the product.
The major steps involved in this procedure are –

1. Identify all the stakeholders, eg. Users, developers, customers etc

2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off

Measuring Requirements

As a practical matter, it is typically useful to have some concept of the “volume” of the requirements for a
particular software product. This number is useful in evaluating the “size” of a change in requirements, in
estimating the cost of a development or maintenance task, or simply for use as the denominator in other
measurements.
 Three levels of requirement

Business Level Requirements

Business Level define problems or opportunity about the product. The first level of product
requirements includes business requirements and business rules. Business requirements are
higher-level statements of the goals, objectives, or needs of the enterprise

Business requirements are the critical activities of an enterprise that must be performed to meet
the organizational objectives while remaining solution independent. A business requirements
document (BRD) details the business solution for a project including the documentation of
customer needs and expectations.

Consider the following business requirements.

 Problem Statement
 Project Vision
 Project Constraints (Budget, Schedule, and Resources)
 Project Objectives
 Project Scope Statements
 Business Process Analysis
 Stakeholder Analysis

The rules may include corporate policies, industry standards, national or international
legislation.

An s with all requirements, business requirements should be:

 Verifiable. Just because business requirements state business needs rather than technical
specifications doesn’t mean they mustn’t be demonstrable. Verifiable requirements are
specific and objective. A quality control expert must be able to check, for example, that
the system accommodates the debit, credit, and PayPal methods specified in the business
requirements
 Unambiguous, stating precisely what problem is being solved. For example, “This project
will be deemed successful if ticket sales increase sufficiently,
  Comprehensive, covering every aspect of the business need. Business requirements are
indeed big picture, but they are very thorough big picture.

“The ultimate business requirement is profit growth achieved through increased earnings or
decreased expenses.”

User Requirements

User requirements should specify the specific requirements which the user expects/wants from
software to be constructed from the software project. A user requirement should be Verifiable,
Clear and concise, Complete, Consistent, Traceable, Viable.

The user requirements document (URD) or user requirements specification is a document usually
used in software engineering that specifies what the user expects the software to be able to do.
User requirements readers are • Client managers • System end-users • Client engineers • Contractor
managers • System architects

System Requirements More detailed specifications of user requirements • Serve as a basis for
designing the system.

System requirements are all of the requirements at the system level that describe the functions
which the system as a whole should fulfill to satisfy the stakeholder needs and requirements,
System requirements are classified as either functional or supplemental requirements. A
functional requirement specifies something that a user needs to perform their work. For example,
a system may be required to enter and print cost estimates; this is a functional requirement. non-
functional requirements specify all the remaining requirements not covered by the functional
requirements are sometimes called quality of service requirements. The plan for implementing
functional requirements is detailed in the system design. The plan for implementing non-funct
requirements is detailed in the system architecture. These are expressed in an appropriate
combination of textual statements, views, and non-functional requirements; the latter expressing
the levels of safety, security, reliability, etc., that will be necessary.

System requirements play major roles in systems engineering, as it Provide a means of

communication between the various technical staff that interact throughout the project.
System Requirements readers are:• System end-users • Client engineers • System architects •
Software developers