Information and Management Sciences Volume 17, Number 1, pp.

67-89, 2006

The Requirements Model and Behaviour in Specication of Requirements

Manu Sood Himachal Pradesh University India Yogesh Singh Guru Gobind Singh Indraprastha University India Sangeeta Sabharwal Netaji Subhas Institute of Technology India

Abstract The proper elicitation and specication of functional and non-functional requirements of an information system in a given environment is the rst and the most critical task for the software developers today. The next critical activity is to properly understand these requirements so as to map them on to various design artifacts. In this paper, with the help of the requirements model, we present the behaviour part in the specication of requirements. We explain the behaviour in the specication with the help of dependencies using a mathematical model and a tree/graph so as to enhance the complete understanding of the requirements specication of the information system.

Keywords: Requirements Engineering, Software Requirements Specication (SRS), Requirements Model, Dependency, Atomic requirements, Complex Requirements, Behaviour in Specication, Strength. 1. Introduction The goal of software engineering, like any other branch of engineering, is to produce a well engineered software product. A well engineered product should be maintainable, reliable, and ecient and should oer an appropriate user interface [25]. The most critical issues in the development of software systems are related to evolution of requirements [9, 10, 16] and are covered under the discipline of requirements engineering. The requirements engineering is a problem understanding and solving activity [3, 8, 19]. Given undened problems, requirements engineers formulate the problem themselves
Received April 2005; Revised May 2005; Accepted August 2005. Supported by ours.

68

Information and Management Sciences, Vol. 17, No. 1, March, 2006

with in the framework of the environment [26] and this process is known as knowledge discovery process [8]. The eld of requirements engineering aims at providing the customer/user with maximum satisfaction by means of meeting their expectations, delivering the software in time and adherence to estimated budget. The requirements engineers handle the complexity of the system by decomposing it into simpler components using a hierarchically organized process [14]. [4, 7, 15, 26] had demonstrated the opportunistic nature of the RE process. Further light is thrown in [21] on the dynamics of the requirements by relating them with two types of complexities. [5, 17, 18, 19] considered the process of RE as a systematic evolutionary development of requirements models. Requirements engineering mainly comprises of three interacting and overlapping activities namely, elicitation, validation and specication [18]. Validation ensures that the problem is well understood by the requirements engineer and the user/customer agreement is obtained on what constitutes a valid description of their problem. A requirement specication as a product is a description of what of a system that is to be built without a description of how. The main objective of the requirements specication phase is to specify all the requirements of the target system in such a way that these are understood and assimilated by all the stakeholders in the system who could be any of the users, customer, supplier, requirements engineers, developers, testers and/or management personnel. The standard denitions for the common software engineering terms used in this paper can be found in [12]. Requirements specication document is the primary output of the process of requirements engineering. If this document describes hardware, software and other requirements, it is called a system requirements specication and if it describes only software requirements, it is known as software requirements specication (SRS) [1]. With an illwritten requirements specication document, it becomes fairly dicult: 1) for developers (designers) to decide what to build, 2) to validate the expected requirements of the system to be built, 3) for customer/users to know what to expect from the system, and 4) for testers to decide what to test against. In contrast, a good SRS oers the following benets: a) establishes the basis for agreement (and legal contract as well) between the users/customers and the supplier/developer on what the functional and non-functional requirements of the software product shall be, b) is used as a reference by all the stakeholders in dierent phases of software engineering, c) acts as basis for the estimations of size, costs, eort etc, d) helps in reduction

The Requirements Model and Behaviour in Specication of Requirements

69

of development eort, e) provides baseline for verication and validation and f) facilitates transfer and installation of a software to the user/customer site(s) and g) helps in traceability and easier control of various types of maintenance jobs. Because of the involvement of various stakeholders especially the users and/or customers, the best choice for the specication of requirements is the natural languages. The specication in natural languages is easy to understand but have disadvantages of ambiguities and may result in multiple interpretations. In contrast, the formal specication languages are precise and technical but are dicult to be understood by the end users/customers. In this reference, the Institute of Electrical and Electronics Engineers (IEEE), Inc., New York, USA has a published standard for software requirements specication [11] that describes recommended practices for the SRS in a natural language. Adherence to this standard results in a process that helps in reducing the ambiguities and inconsistencies inherent in the SRS document because of the natural languages, and helps in checking incompleteness. The IEEE standard in [11] prescribes specic characteristics for a good quality SRS and suggests that for this purpose the requirements in it should be complete, unambiguous, correct, consistent, veriable, modiable, traceable, and ranked for importance and/or stability. All the quality attributes are to be achieved within the tight constraints of timeframes, resources and those of costs. The determination, creation and specication of requirements in the SRS should be done carefully as this SRS is used as a reference through out the software development life cycle (SDLC), specically at the time of acceptance testing [13, 20]. A high quality SRS document and adequate support of standards and documentation to the process of requirements engineering helps in producing high quality software and it also reduces the development cost [13]. Abbreviations used SDLC Software Development Life Cycle IEEE Institute of Electrical and Electronics Engineers SRS AR Software Requirements Specication Atomic Requirement TBD To Be Determined DS Direct-Single DM Direct-Multiple IS Indirect-Single IM Indirect-Multiple CR Complex Requirement

70

Information and Management Sciences, Vol. 17, No. 1, March, 2006

2. Problem Denition The SRS document written in a natural language as per the recommendations of the IEEE Standard 830-1998 [11] acts as input to the design phase of the software engineering and is used by the designers of the development team for purpose of preparing the design for the software system. Depending upon the methodology to be used, this category of developers, design various artifacts of the software and produce related design documents. The specication in the SRS are to be properly understood, assimilated and consumed honestly by these developers in entirety so as to produce a design that will support a high quality, compliant software. Also the ambiguities and inconsistencies inherent in the SRS because of the use of natural languages in specication and the incompleteness are to be eliminated. The specication of requirements in requirements engineering has two dimensions: a product perspective and a process perspective. The focus of our problem here is on its product perspective. Any specication is a valid specication if and only if it is able to provide the answers to three fundamental questions of why specication?, what to specify? and how to specify? [2]. A valid specication does not have ambiguities, inconsistencies and incompleteness. Alagar et al. in [2] have suggested that one of the ways to answer the three questions is through a notion of a view, a model and behaviour in specication. In response to these three questions, a perspective and a requirements model had been proposed in [24]. In this paper, we look at the third part of the approach i.e. the behaviour in specication of requirements of the software to be built.

