Definition 1-1: Requirement:

(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.
Types of requirements
Generally, one can distinguish between three types of requirements:
Functional requirements define the functionality that the system to be developed offers. Usually, these
requirements are divided into functional requirements, behavioral requirements, and data requirements.
Quality requirements define desired qualities of the system to be developed and often influence the system
architecture more than functional requirements do. Typically, quality requirements are about the
performance, availability, dependability, scalability, or portability of a system. Requirements of this type are
frequently classified as non-functional requirements.
Constraints cannot be influenced by the team members. Requirements of this type can constrain the system
itself (e.g., “The system shall be implemented using web services”) or the development process (“The
system shall be available on the market no later than the second quarter of 2012”). In contrast to functional
and quality requirements, constraints are not implemented, they are adhered to because they merely limit the
solution space available during the development process.
 A constraint is a requirement that limits the solution space beyond what is necessary for meeting the
given functional requirements and quality requirements.
User and System Requirements
Typically, requirements are presented into two levels of detail; user and system requirements, where user
need a high-level statement of the requirements, while system developers need a more detailed system
specification. So, user and system requirements just refer to different levels of detail.
Having different levels of detail is useful because it communicates information about the system being
developed for different types of readers.

So, end-users will not be concerned with the detail, they need a generic, abstracted written requirement.
While the people who are involved in the development need to know what exactly the system should do.
You will probably end up with a lot of problems and misunderstandings if you didn’t have a clear separation
between the different level detail.
User Requirements
It describes the services that the system should provide and the constraints under which it must operate. We
don’t expect to see any level of detail, or what exactly the system will do, It’s more of generic requirements.
It’s usually written in a natural language and supplied by diagrams.
System Requirements
The system requirements mean a more detailed description of the system services and the operational
constraints such as how the system will be used and development constraints such as the programming
languages.
This level of detail is needed by those who are involved in the system development, like engineers, system
architects, testers, etc.
Functional & Non-Functional Requirements
The software requirements are classified into functional requirements and non-functional requirements.
Functional Requirements
It covers the main functions that should be provided by the system. When expressed as user requirements,
they are usually described in an abstract way.
However, more specific functional system requirements describe the system functions, its inputs, processing;
how it’s going to react to a particular input, and what’s the expected output.
Non-Functional Requirements
These are the constraints on the functions provided by the system.
The constraints, like how many processes the system can handle (performance), what are the (security)
issues the system needs to take care of such as SQL injections …
The rate of failure (reliability), what are the languages and tools that will be used (development), what are
rules you need to follow to ensure the system operates within the law of the organization (legislative).
Non-functional requirements are often critical than individual functional requirements. Users can usually
find ways to work around a system function that doesn’t really meet their needs. However, failing to meet a
non-functional requirement can mean that the whole system is unusable.
For example, if an aircraft doesn’t mean meet its reliability requirements, it won’t be safe for operation, or if
an embedded control system fails to meet its performance requirements, the control functions won’t operate
correctly.
Non-functional requirements should be measurable
Whenever possible, we should write non-functional requirements quantitatively, so that they can be tested.
You can measure them when the system is being tested to check whether the system meets its non-functional
requirements.
 Metrics for non-functional requirements 1
In practice, customers for a system often find it difficult to translate their goals into measurable
requirements. They don’t understand what some numbers define as the required speed or reliability. For
some goals, such as maintainability, there’re no metrics that can be used.
The cost of verifying measurable non-functional requirements can be very high and the customers may not
think that these costs are justified.
Non-functional and functional requirements are dependent
Non-functional requirements often conflict, interact or even generate other functional or non-functional
requirements.
A user requirement concerned with security, such as limiting access to authorized users, may generate other
requirements that are functional, such as the need to include user authentication facilities in the system.
The distinction between functional and non-functional requirements
In practice, it’s difficult to separate functional and non-functional requirements. The distinction is not clear
as their definitions suggest.
Separate between functional and non-functional requirements
If the non-functional requirements are stated separately from the functional requirements, the relationship
between them may be hard to understand.
However, we should explicitly highlight requirements that are clearly related to emergent system properties
such as performance or reliability.
Feasibility Report
Before getting started with the software, you need to make a study to identify whether the system is worth
implementing and if it can be implemented under the current budget, technical skills, schedule, and if it does
contribute to the whole organization objectives or not, etc.
The input to the feasibility study is a set of preliminary business requirements, an outline description of the
system, and how the system is intended to support business processes.
The business requirements are the need of the customer or the developing organization; why the software is
being developed, that must be fulfilled to achieve a high-level objective.
The source for information may be the managers of departments where the system will be used, software
engineers who are familiar with the type of proposed system, technology experts, end-users of the system,
etc. Normally, we should try and complete a feasibility study in two or three weeks.
The results of the feasibility study should be a report that recommends whether to go forward to the next
process, or you won’t be able to implement the software at all.

Definition 1-2: Stakeholder: A stakeholder of a system is a person or an organization that has an (direct or
indirect) influence on the requirements of the system.
Definition 1-3: Requirements Engineering
(1) Requirements engineering is a systematic and disciplined approach to the specification and management
of requirements with the following goals:
(1.1) Knowing the relevant requirements, achieving a consensus among the stakeholders about these
requirements, documenting them according to given standards, and managing them systematically
(1.2) Understanding and documenting the stakeholders’ desires and needs, they specifying and managing
requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and
needs.
Four core activities of requirements engineering:
The four core activities to meet these ends are as follows:
Elicitation: During requirements elicitation, different techniques are used to obtain requirements from
stakeholders and other sources and to refine the requirements in greater detail.
Documentation: During documentation, the elicited requirements are described adequately. Different
techniques are used to document the requirements by using natural language or conceptual models
Validation and negotiation: In order to guarantee that the predefined quality criteria are met, documented
requirements must be validated and negotiated early on (see chapter 7).
Management: Requirements management is orthogonal to all other activities and comprises any measures
that are necessary to structure requirements, to prepare them so that they can be used by different roles, to
maintain consistency after changes, and to ensure their implementation.
These core activities can be applied for different levels of requirements abstraction, like stakeholder
requirements, system requirements, and software requirements.
What is Requirements Engineering?
A systematic and strict approach to the definition, creation and verification of requirements for a software
system is known as requirements engineering. In order to guarantee the effective creation of a software
product, the requirements engineering process entails a number of tasks that help in understanding,
recording and managing the demands of stakeholders.
Steps in Requirements Engineering Process
The requirements engineering process is an iterative process that involves several steps, including:
Requirements Elicitation
This is the process of gathering information about the needs and expectations of stakeholders for the
software system. This step involves interviews, surveys, focus groups, and other techniques to gather
information from stakeholders.
Requirements Analysis
This step involves analyzing the information gathered in the requirements elicitation step to identify the
high-level goals and objectives of the software system. It also involves identifying any constraints or
limitations that may affect the development of the software system.
Requirements Specification
This step involves documenting the requirements identified in the analysis step in a clear, consistent, and
unambiguous manner. This step also involves prioritizing and grouping the requirements into manageable
chunks.
Requirements Validation
This step involves checking that the requirements are complete, consistent, and accurate. It also involves
checking that the requirements are testable and that they meet the needs and expectations of stakeholders.
Requirements Management
This step involves managing the requirements throughout the software development life cycle, including
tracking and controlling changes, and ensuring that the requirements are still valid and relevant.
Requirement Engineering
The Requirements Engineering process is a critical step in the software development life cycle as it helps to
ensure that the software system being developed meets the needs and expectations of stakeholders, and that
it is developed on time, within budget, and to the required quality.
Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a
process of gathering and defining service provided by the system. it is the disciplined application of proven
principle , methods ,tools and notations to describe a proposed system’s intended behaviour and its
associated constraints.
Tools Involved in Requirement Engineering
 observation report
 Questionnaire ( survey , poll )
 Use cases
 User stories
 Requirement workshop
 Mind mapping
 Role playing
 Prototyping
Requirements Engineering Process Consists of the Following Main Activities
 Requirements elicitation
 Requirements specification
 Requirements verification and validation
  Requirements management
1. Requirements Elicitation
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 same
type, standards and other stakeholders of the project. The techniques used for requirements elicitation
include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are
discussed here. Elicitation does not produce formal models of the requirements understood. Instead, it
widens the domain knowledge of the analyst and thus helps in providing input to the next stage.
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.
There are several techniques that can be used to elicit requirements, including:
 Interviews: These are one-on-one conversations with stakeholders to gather information about their
needs and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather information about
their needs and expectations.
 Focus Groups: These are small groups of stakeholders who are brought together to discuss their
needs and expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work environment to
gather information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software system, which can
be used to gather feedback from stakeholders and to validate requirements.
It’s important to document, organize and prioritize the requirements obtained from all these techniques to
ensure that they are complete, consistent and accurate.
2. Requirements Specification
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.
Requirements specification is the process of documenting the requirements identified in the analysis step in
a clear, consistent, and unambiguous manner. This step also involves prioritizing and grouping the
requirements into manageable chunks.
The goal of this step is to create a clear and comprehensive document that describes the requirements for the
software system. This document should be understandable by both the development team and the
stakeholders.
There are several types of requirements that are commonly specified in this step, including
1. Functional Requirements: These describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data storage, and user interface.
 2. Non-Functional Requirements: These describe how well the software system should do it. They
specify the quality attributes of the system, such as performance, reliability, usability, and security.
3. Constraints: These describe any limitations or restrictions that must be considered when developing
the software system.
4. Acceptance Criteria: These describe the conditions that must be met for the software system to be
considered complete and ready for release.
In order to make the requirements specification clear, the requirements should be written in a natural
language and use simple terms, avoiding technical jargon, and using a consistent format throughout the
document. It is also important to use diagrams, models, and other visual aids to help communicate the
requirements effectively.
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.
3. Requirements Verification and Validation
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. The main steps for this
process include:
1. The requirements should be consistent with all the other requirements i.e no two requirements should
conflict with each other.
2. The requirements should be complete in every sense.
3. The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
Requirements verification and validation (V&V) is the process of checking that the requirements for a
software system are complete, consistent, and accurate, and that they meet the needs and expectations of the
stakeholders. The goal of V&V is to ensure that the software system being developed meets the
requirements and that it is developed on time, within budget, and to the required quality.
1. Verification is the process of 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.
2. 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.
3. V&V is an iterative process that occurs throughout the software development life cycle. It is
important to involve stakeholders and the development team in the V&V process to ensure that the
requirements are thoroughly reviewed and tested.
It’s important to note that V&V is not a one-time process, but it should be integrated and continue
throughout the software development process and even in the maintenance stage.
4. Requirements Management
Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on
the requirement and controlling the communication to relevant stakeholders. This stage takes care of the
changing nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to
incorporate changes in requirements specified by the end users at later stages too. Being able to modify 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.
There are several key activities that are involved in requirements management, including:
1. Tracking and controlling changes: This involves monitoring and controlling changes to the
requirements throughout the development process, including identifying the source of the change,
assessing the impact of the change, and approving or rejecting the change.
2. Version control: This involves keeping track of different versions of the requirements document and
other related artifacts.
3. Traceability: This involves linking the requirements to other elements of the development process,
such as design, testing, and validation.
4. Communication: This involves ensuring that the requirements are communicated effectively to all
stakeholders and that any changes or issues are addressed in a timely manner.
5. Monitoring and reporting: This involves monitoring the progress of the development process and
reporting on the status of the requirements.
Requirements management is a critical step in the software development life cycle as it helps to ensure that
the software system being developed meets the needs and expectations of stakeholders, and that it is
developed on time, within budget, and to the required quality. It also helps to prevent scope creep and to
ensure that the requirements are aligned with the project goals.

Advantages and Disadvantages

The advantages and disadvantages of the requirements engineering process in software engineering include:
Advantages
 Helps ensure that the software being developed meets the needs and expectations of the stakeholders
 Can help identify potential issues or problems early in the development process, allowing for
adjustments to be made before significant
 Helps ensure that the software is developed in a cost-effective and efficient manner
 Can improve communication and collaboration between the development team and stakeholders
 Helps to ensure that the software system meets the needs of all stakeholders.
 Provides a clear and unambiguous description of the requirements, which helps to reduce
misunderstandings and errors.
 Helps to identify potential conflicts and contradictions in the requirements, which can be resolved
before the software development process begins.
 Helps to ensure that the software system is delivered on time, within budget, and to the required
quality standards.
 Provides a solid foundation for the development process, which helps to reduce the risk of failure.
Disadvantages
 Can be time-consuming and costly, particularly if the requirements gathering process is not well-
managed
 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into account
 Can be challenging to ensure that the requirements are clear, consistent, and complete
 Changes in requirements can lead to delays and increased costs in the development process.
 As a best practice, Requirements engineering should be flexible, adaptable, and should be aligned
with the overall project goals.
 It can be time-consuming and expensive, especially if the requirements are complex.
 It can be difficult to elicit requirements from stakeholders who have different needs and priorities.
 Requirements may change over time, which can result in delays and additional costs.
 There may be conflicts between stakeholders, which can be difficult to resolve.
 It may be challenging to ensure that all stakeholders understand and agree on the requirements.
Stages in Software Engineering Process
Requirements engineering is a critical process in software engineering that involves identifying, analyzing,
documenting, and managing the requirements of a software system. The requirements engineering process
consists of the following stages:
 Elicitation: In this stage, the requirements are gathered from various stakeholders such as customers,
users, and domain experts. The aim is to identify the features and functionalities that the software
system should provide.
 Analysis: In this stage, the requirements are analyzed to determine their feasibility, consistency, and
completeness. The aim is to identify any conflicts or contradictions in the requirements and resolve
them.
  Specification: In this stage, the requirements are documented in a clear, concise, and unambiguous
manner. The aim is to provide a detailed description of the requirements that can be understood by all
stakeholders.
 Validation: In this stage, the requirements are reviewed and validated to ensure that they meet the
needs of all stakeholders. The aim is to ensure that the requirements are accurate, complete, and
consistent.
 Management: In this stage, the requirements are managed throughout the software development
lifecycle. The aim is to ensure that any changes or updates to the requirements are properly
documented and communicated to all stakeholders.
 Effective requirements engineering is crucial to the success of software development projects. It
helps ensure that the software system meets the needs of all stakeholders and is delivered on time,
within budget, and to the required quality standards.
SYSTEM ENGINEERING:
What are the fundamentals of systems engineering?

Systems engineering is the interdisciplinary field that focuses on designing, integrating, and managing the
systems that work together to form a more complex system. Systems engineering is based around systems
thinking principles, and the goal of a systems engineer is to help a product team produce an engineered
system that performs a useful function as defined by the requirements written at the beginning of the project.
The final product should be one where the individual systems work together in a cohesive whole that meet
the requirements of the product.

What is a system?

The system context is the part of the system environment that is relevant for the definition as well as the
understanding of the requirements of a system to be developed.

Among others, the following possible aspects of reality influence the context of a system:

 People (stakeholders or groups of stakeholders)

 Systems in operation (other technical systems or hardware)
 Processes (technical or physical processes, business processes)
 Events (technical or physical)
 Documents (e.g., laws, standards, system documentation)

A system is a collection of different elements that produce results that individual elements cannot produce.
Elements or parts can be wide-ranging and include people, hardware, software, facilities, policies, and
documents. These elements interact with each other according to a set of rules that produce a unified whole
with a purpose expressed by its functioning. An example of a system is the human auditory system; the
system includes individual parts in the form of bones and tissue that interact in a way to produce sound
waves, which are transferred to nerves that lead to the brain, which interprets the sounds and formulates a
response. If any single part in the auditory system fails or experiences disruption, the entire system can fail
to perform its function.

What is the role of a systems engineer?

A systems engineer is tasked with looking at the entire integrated system and evaluating it against its desired
outcomes. In that role, the systems engineer must know a little bit about everything and have an ability to
see the “big picture.” While specialists can focus on their specific disciplines, the systems engineer must
evaluate the complex system as a whole against the initial requirements and desired outcomes.
Systems engineers have multi-faceted roles to play but primarily assist with:

 Design compatibility
 Definition of requirements
 Management of projects
 Cost analysis
 Scheduling
 Possible maintenance needs
 Ease of operations
 Future systems upgrades
 Communication among engineers, managers, suppliers, and customers in regards to the
system’s operations

How can systems engineers help improve traceability?

For many systems engineers, balancing the needs of the individual systems and their engineers against the
system as a whole results in addressing problems after the fact, holding unwanted meetings, and trying to
persuade others to change behavior. Many organizations may not adequately focus on requirements and
traceability, resulting in a lack of data that would allow a systems engineer to better evaluate the product.

To avoid constantly chasing problems and start streamlining processes, systems engineers can use three best
practices:
 Baseline the current traceability performance: Traceability spans the product development
process, and product team members understand the value of data management, especially as
concerns meeting industry requirements. By establishing a baseline of traceability performance,
the entire team will be able to see existing risks and potential savings and improvements. In
addition, a baseline can give a foundation for a plan of action to move toward Live Traceability.
 Build the business case for Live Traceability: With a baseline in hand, systems engineers
can offer a case for moving to Live Traceability based on data. The data can establish the ROI,
productivity improvements, and risk reduction of moving from static traceability to Live
Traceability.
 Create quick wins: Once the advantages of Live Traceability are established, the systems
engineer can set up continuous syncing between requirements and task management programs,
thus automating traceability from requirements to user stories. This simple shift can help
demonstrate the value of shifting from after-the-fact traceability to Live Traceability.

What is the Systems Engineering Process?

The systems engineering process can take a top-down approach, bottoms up, or middle out depending on the
system being developed. The process encompasses all creative, manual, and technical activities necessary to
define the ultimate outcomes and see that the development process results in a product that meets objectives.

The process typically has four basic steps:

 Task definition/analysis/conceptual: In this step, the systems engineer works with

stakeholders to understand their needs and constraints. This stage could be considered a creative
 or idea stage where brainstorming takes place and market analysis and end user desires are
included.
 Design/requirements: In this phase, individual engineers and team members analyze the
needs in step 1 and translate them into requirements that describe how the system needs to work.
The systems engineer evaluates the systems as a whole and offers feedback to improve
integration and overall design.
 Create traceability: Although we’re listing traceability here as the third step, traceability is
actually created throughout the lifecycle of development and is not a discrete activity taking place
during one phase. Throughout the lifecycle of development, the team works together to design
individual systems that will integrate into one cohesive whole. The systems engineer helps
manage traceability and integration of the individual systems.
 Implementation/market launch: When everyone has executed their roles properly, the final
product is manufactured or launched with the assurance that it will operate as expected in a
complex system throughout its anticipated life cycle.

The “V” Diagram of Systems Engineering

Developed in the 1980s, the “V” Diagram of Systems Engineering is a way of specifying the specific series
of steps that make up a systems engineering approach. While it was originally employed in a pre-Agile
environment, it still has relevance to product development today and can enable faster, less risky product
development.

The “V” diagram allows system engineers multiple viewpoints and opportunities to evaluate systems as they
integrate with each other. This approach starts with the desired outcomes and objectives and then
deconstructs them into individual systems and system components for the purpose of design. Once the
requirements and design details are established, individual systems can be tested and evaluated, then
integrated into the overall piece for testing and verification. As the systems are integrated and become closer
to the final complex system, teams have multiple opportunities to validate and verify concepts,
requirements, and design.

For the systems engineer, the “V” Model can give a clear roadmap that allows the breakdown of the
complex system into smaller parts and then the reintegration and reassembly of the pieces into a cohesive
whole. With systems broken down to individual components, traceability, requirements management, and
testing and validation become more manageable. In addition, as the pieces are reintegrated into the whole
system, the “V” Model allows for an iterative process that gives a clearer view into potential risks and helps
troubleshoot problems.
Requirements and Quality:

REF:

The consequences of having no requirements are many and varied. There is ample evidence around us of
systems that failed because requirements were not properly organized. However well the system may appear
to work at first, if it is not the system that users want or need then it will be useless. It is interesting to
consider the relationship between requirements and quality. The term “quality” may be understood in a
variety of ways. When asked about quality cars, one might mention Rolls Royce, Mercedes or Jaguar. This
inherent confusion between “quality” and “luxury” is exposed if consideration is given to choosing the best
car for the annual RAC rally. Neither Rolls Royce, Mercedes nor Jaguar are chosen, since they do not
exhibit the right weight/power ratio, ground clearance and robustness properties. Recent history shows that
the best quality car in its class is a Skoda – not a luxury car, but the right quality of car for the job. Quality,
then, is “fitness for purpose” or conformance to requirements – it is providing something that satisfies the
customer and in doing so ensures that the needs of all the stakeholders are taken into account.

requirements engineering acts as a complement to other management considerations, such as cost and
schedule, by providing a vital focus on the delivery of quality. Every management decision is a compromise
between cost, schedule and quality, three inter-related axes. Since requirements engineering is a discipline
that applies from the start of the development lifecycle, the leverage on quality that can be exercised by
proper requirements management is proportionately greater. Relatively little effort expended in early stages
of development can reap dividends in the later stages. The adage “Quality is Free” (the title of a book by
Phil Crosby) holds true, in that getting it right at the outset can save huge amounts of effort that would have
been necessary to put things right later. Improving requirements means improving the quality of the product.

TXT
Quality requirements define desired qualities of the system to be developed and often influence the system
architecture more than functional requirements do. Typically, quality requirements are about the
performance, availability, dependability, scalability, or portability of a system. Requirements of this type are
frequently classified as non-functional requirements.
In daily practice, quality requirements of a system are often not documented, inadequately documented, or
improperly negotiated. Such circumstances can threaten the project’s success or the subsequent acceptance
of the system under development. Therefore, the requirements engineer should place special emphasis on the
elicitation, documentation, and negotiation of quality requirements during the development process.
Typically, many different kinds of desired qualities of the system are assigned to the requirement type
quality requirement. In order to be able to deal with quality requirements in a structured manner, many
different classification schemes for quality requirements have been proposed. The ISO/IEC 25010:2011
standard [ISO/IEC 25010:2011], for example, suggests a classification scheme for quality requirements that
can also be used as a standard structure for requirements documentation and as a checklist for requirements
elicitation and validation. Among others, the following categories are typical for quality requirements (see
[ISO/IEC 25010:2011]):
 Requirements that define the performance of the system, in particular response time behavior and
resource utilization
 Requirements that define the security of the system, in particular with regard to accountability,
authenticity, confidentiality, and integrity
 Requirements that define the reliability of functionalities, in particular with regard to availability,
fault tolerance, and recoverability
 Requirements that define the usability of a system, in particular with regard to accessibility,
learnability, and ease of use
 Requirements that define the maintainability of a system, in particular with regard to reusability,
analyzability, changeability, and testability
 Requirements that define the portability of a system, in particular with regard to adaptability,
installability, and replaceability
Currently, quality requirements are often specified using natural language. However, numerous
approaches to document quality requirements by means of models have been suggested over the past
couple of years. The requirements engineer is responsible for making sure the quality requirements are
as objective and verifiable as possible. Typically, this necessitates that the quality requirements are
quantified. For example, a quality requirement with regard to system performance could specify that a
system shall process 95 percent of all queries within 1.5 seconds and that it must not take longer than 4
seconds to process queries at any given time. This can cause quality requirements to be refined by means
of additional functional requirements. This could be the case for a quality requirement that is concerned
with system security if a functional requirement specifies the exact encryption algorithm to satisfy the
need for encryption as demanded by some quality requirement. Quality requirements are often related to
different functional requirements. As a result, quality requirements should always be kept separated from
functional requirements. In other words, quality requirements should not be mixed with functional
requirements and should be documented separately, with explicit documentation of their relation to
functional requirements.
What is Requirement Lifecycle?
Requirement life cycle is the process of creating, maintaining, evolving, implementing & delivering the
requirements artifacts throughout the life cycle of a system or project. The nature of the process depends
on the methodology we choose like Agile, Waterfall, Incremental, etc.
Requirement’s life cycle can be a critical aspect of any software development project. It is an essential
step that helps assure that the final product is what the customer or user wants. In other words,
requirement’s life cycle is about being able to see the big picture for a project and keeping it on track.
The phases of the requirement life cycle can be seen as follows:

1)What to Build 2) How to Build 3) Build and Deliver

