UNIT II

Software Requirements:
Functional and non-functional requirements, User
requirements, System requirements, Interface specification,
the software requirements document.

Requirements engineering process:

Feasibility studies, Requirements elicitation and analysis,
Requirements validation, Requirements management.

SOFTWARE REQUIREMENTS

Software requirements are necessary

• To introduce the concepts of user and system requirements
• To describe functional and non-functional requirements
• To explain how software requirements may be organized in a requirements
document What is a requirement?
• The requirements for the system are the description of the services provided
by the system and its operational constraints
• It may range from a high-level abstract statement of a service or of a system
constraint to a detailed mathematical functional specification.
• This is inevitable as requirements may serve a dual function
1. May be the basis for a bid for a contract - therefore must be open to
interpretation;
2. May be the basis for the contract itself - therefore must be defined in
detail; Both these statements may be called requirements
Requirements Engineering:
• The process of finding out, analysing documenting and checking these
services and constraints is called requirement engineering.
• The process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed.
• The requirements themselves are the descriptions of the system services and
constraints that are generated during the requirements engineering process.

Requirements abstraction:
• If a company wishes to let a contract for a large software development
project, it must define its needs in a sufficiently abstract way that a
solution is not pre-defined.
• The requirements must be written so that several contractors can bid for
the contract, offering, perhaps, different ways of meeting the client
organisation’s needs.
• Once a contract has been awarded, the contractor must write a system
definition for the client in more detail so that the client understands and
can validate what the software will do.
• Both of these documents may be called the requirements document for
the system.”

Types of requirements:
• User requirements
1. Statements in natural language plus diagrams of the services the system
provides and its operational constraints.
2. Written for customers.
• System requirements
1. A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints.
 2. Defines what should be implemented so may be part of a contract
between client and contractor.

Definitions and specifications:

User Requirement Definition:
The software must provide the means of representing and accessing external
files created by other tools.
System Requirement specification:
• The user should be provided with facilities to define the type of external files.
• Each external file type may have an associated tool which may be applied to
the file.
• Each external file type may be represented as a specific icon on the user’s
display.
• Facilities should be provided for the icon representing an external file type to
be defined by the user.
• When a user selects an icon representing an external file, the effect of that
selection is to apply the tool associated with the type of the external file to the
file represented by the selected icon.
 Functional and non-functional requirements

Functional requirements
• Statements of services the system should provide how the system should react
to particular inputs and how the system should behave in particular situations
Non-functional requirements
• Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
Domain requirements
• Requirements that come from the application domain of the system and that
reflect characteristics of that domain.

FUNCTIONAL REQUIREMENTS
• Describe functionality or system services.
• Depend on the type of software, expected users and the type of system where
the software is used.
• Functional user requirements may be high-level statements of what the system
should do but functional system requirements should describe the system
services in detail.
The functional requirements for The LIBSYS system:
• A library system that provides a single interface to a number of databases of
articles indifferent libraries.
• Examples of functional requirements
Users can search for, download and print these articles for personal study.
• The user shall be able to search either all of the initial set of databases or
select a subset from it.
• The system shall provide appropriate viewers for the user to read documents
in the document store.
• Every order shall be allocated a unique identifier (ORDER_ID) which the user
shall be able to copy to the account’s permanent storage area.

Requirements imprecision
• Problems arise when requirements are not precisely stated.
• Ambiguous requirements may be interpreted in different ways by developers
and users.
• Consider the term ‘appropriate viewers’
1. User intention - special purpose viewer for each different document type;
2. Developer interpretation - Provide a text viewer that shows the contents
of the document.
Requirements completeness and consistency:
In principle, requirements should be both complete and consistent. Complete
• They should include descriptions of all facilities required. Consistent
• There should be no conflicts or contradictions in the descriptions of the
system facilities. In practice, it is impossible to produce a complete and
consistent requirements document.

Examples of Functional Requirements:

1. User Authentication:
o The system must allow users to log in using a username and
password.
o After successful login, the user should be redirected to the
homepage.
2. Search Functionality:
o The system should allow users to search for products by entering
keywords in the search bar.
o The search results should display relevant products sorted by
relevance.
 3. Order Processing:
