Requirement Engineering, Architecture and Design

Requirement Engineering,
Architecture and Design
Chapter One
Introduction to Software Requirements
Engineering & Processes in Requirements
Engineering
Sem. I – 2023
1

Information systems are increasingly becoming an integral part of our everyday,
for correct and efficient functioning.
Requirements specification plays a central role in the process of correct
understanding of the needs of the system’s customers or users.
The process of developing a requirements specification has been called
Requirements Engineering
Definition of Requirements
A condition or capacity needed by a user to solve a problem or achieve an
objective.
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.
A documented representation of a condition or capability as in (1)or (2).
In General, requirements fall into two broad categories:
Market-driven
Customer-specific
Introduction

Comparisons Between Market-Driven and Customer-Specific Projects:
3
Introduction

Requirements - An Organizational Perspective
The contribution of information systems to organisations can be examined in
terms of:
Automating production by reducing the cost of the processes that make up
production.
Informing decision makers through the exploitation of automated
processes.
Transforming the organization in a way that management and business
processes make the best use of information technology
The development of IS
Not only designing database structures and algorithms.
Understanding the needs of individuals and other stakeholders within the
enterprise.
Ensuring that the system meets user requirements and business strategy.

5
Relationship between the ‘enterprise’, ‘system’ and
‘system user’ domains

Requirements Specification from an Enterprise Perspective
6

Requirements engineering is about establishing the ‘connection’ between the
need for some change within an organisational framework and the technology
that could bring about such a change.
Or
Requirements engineering can be considered as a way of managing change.
Requirements engineering involves:
An understanding at a conceptual level of the current status
A definition of the change in terms of the transition from the ‘old’
conceptual situation to a ‘new’ target conceptual situation
The implementation of the change in terms of the new components of the
system
The integration of this new implementation in the environment which
contained some legacy system.
7

Requirements - A Software Perspective
Software Engineering is a systematic approach to the development,
operation, maintenance, and retirement of software
Each of these phases can be seen from a dynamic viewpoint as a process
Process is a unique, finite course of events defined by its purpose or by its
effect, achieved under given conditions
In Software Engineering, Errors in the requirements definition stage resulted
in costly maintenance of software systems at best and total rejection at worst
As a consequence, Requirements Engineering was established as a sub field of
Software Engineering
Defining the software architecture (structure), components, modules,
interfaces, test approach, and data for a software system to satisfy specified
requirements
Software Requirements Engineering
8

Software Requirements Engineering
Three key elements development of a quality product.
Requirements Specification concerns of customers and users,
Functionality of the system and the constraints that must be satisfied.
(both system and organisational constraints).
System Specification is concerned with the definition of the system
boundary and the information used in the interaction of the system and its
environment. This specification represents a ‘black box’ view is a
sequence of actions that must be performed.
9
Different models of software
Method is a prescription of steps that need to be employed in order to
achieve a specified result
Procedure is a sequence of actions that must be performed.
Tool is the machinery used to perform some action as part of a procedure.

Software Project Management
Architectural Design represents a high-level view of the system’s internal
design. is the machinery used to perform some action as part of a
procedure.
Detailed Design represents a decomposition of the system and
concentrates on the details of individual components.
Implementation is concerned with the software components that finally
realise the original user requirements.
10

Software Development Process
Software development process consists of a number of distinct activities
Developing a system constitutes a design activity.
Properties of the design process:
(a) a set of requirements to be met by some artefact,
(b) the output of the process is some design,
(c) the goal of the designer is to produce a design such that if an
implementation of this design were to materialise then the artefact would
satisfy the requirements
(d) the designer has no knowledge of any design that satisfies the
requirements.
11

Characteristics recognized in the software development process:
The software development process involves the generation of a number of
different models
The software development process can be viewed as a series of steps
These steps are goal driven and can be regarded as transitions between
representations, preserving the semantic content, as refinements on these
representations are applied.
12
Software Development Process
Reasons for Software does not satisfy all requirements:
Software is not made of any physical substance it cannot be described in
standard physical descriptions such as material, colour, dimensions etc.
Described in terms of intangible characteristics of the situations, tasks and
environments in which people use it.
Software users best understand and describe their own work;
Software experts are more familiar with their domain-software

Documenting requirements for software construction is an activity termed
requirements specification.
a requirements specification represents both a model of what is needed and a
statement of the problem under consideration.
A requirements specification, ranging from informal natural language text to
more formal graphical and mathematical notations.
The structure of the specification itself varies according to different standards
and practices
13
Requirements Specification
What is Requirement Specification ?

14
First, To correctly understand the needs of the customer and user of the
intended system.
Second, Used for clarifying a situation about the intended system or its
environment i.e. the organizational context.
Third, the specification may be part of contractual arrangements, a
situation that may become especially relevant when an organization
wishes to procure a system from some vendor rather than develop it ‘in
house’
Fourth, For evaluating the final product and could play a leading role in
any acceptance tests agreed between system consumer and supplier.
Purpose of Requirement Specification