What to Build: The main focus is to understand the business demands.

How to Build: This phase mainly focuses on requirements grooming, solution design, and backlog
refinement.

Build and Deliver: Essentially, this entails coding, testing, and releasing.

1.Pre-Planning (New)
Stakeholders: Product Owner & UI designer

1) Once the IT team has received a requirement from the business, create an entry in spec document(s) for
grooming. (closed → The activity should be closed in this phase)

2) Start UI wireframe. It is about creating a sample of the application to test the features, look and usability
of the application before it is developed. It is the easiest way to check functionality and evaluate if the
application serves the purpose. It keeps the user in mind and creates the basic skeleton of any application
feature.

2. Planning (Grooming)

Stakeholders: Product Owner, UI designer, Technical Architect(s) & Tester

1) Based on our understanding of the requirement and keeping high-level UI design in mind, we’ll create
relevant features and/or stories in DevOps to proceed with requirements grooming. (closed)

2) UI design & requirements grooming will supplement each other with ideas/inputs to conclude DevOps
features & stories for implementation (closed)

3. Ready

Stakeholders: Product Owner, UI designer, Technical Architect(s) & Tester

1) Done with story grooming with clear acceptance criteria. (closed)

2) Done with UI design. (closed)

3) Ready to handover the business story to the DEV team for implementation & QA for test plan
preparation. (In-progress)

