Requirements Engineering

Phases of Requirement Engineering

1. Feasibility Study
2. Requirements Elicitation
3. Requirements Specification
4. Requirements Validation
5. Requirements Management

1. Feasibility Study: Assessing the viability of the project.

The feasibility study mainly concentrates on below five mentioned areas below.
Among these Economic Feasibility Study is the most important part of the feasibility
analysis and the Legal Feasibility Study is less considered feasibility analysis.
1.1 Technical Feasibility: In Technical Feasibility current resources both hardware
software along required technology are analyzed/assessed to develop the project. This
technical feasibility study reports whether there are correct required resources and
technologies that will be used for project development. Along with this, the feasibility
study also analyzes the technical skills and capabilities of the technical team, whether
existing technology can be used or not, whether maintenance and up-gradation are
easy or not for the chosen technology, etc.
1.2 Operational Feasibility: In Operational Feasibility degree of providing service to
requirements is analyzed along with how easy the product will be to operate and
maintain after deployment. Along with this other operational scopes are determining
the usability of the product, Determining suggested solution by the software
development team is acceptable or not, etc.
1.3 Economic Feasibility: In the Economic Feasibility study cost and benefit of the
project are analyzed. This means under this feasibility study a detailed analysis is
carried out will be cost of the project for development which includes all required
costs for final development hardware and software resources required, design and
development costs operational costs, and so on. After that, it is analyzed whether the
project will be beneficial in terms of finance for the organization or not.
1.4 Legal Feasibility: In legal feasibility, the project is ensured to comply with all
relevant laws, regulations, and standards. It identifies any legal constraints that could
impact the project and reviews existing contracts and agreements to assess their effect
on the project’s execution. Additionally, legal feasibility considers issues related to
intellectual property, such as patents and copyrights, to safeguard the project’s
innovation and originality.
1.5 Schedule Feasibility: In schedule feasibility, the project timeline is evaluated to
determine if it is realistic and achievable. Significant milestones are identified, and
deadlines are established to track progress effectively. Resource availability is
assessed to ensure that the necessary resources are accessible to meet the project
schedule. Furthermore, any time constraints that might affect project delivery are
considered to ensure timely completion. This focus on schedule feasibility is crucial
for the successful planning and execution of a project.

2. Requirements Elicitation and Analysis: Gathering knowledge about the project

domain and requirements.
It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business
manuals, the existing software of the same type, standards, and other stakeholders of
the project.
Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system. This is the first step in the
requirements engineering process and it is critical to the success of the software
development project. The goal of this step is to understand the problem that the
software system is intended to solve and the needs and expectations of the
stakeholders who will use the system.
Stakeholders range from end-users of a system through managers to external
stakeholders such as regulators, who certify the acceptability of the system. For
example, system stakeholders for the mental healthcare patient information system
include:
1. Patients whose information is recorded in the system.
2. Doctors who are responsible for assessing and treating patients.
3. Nurses who coordinate the consultations with doctors and administer some
treatments.
4. Medical receptionists who manage patients’ appointments.
5. IT staff who are responsible for installing and maintaining the system.
 6. A medical ethics manager who must ensure that the system meets current ethical
guidelines for patient care.
7. Healthcare managers who obtain management information from the system.
8. Medical records staff who are responsible for ensuring that system information
can be maintained and preserved, and that record keeping procedures have been
properly implemented.
3. Requirements Specification: Producing formal software requirement models.
This activity is used to produce formal software requirement models. All the
requirements including the functional as well as the non-functional requirements and
the constraints are specified by these models in totality. During specification, more
knowledge about the problem may be required which can again trigger the elicitation
process. The models used at this stage include ER diagrams, data flow
diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.
Once the requirements are specified, they must be reviewed and validated by the
stakeholders and development team to ensure that they are complete, consistent, and
accurate.
4. Requirements Validation: Ensuring the requirements are accurate and complete.
Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has
been built is traceable to customer requirements. If requirements are not validated,
errors in the requirement definitions would propagate to the successive stages
resulting in a lot of modification and rework.

