ch1 3

Requirment Engineering
Wolkite university
College of Computing
Department of Software Engineering
Bekretsyon B.
March 22, 2019
Wolkite universityCollege of Computing Requirment

Department of
Engineering Bekretsyon
Software Engineering (March 22, 2019 B.
1 / 56
)
Introduction
Modern World and Software

I Its getting difficult to think the modern world without software.
I Infrastructures and Utilities
I Electrical Products
I Industrial Manufacturing processes and distribution
I Entertainment - [Music and Film industry, Games and Televisions]
I Therefore, software engineering is essential and play its core role
for the functioning of national and international societies.
I Software systems are abstract and intangible
I Types of Software Systems: from simple embedded systems to
complex, worldwide information systems

Department of
2 / 56
)
Terminologies and Concepts
Software
I Computer programs and associated documentation
Software Engineering:
I All aspects of software production from system specification
through to maintaining the system after it has gone into use
Software Engineering Process:

I A systematic approach to the production of a software system

Department of
3 / 56
)
Software Engineering Techniques and Methods:

I No universal notation, methods, and techniques for all software
development process.
I Software engineering fundamentals:
I Managed and understood development process: Plan the
development process, outputs and schedule
I Dependability and Performance: Behave as expected, without
failures, and should should perform efficiently
I Managing software specification and requirements: Manage their
expectations
I Re-usability: Effective use of existing resources

Department of
4 / 56
)
Software Engineering Challenges:
I General issues:
I Heterogeneity - Systems are to operate as distributed systems across
networks that include different types of computer and mobile
devices
I Business and Social Change - Business and society are changing
incredibly quickly as emerging economies develop and new
technologies became available
I Security and Trust - Make sure malicious users cannot attack the
software and maintained information security
I Complexity (useful systems are complex)
Complexity
I Why is software complex?
I The complexity of the problem domain
I The difficulty of managing the development process
I The flexibility possible through software (almost everything is
possible)
Department of Software Engineering (Bekretsyon
Engineering March 22, 2019 B.
5 / 56
)
Software Engineering Ethics

I As a software engineer, You
I Must accept that your job involves wider responsibilities than
technical skills
I Must have an ethical and normally responsible way if you are to be
respected as a professional engineer
I Should uphold normal standards of honesty and integrity
I Should not use your skills and abilities to behave in a dishonest way

Department of
6 / 56
)

I Requirement: Specifies what the customers wants, defines what
a system should do and the desirable qualities of that system
I Requirement Engineering: Determining the requirements,
analyzing, validating and managing them in a set of systematic
techniques
I Requirements Engineering Process:Determining the
requirements for a proposed system, well as any hardware and
performance constraints

Department of
7 / 56
)
Requirements Engineering
Why Requirements Matter?

Department of
8 / 56
)

I Requirements are the bridge between the real world and the
software systems

Department of
8 / 56
)

software systems
I Requirements are a translation of real world problems in the form
that can be converted to a software system

Department of
8 / 56
)

software systems
I requirements reflect the problems in real world in a way that can
be utilize by software engineers

Department of
8 / 56
)

software systems
I requirements reflect the problems in real world in a way that can
be utilize by software engineers
I The way the requirements of a system are handled is a significant
cause for project failures and/or time and budget over-runs

Department of
8 / 56
)
Why Requirements Engineering

Department of
9 / 56
)

I 30% and 20% of the software projects investigated in 1994 and
2006, respectively, failed

Department of
9 / 56
)

I Difficulties with requirements are the key root-cause of the
safety-related software errors

Department of
9 / 56
)

I Approximately 60% of all errors in system development projects
originate during the phase of REng.

Department of
9 / 56
)

I Incorrect/incomplete requirements can be interpreted by
developers in such a fashion that they subjectively sound or
subconsciously complete

Department of
9 / 56
)

I Errors are often discovered only in later project phases or once the
system has been deployed

Department of
9 / 56
)

I The later in the development project a defect in the requirements
is corrected, the higher are the costs associated with fixing it