4. Implementation

We can track implementation items such as engineering stories & builds on respective Azure DevOps Team
projects and link engineering stories with the business story that’s part of the Azure DevOps Project
Management dashboard.

Stakeholders: Technical Scrum Team & Tester

1) Done with handover of a business story for implementation. (closed)

2) Dev team to understand the business story, proceed with creating corresponding engineering stories for
grooming and come up with a clear implementation strategy. (closed)

3) Upon complementation of engineering stories grooming, start working on coding in the sprint cycle.
(closed)
4) QA to finish test plan and test cases required to verify business story implementation as per its acceptance
criteria. (closed)

5. Testing

Stakeholders: Product Owner, Technical Scrum Team & Tester

1) QA to verify business story implementation as per its acceptance criteria in the staging environment.
(closed)

2) QA to raise defects if any issues. (closed)

3) QA to hold defect triage meetings with stakeholders. (closed)

6. Release

Stakeholders: Product Owner, Manager & Technical Architect(s)

1) Product Owner to come up with release notes. (closed)

2) Technical Architect(s) to be ready with forward & reverse migration plans (closed)

3) Manager to supervise the release process and help the team with necessary approvals (closed)

7. Post Deployment Testing (PDT)

Stakeholders: Product Owner, Manager & Tester

1) Product Owner & Tester to perform smoke testing in the production environment. (closed)