2.1. Objectives a. To present a mathematical model for the requirements model. b. To propose a denition of behaviour in specication of requirements with the help of the requirements model and its equivalent mathematical model. c. To propose that the much better understanding of the valid software requirements specication is possible from the SRS document using this behaviour description. To achieve these objectives in this paper, we rst discuss the requirements model followed by representation of its equivalent mathematical model. Then we present a discussion on the behaviour in the specication of requirements with the help of a tree/graph representation. Then, we conclude this paper with some suggestions on future work.

The Requirements Model and Behaviour in Specication of Requirements

71

3. The Requirements Model Figure 1 represents our requirements model. According to this model, we use two criteria to segregate the requirements in the SRS document. The requirements are considered to be the user visible external properties of the software to be built and reect behavioural and non-behavioural/quality aspects of the software. The behavioral requirements are termed as functional requirements and non-behavioural/quality requirements as non-functional requirements. Hence rstly, based on this criterion, the requirements are categorised as functional or non-functional meaning thereby that any requirement has to be either functional or non-functional. Further, various requirements gathered from the deliberations with all the stakeholders representing the external user visible properties reect varying levels of granularity. Thus using this granularity as the second criterion, the requirements are considered to be as complex (group) or atomic (single). An atomic requirement is a requirement that represents the smallest grain of a singular software property whereas a complex requirement) contains: a) one or more atomic requirements corresponding to the grains of a singular software property, or b) one or more complex requirement corresponding to the grains of various related software properties. The arrows in Figure 1 symbolize is a relationship. As shown, functional is a requirements type as well as non-functional is a requirement type too and both are mutually exclusive meaning thereby a requirement type can only be either of the two. Likewise as shown in this gure, a requirement whether functional or non-functional, can be either atomic or complex (mutually exclusive) and vice-versa. A complex requirement is further composed of complex or atomic requirements. In our model, all the complex requirements of the SRS document are bound by the parent-child relationship (inverted tree structure). Also, there exists no atomic requirement which is not a part of a complex requirement and likewise there can be no complex requirement which does not contain atomic or further complex requirements. In the SRS, complex requirements are specied as a category (textual) name whereas atomic requirements describe the actual requirement in natural language. We start the specication of requirements in the SRS with the bifurcation of all the requirements under functional and non-functional categories of complex requirements which are further classied into a hierarchy of complex and atomic requirements. Specic categories and hierarchy of the non-functional complex requirements are predened and shown in Figure 1 under non-functional requirement type. The classication of functional

72

Information and Management Sciences, Vol. 17, No. 1, March, 2006

requirements into a hierarchy of complex requirements is domain specic and depends upon the context and its environment. The functional and non-functional atomic requirements are specied at the lowest levels of this hierarchy of functional and non-functional complex requirements according to the grains of the properties of the software.

Figure 1. The Requirements Model. According to this model, the non-functional complex requirement consists of eight complex requirements namely: Security, Safety, Performance, Constraint, External Interface, Software quality, Business rules and User Documentation. If need be, the developers of the software system can append more complex requirements to these eight. The complex requirement Constraint further contains two more complex requirements i.e. Design and Implementation whereas External Interface further contains four more complex requirements i.e. Communication, User, Hardware and Software. Based upon their category, the non-functional atomic requirements are specied at the lowest levels of this hierarchy. An illustration of the hierarchy of functional and non-functional complex and atomic requirements can be found in the example in annexure 1. The attributes in our requirements model are the dening properties of atomic requirements and through atomic requirements are the dening properties of the complex

The Requirements Model and Behaviour in Specication of Requirements

73

requirements too. The attributes ensure the uniqueness of each requirement. These attributes provide the scope for the conversion of this requirements model into an equivalent mathematical model. Every atomic requirement whether functional or non-functional will have an attribute that is composed of a set of four entities: identier, version, author and weight. The identier (numeric type) is used to uniquely identify any atomic requirement. These identiers are also used to map the requirements at the conceptual level to the requirements at the logical level. The version (enumerated type) represents the version of a particular atomic/complex requirement or that of the whole SRS. The author (character type) species the name of the author of the requirement. The author name assumes signicance 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. The weight of an atomic requirement is composed of a set of three entities: priority, dependency and status. We propose to link this weight to the size of various artifacts produced during the whole SDLC. The authors are at present working on dening a new metric(s) for size of the SRS that is based on this weight. This weight property of the attribute of an atomic requirement shall also be explored further in future for the purpose of requirements management. As far as priority is concerned, we propose to put the users into dierent classes based on their role, function, level and interaction with the software system. While eliciting and validating the requirements, no emphasis is laid on the class of the user. But before formally putting requirements into the SRS document, it is 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 exibility in their jobs. Therefore, our model proposes that the priority of an atomic requirement be a set of two entities: user class (numeric type) and an abstract value (numeric type). This value is related to the quantication of the requirement. Some of the value denition methods are sound engineering judgment, simple mathematical approaches, parametric analysis, operation research methods, models & simulations etc [6]. The status of any atomic requirement can be either clear or to be determined (TBD). At times, there are certain requirements that can not be described before a particular event occurs in the SDLC, therefore these requirements can be marked as TBD and can be included later on.

74

Information and Management Sciences, Vol. 17, No. 1, March, 2006