Department of
9 / 56
)
Source of Requirements
I Stakeholders: - are people or organizations that (directly or
indirectly) influence the requirements of a system. Examples:
Users and Operators of the system, developers, architects,
customers, and testers
I Documents: - contain important information that can provide
requirements. Examples: universal documents, such as standards
and legal documents
I Existing Systems: - Systems in operation can be legacy or
predecessor systems as well as competing systems.
I Domain/Business areas: - Allows to identify requirements that
come from the application domain of the system that reflect the
characteristics of that domain

Department of
Engineering Bekretsyon 10
B./ 56
Software Engineering ( March 22, 2019)
Characteristics of Good Requirements
1 Each requirement is clear and unambiguous
2 Each requirement has a priority to indicate its importance
3 Each requirement may be implemented
4 Each requirement is testable
5 Each requirement is necessary
6 Any conflicts between the requirements are resolved
7 Each requirement is broken down as fully as possible
8 Each requirement is consistent with the project’s objectives
9 Each requirement is stated as a stakeholder need (i.e. premature
design/solution or implementation information is not included)
10 The user (business) requirements are traceable (in both directions)
throughout the development cycle
11 The requirements are complete and consistent
Department of
B./ 56
Characteristics of poor Requirements

1 High level of requirements creep during the project
2 Requirements changing regularly during the project
3 Missing requirements
4 Changes to the requirements are not controlled
5 Requirements accepted from any source
6 High level of rework during the project
7 Design, implementation and test products inconsistently interpret
the requirements
8 Deliverables are inconsistent with the requirements
9 Untestable requirements
10 Inability to demonstrate that the implementation satisfies the
requirements

Department of
B./ 56
Results of Poor Requirements

I The system may be delivered late and cost more than originally
expected
I The customer and end-users may not satisfied with the system
I They may not use its facilities or may even decide to scrap it
altogether
I The system may be unreliable in use with regular system errors
and crashes disrupting normal operation
I If the system continues in use, the costs of maintaining and
evolving the system are very high

Department of
B./ 56
Challenges in Requirements Engineering

I Stakeholders don’t know what they want from the new system
I Its very difficult to imagine how a future system might work
I Business operate in a rapidly changing environment so their
requirements for system support constantly changing
I Multiple stakeholders with different goals and priorities are
involved in the requirements engineering process
I System stakeholders don’t have clear ideas about what they need
I They can only describe their requirements in vague and ambiguous
way
I Requirements are often influenced by political and organizational
factors that stakeholders will not admit to publicly

Department of
B./ 56
I Why Requirements Matter?

Department of
B./ 56

software systems

Department of
B./ 56

software systems

Department of
B./ 56

software systems
I requirements reflect the problems in real world in a way that can be
utilize by software engineers

Department of
B./ 56

software systems
I requirements reflect the problems in real world in a way that can be
utilize by software engineers
I The way the requirements of a system are handled is a significant
cause for project failures and/or time and budget over-runs

Department of
B./ 56
I Why Requirements Engineering?

Department of
B./ 56


Department of
B./ 56


Department of
B./ 56


Department of
B./ 56

I Incorrect/incomplete requirements can be interpreted by developers
in such a fashion that they subjectively sound or subconsciously
complete

Department of
B./ 56

complete

Department of
B./ 56

complete
I The later in the development project a defect in the requirements is
corrected, the higher are the costs associated with fixing it

Department of
B./ 56
Source of Requirements
I Stakeholders: - are people or organizations that (directly or

indirectly) influence the requirements of a system. Examples:
Users and Operators of the system, developers, architects,
customers, and testers
I Documents: - contain important information that can provide
requirements. Examples: universal documents, such as standards
and legal documents
I Existing Systems: - Systems in operation can be legacy or
predecessor systems as well as competing systems.
I Domain/Business areas: - Allows to identify requirements that
come from the application domain of the system that reflect the
characteristics of that domain

Department of
B./ 56
Characteristics of Good Requirements
1 Each requirement is clear and unambiguous

2 Each requirement has a priority to indicate its importance
3 Each requirement may be implemented
4 Each requirement is testable
5 Each requirement is necessary
6 Any conflicts between the requirements are resolved
7 Each requirement is broken down as fully as possible
8 Each requirement is consistent with the project’s objectives
9 Each requirement is stated as a stakeholder need (i.e. premature
design/solution or implementation information is not included)
10 The user (business) requirements are traceable (in both directions)
throughout the development cycle
11 The requirements are complete and consistent

