MODULE 2

Requirement
The description of the features and functionalities of the target system is
called requirements. The expectations of users from the software product are communicated
through requirements.
IEEE defines a requirement as follows:

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
documents.
3. A documented representation of a condition or capability as in 1 and 2.

Two kinds of requirements based on the intended purpose and target audience:

User requirements
High-level abstract requirements written as statements, in a natural language plus
diagrams, of what services the system is expected to provide to system users and
the constraints under which it must operate.
System requirements
Detailed description of what the system should do including the software
system's functions, services, and operational constraints. The system
requirements document (sometimes called a functional specification) should
define exactly what is to be implemented. It may be part of the contract between
the system buyer and the software developers.

Three classes of requirements:

Functional requirements
Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations. May
state what the system should not do.
Non-functional requirements
Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc. Often apply
to the system as a whole rather than individual features or services.
Domain requirements
Constraints on the system derived from the domain of operation.
Functional requirements

Functional requirements describe functionality or system services. They depend on the

type of software, expected users and the type of system where the software is used.

 Functional user requirements may be high-level statements of what the system

should do.
 Functional system requirements should describe the system services in detail.

Problems arise when requirements are not precisely stated. Ambiguous requirements
may be interpreted in different ways by developers and users. In principle, requirements
should be both

 Complete: they should include descriptions of all facilities required, and

 Consistent: there should be no conflicts or contradictions in the descriptions of the
system facilities.

In practice, it is impossible to produce a complete and consistent requirements

document.

Non-functional requirements

Non-functional requirements define system properties and constraints e.g. reliability,

response time and storage requirements. Constraints are I/O device capability, system
representations, etc. Process requirements may also be specified mandating a particular
IDE, programming language or development method. Non-functional requirements may
be more critical than functional requirements. If these are not met, the system may be
useless.

Non-functional requirements may affect the overall architecture of a system rather than
the individual components. A single non-functional requirement, such as a security
requirement, may generate a number of related functional requirements that define
system services that are required. It may also generate requirements that restrict existing
requirements.
Three classes of non-functional requirements:

Product requirements
Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
Organizational requirements
Requirements which are a consequence of organizational policies and procedures
e.g. process standards used, implementation requirements, etc.
External requirements
Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc.

Non-functional requirements may be very difficult to state precisely and imprecise

requirements may be difficult to verify. If they are stated as a goal (a general intention
of the user such as ease of use), they should be rewritten as a verifiable non-functional
requirement (a statement using some quantifiable metric that can be objectively tested).
Goals are helpful to developers as they convey the intentions of the system users.

Domain requirements
The system's operational domain imposes requirements on the system. Domain
requirements may be new functional or non-functional requirements, constraints on
existing requirements, or define specific computations. If domain requirements are not
satisfied, the system may be unworkable. Two main problems with domain
requirements:

Understandability
Requirements are expressed in the language of the application domain, which is
not always understood by software engineers developing the system.
Implicitness
Domain specialists understand the area so well that they do not think of making
the domain requirements explicit.

Requirement Engineering

Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process. Requirement engineering
provides the appropriate mechanism to understand what the customer desires, analyzing
the need, and assessing feasibility, negotiating a reasonable solution, specifying the
solution clearly, validating the specifications and managing the requirements as they are
transformed into a working system. Thus, requirement engineering is the disciplined
application of proven principles, methods, tools, and notation to describe a proposed
system's intended behavior and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing the
software that is acceptable to users, flexible to change and conformable to established
standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies,

which are needed to accomplish customer requirements within the time and
budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and
customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary
software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified
with the help of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are
analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in
terms of relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software

analyst after the requirements collected from the various sources - the requirement
received by the customer written in ordinary language. It is the job of the analyst to
write the requirement in technical language so that they can be understood and
beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs),
function decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for
modeling the requirements. DFD shows the flow of data through a system. The
system may be a company, an organization, a set of procedures, a computer
hardware system, a software system, or any combination of the preceding. The
DFD is also known as a data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements stage, the
data dictionary should at least define customer data items, to ensure that the
customer and developers use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is
the entity-relationship diagram, often called an "E-R diagram." It is a detailed
logical representation of the data for the organization and uses three main
constructs i.e. data entities, relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document

are validated. The user might demand illegal, impossible solution or experts may
misinterpret the needs. Requirements can be the check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the

requirements.
o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
 o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the

requirements engineering process and system development.

New requirements emerge during the process as business needs a change, and a better
understanding of the system is developed.

The priority of requirements from different viewpoints changes during development

process.

The business and technical environment of the system changes during the development.

Requirements Engineering Activities

Requirements engineering refers to the broad range of tasks and techniques that lead to
an understanding of requirements. It is a major software engineering activity that
begins during the communication activity and continues into the modelling activity. It
bridges the gap between design and construction.
Requirements engineering provide,

 Understanding what the customer wants.

 Analysing requirements.

 Assessing feasibility.

 Negotiating a reasonable solution.

 Specifying the solution unambiguously.

 Validating the specification.

It consists of seven distinct tasks: elicitation, elaboration, negotiation, specification,

validation, and management.