Lastly, the third entity in the weight set is the dependency that reects the behaviour in specication. We dene 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. As shown in the Figure 1, the dependency of an atomic requirement is composed of a non-null set of pairs of association and link relation. Every atomic requirement exists with at least one association and link pair but generally multiple pairs exist because invariably an individual atomic requirement has dependency relation with a number of other atomic requirements. When an atomic requirement is associated with exactly one more other atomic requirement, it is called as single association but if an atomic requirement is associated with more than one other atomic requirement, the association is termed as multiple associations. Therefore, we say that the multiple associations are made up of more than one single association. When the association is between/amongst the atomic requirements of a single complex requirement, it is termed as direct association and when it is between/amongst the atomic requirements of dierent complex requirements it is called indirect association. Accordingly, there are four dierent types of associations identied in our requirements model: Direct-Single, Direct-Multiple, Indirect-Single and Indirect-Multiple. Direct-Single (DS) association is a single association between any two atomic requirements of a single complex requirement. Direct-Multiple (DM) associations are multiple associations amongst an atomic requirement and more than one (multiple) other atomic requirements of the same complex requirement. Indirect-Single (IS) association is a single association between any two atomic requirements of two dierent complex requirements. Indirect-Multiple (IM) associations are multiple associations amongst an atomic requirement of a complex requirement and more than one atomic requirement of one or more other complex requirements. The links supplement the associations to form complete dependency information of an atomic requirement. This denition of dependencies of requirements provides the denition of behaviour in specication of these requirements in the SRS.

4. The Equivalent Mathematical Model The requirements model depicted in Figure 1 can be further converted into an equivalent mathematical model as given below:

The Requirements Model and Behaviour in Specication of Requirements

75

Requirement = <Requirement Type, <Atomic | Complex>> Requirement Type = <Functional | Non-Functional> Functional Requirement = <<domain specic category 1 > | <domain specic category2 > | . . . <domain specic categoryn >> Non-functional Requirement = <Security | Safety | Performance | Constraint | External Interface | Software Quality | Business Rule | User Documentation> Constraint = <Design | Implementation> External Interface = <Communication | User | Hardware | Software> Atomic Requirement = <Attribute> Attribute = <Identier, Version, Author, Weight> Weight = <Priority, Dependency, Status> Dependencym = << Associationn , Linkn >, < Associationo , Linko >, . . . > Where m, n, o, . . . are the requirement identiers Association = <DS | IS | DM | IM> Where DS Direct-Single DM Direct-Multiple

IS Indirect-Single IM Indirect-Multiple In short, by grouping similar kinds of associations, we say Dependencyx = {< DS : a >, < IS : b >, < DM : m, n, . . . >, < IM : p, q, . . . >} Where a, b, m, n, p, q, x etc are the requirement identiers Priority = <User Class, Value> Status = <Clear | TBD> Where TBD: To Be Determined In a compact form, Atomic Requirement = <Identier, Version, Author, <<User Class, Value>, {< DS : a >, < IS : b >, < DM : m, n, . . . >, < IM : p, q, . . . >}, <Clear | TBD>>> & RequirementAtomic = <<Functional | Non-Functional>, <Identier, Version, Author, <<User Class, Value>, {< DS : a >, < IS : b >, < DM : m, n, . . . >, < IM : p, q, . . . >}, <Clear | TBD>>>> . . . . . . . . . . . .(1) Complex Requirement = <<Atomic1, Atomic2, . . . > | < Complex1, Complex2, . . . >>

76

Information and Management Sciences, Vol. 17, No. 1, March, 2006

5. Behaviour in the Specication of Requirements To highlight the behaviour in specication, we elaborate upon the dependencies of the weight set of the attribute of an atomic requirement. We know that the requirements in the SRS are mapped onto various design artifacts of the software system and these artifacts are reected through various components/features of this system. Since the components/features of the software system are interlinked and constantly interact with each other while the software system is in operation, these interlinkages or the behaviour, when traced back to requirements, have been represented here as dependencies among the requirements. Therefore, every atomic requirement will have a dependency relation with at least one more atomic requirement. Also, since complex requirements are made up of one or more atomic or complex requirement, dependencies of atomic requirements pertaining to complex requirements collectively contribute towards the dependencies of respective complex requirements. We use these dependencies to dene the behaviour in specication of requirements given in the SRS.
LEGENDS: Figure 2 : Tree Edge : Node SRS : Root Node F : Functional Complex Req. NF : Non-functional Complex Req. Fm : mth Functional Req. NFn : nth Non-functional Req. 01 to 19 : Atomic Reqs. identiers

Figure 2. Tree Representation of Requirements in an SRS. Using the mathematical model discussed in the Section 4, we rst convert the SRS into the equivalent mathematical representation. We depict the associations as DS/DM/IS/ IM and the links by corresponding requirements identiers (numeric). An illustration of the mathematical representation of the SRS in annexure 1 is presented in annexure 2. From the mathematical representation, a tree and/or a graph are constructed. In the tree/graph, the parent nodes represent complex functional and non-functional requirements whereas leaf nodes represent functional and non-functional atomic requirement.

The Requirements Model and Behaviour in Specication of Requirements

77

First, a tree is constructed from the requirements specied in the SRS. The root of the tree represents the SRS as whole, intermediate nodes represent hierarchy of functional and non-functional complex requirements labeled with abbreviations of their textual names and the leaf nodes represent functional and non-functional atomic requirements labeled with their respective numeric identiers. Figure 2 shows the tree representation of requirements in the SRS. It shows SRS as the root node consisting of two complex requirements (intermediate nodes F & NF), four complex functional (intermediate nodes F1, F2, F3 & F4) and two complex non-functional requirements (intermediate nodes NF1 & NF2). NF1 further consists of two complex non-functional requirements (intermediate nodes NF11 & NF12). All the lowest level complex requirements in this hierarchy contain nineteen atomic requirements as shown in the diagram as leaf nodes 01 to 19.
LEGENDS: Figure 3 : Tree Edge : DS Association & Link : DM Association & Link : IS Association & Link : IM Association & Link : Node SRS : Root Node Fm : mth Functional Req. NFo : oth Non-functional Req. 01 to : Atomic Reqs. identiers 19 in SRS

Figure 3. Dependencies in Requirements in an SRS. While constructing the tree, we do not take into consideration the dependencies i.e. association and link relations amongst various atomic requirements. Hence the behavioral aspect in the specication of requirements does not get reected. To represent the behaviour, based upon the dependency part in the mathematical representation (i.e. relation (1) in the mathematical model in Section 4), we add directed edges amongst various leaf nodes. These directed edges represent links for particular types of associations from individual atomic requirements to other atomic requirements (Figure 3). With the inclusion of association and link relations into the tree, tree gets transformed into a digraph, the tree being one of the minimum spanning trees of the said digraph. As shown

78

