System Requirement analysis and Specification:

System:

- It is a set or arrangement of things so related as to form a unity or organic whole;

- It is a set of facts, principles, rules etc., classified and arranged in an orderly form so as
to show a logical plan thinking the various parts;
- It is a method or plan of classification or arrangement;
- It is an established way of doing something; method; procedure.

Computer-Based System is defined as a set or arrangement of elements that are organized to

accomplish some predefined goal by processing information.

Computer-Based System Elements

· Software: Computer programs, data structures, and related documentation that serve
to effect the logical method, procedure or control that is required.

· Hardware: Electronic devices that provide computing capability, the interconnectivity

devices (e.g., network switches, telecom devices) that enable the flow of data and
electromechanical devices (e.g., sensors, motors, pumps) that provide external world
function.

People: Users and operator of hardware and software.

· Database: A large, organized collection of information that is accessed via software.

· Documentation: Descriptive information ( e.g., hardcopy manuals, online help files,
Web sites) that portrays the use and/or operation of the system.
· Procedures: The steps that define the specific use of each system element or the
procedural context in which the system resides.
System Engineering Hierarchy

1. World view
2. Domain View
3. Element view
4. Detailed view

System Engineering encompasses a collection of top-down and bottom-up methods to navigate

the hierarchy as shown in the fig below. The system engineering process begins with a "world
view". That is, the entire business or product domain is examined to ensure that the proper
business, or technology context can be established. The world view is refined to focus more
fully on specific domain of interest. Within a specific domain, the need for targeted systems (
data, software, hardware, people) is analyzed. Finally, the analysis, design, and construction of
a targeted system element is initiated.

At the top of the hierarchy, a very broad context is established and, at the bottom, detailed
technical activities are performed.

The world view (WV) is composed of a set of domains (Di), which can each be a system or
system of systems in its own right.
 WV = {D1, D2, D3, . . . , Dn}

Each domain is composed of specific elements (Ej) each of which serves some role in
accomplishing the objective and goals of the domain or component:

Di = {E1, E2, E3, . . . , Em}

Finally, each element is implemented by specifying the technical components (Ck) that achieve
the necessary function for an element:

Ej = {C1, C2, C3, . . . , Ck}

Software requirements:

- The software requirements are description of features and functionalities of the target
system.
- Requirements express the expectations of users from the software product.
- The requirements can be clear 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.
- The goal of requirement engineering is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes –

1. Feasibility Study
2. Requirement Gathering
3. Software Requirement Specification
4. Software Requirement Validation
Importance of Requirement Engineering

Requirement engineering is an important stage in any software development. It is also believed

if the requirement engineering is done appropriately then we can expect that the final software
developed doesn’t lag behind in terms of design or functionality leading to successful and
profitable software.

1. The requirement engineering provides a vision of the final software i.e. what the software
would do? This creates a sense of mutual understanding between the customer and the
software developer.
2. Requirement engineering also helps in defining the scope of the software i.e. what will be the
functionalities of the final software.
3. It also helps in perceiving the cost of the final software.
4. It also helps in perceiving the schedule up to which the software will be delivered to the
customer.

Qualities of Requirements

The requirements collected from the customer must be precise and must convey the customer
need to the software developer. Quality requirements possess the following features:

1. Complete: The specified requirements must be complete, there must be nothing

missing that is important for the development of the software.
2. Consistent: If the software requirements are provided by more than one customer.
Then the software engineer must ensure that the requirements provided by an
individual must not contradict the requirements provided by another customer.
3. Unambiguous: Each specified requirement must be unambiguous i.e. it must specify a
single meaning.
 4. Functions: The requirement must specify what functions or computations must the
software perform and not how they must be implemented.
5. Concise: Each requirement must be specified only once and there should not be
duplication of any requirement statement.
6. Minimum: The specified requirements must not carry unnecessary details.
7. Understandable: The specified requirements must be understandable by both customer
and software developer.
8. Achievable: The requirement must be technically feasible.
9. Testable: It can be verified that the requirements are collected completely.

Types of Software Requirement

There are three types of software requirements as follows:
1. Functional requirements
2. Non-Functional requirements
3. Domain requirements

1. Business Requirements

Business requirements specify the software’s business demand. The business requirement
identifies why the software is required, who will be the end-users of the software, how the
software will benefit its end users.

The business requirement does specify the technicality of the software i.e. how it should be
implemented it focuses only on what software must do for them.
2. Users Requirements

The user requirements specify the need and expectations of the end-users of the software.
Although the user’s requirement is sometimes incorporated with the business requirements.
But sometimes requirements of software with more complex functionality or more complex
user interface must be documented separately.

3. Software Requirements

