A Systematic Approach to Measure the Problem ... - Semantic Scholar

Information and Management Sciences Volume 15, Number 1, pp.69-90, 2004

A Systematic Approach to Measure the Problem Complexity 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 information systems in the given environment. This may be due to increasing complexity of information systems and their development strategies. While functioning in an environment, 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 components 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 developers are: size, structural, environmental, application domain and communicational complexities [1]. Fenton et al. interpret the complexity for the software systems depending 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 paper, 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 decomposition 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 objectives 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: requirements engineers, customer who commissions the system, users who ultimately interact 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, requirements are generally specified in a natural language so that all the stakeholders especially

72


the users and the customers understand what is being specified and developed. 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 the estimated budget. Traditional view of requirements of a candidate system focused only on the functionality 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 nonfunctional requirements as ‘quality requirements’. A. M. Davis describes them as nonbehavioural requirements in contrast to behavioural i.e. functional requirements [4]. According 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 activity 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 Requirements 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, modifiability, traceability etc. The activity of validation ensures that the problem is well


73

understood and the user/customer agreement is obtained on what constitutes a valid description of their problem. The human psychology makes the task of collecting requirements a difficult task because of the human tendency of expressing uncertain desires in an ambiguous language. Some interesting statistics can be found in [15] and [6]. Karl E. Wiegers in [17] describes four techniques to be used to greatly reduce the expectation gap between the system customer really needs to solve his problems, and the system developer decides to build for him. The quality of requirements specified has a direct bearing on the quality of the software, 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 engineered 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 dimensional 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 attributes to be measured. Three classes established in software for the purpose of measurement 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 fundamental attributes: length, functionality and complexity. Length is the physical size of the

74


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 (computational) complexity of software requirements specifications as specified in the SRS document, of an information system. We have measured the complexity of software requirements 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 problem/computational complexity of the information system. We propose that the requirements in the software requirements specifications should strive to achieve the strengths nearer to zero, which can be interpreted as minimizing the problem/computational complexity 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.


75

For the purpose of practical application, a real life example of the software requirements 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 (attributes) 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 , and . 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 dependencies depicts the behaviour of various perspectives that are the objects of interests in this model. Likewise, we have three ordered dependency pairs i.e. , , and at level 3, which show dependency of requirements on application, system and organization views respectively. Similarly, we derive design perspective from software requirement perspective and so on. Also the dependency pairs for the test perspective at level 6 can be derived from software requirements, design and program perspectives at levels 3, 4 and 5 respectively.

76


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 complexities 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


77

strength, straight away from the SRS document, which will ultimately help in estimation of size, time, cost and productivity of the target system. We consider a requirement to be either atomic or complex. The complex requirements 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 =

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 conditions 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, performance, security, software quality, external interface, business rules and user documentation [10] (Figure 5). These requirement types too are mutually exclusive.

78


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 requirements can be specified as shown in Figure 7.

Figure 7. External interface.


79

4.2. Attributes: The attributes are the defining properties of requirements and ensure the uniqueness of each requirement. We propose that the attributes related to each requirement can be defined as a 6-tuple, composed of an identifier, dependency, version, priority, author and status as shown in Figure 8. Attribute =

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 = {< Associationm , Linkm >, , . . .}

Figure 9. Dependency attribute of a requirement.