Department of
B./ 56
Characteristics of poor Requirements
1 High level of requirements creep during the project

2 Requirements changing regularly during the project
3 Missing requirements
4 Changes to the requirements are not controlled
5 Requirements accepted from any source
6 High level of rework during the project
7 Design, implementation and test products inconsistently interpret
the requirements
8 Deliverables are inconsistent with the requirements
9 Untestable requirements
10 Inability to demonstrate that the implementation satisfies the
requirements

Department of
B./ 56
Results of Poor Requirements
I The system may be delivered late and cost more than originally
expected
I The customer and end-users may not satisfied with the system
I They may not use its facilities or may even decide to scrap it
altogether
I The system may be unreliable in use with regular system errors
and crashes disrupting normal operation
I If the system continues in use, the costs of maintaining and
evolving the system are very high

Department of
B./ 56
Challenges in Requirements Engineering
I Stakeholders don’t know what they want from the new system
I Its very difficult to imagine how a future system might work
I Business operate in a rapidly changing environment so their
requirements for system support constantly changing
I Multiple stakeholders with different goals and priorities are
involved in the requirements engineering process
I System stakeholders don’t have clear ideas about what they need
I They can only describe their requirements in vague and ambiguous
way
I Requirements are often influenced by political and organizational
factors that stakeholders will not admit to publicly

Department of
B./ 56
Types of Requirements
Wolkite university
Bekretsyon B.
March 22, 2019
Wolkite universityCollege of Computing Types

Department
of Requirements Bekretsyon 22
B./ 56
of Software Engineering ( March 22, 2019)
Introduction
Requirements
I Requirements for a system are:
I Descriptions of the services that a system should provide and the
constraints on its operation
I Reflect the needs of customers for a system that serves a certain
purpose such as controlling a device
I A detailed, formal definition of a system function
I Problem in Requirements Engineering Process
I Failure to make a clear separation between different levels of
requirements description
I Levels of requirements description:
I Different types of readers use them in different ways
I User and System Requirements

Department
B./ 56
Introduction
User Requirements:
I Expected system services provided to system users
I Statements, in a natural language plus diagrams
I The constraints under which it must operate
System Requirements:
I More detailed descriptions of the software system’s functions,
services, and operational constraints
I Define exactly what is to be implemented
I May be part of the contract between the system buyer and the
software developers

Department
B./ 56
Introduction
Example
I User and System Requirements - [Mental health care patient
information system (Mentcare)]
I User Requirements Definition: The Mentcare system shall
generate monthly management reports showing the cost of drugs
prescribed by each clinic during that month.
I System Requirements Specification: On the last working day
of each month, a summary of the drugs prescribed, their cost and
the prescribing clinics shall be generated.

Department
B./ 56
Readers of requirements
Readers of user requirements

I They are not usually concerned with how the system will be
implemented
I They are not interested in the detailed facilities of the system
I Client Managers, System end-users, Client Engineers, Contractor
Managers and System architects.
Readers of system requirements:

I They need to know more precisely what the system will do
I They are concerned with how it will support the business processes
I They involved in the system implementation
I System end-users, Client engineers, System architects and
Software developers

Department
B./ 56
I Distinction between different types of requirements is not as clear

cut
I A user requirement concerned with security, such as a statement
limiting access to authorized users, may appear to be a
nonfunctional requirement.
I However, when developed in more detail, this requirement may
generate other requirements that are clearly functional, such as
the need to include user authentication facilities in the system.
I This shows that requirements are not independent and that one
requirement often generates or constrains other requirements.
I The system requirements therefore do not just specify the services
or the features of the system that are required; they also specify
the necessary functionality to ensure that these services/features
are delivered effectively.

Department
B./ 56

Department
B./ 56
Functional Requirements
I Requirements that describe what the system should do

Department
B./ 56
Non-functional requirements
I Requirements that define how the system should do it

Department
B./ 56
Domain Requirements
I Requirements that are derived from the application domain

Department
B./ 56
Domain Requirements
I Requirements that are derived from the application domain
Pseudo Requirements
I Requirements imposed by the client that restrict the
implementation of the system (e.g., language, platform)