The traditional view of a requirements specification is that of a functional
specification i.e. a definition of the desired service of the intended system.
A functional requirements specification is the description of the fundamental
functions of the software components that make up the system.
Functions are therefore, specified in terms of inputs, processing and outputs.
A dynamic view of a system’s functionality would need to consider aspects
such as control (e.g. sequencing and parallelism), timing of functions (e.g.
starting and finishing), as well as the behaviour of the system in terms of
exceptional situations.
The specification of ‘real-world’ entities and their relationships, particularly
for data-centred systems, need to be defined at appropriate levels of
abstraction and related to descriptions of system functions.
15
Purpose of Requirements Specification

Requirements Specification & System Architecture
Requirements specification should define the
‘what’ - a description of the problem in hand
and not the
‘how’ - the way that the problem is to be solved.
There are a number of factors, that make a distinction between the ‘what’ and
the ‘how’ .
The requirements specification is one that goes beyond the description of
system functionalities. A functional specification should be one view
supplemented, or even motivated by two other perspectives.
First, an understanding should be gained of the domain within which the
intended system will be firmly embedded.
Second, the constraints that can be placed on the system environment or its
development, known as nonfunctional requirements (NFRs) (e.g. security,
availability, portability, usability, performance, etc.).
16

Software Project Management Fundamentals
Conceptual Framework for Requirements Specifications
17
Requirements specification is shown to constitute an interrelated set of
descriptions in three domains namely, the enterprise, functional and non-
functional domains.

What is Requirements Engineering
The systematic process of developing requirements through an iterative co-
operative process of analyzing the problem, documenting the resulting
observations in a variety of representation formats and checking the accuracy
of the understanding gained.
Requirements Engineering consists of the knowledge elicitation,
representation and validation cycle.
The success of the requirements engineering process often depends on the
ability to proceed from informal, fuzzy individual statements of requirements
to a formal specification that is understood and agreed by all stakeholders
The transition from informal to formal requirements constitutes a
conceptualization activity by using domain knowledge partly expressed in
descriptions of the enterprise, and partly in existing requirements
specifications.
18

Insights of requirements & requirements analysis
Analysis problems, at their inception, have ill-defined boundaries,
structure, and a sufficient degree of uncertainty about the nature and
makeup of the solution.
Requirements are found in organizational contexts, with associated
conflicts on expectations and demands about some intentional system.
The solutions to analysis problems are artificial. That is, they are designed
and hence many potential solutions exist for any one problem.
Analysis problems are dynamic.
Solutions to analysis problems require interdisciplinary knowledge and
skill.
The knowledge base of the systems analyst is continually evolving and
the analyst must be ready to incorporate changes in the technology and to
participate with users in different ways.
The process of analysis itself, is primarily cognitive in nature, requiring
the analyst to structure an abstract problem, process diverse information,
and develop a logical and internally consistent set of specifications.
19

Contemporary software methods do not prescribe a formal Requirements
Engineering process. .
Requirements engineering is easier described by its products than its processes..
A framework for describing Requirements Engineering processes can be
constructed by considering three fundamental concerns of Requirements
Engineering:
Understanding a problem ('what the problem is')
Formally describing a problem
Attaining an agreement on the nature of the problem
The current literature on software requirements, classifies activities in terms:
Acquisition
Elicitation
Analysis
Specification
Validation
A Framework for Requirements Engineering Processes
Processes in Requirements Engineering

21
In order to avoid the confusion, processes proposed here are:
Elicitation
Specification
Validation
Each Requirements Engineering process is described in terms of:
The purpose of the process
The input to the process and its origins
The activities which take place during the process and techniques used
The final and intermediate deliverables
The interaction with other Requirements Engineering processes

A Schematic Framework for Requirements Engineering Processes

23
Requirements Elicitation
Elicitation is the first activity that takes place and continues
through the Requirements Engineering lifecycle.
The purpose of requirements elicitation:
Distributed amongst many people, places and sources.
Knowledge is usually available in a variety of notations
range from sketches, through natural language prose to
formal models (e.g. mathematical models)
Some mental model in people's minds!
To gain of knowledge relevant to the problem.
Relevant knowledge produce a formal specification of the
software needed to solve the problem.

24
Input to requirements elicitation: All Possible sources of
domain knowledge
Domain experts
Literature about the domain
Existing software systems in that domain
Similar software applications in other domains
National and international standards, which constrain the
development of software in that domain
Other stakeholders in the larger system (e.g. an
organisation) which will host the software system.

Activities and techniques of requirements elicitation :
In requirements elicitation, the analyst is presented with the tasks of
Identifying all the sources of requirements knowledge
Acquiring the knowledge
Deciding on the relevance of the knowledge to the problem in hand
Understanding the significance of the elicited knowledge and its impact
on the software requirements.
Some most typically used techniques:
Users interviews, and through the
Creation of mock-up (prototype) software.
Reuse knowledge acquired in similar problem domains
Elicitation is a Labour intensive process, difficult task will take a large share
of time and resources for software development.