2) Manager to make a GO/NO-GO call on release. (closed)

8. Close

1) End of business story life cycle

Maintaining a requirement life cycle in the form of Epics, Features, Business/Engineering stories, Test
Cases, Bugs, Code Repositories, Builds and Releases in a platform such as Azure DevOps will allow us to
trace work from its origin through its delivery, which is vital to traceability.
Requirement Traceability:
it refers to the ability to track and trace requirements to artifacts, test runs, and anything else in the product
lifecycle. Traceability is important because it creates transparency at every step of development, including
who completed what tasks and when.
In the requirements engineering context, traceability is about understanding how high-level requirements –
objectives, goals, aims, aspirations, expectations, needs – are transformed into low-level requirements. It is
therefore primarily concerned with the relationships between layers of information.
In a business context, one may be interested in how
• business vision is interpreted as
• business objectives are implemented as
• business organization and processes.
In an engineering context, the interest may focus on how
• stakeholder requirements are met by
• system requirements are partitioned into
• subsystems are implemented as
• components.
Using traceability can contribute to the following benefits:
• Greater confidence in meeting objectives. Establishing and formalizing traceability engenders greater
reflection on how objectives are satisfied.
• Ability to assess the impact of change.Various forms of impact analysis become possible in the presence
of traceability information.
• Improved accountability of subordinate organizations. Greater clarity of how suppliers contribute to the
whole.
 • Ability to track progress. It is notoriously difficult to measure progress when all that you are doing is
creating and revising documents. Processes surrounding traceability allow precise measures of progress in
the early stages.
• Ability to balance cost against benefit. Relating product components to the requirements allows benefit to
be assessed against cost.
Traceability relationships are usually many-to-many – that is, one lower level requirement may be linked to
several higher level requirements and vice versa. The simplest way to implement a form of traceability is to
link requirements statements in one layer with statements in another. Requirements management tools
typically allow such linking by drag-and-drop between paragraphs of documents. The links are rather like
hyperlinks in web pages, but should ideally be traversable in either direction. Figure 1.6 shows traceability
downwards through the layers of requirements and across to the test information. The direction of the arrows
follows a particular convention: information traces back to the information it responds to. There are a
number of reasons for this convention:
• It usually corresponds to the chronological order in which information is created: always link back to the
older information.
• It usually corresponds to access rights due to ownership: one owns the outgoing links from a document,
someone else owns the incoming links.
TXT:
Traceability Of Requirements:
An important aspect of requirements management is ensuring the traceability of requirements. The traceability of a
requirement is the ability to trace the requirements over the course of the entire life cycle of the system Advantages of
requirements traceability
The use of traceability information supports system development in many aspects and is often the precondition for
establishing and using certain techniques during the developmental process [Pohl 1996; Ramesh 1998]:

 Verifiability: Traceability of requirements allows verifying whether a requirement has been implemented in
the system, i.e., if the requirement has been implemented through a system property.
 Identification of gold-plated solutions in the system: Traceability of requirements allows for the identification
of so-called gold-plated solutions of the developed system and thereby allows identifying unneeded
properties. In order to do that, for each system property (functional or qualitative), a check is performed to
determine whether it contributes to the implementation of a requirement of the system.
 Identification of gold-plated solutions in the requirements: Tracing requirements back to their origin allows
identifying requirements that do not contribute to any system goal and are not associated with any source.
Usually, there is no reason for these requirements to exist and hence these requirements do not have to be
implemented.
 Impact analysis: Traceability of requirements allows for the analysis of effects during change management.
For example, traceability of requirements allows identifying the requirements artifacts that must be changed
when their underlying requirements undergo a change.
 Reuse: Traceability of requirements allows for the reuse of requirements artifacts in other projects. By
comparing the requirements of a previous project to the requirements of a new project by means of trace links,
development artifacts (e.g., components, test cases) can be identified that may be adapted and/or reused in the
new development project.
 Accountability: Traceability of requirements allows for retroactive assignment of development efforts to a
requirement. After the requirement is implemented, for example, all partial efforts for the associated
development artifact can be summed up and associated with the requirement.
 Maintenance: Traceability of requirements allows for simplified system maintenance. For example, the cause
and effect of failures can be identified, the system components that are affected by the failure can be
determined, and the effort for removing the underlying error can be estimated.
Purpose-Driven Definition of Traceability
As resources are usually severely restricted during development projects, capturing all conceivable information that
supports the traceability of requirements over the course of the system life cycle is almost never possible.
Purpose of traceability information
 In order to establish requirements traceability effectively and efficiently, the information to be recorded should be
chosen with respect to the purpose that it will serve. In other words, only the information which has a clear purpose
for system development or system evolution [Dömges and Pohl 1998; Ramesh and Jarke 2001] ought to be recorded.
Recording of traceability information that is not purpose driven often results in the fact that the recorded information
cannot be profitably used in the development project. Traceability information that is recorded in this fashion is often
sketchy and incomplete, unstructured, and erroneous with regard to its further use
Classification Of Traceability Relations:

 Pre-RS traceability: Pre-RS traceability are traceability links between requirements and those artifacts that are