Department
B./ 56
I Statements of services the system should provide
I Describe what the system should do
I Define how the system should react to particular inputs
I How the system should behave in particular situations
I In some cases, they may also explicitly state what the system
should not do
I These requirements depend on:
I The type of software being developed, the expected users of the
software, the general approach taken by the organization when
writing requirements
I Should be written in natural language - system users and
managers can understand them
I Written for system developers
I Describe the system functions, their inputs and outputs, and
exceptions in detail
I Vary from general requirements covering what the system should
do to very specific requirements
Department
B./ 56
I Examples - Mentcare system
I A user shall be able to search the appointments lists for all clinics.
I The system shall generate each day, for each clinic, a list of patients
who are expected to attend appointments that day.
I Each staff member using the system shall be uniquely identified by
his or her eight-digit employee number.
I Define specific functionality that should be included in the system
Information requirements
I Focus on the development and specification of the information
needed for people to do their work
I Specify the information needed and how it is to be delivered and
organized
I Example: Information requirement for the Mentcare system might
specify what information is to be included in the list of patients
expected for appointments that day
Department
B./ 56
I Should be both complete and consistent
CC
I Completeness: means that all services and information required by
the user should be defined
I Consistency: means that requirements should not be contradictory

Department
B./ 56
I Constraints on the services or functions offered by the system

I Requirements that are not directly concerned with the specific
services delivered by the system to its users
I Applied to the system as a whole rather than individual system
features or services
I Relate to emergent system properties such as reliability, response
time, and memory use
I They may define constraints on the system implementation, such
as data representations used in interfaces with other systems
I Example: include timing constraints, constraints on the
development process, and constraints imposed by standards
I Are often more critical than individual functional requirements
I Failing to meet these requirement can mean that the whole system
is unusable
Department
B./ 56
I Arise through user needs:

I Because of budget constraints
I Organizational policies
I The need for interoperability with other software or hardware
systems
I External factors such as safety regulations or privacy legislation
I Implementation of these requirements - Why?
I May affect the overall architecture of a system rather than the
individual components
I May generate several, related functional requirements that define
new system services
I May also generate requirements that constrain existing requirements

Department
B./ 56
Types of non-functional requirements

I Product Requirements: Specify or constrain the runtime
behavior of the software.
I Organizational requirements: Requirements derived from
policies and procedures in the customer’s and developer’s
organizations
I External requirements: Requirements that are derived from
factors external to the system and its development process. These
may include regulatory requirements that set out what must be
done for the system to be approved for use by a regulator.

Department
B./ 56
Common Problems with Non-functional Requirements

I Stakeholders propose requirements as general goals, such as ease of
use
I It is impossible to objectively verify the system goal
I Customers for a system often find it difficult to translate their
goals into measurable requirements
I Often conflict and interact with other functional or non-functional
requirements
I It is difficult to separate functional and non-functional
requirements in the requirements document

Department
B./ 56
Metrics for Specifying Non-functional

I Speed: Processed transactions/second, User/event response time
and Screen refresh time
I Size: Megabytes/Number of ROM chips
I Ease of use: Training time and Number of help frames
I Reliability: Mean time to failure, Probability of unavailability,
Rate of failure occurrence and Availability
I Robustness: Time to restart after failure, Percentage of events
causing failure and Probability of data corruption on failure
I Portability: Percentage of target dependent statements Number
of target systems

Department
B./ 56
Domain requirements
DR
I Derived from application domain of the system
I They are not the specific needs of system users
I Consists new functional requirements and constrain existing
functional requirements
I Set out how particular computation must be carried out
I Software engineers may not understand the characteristics
I Missing or conflicting requirements are another challenge
I Example: Application domain (e.g., website design and
implementation) and Technology domain (e.g., object-oriented
systems or aspect-oriented programming)

Department
B./ 56
Pseudo requirements
Pseudo requirements
I Imposed by the client or the environment in which the system is to
operate
I They are not implemented
I They are adhered to because they merely limit the solution space
available during the development process
I Example: The system shall be implemented using web services

Department
B./ 56
Requirements Engineering Processes
Wolkite university
Bekretsyon B.
March 22, 2019
Wolkite universityCollege of Computing