a) Inception. In general, most projects begin when a business need is identified or a

potential new market or service is discovered. Stakeholders from the business
community define a business case for the idea, try to identify the breadth and depth of
the market, do a rough feasibility analysis, and identify a working description of the
project’s scope.
At project inception, you establish a basic understanding of the problem, the people
who want a solution, the nature of the solution that is desired, and the effectiveness of
preliminary communication and collaboration between the other stakeholders and the
software team.
b) Elicitation. Ask the customer, what the objectives for the system or product are,
what is to be accomplished, how the system or product fits into the needs of the
business, and finally, how the system or product is to be used on a day-to-day basis. A
number of problems that are encountered as elicitation occurs.
• Problems of scope. The boundary of the system is ill-defined or the customers/users
specify unnecessary technical detail that may confuse, rather thanclarify, 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, omit information that is
believed to be “obvious,” specify requirements thatconflict with the needs of other
customers/users, or specify requirements that are ambiguous or un testable.
• Problems of volatility. The requirements change over time. To help overcome
theseproblems, you must approach requirements gathering in an organized manner.
c) Elaboration. The information obtained from the customer during inception
and elicitation isexpanded and refined during elaboration. This task focuses on
developing refined requirements model that identifies various aspects of
software function, behaviour, and information.
Elaboration is driven by the creation and refinement of user scenarios that describe
how the end user (and other actors) will interact with the system. Each user scenario is
parsed to extractanalysis classes—business domain entities that are visible to the end
user. The attributes of each analysis class are defined, and the services that are
required by each class are identified. The relationships and collaboration between
classes are identified, and a variety of supplementarydiagrams are produced.
d) Negotiation.
It’s fairly common for different customers or users to propose competing requirements,
claiming that their version is “essential for our special needs.”
You must resolve these conflicts through a negotiating process. Customers, users, and
other stakeholders are asked to rank requirements and then discuss any conflicts in
priority. Using an iterative approach that prioritises requirements, assesses their cost and
risk, and addresses internal conflicts, requirements are eliminated, combined, and/or
modified so that each party achieves some level of satisfaction.

e) Specification.

To different people, specification means different things. A specification can be

a written document, a collection of graphical models, a formal mathematical model, a
set of usage scenarios, a prototype, or any combination of these. Some argue that a
“standard template” for a specification should be developed and used, arguing that this
results in requirements that are presented in a consistent and thus more understandable
manner.

f) Validation.
After requirement specifications developed, the requirements discussed in this document
are validated.

g) Requirements Management.

Requirement management is the process of managing changing requirements during the

requirements engineering process and system development.

However, when developing a specification, it is sometimes necessary to remain flexible.

A written document combining natural language descriptions and graphical models may
be the best approach for large systems.

2.2 ESTABLISHING THE GROUNDWORK

In an ideal setting, stakeholders and software engineers work together on the same
team. In such cases, requirements engineering is simply a matter of conducting
meaningful conversations with colleagues who are well-known members of the team.
We discuss the steps required to establish the groundwork for an understanding
ofsoftware requirements—to get the project started in a way that will keep it moving
forward toward a successful solution.

2.2.1 Identifying Stakeholders: Stakeholder is “anyone who benefits in a direct

orindirect way from the system which is being developed.” The usual stakeholders
are: business operations managers, product managers, marketing people, internal and
external customers, end users,consultants, product engineers, software engineers,
support and maintenance engineers. Each stakeholder has a different view of the
system, achieves different benefits when the system is successfully developed, and is
open to different risks if the development effort should fail.

2.2.2 Recognizing Multiple Viewpoints: Because many different stakeholders exist,

the requirements of the system will be explored from many different pointsof view.
Each of these constituencies will contribute information to the requirements
engineering process. As information from multiple viewpoints is collected, emerging
requirements may be inconsistent or may conflict with one another. You should
categorize all stakeholder information in a way that will allow decision makers to
choose an internally consistent set of requirements for the system.

2.2.3 Working toward Collaboration: If five stakeholders are involved in a software

project, you may have five different opinions about the proper set of requirements.
Customers must collaborate among themselves and with software engineering
practitioners if a successful system is to result. The job of a requirements engineer is
to identify areas of commonality and areas of conflict or inconsistency. Collaboration
does not necessarily mean that requirements are defined by committee. In many cases,
stakeholders collaborate by providing their view of requirements, but a strong “project
champion” may make the final decision about which requirements make the cut.

2.2.4 Asking the First Questions: Questions asked at the inception of the project
should be “context free. The first set of context-free questions focuses on the
customer and other stakeholders, the overall project goals and benefits. You might
ask:

• Who is behind the request for this work?

• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
These questions help to identify all stakeholders who will have interest in the software
to be built. In addition, the questions identify the measurable benefit of a successful
implementation and possible alternatives to custom software development.

The next set of questions enables you to gain a better understanding of the problem
and allows the customer to voice his or her perceptions about a solution:
• How would you characterize “good” output that would be generated by a
successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution
will be used?
• Will special performance issues or constraints affect the way the solution is
approached?

The final set of questions focuses on the effectiveness of the communication activity
itself.
• Are you the right person to answer these questions? Are your answers “official”?