Information and Management Sciences, Vol. 17, No. 1, March, 2006

in the gure, atomic requirement 01 has a DS association with atomic requirement 02; 04 has DM association with 02, 03 and 06; 08 has IS association with 10; and 13 has IM association with 15, 17 and 18. This diagraph contains the minimum spanning tree of Figure 2. The behaviour of an atomic requirement having a dependency corresponding to DS/IS association and link pair is reected through a single directed edge. For DS dependency of an atomic requirement, a directed edge is drawn between two leaf nodes of the same parent node in the tree as is shown in Figure 3 by an arrow from leaf node 01 to 02, both of which belong to parent node F1. For IS dependency, an edge is drawn from a leaf node to another leaf node of a dierent parent node in the tree as is shown in Figure 3 by an arrow from the leaf node 08 of parent node F2 to leaf node 10 of parent node F3. Similarly, behavior of an atomic requirement having dependencies corresponding to DM/IM association and link is reected through multiple directed edges. For DM dependencies of an atomic requirement, directed edges are drawn from its leaf node to other leaf nodes of the same parent node in the tree. This is shown in Figure 3 by multiple arrows from leaf node 04 of F1 to leaf nodes 02, 03 and 04 of F1. For IM dependencies of an atomic requirement, edges are drawn from the leaf node of a parent node to the leaf nodes of other parent nodes in the tree. It is shown in Figure 3 by multiple arrows from leaf node 13 of F4 to leaf nodes 15 of NF12, 17 of NF2 and 18 of NF2. The number of edges for single dependencies (DS or IS) will be equal to one. The number of edges in the multiple dependencies (DM or IM) will be equal to the number of total dependencies (or association and link pairs) corresponding to the particular type of association in the dependency set. Here multiple means more than one i.e. minimum two. Therefore, number of directed edges (or links) for Direct-Multiple (DM) dependencies set for any atomic requirement (leaf node) varies from minimum two to total number of atomic requirements (leaf nodes) in its parent node minus one. We ignore the dependency of atomic requirements on themselves (that is why minus one). Similarly, the number of directed edges (or links) for Indirect-Multiple (IM) dependencies set for any atomic requirement shall vary from minimum two to total number of atomic requirements (leaf nodes) in the complete tree minus one. All the directed edges from any atomic requirement will terminate on the atomic requirements whose requirement identiers are specied as links.

The Requirements Model and Behaviour in Specication of Requirements

79

Alternatively if, CR Cn x Complex Requirement nth lowest level CR AR m cn Atomic Requirement Total no of ARs under cn
x n=1 mcn

Total no. of CRs at the lowest level of hierarchy

Therefore, Total no. of ARs in the SRS, A = For an AR of a CR: No. of DS/IS dependencies, DS=IS=1,

No. of DM dependencies, DM is 2 DM (m cn 1), No. of IM dependencies, IM is 2 IM [(

x n=1 mcn )

1].

For further illustration, we take into consideration a real life practical example of the SRS for Student Timetabling System (STS) [22], the requirements specication part of which is presented in annexure 1. The tree for this whole SRS is shown in Figure 4. This tree does not contain the behaviour part in the specication of requirements.

LEGENDS:Figure 4 STS: Root Node AR: Atomic Requirement S: CR Secruity CR: Complex Requirement F: CR Functional C: CR Constraint NF: CR Non=Functional D: CR Design UR: CR Unit Registration P: CR Performance PDU: CR Retrieving & Display Unit Info BR: CR Business Rule RG: CR Report Generation SQ: CR Software Quality n: AR identier in SRS : Tree Edge : Node Representing an Atomic/Comples Requirement

Figure 4. Tree Representation for Requirements in the SRS of STS.

80

Information and Management Sciences, Vol. 17, No. 1, March, 2006

The mathematical representation for the atomic requirement 01 (identier) of the complex requirement UR under the functional complex requirements category F of the example under consideration is reproduced below from annexure 2. This expression for the rst atomic requirement, SRS01 does not include the information about version, author, priority, status etc because this information is not relevant here for the description of behaviour in specication. This atomic requirement does not support dependencies based upon DS and IS types of associations. SRS01 = <F01: UR, <01, < {<DM: 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 13>, <IM: 17, 19, 23, 24, 26, 28, 29, 30, 31, 36, 39, 40, 41>} >, . . . >> where, F01: First functional CR UR: Unit Registration-Textual name for CR (Intermediate Node) under CR F 01: Requirement Identier of an AR (Leaf Node) of F01 CR 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 13: Requirement Identiers of those ARs of UR CR, with which AR 01 has Direct-Multiple association 17, 19, 23, 24, 26, 28, 29, 30, 31, 36, 39, 40, 41: Requirement Identiers of those ARs of CRs other than UR, with which the AR 01 has IM association SRS01 is the mathematical representation of the atomic requirement with the identier 01. As given above, it is an n-tuple entity with only some specic properties/ attributes (mainly dependencies) that are relevant in the present context. The graph shown as Figure 5 has been derived from the tree shown in Figure 4 and reects the behaviour of only the specication of atomic requirement 01. This graph also contains the minimum spanning tree of Figure 4, as shown in Figure 5. With the inclusion of the dependencies information of all functional and non-functional atomic requirements in the said graph, we can reect the complete behaviour in specication of all the requirements in the SRS. Additional reection of the behaviour in specication of requirements can be found in the metric strength, a computational complexity metric of the SRS [24]. A reection of this behaviour can also found in the metrics suggested in [23]. The metric strength represents the relative strength of various atomic and complex requirements. These relative strengths are calculated from the mathematical representation of specication of requirements according to formulae given below.

The Requirements Model and Behaviour in Specication of Requirements

81

LEGENDS:Figure 5 STS: Root Node AR: Atomic Requirement CR: Complex Requirement S: CR Secruity F: CR Functional C: CR Constraint NF: CR Non=Functional D: CR Design UR: CR Unit Registration P: CR Performance RDU: CR Retrieving & Display Unit Info BR: CR Business Rule RG: CR Report Generation SQ: CR Software Quality DE: CR Data Entry UD: CR User Documentation n: AR identier in SRS : Tree Edge : DM Association : IM Association : Node Representing an Atomic/Comples Requirement

