A Systematic Approach to Measure the Problem …...Information and Management Sciences Volume 15,...

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


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


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


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.


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.


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


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.


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.


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.


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.


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].


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.


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.


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


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 >} >, . . . >>


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>}>, . . . >>


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


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


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.


[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.

A Systematic Approach to Measure the Problem …...Information and Management Sciences Volume 15,...

Documents

Transcript of A Systematic Approach to Measure the Problem …...Information and Management Sciences Volume 15,...