The software requirements specify what the software must do and it define how the software is
expected to perform. Type of software requirement are as follow:

1. Functional: The functional requirements describe what the software must deliver and
what it must not. How the software must respond to incorrect inputs. Thus, the
functional requirement describes the behaviour of the software.
2. Non-Functional: The non-functional requirements describe the non-behavioural aspects
of the system such as its scalability, reliability, performance, security, its portability,
reusability and flexibility.
3. Domain Requirements: The domain requirement describes the realm, area, group for
which the software is to be developed. Such as for college, office, military, hospital,
students, teachers, patients etc.

Requirement Engineering Process

The requirement engineering process involver certain steps that must be followed to collect the
entire specifications about the project.

1. Inception

In the inception phase we how the concept of the software has evolved. Does there was any
catalyst event that triggered the need for the software or its need has evolved over
time? Although there is no precise answer to this question the conversation starts with these
basic questions.

In the inception phase, the business requirements are identified where first the business need
is identified, the scope of the software in the market is analysed, a rough feasibility analysis is
done and the functioning of the software is discussed. Though all these requirements are
subject to change they are enough to start a conversation between business analysts or
customers or stakeholders and the software developers.

2. Requirement Elicitation

If the inception report is positive to undertake the project the next step is to gather the
requirement from the clients. This phase is the requirement elicitation phase where the system
 analyst or the software developers communicate with the clients or the end-users of the
system to elicit more information.

There are many things that the software analyst come across while eliciting the requirements
such as:

 The problem statement defined by the client or the end-user may have ill-defined boundaries
or the technical details provided by them might confuse the analyst or the developer regarding
the objective of the software to be developed.
 Even the clients or the end-user of the software are not sure about what they want. They are
unaware of the potential of their computing environment and even find it difficult to convey
the problem statement to the software engineer.
 In some cases, the client or end-user misses the most important information to convey to the
software engineer or provide ambiguous requirements.
 Sometimes the requirements of the clients or users change with time which raises confusion
among the software developers.

3. Requirement Specification

In terms of the software, the requirement specification can be a written document, a

mathematical model, graphical models, some usage scenarios, some sort of sample model,
some sort of code etc.

4. Negotiating Requirements

Now each client associated with the same project might have different versions of
requirements and they think that their aspect is more useful to develop software. Observing
the conflicting requirements, the software engineer has to reconcile and negotiate the facts
with the clients and end-users.

Negotiation is an iterative process where each client is asked to rank the requirement in terms
of priority. Parallelly the software engineer also assesses the cost associated with the project,
risk factors.

While addressing the conflicting requirements they may eliminate, add, combine or modify the
conflicting requirements so that each client sense some sort of satisfaction that their
requirements are essential for the development of the software.

5. Requirement Validation

Whatever is gathered, understood during the process of the requirement of engineering must
be validated to ensure that all the software requirements are specified. The software developer
or engineer must also ensure that the requirements are unambiguous, correct, consistent,
essential.
The requirement validation phase requires the presence of all like software developers, clients,
end-users and stakeholders. The specified requirements are checked thoroughly for any
missing, redundant, inconsistent information.

6. Requirement Management

Requirements of any software keep on changing and the business and technical change
throughout the life of the software. Requirement management is subject to keep track of the
requirements and the changes that occur during the development of the software.

So, these are the steps or tasks that must be performed in the requirement engineering
process. The efficient requirement engineering promises that developed software satisfies each
requirement specified and up to the standards.

Functional Requirements
Functional requirements are such software requirements that are demanded explicitly as basic
facilities of the system by the end-users. So, these requirements for functionalities should be
necessarily incorporated into the system as a part of the contract. They describe system
behavior under specific conditions. In other words, they are the functions that one can see
directly in the final product, and it was the requirements of the users as well. It describes a
software system or its components.
These are represented as inputs to the software system, its behavior, and its output. It can be a
calculation, data manipulation, business process, user interaction, or any other specific
functionality which defines what function a system is likely to perform.
A functional requirement can range from the high-level abstract statement of the sender's
necessity to detailed mathematical functional requirement specifications. Functional software
requirements help us to capture the intended behavior of the system.
Functional requirements can be incorporated into the system in many ways as
1. Natural language
2. A structured or formatted language with no rigorous syntax and formal specification
language with proper syntax.
Examples of functional requirements
1. Whenever a user logs into the system, their authentication is done.
2. In case of a cyber attack, the whole system is shut down
3. Whenever a user registers on some software system the first time, a verification email is sent
to the user.
Non-functional Requirements(NFRs)
These requirements are defined as the quality constraints that the system must satisfy to
complete the project contract. But, the extent may vary to which implementation of these
factors is done or get relaxed according to one project to another.
They are also called non-behavioral requirements or quality requirements/attributes.
Non-functional requirements are more abstract. They deal with issues like-
 Performance
  Reusability
 Flexibility
 Reliability
 Maintainability
 Security
 Portability