Figure 5. Partial Digraph Containing Minimum Spanning Tree for the Requirements in the SRS of STS. Strength of an AR of a CR,
N

Si =
j=1

Li,j /N

where

Si is the strength of the ith AR of a CR, N is the total no of ARs in the CR, Li,j is the link value of ith AR with the j th AR, and Li,j = 1 if there is a link between ith and j th AR = 0 if there is no link between ith and j th AR

82

Information and Management Sciences, Vol. 17, No. 1, March, 2006

Li,j = 1 for i = j. Strength of a CR,

N N

Sn =
i=1 j=1

Li,j /(N N )

where

Sn is the strength of a CR, N is the total no of ARs in CR, Li,j is the link value of ith AR with the j th AR, and Li,j = 1 if there is a link between ith and j th AR = 0 if there is no link between ith and j th AR Li,j = 1 for i = j.

The strength of an atomic or a complex requirement or that of whole of the SRS calculated from these formulae will always be greater than 0 and less than or equal to 1. A value of the strength of an AR/CR/SRS that is nearer to 1 indicates that there is greater dependency amongst corresponding atomic requirements. Hence, in those cases we say that the AR/CR/SRS reect higher problem/computational complexity. From this we can infer that this AR/CR/SRS will be the potential candidate for greater eort and will prove to be a costlier aair in all the subsequent phases of SDLC. A value of the strength of an AR/CR/SRS that is nearer to 0 indicates that there is lesser dependency amongst corresponding atomic requirements reecting lesser/least problem/computational complexity and therefore will require lesser/least of eort and cost. This observation is also supported by our intuitive notions about the eort and cost predictions. Hence, we say that, when the requirements engineers are manufacturing the requirements, they should strive to achieve a value of strength for every AR/CR as near to zero as possible, even if an iterative process has to be undertaken for this purpose by rening/ redening/ regrouping/rearranging individual or group of atomic/complex requirements. This process eventually results in the complete understanding of the specication of software requirements of the problem domain. The denition of a view and a model i.e. the requirements model as proposed in [24] and the behaviour in valid specication of requirements proposed in this paper, leads to the satisfactory answers to the questions why specication, what to specify, and how to specify. This means that according to [2], our proposed specication in the form of the requirements model is a valid specication. The only basic assumption that we made in this paper is that our requirements model follows the recommendations in the IEEE Standard 830-1998 [11].

The Requirements Model and Behaviour in Specication of Requirements

83

6. Conclusion When the SRS of an information system is converted into the domain specic contextual view and requirements model, these two bring the behavioural part in the specication of requirements into the focus. We have shown how the explicit representation of this behaviour part in the form of dependencies and its description gives a greater insight into the requirements in the SRS of an information system. The dierent concepts proposed for this purpose are that of the requirements model itself, a mathematical model and a tree/graph for the SRS. Subsequently, this description of behaviour in specication along with the requirements model results in the much better understanding of the requirements, their specication and that of the problem domain. We have also shown that the resulting specication thus is a valid specication of software requirements at hand. This explicit specication of behaviour coupled with corresponding calculated strengths for atomic/complex requirements or that of the whole SRS can be used for reengineering those requirements that have strengths close to 1 to bring their strengths down nearer to 0. It will result in lesser development eort and costs in the subsequent phases of SDLC. Eecting various changes during any phase of the SDLC will also require lesser eorts and costs. In totality, the result will be a strong foundation for a high quality, compliant software product with maximum user/customer level satisfactions and minimum eort, time and cost factors. The authors are at present working on the development of a metric suite for the requirements model that will help the developers control the mapping of requirements specied in the SRS on to the design artifacts. Also, based upon the requirements model, we are working on a tool for the management of forward as well as backward traceability of requirements.
Annexure - 1 Software Requirements Specication of STUDENT TIMETABLING SYSTEM 1. SPECIFIC REQUIREMENTS (R) 1.1 Functional Requirements (F) 1.1.1 Unit Registration (UR)
The unit registration requirements are concerned with functions regarding unit registration, which includes students selecting, adding, dropping, and changing a unit. SRS-001: SRS-002: SRS-003: SRS-004: STS STS STS STS unit shall allow the user to register a unit. shall allow the user to delete a unit if the user has chosen to drop that unit. shall check if a unit has been lled by enough registered students. shall allow the user to add his/her name to the unit waiting list if the user wants to register in a which has been lled already with enough registered students.

84

Information and Management Sciences, Vol. 17, No. 1, March, 2006

SRS-005: STS shall automatically register the unit for the user who is the rst one on the waiting list if a vacancy appears for that unit. SRS-006: STS shall allow the user to change practical session(s) within a unit. SRS-007: STS shall allow the user to change tutorial session(s) within a unit. SRS-008: STS shall check if there are clashes between a new unit to be registered and another unit in which the user is already registered. SRS-009: STS shall warn the user if the user attempts to register more units than allowed by the program in which they are enrolled. SRS-010: 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. SRS-011: STS shall warn the user about the deadline for unit registration. SRS-012: STS shall warn the user about the deadline for dropping a unit. SRS-013: STS shall warn the user about the deadline for adding a unit.

1.1.2 Retrieving and Displaying Unit Information (RDUI)

The retrieving and displaying requirements are concerned with how information is retrieved and presented to the user. SRS-014: STS shall allow users to enter the following selection criteria to retrieve unit information: By By By By unit code, unit number, title of unit, weight of unit (credit points)

SRS-015: STS shall display the following information in a form style: Unit code, Unit number, Prerequisite unit, Catalogue number for telephone registration, Weight of unit (credit points), Title of unit, Number of hours per week, Unit supplementary fees, Sessions the unit will be oered in, A complete timetable of lectures, tutorials and practicals for the selected session showing: Type of instructions, Days of the week, Start time, Number of minutes class is scheduled per class/day, Location. SRS-016: STS shall allow the user to browse all units available. SRS-017: STS shall display how many students can register for a unit, how many students have registered the unit, and how many students are on the waiting list. SRS-018: STS shall display prerequisite unit information for the unit selected. The prerequisites unit information shall be displayed in form format, the contents of display shall be the same as stated in SRS-015. SRS-019: STS shall allow a user to retrieve his/her own registered unit information for a specied semester. The registered unit information should include unit code, unit name, oering, and grade. SRS-020: STS shall allow the user to retrieve the timetable of a particular unit or number of units by week. SRS-021: STS shall allow the user to retrieve timetable information for prerequisite units.