Requirements
Department
Engineering
of Software EngineeringBekretsyon 39
B./ 56
Processes ( March 22, 2019)
Introduction
I Software is created in a step-by-step manner, considers

beginning-to-end software development
I But it frequently is necessary to backtrack and repeat the
procedures
I There might be cycles in software engineering that change the
order in which the steps occur or cause steps to be repeated
Steps in SE process Include

I Requirements analysis, Functional specification, Architecture
development, design and implementation,testing, deployment and
maintenance. .
I Software development models mix these steps
I All software development models incorporate these procedures

Requirements
Department
Engineering
B./ 56
Introduction
Software processes
I A structured set of activities required to develop a software system
I Software processes are complex and rely on people decisions
making and judgments.
I Consequently, no universally applicable software process.
I Process used in different companies depends on
I Type of software being developed
I The Requirements of software customer, and
I Skills of the people writing the software.
I For safety-critical systems, a very structured development process
is required where detailed records are maintained.
I For business systems, with rapidly changing requirements, a more
flexible, agile process is likely to be better.

Requirements
Department
Engineering
B./ 56
Introduction
I There are many different software processes but all involve five
fundamental SE activities:
I Specification-Defining what the system should do and constraints
on its operation.
I Development-Software to meet the specification must be
produced.
I Validation-Checking that it does what the customer wants.
I Evolution-Software must evolve to meet changing customer needs.
I When we describe and discuss processes, it’s about

I Activities in these processes, such as Data model, Designing a user
interface and , Ordering of these activities.
I What people do to develop software
I Describing who is involved, what is produced, and conditions that
influence the sequence of activities

Requirements
Department
Engineering
B./ 56
Introduction
I Process descriptions may also include:

I Products or deliverables: outcomes of a process activity.
I For example, the outcome of the activity of architectural design
may be a model of the software architecture.
I Roles: Responsibilities of the people involved in the process.
I Examples of roles are project manager, configuration manager, and
programmer.
I Pre- and post-conditions: are statements that are true before
and after a process activity has been enacted or a product produced.

Requirements
Department
Engineering
B./ 56
Software Process Model
Software process model

I Simplified representation of a software process.
I Each process model represents a
I Process from a particular perspective and Only provides partial
information about that process.
I For example
I Process activity model shows the activities and their sequence but
may not show the roles of the people involved in these activities.
I Are abstract descriptions of software processes used to explain
different approaches to software development.
I Common Process Models include

Requirements
Department
Engineering
B./ 56
Software Process Models
Waterfall Model:
I Represent development process activities as a separate phases
I Difficulty to accommodate changes after process is underway

Requirements
Department
Engineering
B./ 56
Incremental Development:
I Interleaves software development process activities
I Develop a series of versions (increments)
I Each version adding functionality to the previous version
Integration and Configuration:

I Relies on the availability of reusable components or systems.
I System development process focuses on configuring components
for use in a new setting and integrating them into a system.
Requirements
Department
Engineering
B./ 56
Spiral Development:
I Extends waterfall model by adding iteration
I Identify and solve sub-problems with the highest risk
I Process is represented as a spiral
I No fixed phases such as specification or design loops

Requirements
Department
Engineering
B./ 56
Software Process Models
Rational Unified Process:
I The best known universal software development model
I Developed by Rational, a U.S. SE company
I Encapsulates seven best practices within the model:
I Develop software iteratively using risk management
I Manage requirements
I Employ a component-based architecture
I Use visual models
I Verify quality continuously
I Control change and Use customization
Phases of RUP
I Inception: where a business case for the system is established;
I Elaboration: where requirements and architecture are developed;
I Construction: where the software is implemented; and
I Transition: where the system is deployed.
Requirements
Department
Engineering
B./ 56
Requirements Engineering Process
Requirements engineering
I Understanding and defining what services are required from the
system and Identifying constraints on the system’s operation and
development.
I RE is critical stage of software process, as mistakes made at this
stage inevitably lead to later problems in the system design and
implementation.
RE Process
I presents the requirements and demand management’s
methodology for performing RE best practices,
I Details project requirements engineering activities, and provides an
operational definition of the major components of the RE process.
I Aims to produce an agreed requirements document