Verification is checking that the requirements are complete, consistent, and accurate.
It involves reviewing the requirements to ensure that they are clear, testable, and free
of errors and inconsistencies. This can include reviewing the requirements document,
models, and diagrams, and holding meetings and walkthroughs with stakeholders.
Validation is the process of checking that the requirements meet the needs and
expectations of the stakeholders. It involves testing the requirements to ensure that
they are valid and that the software system being developed will meet the needs of the
stakeholders. This can include testing the software system through simulation, testing
with prototypes, and testing with the final version of the software.
5. Requirements Management: Handling changes and closing the requirement phase.
Requirement management is the process of analyzing, documenting, tracking,
prioritizing, and agreeing on the requirement and controlling the communication with
relevant stakeholders. This stage takes care of the changing nature of requirements. It
should be ensured that the SRS is as modifiable as possible to incorporate changes in
requirements specified by the end users at later stages too. Modifying the software as
per requirements in a systematic and controlled manner is an extremely important part
of the requirements engineering process.

Requirements management is the process of managing the requirements throughout

the software development life cycle, including tracking and controlling changes, and
 ensuring that the requirements are still valid and relevant. The goal of requirements
management is to ensure that the software system being developed meets the needs
and expectations of the stakeholders and that it is developed on time, within budget,
and to the required quality.

Types of Requirements

1. Functional Requirements:
o Definition: Specify what the system should do. They describe the interactions
between the system and its environment, independent of the implementation.
o The functional requirements for a system describe what the system should
do. These requirements depend on the type of software being developed, the
expected users of the software, and the general approach taken by the
organization when writing requirements.
o When expressed as user requirements, functional requirements are usually
described in an abstract way that can be understood by system users.
However, more specific functional system requirements describe the system
functions, its inputs and outputs, exceptions, etc., in detail.
o Functional system requirements vary from general requirements covering what
the system should do to very specific requirements reflecting local ways of
working
or an organization’s existing systems.
o Examples: User login process, data processing logic, and report generation
capabilities.
2. Non-Functional Requirements:
o Definition: Outline the quality attributes or constraints the system must
exhibit. They are not about specific behaviours but how the system performs
under certain conditions or constraints.
 o These are basically the quality constraints that the system must satisfy
according to the project contract. Nonfunctional requirements, not related to
the system functionality, rather define how the system should perform The
priority or extent to which these factors are implemented varies from one
project to other. They are also called non-behavioral requirements. They
basically deal with issues like:
o Portability
o Security
o Maintainability
o Reliability
o Scalability
o Performance
o Reusability
o Flexibility

o Examples: Performance metrics (response time, throughput), security

standards, usability, scalability, and compatibility.

3. Domain Requirements:
Definition: Domain requirements are specific to the domain or industry in which the
software operates. They include terminology, rules, and standards relevant to that
particular domain.
Domain requirements reflect the unique needs and constraints of a particular industry.
They ensure that the software is relevant and compliant with industry-specific regulations
and standards.

Examples:
● Healthcare: The software must comply with HIPAA regulations for handling patient
data.
● Finance: The system should adhere to GAAP standards for financial reporting.
● E-commerce: The software should support various payment gateways like PayPal,
Stripe, and credit cards.
Classifications of Software Requirements
Other common classifications of software requirements can be:
System Requirements:
o Definition: Detailed specifications describing the software system’s functions,
features, and constraints. These can be further divided into software and
hardware requirements.
o are more detailed descriptions of the software system’s functions, services, and
operational constraints.
o 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.
o Examples: Hardware specifications (CPU, memory, disk space), software
dependencies (operating systems, middleware), system integrations, and
system behaviors.
User Requirements:
o Definition: Express the needs and desires of the end-users in terms of tasks
they need to perform with the system, often documented in natural language or
through use cases.
o User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide to system users.
o User requirements define the results and qualities the user wants.
o A user requirement concerned with security, such as a statement limiting
access to authorized users, may appear to be a nonfunctional requirement.
o Examples: Ability to export data into various formats, user-friendly interfaces
for on-technical users, and custom notification settings.
 SRS(Software Requirement Specification)