o The system must allow users to place an order by selecting items,
adding them to the shopping cart, and completing the checkout
process.
o The system should send email confirmation after order is placed

NON-FUNCTIONAL REQUIREMENTS
• These define system properties and constraints e.g. reliability, response
time and storage requirements.
• Constraints are I/O device capability, system representations, etc.
• Process requirements may also be specified mandating a particular CASE
system, programming language or development method.
• Non-functional requirements may be more critical than functional
requirements. If these are not met, the system is useless.

Examples of Non-Functional Requirements:

1. Performance:
o The system should be able to handle 500 concurrent users without
degrading performance.
o Page load time should be under 3 seconds.
2. Scalability:
o The system should be able to scale horizontally to accommodate an
increase in traffic during peak times (e.g., holiday shopping
seasons).
1.2) Non-functional requirement types:

Non-functional requirements:
Product requirements
• Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
E.g.: The user interface for LIBSYS shall be implemented as simple HTML
without frames or Java applets.
Organizational requirements
• Requirements which are a consequence of organizational policies and
procedures.
process standards used, implementation requirements, etc.
• E.g.: The system development process and deliverable documents shall
conform to the process and deliverables defined in XYZCo-SP-STAN-95.
External requirements
• Requirements which arise from factors which are external to the system and
its development process e.g. interoperability requirements, legislative
requirements, etc.
• E.g.: The system shall not disclose any personal information about customers
apart from their name and reference number to the operators of the system.

Goals and requirements:

• Non-functional requirements may be very difficult to state precisely and
imprecise requirements may be difficult to verify.
• Goal –
A general intention of the user such as ease of use.
The system should be easy to use by experienced controllers and should be
organized in such a way that user errors are minimized.
• Verifiable non-functional requirement
- A statement using some measure that can be objectively tested.
- Experienced controllers shall be able to use all the system functions after a
total of two hours training.
After this training, the average number of errors made by experienced users
shall not exceed two per day.
• Goals are helpful to developers as they convey the intentions of the system
users.

Requirements interaction:
• Conflicts between different non-functional requirements are common in
complex systems.
• Spacecraft system
1. To minimize weight, the number of separate chips in the system should
be minimized.
2. To minimize power consumption, lower power chips should be used.
 • However, using low power chips may mean that more chips have to be
used. Which is the most critical requirement?
• A common problem with non-functional requirements is that they can be
difficult to verify.
• Users or customers often state these requirements as general goals such as
ease of use, the ability of the system to recover from failure or rapid user
response.
• These vague goals cause problems for system developers as they leave
scope for interpretation and subsequent dispute once the system is
delivered.

DOMAIN REQUIREMENTS
• Derived from the application domain and describe system characteristics and
features that reflect the domain.
• Domain requirements be new functional requirements, constraints on existing
requirements or define specific computations.
• If domain requirements are not satisfied, the system may be unworkable.

USER REQUIREMENTS
• Should describe functional and non-functional requirements in such a way that
they are understandable by system users who don’t have detailed technical
knowledge.
• User requirements are defined using natural language, tables and diagrams as
these can be understood by all users.
Problems with natural language
Lack of clarity
• Precision is difficult without making the document difficult to read.
Requirements confusion
• Functional and non-functional requirements tend to be mixed-up.
Requirements amalgamation
• Several different requirements may be expressed together.
Requirement problems
Database requirements includes both conceptual and detailed information
• Describes the concept of a financial accounting system that is to be included in
LIBSYS;
• However, it also includes the detail that managers can configure this system -
this is unnecessary at this level.

Grid requirement mixes three different kinds of requirement

• Conceptual functional requirement (the need for a grid);
• Non-functional requirement (grid units);
• Non-functional UI requirement (grid switching).
• Structured presentation

Guidelines for writing requirements

• Invent a standard format and use it for all requirements.
• Use language in a consistent way. Use shall for mandatory requirements,
should for desirable requirements.
• Use text highlighting to identify key parts of the requirement.
• Avoid the use of computer jargon

