Requirements Engineering

1. Introduction

The objectives of this module are

• To establish the importance / relevance of requirement specifications in software development

• To bring out the problems involved in specifying requirements
• To illustrate the use of modelling techniques to minimise problems in specifying requirements

Requirements can be defined as follows:

• A condition or capability 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 to satisfy a contract,
standard, specification, or other formally imposed document.

At a high level, requirements can be classified as user/client requirements and software requirements.
Client requirements are usually stated in terms of business needs. Software requirements specify what the
software must do to meet the business needs. For example, a stores manager might state his
requirements in terms of efficiency in stores management. A bank manager might state his requirements
in terms of time to service his customers. It is the analyst's job to understand these requirements and
provide an appropriate solution. To be able to do this, the analyst must understand the client's business
domain: who are all the stake holders, how they affect the system, what are the constraints, what are the
alterables, etc. The analyst should not blindly assume that only a software solution will solve a client's
problem. He should have a broader vision. Sometimes, re-engineering of the business processes may be
required to improve efficiency and that may be all that is required. After all this, if it is found that a
software solution will add value, then a detailed statement of what the software must do to meet the
client's needs should be prepared. This document is called Software Requirements Specification (SRS)
document.

Stating and understanding requirements is not an easy task. Let us look at a few examples:

• "The counter value is picked up from the last record"

In the above statement, the word 'last' is ambiguous. It could mean the last accessed record,
which could be anywhere in a random access file, or, it could be physically the last record in the file
• "Calculate the inverse of a square matrix 'M' of size 'n' such that LM=ML=In where 'L' is the inverse
matrix and 'In' is the identity matrix of size 'n' "
This statement though appears to be complete, is missing on the type of the matrix elements. Are
they integers, real numbers, or complex numbers. Depending on the answer to this question, the
algorithm will be different.
• "The software should be highly user friendly"
How does one determine, whether this requirement is satisfied or not.
• "The output of the program shall usually be given within 10 seconds"
What are the exceptions to the 'usual 10 seconds' requirement?

The statement of requirements or SRS should possess the following properties:

• All requirements must be correct. There should be no factual errors

• All requirements should have one interpretation only. We have seen a few examples of ambiguous
statements above.
• The SRS should be complete in all respects. It is difficult to achieve this objective. Many times
clients change the requirements as the development progresses or new requirements are added.
The Agile development methodologies are specifically designed to take this factor in to account.
They partition the requirements in to subsets called scenarios and each scenario is implemented
separately. However, each scenario should be complete.
 • All requirements must be verifiable, that is, it should be possible to verify if a requirement is met or
not. Words like 'highly', 'usually', should not be used.
• All requirements must be consistent and non-conflicting
• As we have stated earlier, requirements do change. So the format of the SRS should be such that
the changes can be easily incorporated

2. Understanding Requirements

2.1 Functional and Non-Functional Requirements

Requirements can be classified in to two types, namely, functional requirements and non-functional
requirements.
Functional requirements specify what the system should do.
Examples are:

• Calculate the compound interest at the rate of 14% per annum on a fixed deposit for a period of
three years
• Calculate tax at the rate of 30% on an annual income equal to and above Rs.2,00,000 but less
than Rs.3,00,000
• Invert a square matrix of real numbers (maximum size 100 X 100)

Non-functional requirements specify the overall quality attributes the system must satisfy.
The following is a sample list of quality attributes:

• portability
• reliability
• performance
• testability
• modifiability
• security
• presentation
• reusability
• understandability
• acceptance criteria
• interoperability

Some examples of non-functional requirements are:

• Number of significant digits to which accuracy should be maintained in all numerical calculations is
10
• The response time of the system should always be less than 5 seconds
• The software should be developed using C language on a UNIX based system
• A book can be deleted from the Library Management System by the Database Administrator only
• The matrix diagonalisation routine should zero out all off-diagonal elements, which are equal to or
less than 10-3
• Experienced officers should be able to use all the system functions after a total training of two
hours. After this training, the average number of errors made by experienced officers should not
exceed two per day.

2.2 Other Classifications

Requirements can also be classified in to the following categories:

• Satisfiability
• Criticality
• Stability
• User categories
Satisfiability: There are three types of satisfiability, namely, normal, expected, and exciting.
Normal requirements are specific statements of user needs. The user satisfaction level is directly
proportional to the extent to which these requirements are satisfied by the system. Expected
requirements may not be stated by the users, but the developer is expected to meet them. If the
requirements are met, the user satisfaction level may not increase, but if they are not met, users may be
thoroughly dissatisfied. They are very important from the developer's point of view. Exciting requirements,
not only, are not stated by the users, they do not even expect them. But if the developer provides for
them in the system, user satisfaction level will be very high. The trend over the years has been that the
exciting requirements often become normal requirements and some of the normal requirements become
expected requirements. For example, as the story goes, on-line help feature was first introduced in the
UNIX system in the form of man pages. At that time, it was an exciting feature. Later, other users started
demanding it as part of their systems. Now a days, users do not ask for it, but the developer is expected
to provide it.

Criticality: This is a form of priortising the requirements. They can be classified as mandatory, desirable,
and non-essential. This classification should be done in consultation with the users and helps in
determining the focus in an iterative development model.

Stability: Requirements can also be categorised as stable and non-stable. Stable requirements don't
change often, or atleast the time period of change will be very long. Some requirements may change
often. For example, if business process reengineering is going on alongside the development, then the
corresponding requirements may change till the process stabilises.

User categories: As was stated in the introduction, there will be many stake holders in a system. Broadly
they are of two kinds. Those who dictate the policies of the system and those who utilise the services of
the system. All of them use the system. There can be further subdivisons among these classes depending
on the information needs and services required. It is important that all stakeholders are identified and
their requirements are captured.

3. Modelling Requirements

3.1 Overview

Every software system has the following essential characteristics:

 • It has a boundary. The boundary separates what is with in system scope and what is outside
• It takes inputs from external agents and generates outputs
• It has processes which collaborate with each other to generate the outputs
• These processes operate on data by creating, modifying, destroying, and querying it
• The system may also use data stores to store data which has a life beyond the system

In the following, we will be describing artifacts used by Structured Systems Analysis and Design
Methodology (SSADM).
It uses:

• Data Flow Diagram (DFD) for modelling processes and their interactions.
• Entity Relationship Diagram (ERD) for modelling data and their relationships.
• Data Dictionary to specify data
• Decision Tables and Decision Trees to model complex decisions.
• Structured English to paraphrase process algorithms.

State Transition Diagram to model state changes of the system.

3.2 Data Flow Diagram (DFD)

Data flow diagram focuses on movment of data through the system and its transformations. It is divided
in to levels. Level 0, also known as the context diagram, defines the system scope. It consists of external
agents, system boundary, and the data flow between the external agents and the system. Level 1 is an
explosion of Level 0, where all the major processes, data stores, and the data flow between them is
shown. Level 2, Level 3, etc. show details of individual processes.

The notation used is the following:

External agents: They are external to the system, but interact with the system. They must be drawn at
level 0, but need not be drawn at level 2 onwards. Duplicates are to be identified. They must be given
meaningful names.

Process: They indicate information processing activity. They must be shown at all levels, At level 0, only
a single process, depicting the system is shown. On subsequent levels, the number of processes should be
limited to 7 ± 2. No duplicates are allowed.
Data Stores: They are used to store information. They are not shown at level 0. All data stores should be
shown at level 1. Duplicates must be indicated.

Data Flows: They indicate the flow of information. They must be shown at all levels and meaningful
names must be given.

Examples:

1. Customer places sales orders. The system checks for availability of products and updates sales
information

2. Company receives applications. Checks for eligibility conditions. Invites all eligible candidates for
interview. Maintains a list of all candidates called for interview. Updates the eligibility conditions as and
when desired by the management

Getting started:

• Identify the inputs or events which trigger the system and outputs or responses from the system
• Identify the corresponding sources and destinations (external agents)
• Produce a context diagram (Level 0). It should show the system boundary, external agents, and
the dataflows connecting the system and the external agents.
• Produce Level 1 diagram. It must show all the external agents, all the major processes, all the data
stores, and all the dataflows connecting the various artifacts. The artifacts should be placed based
on logical precedence rather than temporal precedence. Avoid dataflow crossings.
• Refine the Level 1 diagram.
 • Explode the individual processes as necessary.

Points to remember:

1) Remember to name every external agent, every process, every data store, and every dataflow.

2) Do not show how things begin and end.

3) Do not show loops, and decisions.

4) Do not show dataflows between external agents. They are outside the scope of the system.

5) Do not show dataflow between an external agent and a data store. There should be a process in
between.

6) Do not show dataflow between two data stores. There should be a process in between.
7) There should not be any unconnected external agent, process, or data store.

8) Beware of read-only or write-only data stores

9) Beware of processes which take inputs without generating any outputs. Also, beware of processes
which generate outputs spontaneously without taking any inputs.

9) Ensure that the data flowing in to a process exactly matches the data flowing in to the exploded view of
that process. Similarly for the data flowing out of the process.

10) Ensure that the data flowing out of a data store matches data that has been stored in it before.

See the appendix for the complete data flow diagram of "Material Procurement System (Case Study)"

3.3 Entity Relationship Diagram (ERD)

ERD complements DFD. While DFD focuses on processes and data flow between them, ERD focuses on
data and the relationships between them. It helps to organise data used by a system in a disciplined way.
It helps to ensure completeness, adaptability and stability of data. It is an effective tool to communicate
with senior management (what is the data needed to run the business), data administrators (how to
manage and control data), database designers (how to organise data efficiently and remove
redundancies). It consists of three components.

Entity: It represents a collection of objects or things in the real world whose individual members or
instances have the following characteristics:

• Each can be identified uniquely in some fashion.

• Each plays a necessary role in the system we are building.
• Each can be described by one or more data elements (attributes).
Entities generally correspond to persons, objects, locations, events, etc. Examples are employee, vendor,
supplier, materials, warehouse, delivery, etc.

There are five types of entities.

• Fundamental entity: It does not depend on any other entity for its existence. For e.g. materials
• Subordinate entity: It depends on another entity for its existance. For example, in an inventory
management system, purchase order can be an entity and it will depend on materials being
procured. Similarly invoices will depend on purchase orders.
• Associative entity: It depends on two or more entities for its existence. For example, student
grades will depend on the student and the course.
• Generalisation entity: It encapsulates common characteristics of many subordinate entities. For
example, a four wheeler is a type of vehicle. A truck is a type of four wheeler .
• Aggregation entity: It consists of or an aggregation of other entities. For example, a car consists
of engine, chasis, gear box, etc. A vehicle can also be regarded as an aggregation entity, because a
vehicle can be regarded as an aggregation of many parts.

Attributes: They express the properties of the entities.

Every entity will have many attributes, but only a subset, which are relevant for the system under study,
will be chosen. For example, an employee entity will have professional attributes like name, designation,
salary, etc. and also physical attributes like height, weight, etc. But only one set will be chosen depending
on the context.

Attributes are classified as entity keys and entity descriptors.

• Entity keys are used to uniquely identify instances of entities. Attributes having unique values are
called candidate keys and one of them is designated as primary key. The domains of the attributes
should be pre-defined. If 'name' is an attribute of an entity, then its domain is the set of strings of
alphabets of predefined length.

Relationships: They describe the association between entities.

They are characterised by optionality and cardinality.

Optionality is of two types, namely, mandatory and optional.

1. Mandatory relationship means associated with every instance of the first entity there will be
atleast one instance of the second entity.
2. Optional relationship means that there may be instances of the first entity, which are not
associated with any instance of the second entity. For example, employee-spouse relationship has
to be optional because there could be unmarried employees. It is not correct to make the
relationship mandatory.

Cardinality is of three types: one-to-one, one-to-many, many-to-many.

1. One-to-one relationship means an instance of the first entity is associated with only one
instance of the second entity. Similarly, each instance of the second entity is related to one
instance of the first entity.
2. One-to-many relationship means that one instance of the first entity is related to many
instances of the second entity, while an instance of the second entity is associated with only one
instance of the first entity.
3. In many-to-many relationship an instance of the first entity is related to many instances of the
second entity and the same is true in the reverse direction also.

Other types of relationships are multiple relationships between entities, relationships leading to associative
entities, relationship of entity with itself, EXCLUSIVE-OR and AND relationships
ERD notation: There are two type of notation used:

1. Peter Chen notation

2. Bachman notation.

Not surprisingly, Peter Chen and Bachman are the name inventors of the notation. The following table
gives the notation.

COMPONENT REPRESENTATION

ENTITY OR OBJECT TYPE PURCHASE ORDER

RELATIONSHIP

CARDINALITY

OPTIONALITY

PETER CHEN BACHMAN

Example for Bachman notation

Example for Peter Chen notation

Given below are a few examples of ER diagrams using Bachman notation. First the textual statement is
given followed by the diagram

1. In a company, each division is managed by only one manager and each manager manages only one
division

2. Among the automobile manufacturing companies, a company manufactures many cars, but a given car
is manufactured in only one company

3. In a college, every student takes many courses and every course is taken by many students
4. In a library, a member may borrow many books and there may be books which are not borrowed by
any member

5. A teacher teaches many students and a student is taught by many teachers. A teacher conducts
examination for many students and a student is examined by many teachers.

6. An extension of example-3 above is that student-grades depend upon both student and the course.
Hence it is an associative entity

7. An employee can play the role of a manager. In that sense, an employee reports to another employee.
8. A tender is floated either for materials or services but not both.

9. A car consists of an engine and a chasis

3.4 Data Dictionary

It contains

• an organised list of data elements, data structures, data flows, and data stores
• mini specifications of the primitive processes in the system
• any other details which will provide useful information on the system

Data element is piece of data, which can not be decomposed further in the current context of the
system.

Examples are purchase_order_no., employee_name, interest_rate, etc. Each data element is a member of
a domain. The dictionary entry of a data element should also specify the domain.

Data structure is composed of data elements or other data structures.

Examples are Customer_details, which may be composed of Customer_name and Customer_address.

Cutomer_address in turn is a structure. Another example is Invoice, which may be composed of
Invoice_identification, Customer_details, Delivery_address, Invoice_details.

Data flow is composed of data structures and/or data elements. Definitions of dependent data
structures/data elements precede the definition of data flow. While defining the data flow the connecting
points should be mentioned.
Also useful to include the flow volume/frequency and growth rates.

Data store, like data flow is made up of a combination of data structures and/or data elements. The
description is similar to data flows.

The notation elements used in the data dictionary are the following:

• [spouse_name]
This indicates that spouse_name is optional
• {dependent_name,
relationship} * (0 to 15)
This indicates that the data strucure can be repeated 0 to 15 times
• {expense_description,
company_name,
charge} * (1 to N)
This indicates that the data structure may be repeated 1 to N where N is not fixed
• voter_identity_number/customer_account_number
This indicates that either of the elements will be present.

Data dictionary also contains mini specifications. They state the ways in which data flows that enter the
primitive process are transformed in to data flows that leave the process. Only the broad outline is given,
not the detailed steps. They must exist for every primitive process. Structured english is used for stating
minispecifications.

Once the DFD, ERD, and the Data dictionary are created, the three of them must be matched against each
other. DFD and ERD can be created independently and parallely.

• Every data store in the DFD must correspond to atleast one entity in the ERD.
• There should be processes in DFD which create modify and delete instances of the entities in ERD.
• For every relationship in ERD there should be a process in DFD which uses it.

For every description in the data dictionary, there should be corresponding elements in DFD and ERD.

3.5 Decision Tree and Decision Tables

A decision tree represents complex decisions in the form of a tree. Though visually it is appealing, it can
soon get out of hand when the number and complexity of decisions increase. An example is given below.
First the textual statment is given and then the corresponding decision tree is given:

Rules for electricity billing are as below:

If the meter reading is "OK", calculate on consumption basis(i.e. meter reading)

If the meter reading appears "LOW", then check if the house is occupied
If the house is occupied, calculate on seasonal consumption basis otherwise calculate on
consuption basis
If the meter is damaged, calculate based on maximum possible electricity usage

There are two types of decision tables, binary-valued(yes or no) and multi-valued. An example follows:

ELECTRICITY BILL CALCULATION BASED ON CUSTOMER CLASS

If a customer uses electricity for domestic purposes and if the consumption is less than
300 units per month then bill with minimum monthly charges.
Domestic customers with a consumption of 300 units or more per month are billed at
special rate.
Non-domestic users are charged double that of domestic users (minimum and special rates
are double).
 BINARY-VALUED DECISION TABLE

Domestic Customer Y Y N N

Consumtion < 300 units per month Y N Y N

Minimum rate Y N N N

Special rate N Y N N

Double minimum rate N N Y N

Double special rate N N N Y

MULTI-VALUED DECISION TABLE

Customer D D N N

Consumption ≥ 300 <300 ≥300 <300

Rate S M 2S 2M

Like decision trees, binary-value decision tables can grow large if the number of rules increase. Multi-
valued decision tables have an edge. In the above example, if we add a new class of cutomers, called
Academic, with the rules:

If the consumption is less than 300 units per month then bill with concessional rates.
Otherwise bill with twice the concessional rates. then new tables will look like the following:

BINARY-VALUED DECISION TABLE (three rows and two columns are added to deal with the extra class
of customers)

Academic N N N N Y Y

Domestic customer Y Y N N N N

Consumption < 300 units/month Y N Y N Y N

Minimum rate Y N N N N N

Special rate N Y N N N N

Twice minimum rate N N Y N N N

Twice special rate N N N Y N N

Concessional rate N N N N Y N

Twice concessional rate N N N N N Y

 MULTI-VALUED DECISION TABLE (only two columns are added to deal with the extra class of
customers)

Customer Domestic Domestic Non-domestic Non-domestic Academic Academic

Consumption ≥ 300 <300 ≥300 <300 ≥300 <300

Rate Special Minimum Twice special Twice minimum Twice concessional Concessional

3.6 Structured English

To specify the processes (minispecifications) structured english is used.

It consists of:

• sequences of instructions (action statements)

• decisions (if-else)
• loops (repeat-until)
• case
• groups of instructions

Examples:

Loose, normal english:

In the case of 'Bill', a master file is updated with the bill (that is consumer account
number and bill date). A control file is also to be updated for the 'total bill amount'.
A similar treatment is to be given to 'Payment'

Structured english:

If transaction is 'BILL' then

update bill in the Accounts master file
update total bill amount in the Control file

If transaction is 'PAYMENT' then

update receipt in the Accounts master file
update total receipt amount in the Control file

Another example:

If previous reading and new reading match then

perform 'status-check'
If status is 'dead' then
calculate bills based on average consumption
Else
compute bill based on actual consumption

status-check

If meter does not register any change after switching on any electrical device then
meter status is 'dead'
Else
meter status is 'ok'
3.7 State Transition Diagram

Another useful diagram is the state transition diagram. It can be used to model the state changes of the
system. A system is in a state and will remain in that state till a condition and an action force it to change
state. See the following figure. Appendix contains another example.

4. Conclusion

The output of the requirements engineering phase is the software requirements specifications (SRS)
document. At a minimum, it should contain the DFD, ERD, and the data dictionary and the
minispecifications. The other diagrams may be used as required. The satndards body of Institute for
Electrical Electronics Engineers (IEEE) has defined a set of recommended practices called "IEEE
Recommended Practice for Software Requirements Specifications", IEEE standards 830-1998. It can be
used as a guideline document for SRS.

5. Appendix

Case Study: Material Procurement System

XYZ is a company which manufactures fertilizers(Soil Nutrition Chemicals) and chemicals for agricultural
use. The company has its head office in Delhi and a manufacturing plant in Surat.

The manufacturing plant is looked after by a Director-Operations. The Director-Operations is supported by

various deparmental heads for executing day-to-day operations, plant production, plant maintenance,
finance, purchase, stores, personnel fertilizers transportation and plant administration are some of the
major departments.

Our study is restricted to the purchase operations and related interfaces. Currently, all purchase
operations are being carried out manually. Management has decided to support purchase operations with
a computer. An extract of the discussions with the purchase manager and his staff related to current
procedures is enclosed.

An extract of discussions held with the purchase manager and his staff.
A. Overview of the Department

The Purchase Department is headed by a Purchase Manager and he reports directly to Director-
Operations. The Purchase Manager is supported by Material Procurement Officers (Buyers) and clerical
staff, total strength of the department is 20.

The Purchase Department's main function is to procure material for production, maintenance and other
departments in time so that there should not be any situation where the plant has to be shut down due to
requirement of some material requested by the departments.

At present, there are more than 300 Purchase Order (POs) always open at any time (a closed Purchase
Order is defined as a Purchase Order for which all material order is received and paid) and it has become
impossible to keep track of activities and provide up-to-date status of these activities to the concerned
departments.

The idea behind seeking computer support is to access information quickly and monitor purchase activity
efficiently. It is also expected that after computerisation, with the same manpower, future purchase load
(related to diversification plans of the company) can also be met.

The various procedures followed by the Purchase Department have already been studied and improved by
a company approved management consultant and unless really necessary no procedures should be
changed while providing the necessary computer support.

B. Procedural Details Related to Purchase Activity

User Departments (i.e. Production, Maintenance, etc.) prepare their own material purchase request (MPR)
and send these to purchase department as and when a requirement comes up. More than one material
procurement detail can be given in the same MPR. Material Procurement details contain material code,
description and quantity.

Purchase Department validates the MPR for material requested and MPRs received. MPRs are accepted by
Purchase Department only if the required quantity is not available in stores (Stock Clearance by Stores
Dept.) and concerned department has not exhausted allocated budgets for procurement. Stock Clearance
from stores dept. is required only for non-stock items of specific class. (Allocated Budgets are provided by
Finance Department at the beginning of the financial year and are available with purchase Department).

Whenever a buyer who handles a particular material group (25 material group have been formed on the
basis of similariy of material) gets time, he reviews MPR Register and consolidates (from various MPRs)
material requirement for his groups. After this exercise, he raises an enquiry (request for quotation) with
registered vendors (vendors are registered with the company for specific class of items). An enquiry can
contain one of many materials of a material group (for example 1.5", 1" bolts etc. which have separate
material codes, can be part of single enquiry) every enquiry has only one closing date (i.e. last date of
receipt of quotation from vendors).

Vendors submit technical and commercial quotation (2 stage bidding). If any technical discrepancy is
found such quotations are rejected after closing date for an enquiry. All commercial quotations received
are opened by the concerned buyer (in presence of Purchase Manager and Vendors) and afterwards are
analysed for total value (basic cost of materials, taxes, Insurance packing freight). On lowest cost basis an
offer is selected and purchase order proposal is prepared. A PO proposal contains details of all materials,
payment terms and all other relevant terms and conditions. This PO proposal is sent to Finance Dept. and
a financial concurrence is obtained. Sometimes in the organisation's interest, for an enquiry more than
one Purchase Orders are placed (For example, out of 4 materials involved in an enquiry, 2 are cheaper
from one vendor and rest are cheaper from another vendor). In a purchase Order every material ordered
has a due date for delivery. Also in some purchase orders, where quantity ordered is large (this situation
is typical for bulk material procurement, cement, steel etc.) staggered delivery of material is mentioned.
PO is considered effective from the date of acceptance of PO by vendors. Vendors deliver material (against
PO) to Store Department and submit an invoice to Purchase Department. On receiving of "Acceptance"
intimation from stores, Purchase Departments checks and passes the invoice and payment advice to
Finance Department for payment. In case of any discrepancy in the terms & conditions such invoice is
rejected. While passing invoices, adjustments are made of any material which is rejected by stores (such
data is mentioned by Stores in Material Receipt Intimation).

Environmental Model
(Ref. Material Procurement System)

Event List

1. Receipt of Purchase Request from Departments

2. Receipt of Stock Clearance Data
3. Receipt of Quotations from Vendors
4. Order Acceptance from Vendors
5. Availability of Material Receipt Data
6. Invoice Submission by Vendors
7. Receipt of Financial Concurrence
8. Receipt of Allocated Budgets
Level -1 Data Flow Diagram
Level 2 - Data Flow Diagram