1.1.3 Report Generation (RG)

The report generation requirements are concerned with the report generation capabilities of the Student Timetabling System. SRS-022: STS shall have a report feature that will allow the user to generate reports. SRS-023: STS shall allow the student to print the following reports: Summary sheet of the students historical academic achievement Unit outline and description

The Requirements Model and Behaviour in Specication of Requirements

85

Timetable for selected units, and selected period SRS-024: STS shall allow administration sta to create the following reports using a report facility: Units registration summary (which includes how many students have registered in each tutorial and practical session) SRS-025: STS shall provide the capability to display the reports on the screen, to store them in a le or to output to printer.

1.1.4 Data Entry (DE)

The data entry requirements are concerned with how data is entered and validated. SRS-026: STS shall accept user input through keyboard and mouse. SRS-027: STS shall give the user an appropriate error message when the user enters a wrong PIN, wrong ID or wrong unit information.

1.2 Non-Functional Requirements (NF) 1.2.1 Security (S)

The security SRS-028: SRS-029: SRS-030: requirements are concerned with security and privacy issues. STS shall provide student ID and PIN number verication protection to protect privacy. STS shall allow the user to change his/her PIN number as required. STS shall only allow the user to read his/her own historical data. Registration sta will be able to read any students details.

1.2.2 Constraints (C) 1.2.2.1 Design (D)

SRS-031: STS shall store and retrieve persistent data. SRS-032: STS shall support PC and/or UNIX platforms. SRS-033: STS shall be developed using the JAVA programming language.

1.2.3 Performance (P)

SRS-034: SRS-035: SRS-036: SRS-037: SRS-038: STS shall respond to any retrieval in less than 5 seconds. STS shall generate a report within 1 minute. The functionality of STS shall be demonstrated in no longer than 15 minutes. STS shall be on line: 7:00am 10:00pm, Mon - Sat: 12:00am - 5:00pm, Sun. STS shall allow the user to remotely connect to the system.

1.2.4 Business Rule (BR)

SRS-039: STS shall be available for demonstration in the 3rd Year Computing laboratories by the end of week 11.

1.2.5 Software Quality (SQ)

SRS-040: STS shall be easy to learn and use.

1.2.6 User Documentation (UD)

SRS-041: The system will be accompanied by a comprehensive users manual.

Annexure - 2 Mathematical Model of Software Requirements Specication of STUDENT TIMETABLING SYSTEM Here we have used the relation Atomic Requirement = <<Functional | Non-Functional >, <Identier, Version, Author, <<User Class, Value>, {<DS: a>, <IS: b>, <DM: m, n, . . . >, <IM: p, q, . . . >}, <Clear | TBD>>>> But we have deliberately suppressed the information about version, Author, User Class, Value and Clear/TBD because this information does not play any role in the description of behaviour in specication.

86

Information and Management Sciences, Vol. 17, No. 1, March, 2006

The Figure in bold within square brackets shows the value of Strength of individual atomic or complex requirements. 1. SPECIFIC REQUIREMENTS (STS) [0.347] 1.1 Functional Requirements (F) [0.398] 1.1.1 Unit Registration (UR) [0.462]
SRS001 = <F01: UR, <01, < {<DM: 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 13>, <IM: 17, 19, 23, 24, 26, 28, 29, 30, 31, 36, 39, 40, 41>} >, . . . >> [0.610] SRS002 = <F01: UR, <02, < {<DM: 03, 04, 05, 08, 09, 10>, <IM: 17, 19, 23, 24, 26, 27, 31, 36, 39, 40, 41>} >, . . . >> [0.439] SRS003 = <F01: UR, <03, < {<DM: 01, 04, 06, 07>, <IM: 14, 15, 17, 19, 24, 31>} >, . . . >> [0.268] SRS004 = <F01: UR, <04, < {<DM: 01, 03, 05, 10, 13>, <IM: 14, 17, 26, 31, 36, 39, 40, 41>} >, . . . >> [0.341] SRS005 = <F01: UR, <05, < {<DM: 01, 03, 04, 10, 13>, <IM: 27, 31>} >, . . . >> [0.195] SRS006 = <F01: UR, <06, < {<DM: 07, 08>, <IM: 14, 15, 20, 24, 25, 26, 27, 29, 31, 36, 39, 40, 41>} >, . . . >> [0.390] SRS007 = <F01: UR, <07, < {<DM: 06, 08>, <IM: 14, 15, 20, 24, 25, 26, 27, 29, 31, 36, 39, 40, 41>} >, . . . >> [0.390] SRS008 = <F01: UR, <08, < {<DM: 01, 02, 06, 07, 09>, <IM: 23, 24, 27, 31>} >, . . . >> [0.244] SRS009 = <F01: UR, <09, < {<DM: 02, 05, 10, 11, 12, 13>, <IM: 26, 36, 39, 40, 41>} >, . . . >> [0.293] SRS010 = <F01: UR, <10, < {<DM: 01, 02, 04, 06, 07, 08, 09, 11, 12, 13>, <IM: 14, 15, 17, 23>} >, . . . >> [0.366] SRS011 = <F01: UR, <11, < {<DM: 01, 12, 13>, <IM: 14, 15, 17, 23>} >, . . . >> [0.195] SRS012 = <F01: UR, <12, < {<DM: 02, 11>, <IM: 14, 15, 17, 23>} >, . . . >> [0.171] SRS013 = <F01: UR, <13, < {<DM: 01, 09, 10, 11>, <IM: 14, 15, 16, 17, 18, 19, 23, 24>} >, . . . >> [0.317]

1.1.2 Retrieving and Displaying Unit Information (RDUI) [0.516]