SYSTEM REQUIREMENTS
More detailed specifications of system functions, services and constraints than
user requirements.
• They are intended to be a basis for designing the system.
• They may be incorporated into the system contract.
• System requirements may be defined or illustrated using system models
Requirements and design
Requirements should state what the system should do and the design should
describe how it does this.
In practice, requirements and design are inseparable
• A system architecture may be designed to structure the requirements
• The system may inter-operate with other systems that generate design
requirements
• The use of a specific design may be a domain requirement.

Problems with NL (natural language) specification

1. Ambiguity
• The readers and writers of the requirement must interpret the same words in
the same way. NL is naturally ambiguous so this is very difficult.
2. Over-flexibility
• The same thing may be said in a number of different ways in the specification.
3. Lack of modularization.
• NL structures are inadequate to structure system requirements.

4) INTERFACE SPECIFICATION
• Most systems must operate with other systems and the operating interfaces
must be specified as part of the requirements.
• Three types of interfaces may have to be defined
• Procedural interfaces where existing programs or sub-systems offer a range of
services that are accessed by calling interface procedures. These interfaces are
sometimes called Application Programming Interfaces (APIs)
• Data structures that are exchanged that are passed from one sub-system to
another. Graphical data models are the best notations for this type of description
• Data representations that have been established for an existing sub-system
• Formal notations are an effective technique for interface specification
THE SOFTWARE REQUIREMENTS DOCUMENT
• The requirements document is the official statement of what is required of the
system developers.
• Should include both a definition of user requirements and a specification of
the system requirements.
• It is NOT a design document. As far as possible, it should set of WHAT the
system should do rather than HOW it should do it

IEEE requirements standard defines a generic structure for a requirements

document that must be instantiated for each specific system.
1. Introduction.
• Purpose of the requirements document
• Scope of the project
• Definitions, acronyms and abbreviations
• References
• Overview of the remainder of the document
2. General description.
• Product perspective
• Product functions
• User characteristics
• General constraints
• Assumptions and dependencies
3. Specific requirements cover functional, non-functional and interface
requirements. The requirements may document external interfaces, describe
system functionality and performance, specify logical database requirements,
design constraints, emergent system properties and quality characteristics.
4. Appendices.
5. Index.

Main Elements of System Requirements Document

1) Constraints and Assumption

• The constraints and assumption section will underline the lack of any
design imposed by the client on the system design, resulting in removing
some options from being considered by the developers.
• This section also comprises assumptions which are made by the team of
requirement engineering at the time of requirements gathering and
analysis.
• If there is an incorrect assumption, it is needed to re-evaluate the system
requirements specification in order to ensure that the documented
requirements are still valid.

2) Functional and System Requirements

• This segment normally comprises a hierarchical arrangement of

requirements, with the functional/business requirements at the uppermost
level and the detailed system requirements are listed as their child items.
• Mostly in the form of statements, the requirements are written like
"System requires the capability to do x," with supporting information
comprised as required.
3) Technical Requirements

• This part is utilized to list any of the non-functional requirements, which

basically personifies the technical environment that the product requires
to work in and incorporate the technical limitations that it requires to
work under.
• These technical requirements are important in deciding how high-level
functional requirements can decompose into more definite system
requirements.

4) Business Drivers

• This part depicts the reasons why the client is hoping to build the system.
• The new system's rationale is significant because it will manage the
choices made by business experts, engineers, and system architects.
• Documentation that absolutely recognizes the business explanations for
the system will help to continue support the project if the original sponsor
proceeds onward.
• The drivers may comprise issues as well as opportunities. Generally, a
mix of issues and opportunities are required to give inspiration to a new
system.

5) System Qualities

• The system qualities are the non-functional requirements which are used
to define the system's quality.
• These qualities are frequently known as "ilities," and the reason behind that
is many of these qualities end with "ility".
• They are comprised of items like availability, maintainability, security,
reliability, and scalability.
• Unlike functional requirements, the quality of the system generally
contains tables of particular metrics that the system should meet to be
acknowledged.

6) Business Models

• This part portrays the fundamental business model of the client that the
system will require to support.
• This contains current-state, future-state and organizational context state
diagrams, key business functions, business context and process flow
diagrams.
• This part is generally made during the functional analysis phase.

7) Acceptance Criteria