Deliverables of requirements elicitation:
The formal outcome of Requirements Engineering should be the
requirements specification model.
The Model creation starting with conceptual models and ending with the
requirements specification model.
Model contains environmental factors, domain goals, policies, constraints etc.
26
Interactions between elicitation and other Processes:
Elicitation is ongoing process of Requirements Engineering
Provides the 'raw material' to other processes to produce formal Model
Elicitation occurs in parallel with specification and validation processes.

27
A specification is a contract between users and software developers which
defines the desired functional behaviour of the software artefact (and other
properties of it such as performance, reliability etc.) without showing how
such functionality is going to be achieved.
Specification describes: 1. Application domain (enterprise models)
2. Nonfunctional models.
.
The purpose of requirements Specification:
The specification model is used as an agreement between the software
developers and the users on what constitutes the problem which must be
solved by the software system
The specification model is also a blueprint for the development of the
software system.

28
Input to requirements Specification:
The process of specification requires as input knowledge about the
problem domain.
This knowledge is supplied by the elicitation process.
The input knowledge comes in a 'raw' format which must be converted
to meaningful information in order to produce a formal specification
model.
Other types of knowledge produced by the validation process is also
employed in specification.
Such knowledge states what is valid and what is not in the formal
specification.
It acts as a force for changing the formal requirements model.

Activities and techniques of requirements Specification :
The process is analytical because all different kinds of knowledge
that the analyst elicits from the problem domain must be examined
and cross-related.
Specification is also synthetic because the heterogeneous
knowledge must be combined into producing a logical and
coherent requirements specification.
Requirements specification is described by the following major
activities:
Analysis and assimilation of requirements knowledge •
Synthesis and organization of the knowledge into a coherent and
logical requirements.

Deliverables of requirements Specification:
User-oriented models specifying the behaviour, non-functional characteristics
etc. of the software which serve as a point of understanding between the
analyst, the customer and the user
Developer-oriented models specifying functional and non-functional
properties of the software system as well as constraints on resources, design
constraints etc. which act as blueprints for further development stages.
30
Interactions between Requirements Specification and other Processes:
Requirements specification is the central process of Requirements
Engineering.
Specification controls both the elicitation and validation processes as follows.
This will trigger the process of elicitation which will in turn supply the
needed information.
Some change in the problem domain (e.g. change in some assumption, made
about the domain) can trigger a change in the specification model.

31
Requirements Validation
Requirements validation is a process of Requirements Engineering which
aims to ensure that the right problem is being tackled at any time.
In many Requirements Engineering methods, validation is not a separate
activity, part of requirements specification.
Conceptual as well as practical reasons, to make the distinction between
validation and other processes and activities of Requirements Engineering.
The purpose of requirements Validation:
Requirements validation is defined as the process which certifies that the
requirements model is consistent with customers’ and users’ intents.
Validation is an ongoing process which proceeds in parallel with
elicitation and specification.
Validation encompasses activities such as requirements communication

32
Input to requirements Validation:
Any requirements model (formal or informal) is subject to
validation and thus provides an input to the process.
Knowledge about the problem domain for example must be
validated, i.e. checked for accuracy, consistency, relevance
to the project etc.
In a similar way, some part of the formal requirements
model must be validated in parts and as a whole.

Activities and techniques of requirements Validation :
Validation is a process which requires interactions between analysts,
customers of the intended system and users in the problem domain.
This is similar to the scientific process of formulating a new theory
(specification) and subsequently testing it by performing experiments
(validation).
In some occasions, the analyst can test the validity of the requirements
model without resorting to experimentation, e.g. by using common-sense.
In a scientific sense, validation is therefore characterized by two principal
types of activities:
preparing the settings for an experiment
performing the experiment and analyzing its results

Deliverables of requirements Validation:
Validation delivers a requirements model which is consistent and in
accordance with the users expectations.
This does not mean that the model is in any sense correct.
Validation yields a compromise between what was desired by the users and
what is possible and feasible under the project constraints.
34
Interactions between Requirements Validation and other Processes:
Validation is ever present in all stages of Requirements Engineering.
The need for validation is triggered by the acquisition of new knowledge
about the problem domain (elicitation), or by the formulation (even in part)
of a requirements model (specification).
Validation is also needed during the analysis and synthesis phases of
requirements specification, since information analysed must be checked for
correctness and synthesised requirements must be checked for logical
consistency and coherence.

Processes of Requirements Engineering, in the context of the
following software development models
The waterfall model
The spiral model
The prototyping model
The operational model
The transformational model
The knowledge-based model
The Domain Analysis model
Processes of RE, in the context of the S/W development models

Requirement Engineering, Architecture and Design

More Related Content

Similar to Requirement Engineering, Architecture and Design (20)

Recently uploaded (20)

Requirement Engineering, Architecture and Design

Editor's Notes