SRS Template:

Characteristics of a good SRS document:

1. Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS
is said to be correct if it covers all the requirements that are actually expected from the
system.

2. Completeness:
Completeness of SRS indicates every sense of completion including the numbering of
all the pages, resolving the to be determined parts to as much extent as possible as
well as covering all the functional and non-functional requirements properly.

3. Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any set
of requirements. Examples of conflict include differences in terminologies used at
separate places, logical conflicts like time period of report generation, etc.

4. Unambiguousness:
A SRS is said to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the use of
modelling techniques like ER diagrams, proper reviews and buddy checks, etc.

5. Ranking for importance and stability:

There should a criterion to classify the requirements as less or more important or more
specifically as desirable or essential. An identifier mark can be used with every
requirement to indicate its rank or stability.

6. Modifiability:
SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent. Modifications should be properly
indexed and cross-referenced.
7. Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably measure the
extent to which every requirement is met by the system. For example, a requirement
starting that the system must be user-friendly is not verifiable and listing such
requirements should be avoided.

8. Traceability:
One should be able to trace a requirement to design component and then to code
segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.

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

10. Testability:
A SRS should be written in such a way that it is easy to generate test cases and test
plans from the document.

11. Understandable by the customer:

An end user maybe an expert in his/her specific domain but might not be an expert in
computer science. Hence, the use of formal notations and symbols should be avoided
to as much extent as possible. The language should be kept easy and clear.

12. Right level of abstraction:

If the SRS is written for the requirements phase, the details should be explained
explicitly. Whereas, for a feasibility study, fewer details can be used. Hence, the level
of abstraction varies according to the purpose of the SRS.

Requirement Elicitation Techniques

1. Brainstorming
Brainstorming, as a requirements elicitation technique, embodies a dynamic group
activity focused on generating a wide array of ideas, solutions, and requirements for a
project.
This technique is especially valuable in the initial phases of a project, where the goal
is to explore various possibilities and identify innovative solutions without the
constraints of criticism or feasibility considerations.
2. Interviewing
 Formal or informal interviews with system stakeholders are part of most requirements
engineering processes. In these interviews, the requirements engineering team puts
questions to stakeholders about the system that they currently use and the system to be
developed. Requirements are derived from the answers to these questions.

Interviews may be of two types:

1. Closed interviews, where the stakeholder answers a pre-defined set of questions.

2. Open interviews, in which there is no pre-defined agenda. The requirements

engineering team explores a range of issues with system stakeholders and hence
develop a better understanding of their needs.
3. Surveys/Questionnaires
Surveys and questionnaires stand as highly scalable and efficient techniques for
requirement elicitation, enabling data collection from a broad audience in a relatively
short period of time.
This method is particularly useful when the project stakeholders are numerous or
geographically dispersed, and there’s a need to gather a wide range of opinions,
preferences, and requirements for the system under development.
4. Prototyping
Prototyping is a dynamic and interactive requirements elicitation technique that
involves creating preliminary versions of a software system to explore ideas, uncover
requirements, and gather feedback from users and stakeholders.
This approach allows for a tangible exploration of the system’s functionality and
design before developing the full system.
5. Scenarios
a scenario may include:
1. A description of what the system and users expects when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the same time.
5. A description of the system state when the scenario finishes.
6. Use Cases
Use Case 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 include three major things – Actor, use cases,
and use case diagram.
1. Actor: It is the external agent that lies outside the system but interacts with it in some
way. An actor may be 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.
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.

Example: Use case diagram of Medical Health Care