SRS014 = <F02: RDUI, <14, < {<DM: 15, 17, 18, 19, 20, 21>, <IM: 06, 07, 23, 24, 25, 26, 27, 30, 31, 34, 36, 39, 40, 41>} >, . . . >> [0.512] SRS015 = <F02: RDUI, <15, < {<DM: 16, 17, 18, 19, 20, 21>, <IM: 26, 27, 36, 39, 40, 41>} >, . . . >> [0.317] SRS016 = <F02: RDUI, <16, < {<DS: 15>, <IM: 01, 23, 26, 34, 36, 39, 40, 41>} >, . . . >> [0.244] SRS017 = <F02: RDUI, <17, < {<DM: 15, 16, 19>, <IM: 01, 04, 24, 26, 31, 35, 36, 39, 40, 41>} >, . . . >> [0.341] SRS018 = <F02: RDUI, <18, < {<DM: 14, 15>, <IM: 02, 26, 31, 34, 35, 36, 39, 40, 41>} >, . . . >> [0.293] SRS019 = <F02: RDUI, <19, < {<DM: 14, 15>, <IM: 12, 13, 26, 27, 31, 34, 35, 36, 39, 40, 41>} >, . . . >> [0.341] SRS020 = <F02: RDUI, <20, < {<DM: 14, 15, 21>, <IM: 23, 26, 27, 31, 34, 35, 36, 39, 40, 41>} >, . . . >> [0.341] SRS021 = <F02: RDUI, <21, < {<DM: 14, 15>, <IM: 02, 06, 07, 11, 12, 13, 22, 23, 25, 26, 27, 31, 34, 35, 36, 39, 40, 41>} >, . . . >> [0.512]

1.1.3 Report Generation (RG) [0.750]

SRS022 = <F03: RG, <22, < {<DM: 23, 24, 25>, <IM: 01, 03, 06, 07, 10, 14, 15, 17, 18, 19, 20, 21, 26, 27, 31, 35, 36, 39, 40, 41>} >, . . . >> [0.585] SRS023 = <F03: RG, <23, < {<DS: 25>, <IM: 01, 02, 06, 07, 10, 19, 20, 21, 26, 27, 28, 30, 31, 35, 36, 39, 40, 41>} >, . . . >> [0.488] SRS024 = <F03: RG, <24, < {<DS: 25>, <IM: 01, 02, 04, 06, 07, 10, 26, 27, 28, 29, 30, 31, 35, 36, 39, 40, 41>} >, . . . >> [0.463] SRS025 = <F03: RG, <25, < {<DM: 22, 23, 24>, <IM: 26, 27, 28, 29, 30, 31, 34, 35, 36, 39, 40, 41>} >, . . . >> [0.390] 10 1.1.4 Data Entry (DE) [1.000] SRS026 = <F04: DE, <26, < {<DS: 27>, <IM: 01, 02, 04, 06, 07, 10, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 29, 30, 32, 38, 39, 40>} >, . . . >> [0.634] SRS027 = <F04: DE, <27, < {<DS: 26>, <IM: 01, 02, 04, 06, 07, 10, 14 , 15, 16, 17, 18, 19, 20, 21, 23, 24, 25, 28, 29, 30, 31, 34, 41>} >, . . . >> [0.610]

The Requirements Model and Behaviour in Specication of Requirements

87

1.2 Non-Functional Requirements (NF) [0.388] 1.2.1 Security (S) [0.889]

SRS028 = <F05: S, <28, < {<DM: 29, 30>, <IM: 01, 24, 26, 27, 31, 41>} >, . . . >> [0.220] SRS029 = <F05: S, <29, < {<DS: 28>, <IM: 01, 26, 31, 39, 41>} >, . . . >> [0.171] SRS030 = <F05: S, <30, < {<DM: 28,29>, <IM: 01, 26, 31, 39, 41>} >, . . . >> [0.195]

1.2.2 Constraints (C) [0.556] 1.2.2.1 Design (D) [0.556]

SRS031 = <NF01: {C, D}, <31,< {<DS: 33>, <IM: 02, 03, 04, 05, 06, 07, 08, 10, 14, 15, 16, 17, 18, 19, 20, 21, 23, 24, 25, 26, 27, 29, 30, 34, 35, 38>} >, . . . >> [0.683] SRS032 = <NF01: {C, D}, <32, < {<IM: 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 27, 28, 29, 30, 34, 35, 36, 38, 39, 40, 41>} >, . . . >> [0.585] SRS033 = <NF01: {C, D}, <33, < {<DS: 31>, <IM: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 34, 35, 38>} >, . . . >> [0.854]

1.2.3 Performance (P) [0.520]

SRS034 = <NF02: P, <34, < {<DM: 35, 38>, <IM: 15, 17, 18, 19, 20, 21, 23, 24, 25, 26, 27, 30, 31, 32, 33, 41>} >, . . . >> [0.463] SRS035 = <NF02: P, <35, < {<DS: 38>, <IM: 22, 23, 24, 25, 26, 30, 31, 32, 33 >} >, . . . >> [0.268] SRS036 = <NF02: P, <36, < {<IS: 39>} >, . . . >> [0.049] SRS037 = <NF03: P, <37, < {<DS: 36>} >, . . . >> [0.049] SRS038 = <NF03: P, <38, < {<DM: 34, 35, 36, 37>, <IM: 39, 40, 4>} >, . . . >> [0.195]

1.2.4 Business Rule (BR) [0.098]

SRS039 = <NF04: BR, <39, < {<IM: 34, 35, 38>} >, . . . >> [0.098]

1.2.5 Software Quality (SQ) [0.049]

SRS040 = <NF05: SQ, <40, < {<IS: 39>} >, . . . >> [0.049]

1.2.6 User Documentation (UD) [0.049]

SRS041 = <NF06: UD, <41, < {<IS: 39>} >, . . . >> [0.049]