the basis for the requirements, e.g., artifacts like the source or origin of a requirement (previous artifacts).
 Post-RS traceability: Post-RS traceability comprises traceability information between requirements and
artifacts of subsequent development activities. For example, such artifacts could be components,
implementation, or test cases that belong to a requirement (posterior artifacts).
 Traceability between requirements: The traceability between requirements is about mapping dependencies
between requirements. An example of this kind of traceability is the information that a requirement refines
another requirement, generalizes it, or replaces it.

Representation Of Requirements Traceability

Requirements traceability information can be represented in different ways. The most common approaches to
representing traceability are simple textual references, hyperlinks, and trace matrices and trace graphs.

 Text-Based References and Hyperlinks: This simple way to represent traceability information of a requirement
consists of annotating the target artifact as a textual reference in the requirement (initial artifact) or to establish
a hyperlink between the initial artifact and the target artifact. When linking artifacts, different types of
hyperlinks with specific link semantics can be used.
 Trace Matrices : Another common technique for representing and documenting traceability information
between requirements as well as between requirements and previous and posterior artifacts in the development
process are trace matrices. The rows in a trace matrix contain the initial artifacts (requirements). In the
columns, the target artifacts (e.g., sources of requirements, development artifacts, requirements) are
represented. If a trace link exists between an initial artifact in row n and a target artifact in column m, cell (n,
m) is marked in the trace matrix. Interpretation of a trace matrix Figure 8-7 shows a simple trace matrix for
the trace relation “derived” that exists between two requirements. An entry in the matrix specifies that a trace
link of type “derived” exists from a requirement “Req-n” to another requirement “Req-m” such that “Req-n”
was derived from “Req-m”
  Trace Graphs :
A trace graph is a graph in which all nodes represent artifacts and all edges represent relationships between
artifacts. The distinction between different artifacts and types of traceability can be realized by means of
assigning different attributes to the nodes and edges of the graph.Figure 8-8 shows the representation of
traceability information in a simple example. In the trace graph, a node type is defined for each type of artifact
(context information “C”, requirements “Req-n”, components “Comp-n”). In addition, three types of edges are
defined to represent three types of traceability relations (“realized through”, “is origin”, “refines”).

What is Requirements Modeling: Process & Tools

Requirements Modeling is a process of documenting, analyzing, and managing Requirements. Requirements

change throughout the project, so it is important to have a way to track them and make sure everyone
understands them. There are many tools and courses available to help you with Requirements Modeling. In
this article, we will discuss what Requirements Modeling is, the different processes and tools involved in
Requirements Modeling, as well as some courses that can help you learn more about Requirements
Modeling.

What is Requirements Modeling?

The technique of modeling requirements and solutions as they change through collaborative work and
cooperation is known as Requirements Modeling. You may ensure that your team satisfies the stakeholders’
exact requirements by employing this approach of cross-functional, self-organizing teams.

Requirements Modeling is the process of documenting, analyzing, and managing Requirements.

Requirements can be anything that a customer or user wants from a software system. They can include
functional requirements (what the system should do), non-functional requirements (such as performance,
security, etc.), as well as constraints (things that might limit what the system can do).

The Requirements Modeling process involves three main activities:

1. Analysis: Once the Requirements have been collected, they need to be analyzed to see if they are
complete, consistent, and clear. Any inconsistencies or ambiguities should be resolved at this stage.
2. Documentation: The Requirements should be documented in a clear and concise way. This will
ensure that everyone understands the Requirements and can refer back to them if needed.
3. Management: Once the Requirements have been collected and documented, they need to be
managed throughout the project. This includes keeping track of changes to Requirements, making
sure everyone is aware of these changes, and ensuring that the requirements are still being met.

Benefits of Requirements Modeling

Requirements modeling will improve the clarity of your requirements. This may have a profound influence
on the success of your software projects. The following are some of the most significant advantages of
adopting modern requirements modeling and management systems:

1. Creating simulations is a breeze

2. Automatic document generation
3. Automatics Test Conduction
4. Easy integration with development and testing tools
5. Easy requirements change management

Why is Requirements Modeling Important?

Requirements Modeling is important because it helps to ensure that the Requirements for a project are well
understood by everyone involved. It also helps to identify any potential risks or problems early on in the
project, which can save time and money later on.

If you want to achieve quick, consistent, and continuous software delivery, then requirements modeling is
key. Even though this process might not give you clear-cut solutions, it will provide you with a reliable
guide for the end product. This way, your development team will have a stronger comprehension of the
product and how to develop it. Consequently, both developers and clients can voice any concerns they may
have about the product early on. By using this process from the beginning stages of planning, you can
present both your project stakeholders and customers with a comprehensive blueprint that is easy to follow.

Any modifications that are required to match their exact demands and specifications may be addressed in
this strategy. You will decrease the chance of obstacles later on by providing enhanced and rapid feedback at
the start of the project and throughout its duration. When fresh team members are added, it’s even more
crucial. These methods can quickly provide new workers an overview of the project from beginning to end –
from conception to completion. This allows new employees to grasp how iterations in this system are
prioritized.

If Requirements are not well understood, there is a risk that they will not be met. This can lead to the project
being delayed, over budget, or even canceled. In some cases, it can also lead to legal issues if the final
product does not meet the customer’s expectations.
Requirements Modeling Techniques

There are many different tools that can be used for Requirements Modeling, depending on the needs of the
project. Some of the most popular requirements modeling tools include

 Requirements Traceability Matrix: A requirements traceability matrix is a table that shows the
relationships between requirements. It can be used to ensure that all requirements are being met.
 Use Cases: A use case is a description of how a user will interact with the system to achieve a
specific goal. Use cases can be used to capture functional requirements. Use cases depict the high-
level functionalities that the system should be able to perform.
 User Stories: A user story is a short, simple description of a feature from the perspective of the user.
User stories can be used to capture both functional and non-functional requirements.
 Process Flow Diagrams: A process flow diagram shows how tasks are performed in a process.
Process flow diagrams can be used to capture both functional and non-functional requirements.
 Activity Diagram – This approach is used to address the whole business process or system process –
which may be appropriate for all sorts of users depending on the requirement’s being functional and
the type being fundamental. This approach can only define the scope of a system or procedure, but it
can’t help with detailed impact analysis.
 State Diagram – A state diagram is a more detailed approach than a flow chart. Only the various
states of an object that passes through a process flow are depicted in a state diagram when it comes
to the system’s or procedure’s elements, or the process itself. This element, according to this
viewpoint, cannot be used directly in impact analysis calculations.
 Sequence Diagram – This is more relevant for a technical user, especially when many processes are
underway. It visualizes how processes or objects interact during a scenario and depicts this in a
graphical way. This approach adds additional value to technical users since it can help them get
down to specific technological specifications. During the development phase, this technique is the
most popular method for requirement reference, owing to its usefulness.

Requirements Modeling Elements

Below are the different strategies of requirements modeling:

1. Flow Oriented Modeling – The data objects are transformed by the function as it is processed.

The Flow oriented elements are

 Data Flow Model – It is a graphical technique. It is used to represent information flow.

 Control Flow Model – Large class applications require control flow modeling.
 Control Specification – The state diagram in the control specification is a sequential specification of
the behavior.
 Process Specification – The process specification is used to describe all flow model processes.

2. Class-based Modeling – Class-based modeling represents the object. The system manipulates the
operations.

The elements of the class-based model consist of the following:

 Classes – To figure out which classes to take, underline each noun or noun clause in the text and
enter it into the table.
 Attributes – Attributes are the data objects that define a class within the context of the problem. For
example, ’employee’ is a class consisting of the name, Id, department, designation, and salary of the
employee.
 Operations – The operations describe the actions of a thing.

Unified Modeling Language (UML)

