Theoretically, every software project can be successful if it has unlimited resources and does not care about the pro t. Because this is not true in practice, the feasibility study is an important step in the software project initial phase. To achieve a valuable analysis, it is important to identify crucial aspects related to the feasibility. Most of the aspects come from the software product requirements. An original method for identifying and documenting inputs to a feasibility study is presented in this paper. The method takes the requirements on the software product and provides a structured quanti ed framework for analysis of the requirements' impacts on the project infrastructure needs. The method formalism is based on the theoretical background of systems theory and modelling.
The feasibility study (or the analysis of alternatives 1) is used to justify a project.
It compares the various implementation alternatives based on their economic,
technical and operational feasibility [
{ Technologies to cooperate with / integrate with. 4. Assess the operational feasibility for each alternative. The main question is \Is it possible to maintain and support this application once it is in production?" 5. Choose an alternative.
We will let aside the operational feasibility which is not so tightly related to
the requirements engineering compared to the remaining feasibilities (economic
and technical). The requirements analysis implies many input parameters to the
feasibility study and the feasibility study implies input parameters to the De ne
Infrastructure stage [
The starting point for the method is the demand that the transformation of the requirements to the feasibility study (further denoted as RFST, requirements-feasibility study transformation) should have the following attributes: { structured, so that the logic of the transformation is easy to comprehended, { recordable, so that the conclusions may be veri ed and/or used for increasing the evaluation accuracy in the future, { traceable, so that the conclusions may be analysed and audited.
Here follows an original method based on the analogy between the software project and the systems theory and modelling that provides a quanti ed structured framework for this transformation.
The method is based on the analogy between systems theory and software
project. A formal model of a general system consists generally of inputs, outputs,
inner elements and relations [
parametres, { technology environment for running
the product, { documentation and other artefacts, { trainings { team (project roles), { subcontractors, { tools (both development and
supporting), { artefacts (code and documentation) { process, { project management, { intra-team communication, { subcontractors communication.
IE O P RI I = IS [ IE relations from inside information to the customer to outside relations from outside inside information about the requirements changes
RIO ROI relations from inside cooperation requests to customer from RIOI to outside and to the team inside relations from team responds to immediate customer ROIO outside to inside and requests for cooperation outside relations (union) all relations
R = ROIO [ RIOI [ ROI [ RIO [ RI
Inner elements may be based on the concrete purpose and goal of the model { objects, { classes.
Objects are chosen in the case when it is necessary to model the project system in a detailed level of single objects: documents, team roles, etc. In general methodological models, classes will be usually used. Each element then represents a whole class, not an individual object: e.g. \programmer" represents all the programmers; We do not care about structure and dynamics of objects inside the class. For the purpose of this paper, we will assume that all the inner elements are classes.
Now we can speak about software project management from the perspective of systems modelling. Input-output mappings constitute functional requirements. The inputs are given (the customer speci es the requirements). The outputs are implied by the inputs. This implication is methodologically not trivial at all, however we may assume that the outputs are created according to some best-practices and their characteristics are thus given. Inputs and outputs are thus out of our management attention here, while the other elements are the core of software process management: { inner elements, { relations between inner elements, { relations from inside to outside.
Managing the software project thus means managing those elements. It may be also comfortable to work with groups of those elements: De nition 1. Project factor is { An inner element. { A relation between inner elements, { A relations from inside to outside, { Any sub graph of a graph consisting of a set of nodes P and a set of edges
RI [ RIO.
The set of project factors will be denoted C.
If we suppose, that the goal of the project is to achieve the relation between the inputs and outputs, then the project management means ne-tuning the project factors. This happens based on the inputs and represents an adaptation of the project system according to inputs in such a way, that the project system achieves its goal in an optimal way, i.e. with minimum resources (time and costs).
Generally, there are two possibilities how to detect an adaptation need:
1. Adaptation ex post, that is based on past. The adaptation driver is
discrepancy between outputs and inputs. This type of adaptation is used in the
Adaptive Software Development (ASD) methodology [
csub(sj ) =
sub(sj ; sk); n
X k=1;k6=j where n is the number of project factors.
The above formal model as a general software project model may be used for further research by introducing appropriate relations and factors in the system model. The method for supporting the RFST is based on introducing the relation representing demands on adaptation for the project system: De nition 2. Demand dem(a; s) of the input a for the project factor s, where a 2 I and s 2 C is a mapping I C onto an ordinal scale h0; 10i. 0 means, that the input a does not require the adaptation of the factor s. The higher the value, the higher the adaptation needs.
As for the relations between the inner elements, substitutability has been chosen to be included in the method. Demands for adaptation of one factor may be mitigated by substitution of another factor. An example may be providing training to team members instead of hiring a new needed expert role (or vice versa). Substitutability is de ned as: De nition 3. Substitution of project factors s1 and s2 sub(s1; s2), where s1; s2 2 C, is a mapping C C onto an ordinal scale h0; 10i. The substitution represents a possibility of substituting a demand for project factor s1 by a substitute s2. In case where substitution is not possible, the function has value 0. The higher value, the higher substitutability. The value 10 means perfect substitutes.
Individual demands for factor adaptation are added and we get the total demand: De nition 4. Di erence of the factor sj , where j = 1; : : : ; n is the value of the function dif (sj ), that assigns a non-negative whole number to every project factor sj 2 C: dif (sj ) = m X dem(ai; sj ) i=1 where ai is input, n is the number of project factors and m is the number of inputs.
A factor may be substituted by substitutes, which is covered by the following de nition: De nition 5. Total substitution of the project factor sj , where j = 1; : : : ; m is the value of the function csub(sj ), that assigns a non-negative whole number to every project factor sj 2 C: (1) (2)
The resulting demands for factor adaptation may be thus mitigated by inner substitution relations. We get the resulting di erence of the factor: De nition 6. Resulting di erence of the project factor bj is the function vdif (bj ) = max(0; dif (bj ) csub(bj )) (3)
The resulting di erence represents overall clean demands for factor adaptation. Factors with highest values are the most crucial topics for the RFST, however also high di erences mitigated by high substitutions will result in an action (ensuring the substitution works).
The next step in the method construction is to select appropriate inputs and project factors. The sets I and C are naturally very large. For practical applications it is necessary to specify a subset of the inputs I2 I and a subset of the project factors C2 C. Ideal attributes of those sets should be: { completeness, { independence, { minimalism.
In practice, it is very hard to achieve perfection in all those parameters and we make a balance between completeness and model comprehensibility and manageability, for the time complexity of processing all demands according to the de nition is (jI2j jC2j).
During the method development, 32 inputs and 57 factors were included
in the method. Software product quality characteristics and subcharacteristics
according to ISO/IEC 9126-1 [
The process of evaluating the inputs for RFST using the method is as follows:
1. Requirements gathering. Requirements gathering by ordinary methods
(interviews, questionnaires, etc.) [
Please contact the author of the contribution if interested. 3. Requirements analysis. This step means identi cation and quanti cation of demand functions. For all the pairs of inputs and factors, we analyse whether the input implies some sort of adaptation of the project infrastructure. For factors that are not present in the project infrastructure yet, the adaptation means the adoption of this factor. The demand value then represents the complexity of the factor implementation. 4. Di erence function evaluation according to the Equation 1. 5. Substitution functions and total substitutions evaluation. For the factors with high di erences, the high adaptation demand may be mitigated by identifying some substitution relations. Substitutions for each factor are then summed according to the Equation 2. 6. Resulting di erences evaluation according to the Equation 3. 7. Results interpretation. Non-zero resulting di erences represents overall clean demands for factor adaptation and are thus a topic for the RFST. Generally, the higher the value, the higher the overall adaptation needs. Factors with highest values are the most crucial topics for the RFST, however also high di erences mitigated by high substitutions need attention (ensuring the substitution takes place). For a further discussion about results interpretation see the next section.
The quanti cation of the demand and substitution values is performed based on expert estimations of the method's user. The correctness of the values and thus the correctness of the results depends on the ability of the user to estimate the adaptation needs and to assign ordinal numbers to them.
If the method's user sticks to the recommended ordinal scale h0; 10i, the values of the resulting di erences lie in the interval h0; 10mi, where m is the number of inputs. The upper limit represents the situation when all the inputs imply the maximum demand.
For each speci c input set it is necessary to de ne certain results interpretation ranges having an adequate message. For example for the set of 32 inputs the resulting di erences are in the range h0; 320i and we may decide to de ne the following ranges categories: 1. The range h0; 50i means \Neglectable adaptation need". 2. The range h51; 250i means \Necessary to adapt". 3. The range h251; 320i means \Too high adaptation needs".
When interpreting the values, it is necessary to keep in mind that the resulting di erence is a scalar value, while the demands have in nature also various qualitative characteristics, as well. Those qualitative characters are not expressed in the calculation. Thus situations may occur, when two demands for adaptation may even neutralise each other. The resulting di erence value represents just a sum of all the demands. Its high value represents the message \this factor needs an attention" and must be interpreted correctly according to the nature of demands that contribute to it.
Let us illustrate the whole concept on a small example. Let us imagine that we need to develop an information system for a cattle farm. The information system should be used to administrate information about the cattle, the information about the veterinary inspections and the lactation data.
Let us suppose that we chose the quality characteristics according to ISO/IEC
9126-1 [
As for the project factors C2, let us suppose, we use the following factors in several categories: { team characteristics: { quali cation, { personal stability, { personal commitment, { roles: { team leader, { analyst, { developer, { tester, { technical writer, { subject matter expert. { process: { development process exibility, { risk management, { quality assurance.
We gather requirements using suitable methods, structure them, map them to the inputs and evaluate the demands. For simplicity of the example, let us assume that we learnt that the information system must be highly reliable and this makes demands for our team quali cation, on the tester role and also makes the quality assurance process a crucial one. The project is large and complex and the schedule is tight. It makes demands for the team commitment. Unfortunately, it looks like the team commitment is not high and needs increasing, fortunately, the team is at least stable and the personality of the team leader makes him a team authority. Users request the possibility of remote lactation data gathering. This will be solved by porting the solution to mobile devices. This portability of the solution will require more team quali cation and will enhance demands for the tester role and overall quality assurance.
First, we ll in the demands table Table 2. Only rows and columns with at least one non-zero demand are shown.
Inputs a reliability
functionality portability s team quali cation 6 sro commitment 0 tca tester role 3 Fquality assurance 8 2 8 0 0 5 0 8 5 dif (s) 13 8 11 13
Next, we quantify the substitution functions like: sub(commitment, personal stability) = 2 sub(commitment, team leader role) = 3
By incorporating these substitutions we obtain a table with resulting di erences (Table 3).
Total di erence dif (s)
Total Resulting substitution di erence csub(s) vdif (s) s team quali cation 13 sro commitment 8 tca tester role 11 Fquality assurance 13 0 5 0 0 13 3 11 13
The feasibility study is a crucial input to decision about the go/not-go for a project. In the case of software projects, a quality feasibility study has a great importance, because the success rate of the software projects is far from 100% (Standish Group CHAOS reports). One of the input sources for the feasibility study are the resulting software product requirements.
The presented method provides a way how to quantify the impact of user requirements and other software project aspects on the project infrastructure. The demands for infrastructure changes resulting from the requirements represent required adaptation that should take place for the project to be successful. The presented method represents one possible approach to this issue and meets the stated criteria: to be structured, recordable and traceable. It is based on the analogy between the system modelling and a software project and formalizes the software project as a system with inputs, outputs and inner structure which is represented by project factors crucial in the project management.
The presented example should provide the reader with a feeling how the method works and how it can be used. In this simple example, the conclusions may be made just with common sense, but in real situations, typically tens of inputs and factors will be involved and the conclusions will not be that apparent.
The selection of appropriate inputs and project factors sets is an import step of the method. The balance between the accuracy and the manageable number of elements should be maintained.
The method does not automate the process, but helps to cope with the analysis in a structured, manageable way that simpli es discussion, reasoning and makes decision making process a recordable, traceable action with better reuse options. The method also inspires the user to think about possible relations between the requirements and the infrastructure, which serves as a kind of checklist for not forgetting some important issue.
The economic aspects of the analysis are not covered in the method, however they should be taken into account during the analysis: e.g. when deciding about the possible substitutions. Enhancement of the method in this area is one of the topics of the further development.
The method is now being further developed and tested in practice with the support of the IZMAN project (see Acknowledgement).
The research was supported by the Ministry of Education, Youth and Sports of the Czech Republic (Grant No. 2C06004 Information and knowledge management IZMAN).