Non-Functional Requirements are classified into many types. Some of them are as:
 Interface Constraints
 Economic Constraints
 Operating Constraints
 Performance constraints: storage space, response time, security, etc.
 Life Cycle constraints: portability, maintainability, etc.
To perform the process of specification of non-functional requirements, we require knowledge
of the context within which the system will operate and an understanding of the system's
functionality.
Domain Requirements
Domain requirements are the requirements related to a particular category like software,
purpose or industry, or other domain of projects. Domain requirements can be functional or
non-functional. These are essential functions that a system of specific domains must necessarily
exhibit.
The common factor for domain requirements is that they meet established standards or widely
accepted feature sets for that category of the software project. Domain requirements typically
arise in military, medical, and financial industry sectors. They are identified from that specific
domain and are not user-specific.
Examples of domain requirements are- medical equipment or educational software.
Software in medical equipment
 In medical equipment, software must be developed per IEC 60601 regarding medical
electrical equipment's basic safety and performance.
 The software can be functional and usable but not acceptable for production because it
fails to meet domain requirements.
An Academic Software
 Such software must be developed to maintain records of an institute efficiently.
 Domain requirement of such software is the functionality of being able to access the list of
faculty and list of students of each grade.
Difference between Functional Requirement and Non-Functional Requirement
The following are the differences between functional and non-functional requirements:
Functional Requirement Non-Functional Requirement
It is used for defining a system and its It is used for defining the quality attribute of a
components. software system.

It focuses on what software will be doing. It fixes the constraint on which software should fulfill
 the functional requirement.

Techies like architects or software developers specify

The user specifies it.
it.

It is compulsory. It is not compulsory.

It is easy to define. It is comparatively tough to define.

It verifies the functionality of the system. It verifies the performance of the system.

It is defined as a system at the component

It is defined as a system as a whole.
level.

Example-System should be shut down if a Example-Within 10 seconds, the processing should be

cyber attack happens. done of each request.

Requirements elicitation
- In requirements engineering, requirements elicitation is the practice of
researching and discovering the requirements of a system from users,
customers, and other stakeholders.
- The practice is also sometimes referred to as "requirement gathering".
- The requirements elicitation process may appear simple: ask the customer,
the users and others
- It's a process of interacting with customers and end-users to find out about
the domain requirements, what services the system should provide, and
the other constraints.
In 1992, Christel and Kang identified problems that indicate the challenges
for requirements elicitation:

1. Problems of scope
2. Problems of understanding
3. Problems of volatility.
Requirements quality can be improved through these approaches:
1. Visualization. Using tools that promote better understanding of the
desired end-product such as visualization and simulation.
2. Consistent language. Using simple, consistent definitions for requirements
described in natural language and use the business terminology that is
prevalent in the enterprise.
3. Guidelines. Following organizational guidelines that describe the collection
techniques and the types of requirements to be collected. These guidelines
are then used consistently across projects.
4. Consistent use of templates. Producing a consistent set of models and
templates to document the requirements.
5. Documenting dependencies. Documenting dependencies and
interrelationships among requirements.
6. Analysis of changes. Performing root cause analysis of changes to
requirements and making corrective actions.

- The requirements elicitation and analysis has 4 main process

 1. Requirements Discovery: It’s the process of interacting with, and
gathering the requirements from, the stakeholders about the
required system and the existing system (if exist). It can be done using
some techniques, like interviews, scenarios, prototypes, etc, which
help the stockholders to understand what the system will be like

Interviews

- In Interviews, requirements engineering teams put the questions to the

stakeholder about the system that’s currently used, and the system to be
developed, and hence they can gather the requirements from the answers.

- The questions fall under two categories:

1. Closed-Ended Questions: A pre-defined set of questions.

2. Open-Ended questions: There is no pre-defined expected answer, they are

more generic questions.

Use Cases & Scenarios

The use cases and scenarios are two different techniques, but, usually, they are
used together.

Use cases identify interactions between the system and its users or even other
external systems (using graphical notations), while a scenario is a textual
description of one or more of these interactions.

Use case involves some symbols to describe the system:

 1. Actors: Are those who interact with the system; human or other systems

2. Interaction (Use Case): It denotes the name of the interaction (verb). It’s
represented as a named ellipse.

3. Connection: Lines that link between the actors and the interactions.

4. Include Relationship: It denotes a connection between two interactions when

