SOFTWARE ENGINEERING – UNIT II

System Engineering – Requirement Engineering – Requirements Documentation –

Requirement Elicitation – Requirement Analysis and Negotiation – Requirement validation –
Requirement Management

SYSTEM ENGINEERING
Software engineering occurs as a consequence of a process called system engineering.
Instead of concentrating solely on software, system engineering focuses on a variety of
elements, analyzing, designing, and organizing those elements into a system that can be a
product, a service, or a technology for the transformation of information or control.
The system engineering process is called business process engineering when the
context of the engineering work focuses on a business enterprise. When a product is to be built,
the process is called product engineering.
Both business process engineering and product engineering attempt to bring order to the
development of computer-based systems.
The overall objective of the system must be determined;
 The role of hardware, software, people, database, procedures, and other system elements
must be identified; and
 Operational requirements must be elicited, analyzed, specified, modeled, validated, and
managed.
These activities are the foundation of system engineering.

A system engineer works to understand system requirements by working with the

customer, future users, and other stakeholders.
Objectives and more detailed operational requirements are identified by eliciting
information from the customer; requirements are analyzed to assess their clarity, completeness,
and consistency; a specification, often incorporating a system model, is created and then
validated by both practitioners and customers. Finally, system requirements are managed to
ensure that changes are properly controlled.
To accomplish the goal, a computer-based system makes use of a variety of system
elements:
 Software. Computer programs, data structures, and related documentation that serve to
affect the logical method, procedure, or control that is required.
 Hardware. Electronic devices that provide computing capability, the inter-connectivity