References
[1] Aggarwal, K. K. and Singh, Y., Software Engineering: Programs, Documentation & Operating Procedures, New Age International Publishers, New Delhi, pp. 144-145, 2001. [2] Alagar, V. S. and Periyasamy, K., Specication of Software Systems, Springer-Verlag, New York, Inc., pp.22-25, 1998. [3] Batra, D. and Davis, J. G., Conceptual data modeling in database design: similarities and dierences between expert and novice designers, International Journal Man-Machine Studies, Vol.37, pp.83-101, 1992. [4] Carroll, J. and Swatman, P. A., The process of deriving requirements: learning form practice, Proceedings of the Ninth Annual Australian Conference on Information Systems, Sydney, Australia, 1998. [5] Christel, M. G. and Kang, K. C., Issues in Requirements Elicitation, ESC-TR-92-012CMU/SEI-92TR-12, Software Engineering Institute, Carnegie Mellon University, Pittsburgh Pennsylvania 15213, 1992. [6] Fenton, N. E. and Peeger, S. L., Software Metrics: A rigorous and Practical Approach, 2nd Edition, pp.245, International Thomson Computer Press, 1996. [7] Guindon, R., Knowledge exploited by experts during software system design, International Journal Man-Machine Studies, Vol.33, pp.279-304, 1990.

88

Information and Management Sciences, Vol. 17, No. 1, March, 2006

[8] Guindon, R., The Process of Knowledge Discovery in System Design, Salvendy G., and Smith M. J. (eds), Designing and Using Human-Computer Interfaces and Knowledge Based Systems, Elsevier Science Publisher, Amsterdam, Netherlands, pp.727-734, 1989. [9] Hammer, T. F., Human, L. L. and Rosenberg, L. H., Doing requirements right the rst time, Crosstalk - The Journal of Defense Software Engineering, pp.20-25, December 1998. [10] Harker, S., Eason, K. and Dobson, J., The change and evolution of requirements as a challenge to the practice of software engineering, Proceedings of the IEEE International Symposium on Requirements Engineering, San Diego, California, USA, IEEE Computer Society Press, pp.266-272, January 1993. [11] IEEE Recommended Practice for Software Requirements Specication, Institute of Electrical and Electronics Engineers, New York, IEEE Standard 830-1998, IEEE, 1998. [12] IEEE Std 610-1990: Glossary of Software Engineering Terminology, Institute of Electrical and Electronics Engineers, New York, IEEE Standard 610-1990, IEEE, 1990. [13] Jalote, P., An Integrated Approach to Software Engineering, Narosa Publishing House, New Delhi, 2nd Edition, pp.76-79, 2001. [14] Jeries, R., Turner, A. A., Polson, P. G. and Atwood, M. E., The Processes Involved in Designing Software, Anderson J. R., (ed.), Cognitive Skills and Their Acquisition, Lawrence Erlbaum Associates Publishers, Hillsdale, New Jersey, Chapter 8, pp.255-283, 1981. [15] Khushalani, A. J., Modeling and supporting opportunistic design problem solving, Ph.D. Thesis, School of Computer Science and Software Engineering, Swinburne University of Technology, Melbourne, Australia. [16] Lamsweerde, A. V., Requirements engineering in the year 2000: a research perspective, Proceeding of International Conference of Software Engineering 2000, (ICSE 2000) Limerick, Ireland, pp.5-19, June 2000. [17] Loucopoulos, P. and Champion, R. E. M., Knowledge-based support for requirements engineering, Information and Software Technology, Vol.31, No.3, pp.123-135, 1989. [18] Loucopoulos, P. and Karakostas, V., System Requirements Engineering, McGraw-Hill Book Company, Berkshire, pp.13-15, 1995. [19] Malhotra, A., Thomas, J. C., Carroll, J. M. and Miller, L. A., Cognitive processes in design, International Journal Man-Machine Studies, Vol.12, pp.119-140, 1980. [20] Myers, G. J., Software Reliability: Principles and Practices, John Wiley & Sons, New York, 1976. [21] Nguyen, L. and Swatman, Essential and Incidental Complexity in Requirements Models, Proceedings of Fourth conference on Requirements Engineering, 2000, IEEE Society, 2000. [22] Richard, D., Student Timetabling System, (cMacquarie University, 2000) Version 1.0, University of Calgary, 2000. [23] Sood, M., Sabharwal, S. and Singh, Y., A Step towards the Requirements Model Metric Suite, Proceedings of the International Conference on Computing, Communication & Control Technologies (CCCT 04) at The University of Texas, Austin, Texas, USA, 14th to 17th August 2004. [24] Sood, M., Sabharwal, S., and Singh, Y., A systematic approach to measure the problem complexity of software requirements specication of an information system, International Journal of Information and Management Sciences, Vol.15, No.1, pp.69-90, March 2004. [25] Sommerville, I., Software Engineering, Addison-Wesley Publishing Company, 1992. [26] Visser, W., Designers Activities Examined at Three Levels: Organisation, strategies and problemsolving processes, Knowledge-Based Systems, Vol.5, No.1, pp.92-104, 1992.

Authors Information
Manu Sood is currently is working as Senior Lecturer, Department of Computer Science, Himachal Pradesh University, Summer Hill, Shimla, Himachal Pradesh, India. He is pursuing Ph.D. programme

The Requirements Model and Behaviour in Specication of Requirements

89

from the Division of Computer Engineering & Information Technology under the Faculty of Technology, Delhi University. He received his degree in M.Tech. (INFORMATION SYSTEMS) with gold medal from Division of Computer Engineering & Information Technology, Netaji Subhas Institute of Technology, Dwarka, New Delhi. He has more than 17 years of professional experience in dierent elds at dierent levels. 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 67@yahoo.com Tel: 91-177-2832569.

Sangeeta Sabharwal is currently working as Assistant Professor and Associate Head, Division of Computer Engineering and Information Technology at Netaji Subhas Institute of Technology, New Delhi, India. She received her Ph.D. in Computer Engineering from Faculty of Technology, Delhi University in 2001 with specialization in Software Engineering. Her current research interests include Requirements Engineering, Meta-modelling, Process Modelling and Data warehousing. Division of Computer Engineering & Information Technology, Netaji Subhas Institute of Technology, Sector-3, Dwarka, New Delhi-110045, India. E-mail: ssab@nsit.ac.in Tel: 91-11-25099036.

Yogesh Singh is at present Dean & Professor, School of Information Technology, Guru Gobind Singh Indraprastha University, Kashmere Gate, Delhi.-110006, India. He received his Ph.D. in Computer Engineering from National Institute of Technology, Kurukshetra (previously known as Regional Engineering College, Kurukshetra). 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 100 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 elds. 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 CoreGroup 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 by 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: ys@ipu.edu Tel: 91-11-23862856.