• This part will portray the measures by which the client will "sign-off" the
final system.
• Based on the procedure, this may occur toward the end of the testing and
quality assurance stage, or in agile methodology, toward the finish of every
iteration.
• Usually, this measure refers to the requirement in order to complete all user
acceptance tests and fix all bugs/defects which meet a pre-defined priority
or severity limits.
 8) Business and System Use Cases
• This segment ordinarily comprises a UML use case diagram, which
shows the main external entities that will collaborate with the system
along with diverse use cases that should be met.
• There will be a formal definition of the steps for every use case which is
required to fulfil the purpose of the business, along with the essential pre-
conditions and post-conditions.

Characteristics of a Good System Requirements Document

There are various characteristics of good system requirements:
1. Completeness
2. Correctness
3. Modifiability
4. Consistency
5. Testability
6. Design independence
7. Understandable by the customer
8. Traceability
9. Verifiability
10.Unambiguousness
 1. Completeness
The completeness of the system requirements specification or system
requirements document shows each meaning of completion, together with the
number of pages, that properly covers all the functional and non-functional
requirements as well as resolving parts to the extent possible.
2. Correctness
The reviews of the users are used to make sure the accuracy of the requirements
states in the system requirements document. The system requirements document
is called true if it contains all the requirements which are really anticipated from
the system.
3. Modifiability
The system requirements document should be modified as well as able to adapt
changes to the system. Modifications must be appropriately indexed and cross-
referenced.
4. Consistency
In the system requirements document, requirements are called consistent if in
between any requirements, there is no conflict. Examples of conflicts: logical
conflicts such as time period of the report generation, terminologies which are
used at separate places, etc.
5. Testability
A system requirement document must be written in a manner which is simple to
create test plans and test cases from the document.
6. Design Independence
For the final system, it must be an option to select from the different design
alternatives. In particular, the system requirement document should not include
any details regarding implementation.
7. Understandable by the Customer
An end-user possibly a specialist in his/her particular domain; however
probably won't be a specialist in computer science. Thus, the utilization of
formal notations and symbols must be avoided as much as possible. It is must
that the language should be simple and clear.
 8. Traceability
One must be capable to design a component in a program and then to detect a
requirement for a code fragment. Similarly, one needs to be able to detect the
need for related test cases.
9. Verifiability
A system requirements document is validated if, in the system requirements
document, a particular technique is present in order to quantifiably measure the
degree to which the system meets each requirement. For instance, a requirement
expressing that the system should be easy to use isn't verifiable and listing such
requirements must be dodged.
10. Unambiguousness
If each requirement in the system requirements document has only a single
interpretation, then the system requirement document is unambiguous. If we
want to avoid unambiguousness, we have to use some modeling techniques such
as proper reviews, ER diagrams, buddy checks, etc.

REQUIREMENTS ENGINEERING PROCESSES

1. The goal of requirements engineering process is to create and maintain a
system requirements document.
2. The overall process includes four high-level requirement engineering sub-
processes. These are concerned with
• Assessing whether the system is useful to the business
• Discovering requirements
• Converting these requirements into some standard form
• Checking that the requirements actually define the system that the
customer wants the process of managing the changes in the requirements
is called requirement management.
The requirements engineering process

Requirements engineering:
• The requirements engineering process presents the process as a three-
stage activity where the activities are organized as an iterative process
around a spiral.
• The amount of time and effort devoted to each activity in iteration
depends on the stage of the overall process and the type of system being
developed.
• Early in the process, most effort will be spent on understanding high-level
business and nonfunctional requirements and the user requirements.
• Later in the process, in the outer rings of the spiral, more effort will be
devoted to system requirements engineering and system modeling.
• Some people consider requirements engineering to be the process of
applying a structured analysis method such as object-oriented analysis.
This involves analysing the system and developing a set of graphical
system models, such as use-case models, that then serve as a system
specification.
Stages in Software Engineering Process
Requirements engineering is a critical process in software engineering that
involves identifying, analysing, 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.
1) FEASIBILITY STUDIES
• A feasibility study decides whether or not the proposed system is
worthwhile.
• 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 results of the feasibility study should be a report that recommends
whether or not it worth carrying on with the requirements engineering
and system development process.
A short-focused study that checks
– If the system contributes to organizational objectives;
– If the system can be engineered using current technology and within
budget;
– If the system can be integrated with other systems that are used.
The feasibility study mainly concentrates on below five mentioned areas
below.
1. Technical Feasibility: In Technical Feasibility current resources
both hardware software along required technology is
analyzed/assessed to develop the project. This technical feasibility
study reports whether there are correct required resources and
technologies that will be used for project development.