People have been using models for as long as systems modeling has existed. Models include physical mock-
ups, such as the hull of a ship’s body. Prototypes and mock-ups are examples of physical models. And, since
engineers can remember, models were created on paper in the form of sketches, flow diagrams, and the like.
Some were informal and intended to be discarded; others utilized a more formal notation and were
maintained throughout the system development cycle.

The invention of the unified modeling language (UML) proved to be a game-changer. For those who are
unfamiliar with it: UML is a graphical general-purpose modeling language that covers both structural and
behavioral elements of a system. In a nutshell, it formalizes the use of “boxes and arrows” to provide
defined syntax and meaning.

UML Methods for Requirements Modeling

While UML has been incredibly successful, it has one negative consequence: Over time, it becomes very
large and complex. This can be intimidating for people trying to learn the standard. Therefore, it’s essential
to only use the relevant subset of UML for any given task. Also, like spoken languages, there are different
ways to use UML correctly or incorrectly. A method outlines how the language should ideally be applied in
order to limit which UML elements are used and to what purpose.

Two popular methods for starting a UML requirements model are use cases and class diagrams. To create a
more detailed picture, the initial model is elaborated with additional information. What this looks like in
practice is described below:

 ICONIX – ICONIX is a lightweight method from the ’90s. It promised to get from requirements to
code with only four UML diagrams. For whatever reason, it is not very widely known. I consider it
very useful for small and medium-sized software projects that are not safety-critical.
 SYSMOD – SYSMOD is more of a toolbox than a method, but it contains a number of useful tactics
for requirements modeling.

Requirements Model Structure

At first glance, UML may seem to be all about the diagrams. But if done correctly, it is a byproduct of the
modeling process – albeit a useful one. The diagram helps readers understand the “big picture.” It serves as a
map, guiding them through the model. But each symbol in the diagram provides extensive amounts of extra
information that often has no representation in the picture. To demonstrate this, let’s look at use cases. The
accompanying table below shows some of the information that may be included in part of the model:

Name Log-out

Actors The logged-in users

I want to be able to log out of the system so that my account cannot be accessed by
Description
anyone else during this browser session.

Preconditions The user must be logged into the system

The user initiates the log-out command. The system then logs the user out of the system
Activity
and further, displays a corresponding message.

Postcondition
The user is logged out of the system
s
What are Agile Methodologies?
Agile Methodologies such as Scrum and Kanban, provide an iterative approach to validate requirements
by delivering small chunks of functionality and getting feedback from the customer.
It is important to note that no single technique is sufficient on its own and a combination of different
techniques is usually used to validate software requirements effectively.
0 seconds of 16 secondsVolume 0%

What is Requirements Validation/Requirement Testing?

Requirements validation is the process of checking that requirements defined for development, define
the system that the customer wants. To check issues related to requirements, we perform requirements
validation. We typically use requirements validation to check errors at the initial phase of development
as the error may increase excessive rework when detected later in the development process. In the
requirements validation process, we perform a different type of test to check the requirements mentioned
in the Software Requirements Specification (SRS), these checks include:
1. Completeness checks: A requirement must contain all information needed for developers and
everyone else who uses it to do their jobs. And a requirement should include all the details necessary
to express the users' needs.
2. Consistency checks: Requirements should not contradict other requirements. Each must fully comply with
external documentation, as well as internal and external standards.Pay attention to the general wording in
your requirements. For example, if all "submit" buttons should be blue throughout the application,
put these on a "dangerous requirements" list, and then analyze all other requirements for any
contradictions.
3. Validity checks
4. Realism checks
5. Ambiguity checks
6. Variability
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 actions states the corrective action that should be taken to fix the detected problem.
Requirement Validation Techniques
There are several techniques that are used either individually or in conjunction with other techniques to
check entire or part of the system:
1. Test Case Generation
The requirement mentioned in the SRS document should be testable, the conducted tests reveal the error
present in the requirement. It is generally believed that if the test is difficult or impossible to design, this
usually means that the requirement will be difficult to implement and it should be reconsidered.
2. Prototyping
In this validation technique the prototype of the system is presented before the end-user or customer,
they experiment with the presented model and check if it meets their need. This type of model is mostly
used to collect feedback about the requirement of the user.
3. Requirements Reviews
In this approach, the SRS is carefully reviewed by a group of people including people from both the
contractor organizations and the client side, the reviewer systematically analyses the document to check
errors and ambiguity.
4. Automated Consistency Analysis
This approach is used for the automatic detection of an error, such as non-determinism, missing cases, a
type error, and circular definitions, in requirements specifications. First, the requirement is structured in
formal notation then the CASE tool is used to check the 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.
 Checking early whether the idea is feasible or not.
 Obtaining the opinions and suggestions of other people.
 Checking the approval of others and reaching an agreement.
6. Simulation
Simulating system behavior in order to verify requirements is known as simulation. This method works
especially well for complicated systems when it is possible to replicate real-world settings and make sure
the criteria fulfil the desired goals.
0 seconds of 17 secondsVolume 0%

7. Checklists for Validation

It employs pre-made checklists to methodically confirm that every prerequisite satisfies predetermined
standards. Aspects like completeness, clarity and viability can all be covered by checklists.
Importance of Requirements Validation Techniques
1. Accuracy and Clarity
It makes sure that the requirements are precise, unambiguous and clear. This helps to avoid
miscommunications and misunderstandings that may result in mistakes and more effort in subsequent
phases of the project.
2. User Satisfaction
It confirms that the requirements meet the wants and expectations of the users, which helps to increase
user happiness. This aids in providing a product that satisfies consumer needs and improves user
experience as a whole.
3. Early Issue Identification
It makes it easier to find problems, ambiguities or conflicts in the requirements early on. It is more
economical to address these issues early in the development phase rather than later, when the project is
far along.
4. Prevents the Scope Creep
It ensures that the established requirements are well stated and recorded, which helps to prevent scope
creep. By establishing defined parameters for the project’s scope, requirements validation helps to lower
the possibility of uncontrollably changing course.
5. Improving Quality:
It enhances the software product’s overall quality. By detecting and resolving possible quality problems
early in the development life cycle, requirements validation contributes to the creation of a more durable
and dependable final product.
Advantages of Requirements Validation Techniques
1. Improved quality of the final product: By identifying and addressing requirements early on in the
development process, using validation techniques can improve the overall quality of the final
product.
2. Reduced development time and cost: By identifying and addressing requirements early on in the
development process, using validation techniques can reduce the likelihood of costly rework later on.
3. Increased user involvement: Involving users in the validation process can lead to increased user
buy-in and engagement in the project.
4. Improved communication: Using validation techniques can improve communication between
stakeholders and developers, by providing a clear and visual representation of the software
requirements.
5. Easy testing and validation: A prototype can be easily tested and validated, allowing stakeholders
to see how the final product will work and identify any issues early on in the development process.
6. Increased alignment with business goals: Using validation techniques can help to ensure that the
requirements align with the overall business goals and objectives of the organization.
7. Traceability: This technique can help to ensure that the requirements are being met and that any
changes are tracked and managed.
8. Agile methodologies: Agile methodologies provide an iterative approach to validate requirements
by delivering small chunks of functionality and getting feedback from the customer.
Disadvantages of Requirements Validation Techniques
1. Increased time and cost: Using validation techniques can be time-consuming and costly, especially
when involving multiple stakeholders.
2. Risk of conflicting requirements: Using validation techniques can lead to conflicting requirements,
which can make it difficult to prioritize and implement the requirements.
3. Risk of changing requirements: Requirements may change over time and it can be difficult to keep
up with the changes and ensure that the project is aligned with the updated requirements.
4. Misinterpretation and miscommunication: Misinterpretation and miscommunication can occur
when trying to understand the requirements.
5. Dependence on the tool: The team should be well-trained on the tool and its features to avoid
dependency on the tool and not on the requirement.
6. Limited validation: The validation techniques can only check the requirement that is captured and
may not identify the requirement that is missed
7. Limited to functional requirements: Some validation techniques are limited to functional
requirements and may not validate non-functional requirements.

System Modelling for Requirements Engineering

