REQUIREMENTS ENGINEERING PROCESS

Software requirements engineering is the process of determining what is to be produced in a

software system. As the name implies requirements engineering is a dig field responsible to cover
all the activities involved indiscovering, documenting, and maintaining a set of requirements for a
computer based systems. A numbers of consequences may arise due to wrong requirements such
as the system may be delivered late, more costly than the original estimation, customer and end-
user will not be satisfied, the system may be unreliable and there may be regular system defects.

Definition=“Requirements engineering is the branch of software engineering concerned with the

real world goals for functions of and constrains on the software systems. It is also concerned with
the relationship of these factors to precise specifications of software behavior and their evolution
overtime and across software families.”

Input/output of Requirements Engineering Process

 Software prototyping
Software prototyping, refers to the activity of creating prototypes of software applications, i.e.,
incomplete versions of the software program being developed. It is an activity that occurs during
certain software development and is comparable to prototyping as known from other fields, such
as mechanical engineering or manufacturing. Software prototyping is an approach to software
development that uses prototypes to help both the developers and their customers visualize the
proposed system and predict its properties in an iterative process

The conventional purpose of a prototype is to allow users of the software to evaluate developers'
proposals for the design of the eventual product. Prototyping can also be used by end users to
describe and prove requirements that developers have not considered.

Advantages of prototyping

 Improved and increased user involvement: Prototyping requires user involvement and allows
them to see and interact with a prototype allowing them to provide better and more complete
feedback and specifications

 Reduced time and costs: Prototyping can improve the quality of requirements and specifications
provided to developers

 Misunderstandings between software users and developers are exposed

 Missing services may be detected and confusing services may be identified

Disadvantages of prototyping

 Insufficient analysis: The focus on a limited prototype can distract developers from properly
analyzing the complete project

 User confusion of prototype and finished system: Users can begin to think that a prototype,
intended to be thrown away, is actually a final system that merely needs to be finished or
polished.

 Expense of implementing prototyping: the start up costs for building a development team
focused on prototyping may be high.

 Developer misunderstanding of user objectives: Developers may assume that users share their
objectives without understanding wider commercial issues.

Types of prototyping

1. Throwaway prototyping

2. Evolutionary prototyping

3. Incremental prototyping
1. Throwaway prototyping

Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be
discarded rather than becoming part of the final delivered software. After preliminary
requirements gathering is accomplished, a simple working model of the system is constructed to
visually show the users what their requirements may look like when they are implemented into a
finished system.

Rapid Prototyping involved creating a working model of various parts of the system at a very
early stage, after a relatively short investigation. The method used in building it is usually quite
informal, the most important factor being the speed with which the model is provided. The model
then becomes the starting point from which users can re-examine their expectations and clarify
their requirements. When this has been achieved, the prototype model is 'thrown away', and the
system is formally developed based on the identified requirements

Outline Develop Evaluate Specify

requirements prototype prototype system

Reusable
components

Delivered
Develop Validate software
software system system

Reason for using Throwaway Prototyping is that it can be done quickly. And it has the ability to construct
interfaces that the users can test.

Key points—

 Used to reduce requirements risk

 The prototype is developed from an initial specification, delivered for experiment then discarded

 The throw-away prototype should NOT be considered as a final system

2. Evolutionary Prototyping

The main goal when using Evolutionary Prototyping is to build a very robust prototype in a
structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype,
when built, forms the heart of the new system, and the improvements and further requirements
will be built.

When developing a system using Evolutionary Prototyping, the system is continually refined and
rebuilt. A product is never "done;" it is always maturing as the usage environment changes…we
 often try to define a system using our most familiar frame of reference---where we are now. We
make assumptions about the way business will be conducted and the technology base on which
the business will be implemented. A plan is enacted to develop the capability, and, sooner or later,
something resembling the envisioned system is delivered.

Develop abstract Build prototype Use prototype

specification system system

Deliver YES System

system adequate?

Evolutionary prototyping advantages

 Accelerated delivery of the system--Rapid delivery and deployment are sometimes more
important than functionality or long-term software maintainability

 User engagement with the system--Not only is the system more likely to meet user
requirements, they are more likely to commit to the use of the system

3. Incremental prototyping

 The final product is built as separate prototypes. At the end the separate prototypes are merged in
an overall design.

 System is developed and delivered in increments after establishing an overall architecture

 Users may experiment with delivered increments while others are being developed

 Intended to combine some of the advantages of prototyping like

 More manageable process

 Better system structure

 Define system
deliverables

Design system Specify system Build system Validate

architectur e increment increment increment

NO

Deliver final System Validate Integrate

system complete? system increment
YES

Formal specification
A formal specification is a mathematical description of software or hardware that may be used
to develop an implementation. It describes what the system should do, not (necessarily) how the
system should do it. A design (or implementation) cannot ever be declared “correct” in isolation,
but only “correct with respect to a given specification”.
Eg; Z notation, VDM-SL

Formal specification is part of a more general collection of techniques that are known as ‘formal
methods’. These are all based on mathematical representation and analysis of software. Formal
methods include
• Formal specification;
• Specification analysis and proof;
• Transformational development;
• Program verification.

System
Formal
requirements
specification
specification
User High-level
requirements design
definition

System Architectural
modelling design

Specification in the software process

Use of formal specification

 Formal specification involves investing more effort in the early phases of

software development.

 This reduces requirements errors as it forces a detailed analysis of the

requirements.

 Incompleteness and inconsistencies can be discovered and resolved.

 Hence, savings as made as the amount of rework due to requirements

problems is reduced.

Specification techniques

1. Algebraic specification--The system is specified in terms of its operations

and their relationships. Algebraic techniques are suited to interface
specification where the interface is defined as a set of object classes.

2. Model-based specification--The system is specified in terms of a state model

that is constructed using mathematical constructs such as sets and
sequences. Operations are defined by modifications to the system’s state. The
Z notation is a mature technique for model-based specification. It combines
formal and informal description and uses graphical highlighting when
presenting specifications.

Interface specification

Large systems are decomposed into subsystems with well-defined interfaces between
these subsystems. Specification of subsystem interfaces allows independent
development of the different subsystems. Interfaces may be defined as abstract data
types or object classes. The algebraic approach to formal specification is particularly
well-suited to interface specification as it is focused on the defined operations in an
object
Interface
objects

Sub-system Sub-system
A B

Specification components

1. Introduction--Defines the sort (the type name) and declares other

specifications that are used.

2. Description--Informally describes the operations on the type.

3. Signature--Defines the syntax of the operations in the interface and their

parameters.

4. Axioms--Defines the operation semantics by defining axioms which

characterise behaviour.

Eg; Consider an air traffic control system where aircraft fly through managed sectors of
airspace. Each sector may include a number of aircraft but, for safety reasons, these
must be separated. In this example, a simple vertical separation of 300m is proposed.
The system should warn the controller if aircraft are instructed to move so that the
separation rule is breaked.