80


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 (mutually 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 association. 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.


81

Most of the requirements specified in the SRS are susceptible to changes a no. of times during the SDLC and may even change a number of times during the requirements 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 = The value is related to the quantification of the requirements. In the absence of quantification, there is an excellent chance for failure of software system in the form of: (1) exceeding the minimum necessary cost due to over-design, or (2) failing to account for needed capability, thus reducing item value to the customer. This logic may not be always accepted. Some of the value definition methods are sound engineering judgment, simple mathematical approaches, parametric analysis, operation research methods, models & simulations etc. [9].

82


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.


83

4.3. Dependency matrix: Dependency matrix in this context is the matrix, which is generated using values of notational representations prescribed for the requirements in accordance with the requirements model. Dependencies, which are part of the definition of any requirement, are used to fill the matrix rows and columns. For a particular requirement identifier represented by a single row in the dependency matrix, the values of links in terms of ‘0’ or ‘1’ are entered in the corresponding columns represented again by the requirements identifiers. A ‘0’ represents no link, whereas a ‘1’ represents the presence of a link between a particular requirement and another requirement. Also, a ‘1’ is used to represent the link of a particular requirement to itself. The notation of a requirement gives us the dependency pairs in terms of the type of association followed by all the requirement identifiers for that type of association. To construct a dependency matrix, a particular requirement in the particular category/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/subcategory of requirement(s) is ready, it is used to calculate the strengths for the individual requirements as well as for the category/sub-category as a whole. Strengths are calculated from the dependency matrices according to the formula as given below.

84


The formulae for calculating the strength of an individual requirement is: Si =

N

Li,j

N

j=1

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 j t h requirement, and Li,j = 1 for i = j Strength of a Category/sub-category of requirements is given by: S=

N N

Li,j

(N ∗ N )

i=1 j=1

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/subcategories 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 requirement 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


85

they are enrolled in for an individual semester. The system must assist the student in avoiding timetable clashes. The requirements, 41 in total, in this SRS have been categorized 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) Performance (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 matrices 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 = < F 01 : U R, < 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 = < F 01 : U R, < 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 = < F 01 : U R, < 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 = < F 01 : U R, < 4, < {< DM : 1, 3, 4, 5, 10, 13 >, < IM : 14, 17, 26, 31, 36, 39, 40, 41 >} >, . . . >>

86


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 = < F 01 : U R, < 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 = < F 01 : U R, < 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 = < F 01 : U R, < 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 = < F 01 : U R, < 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 = < F 01 : U R, < 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 = < F 01 : U R, < 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 = < F 01 : U R, < 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 = < F 01 : U R, < 12, < {< DM : 2, 11, 12 >, < IM : 14, 15, 17, 23 >} >, . . . >>


87

SRS013: STS shall warn the user about the deadline for adding a unit. SRS013 = < F 01 : U R, < 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 = < N F 03 : 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 = < N F 03 : 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 =< N F 03 : P, < 36, < {< DM : 36 >, < IM : − >} >, . . . >> SRS037: STS shall be available for demonstration in the 3rd Year Computing laboratories by the end of week 11. SRS037 = < N F 03 : 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 =< N F 03 : P, < 38, < {< DM : 34, 35, 38 >, < IM : − >} >, . . . >> SRS< n >: Identifier of nth requirement, F< m >: mth sub-category of functional category of requirements, NF< p >: pth sub-category of non-functional category of requirements, DM: Direct-Multiple association, IM: Indirect-Multiple association, UR: Unit Registration, P: Performance

88


As can be seen from the strengths calculated above, the strengths of individual requirements 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 registration 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 13 12 11 10 9 8 7 6 5 4 3 2 1

S

1 1 1 1 1 1 1 1 1 1 1 0 1 0.923

Dependency Matrix

2

0 1 1 1 1 0 0 1 1 1 0 0 0 0.539

Performace

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

38 37 36 35 34

1

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

10 1 1 0 1 0 1 1 1 1 1 1 1 1 0.846

Sub-category Strength

11 1 0 0 0 0 0 0 0 0 0 1 1 1 0.308

= 0.560

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 Figure 13. Dependency matrices and average strengths.

6. Conclusion The SRS document, written in natural language, serves the purpose of formal contract between the user and the developer of the software of an information system. This


89

document reflects the problem complexity of the information system. We felt a need to measure this complexity and define metrics for it. These metrics can then be associated in deriving some estimates related to the development of software. As such, very little work has been done in this area i.e. deriving estimates directly from the SRS. In this work, we have defined a problem complexity metric, strength. It measures the relative strength(s) of the requirements specified with in the SRS document, from the values of their dependencies. To arrive at this metric, a requirements model has been proposed that provides the necessary base for the measurement. We have supported this work with a real life example and the metric calculated successfully. We conclude that the strengths of the individual orcategory/sub-category of requirement(s) will be always less than or equal to unity. A value nearer to one indicates that the particular requirement(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 Company, Berkshire, 1995. [12] Pressman, R. S., Software Engineering-A Practitioner’s Approach, McGraw Hill, 2001.

90


c [13] Richard, D., Student Timetabling System, (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’ Information Yogesh 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: ys66@rediffmail.com

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 Engineering 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 Warehousing. Division of Computer Engineering, Netaji Subhas Institute of Technology, Sector-3, Dwarka, New Delhi 110045, India. E-mail: ssab23@rediffmail.com

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