System modelling supports the analysis and design process by introducing a degree of formality into the way
systems are defined. During system development it is often the case that pictures are used to help visualize some
aspects of the development. Modelling provides a way of formalizing these representations, through diagrams, by
not only defining a standard syntax, but also providing a medium for understanding and communicating the ideas
associated with system development
During model-based documentation of requirements in requirements engineering, three types of requirements are
documented independently and used in conjunction:

 Goals describe intentions of stakeholders or groups of stakeholders. Goals can potentially conflict with one
another.
 Use cases and scenarios document exemplary sequences of system usage. Scenarios are grouped together in
use cases.
 System requirements (generally referred to as requirements) describe detailed functions and qualities that the
system to be developed shall implement or possess. In addition, system requirements provide complete and
precise information to serve as input for subsequent development steps
Model
A model is an abstract representation of an existing reality or a reality to be created.
Requirements Model:
Conceptual models that document the requirements of a system are called requirements models. The Unified
Modeling Language (UML) is frequently used to construct requirements models [OMG 2007]. UML has
developed into the quasi-standard for model-based construction of software systems. It consists of a set of
partially complementary modeling languages that are particularly used in requirements engineering to model
the requirements of a system from different perspectives. Extensive examples of modeling using UML can be
found in [Rupp et al. 2007], for instance.
Requirements models vs. design models
A considerable difference between the conventional use of conceptual models in system development and
model usage for requirements documentation is that conventional models document solutions chosen during
system development. Requirements models, on the other hand, depict specific aspects of the underlying
problem.

Representations for Requirements Engineering

1. Data Flow Diagrams:
 Data flow diagrams (DFDs) are the basis of most traditional modelling methods. They are the
minimalist graphical representation of the system structure and interfaces and although initially
produced for use in data representation and flow, the diagrams can in fact be used to show any type of
flow, whether a computer-based system or not. The one output which DFDs do not show is that of
control flow. The elements in a data flow diagram are
• data flows (labelled arrows);
• data transformations (circles or “bubbles”);
• data stores (horizontal parallel lines);
• external entities (rectangles).

2. Entity–Relationship Diagrams
Modelling the retained information in a system, for example flight plans, system knowledge and database records, is
often important. Entity–relationship diagrams (ERDs) provide a means of modelling the entities of interest and the
relationships that exist between them. Chen (1976) initially developed ERDs. There is now a very wide set of
alternative ERD notations.
An entity is an object that can be distinctly identified, such as customer, supplier, part, or product. A property (or
attribute) is information that describes the entity. A relationship has cardinality, which expresses the nature of the
association (one-to-one, one-to-many, many-to-many) between entities. A subtypeis a subset of another entity, i.e. a
type X is a subtype of Y if every member of X belongs to Y. ERDs define a partial model of the system by identifying
the entities within the system and the relationships between them. It is a model that is independent of the processing
which is required to generate or use the information. It is therefore an ideal tool to use for the abstract modelling work
required within the system requirements phase. Consider the example Ambulance C&C system in Figure
 3. Statecharts
Functionality and data flows are not enough for requirements definition. It is also necessary to be able to represent the
behaviour of the system and in some circumstances consider the system as having a finite number of possible “states”,
with external events acting as triggers that lead to transitions between the states. To represent these aspects, it is
necessary to examine what states the system can be in and how it responds to events in these states. One of the most
common ways of doing this is to use Harel’s statecharts (Harel, 1987). Statecharts are concerned with providing a
behavioural description of a system. They capture hierarchy within a single diagram form and also enable concurrency
to be depicted and therefore they can be effective in practical situations where parallelism is prevalent. A labelled box
with rounded corners denotes a state.
Hierarchy is represented by encapsulation and directed arcs, labelled with a description of the event, are used to
denote a transition between states. The descriptions of state, event and transition make statecharts suitable for
modelling complete systems
 4. Object-oriented Approaches
Object orientation provides a different approach from that of the structured analysis approach. Objects describe stable
(and hopefully) re-usable components.
Object orientation tries to maximize this re-usability by asking the systems engineer to pick persistent objects, i.e.
those that can be used in system requirements and design.
Object orientation focuses on the behaviour of objects and their interrelationships.

a. Class Diagrams
The class diagram is the basic diagramming notation from object-oriented analysis and design. Object
orientation arose out of computer-based simulation. The basic principle is that the contents of a software
system should model the real world. The natural way to handle this is to have objects in the software that
represent entities in the real world, in terms of both information and actions.
Class diagrams express information about classes of objects and their relationships.
For example, in a banking system, instead of having an accounts file and separate accounts programs, there
are accounts objects that have information such as balance and overdraft limit and relationships to other
objects such as account owner. These objects have operations (also called methods) to handle the actions that
are performed in accounts, such as check balance, deposit, withdraw.
 b. Use Cases
Use cases define the interaction that takes place between a user of a system (an actor) and the system itself.
They are represented as process bubbles in a DFD type of context diagram. The use case diagram contains the
actors and the use cases and shows the relationship between them. Each use case defines functional
requirements for the system. Actors do not need to be human, even though they are represented as stick
figures, but in fact represent roles. Each of the actors will have an association with at least one use case.

Methods
A method is a degree more prescriptive than a modelling approach – it tells us what to do to and in what order to do it.
Methods use various representations ranging from natural language, through diagrammatic forms to formal
mathematics. Methods indicate when and where to use such representations. Those methods that use diagrammatic
representations are usually referred to as “structural methods”; those that use object orientation are referred to as
“object-oriented methods” and those that use mathematics are referred to as “formal methods”.
The purpose of the representations used in a method is to capture information. The information capture is aided by
defining the set of concepts that a diagram represents, and the syntactic rules that govern the drawing of diagrams.

A. Viewpoint Methods
A viewpoint-based approach to requirements engineering recognizes that requirements should not be considered from
a single perspective. It is built on the premise that requirements should be collected and indeed organized from a
number of different viewpoints. Basically two different kinds of viewpoint have been proposed: • viewpoints
associated with stakeholders; • viewpoints associated with organizational and domain knowledge. The role of the
stakeholder is well understood in requirements engineering; however viewpoints associated with organization and
domain knowledge may be those associated with some aspect of security, marketing, database system, regulation,
standards, etc. Such viewpoints are not associated with a particular stakeholder, but will include information from a
range of sources.
i. Controlled Requirements Expression (CORE)
CORE was originally developed following work on requirements analysis carried out for the UK Ministry
of Defence. A key finding of this work was that methods often started by defining the context of a solution
 to a problem, rather than attempting to define the problem itself, before beginning to assess possible
solutions. CORE was specifically designed to address the latter approach. Figure 3.14 indicates the
concepts and representations used in CORE. The central concept of CORE is the viewpoint and the
associated representation known as the viewpoint hierarchy. A viewpoint can be a person, role or
organization that has a view about an intended system.
When used for system requirements, the viewpoints can also represent the intended system, its subsystems
and systems that exist within the environment of the system that may influence what the system must do.
The viewpoints are organized in a hierarchy to provide a scope and also to guide the analysis process.
Lines are drawn between adjacent columns to indicate the flows that take place. Once each viewpoint has
been analyzed in this way, the TCFs at each level in the viewpoint hierarchy are checked as a group to
ensure that the inputs which each viewpoint expects are generated by the source viewpoint and that the
outputs which each action generates are expected by the viewpoint(s) indicated as the destination(s) for
them.

ii. Structured Analysis and Design Technique (SADT)

SADT is a method of structured analysis, based on the work undertaken by Ross on structured analysis
(SA) in the 1970s (Ross, 1977). It is graphically oriented and adopts a purely hierarchical approach to the
problem with a succession of blueprints both modularizing and refining it until a solution is achieved. The
basic element of SADT is the box, which represents an activity (in activity diagrams) or data (in data
diagrams). The boxes are joined by arrows representing either the data needed or provided by the activity
represented by the box (in activity diagrams), or the process providing or using the data (in data
diagrams). There are four basic arrows associated with a box, as shown in Figure 3.17. The type of arrow
is implied by its point of connection to the box: • Input arrows enter the box from the left side, and
 represent data that is available to the activity represented by the box. • Output arrows exit the box from