7. Ethnography
Ethnography comes from anthropology, literally means "writing the culture"
• Essentially seeks to explore the human factors and social organization of activities
understand work.
• Studies have shown that work is often richer and more complex than is suggested by
simple models derived from interviews
• Social scientists are trained in observation and work analysis
• Discoveries are made by observation and analysis, workers are not asked to explain
what they do
• Collect what is ordinary/what is it that people do (aim at making the implicit
explicit)
• Study the context of work and watch work being done

Data Flow Diagram

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data
through an information system.
• It is common practice to draw a System Context Diagram first which shows the
interaction between the system and outside entities.
• The DFD is designed to show how a system is divided into smaller portions and to
highlight the flow of data between those parts.
• Level 0 DFD i.e. Context level DFD should depict the system as a single.
• Primary input and primary output should be carefully identified.
•Information flow from continuity must be maintained from level to level.
DFD four Symbols:
 Types of DFD:
1) Logical DFD
It illustrates how data flows in the system
- What system should do
2) Physical DFD
Physical data flow diagram shows how the data flow is actually implemented in the
system.
- How system should work
Rules for creating Data Flow Diagrams (DFD) include the following.
● Data cannot flow directly between two entities.
● Data flow must be from entity to a process or a process to an entity.
● There can be multiple data flows between one entity and a process.
● Each process should have at least one input and one output.
● Each data store should have at least one data flow in and one data flow out.
Levels of Data Flow Diagram (DFD)
Data Flow Diagram (DFD) uses hierarchy to maintain transparency thus multilevel Data
Flow Diagram (DFD’s) can be created. Levels of Data Flow Diagram (DFD) are as follows:
1. 0-level DFD
It is also known as a context diagram. It’s designed to be an abstraction view, showing the
system as a single process with its relationship to external entities. It represents the entire
system as a single bubble with input and output data indicated by incoming/outgoing arrows.
2. 1-Level DFD
This level provides a more detailed view of the system by breaking down the major processes
identified in the level 0 DFD into sub-processes. Each sub-process is depicted as a separate
process on the level 1 DFD. The data flows and data stores associated with each sub-process
are also shown. In 1-level DFD, the context diagram is decomposed into multiple
bubbles/processes. In this level, we highlight the main functions of the system and
breakdown the high-level process of 0-level DFD into subprocesses.
3. 2-level DFD
This level provides an even more detailed view of the system by breaking down the
sub-processes identified in the level 1 DFD into further sub-processes. Each sub-process is
depicted as a separate process on the level 2 DFD. The data flows and data stores associated
with each sub-process are also shown.

Data Dictionary
A data dictionary is an alphabetic list of the names included in the system models. As well as
the name, the dictionary should include an associated description of the named entity and, if
the name represents a composite object, a description of the composition.
• Other information such as the date of creation, the creator and the representation of the
entity may also be included depending on the type of model being developed.
Ex.
Data element- Order

Description- Record comprising fields

Order identification Customer name Customer address
..
Package name
Package price

Product specification document

• Planning
This section outlines who is involved in the development of the product and who is
accountable for decisions that need to be made. It also outlines the intended problem
to solve.
• Scope
The scope section outlines the product’s features and functionality, performance
targets and metrics that define success, any constraints and limitations, and key
assumptions and risks.
• Product design
 For most software products you will need a high-level architecture design, the user
interface mockups, process maps for any changing workflow, and technical designs.
You’ll also need to compliance with any relevant standards and regulations.
• Testing plan
It is likely you will have a standard method for testing your software, so this section
just needs to note any differences or adaptations from the norm. Possibly, you will
need to establish the product’s warranty and support policy.

• Release plan
The release plan should include required steps to release the product to customers. It
may involve training for teams, a tie-in with sales and marketing activity, or
something else relevant to the market your product is entering.
• Managing the product
Managing the product involves defining the product’s lifecycle, outlining the
maintenance and upgrade plan, and establishing the product’s support and training
needs. It’s essential to ensure that the product continues to meet the customer’s needs
and expectations throughout its lifecycle and to identify opportunities for
improvement.

Process Modelling: Structural English, Decision Tree, Decision Table

Structural English:
Decision Tree:
Decision Table: