Information and Management Sciences
Volume 15, Number 1, pp.69-90, 2004
A Systematic Approach to Measure the ProblemComplexity of Software Requirement Specifications
of an Information System
Yogesh Singh Sangeeta Sabharwal
Guru Gobind Singh Indraprastha University Netaji Subhas Institute of Technology
India India
Manu Sood
Himachal Pradesh University
India
Abstract
SRS document is the first deliverable product/milestone in the software development
process and acts as a basis for the formal contract between the user and the developer of
the software of an information system. This document is written in natural language and
reflects the problem (computation) complexity of the system. We felt that there was a need
to measure this complexity since little effort has been made towards the measurement of this
complexity; and then deriving estimates from the SRS. In this work, we define a problem
complexity metric, which measures the strength(s) of the requirements specified with in the
SRS document, in terms of their inter-dependencies. This metric will be used in future
works to derive various estimates related to the development of software. To arrive at this
metric, a requirements model has been proposed that provides the necessary base for the
measurement. The work has been supported with the successful calculation of this metric
for a real life example.
Keywords: Software Requirements Specifications, Metric, Strength, CARE Tool.
1. Introduction
Information Systems are the vehicles and Softwares are the driving force behind the
delivery of the most important product of recent times i.e. information. Right information
at the right time, at right place and consumed rightly can facilitate right decisions in
any environment. We conceptualize an information system in its most abstract form as
shown in Figure 1, where predefined inputs are consumed as raw data during processing
Received October 2002; Revised March 2003; Accepted September 2003.Supported by ours.
70 Information and Management Sciences, Vol. 15, No. 1, March, 2004
and the information is produced in the form of expected outputs under certain controls
in an environment.
Figure 1. Conceptual model of an information system.
It is becoming difficult to ensure the expected performance of software controlled in-
formation systems in the given environment. This may be due to increasing complexity of
information systems and their development strategies. While functioning in an environ-
ment, the external behaviour of any software system has to be observed within that very
environment only. The behaviour of its components and the interaction among them is
reflected through this external behaviour. When the interaction between different com-
ponents is governed by simple, well-defined and deterministic rules, the overall enternal
behaviour of the system is predictable to a high degree of accuracy. This predictability
provides the basis for differentiating simple or complex systems.
Accordingly, the behaviour of simple system is completely predictable irrespective
of the algorithmic or software complexity. In practice, very few simple systems exist
for obvious reasons. When some of the components of a system cannot be modeled
accurately or the rules for interaction between these components cannot be precisely
defined, the overall behaviour of the system can only be predicted with some degree of
uncertainty and hence we have complex systems with varying levels of complexity. The
level of complexity obviously is influenced by how closely we can model the components
or the accuracy of definition of rules governing their interactions.
Alagar et al. describe that the major categories of complexities identified by the de-
velopers are: size, structural, environmental, application domain and communicational
complexities [1]. Fenton et al. interpret the complexity for the software systems de-
pending upon the perspective, in four different ways: problem complexity (also known
as computational complexity) that measures the complexity of the underlying problem;
algorithmic complexity that reflects the complexity of the algorithm implemented to
solve the problem and measures the efficiency of the software; structural complexity that
measures the structure of the software used to implement the algorithm; and cognitive
A Systematic Approach to Measure the Problem Complexity 71
complexity that measures the effort required to understand the software [7]. In this pa-
per, we have concentrated on the problem complexity of the software systems reflected
through the software requirements specifications.
Two main tools mostly used to deal with any type of software complexity are de-
composition and abstraction. The principle of decomposition ensures that properties of
whole system follow from the properties of its parts whereas the abstraction principle
ensures that specification focus only on key features suppressing the unnecessary details,
without a description on how to realize them. However, sometimes, the software products
are so complex that it is not easy to partition the tasks [3].
Software developers cannot build what cannot be properly specified. The specification
of requirements that the software system is supposed to provide, establishes the scope for
the system development. Requirements are considered to be the properties of the system
to be built. The formal definition of requirement is given in [8]. These are used to express
the proposed system in terms of ‘what’ to build, with no emphasis, whatsoever, at all
on ‘how’ to build it [1]. The ‘what’ part specified by requirement engineers is developed
and delivered by software developers.
Three fundamental questions about the requirements that arise are why specifications,
what to specify and how to specify? The ‘Why specification’ part is related to the objec-
tives of the system in reference to its environment. The ‘What to specify’ part prescribes
the behaviour and functionality of the system as a whole. And the ‘How to specify’ part
is concerned about the specification language and techniques used for this description
and not about the realization of ‘What’ part. The answers to these questions lead to
defining the notion of a view, a model and the behaviour in the specifications. A view
reflects the abstraction and its level. A model exhibits the behaviour of the objects of
interest [1].
Requirements Engineering is a systematic process of developing requirements through
an iterative co-operative process of analyzing the problem, documenting the resulting
observations in a variety of representational formats, and checking the accuracy of the
understanding gained [11]. Requirements engineering calls for the involvement of: re-
quirements engineers, customer who commissions the system, users who ultimately inter-
act with the system, and the persons who introduce the system in the enterprise. There
is no unique or standard technique for specifying the requirements although IEEE has
made certain recommendations for this purpose [10]. As a matter of practice, require-
ments are generally specified in a natural language so that all the stakeholders especially
72 Information and Management Sciences, Vol. 15, No. 1, March, 2004
the users and the customers understand what is being specified and developed. Require-
ments Engineering aims at providing the customer/user with maximum satisfaction by
means of meeting their expectations, delivering the software in time and adherence to
the estimated budget.
Traditional view of requirements of a candidate system focused only on the function-
ality of the system and resulted in functional requirements. Functional requirements are
based only on the functions/services that must be provided by the system. But of late,
much emphasis is being put on non-functional requirements.
I. Sommerville defines non-functional requirements as restrictions or constraints
placed on a system service [14]. B. Bohem [2] and Deutsch et al. [5] have termed non-
functional requirements as ‘quality requirements’. A. M. Davis describes them as non-
behavioural requirements in contrast to behavioural i.e. functional requirements [4]. Ac-
cording to IEEE-Std830 (1984), non-functional requirements are based on constraints of
performance, user interfaces, reliability, maintainability, security, portability, standards
etc. Both, functional and non-functional requirements are essential for the successful
construction of the software system. But it has been found that the distinction between
the functional and non-functional requirements has diminished. The possible reason for
that is what might be initially considered as a non-functional requirement may have to
be ultimately specified as a functional requirements, as the knowledge about the system
is assimilated during the development process.
A common framework of requirement engineering processes is given in [11] in terms
of three overlapping and interacting activities: elicitation, specification, and validation.
The elicitation activity is carried out in order to gain enough knowledge of the system so
as to produce formal requirements specifications for it. Requirements specification ac-
tivity carries out two sub activities: 1) assimilation and analysis of knowledge of system
requirements, and 2) synthesis and organization of the knowledge into logically coherent
requirements [11]. The deliverable or the product of this activity is called Software Re-
quirements Specification document or simply SRS. It should describe as completely as
possible the intended external, user visible behaviour of the system. But it should not
contain design, construction, testing, or project management details other than known
design and implementation constraints. Some important characteristics of a good SRS
are Correctness, unambiguity, Completeness, consistency, rankings, verifiability, mod-
ifiability, traceability etc. The activity of validation ensures that the problem is well
A Systematic Approach to Measure the Problem Complexity 73
understood and the user/customer agreement is obtained on what constitutes a valid
description of their problem.
The human psychology makes the task of collecting requirements a difficult task
because of the human tendency of expressing uncertain desires in an ambiguous language.
Some interesting statistics can be found in [15] and [6]. Karl E. Wiegers in [17] describes
four techniques to be used to greatly reduce the expectation gap between the system
customer really needs to solve his problems, and the system developer decides to build
for him.
The quality of requirements specified has a direct bearing on the quality of the soft-
ware, both of which again depend upon the quality of processes, which create these two.
Quality is a feature or characteristic or attribute of something. As an attribute of an
item, quality refers to measurable characteristic - things that can be compared to the
known standards. However, since the softwares as well as the requirements are engi-
neered intellectual entities, finding out of measurable attributes, measuring them and
also having standards to compare with is a challenging task. Again, quality has a two di-
mensional perspective: quality of design concerned with requirements, specifications and
overall design of the system; and quality of conformance concerned with implementation.
An intuitive relationship between user satisfaction and the quality can be represented in
the form of the following equation [12]:
User Satisfaction = Compliant Product + Good Quality
+ Delivery within Budget and Schedule
Customer involvement is the most critical factor in software quality and the most difficult
problem is sharing the vision of the final product with the customer [16].
Any software measurement activity starts with the identification of entities and at-
tributes to be measured. Three classes established in software for the purpose of mea-
surement are processes, products, and resources [7]. Each of these classes have internal or
external attributes. The internal attribute can be measured by examining the product,
process or resources on its own, separate from its behaviour. The external attribute can
be measured with respect to its environment. Here the behaviour of the product, process
or resources is important rather than the entity itself.
Fenton et al. in [7] suggest that the software size can be described with three funda-
mental attributes: length, functionality and complexity. Length is the physical size of the
74 Information and Management Sciences, Vol. 15, No. 1, March, 2004
product, and functionality measures the functions supplied by the product to the user.
The size measure can be used to represent the size of specifications, design and length
of the programs code. Some effort has been also made to measure the functionality of
sepcifications, design and programs but the software engineering community has not put
in much efforts in measuring the software complexity [7].
2. Problem Definition
In this paper, we suggest a systematic approach to measure the problem (computa-
tional) complexity of software requirements specifications as specified in the SRS doc-
ument, of an information system. We have measured the complexity of software re-
quirements specifications in terms of the strengths (can also be expressed alternatively
in terms of weaknesses) of individual requirements or category of requirements, and the
interrelationship of strengths of various categories of requirements. The strenghts, thus
calculated using dependency matrices, in turn, could be used in the estimation of cost,
time, effort and productivity.
The requirements are the components of the SRS reflecting directly the
problem/computational complexity of the information system. The calculated strengths
are the measure of the degree of dependencies aomongst the requirements. Hence,
we consider the strengths of the requirements thus calculated as a measure of prob-
lem/computational complexity of the information system. We propose that the require-
ments in the software requirements specifications should strive to achieve the strengths
nearer to zero, which can be interpreted as minimizing the problem/computational com-
plexity in the SRS. This will ultimately ensure least effort at every stage of the SDLC
and lesser costs of development, better productivity, better maintainability etc.
The solution to our problem is based upon the approach given by Alagar et al. in [1]
as mentioned earlier, with conceptualization of a general view of an information system
from the requirement engineer’s point of view. Next, a comprehensive requirements
model of the software requirements specifications is proposed. Subsequently, we followed
the key stages of formal measurement given by Fenton et al. in [7] that are reproduced
here for ready reference: 1) Identify attribute for some real world entities, 2) Identify
empirical relations for attribute, 3) Identify numerical relations corresponding to each
empirical relation, 4) Define mapping from real world entities to numbers, and 5) Check
that numerical relations preserve and are preserved by empirical relations.
A Systematic Approach to Measure the Problem Complexity 75
For the purpose of practical application, a real life example of the software require-
ments specifications of the student timetabling system mentioned in its SRS document
has been taken up. Then the requirement model has been applied to the requirements
specified in this example. Appropriate tuples with only some specific properties (at-
tributes) have been generated for each individual requirement. Some aspects of the
model proposed have not been incorporated in this work and will be taken up further
in the future. The main emphasis has been on the representation of dependencies in
terms of associations and links. The links are represented in the numeric form as 0
or 1. From these specific tuple values, we have generated various dependency matrices
and calculated the strengths of requirements at an individual level as well as at the
category/subcategory levels.
3. Requirements Perspective of an Information System:
Figure 2 depicts a requirements perspective of an information system, proposed by
us, at a reasonably high level of abstraction. We look at the knowledge domain of
any information system from three different perspectives i.e. application, system and
organization perspectives as shown at level 2 and we have expressed them in terms of
level 2 ordered dependency pairs. The level 2 dependency pairs are <Organization,
Knowledge Domain>, <System, Knowledge Domain> and <Application, Knowledge
Domain>.
Here, we mean to say that all the level 2 perspectives e.g. system perspective, depend
upon or can be derived from the knowledge domain. This relationship in terms of de-
pendencies depicts the behaviour of various perspectives that are the objects of interests
in this model. Likewise, we have three ordered dependency pairs i.e. <Software Require-
ments, Application>, <Software Requirements, System>, and <Software Requirements,
Organization> at level 3, which show dependency of requirements on application, system
and organization views respectively. Similarly, we derive design perspective from software
requirement perspective and so on. Also the dependency pairs for the test perspective
at level 6 can be derived from software requirements, design and program perspectives
at levels 3, 4 and 5 respectively.
76 Information and Management Sciences, Vol. 15, No. 1, March, 2004
Figure 2. Requirements perspective of an information system.
4. The Requirements Model:
We propose a requirements model from requirements engineering point of view as
shown in the Figure 3. This is a model, which tries to capture and control the complex-
ities inherent in the software requirements specifications due to the specification being
prescribed in natural languages. The specification of requirements in natural language
is based on the IEEE recommended standard format [10] of the formal SRS document.
Figure 3. Requirements model of an software system.
A CARE (Computer Aided Requirements Engineering) tool based on this model may
be developed (proposed future work) and can be used to measure some metrics including
A Systematic Approach to Measure the Problem Complexity 77
strength, straight away from the SRS document, which will ultimately help in estimation
of size, time, cost and productivity of the target system.
We consider a requirement to be either atomic or complex. The complex require-
ments consist of two or more atomic/complex requirements. As an example, an atomic
requirement is a single requirement within a requirement type and can be a functional or
a non-functional requirement whereas a complex requirement is given a group name and
may have two or more than two atomic or complex requirements. We have identified a
requirement by pair, which is composed of a requirement type and an attribute. So we
can say that any requirement in the SRS can be defined as:
Requirement = <Requirement type, Attribute>
Figure 4. Requirement types.
4.1. Requirement type:
A requirement that directly prescribes some functionality for the software system to
be developed is termed as functional requirement. These are the software capabilities
that must be available to user to a) carry out the services provided by the feature or b)
perform the task specified by a use case, in case the requirement are captured through
use case diagrams.
These ate also used to specify how the product should report to anticipated error con-
ditions or invalid input. Another type of the requirement is non-functional requirement.
It prescribes the requirement that is indirectly related to the functionality of the system.
These two types of requirements are mutually exclusive (Figure 4) i.e. a requirement can
either be functional or non-functional but cannot be of both types.
The non-functional requirements can be of any one type: constraint, safety, perfor-
mance, security, software quality, external interface, business rules and user documenta-
tion [10] (Figure 5). These requirement types too are mutually exclusive.
78 Information and Management Sciences, Vol. 15, No. 1, March, 2004
Figure 5. Non-functional requirements.
A constraint as a non-functional requirement, has been specified in terms of one of the
two types of mutually exclusive constraints namely, design constraint or implementation
constraint (Figure 6).
Figure 6. Constraint.
We ensure the proper connectivity of the product with the external components with
the help of these external interface requirements. Four types of external interfaces have
been identified i.e. user, hardware, software and communication external interfaces and
details about them can be found in [10]. Accordingly, four kinds of corresponding re-
quirements can be specified as shown in Figure 7.
Figure 7. External interface.
A Systematic Approach to Measure the Problem Complexity 79
4.2. Attributes:
The attributes are the defining properties of requirements and ensure the uniqueness
of each requirement. We propose that the attributes related to each requirement can be
defined as a 6-tuple, composed of an identifier, dependency, version, priority, author and
status as shown in Figure 8.
Attribute = <Identifier, Dependency, Version, Priority, Author, Status>
Figure 8. Attribute composition of a requirement.
We attach a unique identification to each requirement called as an identifier. We
propose that the requirements engineer must allocate identifier to each requirement in
the software requirements specification (SRS) document. These identifiers can be used
to map the requirements at the conceptual level to the requirements at the logical level.
Dependency<Requirement Identifier>
= {< Associationm, Linkm >, <Associationn, Linkn, >, . . .}
Figure 9. Dependency attribute of a requirement.
80 Information and Management Sciences, Vol. 15, No. 1, March, 2004
We define the dependency of a requirement as say requirement a1 has a dependency
on the requirement a2, if a1 is related to a2 or a1 changes if a2 changes or a1 can be
derived from a2. We represent these dependencies for a particular requirement as a non
null set of multiple instances of pairs of an association and a link with other requirements
(Figure 9).
We propose to express the association of a requirement with other requirements in two
ways (Figure 10). Associations can be classified as direct or indirect associations (mutu-
ally exclusive). The direct association is used to represent the hierarchical associations
in the form of parent-child relationship. The indirect associations are used to represent
associations between different categories of requirements. Alternatively, associations can
also be classified as single or multiple associations (again mutually exclusive). When a
requirement is associated with only one more requirement, it is called as single associa-
tion. When a requirement is associated with more than one requirement, the association
is termed as multiple associations. A multiple association will be composed of more than
one single or multiple requirements.
Figure 10. Associations of requirements.
As far as a link is concerned, we propose that if a requirement has an association
with another requirement, it will also have a link with that requirement. The identifier
of the later requirement gives this link. Multiple instances of pairs of an association and
a link can exist because of the fact that a requirement may have dependency with many
other requirements. We say, as a thumb rule that no requirement can exist without
an association and a link. Within the above mentioned two categories of associations,
hybrid associations such as single-indirect or multiple-direct etc are also possible. In line
with these associations, we have also categorized the dependencies into direct/indirect,
single/multiple and hybrid types.
A Systematic Approach to Measure the Problem Complexity 81
Most of the requirements specified in the SRS are susceptible to changes a no. of
times during the SDLC and may even change a number of times during the require-
ments specification activity. The change here implies addition, deletion or modification
of requirements. Since SRS document is considered to be the reference point by all
stakeholders in the development process of the software system, even a single change
in the requirements has to be reflected in this document immediately. This change of
requirements has also to be propagated to the stakeholders. As the requirements may
keep on changing frequently during the SDLC, we use the concept of version to have a
proper control over the resulting chaos. Here, the version may be specified for each and
every individual requirement separately or we may use the version of the SRS as the
version of the requirements. Both these strategies have their pros and cons.
During the requirement specification activity of the SDLC, the requirements engineer
carries out process of elicitation of requirements from the information system users. We
here propose to put the users into different classes based on the their role, function,
level and interaction with the information system. While collecting and validating the
requirements, no emphasis is laid on the class of the user. But before formally putting
requirement into the SRS document, it will be a good practice to attach some priority
level to each requirement depending upon the objective and the class of the concerned
user. This practice facilitates the rest of the developing team i.e. designers, coders, testers
etc to have a better control and flexibility in their jobs. We have defined the priority of
a requirement as a 2-tuple, with the composition of a user class and a value (Figure 11).
Priority = <User class, Value>
The value is related to the quantification of the requirements. In the absence of
quantification, there is an excellent chance for failure of software system in the form of:
(1) exceeding the minimum necessary cost due to over-design, or (2) failing to account for
needed capability, thus reducing item value to the customer. This logic may not be always
accepted. Some of the value definition methods are sound engineering judgment, simple
mathematical approaches, parametric analysis, operation research methods, models &
simulations etc. [9].
82 Information and Management Sciences, Vol. 15, No. 1, March, 2004
Figure 11. Priority composition of an attribute of a requirement.
The attribute, author represents the identity of the author of a particular requirement.
This attribute assumes significance in the development of very large information systems,
where a large group of requirement engineers along with other large group of developers
are working simultaneously on more than one project. Also the author may be related
to a particular version of a particular requirement.
At times some of the requirements are not clear in the mind of user(s). It is also
possible that the user and the requirements engineer cannot reach at a mutually agreeable
stage about some requirement till some other requirements get proper shape.
Also, may be some requirements cannot be specified until the design, implementation,
or testing/acceptance phase is over. Such requirements too have to find a place in the
SRS document (of course with a version no.). In our model, we propose to mark these
requirements as To Be Determined (TBD) [10] as shown in Figure 12. The space for
such requirements is reserved in the SRS document although it is assigned an identifier
and the status flag for such requirements is said to be TBD. The status of all other
requirements is said to be clear.
Figure 12. Status as an attribute of a requirement.
A Systematic Approach to Measure the Problem Complexity 83
4.3. Dependency matrix:
Dependency matrix in this context is the matrix, which is generated using values
of notational representations prescribed for the requirements in accordance with the
requirements model. Dependencies, which are part of the definition of any requirement,
are used to fill the matrix rows and columns. For a particular requirement identifier
represented by a single row in the dependency matrix, the values of links in terms of ‘0’
or ‘1’ are entered in the corresponding columns represented again by the requirements
identifiers. A ‘0’ represents no link, whereas a ‘1’ represents the presence of a link between
a particular requirement and another requirement. Also, a ‘1’ is used to represent the
link of a particular requirement to itself. The notation of a requirement gives us the
dependency pairs in terms of the type of association followed by all the requirement
identifiers for that type of association.
To construct a dependency matrix, a particular requirement in the particular cate-
gory/sub-category of requirements is taken and the value in terms of 0/1, of its links
with all other requirements of the same or different category/sub-category are filled up.
In this way, we can generate different dependency matrices including the one, which will
cover all the requirements mentioned in the SRS document. This dependency matrix is
called as a complete dependency matrix.
4.4. Metric for complexity:
The proposed requirements model provides a simple way to measure the problem
complexity indirectly and metrics can be defined to express the relational complexity.
One such metric proposed in this work is termed as strength. It represents the relative
strength of various individual requirements or a category/sub-category of requirements.
The strength of an individual requirement or a category/sub-category of requirements
as defined by us is a measure of its relative dependency on individual requirements in
various categories/sub-categories of requirements, where dependency is defined in term
of association type and links. Once the dependency matrix for a particular category/sub-
category of requirement(s) is ready, it is used to calculate the strengths for the individual
requirements as well as for the category/sub-category as a whole. Strengths are calculated
from the dependency matrices according to the formula as given below.
84 Information and Management Sciences, Vol. 15, No. 1, March, 2004
The formulae for calculating the strength of an individual requirement is:
Si =
(N∑
j=1
Li,j
)/N
where Si is the strength of the it h requirement of a particular category/sub-category,
N is the total no of requirements in the particular category/sub-category,
Li,j is the link value of it h requirement with the jt h requirement, and
Li,j = 1 for i = j
Strength of a Category/sub-category of requirements is given by:
S =
(N∑
i=1
N∑j=1
Li,j
)/(N ∗ N)
where S is the strength of a Category/sub-category of requirements,
N is the total no of requirements in the particular category/sub-category,
Li,j is the link value of ith requirement with the ith requirement, and
Li,j = 1 for i = j
As can be seen that the strengths of individual requirements, requirement categories/sub-
categories etc thus calculated will always be less than or equal to 1 and greater than 0.
A value of the strength in the dependency matrix of requirements nearer to ‘1’ indicates
that the requirement has greater dependency on other requirements and will require more
effort and prove to be costlier affair in all the subsequent phases of SDLC and hence
will infer that the SRS refects higher problem/computational complexity. A value of the
strength in the dependency matrix of requirements nearer to ‘0’ indicates that the require-
ment has lesser dependency on other requirements and will require lesser effort and will
not prove to be costlier affair in all the subsequent phases of SDLC and hence will infer
that the SRS refects lesser problem/computational complexity. The complement of this
strength metric can be defined as weakness.
5. Real Life Example:
A real life example; an SRS document for the Student Timetabling System [13] has
been adopted for the practical application of our requirements model and for the purpose
of calculation of the strength metric. The purpose of the Student Timetabling System is
to assist students in determining their timetable of practicals and tutorials for the units
A Systematic Approach to Measure the Problem Complexity 85
they are enrolled in for an individual semester. The system must assist the student in
avoiding timetable clashes. The requirements, 41 in total, in this SRS have been cate-
gorized into functional and non-functional requirements. The functional requirements,
27 in total, have further subcategories as 1) Unit Registration (001 to 013), 2) Retrieval
and Displaying Unit Information (014 to 021), 3) Report Generation (022 to 025), and
4) Data Entry (026 to 027). 14 numbers of non-functional requirements have further
sub-categories as 1) Security (028 to 030), 2) Design Constraint (031 to 033), 3) Perfor-
mance (034 to 038), 4) Software Quality (039), 5) External Interface (040), and 6) User
Documentation (041).
Two requirements sub-categories Unit Registration (functional) and Performance
(non-functional) of the said SRS along with their representations according to our model
are given below. Dependency matrices generated and strengths calculated from these ma-
trices have been shown below. Full text of the example has been attached as Appendix-A.
Unit Registration-SRS001 to SRS013: The unit registration requirements are
concerned with functions regarding unit registration, which includes students selecting,
adding, dropping, and changing a unit.
SRS001: STS shall allow the user to register a unit.
SRS001 = < F01 : UR, < 1, < {< DM : 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 13 >,
< IM : 17, 19, 23, 24, 26, 28, 29, 30, 31, 36, 39, 40, 41 >} >, . . . >>
SRS002: STS shall allow the user to delete a unit if the user has chosen to drop that
unit.
SRS002 = < F01 : UR, < 2, < {< DM : 2, 3, 4, 8, 9, 10 >,
< IM : 17, 19, 23, 24, 26, 27, 31, 36, 39, 40, 41 >} >, . . . >>
SRS003: STS shall check if a unit has been filled by enough registered students.
SRS003 = < F01 : UR, < 3, < {< DM : 1, 3, 4, 6, 7 >,
< IM : 14, 15, 17, 19, 24, 31 >} >, . . . >>
SRS004: STS shall allow the user to add his/her name to the unit waiting list if the
user wants to register in a unit which has been filled already with enough registered
students.
SRS004 = < F01 : UR, < 4, < {< DM : 1, 3, 4, 5, 10, 13 >,
< IM : 14, 17, 26, 31, 36, 39, 40, 41 >} >, . . . >>
86 Information and Management Sciences, Vol. 15, No. 1, March, 2004
SRS005: STS shall automatically register the unit for the user who is the first one on
the waiting list if a vacancy appears for that unit.
SRS005 = < F01 : UR, < 5, < {< DM : 1, 3, 4, 5, 10, 13 >,< IM : 27, 31 >} >, . . . >>
SRS006: STS shall allow the user to change practical session(s) within a unit.
SRS006 = < F01 : UR, < 6, < {< DM : 6, 7, 8 >,
< IM : 14, 15, 20, 24, 25, 26, 27, 29, 31, 36, 39, 40, 41 >} >, . . . >>
SRS007: STS shall allow the user to change tutorial session(s) within a unit.
SRS007 = < F01 : UR, < 7, < {< DM : 6, 7, 8 >,
< IM : 14, 15, 20, 24, 25, 26, 27, 29, 31, 36, 39, 40, 41 >} >, . . . >>
SRS008: STS shall check if there are clashes between a new unit to be registered and
another unit in which the user is already registered.
SRS008 = <F01 : UR, <8, <{<DM : 1, 2, 6, 7, 8, 9>,<IM : 23, 24, 27, 31>}>, . . . >>
SRS009: STS shall warn the user if the user attempts to register more units than
allowed by the program in which they are enrolled.
SRS009 = < F01 : UR, < 9, < {< DM : 2, 5, 9, 10, 11, 12, 13 >,
< IM : 26, 36, 39, 40, 41 >} >, . . . >>
SRS010: STS shall provide the user with options when the number of units a user
has registered is beyond the maximum allowed number. The options include giving up
registration on one or more units or paying additional fees.
SRS010 = < F01 : UR, < 10, < {< DM : 1, 2, 4, 6, 7, 8, 9, 10, 11, 12, 13 >,
< IM : 14, 15, 17, 23 >} >, . . . >>
SRS011: STS shall warn the user about the deadline for unit registration.
SRS011 =<F01 : UR, <11, <{<DM : 1, 11, 12, 13>,<IM : 14, 15, 17, 23>}>, . . . >>
SRS012: STS shall warn the user about the deadline for dropping a unit.
SRS012 = <F01 : UR, < 12, <{<DM : 2, 11, 12>,<IM : 14, 15, 17, 23>}>, . . . >>
A Systematic Approach to Measure the Problem Complexity 87
SRS013: STS shall warn the user about the deadline for adding a unit.
SRS013 = < F01 : UR, < 13, < {< DM : 1, 9, 10, 11, 13 >,
< IM : 14, 15, 17, 18, 19, 23, 24 >} >, . . . >>
Performance-SRS034 to SRS038:
SRS034: STS shall respond to any retrieval in less than 5 seconds.
SRS034 = < NF03 : P, < 34, < {< DM : 34, 35, 38 >,
<IM : 15, 17, 18, 19, 20, 21, 23, 24, 25, 26, 27, 30, 31, 32, 33, 41>}>, . . . >>
SRS035: STS shall generate a report within 1 minute.
SRS035 = < NF03 : P, < 35, < {< DM : 35 >,
< IM : 22, 23, 24, 25, 26, 30, 31, 32, 33, 38 >} >, . . . >>
SRS036: STS shall be on line: 7:00am – 10:00pm, Mon-Sat: 12:00am – 5:00pm, Sun.
SRS036 =< NF03 : P, < 36, < {< DM : 36 >,< IM : − >} >, . . . >>
SRS037: STS shall be available for demonstration in the 3rd Year Computing labo-
ratories by the end of week 11.
SRS037 = < NF03 : P, < 37, < {< DM : 34, 35, 36, 37, 38, 39, 40, 41 >,
< IM : − >} >, . . . >>
SRS038: The functionality of STS shall be demonstrated in no longer than 15 minutes.
SRS038 =< NF03 : P, < 38, < {< DM : 34, 35, 38 >,< IM : − >} >, . . . >>
SRS< n >: Identifier of nth requirement,
F< m >: mth sub-category of functional category of requirements,
NF< p >: pth sub-category of non-functional category of requirements,
DM: Direct-Multiple association,
IM: Indirect-Multiple association,
UR: Unit Registration,
P: Performance
88 Information and Management Sciences, Vol. 15, No. 1, March, 2004
As can be seen from the strengths calculated above, the strengths of individual require-
ments within the unit registration sub-category vary between 0.231 and 0.923 whereas
the strength of the sub-category as a whole is 0.462. This means that within unit registra-
tion sub-category, the requirement no. 1 having strength of 0.932 is going to consume the
highest efforts/resources and requirement nos. 6, 7 and 12 having strength of 0.231 will
consume the least of efforts/resources. Similarly, for the Performance sub-category, the
strengths of individual requirements vary between 0.2 and 1.0, and the overall strength
of this sub-category is 0.56. This also reflects that the Performance sub-category is going
to consume more efforts/resources as compared to unit registration sub-category.
Dependency Matrix
Unit Registration
1 2 3 4 5 6 7 8 9 10 11 12 13 S
1 1 1 1 1 1 1 1 1 1 1 1 0 1 0.923
2 0 1 1 1 1 0 0 1 1 1 0 0 0 0.539
3 1 0 1 1 0 1 1 0 0 0 0 0 0 0.385
4 1 0 1 1 1 0 0 0 0 1 0 0 1 0.462
5 1 0 1 1 1 0 0 0 0 1 0 0 1 0.462
6 0 0 0 0 0 1 1 1 0 0 0 0 0 0.231
7 0 0 0 0 0 1 1 1 0 0 0 0 0 0.231
8 1 1 0 0 0 1 1 1 1 0 0 0 0 0.462
9 0 1 0 0 1 0 0 0 1 1 1 1 1 0.539
10 1 1 0 1 0 1 1 1 1 1 1 1 1 0.846
11 1 0 0 0 0 0 0 0 0 0 1 1 1 0.308
12 0 1 0 0 0 0 0 0 0 0 1 1 0 0.231
13 1 0 0 0 0 0 0 0 1 1 1 0 1 0.385
Sub-category Strength = 0.462
Dependency Matrix
Performace
34 35 36 37 38 S
34 1 1 0 0 1 0.600
35 0 1 0 0 1 0.400
36 0 0 1 0 0 0.200
37 1 1 1 1 1 1.000
38 1 1 0 0 1 0.600
Sub-category Strength
= 0.560
Figure 13. Dependency matrices and average strengths.
6. Conclusion
The SRS document, written in natural language, serves the purpose of formal con-
tract between the user and the developer of the software of an information system. This
A Systematic Approach to Measure the Problem Complexity 89
document reflects the problem complexity of the information system. We felt a need to
measure this complexity and define metrics for it. These metrics can then be associated
in deriving some estimates related to the development of software. As such, very little
work has been done in this area i.e. deriving estimates directly from the SRS. In this
work, we have defined a problem complexity metric, strength. It measures the relative
strength(s) of the requirements specified with in the SRS document, from the values of
their dependencies. To arrive at this metric, a requirements model has been proposed
that provides the necessary base for the measurement. We have supported this work
with a real life example and the metric calculated successfully. We conclude that the
strengths of the individual orcategory/sub-category of requirement(s) will be always less
than or equal to unity. A value nearer to one indicates that the particular require-
ment(s) or a category/sub-category of requirement(s) are contributing more towards the
problem/computational complexity and need greater effort and consume more resources
during the whole SDLC. Lesser the problem complexity reflected in the SRS, lesser will
be the values of strengths of requirements i.e. values nearer to zero and vice-versa. In
fact, this metric if supplemented by some more metrics to be proposed in future, may
provide the bases for the estimation of cost, time, productivity etc. from the SRS directly.
References
[1] Alagar, V. S. and Periyasamy, K., Specification of Software Systems, Springer-Verlag, New York,
Inc., 1998.
[2] Bohem, B., Software Engineering, IEEE Transactions on Computers, Vol.25, No.12, 1976.
[3] Conte, S. D., Dunsmore, H. E. and Shen, V. Y., Software Engineering Metrics and Models, Section
5.8, Benjamin/Cummings, 1986.
[4] Davis, A. M., Software Requirement, Objects, Functions and States, Prentice Hall, Englewood Cliffs,
NJ, 1993.
[5] Deutsch, M. S. and Willis, R. R., Software Quality Engineering: A Total Technical and Management
Approach, Prentice Hall, Englewood Cliffs, NJ, 1988.
[6] Engler, N., Bringing in the Users, Computerworld, November 25, 1996.
[7] Fenton, N. E. and Pfleeger, S. L., Software Metrics: A Rigorous and Practical Approach, 2nd Edition,
p.245, International Thomson Computer Press, 1996.
[8] Glossary of Software Engineering Terminology, Institute of Electrical and Electronics Engineers, New
York, IEEE Standard 610-1990, IEEE, 1990.
[9] Grady, J. O., System Requirements Analysis, McGraw-Hill, Inc., 1993.
[10] IEEE Recommended Practice for Software Requirements Specifications, Institute of Electrical and
Electronics Engineers, New York, IEEE Standard 830-1998, IEEE, 1998.
[11] Loucopoulos, P. and Karakostas, V., System Requirements Engineering, McGraw-Hill Book Com-
pany, Berkshire, 1995.
[12] Pressman, R. S., Software Engineering-A Practitioner’s Approach, McGraw Hill, 2001.
90 Information and Management Sciences, Vol. 15, No. 1, March, 2004
[13] Richard, D., Student Timetabling System, ( c©Macquarie University 2000), Version 0.1, University
of Calgary, 2000.
[14] Sommerville, I., Software Engineering, Addison-Wesley, 1992.
[15] Rochelle, G., Why JAD Goes Bad, Computerworld, April 10, 1995.
[16] Wiegers, K., Creating a Software Requirements Specifications, Software Development, July 1994.
[17] Wiegers, K., In Search of Excellent Requirements, The Journal of the Quality Assurance Institute,
January 1995.
Authors’ InformationYogesh Singh received his M.Tech. and Ph.D. (Computer Engineering) degree from National Institute of
Technology, Kurukshetra (previously know as Regional Engineering College, Kurukshetra). At present,
he is Professor & Dean at below address. His area of research is Software Engineering focusing on
Planning, Testing, Metrics and Neural Networks. He has also worked actively in the area of fuzzy
systems. He has more than 95 publications in International / National Journals and Conferences. He is a
referee for various journals of International and National repute in the area of Information Technology and
allied fields. He is a co-author of the book on “Software Engineering”. He was the Principal Investigator
of the successfully implemented MHRD-AICTE Project entitled “Experimentation & Development of
Software Reliability & Complexity Measurement Techniques”. He is a member of IT-Task force and a
member of its Core-Group on E-Education, Government of NCT of Delhi. He is a member of Review
Committee for Direct Central Assistance Schemes Project, Ministry of Human Resources Development,
Government of India and member of various committees constituted b AICTE and UGC. He is a Fellow
Member of IETE (F158608) and Member of IEEE (41481854).
School of Information Technology, Guru Gobind Singh Indraprastha University, Kashmere Gate, Delhi
110006, India.
E-mail: [email protected] TEL: 91-11-23862856.
Sangeeta Sabharwal has done B.E. amd M.E. in Electronics and Communication Engineering from Delhi
College of Engineering, Delhi University, Delhi in 1984 and 1990 respectively. Further, she did her
Ph.D. from Faculty of Technology, Delhi University in 2001 with specialization in Software Engineering.
At present, she is working as Assistant Professor and Associate Head, Division of Computer Engineer-
ing and Information Technology at Netaji Subhas Institute of Technology, New Delhi, India, Her current
research interests include Requirements Engineering, Meta-Modelling, Process Modelling and Data Ware-
housing.
Division of Computer Engineering, Netaji Subhas Institute of Technology, Sector-3, Dwarka, New Delhi
110045, India.
E-mail: [email protected] TEL: 91-11-25099036.
Manu Sood is currently pursuing Ph.D. programme from the Division of Computer Engineering under
the Faculty of Technology, Delhi University, and the topic being “Development of Estimation Measures
from the Software Requirement Specification of Information Systems”. At present, he is working as
Senior Lecturer at below address. He has more than 15 years of professional experience in different
fields at different levels; approx. 5 years Industry experience and rest with the Himachal Pradesh Uni-
versity, Shimla. His research interests include software development process, requirements engineering,
estimation, measurements, metrics data warehousing and data mining.
Department of Computer Science, Himachal Pradesh University, Summer Hill, Shimla, Himachal Pradesh
171005, India.
E-mail: soodm [email protected] TEL: 91-117-2832569.
Top Related