the right side, and represent data that is produced by the activity represented by the box, i.e. the input data
has been transformed by the activity represented by the box to produce this output. • Control arrows enter
the box from the top and govern the way in which the transformation takes place. • Mechanism arrows
enter the box from below and control the way in which the activity may use outside mechanisms, e.g. a
specific algorithm or resources. An SADT diagram is made up of a number of boxes with the associated
set of arrows. A problem is refined by decomposing each box and generating a hierarchical diagram, as
shown in Figure 3.18. Figure 3.19 shows an example activity diagram for an ABCS. This decomposition
proceeds until there is sufficient detail for the design to proceed.

iii. Viewpoint-oriented Requirements Definition (VORD)

VORD (Kotonya and Sommerville, 1996) is a method based on viewpoints. The model used is a service-
oriented one, where the viewpoints are considered to be clients, if one was to think of it as a client–server
system. A viewpoint in VORD receives services from the system and in turn passes control information to
the system. The service-oriented approach makes VORD suited for specifying interactive systems.
There are two types of viewpoint in VORD – direct and indirect:
• Direct viewpoints receive services from the system and send control information and data to the system.
• Indirect viewpoints do not interact directly with the system but rather have an “interest” in some or all of
the services delivered by the system.
 B. Object-oriented Methods
The main players were object-oriented analysis (OOA), object modelling technique (OMT), Booch and Objectory.
Shlaer and Mellor’s method (Shlaer and Mellor, 1998) was also there, but would not have been regarded as a truly O-
O method. However, it did play an important role in assisting in the identification of objects.
i. OOA
OOA was developed by Coad and Yourdon (1991a). OOA is spread across three layers, as they are called. The first
layer is the subject layer, which is concerned with object identification. Here the users are able simply to represent
their understanding of the problem domain by identifying relevant problem domain objects. The second layer, called
the attributes layer, is concerned with identifying attributes (data elements) associated with problem domain objects.
The third and final layer is the services layer. This specifies the services (or operations) performed by each object. In
effect, OOA helps the systems engineer in identifying the requirements of a system, rather than how the software
should be structured or implemented. It therefore describes the existing system, its operation and how the software
system should interact with it.
ii. OMT
The OMT method was developed by Rumbaugh (Rumbaugh et al., 1991a, b). It aims to construct a series of object
models that refine the system design until the final model is suitable for implementation. The approach is achieved in
three phases. The analysis phase produces models of the problem domain. Three types of model are produced – the
object model, the dynamic model and the functional model. The object model is the first one to be built. It uses
notation similar to that used in OOA, which is based on the concept of ER modelling which describes the objects, their
classes and the relationships between the objects. The dynamic model represents the behaviour of the system and uses
an extension of Harel’s statecharts. The functional model describes how the system functions are performed through
the use of DFDs. These models are arrived at by using an iterative approach. The design phase then structures the
model and the implementation phase takes into account the appropriate target language constructs. In this way, OMT
covers not only the requirements capturing phase but also helps to inform the architectural design process.
iii. Booch
The Booch method (Booch, 1994) is one of the earliest O-O methods proposed. Although the method does consider
analysis, its strength lies in the contribution it makes to the design of an object-oriented system. The approach is both
incremental and iterative and the designer is encouraged to develop the system by looking at both logical and physical
views of the system. The method involves analyzing the problem domain to identify the set of classes and objects and
their relationships in the system. These are represented using a diagrammatic notation. The notation is extended
further when considering the implementation of classes and objects and the services they provide. The use of state
transition diagrams and timing diagrams is also an important part of this method.
iv. Objectory
Jacobsen proposed the Objectory method (Jacobsen et al., 1993). Many of its ideas are similar to those in other O-O
methods, but the fundamental aspect of this method is the scenario or use case, as described earlier in this chapter. The
system’s functionality should therefore be able to be described based on the set of use cases for a system – the use case
model. This model is then used to generate a domain object model, which can become an analysis model by
classifying the domain objects into three types: interface objects, entity objects and control objects. This analysis
model is then converted to a design model, which is expressed in terms of blocks, from which the system is
implemented.
v. The UML
The Unified Modelling Language (UML) (OMG, 2003) was an attempt to bring together three of the O-O approaches
which had gained greatest acceptance – Booch, OMT and Objectory. In the mid-1990s, Booch, Rumbaugh and
Jacobsen joined Rational to produce a single, common and widely usable modelling language. The emphasis was very
much on the production of a notation rather than a method or process. Since its inception, the UML has undergone
extensive development and changes with various versions being launched. UML 1.0 became a standard in 1997
following acceptance by the Object Management Group (OMG). Version 1.3 was released in 1999 and in 2003 the
UML 2.0 was released, which is the version used in this book. A discussion of the UML is provided in the following
section.

C. The UML Notation

The UML is made up of a number of models, which together describe the system under development. Each model
represents distinct phases of development and each will have a separate purpose. Each model is comprised of one or
more of the following diagrams, which are classified as follows:
• structure diagrams;
• behaviour diagrams;
• interaction diagrams.
The 13 diagrams of UML2 are shown in Figure 3.24 and represent all the diagrams which are available to the systems
engineer. In reality many will not be used and often only a small subset of the diagrams will be necessary to model a
system. Class diagrams, use case diagrams and sequence diagrams are probably the most frequently used. If dynamic
modelling is required, then activity diagrams and state machine diagrams should be used.
It is how the UML diagrams contribute to modelling which is of interest to us. The purpose of this section is not so
much to provide an overview of UML2, but rather to show how models can be used in various aspects of requirements
engineering.
Consider the banking example used earlier in this chapter. The class is the basic modelling diagram of the UML.
Figure 3.25 presents a UML class diagram extending the set of classes to include “Account”, “Owner”, “Current
Account” and “Issued Cheque” – used to model the system. As shown, each class has an associated set of attributes
and operations, i.e. the relationships (in this case, generalization and association) which exist between one or more
classes.
Use case modelling is used to describe the functional requirements of systems
The UML also provides diagrams to allow the systems engineer to model functionality and behaviour. A sequence
diagram shows the interaction and collaboration which exists between objects and thus can model complex behaviour.
It is depicted by messages which flow between objects over time.
 D. Formal Methods
Formal methods provide a more rigorous representation based on mathematics, and can be used to conduct
mathematical proofs of consistency of specification and correctness of implementation. Rigorous checking is possible,
which can eliminate some kinds of errors. This may be necessary in certain types of systems, for example, nuclear
power stations, weapons and aircraft control systems. Z (Spivey, 1989), VDM (Jones, 1986), LOTOS (Bjorner, 1987)
and B (Abrial, 1996) are the most common formal methods for formal definition of functionality. LOTOS (Language
of Temporal Ordering Specification), VDM (the Vienna Definition Language) and Z are formal methods standardized
by ISO. B and LOTOS models are executable, and B models can be refined into code. Formal methods are particularly
suitable for critical systems, i.e. those in which potential financial or human loss would be catastrophic, and the cost of
applying mathematically rigorous methods can be justified.

Formal methods are slowly becoming more important. If their scope can be broadened to address wider system issues,
they will become more useful.
i. Z – A Model-based Formal Method
Z is a formal specification notation based on first-order predicate logic and set theory. The notation allows data to be
represented as sets, mappings, tuples, relations, sequences and Cartesian products. There are also functions and
operation symbols for manipulating data of these types. Z specifications are presented in a small, easy to read boxed
notation called a “schema”. Schemas take the form of a signature part and a predicate part. The signature part is a list
of variable declarations and the predicate part consists of a single predicate. Naming a schema introduces a syntactic
equivalence between the name and the schema. The Z schema is illustrated in Figure 3.31. Specifications in Z are
presented as a collection of schemas where a schema introduces some specification entities and sets out the
relationships between them. They provide a framework within which a specification can be developed and presented
incrementally. Figure 3.32 shows a Z specification for the “issue” operation for a library, where the general behaviour
of the overall library system would be specified in a schema named “library”. The notation Library is called a delta
schema and indicates that the “issue” operation causes a state change to occur in the library.