Measuring the efficiency and effectivity of
requirement engineering
A.G.P. Sterk
April 2007
Measuring the efficiency and effectivity of
requirement engineering
By
Bertin (A.G.P) Sterk
April 2007
University of Groningen, The Netherlands Faculty of Economics
Supervisors:
Prof. Dr. E.W. Berghout
Drs. ing. A.L. Commandeur
Student number: S1446452 Telephone: 06-55163789 E-mail: a.g.p.sterk@student.rug.nl
Preface
This master thesis has been written as a final assessment for my Master of Science & Business Administration study at the faculty of economics of the University of Groningen in the Netherlands. The specialisation I chose in this master study is the specialisation Business & ICT.
The department Business Solutions at ABN AMRO bank provided me with a daring assignment of which this thesis is a result.
After my introduction at the management support department of Business Solutions the first challenge was to get to know the entire process of Business Solutions and get to know who was responsible for which part. The second challenge turned out to be further specification of the objectives of this study. Every manager had its own thoughts, goals and intentions about a measurement method of efficiency and effectivity.
After these first challenges the solving of the problem still had to begin. After all these challenges I am pleased to be able to present this master thesis. I am also delighted to return ABN AMRO a solution of the problem that was presented to me.
To write and finish this master thesis would not have been possible without the help of others. First of all I would like to thank Willem Wulffraat, who functioned as my supervisor at Business Solutions. The brainstorming sessions with Willem provided me with a basic principle, a clear objective for my research, and helped me to stay on the right track. Second I would like to thank Wieger Dijkstra, who gave me the assignment. Thirdly my thanks go to the support and advice that I received from Arnold Commandeur, who has spent a lot more hours in guiding my master thesis than is obligated by the University of Groningen for a supervisor. As fourth I would like to thank Egon Berghout, Steef Peters and Peter Schuurman for their effort and advice they offered me. Finally my gratitude goes to Inger Verschoor who made it possible for me to spend most of my time on writing this thesis.
I am especially proud that ABN AMRO has adopted the method presented in this report. Currently Business Solutions of ABN AMRO is using my measurement methods for evaluating the efficiency and effectivity of requirements engineering. The implementation report and manual that I produced working at ABN AMRO after my thesis is included in appendix L.
Bertin Sterk
Management summary
Business Solutions is a service department of the ABN AMRO bank, which is responsible for the development and maintenance of all IT related aspects of ABN AMRO. Business Solutions translates the IT question ABN AMRO has to a well-formulated list of requirements that can be used by an external software development company. After implementation Business Solutions is furthermore, responsible for maintenance of the implemented systems.
The problem statement of this research is:
How can Business Solutions monitor, evaluate, and control the efficiency and effectivity of the business analysis effort conducted in IT-projects at ABN AMRO?
Business analysis is the process in which the translation to the requirements is done. This process is mentioned above as the development part of Business Solutions. The development part was also the scope of this research.
Currently, the Dynamic Systems Development Method (DSDM) is used for structuring the
development process. The business analysis is accordingly structured through the application of the requirement engineering and management process.
First, a study was conducted to find out if the efficiency and effectivity could be measured by using the current methods, models and instruments already used at Business Solutions. The research into these methods, models and instruments revealed that the current process had a lot of potential possibilities that could be used in a measurement, but also revealed that there was no current method, model or instrument that would report about the efficiency or effectivity independently. A review process is the way the quality of the requirements is checked and improved by colleagues. This reviewing offered a potential indicator for effectiveness. Another most promising indicator was the already applied function point analysis. Function point analysis is used to estimate the amount of work that needs to be done after the requirements are drawn up.
Second a literature study was conducted. This literature study indicated that existing methods offer a lot of indicators about the process of software development and the improvement of quality of software development. However, the literature study also revealed that there is no ready of-the-shelve method for measuring efficiency and effectivity of requirement engineering. The conclusion based on the literature research was that, no methods, models, or instruments in general exist that measure the efficiency and effectivity of the business analysis.
For efficiency measurement the main focus was on finding the relation between the function point analysis and the hours spent on the business study. The result of this research for this part revealed that a relation between function points and the work done in the business study could not be made.
In this research an indicator for effectiveness is based on the number of defects found in the reviewing of requirements. The assumption behind this indicator is that the number of defects is an indicator for quality, and less quality is expected to be less effective.
Table of contents
1 ABN AMRO - BUSINESS SOLUTIONS ...7
1.1 INTRODUCTION...7
1.2 BUSINESS SOLUTIONS...7
1.3 ORGANISATION CHART BUSINESS SOLUTIONS...7
1.4 MISSION BUSINESS SOLUTIONS...8
1.5 PROCESS BUSINESS SOLUTIONS...8
2 RESEARCH APPROACH ...10
2.1 INTRODUCTION...10
2.2 RESEARCH TOPIC...10
2.3 OBJECTIVE OF THE RESEARCH...10
2.4 SCOPE...11
2.5 PROBLEM DEFINITION...11
2.6 EFFICIENCY AND EFFECTIVITY...12
2.6.1 Efficiency...12 2.6.2 Effectivity...13 2.7 PROBLEM SURVEY...13 2.7.1 Efficiency...13 2.7.2 Effectivity...14 2.7.3 Evaluate ...15 2.7.4 Control ...15 2.8 SUB QUESTIONS...15 2.8.1 Efficiency...15 2.8.2 Effectivity...15 2.8.3 Evaluate ...15 2.8.4 Control ...16 2.9 RESEARCH METHOD...16 2.10 RESEARCH STRUCTURE...16
3 CURRENT PROCESS AT BUSINESS SOLUTIONS...17
3.1 INTRODUCTION...17
3.2 DYNAMIC SYSTEMS DEVELOPMENT METHOD...17
3.2.1 Why does ABN AMRO use DSDM? ...17
3.2.2 DSDM Lifecycle...19
3.3 REQUIREMENT ENGINEERING AND MANAGEMENT...22
3.3.1 Requirements ...22 3.3.2 Requirement engineering ...22 3.3.3 Requirement levels...24 3.3.4 Requirement Types...24 3.3.5 Requirement testing ...25 3.3.6 Traceability ...25
3.3.7 REM Iterative Process ...26
3.3.8 REM Process and DSDM Phases ...27
3.3.9 Requirement Types and DSDM Phases...27
3.4 BUSINESS ANALYSTS...28
4 CURRENT METHODS, MODELS, AND INSTRUMENTS AT BUSINESS SOLUTIONS 31
4.1 INTRODUCTION...31
4.2 METHODS...31
4.2.1 Function point analysis ...31
4.2.2 Review process ...33
4.2.3 MoSCoW ...35
4.3 INSTRUMENTS...36
4.3.1 AIMS ...36
4.3.2 CaliberRM ...37
4.4 SUMMARY AND CONCLUSION...39
5 LITERATURE REVIEW...40
5.1 INTRODUCTION...40
5.2 CAPABILITY MATURITY MODEL INTEGRATION...40
5.2.1 History...40
5.2.2 Standard CMMI Appraisal Method for Process Improvement...41
5.2.3 Conclusion...41
5.3 QUALITY ANALYZER FOR REQUIREMENTS SPECIFICATIONS...41
5.3.1 Conclusion...41
5.4 SIX SIGMA...42
5.4.1 Six Sigma as a Metric...42
5.4.2 Conclusion...42
5.5 GOAL QUESTION METRIC...42
5.5.1 Conclusion...43
5.6 RISK &REQUIREMENTS BASED TESTING...43
5.6.1 Conclusion...43
5.7 OTHER SOURCES...43
5.8 SUMMARY AND CONCLUSION...43
6 RESEARCH RESULTS ...44
6.1 OUTPUT...44
6.1.1 Requirements ...44
6.1.2 Function Points...44
6.2 INPUT...49
6.3 RESULT &GOAL...50
7 SUMMARY AND CONCLUSION ...53 7.1 INTRODUCTION...53 7.2 SUMMARY...53 7.3 CONCLUSION...54 7.3.1 Efficiency...54 7.3.2 Effectivity...54 7.3.3 Evaluate ...55 7.3.4 Control ...55 8 RECOMMENDATIONS ...56 8.1 MEASURING EFFECTIVITY...56 8.1.1 CaliberRM ...56 8.2 MEASURING EFFICIENCY...56 8.3 TIME REGISTRATION...57
LIST OF FIGURES & TABLES...59
REFERENCES ...60
APPENDIX A - REQUIREMENT TYPES...63
APPENDIX B - DETAILED REQUIREMENTS ...64
APPENDIX C – REQUIREMENTS CATEGORISATION...65
APPENDIX D - TRACEABILITY...66
APPENDIX E – ATR CLASSIFICATION IT ...68
APPENDIX F – ROLE REQUIREMENTS ENGINEER...72
APPENDIX G – QUALITY DATASET...74
APPENDIX H – DEFINITIONS, DESCRIPTIONS, AND DELIVERABLES...75
APPENDIX I – FINDINGS REPORT ...76
APPENDIX J - PROJECT CHARACTERISTICS ...78
APPENDIX K – STATISTICAL ANALYSIS ...81
1 ABN AMRO - Business Solutions
1.1 Introduction
In this chapter the responsibilities of the department Business Solutions of ABN AMRO and her place in the total ABN AMRO structure will be explained. Subsequently the mission and the process of Business Solutions are further explained.
1.2 Business Solutions
Business Solutions is the internal partner for the value centres and service centres of ABN AMRO in the Netherlands. These centres are the customers of Business Solutions. Business Solutions supplies expertise for the development, improvement, and exploitation of (core)systems and products. Products being for example: “Internet Banking, the virtual assistant “Amber” on the internet, and the digital vault”. Business Solutions develops and exploits services and applications for the following channels: “internet, ATM machines, the bank shops, and the call centre”. By using these channels ABN AMRO can attend to her customers in a personalized way. Business Solutions is also responsible for the professionalization of the programme and project management. Business Solutions provides project managers who fulfil a key role in essential strategic changes within ABN AMRO. Besides project managers, Business Solutions provides implementation managers who make sure that the changes in the sales organisation are well guided and implemented in the proposed manner. Business Solutions plays a central role in the communication between the sales organisation and IT.
1.3 Organisation chart Business Solutions
In Figure 1 an organisation chart of Business Solutions is presented. In the chart the different departments of Business Solutions are shown.
Management Support Sven Duyx BS Projectmanagement Sven Duyx Interactive Banking Business Development Hans Pothuizen Interactive Banking Sales Diana Bossema Customer Support Marcel Timmerman
Interactive Banking Center Max Mouwen a.i. Direct Channels Interactive
Banking Max Mouwen
Branch & CCC Services Development Remco Meeuwsen Branch & CCC Services
Exploitatie Erik Strijker en Karel Mulder Intranet Infrastructure Services
Klaas Hollander Phone & Branches Business
Services André Biegstraaten
Development Information Services Jeroen Ploeg
Development Administration Services Rob Gijbels
Exploitatie Services Manuela Krull-Mancinelli
Acceptatie Services Pieter Allijn Core Business Services
Wieger Dijkstra IM CCC Frits Beckerman IM Amsterdam Martin Rol IM Noord Oost Ludwin Knol IM Midden Henk Hogeweg IM Rotterdam Richard Bode IM Zuid Marijke Platel Implementatiediensten Nery Anderson Projectmanagers Pool Projectmanagers Support Anneke Burger ProjectPartners Inge van Harten
Leiding & Secretariaat
Policies & Assurance Herman Mansveld
Content Management Office Bert van Beek
Business Architecture Ton Hardeman
Design & Improvement Arjan van Os
Functiewaardering Karen Teune
Six Sigma Serge Simons
Business Information Services Margriet Heijne O&PD
Remko Dur a.i. Business Solutions
Leiding en Secretariaat Remko Dur
Figure 1 - Organisation chart Business Solutions
1.4 Mission Business Solutions
The mission of Business Solutions is to supply her customers with an integrated multi-channel service that treats her customers pro-actively, personally, and with a service level above branch average. To accomplish this Business Solutions offers all the necessary services, competencies, and methodologies to support the changes at ABN AMRO, her processes, and business services.
As a business partner, Business Solutions commits itself to the commercial targets of its customers as defined in the operational plan, in which the operational goals of ABN AMRO and their priorities are recorded. Business Solutions supports pro-actively to help its customers maximise these targets (Banknet, 2006).
1.5 Process Business Solutions
Business Solutions on the one hand has a key role in constructing, updating and realising the operational plan. On the other hand, Business Solutions has an important role in the realization of the requests of the Value Centres and Service Centres.
The operational plan is drawn up based upon the strategy of the Value Centres and the corresponding objectives. Most of these objectives require IT-capacity to build new applications or improve current applications.
Besides the operational plan Business Solutions is responsible for the request circuit. A request is a demand for a business solution meant for an application already managed by Business Solutions or an application that needs to be developed and is going to be managed by Business Solutions. Adjustments on existing functionality, new functionality, or a connection between systems are also considered requests.
Requests are reported to Business Solutions through various ways; account management
conversations, user meetings, adoption offices, idea-mine, functional management, or during or after the implementation of a project, product, or programme. The “intake board” reviews all the requests and approves or disapproves the continuation of the requests and counsels the portfolio assembly. The portfolio assembly reviews the portfolio of Business Solutions and gives priorities to the approved requests. A solution engineer gives concrete form to the request if necessary. After this the customer board decides on the projects to be started.
Once the project has started, the usual process is that the development departments of Business Solutions engineer the requirements. These requirements are then sent to an external party, which takes care of the technical design and building. The developed systems are then evaluated by acceptance services of Business Solutions. Here the systems are being checked before they are assigned to exploitation. Exploitation is the department that manages the systems once operational and controls all the operational changes. This is shown in Figure 2.
2 Research approach
2.1 Introduction
In this chapter the research approach will be elaborated. To do this first the topic of the research will be explained followed by the objective and the scope. Thirdly the problem statement is defined. Fourthly the definitions of efficiency and effectivity that will be used in this research are given. Hereafter the initial problem survey will be illustrated. Sixth the sub questions of the research are given. Finally the method of research that will be applied is described.
2.2 Research topic
In the strategic management agenda 2006 of Business Solutions of ABN AMRO the following is recorded:
“Productivity and effectivity of the solution delivery organisation”. The description states:
• Research the different ways of how to measure and benchmark effectiveness and productivity. • Look for best practices outside Business Solutions and (if possible) outside ABN AMRO.
Business Solutions wants to be able to account for her performance to her customers and improve efficiency and effectivity. Being able to monitor efficiency and effectivity are steps in achieving this goal. An element in measuring the total efficiency and effectivity of Business Solutions is the efficiency and effectivity of the business analysis. The business analysis is the process in which business analysts translate the requests of the customer to requirements. Requirements are explained in paragraph 3.3.1.
ABN AMRO wants an instrument that can give a reliable overview of the efficiency and effectivity of the business analysis process at Business Solutions. This instrument should also be usable as a management tool. To accomplish this there is, next to a practical working model, also an approach necessary to act upon the found differences between projects by influencing the factors that affect efficiency and effectivity.
2.3 Objective of the research
The objective of this research is to develop an instrument that can measure the efficiency and effectivity of the business analysis. To realise this instrument first research needs to be done to get an overview of the current situation with regard to the measurement of efficiency and effectivity within ABN ANRO. Secondly the current literature needs to be examined to get an overview of the possible measuring methods.
Thirdly the current situation needs to be evaluated against the possible measuring methods available in current literature.
The objective of this research is not to report about individual efficiency and effectivity of employees. A method for evaluating individual employees already exists. This method is the Personal
development plan. The intention of this research is to evaluate the process done in the business analysis.
2.4 Scope
Business Solutions consists of 5 departments: Direct Channels Business Services, Core Business Services, Phone and Branches Business Services, Project Partners, and Organisation & Process Development. The business analysis this thesis is about is performed in the development branches of the departments Direct Channels Business Services, Core Business Services, and Phone and Branches Business Services. These branches of these departments form the scope of this research. Additionally this scope is narrowed down to the business analysts who work at the development branches with the role requirement engineer. The circles indicate these development branches as shown in Figure 3 - scope of the research.
2.5 Problem definition
The goal is to develop an instrument that can measure the efficiency and effectivity for requirement engineering within Business Solutions. Using this instrument the efficiency and effectivity need to be evaluated and controlled. Therefore, the problem statement is formulated as follows:
Management Support BS Projectmanagement
Interactive Banking Business Development
Interactive Banking Sales
Customer Support
Interactive Banking Center Direct Channels Interactive
Banking
Branch & CCC Services Development
Branch & CCC Services Exploitatie
Intranet Infrastructure Phone & Branches Business
Services
Development Information
Development Administration
Exploitatie Services
Acceptatie Services Core Business Services
IM CCC IM Amsterdam IM Noord Oost IM Midden IM Rotterdam IM Zuid Implementatiediensten Projectmanagers Pool Projectmanagers Support ProjectPartners
Leiding & Secretariaat
Policies & Assurance
Content Management Office
Business Architecture
Design & Improvement
Functiewaardering
Six Sigma
Business Information Services O&PD
Business Solutions Leiding en Secretariaat
How can Business Solutions monitor, evaluate, and control the efficiency and effectivity of the business analysis effort conducted in IT-projects at ABN AMRO?
There are many definitions of efficiency and effectivity and in the case of efficiency also confusion with other terms such as productivity. Clear definitions are needed for this research. In the next paragraph these definitions are given.
2.6 Efficiency and effectivity
For this research study the terms efficiency and effectivity need to be defined. Literature about these definitions was consulted to get the definitions that will be used in this research.
2.6.1 Efficiency
In the strategic management agenda 2006 of Business Solutions the following is recorded: “Productivity and Effectivity of the solution delivery organisation”.
The economic definition of productivity according to the American Heritage Dictionary (2004) is “The rate at which goods or services are produced especially output per unit of labour”. The Collins English Dictionary (1999) states: “The output of an industrial concern in relation to the materials, labour, etc., it employs”. So productivity is how much output is generated per unit of input. To compare a calculation of productivity to other calculations of productivity the same unit of input is needed. So the unit of input is fixed and the output varies.
Literature is not clear about the difference between productivity and efficiency, for example Fried (1993) describes efficiency as “the comparison between the observed and optimal values of output and input. The comparison can take the form of the ratio of maximum potential output obtainable from the given input, or the ratio of minimum potential to observed input required to produce the given output, or a combination of the two”. This definition does clarify the fact that productivity and efficiency are closely related.
Efficiency is described in The Collins English Dictionary (1999) as “1:the quality or state of being efficient 2:the ratio of the useful work done by a machine, engine, device, etc. to the energy supplied to it, often expressed as a percentage” The same dictionary states that efficient is “functioning or producing effectively and with the least waste of effort”. Robert D. Pritchard (1990) used a similar definition “The degree of means used to reach a certain goal. A process is efficient if it uses few means. These means can for instance be time, effort (man-hours), resources, or funds.” This is also the definition that is used by Paul, van Gils, Karsten, van Offerbeek, and de Vries in Organisatie en gedrag (1994).
In this research the following definitions for productivity and efficiency will be used to make a distinction between the two ways of looking at a process:
Productivity: Productivity is how much output is generated given a fixed unit of input. (Maximising output with the current resources)
Efficiency: Efficiency is how much input is used given a fixed unit of output. (Minimising the resources needed or optimizing the process for the current output)
amount of business analysts. The goal is to know and be able to report how Business Solutions has used her business analysts to reach the goals stated by her customers.
Thus, the objective is not to know how much requirements can be written down given a certain timeframe, because it is known that the number of requirements will only be sufficient if they exactly describe the solution. So the output that is expected from the process is fixed as being a sufficiently described solution. Input however varies to reach this sufficiently described solution.
2.6.2 Effectivity
The American Heritage Dictionary (2004) states that something is effective if it has an intended or expected effect. Robert D. Pritchard (1990) defines effectivity as a method that is effective if the concerning effort and expenses actually contribute to the realisation of the intended goal.
So effectivity is defined as the degree to which an organisation or project succeeds in reaching her stated goals (Paul, 1994). J. in ‘t Veld (1978) defines that the calculation of effectivity is the actual reached result divided by the intended result. So, when talking about the result of the process the term effectivity is used.
For this research the following definition will be used.
Effectivity: Effectivity is the degree to which an organisation or project succeeds in reaching her stated goals (Paul, 1994).
2.7 Problem survey
2.7.1 Efficiency
In measuring the efficiency of the business analysis the first question is how efficiency can be measured. Efficiency is the relation between output and input. Output is fixed as a sufficiently described solution. Every project at Business Solutions however has a different solution, thus the output cannot be compared amongst projects. Therefore a measure is needed for output that makes the described solution of the projects comparable. Output is in this case a certain amount of realised production or units. Input is the use of resources to reach a certain amount of output. To describe efficiency of the business analysis it is required to specify the resources and the produced comparable units.
Input for the business analysis can be all resources business analysts use to reach their output. These resources can for instance be: time, effort, or funds.
Output of a business analysis can for instance be the formulation of requirements or a number of developed process models.
To measure input and output it is necessary to know the exact input and output of a business analysis. This input and output also needs to be quantified to be able to count or calculate efficiency. In addition it must be possible to measure this quantitative data. This measurement has to take into account that not all requirements are the same and equally hard to formulate. In other words, there is no
standardized output. The model has to take these things into consideration.
If efficiency is calculated as “efficiency = output / input” with the data mentioned above then a difference in efficiency is presented between business analysis.
the customer has or the degree of stakeholder involvement. If all these factors are specified it is also practical if they can be quantified.
If it is possible to measure efficiency it is also important to know if the accomplished result is also effective. Otherwise it is possible to have worked very efficient without reaching the stated goal.
2.7.2 Effectivity
A method is effective if the input (effort and expenses) indeed contribute to the realisation of the stated goal. Goals should be derived from the goals of Business Solutions or the goals of the Value Centres of ABN AMRO. Bearing in mind that the goals of Business Solutions should be in line with the goals of ABN AMRO. The actual fact being measured is the effect activities have on the
realisation of the goals. For the business analysis this is the contribution to the realisation of the goals of Business Solutions or ABN AMRO.
The activities of the business analysis are for example the formulating of requirements by a business analyst. The formulating of requirements is however only a part of the total development track. After the requirements phase there are also the design and build phase and the implementation phase. Hence business analysts cannot take credit for the effectivity of the total project. If the implementation is not successful and a project fails, this is not always due to an error made in the requirements. For example, if the users are using the product in the wrong way because they did not receive a proper instruction course.
The intended goal is to offer a good solution to satisfy a request a customer has. Effectivity of the solution can in this case only be measured at the end of the development track, after the analysis, building, and implementation phases. These phases are further described in paragraph 3.2.2 DSDM Lifecycle. Once the solution is implemented the experience gained working with the solution can tell if the solution is paying off like it is supposed to. The pay off is formulated in the goal at the beginning of the project in the project proposal. These results and goals have to be quantified to actually
determine effectivity. As for example ABN AMRO wants to heighten the customer satisfaction with 2% it is important to measure the current level and the level after implementation.
When having multiple goals a weighing has to be applied to process all the goals into a single effectivity figure. Because there are multiple projects running simultaneously the pay off cannot be accounted to an individual project. In this research this has to be taken into account.
More practical is the possibility to say something about the expected effectivity. This is because the situation can have changed, the feedback is less effective, and adjusting the process is not possible anymore when using a measurement at the end of the project.
The chance to bring forth an effective solution is better if the activities in the process business analysis and formulated requirements are subjected to specific criteria. These criteria can for instance be the method of working drawn up in the Requirements Engineering Management (REM) manual. In short, can there be criteria drawn up for the process and results?
2.7.3 Evaluate
After linking efficiency and effectivity for one project’s business analysis the data can be compared to other efficiency and effectivity measurements of business analyses of other projects. The question is whether the data can be used to compare Business Solutions to an external party that does similar work as Business Solutions. If this external benchmark is not possible then maybe it is possible to use the data to create an internal benchmark.
2.7.4 Control
Basically, management can control the project better if there is data available from an evaluation. This is because Business Solutions knows which factors define the efficiency and effectivity and can use these to control the process. For example, prescribing training for the business analysts or
standardising processes.
To facilitate this better controlling, the proposed method of this research that will measure and evaluate the efficiency and effectivity, has to be implemented.
When implementing the method it is important to know who is going to measure the efficiency and effectivity. It is also important is to know who is going to take action based upon the results of the measurement to control the efficiency and effectivity.
2.8 Sub questions
The above described problem survey leads to the following sub questions that have to be answered.
2.8.1 Efficiency
• What is the efficiency of the business analysis?
o What are the current methods, models, and instruments? o What is input for a business analysis?
o What is output for a business analysis?
o What is a suitable model or instrument for Business Solutions? • How can efficiency be measured?
2.8.2 Effectivity
• What is the effectivity of the business analysis?
o What are the current methods, models, and instruments? o What is a goal for a business analysis?
o What is a result for a business analysis?
o What is a suitable model or instrument for Business Solution? • How can effectivity be measured?
2.8.3 Evaluate
• How can the data of efficiency and effectivity be compared with other business analyses? • How can the data of efficiency and effectivity be compared with business analyses outside
• Are the final data/measurement indicators comparable to a standard or a party outside Business Solutions?
2.8.4 Control
• Which are the factors that explain the difference in efficiency and effectivity? • How should the method be implemented?
2.9 Research method
Literature research: Research the existing methods, models, and instruments that deal with the measurement of effectivity and efficiency.
Desk research: Research the way Business Solutions currently deals with the measurement of effectivity and efficiency.
Interviews: Using interviews to get a clear view of the processes at Business Solutions. These interviews will be focused on searching for possible factors that are measurable to determine efficiency and effectivity. These measurable factors need to be generalized for the activities of all the business analyses.
2.10 Research structure
To answer the research question and the sub questions this research study will first explain the current situation at Business Solutions concerning this research.
3 Current Process at Business Solutions
3.1 Introduction
This chapter describes in the first paragraph what Dynamic Systems Development Method DSDM is and how and why it is used at ABN AMRO. The functionality that ABN AMRO has added to the DSDM is explained. The Process descriptions of the DSDM are given in paragraph 3.2.2 and these are in more detail for the processes that are in the scope of this research.
In paragraph 3.3 the Requirement Engineering and Management Process is described. This is the method of working that is used in the business analysis. In paragraph 3.4 the activities performed by the business analyst are described. The business analysts are the employees that actually perform the requirement engineering in the business analysis.
3.2 Dynamic Systems Development Method
DSDM is a framework based upon the Rapid Application Development (RAD) software development method. This framework is improved using the best practices and lessons learnt since the early 1990’s. DSDM provides a flexible yet controlled process that can be used to deliver new systems, which combines the most effective use of people's knowledge, tools and techniques such as prototyping to achieve tight project delivery timescales.
DSDM has primarily been used as an approach for IT projects. It can also be used for business change projects and programmes. Such projects may have a large amount of technology change or no technology element at all (DSDM Manual version 4.2).
3.2.1 Why does ABN AMRO use DSDM?
DSDM is a vendor-independent method. DSDM is also tool and technique independent enabling it to be used in any business and technical environment without tying the users to any vendor.
Many system development projects fail to meet the expectations of the end users. Such project failures can be classified into one of five basic types:
1. The system fails to meet the business requirements for which it was developed. The system is either abandoned or expensive adaptive maintenance is undertaken.
2. There are performance shortcomings in the system, which make it inadequate for the users' needs. Again, it is either abandoned or amended incurring extra costs.
3. Errors appear in the developed system causing unexpected problems. Patches have to be applied at extra cost.
4. Users reject the imposition of the system, for political reasons, lack of involvement in its development or lack of commitment to it.
5. Systems are initially accepted but over time become impossible to maintain and so pass into disuse.
DSDM aims to prevent all five types of project failure (DSDM Manual version 4.2).
To do this the DSDM assumes that nothing is built perfectly the first time, but that 80% of the solution is built in 20% of the time (DSDM Manual version 4.2).
in the work that was previously accepted. A result of this approach is that projects are delivered late and over budget or even fail to meet the requirements.
DSDM’s solution to this problem is to divide the project into smaller parts called increments. This iterative approach makes it possible to deliver projects faster. Hence a step in the process only needs to be completed as much as necessary to move to the next step.
DSDM’s basic principle is that requirements will be changed anyway, because understanding increases as the project progresses.
A characteristic of DSDM is that the final functionality of the solution is constantly monitored. In doing so the functionality delivered is that which satisfies the requirements with the highest priorities. This is done because DSDM uses a different approach than the classical approach in resource management. Classically time and resources vary during development and requirements are fixed. In the DSDM approach time is fixed and resources are fixed as far as possible, but the requirements are allowed to change. This is illustrated in Figure 4.
Figure 4 – DSDM vs Traditional software development
ABN AMRO is using this approach as a replacement for the “waterfall” approach. DSDM is now used as a method to reach a higher-quality set of requirements in a more efficient way than before.
3.2.2 DSDM Lifecycle
DSDM defines a generic high-level process that can be customized to fit a specific organisation.
Figure 5 – DSDM lifecycle
The project process, as shown in Figure 5, has five phases: Feasibility Study, Business Study, Functional Model Iteration, Design and Build Iteration and finally Implementation in the working environment. These are preceded by the Pre-Project phase and end with the Post-Project phase (DSDM Manual version 4.2).
For every phase in DSDM is defined what the deliverables are. Every deliverable has a set of quality criteria. DSDM has not defined how the deliverables should be produced and what the content should be, but the set is a minimum that should be used to keep the project successful and controllable. Deliverables can be added to better suit the process of the organisation. Removing deliverables from the standard set provided by DSDM will result in reduced controllability. To assure a controlled transition to a next phase there are minimal entry and exit criteria defined for each phase.
Figure 6 – Process Business Solutions (Ontrack 2006)
3.2.2.1 Pre-Project
The Pre-Project phase ensures that only the right projects are started and that they are set up correctly. Once it has been determined that a project is to go ahead, funding is made available. Also the initial project planning for the Feasibility Study is done. This phase is part of the DSDM but is not represented in Figure 6 because at Business Solutions this part is integrated in the Feasibility Study.
3.2.2.2 Feasibility Study (FS)
In the FS is determined if DSDM is the right approach for the project and if conditions can be set for a successful project. Also an estimate is made for the needed time and resources.
For most of the deliverables ABN AMRO has composed templates. The person responsible for that specific deliverable can use these templates. In the FS the project manager is responsible for most of the deliverables.
The PRL (Prioritized Requirements List) is one of the deliverables of the FS. This is the document that lists the high-level requirements. In the Business Study these requirements are elaborated.
3.2.2.3 Business Study (BS)
The BS scopes the overall activity of the project given the approved direction/solution of the FS and provides a sound business and technical basis for all future work. In the BS is defined which processes and users will be supported by the system. Also is defined how the project is set up. The project team is composed and the project is split up in increments. The high-level functional and non-functional requirements are baselined, a high-level model of the business requirements is produced, the system architecture is outlined and the maintainability and supportability objectives are agreed upon.
3.2.2.4 Functional Model Iteration (FMI)
In the BS is defined which processes will be supported. In the FMI is defined with what functionality these processes will be supported. According to DSDM the functionality should be developed iteratively using prototypes and functional models.
The FMI gives an answer to what the system or application should do.
The information need of the users is identified, and the high-level requirements that are defined in the FS and BS are elaborated into more detailed requirements. The detailed view of the several categories of requirements is enclosed in Appendix C.
3.2.2.5 Design and Build Iteration (DBI)
In the FMI the focus is on answering “what” should be realized. In the DBI the focus is on “how” the system should be realized. Required for the start of the DBI phase are an approved functional prototype and a prioritized list of non-functional requirements. At the end of the DBI an operational system is delivered.
Depending on the complexity of the increment it can be decided to combine the DBI with the FMI. An important downside of combining the DBI and FMI is that the elicitation of requirements lacks in getting the necessary functionality.
With DSDM development is done in increments. Thus it is possible that various increments are in different phases of development. A certain increment can already be implemented while other increments of the same project are still in the FMI or DBI phase.
At ABN AMRO the DBI phase is different from the standard DSDM DBI phase because ABN AMRO has outsourced the development. Because of this situation it has become very important to have a high quality list of requirements at the end of the FMI phase. If the requirements are of poor quality, the vendor will produce a system that will not be useful. Or if the requirements are not complete the vendor will produce a system that probably will not be what the end users had requested.
At ABN AMRO the DBI focuses on ensuring that the system has a sufficiently high standard to be safely placed in the hands of the users. The major product here is the Tested System. The selected vendor does the actual building. The Test Management Process is applied to create a Tested System.
3.2.2.6 Business Acceptance
Within the Business Acceptance the business will accept the business process and all needed tools. To make this possible the Business Acceptance Manager (BAM) will define per stakeholder what the acceptance criteria are. He will also define the product risks if the requirements are not met.
3.2.2.7 Implementation phase
The Implementation covers the transfer from the development environment to the operational environment. This includes training all users and handing over the system to the exploitation department. The Increment Review Document is also produced and summarizes what the project has achieved for the delivered increment. The Increment Review looks at all the requirements, which were identified during development of the increment and the development of the system in relation to those requirements.
3.2.2.8 Post-Project phase
Post-Project contains the activities that occur once the project team has delivered the final increment. The objectives of the Post Project are to assess whether or not the proposed benefits of the project, as stated during its initial phase, are achieved and to evaluate the delivered system in use.
3.3 Requirement Engineering and Management
The purpose of the Requirement Engineering and Management Process is to ensure a standard means of eliciting, analysing, representing, and validating requirements, and managing changes to approved and baselined requirements.
3.3.1 Requirements
There are many definitions of what requirements are. Sommerville and Sawyer (1997) describe requirements as a description of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system. Brian Lawrence (1997) suggests that a requirement is “anything that drives design choices”.
At ABN AMRO the definition from the IEEE Standard Glossary of Software Engineering Terminology (1990) is used:
1. A condition or capability needed by a user to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a system or system component to
satisfy a contract, standard, specification, or other formally imposed document. 3. A documented representation of a condition or capability as in (1) or (2).
3.3.2 Requirement engineering
Requirement engineering covers all the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system (Sommerville, 1997).
Sommerville and Sawyer (1997) are convinced that you will benefit by defining a requirements engineering process that is appropriate to your organisation. A good process description will provide guidance to the people involved and will reduce the probability that activities will be forgotten about or carried out in a perfunctory way (Sommerville, 1997).
Requirements
Elicitation
Requirements
Analysis
Requirements
Representation
Requirements
Validation
Change ManagementFigure 7 - Requirement engineering process
3.3.2.1 Requirements Elicitation
Requirements Elicitation covers the activities to assemble the stakeholders and discover, reveal, gather, articulate, and define the requirements. This is usually the first stage (IEEE, 1990).
3.3.2.2 Requirements Analysis
Requirements Analysis follows the elicitation stage as the second stage in the process. The Analysis stage includes such activities as identifying and analysing risks, constraints, assumptions, and exclusions, as well as, analysing the priority of the requirements and urgency (trade-off analysis). (IEEE, 1990)
3.3.2.3 Requirements Representation
Requirements Representation follows the analysis stage as the third stage in the process. Representation is the way the requirements are documented, presented, and communicated to all stakeholders in a reviewable format. This is done via documents, process models, diagrams, etc (IEEE, 1990).
3.3.2.4 Requirements Validation
Requirements Validation follows the representation stage as the fourth stage in the process. Validation includes activities to review and verify the requirements. This is for example done for completeness, accuracy, consistency, traceability and testability. All relevant project stakeholders are included in conducting the reviews (IEEE, 1990).
3.3.2.5 Change Management
3.3.3 Requirement levels
Requirements are usually classified into levels, where requirements are decomposed from the high-level to the lowest detailed high-level. There are 3 high-levels:
1. High-level Business Requirements, describing the ‘WHY’ of a system
2. User, Interface and Functional Requirements, describing the ‘WHAT’ of a system 3. Detailed Requirements, describing the ‘HOW’ of a system (IEEE, 1990).
A separate group are the non-functional requirements. They describe restrictions and/or quality aspects which can be of importance on each of the three levels, usually the “WHAT” of a system.
Sommerville and Sawyer (1997) describe functional requirements as what the system should do and non-functional requirements as placing constraints on how these functional requirements are implemented.
3.3.4 Requirement Types
In the three requirement levels High-level Business, User, Interface, Functional, Non-Functional and Detailed Requirements are mentioned. These are called requirement types. These types can be used as:
• as checklist to identify and define requirements • for accessibility of the requirements
• for completeness and consistency check
• for description of aspects for testing the IT-solution • to arrange the requirements conveniently
See Appendix A - Requirement Types for examples of Requirement Types.
3.3.4.1 High-level Business Requirements
This Requirement Type reflects the high-level objectives of the organisation or customer requesting the system, product or service, the WHY (IEEE, 1990).
3.3.4.2 User Requirements
User requirements describe tasks the users must be able to accomplish with the product, service or system. They are usually captured in use cases, scenarios, or business processes, the WHAT (IEEE, 1990).
3.3.4.3 Interface Requirements
They specify the hardware or software elements with which the system, or system component, must interact or communicate, the WHAT (IEEE, 1990).
3.3.4.4 Functional Requirements
Functional requirements define the software functionality/features that must be built into the product, service or system to enable users to accomplish their tasks, thereby satisfying the high-level Business and User Requirements. A feature is a set of logically related Functional Requirements that provides a capability to the user, the WHAT (IEEE, 1990).
3.3.4.5 Non-Functional Requirements
3.3.4.6 Detailed Requirements
This Requirement Type categorises the requirements necessary to actually build and deliver the solution. They capture data, report, file and database schemas, valid data, values and ranges, algorithms, calculations, workflow, etc., the HOW (IEEE, 1990).
The level of detail largely depends on the normal practice in the organisation, whether the
requirements document will be the basis of a contract for software development and the type of system that is being developed. If developing a product that will be both specified and implemented
internally, a fairly general specification will be sufficient. Details can be added to the system as development proceeds. On the other hand, if another company is contracted to develop the system, a much more detailed specification is needed which defines what must be build (Sommerville, 1997).
3.3.5 Requirement testing
It has to be verified that requirements are testable, clearly stated, feasible, appropriate, and consistent. To accomplish this there are criteria drawn up for the requirements.
3.3.5.1 Validation criteria
The validation criteria describe how for each requirement it will be verified that the requirement is indeed implemented properly. These criteria can be written as a kind of test description or another kind of procedure that must be followed. These criteria will be used by the tester to develop the appropriate test cases. If it is not possible to define validation criteria for a requirement, it has to be examined whether the proposed requirement is in fact a real requirement.
Not all requirements have to be validated. A high-level business requirement will be validated by all underlying and related requirements. Also decomposed requirements can be validated by their underlying requirements.
The requirements engineer records the validation criteria as part of the requirement definition.
3.3.5.2 Acceptance criteria
Acceptance criteria are of a higher level than the requirements and their validation criteria. They are criteria that a stakeholder wants to have seen, done, tested, or examined before he can accept a finished product. Acceptance criteria can differ from "all requirements must be tested" to "during the project a presentation must be given to all users about the new system".
The Business Acceptance Manager records the acceptance criteria in the Master Acceptance Plan.
3.3.6 Traceability
Traceability is the process of linking each requirement to its origin and to the design elements, prototypes, source code, and test cases that verify the correct implementation of the requirement (Gotel and Finkelstein, 1994). Tracing links help to track parentage, interconnections, and
dependencies among individual requirements. This information is beneficial in assessing impact when a requirement is modified.
To put it in other words requirement traceability refers to the ability to follow the life of a requirement, from its origin, through its development and specification, to its implementation and deployment throughout the development, deployment, and maintenance phases.
3.3.7 REM Iterative Process
As there is a hierarchy in the levels, the process of eliciting, analysing, representing and validating requirements can easily be broken up in three so called “Iterative processes”:
1. Identify the High-level Business Requirements
2. Identify User, Interface, Functional and Non-Functional Requirements (decomposing the High-level Business Requirements)
3. Define the Detailed Requirements (decomposing and detailing the User, Interface, Functional and Non-Functional Requirements)
Each iterative process is the same as the process shown in Figure 7.
Iterative process 1: Identify High-level Business Needs
Why?
How?
What?
Requirements Elicitation Requirements Analysis Requirements Representation Requirements Validation Change Management Requirements Elicitation Requirements Analysis Requirements Representation Requirements Validation Change Management Requirements Elicitation Requirements Analysis Requirements Representation Requirements Validation Change ManagementIterative Process 2: Derive User, Interface, Functional and Non-Functional Requirements
Iterative process 3: Define Detailed Requirements
Figure 8 - REM Iterative Process
Figure 8 above illustrates the Requirements Engineering and Management (REM) Iterative Process. The requirements flow through the five stages, as described above in the paragraph Requirement engineering, until the requirements for all three levels are completely defined. Projects iterate through the requirement process stages.
Typically, projects iterate through the requirement process stages to complete the requirement decomposition from the High-level Business Requirements to the Detailed Requirements. However, the number of iterations may vary depending on project size and complexity. For example, small projects may only need to go through each iterative process once to completely define all three levels (“WHY”, “WHAT”, “HOW”) of requirements; standard and complex projects may need to go through Iterative process 1 multiple times, Iterative process 2 multiple times, and even Iterative process 3 multiple times.
3.3.7.1 Iterative process 1
3.3.7.2 Iterative process 2
Iterative process 2 decomposes the requirements identified in the “WHY” level, and focuses on “WHAT” is needed to support the high-level Business Requirements. This process identifies the User Requirements, the Interface, the Functional Requirements, and the Non-Functional Requirements. The goal of Iterative process 2 is to produce requirements sufficient for team members to provide
management with reasonable initial estimates of cost and labour required to implement the project.
3.3.7.3 Iterative process 3
Iterative process 3 completes the decomposition of the User, Interface, Functional and Non-Functional Requirements to the lowest “HOW” level. The detailed requirements are defined and focus on how to implement the User, Interface, Functional and Non-Functional requirements.
In Figure 8, the blue right angles with double-ended arrows indicate the hierarchical or traceability relationship between the three levels. For example, the High-level Business Requirements in the “WHY” level decompose into the User, Interface, Functional, and Non-Functional Requirements in the “WHAT” level, and so on.
3.3.8 REM Process and DSDM Phases
In the Feasibility Study and the Business Study the scope of a project is defined. In these phases the “WHY”- and a part of the “WHAT”-questions have to be answered. So the REM Iterative Processes 1 & 2 have to be executed in these phases. In the FMI iterations, the rest of the “WHAT” and some of the “HOW” of the system are described. So the REM Iterative Processes 2 & 3 are executed during these DSDM Phases.
3.3.9 Requirement Types and DSDM Phases
Figure 9 gives an overview of the different requirement types and the phases of the DSDM. In the figure is shown when the requirement types are defined and when the requirement type is baselined.
High Level Business req’s
User / Functional req’s
Detailed (funct.) req’s
Non-functional/Detailed (NF)req’s Baselined PRL (FMI) PRL (DBI) PRL Post-project
Pre-project FeasibilityStudy
Business Study Functional Model iter. Design & Build iter. Implemen-tation DSDM phases
Create/update product centered requirement types
Create/update Non-Functional requirement types
PRL Prioritised Requirements List (DSDM product)
Baseline created of all at that time available requirements
The baseline (FMI)PRL is the updated and signed-off PRL, and the (DBI)PRL is the more detailed and baselined PRL.
At the end of the Business Study all requirements, which determine the scope of the project, are baselined. This includes at least all high-level Business Requirements.
At the end of the FMI the PRL is not only updated and baselined again, but it is also signed-off by all stakeholders. The contract with the vendor is based on this signed deliverable.
Only present Non Functional Requirements can get more detailed during DBI. Also the tracing (between the requirements and from requirements to test cases or design components) will be updated. These need to be baselined before the System Testing, so that, the affected products like Software Components, Test Cases can also be updated before carrying out the System Testing. This will ensure that, the activity of coding is carried out on the baselined Non functional requirements. However, new Non Functional Requirements can be added, but they have to follow the Change Request mechanism. The last baseline-moment is earlier than the end of the DBI phase, because only baselined
requirements can be tested for acceptance.
3.4 Business analysts
A business analyst according to Karl Wiegers (2003) is the individual who has the primary responsibility to gather, analyze, document and validate the needs of the project stakeholders. At ABN AMRO business analysts work at the development departments. Business analysts develop systems that are used to support the business processes, and give advice about the improvement of the related business processes. The activities of a business analyst are: management support, development, maintenance, and knowledge management. These activities are carried out to optimally support the department in reaching its goals.
3.4.1 Skills
An effective analyst combines strong communication, facilitation, and interpersonal skills with technical and business domain knowledge and the right personality for the job (Ferdinandi, 2002). Wiegers (2003) mentions as key skills:
Listening skills, interviewing and questioning skills, analytical skills, facilitation skills, observational skills, writing skills, organisational skills, modelling skills, interpersonal skills, and creativity. The effective analyst has a rich toolkit of techniques available and knows when, and when not, to use each one (Wiegers, 2003).
At Business Solutions the function business analyst is, with regard to the requirements engineering, divided in two roles. These are the role of solution engineer and requirement engineer. The roles are a differentiation between business analysts based on skill. The solution engineer is the business analyst with better skills to elicit the requirements at the business part (high-level requirements). The
requirements engineer is the business analyst with more technical skills and is better in drawing up the detailed requirements.
engineering begins in the business study but is mainly done in the functional modelling iteration. This is represented in Figure 10.
Figure 10 - Requirement engineering & Management process
3.5 Summary and Conclusion
In the paragraphs 3.2, 3.3, and 3.4 the current process at Business Solutions is described. The DSDM process is a well-structured process and the used REM process is also a well-considered method. So, the basis for an efficient and effective business analysis is already available at Business Solutions. Also the roles that are fulfilled by the business analysts in the business analysis are linked to the different iterative phases in the REM process.
This chapter has given a clear overview of the total process and has made the objective and the scope of the research as defined in chapter 2 more clear. The business analysis is the requirement
engineering work that is done by the business analysts in the phases BS and FMI of the DSDM. In the next chapter the used methods, models, and instruments that contribute to the work the business analysts do are elaborated.
4 Current Methods, models, and instruments at Business Solutions
4.1 Introduction
In this chapter the methods, models, and instruments that are used during the business analysis are elaborated. This elaboration will attempt to reveal methods, models, or instruments that can be used for the measuring of efficiency and/or effectivity.
4.2 Methods
4.2.1 Function point analysis
The management of information system cost, development effort and project planning are key aspects of software development. There are various ways to measure software size. For instance the number of lines of source code, or functional size measurement methods. Source Lines of Code(SLOC) can only be counted after an information system is developed (NESMA, 1998). Hence SLOC is suitable to calculate the efficiency afterwards, but cannot be used to make a software size measurement without data from previous SLOC calculations. With data from previous SLOC calculations an estimate can be made based on similarities in the previous projects.
Functional size measurement methods are developed to overcome some of the problems with approaches based on source code (Fetcke). The goal of the methods is to measure the functionality of the information system based on functional specifications. There are a few measurement methods certified by the ISO/IEC (ISO, the International Organisation for Standardization, and IEC, the International Electrotechnical Commission). These are currently the function point analysis(FPA) according to the IFPUG(international function point user group) and according to the
NESMA(Nederlandse Software Metrieken Associatie), Mark II standard of the UKSMA (UK Software Measurement Association), and COSMIC Full Function points of the COSMIC(Common Software Measurement International Consortium).
ABN AMRO currently uses the IFPUG standard 4.2 since mid 2006, before that the NESMA standard was used.
Function Point Analysis (FPA) is a method to measure the functional size of an information system. This can be for a new development or an enhancement of an information system. FPA measures the functional size by looking at the (functional) transactions and data files that are relevant to the user in the business. The functional size of an information system is expressed by a number of function points (FP).
FPA is used to budget a development project. The development costs for an information system are related to its size. The bigger the system, the more expensive the development will be.
Based on experiences in earlier projects an organisation knows, how many hours (on average) one needs to realize one function point: the productivity rate.
Size (number of function points) x productivity rate (hours per function point) is a basis for the project budgeting process (NESMA, 2004).
It is also possible to budget annual maintenance costs of the application portfolio or to determine the project productivity after completion of the product. Productivity can be estimated based on
4.2.1.1 Counting at ABN AMRO
For this research we will focus on the NESMA standard that was used by ABN AMRO up till the summer of 2006, because all the data available at Business Solutions is accumulated during the period the NESMA standard was used.
The standard NESMA counting method is done in 3 steps. First the functions are identified, second the functional complexity of the function is determined, and finally the functional size is calculated.
There are five functions that are distinguished for identifying the functions a system has. Important is that the functions are identified that concern the user. The user has to acknowledge or must have requested the functionality. The five functions are:
• Internal logical data collection • Linking data collection • Input function
• Output function • Request function
In step two the functional complexity of the functions is determined. Every function is rated with the scale “simple, medium, difficult”. To determine this complexity there are clear criteria drawn up. Leading in the determination is the quantity of data processing by a function.
This step can also be skipped. The analysis is then called an estimated count. In an estimated count the functions get a standard rating. For the internal and linking data collections this is “simple” and the input, output, and request functions are rated “medium”. This estimated counting is used at ABN AMRO.
After rating the functions the function points are counted. This is done using the matrix shown in Table 1.
Table 1 – Rating function points
Complexity
Function Simple Medium Difficult
Internal logical data collection 7 10 15
Linking data collection 5 7 10
Input function 3 4 6
Output function 4 5 7
Request function 3 4 6
(NESMA, 2004)
4.2.1.2 Counting method
Figure 11 – Estimated FP count <=> detailed FP count
The result of the estimated function point count and the detailed function point count is very close. The main reason why ABN AMRO uses the estimated method is because it is less time consuming and still reliable.
Besides this it is also not necessary to do a detailed count, because ABN AMRO wants to compare the pre-count with the post-count and the pre-count can only be performed as an estimated count. Hence there is no need for the post-count to be more detailed than the pre-count. All the differences would be due to the difference in counting method.
A detailed count is not performed in the pre-count because this would create a pretence certainty.
4.2.2 Review process
Reviews are quality control techniques used in software development that rely on individuals other than the author to evaluate the software product for findings. Reviews may be applied to any software product and are done in the early stages of each software product's development.
Reviewing requirements documents is a powerful technique for identifying ambiguous or unverifiable requirements, requirements that aren’t defined clearly enough for design to begin, and other problems (Wiegers, 2003).
Reviews are held to assure that a product meets the specified requirements and that the solution offered in the product is fit and adequate for the problem to be solved. Reviews increase the quality of the product and prevent the necessity of rework (Wiegers, 2003).
The Review objectives are:
1. Verify that specifications are satisfied 2. Bring out improvements to the work product 3. Verify conformance to standards
5. Collect data for process improvement
6. Does not examine alternatives or stylistic issues 7. Any other improvements to be identified
The effectiveness is highly increased by reviews and less time may have to be devoted to test the product so the overall software life cycle cost is lowered since findings are found early and are less expensive to fix. Karl Wiegers (2003) confirms that uncorrected requirement findings will be expensive to fix down the road.
Investing in reviewing and testing can shorten the delivery schedule by reducing the rework required and by accelerating system integration and testing (Blackburn, Scudder, and van Wassenhove 1996). Casper Jones (1994) reports that every dollar spent to prevent findings will reduce finding repair cost by 3 to 10 dollars. Grady and van Slack (1994) report that Several companies have avoided as much as 10 hours of labour, for every hour they invested in inspecting requirements documents and other software deliverables.
Another important benefit of reviews is the immediate evaluation and feedback to the author/producer from his/her peers, which will bring about improvements in the quality of existing and future software products. So every minute spent on inspecting requirements is worthwhile (Wiegers, 2003).
The best-established type of formal review is called Fagan inspection (Gilb and Graham 1993; Radice 2002). Micheal Fagan (1976) developed the inspection process at IBM in the mid-1970s, and others have extended or modified his methods (Gilb and Graham 1993). Inspection has been recognized as a software industry best practice (Brown 1996). Any software product can be inspected, including requirements and design documents, source code, test documentation, and project plans.
Following are the type of review techniques used at ABN AMRO: • Peer Review
• Structured Walk Through • Review Workshop
4.2.2.1 Peer Reviews
One reviewer being an experienced peer of the author/producer typically executes a Peer Review. Peer reviews are formal reviews when planned in the Quality Plan section of the workplan. The findings will be registered in writing and tracked until closure.
4.2.2.2 Structured Walk Through Technique
Structured Walk Through (SWT) is a formal review technique where a delivered product is examined in detail by a group of persons including the author/producer(s) to detect faults, violation of
development standards and any other non-conformances. The Review comments will be prepared individually and discussed in a Review meeting. All findings will be registered in writing and tracked until closure. The SWT technique as used within the bank is similar to the Fagan Inspection technique (Ontrack 2006).
4.2.2.3 Review Workshop