2. Operational Feasibility: In Operational Feasibility degree of

providing service to requirements is analysed along with how easy
the product will be to operate and maintain after deployment.

3. Economic Feasibility: In the Economic Feasibility study cost and

benefit of the project are analyzed. This means under this
feasibility study a detailed analysis is carried out will be cost of the
project for development which includes all required costs for final
development hardware and software resources required, design and
development costs operational costs

4. Legal Feasibility: In legal feasibility, the project is ensured to

comply with all relevant laws, regulations, and standards.

5. Schedule Feasibility: In schedule feasibility, the project timeline is

evaluated to determine if it is realistic and achievable. Significant
milestones are identified, and deadlines are established to track
progress effectively.

Feasibility study implementation:

• A feasibility study involves information assessment, information collection
and report writing.
• Questions for people in the organization
– What if the system wasn’t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed system?
• In a feasibility study, you may consult information sources such as the
managers of the departments where the system will be used, software
engineers who are familiar with the type of system that is proposed,
technology experts and end-users of the system.
• They should try to complete a feasibility study in two or three weeks.
• Once you have the information, you write the feasibility study report.
• You should make a recommendation about whether or not the system
development should continue.
• In the report, you may propose changes to the scope, budget and
schedule of the system and suggest further high-level requirements for
the system.

2) REQUIREMENT ELICITATION AND ANALYSIS

The requirement engineering process is requirements elicitation and

analysis.
• Sometimes called requirements elicitation or requirements discovery.
• Involves technical staff working with customers to find out about the
application domain, the services that the system should provide and the
system’s operational constraints.
• May involve end-users, managers, engineers involved in maintenance,
domain experts, trade unions, etc. These are called stakeholders.

Problems of requirements analysis

• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may influence the system
requirements.
• The requirements change during the analysis process. New stakeholders
may emerge and the business environment change.
Process activities
1. Requirements discovery –
Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
2. Requirements classification and organization –
Groups related requirements and organizes them into coherent
clusters.
3. Prioritization and negotiation –
Prioritizing requirements and resolving requirements conflicts.
4. Requirements documentation –
Requirements are documented and input into the next round of the
spiral.

• The process cycle starts with requirements discovery and ends

with requirements documentation.
• The analyst’s understanding of the requirements improves with
each round of the cycle.
 • Requirements classification and organization is primarily
concerned with identifying overlapping requirements from
different stakeholders and grouping related requirements.
• The most common way of grouping requirements is to use a
model of the system architecture to identify subsystems and to
associate requirements with each sub-system.
• stakeholders have different views on the importance and priority
of requirements, and sometimes these view conflict.
• In the requirement documenting stage, the requirements that
have been elicited are documented in such a way that they can
be used to help with further requirements discovery.
Use cases
• Use-cases are a scenario-based technique in the UML which identify the
actors in an interaction and which describe the interaction itself.
• A set of use cases should describe all possible interactions with the system.
• Sequence diagrams may be used to add detail to use-cases by showing the
sequence of event processing in the system.

REQUIREMENTS DISCOVERY:
• Requirement discovery is the process of gathering information about the
proposed and existing systems and distilling the user and system requirements
from this information.
• Sources of information include documentation, system stakeholders and the
specifications of similar systems.
• They interact with stakeholders through interview and observation and may
use scenarios and prototypes to help with the requirements discovery

For example,
system stakeholder for a bank ATM includes
1. Bank customers
2. Representatives of other banks
3. Bank managers
4. Counter staff
5. Database administrators
6. Security managers
7. Marketing department
8. Hardware and software maintenance engineers
9. Banking regulators