Requirements
Department
Engineering
B./ 56
Requirements Engineering Process Activities
I The processes used for RE vary widely depending on the

application domain, the people involved and the organization
developing the requirements.
I However, there are a number of generic activities common to all
processes
I 5 important activities:
I Feasibility study
I Requirements elicitation and analysis
I Requirements documentation
I Requirements validation
I Requirements management
I However, in practice, requirements engineering is an iterative
process in which the activities are interleaved.

Requirements
Department
Engineering
B./ 56

Requirements
Department
Engineering
B./ 56
Requirements elicitation and analysis
I Deriving system requirements through
I Observation of existing systems, discussions with potential users
and procurers, task analysis, and so on.
I Involve development of system models and prototypes to
understand the system to be specified.
I Help you understand the system to be specified
Requirements specification
I Activity translating the information gathered during requirements
analysis into a document that defines a set of requirements.
I Two types of requirements may be included in this document.
I User requirements:Abstract statements of the system requirements
for customers and end-user of the system;
I System requirements:A more detailed description of the
functionality to be provided
Requirements
Department
Engineering
B./ 56
Requirements validation
I Checks the requirements for realism, consistency, and
completeness.
I Errors document are inevitably discovered. It must then be
modified to correct these problems.
Iterative process around a spiral

I The amount of time and effort devoted to each activity in an
iteration depends on:
I The stage of the overall process
I The type of system being developed, and
I The budget that is available
I Early in the process, most effort will be spent on understanding
high-level business and non-fun req, and User req
I Later in the process, more effort will be devoted to eliciting and
understanding the non-fun req and system req
Requirements
Department
Engineering
B./ 56

Requirements
Department
Engineering
B./ 56
Deliverables of Requirements Engineering Process
Feasibility studies
I Performed before the requirements engineering process starts
I Used to assess whether or not there is a need or a market for the
software
I Define whether or not it is technically and financially realistic to
develop the software required
I Short-term, cheap studies that inform the decision of whether or
not to go ahead with a more detailed analysis
Aims of RE process
I An agreed requirements document that specifies a system
satisfying stakeholder requirements
I User and System requirement documents
I Checklists
I Documents- [Requirements including Business]
Requirements
Department
Engineering
B./ 56
Thank You...!!!!

Requirements
Department
Engineering
B./ 56

ch1 3

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ch1 3

Uploaded by

Copyright:

Available Formats

Requirment Engineering

March 22, 2019

Wolkite universityCollege of Computing Requirment

Modern World and Software

Wolkite universityCollege of Computing Requirment

Software Engineering Process:

Wolkite universityCollege of Computing Requirment

Software Engineering Techniques and Methods:

Wolkite universityCollege of Computing Requirment

Software Engineering Ethics

Wolkite universityCollege of Computing Requirment

Terminologies and Concepts

Wolkite universityCollege of Computing Requirment

Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

Why Requirements Engineering

Wolkite universityCollege of Computing Requirment

Why Requirements Engineering

Wolkite universityCollege of Computing Requirment

Why Requirements Engineering

Wolkite universityCollege of Computing Requirment

Why Requirements Engineering

Wolkite universityCollege of Computing Requirment

Why Requirements Engineering

Wolkite universityCollege of Computing Requirment

Why Requirements Engineering

Wolkite universityCollege of Computing Requirment

Why Requirements Engineering

Wolkite universityCollege of Computing Requirment

Wolkite universityCollege of Computing Requirment

Characteristics of poor Requirements

Wolkite universityCollege of Computing Requirment

Results of Poor Requirements

Wolkite universityCollege of Computing Requirment

Challenges in Requirements Engineering

Wolkite universityCollege of Computing Requirment

I Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

I Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

I Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

I Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

I Why Requirements Matter?

Wolkite universityCollege of Computing Requirment

I Why Requirements Engineering?

Wolkite universityCollege of Computing Requirment

I Why Requirements Engineering?

Wolkite universityCollege of Computing Requirment

I Why Requirements Engineering?

Wolkite universityCollege of Computing Requirment

I Why Requirements Engineering?

Wolkite universityCollege of Computing Requirment