an interaction is invoked by another. As an example, splitting a large
interaction into several interactions.

5. Exclude Relationship: It denotes a connection between two interactions when

you want to extend an interaction by adding an optional behavior, but you can
use the main interaction on its own without the extending interaction.

2. Requirements Classification & Organization: It’s very important to

organize the overall structure of the system. Putting related
requirements together, and decomposing the system into sub
components of related requirements. Then, we define the
relationship between these components.
 3. Requirements Prioritization & Negotiation: This activity is concerned
with prioritizing requirements and finding and resolving requirements
conflicts through negotiations until you reach a situation where some
of the stakeholders can compromise.
4. Requirements Specification: It is the process of writing down user
and system requirements into a document. The requirement should
be clear, easy to understand, complete and consistent.

What is Requirement Validation?

- Requirements Validation is the process of checking that the defined requirements
are for development, and defining the system that the customer really wants.
- Requirements validation helps us detect errors at an early stage of product
development so that it does not result in excessive rework when detected later in
the system development life cycle
- Requirements Validation is, its Process, and various Tools used for
Requirements Validation.

Validation VS Verification:
- Validation is the process of confirming that an item (a system, a work product or
a part thereof) matches its stakeholders’ needs.
- In Requirements Engineering, validation is the process of confirming that the
documented requirements match their stakeholders’ needs; in other
words: whether the right requirements have been specified.
- Verification is the process of confirming that an item (a system, a work product,
or a part thereof) fulfills its specification. Requirements verification is the process
of confirming that the requirements have been documented properly and satisfy
the quality criteria for requirements; in other words, whether the requirements
have been specified right.
- In simpler terms, Requirements verification is the process of confirming that the
system requirements contain all the necessary elements of well-written
requirements. Requirements validation is the process of confirming that the
written requirements agree with the stakeholders’ requests.
- In other words, verification is about checking whether the requirements are
complete, correct, and consistent. Validation is about checking whether the
requirements describe the intended system objectives and functions.

Why is it important to Validate?

- Validating the requirements helps check issues related to the requirements
specified during previous activities of requirements engineering. Usually, the
 validation is used to identify errors in the initial phases of the development cycle
related to misunderstandings in the requirements-gathering process. Validation
ensures accuracy and clarity in the data by mitigating any defects in the
requirements collected. Without validation, there is a high risk of inaccurate data
which would result in inaccurate outcomes that will lead to stakeholders rejecting
the system after it has been built; which implies delays and over-costs that could
have been avoided. A strong base ensures a robust project structure and
reduced chances of failures and rejections.

When to Validate?
“Requirements Validation is an ongoing process to ensure that stakeholders,
solution, and transition requirements align to the business requirements” –
BABok

We must perform validation at each and every stage during requirements

engineering. During elicitation, go back and cross-check the requirements and
the sources through which the requirements were gathered. During analysis and
negotiation, validate the final requirement document with the stakeholders to
ensure that we got the right and valid requirements. During specification, cross-
check that the requirements specified in the document match what the users
need or expect. Also, we validate that the requirements match the ideal rules and
standards.

Validation Techniques:
There are various techniques that can be used to validate the requirements. They
include:

 Checks – While checking the requirements, we proofread the requirements

documents to ensure that no elicitation notes are missed out. During these
checks, we also check the traceability level between all the requirements. For
this, the creation of a traceability matrix is required. This matrix ensures that all
the requirements are being properly considered and everything that is specified
is justified. We also check the format of requirements during these checks. We
see if the requirements are clear and well-written or not.
 Prototyping – This is a way of building a model or simulation of the system that
is to be built by the developers. This is a very popular technique for requirements
validation among stakeholders and users as it helps them to easily identify the
problems, detect missing requirements and understand how technology can help
them. We can just reach out to the users and stakeholders and get their
feedback.
 Test Design – During test designing, we follow a small procedure where the
testing team build a few testing scenarios. Tests have to be derived from the
requirements specification The aim of this process is to figure out the errors in
 the specification or the details that are missed out leading to difficulties in the
definition of the test scenarios.
 Requirements Review – During requirement review, a group of knowledgeable
people analyze the requirements in a structured and detailed manner and identify
potential problems. After that, they gather up to discuss the issues and figure out
a way to address the issues. A checklist is prepared that the reviewers fill up to
provide a formal output of the review. After that, a final approval sign-off is done.

Principles of Requirements Validation:

According to the IREB syllabus, considering the following four principles of requirements
validation increases the quality of the validation results:

Principle 1: Involvement of the correct stakeholders

Principle 2: Separating the identification and the correction of errors

Principle 3: Validation from different views

Principle 4: Repeated validation.