devices (e.g., network switches, telecommunications devices) that enable the flow of
data, and electromechanical devices (e.g., sensors, motors, pumps) that provide external
world function.
 People. Users and operators of hardware and software.
  Database. A large, organized collection of information that is accessed via software.
 Documentation. Descriptive information (e.g., hardcopy manuals, on-line 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

THE SYSTEM ENGINEERING HIERARCHY

The role of the system engineer is to define the elements for a specific computer-based
system in the context of the overall hierarchy of systems. System engineering encompasses a
collection of top-down and bottom-up methods to navigate the hierarchy illustrated in Figure.
 The system engineering process usually 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.

Figure. The system engineering hierarchy

 Within a specific domain, the need for targeted system elements (e.g., 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.
 At the bottom, detailed technical activities, performed by the relevant engineering
discipline (e.g., hardware or soft-ware engineering), are conducted.

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}

SYSTEM MODELING
System engineering is a modeling process. Whether the focus is on the world view or
the detailed view, the engineer creates models that
 Define the processes that serve the needs of the view under consideration.
 Represent the behavior of the processes and the assumptions on which the behavior is
based.
 Explicitly define both exogenous and endogenous input to the model.
 Represent all linkages (including output) that will enable the engineer to better
understand the view.

REQUIREMENTS ENGINEERING

The broad spectrum of tasks and techniques that lead to an understanding of

requirements is called requirements engineering. From a software process perspective,
requirements engineering is a major software engineering action that begins during the
communication activity and continues into the modeling activity

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.
What is a requirement?
The requirements for a system are the descriptions of what the system should do—the
services that it provides and the constraints on its operation. These requirements reflect the
needs of customers for a system that serves a certain purpose such as controlling a device,
placing an order, or finding information.
The process of finding out, analyzing, documenting and checking these services and
constraints is called requirements engineering (RE).

TYPES OF REQUIREMENTS
User requirements and system requirements may be defined as follows:
 User requirements: Statements in natural language plus diagrams of the services the
system provides and its operational constraints.
What services the system is expected to provide to system users and the constraints
under which it must operate. Written for customers.
 System requirements: A structured document setting out detailed descriptions of the
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.
These are higher level than functional and non-functional requirements, which these may
subsume.
The below Figure illustrates the distinction between user and system requirements.
This example from a mental health care patient management system (MHC-PMS) shows how a
user requirement may be expanded into several system requirements. From the Figure, that the
user requirement is quite general. The system requirements provide more specific information
about the services and functions of the system that is to be implemented.
Figure shows possible readers of the user and system requirements.

 The readers of the user requirements are not usually concerned with how the system
will be implemented and may be managers who are not interested in the detailed
facilities of the system.
 The readers of the system requirements need to know more precisely what the system
will do because they are concerned with how it will support the business processes or
because they are involved in the system implementation.
Software system requirements are often classified as functional requirements or non-functional
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.

Functional Requirements
 Describe functionality or system services.

 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.

 Essentially, these are the ‘whats’ of the system that we often refer to. These are not ‘all
that there is,’ but these should describe the overall functionality of the system.
 For example, here are examples of functional requirements for the MHC-PMS system, used
to maintain information about patients receiving treatment for mental health problems:

The functional requirements specification of a system should be both complete and

consistent. Completeness means that all services required by the user should be defined.
Consistency means that requirements should not have contradictory definitions.
Non-functional Requirements
 Requirements that are not directly concerned with the specific functions delivered by
the system

 Typically relate to the system as a whole rather than the individual system features

 Often could be deciding factor on the survival of the system (e.g. reliability, cost,
response time)

 These define system properties and constraints e.g. reliability, response time,
maintainability, scalability, portability, 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.

 (Often internal to an organization or required for fit / compatibility with other

comparable systems.)

 Non-functional requirements may be more critical than functional requirements. If

these are not met, the system may be useless.

Requirement Engineering Process

Requirement Engineering Process includes the following activities -

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:

nners
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.

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.
o Data Dictionaries: Data Dictionaries are simply repositories to store information about
all data items defined in DFDs.
o Entity-Relationship Diagrams: 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 -

5.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 elicitation

Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really need.
Requirements elicitation Activities:
Requirements elicitation includes the subsequent activities. Few of them are listed below –

 Knowledge of the overall area where the systems is applied.

 The details of the precise customer problem where the system are going to be applied
must be understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.

Requirements elicitation Methods:

There are a number of requirements elicitation methods. Few of them are listed below –
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.
1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations from the
software.
It is impossible to interview every stakeholder hence representatives from groups are selected
based on their expertise and credibility.
Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free questions may be asked
to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.

2. Brainstorming Sessions:
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their
priority if possible.

3. Facilitated Application Specification Technique:

It’s objective is to bridge the expectation gap – difference between what the developers think
they are supposed to build and what customers think they are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally
a draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer.
3 types of requirements are identified –
 Normal requirements –
In this the objective and goals of the proposed software are discussed with the customer.
Example – normal requirements for a result management system may be entry of marks,
calculation of results, etc
 Expected requirements –
These requirements are so obvious that the customer need not explicitly state them.
Example – protection from unauthorized access.
 Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very
satisfying when present. Example – when unauthorized access is detected, it should
backup and shutdown all processes.
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

5. Use Case Approach:

This technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system.
The components of the use case design includes three major things – Actor, Use cases, use
case diagram.
1. Actor –
It is the external agent that lies outside the system but interacts with it in some way. An
actor maybe a person, machine etc. It is represented as a stick figure. Actors can be
primary actors or secondary actors.
 Primary actors – It requires assistance from the system to achieve a goal.
 Secondary actor – It is an actor from which the system needs assistance.
2. Use cases –
They describe the sequence of interactions between actors and the system. They capture
who(actors) do what(interaction) with the system. A complete set of use cases specifies
all possible ways to use the system.
3. Use case diagram –
A use case diagram graphically represents what happens when an actor interacts with a
system. It captures the functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.

Requirements Analysis

Requirement analysis is significant and essential activity after elicitation. We analyze, refine,
and scrutinize the gathered requirements to make consistent and unambiguous requirements.
This activity reviews all requirements and may provide a graphical view of the entire system.
After the completion of the analysis, it is expected that the understandability of the project may
improve significantly. Here, we may also use the interaction with the customer to clarify points
of confusion and to understand which requirements are more important than others.

As the requirements analysis activity commences, the following questions are asked
and answered:
• Is each requirement consistent with the overall objective for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do some
requirements provide a level of technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not be
essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or
product?
• Is each requirement testable, once implemented?

The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that defines the
boundaries and interfaces of the proposed systems with the external world. It identifies the
entities outside the proposed system that interact with the system. The context diagram of
student result management system is given below:

(ii) Development of a Prototype (optional): One effective way to find out what the customer
wants is to construct a prototype, something that looks and preferably acts as part of the system
they say they want.

We can use their feedback to modify the prototype until the customer is satisfied continuously.
Hence, the prototype helps the client to visualize the proposed system and increase the
understanding of the requirements. When developers and users are not sure about some of the
elements, a prototype may help both the parties to take a final decision.
Some projects are developed for the general market. In such cases, the prototype should be
shown to some representative sample of the population of potential purchasers. Even though a
person who tries out a prototype may not buy the final system, but their feedback may allow us
to make the product more attractive to others.

The prototype should be built quickly and at a relatively low cost. Hence it will always have
limitations and would not be acceptable in the final system. This is an optional activity.

(iii) Model the requirements: This process usually consists of various graphical
representations of the functions, data entities, external entities, and the relationships between
them. The graphical view may help to find incorrect, inconsistent, missing, and superfluous
requirements. Such models include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries, State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will have a better
understanding of the system behavior. The inconsistencies and ambiguities have been
identified and corrected. The flow of data amongst various modules has been analyzed.
Elicitation and analyze activities have provided better insight into the system. Now we finalize
the analyzed requirements, and the next step is to document these requirements in a prescribed
format.

Software requirement means requirement that is needed by software to increase quality

of software product. These requirements are generally a type of expectation of user from
software product that is important and need to be fulfilled by software. Analysis means to
examine something in an organized and specific manner to know complete details about it.
Therefore, Software requirement analysis simply means complete study, analyzing,
describing software requirements so that requirements that are genuine and needed can be
fulfilled to solve problem. There are several activities involved in analyzing Software
requirements. Some of them are given below :
1. Problem Recognition:
The main aim of requirement analysis is to fully understand main objective of
requirement that includes why it is needed, does it add value to product, will it be
beneficial, does it increase quality of the project, does it will have any other effect. All
these points are fully recognized in problem recognition so that requirements that are
essential can be fulfilled to solve business problems.

2. Evaluation and Synthesis :

Evaluation means judgement about something whether it is worth or not and synthesis
means to create or form something. Here are some tasks are given that is important in the
evaluation and synthesis of software requirement :
 To define all functions of software that necessary.
 To define all data objects that are present externally and are easily observable.
 To evaluate that flow of data is worth or not.
 To fully understand overall behavior of system that means overall working of system.
 To identify and discover constraints that are designed.
 To define and establish character of system interface to fully understand how system
interacts with two or more components or with one another.

3. Modeling :
After complete gathering of information from above tasks, functional and behavioral
models are established after checking function and behavior of system using a domain
model that also known as the conceptual model.

4. Specification :
The software requirement specification (SRS) which means to specify the requirement
 whether it is functional or non-functional should be developed.

5. Review :
After developing the SRS, it must be reviewed to check whether it can be improved or not
and must be refined to make it better and increas

REQUIREMENT DOCUMENTATION
software requirements document (also known as software requirements specifications) is a
document that describes the intended use-case, features, and challenges of a software
application.
SRS is a formal report, which acts as a representation of software that enables the customers to
review whether it (SRS) is according to their requirements. Also, it comprises user
requirements for a system as well as detailed specifications of the system requirements.
considered to form a structure of good SRS. These are as follows :
1. Introduction
 (i) Purpose of this document
 (ii) Scope of this document
 (iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
Software Requirement Specification (SRS) Format as name suggests, is complete
specification and description of requirements of software that needs to be fulfilled for
successful development of software system. These requirements can be functional as well as
non-functional depending upon type of requirement. The interaction between different
customers and contractor is done because its necessary to fully understand needs of
customers.
Depending upon information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is needed to be
done to increase quality of product and to satisfy customer’s demand.
1. Introduction :
 (i) Purpose of this Document –
At first, main aim of why this document is necessary and what’s purpose of document
is explained and described.
 (ii) Scope of this document –
In this, overall working and main objective of document and what value it will
provide to customer is described and explained. It also includes a description of
development cost and time required.
 (iii) Overview –
In this, description of product is explained. It’s simply summary or overall review of
product.

2. General description :
In this, general functions of product which includes objective of user, a user
characteristic, features, benefits, about why its importance is mentioned. It also describes
features of user community.

3. Functional Requirements :
In this, possible outcome of software system which includes effects due to operation of
program is fully explained. All functional requirements which may include calculations,
data processing, etc. are placed in a ranked order.

4. Interface Requirements :
In this, software interfaces which mean how software program communicates with each
other or users either in form of any language, code, or message are fully described and
explained. Examples can be shared memory, data streams, etc.
5. Performance Requirements :
In this, how a software system performs desired functions under specific condition is
explained. It also explains required time, required memory, maximum error rate, etc.

6. Design Constraints :
In this, constraints which simply means limitation or restriction are specified and
explained for design team. Examples may include use of a particular algorithm, hardware
and software limitations, etc.

7. Non-Functional Attributes :
In this, non-functional attributes are explained that are required by software system for
better performance. An example may include Security, Portability, Reliability,
Reusability, Application compatibility, Data integrity, Scalability capacity, etc.

8. Preliminary Schedule and Budget :

In this, initial version and budget of project plan are explained which include overall time
duration required and overall cost required for development of project.

9. Appendices:
In this, additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.

Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS.
SRS is said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all
available categories of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of
all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the SRS:
(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but in
another as textual.

(b) One condition may state that all lights shall be green while another states that all lights shall
be blue.

(2). There may be a reasonable or temporal conflict between the two specified actions. For
example,

(a) One requirement may determine that the program will add two inputs, and another may
determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A and
B" co-occurs.

(3). Two or more requirements may define the same real-world object but use different terms
for that object. For example, a program's request for user input may be called a "prompt" in one
requirement's and a "cue" in another. The use of standard terminology and descriptions
promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a method
used with multiple definitions, the requirements report should determine the implications in the
SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if
each requirement in it has an identifier to indicate either the significance or stability of that
particular requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential,
especially for life-critical applications, while others may be desirable. Each element should be
identified to make these differences clear and explicit. Another way to rank requirements is to
distinguish classes of items as essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly
obtain changes to the system to some extent. Modifications should be perfectly indexed and
cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement
documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its
source in earlier documents.

2. Forward Traceability: This depends upon each element in the SRS having a unique name
or reference number.

The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to
be able to ascertain the complete set of requirements that may be concerned by those
modifications.

9. Design Independence: There should be an option to select from multiple design alternatives
for the final system. More specifically, the SRS should not contain any implementation details.

10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit
domain but might not be trained in computer science. Hence, the purpose of formal notations
and symbols should be avoided too as much extent as possible. The language should be kept
simple and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the details
should be explained explicitly. Whereas,for a feasibility study, fewer analysis can be used.
Hence, the level of abstraction modifies according to the objective of the SRS.

Requirements Validation
The work products produced as a consequence of requirements engineering (a system
specification and related information) are assessed for quality during a validation step.
Requirements validation examines the specification to ensure that all system
requirements have been stated unambiguously; that inconsistencies, omissions, and errors have
been detected and corrected; and that the work products conform to the standards established
for the process, the project, and the product.
During the requirements validation process, different types of checks should be carried
out on the requirements in the requirements document. These checks include:
 1. Validity checks A user may think that a system is needed to perform certain
functions. However, further thought and analysis may identify additional or different functions
that are required. Systems have diverse stakeholders with different needs and any set of
requirements is inevitably a compromise across the stake-holder community.
2. Consistency checks Requirements in the document should not conflict. That is, there
should not be contradictory constraints or different descriptions of the same system function.
3. Completeness checks The requirements document should include requirements that
define all functions and the constraints intended by the system user.
4. Realism checks Using knowledge of existing technology, the requirements
should be checked to ensure that they can actually be implemented. These checks should also
take account of the budget and schedule for the system development.
5. Verifiability To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable. This means that you should
be able to write a set of tests that can demonstrate that the delivered system meets each
specified requirement.
The output of requirements validation is the list of problems and agreed on actions of
detected problems. The lists of problems indicate the problem detected during the process of
requirement validation. The list of agreed action states the corrective action that should be
taken to fix the detected problem.

The primary requirements validation mechanism is the formal technical review. The
review team includes system engineers, customers, users, and other stakeholders who
examine the system 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), con-flicting requirements, or unrealistic
(unachievable) requirements.
There are a number of requirements validation techniques that can be used
individually or in conjunction with one another:
1. Requirements reviews The requirements are analyzed systematically by a team of
reviewers who check for errors and inconsistencies.
2. Prototyping In this approach to validation, an executable model of the system in
question is demonstrated to end-users and customers. They can experiment with this
model to see if it meets their real needs. This type of model is generally used to collect
feedback about the requirement of the user.

3. Test-case generation
Requirements should be testable. If the tests for the requirements are devised as
part of the validation process, this often reveals requirements problems. If a test is
difficult or impossible to design, this usually means that the requirements will be
 difficult to implement and should be reconsidered. Developing tests from the user
requirements before any code is written is an integral part of extreme programming.

4. Automated Consistency Analysis:

This approach is used for automatic detection of an error, such as nondeterminism,
missing cases, a type error, and circular definitions, in requirements specifications.
First, the requirement is structured in formal notation then CASE tool is used to check
in-consistency of the system, The report of all inconsistencies is identified and
corrective actions are taken.
5. Walk-through:
A walkthrough does not have a formally defined procedure and does not require a
differentiated role assignment.
a. Checking early whether the idea is feasible or not.
b. Obtaining the opinions and suggestion of other people.
c. Checking the approval of others and reaching an agreement.

Requirements management
Requirements for computer-based systems change and that the desire to change
requirements persists throughout the life of the system. 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. During the software process, the stake-holders’
understanding of the problem is constantly changing. The system requirements must then also
evolve to reflect this changed problem view. Requirements management is the process of
understanding and controlling
changes to system requirements. Let’s keep track of individual requirements and maintain links
between dependent requirements so that can assess the impact of requirements changes.
Requirements management planning
Planning is an essential first stage in the requirements management process. The planning stage
establishes the level of requirements management detail that is required. During the
requirements management stage, you have to decide on:
1. Requirements identification Each requirement must be uniquely identified so that it can be
cross-referenced with other requirements and used in traceability assessments.
2. A change management process This is the set of activities that assess the impact and cost
of changes.
3. Traceability policies These policies define the relationships between each requirement and
between the requirements and the system design that should be recorded. The traceability
policy should also define how these records should be maintained.
4. Tool support Requirements management involves the processing of large amounts of
information about the requirements. Tools that may be used range from specialist requirements
management systems to spreadsheets and simple database systems.
Requirements management needs automated support and the software tools for this should be
chosen during the planning phase. Need tool support for:
1. Requirements storage - The requirements should be maintained in a secure, managed data
store that is accessible to everyone involved in the requirements engineering process.
2. Change management - The process of change management is simplified if active tool
support is available.
3. Traceability management - tool support for traceability allows related requirements to be
discovered. Some tools are available which Requirements change management.

Requirements change management

Requirements change management should be applied to all proposed changes to a
system’s requirements after the requirements document has been approved.

There are three principal stages to a change management process:

1. Problem analysis and change specification The process starts with an identified
requirements problem or, sometimes, with a specific change proposal. During this stage, the
problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to
the change requestor who may respond with a more specific requirements change proposal, or
decide to withdraw the request.
2. Change analysis and costing The effect of the proposed change is assessed using
traceability information and general knowledge of the system requirements. The cost of making
the change is estimated both in terms of modifications to the requirements document and, if
appropriate, to the system design and implementation. Once this analysis is completed, a
decision is made whether or not to proceed with the requirements change.
3. Change implementation The requirements document and, where necessary, the system
design and implementation, are modified. You should organize the requirements document so
that you can make changes to it without extensive rewriting or reorganization. As with
programs, changeability in documents is achieved by minimizing external references and
making the document sections as modular as possible. Thus, individual sections can be
changed and replaced
without affecting other parts of the document.

If a new requirement has to be urgently implemented, there is always a temptation to change

the system and then retrospectively modify the requirements document. You should try to
avoid this as it almost inevitably leads to the requirements specification and the system
implementation getting out of step. Once system changes have been made, it is easy to forget to
include these changes in the requirements document or to add information to the requirements
document that is inconsistent with the implementation.
Use natural language processing techniques to help discover possible relation-ships between
requirements.