REQUIREMENTS VALIDATION
• Concerned with demonstrating that the requirements define the system that
the customer really wants.
• Requirements error costs are high so validation is very important – Fixing a
requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error.
Requirements checking:
• Validity: Does the system provide the functions which best support the
customer’s needs?
• Consistency: Are there any requirements conflicts?
• Completeness: Are all functions required by the customer included?
• Realism: Can the requirements be implemented given available budget and
technology
• Verifiability: Can the requirements be checked?

Review checks:
• Verifiability: Is the requirement realistically testable?
• Comprehensibility: Is the requirement properly understood?
• Traceability: Is the origin of the requirement clearly stated?
• Adaptability: Can the requirement be changed without a large impact on other
requirements?
REQUIREMENTS MANAGEMENT
• Requirements management is the process of managing changing requirements
during the requirements engineering process and system development.
• Requirements are inevitably incomplete and inconsistent-
– New requirements emerge during the process as business needs change and a
better understanding of the system is developed;
– Different viewpoints have different requirements and these are often
contradictory.

Several key activities 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 promptly.
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.
Tools Involved in Requirement Engineering
• Observation report
• Questionnaire (survey, poll)
• Use cases
• User stories
• Mind mapping
• Roleplaying
• Prototyping

Requirements change
• The priority of requirements from different viewpoints changes during the
development process.
• System customers may specify requirements from a business perspective that
conflict with end-user requirements.
• The business and technical environment of the system changes during its
development.

Fig-Requirements evolution
Requirements management planning:
• During the requirements engineering process, you have to plan: –
✓ Requirements identification –
How requirements are individually identified
 ✓ A change management process
The process followed when analysing requirements change
✓ Traceability policies
The amount of information about requirements relationships that is maintained
✓ CASE tool support
The tool support required to help manage requirements change;

CASE tool support:

• Requirements storage – Requirements should be managed in a secure,
managed data store.
• Change management – The process of change management is a workflow
process whose stages can be defined and information flow between these stages
partially automated.
• Traceability management – Automated retrieval of the links between
requirements.

Requirements change management:

• Should apply to all proposed changes to the requirements.
• Principal stages-
✓ Problem analysis. Discuss requirements problem and propose change;
✓ Change analysis and costing. Assess effects of change on other
requirements;
✓ Change implementation. Modify requirements document and other
documents to reflect change.

Model types
Data processing model shows how the data is processed at different stages.
• Composition model shows how entities are composed of other entities.
• Architectural model showing principal sub-systems.
• Classification model shows how entities have common characteristics.
• Stimulus/response model showing the system’s reaction to events.

1. CONTEXT MODELS:
•Context models are used to illustrate the operational context of a system - they
show what lies outside the system boundaries.
•Social and organisational concerns may affect the decision on where to
position system boundaries.
• Architectural models show the system and its relationship with other systems.

Process models:
• Process models show the overall process and the processes that are supported
by the system.
• Data flow models may be used to show the processes and the flow of
information from one process to another.

2. BEHAVIOURAL MODELS:
• Behavioural models are used to describe the overall behaviour of a
system.
• These models show different perspectives so both of them are
required to describe the system’s behaviour
 • Two types of behavioural model are:
✓ Data processing models that show how data is processed as
it moves through the system;
✓ State machine models that show the systems response to
events.

3. SEMANTIC DATA MODELS:

• Used to describe the logical structure of data processed by the system.
• An entity-relation-attribute model sets out the entities in the system, the
relationships between these entities and the entity attributes
• Widely used in database design. Can readily be implemented using
relational databases.
• No specific notation provided in the UML but objects and associations
can be used.

4. OBJECT MODELS:
• Object models describe the system in terms of object classes and their
associations.
• An object class is an abstraction over a set of objects with common attributes
and the services provided by each object.
• Various object models may be produced
✓ Inheritance models
✓ Aggregation models
✓ Interaction models.
• Natural ways of reflecting the real-world entities manipulated by the system
• More abstract entities are more difficult to model using this approach
• Object class identification is recognised as a difficult process requiring a deep
understanding of the application domain
Advantages of Requirements Engineering Process
• Helps ensure that the software being developed meets the needs and
expectations of the stakeholders
• 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 an 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 of Requirements Engineering Process

• 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
• It 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.
• Requirements engineering should be flexible, adaptable, and should be
aligned with the overall project goals.
• 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.