requirements engineering for building it - an industrial...

CODEN:LUTEDX(TETS)-5478/1-86/(2003)&local5

Requirements Engineering for Building IT - an Industrial Case Study

Master Thesis by

Anders Åkesson

Performed at TAC AB Supervisor

Claes-Peter Haväng

Department of Communication Systems at Lund Institute of Technology Supervisor

Björn Regnell

March 2003

Requirements Engineering for Building IT – an Industrial Case Study iii

Abstract In the industry today, requirements engineering is becoming more important than ever. The lack of methods, techniques and processes dealing with requirements may not be directly noticeable, but the cost for not having them is great. Competition on the software market is fierce and users do not hesitate to abandon a software product if it does not fulfil his or her needs. One of the most important software attributes which greatly affect the user is quality. It has been proven time after time that introduction and successful use of requirements engineering will improve software quality. If quality is improved, extensive rework and support will not be needed. Thus, costs will decrease. TAC is a supplier of integrated systems for building automation. Along with these integrated systems, various software programs which support user and market needs are developed and marketed. A late addition to TAC’s software offer is the web based business platform I-talk®. This product has until now been run as a research project with poorly defined processes and procedures. An effort is being made to include it in TAC’s product planning process. However, requirements engineering is not directly addressed in this process. I-talk, being a rapidly developing web system, suffers from this. This thesis introduces requirements engineering and suggests techniques for dealing with requirements. Some of the techniques presented have been studied in an I-talk project and are evaluated as a part of this thesis. Also, a suggestion of a tuned requirements engineering process, which supports both the common product planning process as well as the somewhat complex nature of I-talk as a product, is made.

Requirements Engineering for Building IT – an Industrial Case Study iv

Requirements Engineering for Building IT – an Industrial Case Study v

Acknowledgements I would like to take this opportunity to thank all the patient people I have used and hassled to get substantial input to this thesis report. I would especially like to thank my supervisor Claes-Peter Haväng at TAC AB for his constant interest and support during the writing of this thesis. Also, the man who unknowingly pushed me through the hard work of completing this thesis report, my academic supervisor Björn Regnell at the Department of Communication Systems at Lund Institute of Technology, deserve the warmest of thanks. Finally, I would like to thank the I-talk team at TAC AB for their support and encouragement during the days at TAC. Malmö, March 2003 Anders Åkesson

Requirements Engineering for Building IT – an Industrial Case Study vi

Requirements Engineering for Building IT – an Industrial Case Study vii

Table of Contents

Abstract .........................................................iii

Acknowledgements .......................................... v

Table of Contents............................................vii

Introduction .................................................... 1 1.1 Background ..................................................... 1 1.2 Audience ......................................................... 1 1.3 Objectives ....................................................... 1 1.4 Outline............................................................ 1

Theory and Techniques..................................... 3 2.1 Software Engineering ........................................ 3

2.1.1 Comprehensive summary ................................................................... 3 2.1.2 Process improvement ........................................................................ 4

2.2 Requirements Engineering ................................. 5 2.2.1 Requirements ................................................................................... 6

High-level requirements ................................................................ 6 Functional requirements................................................................ 6 Domain-level requirements............................................................ 6 Product-level requirements............................................................ 7 Design-level requirements ............................................................. 7 User requirements........................................................................ 7 System requirements.................................................................... 7 Quality requirements .................................................................... 7

2.2.2 Quality............................................................................................. 7 2.2.3 Describing the process activities.......................................................... 9

Feasibility study ........................................................................... 9 Elicitation and analysis ................................................................ 10 Specification .............................................................................. 12 Validation.................................................................................. 16 Prioritization .............................................................................. 17

2.2.4 Requirements engineering processes ................................................. 18 A general phase-oriented process model ....................................... 18 A state-oriented process model .................................................... 18

2.2.5 CASE - Computer Aided Software Engineering .................................... 19 Existing tools ............................................................................. 20

2.3 Usability.........................................................20 2.3.1 Measurements ................................................................................ 20 2.3.2 Benefits ......................................................................................... 21 2.3.3 Usability testing .............................................................................. 21 2.3.4 Conducting a test ............................................................................ 21

Planning.................................................................................... 21 Selecting Users .......................................................................... 21 Collect user data ........................................................................ 22 Develop prototype ...................................................................... 22 Conduct test .............................................................................. 22 Iteration.................................................................................... 22

2.4 Evaluation methods .........................................22 2.4.1 Heuristic evaluation ......................................................................... 22 2.4.2 Capability Maturity Model – CMM....................................................... 23

2.5 Prototyping.....................................................24 2.5.1 A general prototyping process........................................................... 24 2.5.2 Throw-away prototyping .................................................................. 25

Requirements Engineering for Building IT – an Industrial Case Study viii

Table of Contents

2.5.3 Evolutionary prototyping .................................................................. 25 2.5.4 e-Prototyping.................................................................................. 26 2.5.5 User interface prototyping ................................................................ 26 2.5.6 Prototyping benefits ........................................................................ 27

The Current Situation ..................................... 29 3.1 The domain of TAC ..........................................29

3.1.1 Business goals ................................................................................ 29 3.1.2 Products......................................................................................... 29 3.1.3 I-talk ............................................................................................. 31

3.2 Establishing the current work process.................32 3.2.1 Why?............................................................................................. 33 3.2.2 The interviews ................................................................................ 33 3.2.3 Observation.................................................................................... 33 3.2.4 Reading ......................................................................................... 33 3.2.5 Web library..................................................................................... 34

3.3 Current work process .......................................34 3.3.1 Actors............................................................................................ 34

Sales Person.............................................................................. 34 European Coordinator ................................................................. 34 Technical Product Manager – TPM................................................. 34 Product Planning Team – PPT....................................................... 34

3.3.2 Workflow for deciding new functionality ............................................. 35 3.3.3 Fast-Lane development.................................................................... 36 3.3.4 Requirements ................................................................................. 36

Workshop.................................................................................. 37 3.3.5 Summary ....................................................................................... 37

3.4 Future: Product Planning Process.......................38 3.4.1 Actors............................................................................................ 38

Technical Product Manager .......................................................... 38 Market Managers........................................................................ 38 Regional Product Council ............................................................. 38 Management Research & Development ......................................... 38 Product Proposal Web ................................................................. 39 Product Planning Team................................................................ 39

3.4.2 Phases and activities ....................................................................... 40 Market input phase..................................................................... 40 Create product vision phase......................................................... 40 Approve product vision phase ...................................................... 40 Preliminary plan phase................................................................ 41 Approve start of development phase............................................. 41

3.4.3 Requirements ................................................................................. 41 3.4.4 Summary ....................................................................................... 41

3.5 CaliberRM – a CASE tool ...................................41 3.5.1 Introduction ................................................................................... 41 3.5.2 TAC benefits ................................................................................... 42

Central storage .......................................................................... 42 Distributed communication .......................................................... 42 Easy integration ......................................................................... 42

3.5.3 TAC Challenges ............................................................................... 43

PREP-IT........................................................ 45 4.1 Goals.............................................................45

4.1.1 Integration ..................................................................................... 45 4.1.2 Speed ............................................................................................ 45 4.1.3 The core ........................................................................................ 45 4.1.4 Requirements prioritization............................................................... 45 4.1.5 Requirements representation ............................................................ 46

4.2 Overview........................................................47 4.3 Actors............................................................47

4.3.1 Technical Product Manager ............................................................... 47 4.3.2 Regional Market Manager / Sales ...................................................... 48 4.3.3 Project Manager .............................................................................. 48 4.3.4 Developers ..................................................................................... 48 4.3.5 Product Planning Team .................................................................... 48

Requirements Engineering for Building IT – an Industrial Case Study ix

Table of Contents

4.4 Phases ...........................................................48 4.4.1 Idea evaluation phase...................................................................... 48

Activities ................................................................................... 49 4.4.2 Study phase ................................................................................... 49

Activities ................................................................................... 50 4.4.3 Project start-up phase ..................................................................... 50

Activities ................................................................................... 51 4.5 Activities ........................................................51

4.5.1 Elicitation ....................................................................................... 51 4.5.2 Negotiation..................................................................................... 52

Specification .............................................................................. 52 Estimation ................................................................................. 52 Prioritization .............................................................................. 52

4.5.3 Validation....................................................................................... 53 4.5.4 Prototyping..................................................................................... 53

4.6 Requirement refinement...................................53 4.6.1 Issued ........................................................................................... 53 4.6.2 Evaluated....................................................................................... 54 4.6.3 Investigated ................................................................................... 54 4.6.4 Specified ........................................................................................ 54 4.6.5 Implemented .................................................................................. 54 4.6.6 Rejected ........................................................................................ 54

Evaluation Results ......................................... 57 5.1 PREP-IT .........................................................57

5.1.1 Goals ............................................................................................. 57 5.1.2 Idea evaluation phase...................................................................... 57 5.1.3 The prioritization activity.................................................................. 57 5.1.4 Requirements refinement ................................................................. 58 5.1.5 Overall........................................................................................... 58

5.2 Prioritization ...................................................58 5.2.1 Requirements collection ................................................................... 58 5.2.3 The pre-meeting ............................................................................. 58 5.2.4 The prioritization meeting................................................................. 59 5.2.5 Result ............................................................................................ 60 5.2.6 Follow-up ....................................................................................... 60

5.3 Logbook prototype...........................................62 5.3.1 Logbook......................................................................................... 62 5.3.2 Background .................................................................................... 62 5.3.3 Objectives ...................................................................................... 62 5.3.4 Functionality................................................................................... 63 5.3.5 Development .................................................................................. 63

Database................................................................................... 63 View entries............................................................................... 64 Create entry .............................................................................. 64

5.3.6 Feedback ....................................................................................... 65 5.4 Usability of the prototype .................................65

5.4.1 Planning......................................................................................... 65 5.4.2 Users............................................................................................. 66 5.4.3 End-user test.................................................................................. 66

Ease of learning ......................................................................... 66 Efficiency of use ......................................................................... 66 Memorability.............................................................................. 66 Satisfaction ............................................................................... 66

5.4.4 Usability thoughts ........................................................................... 66

Conclusions and Future Work .......................... 69 6.1 Conclusions ....................................................69 6.2 Future work....................................................69

References.................................................... 71

Abbreviation List............................................ 75

Requirements Engineering for Building IT – an Industrial Case Study x

Table of Contents

Appendix A ................................................... 77 Original logbook requirements ..................................77

Appendix B ................................................... 83 Preliminary requirements specification .......................83

Appendix C ................................................... 89 Prioritization result Table..........................................89

Appendix D ................................................... 93 Prioritization result document....................................93

Appendix E ................................................... 99 Prototype source .....................................................99

logbookmenu.jsp ....................................................................................... 101 listlogbook.jsp ........................................................................................... 101 createlogbookentry.jsp ............................................................................... 103

Requirements Engineering for Building IT – an Industrial Case Study 1

Introduction This Section contains some background information, the objectives of this thesis and how to read it.

1.1 Background

TAC is a company who develop, produce and market products that improve indoor environment. Starting out with the production of control hardware alone, TAC has evolved and is now also a supplier of software. This software is mainly application based software which support their hardware solutions. TAC I-talk® is a web based business platform and is very different from these other software products. The lack of an established requirements engineering process has larger affect on I-talk, since web-based software suffers from shorter time-to-market demands. The quality of I-talk staggers and in order to once again be a competitive alternative, active measures are taken. One of these measures is to analyze the current situation and propose a better requirements engineering process. This thesis is an attempt to do that.

1.2 Audience

Since this report focuses on TAC’s processes and refers to some internal documentation, accessible only from within TAC, the main audience is employees at TAC. However, an external reader should be able to profit from the reading. Enough information from the internal documentation is reflected in the report for the contents to be understandable.

1.3 Objectives

This thesis main objective is to propose and evaluate techniques used in requirements engineering. The methods and processes used in I-talk projects today are investigated and analyzed. Results from this investigation serve as a basis for the new requirements engineering process proposal. Some of the techniques proposed in this process are evaluated in a case study. The case study is concerned with producing a prototype of a logbook function for I-talk. Requirements for this logbook are collected, analyzed, prioritized and finally prototyped.

1.4 Outline

Chapter two of this report presents the theories and techniques of requirements engineering. However, the chapter barely scratches the surface of software engineering. It is recommended that the reader possesses some basic skills of software engineering before reading the entire report. Also, this chapter introduces the scientific views on usability and prototyping. Chapter three presents the analysis of the processes used at TAC today. The beginning of this chapter briefly presents TAC and the I-talk idea. Ending this chapter is a short introduction to CaliberRM, the requirements management tool used at TAC.


Chapter 1: Introduction

In chapter four, a process proposal for requirements engineering related to I-talk is presented. Actors, phases and activities of the process are defined. A proposal of a requirements refinement model adapted to TAC conditions ends the chapter. In chapter 5, the proposed process, a prioritization study and the prototype are evaluated. Finally, in chapter 6, the last part of this report, the work and results of this thesis are presented. It reflects the intended objectives on the achieved results and suggests further work in the direction of this thesis.


Theory and Techniques The objective of this chapter is to introduce software engineering, requirements engineering, usability, evaluation methods and prototyping. Software engineering is the science of developing and producing software which will live up to the demands of functionality, reliability, costs and so on. A very important part of this science is the main theme in this thesis, namely requirements engineering. Requirements engineering deal with the more delicate procedure of eliciting, documenting, validating and prioritizing requirements which poses as the foundation of software development. More on software engineering and requirements engineering is found in Section 2.1 and 2.2. When dealing with requirements, usability can help in giving a more objective view of a system and its functions. Often requirements can get to technical at an early stage, reducing the flexibility of implementation in a later stage. The classification of requirements is also a delicate matter explained further in Section 2.3. In order for new development ideas to gain trust with management, evaluation methods must be used for measuring the gain or loss when these ideas are put to the test. Different evaluation methods are discussed in Section 2.4. The need for and usefulness of prototyping is discussed in Section 2.5. Also, the many different types of prototyping are described.

2.1 Software Engineering

Virtually everything produced today incorporates some sort of software, either the product contains some sort of controlling software, or the product relied on machines controlled by software whilst being produced [Sommerville, 2001]. This massive integration with software on all levels has led to the fact that software now is one of the largest contributing parts in system costs. Thus, it has been identified that software needs to be produced and maintained in a cost-effective way. One way to achieve this is to use strict methods for planning, documentation, implementation and testing.

2.1.1 Comprehensive summary

Software is not just computer programs but also all associated documentation and configuration data which is needed to make these computer programs operate correctly [Sommerville, 2001]. This fact implicates that it requires more than just programming to engineer good software, which is true. Software engineering is the name of the discipline which is concerned with principally all aspects of producing good software. One of the key elements is planning. Software development can easily take more time than expected. In the early days of computing and software development, the customer was happy when the computer, with the help of some sort of software, produced just about anything [Sommerville, 2001]. Time was not of the essence. Nowadays, however, time is indeed of the essence. The date of delivery is a major part in software engineering. The company, who can produce the correct software in the shortest amount of time and to a reasonable price, gets the order. The consequence of a delayed delivery can be severe (Penalties, Lawsuits and so on).


Chapter 2: Theory and Techniques

Another important element is documentation. Software is definitely not eternal. The world changes, hardware changes and user demands changes so why should not software change? Updating existing software to concur with these changes is often immensely cheaper than developing entirely new software. But, in order for evolution of existing software to be possible, good documentation is a must [Sommerville, 2001].

2.1.2 Process improvement

The production of software includes software development processes. The general opinion is that using these processes facilitates work, resulting in higher quality products [Sommerville, 2001]. However, there is always room for improvement. Different software companies use different methods and work in different ways. An optimal process should be adjusted to fit a specific company even when work methods and/or staff changes. This is where the need for continuous process improvement has been identified. By improving the development process, companies can reduce the amount of time and money that is spent on development. These reductions are a result of the facilitated work which has made it easier to, for example, meet deadlines, find errors early in the development, etc. If a company reduce their internal costs and are able to deliver high quality software faster, they will be more competitive on the market. Improving processes is a process itself. This latter process is a long and iterative process. Often a software development process can be improved in several places. Activities describing the work in these places are the ones actually improved. Although, introducing several improvements simultaneously can be a slower solution than introducing them one at a time. It is easier to train employees and tune the process changes if the improvements are introduced one at a time. A basic software process improvement method is described by Karlström [Karlström, 2002]. This method is shown in Figure 2.1.

Start Assess Change

Figure 2.1 – Basic software process improvement method [Karlström, 2002].

This basic method consists of three steps: start, assess and change. The first step, start, is concerned with getting management to sponsor and support improvements. In the next step, assess, an evaluation of the current method is made comparing it to some kind of reference. In the final step, change, the actual changes are made. Sommerville presents a process improvement model, shown in Figure 2.2, which fit the two latter steps in the method described in Figure 2.1.


2.2 Requirements Engineering

Analyseprocess

Processmodel

Identifyimprovements

Processchange

plan

Trainingplan

Introduceprocess change

Trainengineers

Feedback onimprovements

Revisedprocessmodel

Tuneprocesschange

Figure 2.2 – Process improvement model [Sommerville, 2002].

Here the improvement is described in five steps: 1. Process analysis, the current process/processes must be analyzed,

evaluated and documented. 2. Identify improvements, after the analysis, possible weaknesses and

bottlenecks are found. This step is concerned with proposing new methods to address the problems found.

3. Introduce process change, improvements stated in the previous step must be integrated in the existing process.

4. Train engineers, all personnel must receive training to incorporate the improvements made to the process.

5. Tune process changes, the improvements have to be tuned to achieve desirable results and to satisfy employees.

When comparing this model with the Karlström method, one can see that step 1 and 2 in Sommervilles model corresponds to the assess step in the basic method and step 3, 4 and 5 corresponds to the change step.


This Section presents requirements engineering, activities related to it and their usage. Also, the importance and benefits of good a requirements engineering process is pointed out. When improving the software engineering process, the area, which may have the largest effect on the result, is requirements engineering. Requirements are the first things produced, and projects are conducted and finalized in strict concordance with them. A change in a single requirement can have large effects on a project. But it is not only requirement changes that are important. The production of good, quality software relies on a well-defined method and on a structured work procedure [Lauesen, 2000]. The ideas and thoughts concerning new products must be elicited and analyzed. If this in done in a proper way, time is saved in later stages of projects. If time is saved, costs are reduced. If costs are reduced, everyone, including management and customers, is satisfied. The ideas then have to be documented as requirements and verified to check that they correspond to the ideas elicited in the first place. Later on, when it is time to start implementing some software product that will fulfil the requirements, prioritization comes into play. Realizing all requirements may be impossible, due to time constraints or conflicting requirements among others. This is why requirements, preferably early in the requirements engineering process, need to be prioritized. More on challenges in requirements engineering can be read in [Karlsson et al 2002].



The common activities involved with requirements engineering are explained further in this Section, but first some basic knowledge is needed.

2.2.1 Requirements

One big difficulty with requirements is that there is no unambiguous definition of what a requirement really is. This has also resulted in numerous different categories being defined for requirements. One likely reason to why there exists no common definition of the term requirement is that a requirement does not have the same meaning for different types of products/project. Two examples of a requirements definition are:

Requirement: A specific feature, function or capability that the system must perform as viewed from the external perspective. [ITFlightplan, 2003]

Requirements are descriptions of how the system should behave, application domain information, constraints on the system's operation, or specifications of a system property or attribute. [Kotonya & Sommerville, 1998]

As mentioned above, there are many different categorisations of requirements. Depending on what a requirement describes, it must be put in the correct category. This is done so that it is easier to know when a requirement is to be used in the requirements process. Say, as an example, that a test engineer wants to test some quality aspect of a function, which is being developed. This may be impossible, since the requirement describing the functionality has not yet been considered, meaning that the functionality is not yet implemented. Below, some common categories are defined.

High-level requirements

The original thoughts and ideas of a system with very low detail are called high-level requirements. These requirements are often very abstract and ambiguous. They state everything from system functionality to user interaction and quality restrictions. This is usually the first form a requirement takes. To be able to gain from these requirements, they often need to be broken into smaller parts. When these smaller parts have been defined, the requirements may end up in a different category.

Functional requirements

The functional requirements specify functions of the system, how the system records, computes, transforms and transmits data [Lauesen, 2000].

Domain-level requirements

The domain is the product and user. The work in the domain is what the user and the product can do together. These requirements describe the activities that go on outside the product - in the domain [Lauesen, 2000].



Product-level requirements

This is the products part of the domain-level requirements. This can also be seen as the equivalent to system requirements. Product-level requirements specify what should come in and out of the product [Lauesen, 2000].

Design-level requirements

Requirements of this form are often not produced in the beginning. They can on the other hand be the result of a prototype. They contain design restrictions on the product.

User requirements

The user requirements are a form of high-level requirements. They explain, in natural language and in some cases with diagrams, what services the system is expected to provide and the constraints under which the system must operate [Sommerville, 2001].

System requirements

These requirements are detailed descriptions of what the system should do [Lauesen, 2000].

Quality requirements

As mentioned earlier, requirements are based on the stakeholders’ ideas and thought of the product. They make up the rules for a software product of some sort. It is easy to make the mistake to believe that requirements on software are strictly relating to its functionality, but this is not true. Since software with the same functionality can be compared, it must depend on something other than their functions. The common word is that the quality of one software product is better than the quality of the other. Quality requirements, also known as non-functional requirements, state demands that are not so obvious, such as response time, security, ease of use and much more. These are all of great importance in a software product.

2.2.2 Quality

The objective of most organizations is to achieve a high level of product quality. The market no longer accepts the deliverance of poor quality software followed by repairs and fixes. However, there is no simple definition of software quality. The classical notation is that the developed product should meet its specification [Sommerville, 2001]. This would be sufficient, but since the work with specifications is not an exact science, meeting a specification may not result in a high quality product. But, since high quality products is what the market wants and demands, increasing quality is a must. This is a never-ending process, since there is no such thing as a perfect organization.



Knowing that quality is important and necessary, there are several actions that can be taken to improve it. Usually the first action taken towards quality improvement is structuring work through process definition and improvement. However, quality work needs to be managed. Sommerville suggests the activities, which should be of help when structuring the work [Sommerville, 2001]:

• Quality Assurance - Aims at structuring work in the organization. Accomplished by introducing a framework of standards and procedures. This will improve work quality in the entire organization.

• Quality Planning - Aims at structuring and improving product planning. Accomplished by selecting appropriate procedures and standards from the organization framework. This will improve project quality.

• Quality Control - Aims at making people use defined processes and standards. Accomplished by following up on the work in the projects. This makes sure that the quality improvement measures taken will be followed.

Lauesen proposes more hands-on ways of dealing with software quality [Lauesen, 2000]. One good example is the quality grid showed in Figure 2.3.

Figure 2.3 - A quality grid for the hotel booking system [Lauesen, 2000].

This type of grid could be used as a general guideline for all projects/products as well as for a specific one. Also, Lauesen mentions that the wish to deliver a high quality product may result in all quality aspects being classified as important. However, this is unrealistic if project/product funding is not increased. Some sort of prioritization must be made.



Also, Lauesen lists what can be done to improve quality [Lauesen, 2000]:

• Work harder • Get more funding • Ignore unimportant things • Use better techniques

Here, some alternative ways of improving quality are mentioned. Although they may only be temporary solutions, they are proven to be effective. The one similarity with Sommerville's ideas is the 'use better techniques' part. The use of better techniques will hopefully also improve quality in the future, not only temporarily.

2.2.3 Describing the process activities

The requirements engineering process contains roughly the same activities in all kinds of projects. Figure 2.4 shows a general requirements engineering process.

Feasabilitystudy

Requirementselicitation and

analysis

Requirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

Figure 2.4 – General requirements engineering process model [Sommerville, 2001].

To get a better understanding of the activities involved, they are explained here.

Feasibility study

Initially there is some sort of feasibility study to see weather or not the project contributes to business objectives. This means that if the organization or company developing the final product will not benefit from it in any way, the project is a total waste of time and money and will thus not be executed. Other issues such as technological constraints or demands are also looked upon and summarized in a feasibility report. The next phase in the process is to elicit an analyze requirements.



Elicitation and analysis

Elicitation can be used for more than just finding and formulating requirements. Some elicitation techniques will help the requirements engineer to understand the system, current problems and future ideas. Although this will result in requirements, the requirements engineer will have a more complete picture of the product or functionality, which is going to be developed. Hopefully this will increase the correctness and quality of requirements. The quality of requirements will be addressed later. Knowledge of the general area where a system is applied is called “domain knowledge”. Domain knowledge is, as vaguely mentioned in the previous paragraph, very important when eliciting and analysing requirements.

… to understand the requirements for a cataloguing system, you must have a general knowledge of how libraries and how libraries work; to understand the requirements for a railway signalling system, you must have background knowledge about the operation of railways and the physical characteristics of trains. [Kotonya & Sommerville, 1998]

The hard part with domain knowledge is that it is not collected neatly in one place [Kotonya & Sommerville, 1998]. It exists in various different sources such as textbooks, manuals and in the minds of people working in the domain. Although the sources can be identified, it may be hard for a requirements engineer to understand specialist terminology used in the applicable domain. Stakeholders are one group of people, widely spoken of when talking about requirements, but who are the stakeholders? Stakeholders are the people needed to ensure the success of the project [Lauesen, 2000]. They could be a combination of, for instance customers, developers, marketing departments and management. All of these people will surely have different opinions on what is important and what is not, but the elicitation activity depends on the diversity of opinions. When outlining the requirements of a project, it is necessary to address everyone’s point of view. However, it is incorrect to assume that every stakeholder can express his or her needs in an understandable way. Often the stakeholders cannot even recognize their own needs, which lead to requirements being forgotten or overlooked [Lauesen, 2000]. One major problem faced by requirements engineers is the choice of method for acquiring requirements. The problem is not that there is a lack of method. Rather, no guidance is available to choose among the various [Maiden & Rugg, 1996]. There are several different elicitation techniques. Short descriptions of the techniques, which are considered in this thesis, are presented below [Lauesen, 2000].

Interviewing

A requirements engineer discusses the system with stakeholders to build up an understanding of their requirements.



There are two types of interviews [Kotonya & Sommerville, 1998]:

1. Closed interviews where a pre-defined set of questions are to be answered. 2. Open interviews where there is no pre-defined agenda. Instead there is an

open-ended discussion of what stakeholders want from the system. Interviewer must be open minded and willing to listen. Stakeholders must be given a starting point of discussion. It can be a question, a proposal or an existing system. “Tell me what you want” is unlikely to result in useful information. Interviews should be part of all requirements elicitation processes. Negative: Domain and organisational knowledge is hard to elicit. Positive: Good for establishing an understanding of the problem and to elicit high-level requirements.

Brainstorming

Requirements engineer asks a group of stakeholders to generate as many ideas as possible, with the emphasis on generation rather than on evaluation [Maiden & Rugg, 1996], about the system or product to be developed. This technique is good for eliciting high-level domain entities. Brainstorming also questions assumptions, which might have constrained certain approaches that were considered. Although, no criticism is allowed so all ideas are welcome. A brainstorming session usually ends with a common prioritization of the elicited ideas to get the most important ones and to, in a sense, prevent unrealistic ones.

Prototyping

Prototyping can be successfully used as an elicitation method, but can also be used for evaluating results. See Section 2.5 for more information on prototyping.

Scenarios

Scenarios are an effective way of describing end-user interaction with the system. Stakeholders, including end users, find it easier to relate to real-life examples than abstract descriptions of functionality offered by a system. Scenarios can be thought of as stories which explain how the system is used [Kotonya & Sommerville, 1998]. The question is what to include when specifying scenarios. According to Kotonya et al, scenarios should at least include the following information [Kotonya & Sommerville, 1998]:

1. a description of the state of the system before entering the scenario 2. the normal flow of events in the scenario 3. exceptions to the normal flow of events 4. information about other activities which might be going on at the same

time 5. a description of the state of the system after completion of the scenario

Negative: It can take a lot of time to develop scenarios which describe all interaction in a complex system. It requires high end-user involvement. Positive: Easy to understand.

Other

As mentioned above, there are numerous methods for acquiring requirements. Which method to use, depends on the information that needs to be acquired.



Maiden and Rugg discuss the usefulness of twelve different methods in different situations [Maiden & Rugg, 1996]. Lauesen has also described a large number of elicitation methods [Lauesen, 2000] which include advantages and disadvantages. One thing worth mentioning is that the experience of the requirements engineer affects the quality of requirements elicited [Lauesen, 2000]. A skilled requirements engineer has greater understanding of the method he/she uses and can, consequently, benefit more from the method. Not mentioned above is where the analysis part of this activity comes into play. Analysis is part of the elicitation. When a possible requirement is discovered it must be carefully analyzed to see if it is correct, complete and feasible. If the analysis shows that some of these necessary attributes of a good requirement are missing, further elicitation in the same area is needed. When this step is completed, requirements can be formulated and documented.

Specification

Documenting requirements is of great importance due to the information that can be extracted from a proper documentation. The phase, which is concerned with the documentation of requirements, starts when the requirements are being elicited. As soon as a requirement is found/elicited it must somehow be saved for the future. This is important because it should prevent any requirements from being forgotten or disappearing. Most requirements management tools use a requirements database where requirements are submitted and can be linked to each other. The use of a database makes requirements traceable, meaning that the change of a requirement can be traced through time. The first event usually states who came up with the idea resulting in the requirement. Later, information stating why the requirement has been rejected, if it has, or when the requirement is being implemented, e.g. what release it will be a part of, can be found. More about the usefulness of databases and CASE tools can be found later in "CASE - Computer Aided Software Engineering". There are numerous styles available for representing requirements. Lauesen describes several different styles [Lauesen, 2000] whereas Kotonya and Sommerville promote one style, Viewpoint-oriented requirements definition (VORD) [Kotonya & Sommerville, 1996], which will not be mentioned here. The use of styles depends on the type of requirements, the kind of interface and the type of project. The general idea with the styles and the requirements documentation is to make the requirements understandable and unambiguous. Lauesen uses a hotel booking system to describe his styles. Some of the styles from his book are described below [Lauesen, 2000].



Context diagram

The context diagram in Figure 2.5 shows the product (the hotel system) surrounded by systems and groups of users with which it communicates. Arrows are used to show dataflow between the entities. This form of representation gives developers a good over-view of what should be developed. It is easy to verify that all aspects of communication with the entities are dealt with. It is also an understandable style for customers not trained in software development, who can easily validate the diagram. Another advantage is that a project can easily be delimited to some part of the context diagram, since it is easy to see what is affected and what is not.

Figure 2.5 - Context diagram describing the hotel booking system [Lauesen, 2000].



Feature requirements

The most common way of representing requirements is to specify features in plain text. According to Lauesen, most customers and analysts cannot imagine other ways to specify functionality. With this style, both functional and quality requirements can be described. Feature requirements should include the key word "shall" as the examples in Figure 2.6, which clearly states that the feature must be supported. Although this style is easy to use, it is very difficult to formulate unambiguous requirements, thus making the development of the correct product hard.

Figure 2.6 - Feature requirements describing the hotel booking system [Lauesen, 2000].



Task descriptions

Task descriptions are structured text describing user tasks. The complete description is divided into different parts, describing different areas of work. The requirement in Figure 2.7, marked R1, is a domain-level requirement, meaning that it states what the product and the user together should achieve. A task description includes a purpose for the task, a precondition and some quality aspects, which the task must fulfil. Also, a task may include subtasks. These are minor tasks, which must be carried out in order for the larger task to be completed. How to divide the tasks and subtasks can be read in [Lauesen, 2000], but a rule of thumb is that a task should be complete, e.g. the user should have achieved something meaningful when completed the task.

Figure 2.7 - Task descriptions for the hotel booking system [Lauesen, 2000].

Use cases

The difference between a task and a use case is that a task is what user and product do together to achieve a common goal and a use case is mostly the product's part of the task. A use case describes an action or activity carried out by an actor of the product. The most common way of use cases are UML use cases. UML (Unified Modelling Language) is a standard notation used in object-oriented development. In Figure 2.8, UML use cases are shown for a hotel booking system. There are also other



types of use cases, but since UML is a widely known standard, this is the only one mentioned here. Use cases are, together with feature requirements, widely used. This is one of the main advantages of this style, since analysts and customers know them and their limitations

Figure 2.8 - Use case describing the hotel booking system [Lauesen, 2000].

Validation

One of the most challenging aspects of software development is the requirements validation. This is the process which is to ensure that the requirements specification document is an accurate reflection of what the customer wants [Fenkam, 2002]. Since the customer must be able to validate the requirements to see that they reflect his needs, he or she must be able to read the specification and understand it [Lauesen, 2000]. However, textual requirements specifications are often hard to validate. Some aspects, for example efficiency and usability, are almost impossible to validate, but there is a simple solution to this problem. Prototyping has proven to be of great use for all stakeholders, when validating requirements [Karlsson, 1998]. Prototyping is discussed later in Section 2.5. Although validation seems to have connection only to the requirements specification, it is important to realize that the validation process is continuous. This means that the validation of requirements, in any form, must be done all the time. It is very easy to implement something other than what the customer validated, without knowingly deviate from the validated requirements specification.



Prioritization

Often, a requirements specification contains a great many requirements. Since it may be impossible to be able to implement them all due to time constraints or product quality constraints, the requirements need to be prioritized. One likely scenario is that there are too many requirements. Another is that there are requirements that are so complex and time demanding that implementing them will not be practicable. When prioritizing requirements, several stakeholders should be involved. Depending on the product being developed and its purpose, different stakeholders should be selected to participate in the prioritizing. Involving to many stakeholders can result in an invalid prioritization due to conflicting interests. Some stakeholders should have more influence on the result than others, although this may render some stakeholders even less satisfied [Regnell et al, 2001]. This implies that prioritizing is a delicate matter and requires some diplomatic skills. As with many of the other parts of requirements engineering, there are many ways of prioritizing as well. Two of these, a numerical assignment technique and a pair-wise comparison technique, will be explained here.

Numerical assignment

This technique is based on assigning an absolute numerical value to represent the perceived importance of every requirement. A scale of importance is established and used when prioritizing. An example of a 5 step importance scale is presented below [Karlsson, 1996]:

• 5. Mandatory (the customer cannot do without it). • 4. Very important (the customer does not want to be without it). • 3. Rather important (the customer would appreciate it). • 2. Not important (the customer would accept its absence). • 1. Does not matter

This has proven to be a difficult technique due to problems when all requirements are important. However, the following technique can solve that problem.

Pair-wise comparison

Using this technique, two requirements at a time are compared to each other. Their comparison could result in a number stating the intensity of importance of the first requirement over the other [Karlsson, 1996]. Say, for example, that requirement A is compared to requirement B. If A is essentially more important than B, the intensity of importance is 5. But if B is essentially more important than A, the intensity of importance is a reciprocal value, 1/5. Thus, when comparing B to A, the intensity of importance will be 5. This example is based on an intensity of importance scale from 1, meaning equal importance, to 9, meaning extreme importance. Pair-wise comparison can be conduced in other ways. The comparison can be based on a different comparison questions, e.g. with emphasis on different issues. This technique will prove one requirement to be the most important. It will also show any requirements importance compared to any other, thus making the decision of which requirements to develop easy. Studies show that a pair-wise comparison technique is to prefer. Not only are they easier to conduct, but they also prove more accurate [Regnell et al, 2001].



2.2.4 Requirements engineering processes

To help facilitate work with requirements, different processes for handling the requirements exist. Processes are a way for requirements engineers and other people involved with requirements to know how to work. A documented process will not only help avoiding mistakes, but will facilitate the repeated work with requirements. The process can be used over and over again, possibly experiences will be documented and the process can be optimized over time. Often companies have their own highly customized requirements engineering process. This process can be an internally developed process, or a customized general process. To get a better view of what these processes can do, two models are presented here.

A general phase-oriented process model

In Figure 2.4 a general phase-oriented process model is shown [Sommerville, 2001]. This model is divided into four different phases. The first and initial phase is the feasibility study phase. Following the initial phase is the elicitation and analysis phase. This phase is in constant interaction with the third phase, specification. When requirements are specified, ambiguities can arise and requirements must be re-analyzed. It is also possible that new requirements must be defined. After several iterations between these phases, the last phase, validation, comes into play. Validation must ensure that the requirements specified in the specification are what the customers want. A similar inter-phase iteration occurs when some specified requirements are not validated.

A state-oriented process model

For market driven products with short "time-to-market" requirements are discovered on a regular basis. With this in mind, a process model with a concurrent approach will replace the traditional phase-oriented process model. With this state-oriented model, requirements are refined in parallel from their invention to their release. The refinement is based on a lifecycle model represented by a "ladder" of states for each requirement to climb [Carlshamre & Regnell, 2000]. The example chosen here is REPEAT, a requirements engineering process used at Telelogic AB. The states of REPEAT are shown in Figure 2.9.

New

Assigned

Classified

Selected

Applied

Rejected

Figure 2.9 - The REPEAT requirements lifecycle model [Carlshamre & Regnell, 2000].



The states in the REPEAT model are explained below [Carlshamre & Regnell, 2000]:

New

This state represents the initial state of a requirement. Every requirement is defined as new when it has been issued and given an initial priority.

Assigned

Requirements climb to the assigned state when an expert has been assigned to it. The expert shall investigate the requirement.

Classified

An expert has assigned values to some important attributes of the requirement and it will climb to the classified state.

Selected

All requirements in this state have been selected for implementation in the coming release. Here, requirements are sorted in priority in two different groups; one group containing mandatory requirements and the other group containing "nice-to-have" requirements.

Applied

This is an end-state indicating that the requirement has been implemented and verified.

Rejected

This is an end-state indicating that the requirement has been rejected. This is where duplicate requirements, requirements which not comply with product or company strategy among other reasons go.

2.2.5 CASE - Computer Aided Software Engineering

CASE tools, short for Computer Aided Software Engineering tools, are programs that facilitate and support various software activities [Sommerville, 2001]. The activities supported range from requirements analysis, change management and project management to testing, system modelling etc. CASE tools are increasingly important in larger organizations, where several projects, including large number of people, are running simultaneously. Another accurate definition of CASE from [McMurtrey et al, 2000] is found below.

Simply put, CASE is the automation of "anything a human does to software" (Stamps, 1987) [McMurtrey et al, 2000]

There are several proven benefits of using CASE tools. Productivity and quality will increase as a consequence of easier analysis, design and management. The uniformity between projects and between employees will also increase, since everyone must work according to the CASE tools. One of the most important and probably the reason why CASE tools are so popular is that the development time



is likely to decrease. This is because the CASE tools offer a structured way of working, avoiding known bottlenecks and problems. Although, CASE tools often are seen as the solution to all problems, there are drawbacks. Introducing a new CASE tool in an organization and getting people to work with it, requires large amounts of time. Acceptance for new tools may be low, since some functionality may not be provided [McMurtrey et al, 2000]. When it comes to the requirements engineering activities, support for requirements management, prioritization and analysis can be found in several different tools. However, since the nature of elicitation is to think of new possibilities and/or limitations, it is hard to find support for this in CASE tools. Also, elicitation is very different from organization to organization. One technique, perfect for one organization, may not even be remotely applicable on another organization.

Existing tools

Examples of some existing tools, which support requirements engineering activities, are DOORS from Telelogic [DOORS, 2003], Requisite Pro from Rational [RequisitePro, 2003] and CaliberRM [CaliberRM, 2003] from Borland. Since CaliberRM is the CASE tool used at TAC, more information about it can be found in Section 3.5.

2.3 Usability

Usability is an increasingly popular term in software development, but what is usability? According to the website Usability.gov [Usability, 2003] and others, usability is the measure of the quality of a user’s experience when interacting with a product or system. Unfortunately, quality is not the most ambiguous term.

2.3.1 Measurements

In order for usability to be effectively measured, some sort of quality definition regarding usability must be done. Usability quality is a complex combination of factors that affect the user’s experience with the product or system. Some of these factors are [Usability, 2003]:

• Ease of learning – How fast can a user who has never seen the user interface before; learn it sufficiently well to accomplish basic tasks?

• Efficiency of use – Once a user has learned to use the system, how fast can he or she accomplish tasks?

• Memorability – If a user has used the system before, can he or she remember how to use it the next time, or dose the user need to start over, learning everything again?

• Error frequency and severity – How often do users make errors while using the system, how serious are these errors and how do users recover from these errors?

• Subjective satisfaction – How much does the user like using the system? This is what should be measured, but will the work be worth while?


2.3 Usability

2.3.2 Benefits

The importance of usability becomes obvious when a product or system produced is rejected by users due to the factors mentioned above. The benefits are many and significant. Some examples of benefits of usability are [Ricks & Arnoldy, 2002]:

• Positive user experience • Users can accomplish their tasks simply and effectively • Users feel good about the product and the company • Reduced documentation and training costs • Reduced support costs • Reduced development costs

It can be concluded from these benefits, that usability is not only valuable for users, but also for companies/organizations. Indirectly related product costs are decreased. Also, if users cannot accomplish their tasks effectively, the trust for the product will decrease, possibly making future products unwanted. Keeping the customers happy and satisfied is the key to success.

2.3.3 Usability testing

In order for an organization to successfully harvest the benefits of usability, usability engineering must be woven into the organization. This engineering technique involves methods for increasing product or system usability. Some examples of usability engineering work can be development and testing of prototypes, analysis of usability problems, evaluation of design alternatives etc. Usability testing is a part of this engineering process and includes methods for having users try out a product or system. A typical usability test lets users perform a variety of tasks with a prototype, while an observer record notes on what the user does and says [Usability, 2003]. The goal of most usability testing is to uncover any problems encountered by users. Before making final releases of the product, these problems have been addressed and hopefully solved.

2.3.4 Conducting a test

There are a range of actions and decisions to be taken when conducting a usability test. The usual activities involved with conducting a usability test are described below.

Planning

The largest cost and effort is related to the planning of the test. However, cutting down on test planning will seriously affect the results of the test in a negative direction.

Selecting Users

First of all, it must be made clear what should be studied and tested. Simultaneously, users must be recruited for usability tests. Depending on which users are to be participating in the usability tests, focus on different areas may be necessary. Also, technical difficulties can interfere with the possibility to test certain things.



Collect user data

Since product or system design depend on the user needs, data must be collected about those needs and how well existing products meet those needs.

Develop prototype

Next, a prototype must be defined and developed. It is easier for a user to react/interact with a running prototype, than to theoretically elaborate on how he or she would react and do [Usability, 2003]. More on prototyping is found in Section 2.5.

Conduct test

When it is time to conduct the actual test with users, users are instructed to perform certain tasks using the prototype. Detailed information about user success and user reaction is gathered and reported.

Iteration

Optimally, several usability tests are carried out. Getting user feedback is vital when developing software with user interaction!

2.4 Evaluation methods

To reap benefits or identify problems with processes and executable software, they must be evaluated. Evaluating these requires different methods. One of the most commonly used methods for usability evaluation is heuristic evaluation [Danino, 2001].

2.4.1 Heuristic evaluation

This method relies on experts who judge the software’s/product’s compliance with defined usability principles, so called heuristics. This method can be used on a paper version of the software as well as on a prototype or the finished product. The result from a heuristic evaluation is a list with identified problems which should be solved. A negative aspect on heuristic evaluation is that the experts may have great knowledge and experience with usability issues, but they do not possess skills in the end-users field of work. As a result of this, the software can be flawless in regards to known usability issues, but there are certain areas were the end-user is the only one who can give good feedback. More about heuristic evaluation can be read in [Tec-Ed, 2003] and [Nielsen, 2003]. When processes are to be evaluated, they are compared to certain defined guidelines. A form of heuristic evaluation can be used, but the heuristics are somewhat different. Another process evaluation method is the Capability Maturity Model, CMM, which evaluates the entire organization including its processes.


2.4 Evaluation methods

2.4.2 Capability Maturity Model – CMM

This model classifies software processes into five different levels. Figure 2.10 shows the five levels and their main process areas.

Optimizing

Managed

Software quality managementQuantitative process management

Process change managementTechnology change managementDefect prevention

Initial

Repeatable

Software configuration managementSoftware quality assuranceSoftware subcontract managementSoftware project tracking and oversightSoftware project planningRequirements management

Defined

Peer reviewsIntergroup coordinationSoftware product engineeringIntegrated software managementTraining programmeOrganization process definitionOrganization process focus

Figure 2.10 – Key process areas of the CMM [Sommerville, 2001].

This model is used to establish the capability of an organization. Process improvement should be concerned with establishing the key process areas of each level. The five levels of the CMM are defined as follows [Sommerville, 2001]:

1. Initial level – At this level, the organization does not have effective management procedures or project plans.

2. Repeatable level – At this level, the organization must have formal management, configuration management and quality control. Projects can be successfully repeated although there is a lack of a formal process model.

3. Defined level – At this level, the organization have a defined process model.

4. Managed level – At this level, the organization have data and metrics collection, used for process improvement.

5. Optimizing level – At this final level, the organization has continuous process improvement, which is a key area of the organization’s process.

Problems with certain processes can be identified when applying this method, although individual processes may not be thoroughly evaluated. A comparison



between CMM and other evaluation processes can be found in [Ares Casal et al, 1998].

2.5 Prototyping

A prototype is a simplified version of part of the final system [Lauesen, 2000] and prototyping is the rapid development of a system [Sommerville, 2001]. Prototypes are used to investigate difficult and/or hard parts of a system. These parts are often the ones, which are most uncertain, meaning that there is a need for more knowledge in the area of those parts. The knowledge could be an attempt to try to understand the underlying requirements or an attempt to see if some quality aspects are feasible. Prototypes support the communication between developers and users, by letting developers experiment on requirements and users to give feedback on the prototype developed [Bleek et al, 2002].

2.5.1 A general prototyping process

There are steps to complete in order for a prototype to be of any use. Sommerville describes a general process of prototyping in four steps (Figure 2.11) [Sommerville, 2001]:

Establishprototypeobjectives

Defineprototype

functionality

Developprototype

Evaluateprototype

Prototypingplan

Outlinedefinition

Executableprototype

Evaluationreport

Figure 2.11 - The process of prototype development [Sommerville, 2001].

Establish prototype objectives

The objectives of the prototype should be explicitly stated early. If objectives are not clear, the benefits from the prototype might not be as expected.

Define prototype functionality

A prototype should have limited functionality. It is important to select the right functionality to prototype. It is even more important to leave out the functionality, which does not need to be prototyped. Also, functionality, which might take to much time, can be avoided in order to limit prototyping costs.

Develop prototype

The quality of the executable prototype, in capacity of error handling and/or reliability, does not necessarily need to be high. This, of course, is not the case if the prototype's objective is to investigate reliability or error handling.


2.5 Prototyping

Evaluate prototype

Here the benefits of the prototype are drawn. The prototype can be evaluated by end-users and produce important feedback. However, the evaluation can also show that some functionality or quality requirement is not feasible, thus the requirement need to be changed. One step not mentioned by Sommerville, but which Floyd describes in her process, is the future of the prototype [Bleek et al, 2002]. Depending on what information gained from the prototype, two possible kinds of future usage exist. The first possibility is to treat the prototype solely as a learning experience. This means that the information gathered is saved, but the prototype itself is discarded. This is more commonly known as "throw-away" prototyping. The second possibility is that the prototype, or at least parts of the prototype, will actually be used in the final system. One version of this is called "evolutionary" prototyping. In evolutionary prototyping an initial prototype is refined a number of times, finally ending up as the final system.

2.5.2 Throw-away prototyping

When using throw-away prototyping, it is often the case that the prototype will generate more requirements. Since these prototypes often experiments on areas where there is little understanding, requirements, which will make the area understandable, must be produced. The result can be two different kinds of functional requirements [Lauesen, 2000]:

Product-level requirements

The experiment has confirmed that the required functionality partly developed in the prototype is feasible and useful. A requirement saying that the functionality shall exist can be stated, but this will not limit the final system saying that it shall be exactly as the prototype.

Design-level requirements

The final system shall have the same functionality and it will be an interface exactly like the prototype. Although throw-away prototypes should be seen as a tool to reduce requirements risk, developers may be pressured to deliver a prototype of this kind as a final system. Doing that can pose many problems; vital system functionality may have been left out; the system can be poorly structured and impossible to maintain; there is no or poor documentation of the system.

2.5.3 Evolutionary prototyping

Opposed to the objective of the throw-away prototype, which is to validate or derive the system requirements, the objective of evolutionary prototyping is to deliver a working system. The latter type of prototyping is used for systems where the requirements specification cannot be developed in advance. Instead, specification, design and implementation are carried out at the same time in several iterations. System delivery is made in a series of increments, which for each step are of increasing functionality. Figure 2.12 show the steps in evolutionary prototyping.



Develop abstractspecification

Build prototypesystem

Use prototypesystem

Deliversystem

Systemadequate?

NO

YES

Figure 2.12 - Evolutionary prototyping [Sommerville, 2001].

The main advantages with evolutionary prototyping are the accelerated delivery of the system and the increased user engagement. It is often the case that customers expect new functionality requests to be implemented fast and if they not, customers will abandon the system and choose a competitor system. Also, if users are engaged throughout the entire development, it is more likely to produce a system, which meets user requirements. Although evolutionary prototyping might seem wonderful, there are drawbacks. One large and observed problem is that continual change tends to corrupt system structure. This will increase maintenance costs dramatically.

2.5.4 e-Prototyping

Bleek et al have written an article titled "Developing Web-based Applications through e-Prototyping" [Bleek et al, 2002]. In this article they describe an approach to prototyping called e-Prototyping, which can be used in web-based applications development. Since this thesis studies I-talk, a web-based business platform, a very brief presentation of e-Prototyping is presented here. The e-Prototyping process is part of a cyclic development process. The approach is very similar to evolutionary prototyping and the main idea is that the prototype evaluation relies on communicational means. The communication between users and developers is essential for driving the prototyping process. Several channels should exist; a reserved email address, a call-centre, a web site containing error report forms and electronic discussion forums.

2.5.5 User interface prototyping

A very important and worthwhile prototype is a simplified version of the user interface. A user interface cannot be effectively pre-specified [Sommerville, 2001]. The prototype can be just an example of what the user interface might look like. In this case, the prototype will need little or no functionality at all. This will result in some product-level requirements stating what should be included. However, a more useful prototype, which can be used for usability testing and tested against real tasks, can result in design-level requirements. The tests can show that some ways of performing tasks are satisfactory and some are not. This will give the restricting requirements for the design of the final system. However, it is important to involve end-users in the prototype evaluation.


2.5 Prototyping

2.5.6 Prototyping benefits

There are many benefits to prototyping. Depending on the intention of the prototype, certain areas of the prototyped system are improved. A study by Gordon and Bieman (1995) found five benefits of using prototyping in the software process [Sommerville, 2001]:

• Improved system usability. • A closer match of the system to the user needs. • Improved design quality. • Improved maintainability. • Reduced development effort.

The last benefit is very important because it defies general thoughts that prototyping increase costs. However, it is true that costs in an initial stage of a project increase, due to prototype development, but the benefits reduce costs in later stages. This is a direct result of the lesser need for rework and fewer system changes.


The Current Situation This chapter will attempt to explain the requirements engineering process at TAC and try to highlight problem areas. In order to make this possible, firstly this chapter contains a brief description of TAC and their products. Secondly, the work procedure used in I-talk today is described. Thirdly, the documented work procedure which is supposed to be used for all products/projects at TAC is outlined.

3.1 The domain of TAC

This Section contains a description of what TAC as a company is doing and which product they offer, with focus on TAC I-talk. In relation to theory, this Section is comparable to the term "domain knowledge". It is important to try to understand the reality in which processes are used. This makes the improvement suggestions practically applicable. The danger with not having accurate domain knowledge is that the improvement suggestions can be theoretically perfect, but they cannot be supported in reality.

3.1.1 Business goals

TAC is a supplier of integrated systems for building automation, based on information technology. The company's goal is to develop, produce and market products, open system solutions, and services that improve the indoor environment and provide the building owner with added value in the form of lower operating costs and more attractive properties.

3.1.2 Products

In order for indoor environment to be successfully controlled, hardware units called RPUs (Remote Processing Unit) are installed in a buildings heat and ventilation systems (Figure 3.1). The RPU contains some customized programmable logic for controlling the media system to which it is connected. The control of systems such as heat and ventilation are based on measurements of some sort (temperature, fan rpm, voltage, air flow etc.). Based on the value of the measurement, the heat and ventilation systems are adjusted to achieve the best indoor environment possible. Since air and water (most heat systems use water as heat carrier) react slowly to changes in temperature, the RPUs have a relatively long periodicity, opposed to real-time process control systems which have to react instantly to changes. Examples of RPUs are the Xenta family.


Chapter 3: The Current Situation

Heatingsystem

Ventilationsystem

Watersystem

RPU's

Figure 3.1 – RPU’s installed in media systems throughout a building.

With many RPUs spread throughout a building, it is hard to maintain, control and view the system. This is where Vista is used. A Vista server is installed locally in a building and is connected to all the RPUs in the building (Figure 3.2).

Heatingsystem

Ventilationsystem

Watersystem

RPU's

Vista Server

Figure 3.2 – A Vista server installed in a building.

From an ordinary workstation, engineers can connect to the Vista server and get a colourful presentation of the building’s status (fan rpm, temperatures and so on). The Vista server automatically logs values received from the RPUs and generate reports based on these values. However, in order for larger organizations, managing several buildings, having one Vista server in each building may pose a problem (Figure 3.3).


3.1 The domain of TAC

Vista Server

Vista Server

Vista Server

Vista Server

Vista Server

Management

Overview?

Figure 3.3 – Many different buildings with Vista server.

How are people concerned with the entire organization supposed to get a good overview, when information is spread out at several different locations? The answer is TAC I-talk.

3.1.3 I-talk

TAC I-talk is a web based business platform that offers a basis for decisions within the areas of indoor comfort, environment and finance based on expert analysis, experience and comparisons. The target group for these services is decision makers within the building management industry. The functionality to date has been focused on providing many basic services that present energy usage, energy costs, indoor comfort and alarm statistics. The target users of these services have a need to get a quick overview of the operation of the building and the above-mentioned services partly fulfil their need. To get deeper understanding and to continue the functionality explanation in the previous Section, an attempt to put I-talk in the building/information hierarchy will follow here.

Management

I-talkServer

Overview

Vista Server

Vista Server

Vista Server

Vista Server

Vista Server

Database Figure 3.4 – I-talk gathering information from all buildings.



In order to make reports and decisions based on the information in the entire organization, all, or some, information must be gathered to a common database. I-talk achieves this by installing collectors locally at every Vista server (Figure 3.4). Since the connection between I-talk and the collectors can be internet or dial-up connections, the problem with availability has been solved by making I-talk a passive master collector (Figure 3.5).

CollectorI-talk Vista

1

2

3

Figure 3.5 – Communication between I-talk, a collector and the Vista Server.

All collection is initiated by the locally installed collectors. They establish a connection to I-talk and finds out what information they are supposed to send. If I-talk has been out of reach at previous attempts to connect, I-talk will order the collector to send all information “not received”. In other words, I-talk orders the collector to send collected values since the last communication. The collector then gathers the information wanted, from the Vista server and sends it to I-talk. Below, a structural hierarchy model and a TAC product hierarchy model are placed side by side, making it easier to identify on which level products are used.

Measuringpoint

Measuringpoint

Building Building

Measuringpoint

Organization

RPU RPU

VistaServer

VistaServer

RPU

I-talk

Figure 3.6 – Structure hierarchy and product hierarchy.

3.2 Establishing the current work process

The actual work process lies in the minds of the employees. They are the ones using it every day. Therefore, interviews with people who are involved in the requirements engineering process seem to be the best option in getting to know the current way of work. Lauesen states the usefulness of interviews with this sentence:

…, interviewing is good for getting knowledge about the present work in the domain and the present problems. [Lauesen, 2000]

But how can it be assured that the process described here is a true picture of the process used at TAC? One way is to use several sources when interviewing and try to weave all information into one description of the process. An addition to this might be to let someone, who has not been interviewed, read through the


3.2 Establishing the current work process

description produced from the interviews and see if he or she agrees with it. But, since there are few people involved in the requirements engineering process for I-talk, interviews with all involved parts will have to be enough to ensure the correctness of the work procedure described in this chapter.

3.2.1 Why?

But why is information about the current way of work needed? It is somewhat obvious that it is impossible to improve a process if the current process is not understood. Also, problems, suggestions and ideas must be identified, or else there might not be a need to improve the process in the first place. Sommerville states the usefulness of understanding the old process:

Process improvement needs information about activities, deliverables, people, communications, schedules and other organisational processes that affect the software development process. [Sommerville, 2001]

In Chapter 2, some ideas regarding process improvement were identified. The first step taken in Sommerville's improvement model, shown in Figure 2.2, is the process analysis. Without an evaluation or analysis of the current work process, making improvement suggestions and even new processes would be scientifically incorrect. There is no need improving what is already perfect. Not analysing the current work process does not automatically make it imperfect. Now, the methods, for how the current situation at TAC is to be derived, will be explained.

3.2.2 The interviews

As seen under Section 2.2 in the Elicitation and analysis part, there are different techniques to use when conducting interviews. One way to establish the current work procedure is to have several predefined questions and compare the responses of all interviewees. On the other hand, it might be good to let the interviewees speak more freely on the subject “how do you work?”, since this can lead to information being revealed that might not have been revealed if predefined questions was used. The information in this Section has been retrieved using the latter method. The interviewees have been asked to describe the way in which work is carried out.

3.2.3 Observation

Another great method for getting knowledge about the way work is carried out is to study people involved in the process and how they work. This method is called Ethnographic studies [Sommerville, 2001]. This method is more likely to discover the true process use. However, it is a very time consuming and expensive activity which can last for several months. To get a complete analysis, it must continue from the initial stage of a project through to delivery. This, of course, makes it very impractical, since project often last several months/years.

3.2.4 Reading

At TAC some processes used during development are well documented. A thorough study of these documents aid in getting a better understanding for the processes used. It should be noted, though, that it is not always the case that



everyone follows the defined processes. That is why reading alone, cannot be the grounds for a valid understanding of work and problems.

3.2.5 Web library

At TAC there is an extensive web library of methods, rules and restrictions [Delphi, 2002]. Some documents in this library describe the different phases of projects, achievements for the different phases and so on. A new addition is the Product Planning Process [Nilsson, 2002].

3.3 Current work process

Until now, there has been no documented process describing activities in the requirements engineering process. This Section describes the work process used today. But before the description of what really goes on, the participating actors will be described.

3.3.1 Actors

The actors of the current process are somewhat fuzzily defined, but since the process description is based on interviews and some smaller documents, this should be very similar to the reality.

Sales Person

The sales person is the one person having close contact with end customers. He or she will collect and pass on the customers’ requests and thoughts to the correct people in the organization. The sales person is located at an affiliated company.

European Coordinator

The European coordinator handles all market-development coordination for Europe. He or she has close contact with the technical product managers and the market to be able to get the most out of both worlds. Also, he or she is very up do date on where both sides stand. The european coordinator will pass on feasible/valuable requests to the corresponding technical product manager.

Technical Product Manager – TPM

The TPM is the technically responsible person for a product. He or she is also responsible for eliciting early requirements and making a product vision, which is to be presented to the product planning team.

Product Planning Team – PPT

The PPT guides products and makes decisions weather to approve product visions or not. PPT participants are highly placed people from the entire organization seeing to the vision of all the products developed by the organization.



3.3.2 Workflow for deciding new functionality

Since I-talk is a customer driven product, customers are the ones initiating the process of describing, analyzing and documenting requirements. The workflow can be described in a number of steps:

Affiliatedcompany

Europeancoordinator

TPM

PPT

1

2

4

3

5

6

7

Figure 3.7 – Illustrating the workflow.

1. A formal inquiry of new functionality is sent from an affiliated company to TAC’s European coordinator. This inquiry is created in close contact with the end customer (here on referred to as the customer).

2. The coordinator conducts a brief investigation whether or not to spend more time investigating the new functionality and, depending on the result, sends the inquiry to the TPM for I-talk.

3. The TPM conducts a more thorough investigation, looking into, for example the possibilities to offer the same functionality to other customers. If the new functionality can not be offered to other customers, i.e. it is a tailored solution usable only by the customer wanting the functionality; the development costs will be paid by the customer. Otherwise the functionality can be developed as an in-house project, which will enhance the product for all customers. This resulting in the customer not being billed the development costs. If the new functionality does not fit into I-talk, the TPM will reject the inquiry and notify the affiliated company that the functionality will not be developed. If this is the case, the workflow will end here, meaning that no further work will be done regarding the functionality.

4. After the thorough investigation, a recommendation is sent to the PPT (Product Planning Team), which makes the final decision whether to start a project inserting the new functionality or not. If the project is to be carried out, the PPT creates a new project plan and assigns people to the project. The price for the project is settled.

5. The decision made by the PPT is sent to the inquiring affiliate company including information of costs and a time estimate for the project inserting the functionality.

6. The affiliate company informs the customer and if necessary an order is sent to TAC.



7. Upon reception of the order, the TPM starts the work on a requirements specification, which is sent to the project manager, PM. After this, the well-described software development process can be used.

There should be a TPM for every project running at TAC. However, I-talk is currently without a TPM, which somewhat complicates the requirements engineering process1. Instead the PM creates the requirements specification. This procedure may take up to 18 months depending on the importance of the functionality and the workload of the PPT. This may have a negative effect on customers. Having to wait that long just to get a decision or an offer might make customers go away or not wanting the functionality, thus time spent on investigation and planning will be lost.

3.3.3 Fast-Lane development

An alternative to the extensive process above is the fast-lane development method [Haväng, 2002]. Since development decisions, which must pass through the PPT, can take a lot of time, the need for a faster method is obvious. The idea is that functionality, which will not affect anyone except the customer wanting it, thus leaving the greater perspective of I-talk as a product alone, will be paid for by the customer. This is no different from the ordinary method, but here it goes one step further. When the customer is the one paying for the project, a consultant can be brought in and take care of all development work. This means that the functionality is developed and inserted alongside the normal projects. The work is carried out by someone else than employees at TAC. An external project does not need to be planed by the PPT nor does it have to go through the European coordinator. Avoiding the PPT and the coordinator will thus speed up the process. The main goal of this method is to begin development of new functionality almost instantly. The TPM is supposed to respond to an inquiry within a week from its arrival. If a decision is made to conduct a pre-study of the functionality, the outcome should be available to the customer within two to three weeks. After this, the development project, in which the new functionality is developed, can be started. This gives a total time of about one month before development is started. This should be put in contrast to the 12 – 18 months it can take when involving the PPT. Although this sounds like a reasonable method, it is disliked among employees and decision makers. Developers complain since service and maintenance of code developed in the external project might end up on their desk. This might not sound troublesome, but companies use different standards for writing code. Digging in code written by someone else, who furthermore uses a different programming approach, is the developer’s worst nightmare. But developers are not the only ones complaining. Management dislikes the thought of parts of an in-house project being in the hands of others. The PPT is responsible for planning all projects running at TAC, and external projects can introduce non-planned risks.

3.3.4 Requirements

Requirements are collected continuously. The requirements are analyzed and elicited by the TPM and he or she includes some of the important ones in the

1 A TPM for I-talk was appointed at the same time as the finishing of this thesis.



product vision. The selection of which requirements are to be implemented or not, is made by the TPM in concordance with the european coordinator. Some main requirements are the basis for each project carried out, and new requirements are not inserted into an existing project. If a new requirement is very important, the PPT can allow a new project, implementing that requirement, to be started, temporarily suspending the running project. When dealing with the requirement specification, there is no uniform way to describe the requirements. Depending on the person writing them down, he or she usually also creates use-cases. These use-cases describe and involve actors and user goals. Along with these use-cases of a more detailed level, summary use-cases are produced. The summary use-cases are of a more comprehensive nature, describing several use-cases. All use-cases are UML use-cases. These should be presented together with an explanation of why they exist. Although, there is no rules stating that use-cases shall have an explanation.

Workshop

A requirements workshop was held at TAC where developers and project managers brainstormed together. These are the people who are handed the requirements specification produced in the above described process. The result from the workshop was primarily a number of demands regarding the requirements in the requirements specification. Some of the demands were:

• Requirement justification – making it easy to understand why the requirement exists.

• Non technical requirements – keeping requirements on an abstract level, keeps them from constraining the software.

• Requirements prioritization – making it easier to see what is important from a customer’s point of view and what is not.

• Traceability – identifying from where the requirement originated. • Requirements iteration – letting developers having a say in the high-level

requirements specification. Also, issues not relating to requirements directly were brought up, but will not be issued here.

3.3.5 Summary

There are problems with the current work process. As mentioned above, the process is not very customer friendly due to the PPT bottleneck. Responsibilities are not clearly stated, nor are the activities in each phase. A suggestion of a faster development process has been suggested, but this process also has serious issues. Rules describing how requirements are to be dealt with are not defined. The look and detail level of requirements depend on the person writing them. What does this current work process mean when looking at the capability maturity model in Section 2.4? Well, since the process model is not properly defined, the I-talk organization cannot be classified higher than the repeatable process level. Project are successfully repeated, the organization does have formal management and quality control.



The many problems observed and spoken of in the current work process, are likely to lower quality of delivered products. Since there are little or no documentation on what people should do, project groups need experience of working together. If there is no experience, the likelihood of problem is greater. This makes people less flexible, since restructuring people in projects, may lead to co-operation problems. Some of these issues have been addressed and solved in the Product Planning Process.

3.4 Future: Product Planning Process

This Section describes the documented work process starting with market demands and ending with the start of a project. This process is under development and it is going to be introduced and used for all projects in the near future. The process is called the Product Planning Process, or just PPP.

3.4.1 Actors

The actors of the Product Planning Process are well defined. Below, the actors are listed and briefly explained. Some of their responsibilities are also stated. More details can be found in [Nilsson, 2002].

Technical Product Manager

The technical product manager, TPM, is the owner of a 0-2 years development roadmap of the product for which he or she is responsible. He or she shall serve as the link between the market and the research and development department. Also, the TPM is the one responsible of collecting requirements and seeing to that the evolution of the product, for which he or she is responsible, goes in a desirable direction.

Market Managers

The market managers are responsible for gathering input on customer requirements and product ideas. They have the responsibility to filter and prioritize the ideas, before making a formal product/function request, in the form of a product vision, to the technical product manager.

Regional Product Council

The regional product council, RPC, is a workgroup that summarizes product enhancements requests from different regions to a list, which is sent to the market manager.

Management Research & Development

Management research & development, MR&D, is responsible for managing and running projects at the R&D department. They are also responsible for allocating employees and funding at the R&D department.


3.4 Future: Product Planning Process

Product Proposal Web

The product proposal web is a database for product proposals. This database can be seen as an actor since it provides input for new projects and products. Subsidiaries send proposals to this database.

Product Planning Team

The product planning team, PPT, is responsible for implementing the strategic direction of a 3-5 years product vision. The PPT guides the vision of products and makes decisions weather to approve projects and product visions or not. The team is also responsible for cancelling and prioritizing projects. Members of the PPT are:

• The Marketing Research and Development Manager • The TPM Manager • Market Managers • The Technology Manager • The Commercial Manager • The Research and Development Manager

PPT meetings are held monthly and quarterly. Monthly meetings are held locally and representatives not physically present are participating via phone. Quarterly meetings take place with all representatives physically present.



3.4.2 Phases and activities

The phases of the PPP can be easily identified in Figure 3.8. They are explained below in greater detail. Complete information about the phases can be found in TAC’s internal web [Delphi, 2002] [Nilsson, 2002].

SubmitProductIdeas

SubmitProductIdeas

SubmitProductIdeas

CreateProductRequest

CreateProductVision

ApproveProductVision

TechnicalSolution andEstimation

ApproveStart of

Development

CreateRequirementsSpecification

PP

TM

R&

DP

rop

osa

lsW

eb

Reg

ion

al

Pro

du

ctC

ou

nci

l

Mark

et

Man

ag

ers

TP

M

Figure 3.8 – An overview of the Product Planning Process [Nilsson, 2002].

Market input phase

This phase focuses on the needs of the customer. Customer inputs are gathered from many stakeholders, meaning anyone who is impacted by a TAC product. Customer requirements on TAC systems or products are sent to the TPM for the affected product.

Create product vision phase

This phase is concerned with creating a product vision. The TPM is the person responsible for creating the product vision. The product vision is essential to the success of the product. It specifies the goals of the product development and correlates those goals with the needs of the market. The effort in this phase should reflect the scope and extent of the product vision. The customer requirements gathered in the market input phase, act as the basis for the product vision.

Approve product vision phase

In this phase, the product vision created by the TPM is reviewed by the PPP. They evaluate the product vision and check justification, feasibility and overall strategic direction. In this phase, the decision whether to go ahead with the product vision or to reject it is made.


3.5 CaliberRM – a CASE tool

Preliminary plan phase

This phase is the main planning phase of a project. The TPM is responsible for writing a requirements specification based on the approved product vision. If the project scope is big and complex, the TPM can bring in more people from the R&D department to help him or her with the planning. Along with the requirements specification, a time and cost estimation must be produced. These two documents serve as a basis for decision in the following phase.

Approve start of development phase

The product planning team decides whether to proceed with the project and start development, kill the project or place it on hold. This phase is mainly concerned with waiting for a decision. Once approved, the requirements specification is sent to the R&D department where TAC’s software development process is used.

3.4.3 Requirements

No significant difference from the undocumented work process regarding requirements exists. There is no new documentation stating anything regarding requirements engineering.

3.4.4 Summary

The PPP is an attempt to put the existing work process to print. It is easier for employees to work in a uniform and compatible way if the process is properly documented. Although the PPP is not yet completed, it will most certainly be a step in the right direction. Introducing the PPP is necessary in order for any requirements engineering to be successful. With the introduction of PPP, the I-talk organization will advance in the capability maturity model in section 2.4. The process model is defined and the organization will fulfil the key process areas of the defined level.


Along with the new PPP, a CASE tool has been evaluated and used in small scale among TAC employees. The tool is called CaliberRM and is a requirements management tool [CaliberRM, 2003]. This thesis has not focussed on the functionality of and possibilities with CaliberRM. The summary of CaliberRM possibilities below should not be grounds for any decisions. Instead, it should be seen as a very brief introduction to CaliberRM2.

3.5.1 Introduction

In CaliberRM, requirements are specified and saved. CaliberRM uses a central database to store all requirements. Upon creation, a requirement will automatically receive a unique id. Also, there is a possibility to enter creation date, author and a description among other. Although it seems as if the only way of representing requirements is in natural language, files can be attached to every single requirement. These files can be almost anything, from use-cases to executable

2 For more information on CaliberRM and its functionality, check out [CaliberRM, 2003] in the reference chapter.



examples of prototypes etc. These files can be grounds for decision if the description/specification of the requirement is not enough. If studies and reports can be of any help, they can also be attached to a requirement. The increased importance of prioritization is seen in CaliberRM as well. There is direct prioritization support in the sense that a requirement can be addressed an absolute priority. But there is no direct support for pair-wise prioritization. Although, CaliberRM can be used in such a way that requirements can be sorted in specific order, thus achieving a pair-wise comparison behaviour. Each requirement can also be discussed in a discussion forum, making distributed communication possible. Everyone with a CaliberRM client and the appropriate access can connect to the central database and participate in discussions. If the functionality of CaliberRM is not enough, the program can be integrated with other products from Borland, for example StarTeam.

3.5.2 TAC benefits

As mentioned above, CaliberRM is currently being evaluated by employees at TAC. It is being used in small projects on a high level, but has not yet been tested in full scale. If TAC is supposed to buy and use this requirements management solution, offered with CaliberRM, there must be some benefits. Also, CaliberRM must fit into the work process used at TAC. But will it fit in PPP, the product planning process? Yes, it is believed so!

Central storage

It is said that one of the main reasons why a CASE tool should be used, is that they can offer a central storage of requirements. This is a good enough reason for using CaliberRM regardless of what other possibilities/difficulties it might bring. Although, management at TAC will of course try to take full advantage of CaliberRM, in order to raise quality and make work more efficient.

Distributed communication

With the new PPP, work is more divided. Requirements are used, specified and discussed in several phases by several different people. The distributed nature of CaliberRM is well suited for the PPP.

Easy integration

The way requirements are to be treated in PPP, CaliberRM will be a good solution. Requirements are specified by different people continuously. All these requirements can be inserted in the database and be dealt with when time allows. There is some not so well-defined refinement of requirements in the PPP. CaliberRM is well suited for allowing and supporting the refinement. Overall, CaliberRM will support the needs of TAC and will also support development in the requirements engineering field.



3.5.3 TAC Challenges

As with all new programs and processes, the acceptance for change is usually low. Employees must learn to master CaliberRM if it is to be used effectively. Other than that there seems to be no larger challenges, but the future will show the success of CaliberRM at TAC.


PREP-IT This chapter describes a requirements engineering process proposal, based on some theoretical guidelines and information retrieved during interviews. The new process, called PREP-IT (Parallel Requirements Engineering Process for I-Talk), aims at improving requirements engineering for TAC's product I-talk. With chapter 3, TAC's new process for product planning was introduced. PREP-IT has been defined so that it can be integrated and used together with the product planning process. It is important to introduce process changes slowly in order for PREP-IT to win approval. A complete change of the product planning process would most certainly result in PREP-IT being discarded. As seen in section 2.1, the software process improvement method consists of three steps, start, assess and change. The start of this master thesis settles the first step. Chapter 3 evaluates the current processes, satisfying the assess step. To complete a single iteration of this method, improvement changes must be introduced. That is what this chapter does. PREP-IT is an attempt to introduce improvements to the work process for TAC I-talk.

4.1 Goals

With chapter 3, reflections on the current way of work were gathered. Different stakeholders have different opinions about how work should be carried out.

4.1.1 Integration

It was identified that the actual work procedure was very similar to the new product planning process, which has recently been introduced. Although I-talk has not been considered as a product among others, thus getting "special treatment", the future for I-talk is clear. It shall be considered as an ordinary "product" and work with I-talk shall follow the product planning process. This is the basis for the first goal of PREP-IT, namely integration.

4.1.2 Speed

During interviews with developers of a product similar to I-talk, E-net, it was identified that one of the more important goals of a new process should be to improve the time perspective. This means that the time starting when a proposal of new functionality or a new service is submitted, ending when a decision has been made to develop the functionality/service, must be shortened.

4.1.3 The core

Since descriptions of new services or new functionality often are vague and far from well defined, it is important to be able to find the core in what the customer wants.

4.1.4 Requirements prioritization

If requirements are prioritized in a good manner, it is possible to derive a base functionality or rather a necessary base functionality, which must be developed for the ordered service to be considered ready. However, the base functionality of the


Chapter 4: PREP-IT

service should be quite simple and easy to support. Although all requirements have not been fulfilled, the basic functionality is approved. The functionality, introduced with the remaining low priority requirements, can be released later. This should speed up the time it takes for new services to be added.

4.1.5 Requirements representation

The high-level requirements specification documents that have been produced for I-talk are not very formal and do not use any established method or form for requirements representation. The need for a suitable representation form exists. However, the CASE tool CaliberRM is as mentioned in Section 3.5 currently being introduced at TAC. This will affect the representation forms available, since the selection of a form not supported by CaliberRM will conflict with the integration goal above. Summed up, the goals to achieve with this new process are:

1. To integrate this process with the existing processes and tools used at TAC.

2. To shorten the time it takes for new ideas to be analyzed. 3. To derive core functionality at an early stage. 4. To make the prioritization of requirements efficient. 5. To use a suitable from for requirements representation.

It is important not to forget the more general goals that requirements engineering processes try to fulfil [Sommerville, 2001]. These are:

1. To help improve the quality of the existing process (if such a process does exist).

2. To facilitate peoples work with requirements. 3. To help improve the quality of the product. 4. To increase the customer's satisfaction.

The following Section contains a short presentation of PREP-IT. Later, the activities supporting the mentioned goals are presented.


4.2 Overview

4.2 Overview

In this Section, an overview of PREP-IT is presented. Since the phases of PREP-IT are easily linked to the phases of the product planning process, some elements of the latter will be illustrated and referred here.

PPT

Ideaevaluation

phase

Studyphase

PPT

Projectstart-upphase

SDP

Prototyping

Sales TPM

Sales EndCustomer

Developer

Issued

Evaluated Investigated

Specified

ProjectManager

ProjectManager

TPM

Requirement refinement state Actor

Figure 4.1 - An overview of PREP-IT's phases and actors.

Figure 4.1 presents an overview of PREP-IT. The process starts with the idea evaluation phase where sales and the TPM provide input. In this phase, requirements are identified and classified as Issued. The PPT makes a decision on what has been produced in the idea evaluation phase and approves start of the study phase. As input, this phase receives the Evaluated requirements. The study phase takes requirement elicitation one step further and can optionally use prototyping. At the end of this phase, requirements can be classified as Investigated and the PPT can approve project start-up. The project start-up phase continues specifying the requirements and can leave fairly specified requirements as input to the Software Development Plan, SDP. Next, the participating actors of PREP-IT are introduced.

4.3 Actors

The actors of PREP-IT are almost the same as for the existing product planning process. Although descriptions of the actors may be identical, they are stated here as well, making it easier to read about PREP-IT without reading about the existing process. Some of the actors' responsibilities and tasks are not mentioned here, since they have noting to do with the requirements engineering process.

4.3.1 Technical Product Manager

The technical product manager, TPM, is the owner of a 0-2 years development roadmap of the product for which he or she is responsible. He or she shall serve as


Chapter 4: PREP-IT

the link between the market and the research and development department. Also, the TPM is the one responsible of collecting requirements and seeing to that the evolution of the product, for which he or she is responsible, goes in a desirable direction.

4.3.2 Regional Market Manager / Sales

The regional market manager is responsible for gathering input on customer requirements and product ideas in his or her region. He or she has the responsibility to filter and prioritize the ideas from the region, before he or she makes a formal product/function request, in the form of a product vision, to the technical product manager. Also, he or she shall represent the region at the product planning team meetings.

4.3.3 Project Manager

The project manager is the leader of a project. He or she is responsible for the development of a project plan based on a product vision. Also, the project manager is responsible for running the project and making it a success.

4.3.4 Developers

The developers are employees at TAC who develop software systems. The developers are responsible for eliciting the detailed requirements together with the project manager. A developer is also responsible for implementing the detailed requirements, which have been assigned to him or her.

4.3.5 Product Planning Team

The product planning team, PPT, is responsible for implementing the strategic direction of a 3-5 years product vision. The PPT guides the vision of products and makes decisions weather to approve projects and product visions or not. The team is also responsible for cancelling and prioritizing projects. Members of the PPT are:

• The Marketing Research and Development Manager • The TPM Manager • Market Managers • The Technology Manager • The Commercial Manager • The Research and Development Manager

PPT meetings are held monthly and quarterly. Monthly meetings are held locally and representatives not physically present are participating via phone. Quarterly meetings take place with all representatives physically present.

4.4 Phases

The phases and their activities are explained in greater detail in this Section.

4.4.1 Idea evaluation phase

The purpose of the idea evaluation phase is to gather ideas and wishes from the market. Inputs may be gathered from many different stakeholders. In this case, the


4.4 Phases

stakeholder can be anyone who is impacted by a TAC product, including end-user, sales person, engineering person, market manager, etc. This phase shall focus on the needs of the customer. The ideas proposed are primarily requests for new services. However, an idea can be the basis for a new service even if it originally was not intended as a service. The shaping of ideas, producing a product vision, is the technical product manager's responsibility. This phase must produce a context diagram explaining the base functionality and the interactions with users/other systems. This diagram should be on an abstract level, not going into details of design and implementation. The meaning of the context diagram is to help the technical product manager and developers to elicit requirements on an abstract as well as a detailed level. The product vision must contain all reasons for wanting the functionality/service. If these reasons are supplied, it is easier to suggest alternative solutions and to make strategic decisions. An existing template for the product vision document is found on TAC's internal web [Delphi, 2002]. This template includes all the important issues considered here. In parallel to creating the product vision, the technical product manager should specify the ideas and wishes mentioned in the product vision as business requirements in CaliberRM. If this is done, it will be possible to trace requirements elicited later in the process to these, making them meaningful. If the categorisation "business requirement" is not satisfactory, the possibility to create a new category exists. This could be interesting, since this will make it possible to trace a requirement to the original idea.

Activities

The activities within this phase are primarily:

• Very-high-level elicitation • Negotiation • Estimation • Validation

More details on the activities can be found later in Section 4.5.

4.4.2 Study phase

The purpose of the study phase is to investigate the ideas approved in the product vision. The investigation will not solely be carried out from a technical viewpoint. It will, as in the idea evaluation phase, have considerable focus on the customer, or even better, the market. Depending on the product visions desired features, market needs and competitive solutions; the study will be of varying size. If the scope is big and complex, the technical product manager can get additional help by means of a project manager and developers. The first activity to perform in this phase should be to elicit the ideas and initial requirements. Often the ideas can be transformed to high-level requirements with more detail. There are several means with which this can be conducted. A brainstorming session with focus on the existing ideas is one alternative, specify


Chapter 4: PREP-IT

and evaluate a prototype is another. The advantages and disadvantages of these methods can be found in chapter 2. When conducting this elicitation, all new requirements and ideas must be documented. Also in this phase, CaliberRM would be a suitable CASE tool to use. Linking requirements makes them easier to trace. Another advantage is that if requirements are saved continuously in CaliberRM, it is possible to follow the requirement throughout its evolution. Already in this phase, some initial prioritization of the requirements should be made to ease and steer further work. One simple prioritization method would be to sort the requirements saved in CaliberRM based on a primitive form of pair-wise comparison. The PPT decision is partly based on the estimates made in this phase. Time and cost estimates must be presented in some form. If this cannot be made for each individual requirement, requirements can be estimated as groups. Finally, when the high-level elicitation and prioritization is complete, a high-level requirements specification shall be submitted to the product planning team. A specification can easily be produced in CaliberRM if it contains all requirements.

Activities


• High-level elicitation • Initial prioritization • Estimation • Specification • Validation


4.4.3 Project start-up phase

This phase in concerned with producing a detailed requirements specification. As a basis for the detailed requirements is the approved requirements specification produced in the study phase. As in the study phase, more requirements can be elicited by conducting a brainstorming or by producing a prototype. Here, however, the prototype can be a good way of restricting design and/or to get customer feedback on usability. Evolutionary prototyping is probably the best way of letting customers know that work is progressing. More on prototyping and its benefits can be found in Section 2.5. It is also necessary to prioritize requirements in this phase so that work with the most important parts of the new functionality/service is carried out first. However, it can be the case that an abundance of requirements have been elicited and defined. This will require a selection of requirements to be implemented in the project to be made. A requirement not selected for implementation will however not be a waste. Since it has been analysed and saved, it is easier and cheaper to include it in future projects.


4.5 Activities

Activities


• Low-level elicitation • Prototyping • Prioritization • Specification • Validation


4.5 Activities

There are a number of activities described or referred to in each phase. The activities are primarily elicitation, negotiation and validation. Figure 4.2 will try to illustrate how these activities are connected.

Elicitation

Negotiation

- Specification- Estimation- Prioritization

Validation

Prototyping

Figure 4.2 – Phase activities.

These activities are mainly concerned with requirements. Each one of the activities is explained below.

4.5.1 Elicitation

As described in chapter 2, elicitation is an activity which enables new requirements to be extracted. This activity is also the net which captures all ideas and requirements. It is vital that ideas or requirements are not lost during elicitation, and this is why requirements must be saved in some suitable form. Since the CASE-tool CaliberRM supports saving requirements as well as ideas, it would be a good idea to use it to support this activity. But how will elicitation be carried out? TAC uses a strict project based development. Elicitation is mainly done before projects are started, although


Chapter 4: PREP-IT

comments and ideas are gathered along with the execution of the projects. The possibility to submit new ideas for products already exists in the Product Planning Process. Elicitation before project start-up must, however, include some key stakeholders. The most important stakeholder for a market driven product is of course the customer or end user. His/Her ideas are usually good but vague. The project manager and the technical product manager should also attend these meetings, to be able to maintain the right scope or vision of the product. However, involving developers can be both good and bad. Often, developers can see technical difficulties not realised by customers or any of the managers, which is good. On the other hand, developers tend to make such difficulties larger than they really are, preventing possible ideas. The elicitation, including the key stakeholders, can be effectively carried out, by arranging for example brainstorming meetings or conducting interviews as described in chapter 2.

4.5.2 Negotiation

This is an activity concerned with getting every stakeholders ideas and wishes to work together. This activity is divided into the specification activity, the estimation activity and the prioritization activity.

Specification

As mentioned in the elicitation activity, all elicited requirements must be saved or documented. After every interview or brainstorming session, one of the participants, preferably the technical product manager, must document what has been elicited. This is achieved by entering/updating the information in CaliberRM. Since CaliberRM supports distributed discussions, arguments and thoughts arisen after the interviews or brainstorming session can be submitted as well. The specification which is to be produced in this activity takes a different shape in the different phases. In the idea evaluation phase, the specification is equivalent to the product vision.

Estimation

The estimation activity is one of the more abstract activities. In order to separate and get more knowledge about the requirements they must be estimated. When this information is present, the task of selecting requirements for implementation and calculation budgets etc. is much easier. Depending on what should be estimated, the technical product manager must find a suitable person who can make the estimation. The estimation of market value can for instance be done by a sales person or a market manager. On the other hand, an estimation of the time it takes to develop the requirement should be done by a developer.

Prioritization

Prioritization is necessary to get a better picture of what is possible and important. An experiment where pair-wise comparison, described in detail in chapter 2, was used. The results of this prioritization can be found in Section 5.2. This method for


4.6 Requirement refinement

prioritizing the requirements is recommended, although the work with reflecting the result in the requirements management tool CaliberRM, can be some what tedious, although fully possible.

4.5.3 Validation

The validation activity is concerned with validating the requirements. As stated in chapter 2, this means that the requirements must live up to some predefined quality attributes. If much time is spend on the validation activity, the result will be cost savings in the form of less changes and rework. Also, not to forget, the validation of the requirements must see too that the requirements really define what the customer wants or said he or she wanted. At TAC today, reviews of documents are a common and natural work activity. The conduct of these reviews is documented and appropriate for PREP-IT as well.

4.5.4 Prototyping

An excellent technique for elicitation, analysis, negotiation and validation of requirements is prototyping. This technique can be used in all the main activities above and should therefore be considered as an activity itself. As explained in Section 2.5, there are several areas were prototyping can facilitate work. The prototyping activity shall improve requirements elicitation, system usability and time-to-market. More requirements will arise when users are presented to the prototype. System usability will improve as a result of the prototype being presented to and used by end-users. The time-to-market will decrease as users can se that the prototype is being developed.


Figure 4.3 shows the requirement states of PREP-IT. The states are based on the REPEAT model presented in chapter 2.

Issued

Evaluated

Investigated

Specified

Implemented

Rejected

Figure 4.3 – The requirement refinement states in PREP-IT.

What does a requirement have to fulfil in order to be assigned a certain state in this requirement refinement model? A list of attributes which a requirement must fulfil in order to be transferred to the different states is found below.

4.6.1 Issued

A requirement cannot be handled by the process if it does not fulfil some basic attributes. These attributes are:


Chapter 4: PREP-IT

• ID – A unique id. • Title – A descriptive name. • Author – The name of the person who came up with the idea (can be used

more generally also, e.g. the company which came up with the idea). • Date • Type – What type of requirement it is (Business/Software/Hardware). • Description – A description of the requirement in shall-form.

These attributes are necessary for a requirement to be treated as Issued. CaliberRM have support for all of these attributes and should with advantage be used.

4.6.2 Evaluated

The idea evaluation phase produces input to more of the analyzed requirements attributes. The product vision contains information regarding market value, user gain and technical value. This information is bound to the requirements. Each requirement must have estimation for at least these attributes:

• Market value • User gain • Technical value

4.6.3 Investigated

In order for a requirement to be classified as investigated, all information which may be needed by the project start-up phase must be defined. It must be decided how much resources a requirement will demand. This can in some cases be directly related to the estimation of development cost, but this is still a rough estimate. The estimates needed to fulfil this state are:

• Resource usage • Development cost

4.6.4 Specified

A requirement will have a specified development time when it has been thoroughly studied with the help of developers. This study does not take place in the PREP-IT process, but it is the first activity undertaken in the software development plan, SDP. The requirement will after this have an estimation of:

• Development time

4.6.5 Implemented

When a requirement have been implemented and validated, it shall be classified as implemented. This state is an end-state, meaning that once a requirement has reached this state, it will stay there forever, unless future modifications remove the need for the requirement.

4.6.6 Rejected

At any time in the requirement refinement model, a requirement can be sent to the rejected state. This means that the requirement has not been selected and will



never be addressed again. This is also an end-state. The reason for sending a requirement to the rejected state can vary. An example might be that a similar requirement exists or that a contradiction between requirements would occur if the rejected requirement continued to exist.


Chapter 4: PREP-IT


Evaluation Results This Section contains the evaluation results of this thesis. These results are divided into four different Sections. First, the evaluation of the proposed process, PREP-IT, is presented. The process evaluation is followed by the prioritization evaluation, evaluating the prioritization experiments conducted in the scope of this thesis. Finally, the logbook prototype is evaluated in two different Sections. The first Section describes the pure prototype evaluation, meaning a technical and planning evaluation. The last Section describes the usability evaluation.

5.1 PREP-IT

A thorough evaluation of PREP-IT would require it to be introduced and used in real life. Since the introduction of a process is a time demanding activity, the evaluation of PREP-IT is based on comments and suggestions made by the newly appointed technical product manager for I-talk and a project manager.

5.1.1 Goals

PREP-IT defines speed as one goal. The term speed is related to the more commonly known term time-to-market. This goal is not easily achieved, depending on the company’s entire organization. If TAC had been a product oriented organization instead of a project oriented organization, the situation had been easier. Now, people are not assigned to the same product all the time. It is the technical product manager’s task to gather an assembly of people for each project. This task is quite complex, since people can be unavailable, assigned in other projects. Another comment, also relating to the stated goals, was the need to get requirements identified and introduced fast. It is often the case that requirements are not immediately stored, resulting in them being forgotten. This is a serious problem and should be stated as a goal.

5.1.2 Idea evaluation phase

The purpose of the idea evaluation phase is to gather ideas and wishes from the market. However, all ideas are not fully evaluated. The ideas that are not included in the product vision must be saved in some form. This will result in there being not only the market as an idea source, but also old saved ideas must be taken in consideration. There are some attributes needed to be estimated in the idea evaluation phase. One estimate which is included in the product vision is the ROI, return of investment. This is an essential estimate and the PPT uses it when they make their decision on weather to go ahead with the product vision or not.

5.1.3 The prioritization activity

The work with reflecting prioritization results in CaliberRM can be done in several different ways. An alternative is to use the requirements grid available in CaliberRM, but there is still somewhat limited support for sorting requirements in a custom way.


Chapter 5: Evaluation Results

5.1.4 Requirements refinement

One attribute not mentioned in the issued state is origin. This is an attribute which TAC already has considered to include in their usage of CaliberRM and it should also be included here. Another great argument for adding this attribute is that when evaluating a prototype, it is good to know who came up with the requirement leading to the prototype. This stakeholder can provide useful feedback on the prototype, not expressed by other stakeholders.

5.1.5 Overall

The overall reaction on PREP-IT is positive. In includes ideas and thought which can be applied to the work with I-talk and possibly other products.

5.2 Prioritization

This Section will evaluate the prioritization part of this thesis. A prioritization meeting was held, where participants used card sorting to prioritize requirements. The original collected requirements, the preliminary requirements specification and the prioritization result can be found in Appendix A, B, C and D.

5.2.1 Requirements collection

Before any kind of prioritization is possible, requirements must be collected. Three basic sources for requirements on a logbook function were established at the beginning of this thesis. The three sources are Kärnfastigheter, an organization using I-talk, two TAC market representatives who have been involved with I-talk and finally developers from TAC Finland who have developed a similar function in a similar system. To get the most out of each source, the techniques for gathering the requirements were somewhat adjusted to fit the source. Kärnfastigheter, a user source, was encouraged to answer these basic questions:

• Why do you need a logbook? • How do you want to work with the logbook? • What should the logbook contain? • Who will use the logbook? • Who will enter and who will read/view?

The TAC market representatives were encouraged to explain their vision with the logbook in addition to the above questions. However, the developers of the similar functionality in Finland were instructed to reproduce the customer feedback they have had on their logbook. Also, their thoughts and ideas on what might enhance the logbook for I-talk.

5.2.3 The pre-meeting

One week before the prioritization meeting was held, a pre-meeting was organized. This meeting's intention was to get the participants to understand and get familiar with the gathered requirements. Originally, the invitation went out to 5 persons, but only 3 had the possibility to attend. The meeting started with a short presentation of what the participants had in front of them. They had been given a preliminary ill-edited printout of a text file, containing a presentation of


5.2 Prioritization

requirements sources and their requirements (see Appendix A). They were also given a paper of hand-drawn use-cases, reflecting the requirements in the document. The meeting strayed somewhat of course and came to be mostly about the chain of decision regarding new I-talk functionality. Finally, minor comments were given on the preliminary requirements specification. It was decided that prior to the next meeting, the prioritization meeting, a refined compilation of the text file would be handed out. Although the meeting seemed to be a total disaster, the introduction to the requirements was necessary.

5.2.4 The prioritization meeting

A list of 40 requirements gathered from three different sources (Marketing, TAC Finland and Kärnfastigheter) was handed out one day before the meeting. This list had three check boxes for each requirement, including the text "Must/Uncertain/Reject". There were 4 people attending the meeting. All invited participants were there. The participants consisted of a marketing representative, a project manager, a technical product manager and a software developer. The intention was that the meeting was to be carried out as instructed in the handout (see Appendix B). A conference room had been booked for one hour, which seemed to be a reasonable amount of time prior to the meeting. The participants had been instructed to check one of the three checkboxes for each requirement prior to the meeting. All participants besides one had done this, but there were several ambiguities. Since the pre-meeting had not worked, this meeting had to start with going through the requirements document, straightening out any question marks. All participants had questions. Some requirements were not understood, some requirements was said to be fuzzy. In general, there were lots of complaints on the requirements. There were also discussions of how I-talk worked technically, which requirements depended of each other, etc. After approximately 40 minutes, most questions were dealt with, and the decision on the classification of every requirement had to be made. 40 cards were handed out to every participant, every card containing the reference to and description of one requirement. As instructed, every requirement that was classified as uncertain by at least one participant had to be prioritized. The walkthrough of the list, making a note of the requirements classification, was fairly quick. When making the walkthrough, each participant had put their cards in three different piles; one for "Must" requirements, one for "Uncertain" requirements and finally one for "Reject" requirements. The "Must" and "Reject" piles, containing 7 respectively 4 cards, were put aside and participants focused on the "Uncertain" pile, containing 25 cards. The shortage in number is a result of requirements grouping. All participants agreed on grouping requirements 28 through 32 as one, making the amount of cards smaller. This part of the meeting took about 5 to 10 minutes. As the instructions stated, two sorts of prioritization were to be made. The marketing representative and the project manager were appointed the role of "Marketing". The technical product manager and the software developer were appointed the role of "Developer". All participants said that they had understood the technique and they were instructed to start. Although originating from the same instructions, all four participants had different techniques; a long row from left to right, a single column, clusters and a single pile. The card sort did not take much time and was finished in about 15 minutes.



As the participants were gradually finished, their card order was written down. Three of the participants had the intended list of cards, where one card was more valuable or expensive than the other, but one participant had sorted the cards into small clusters, where cards were of equal importance. This participant had 7 clusters and the rank for each requirement should therefore be treated in another way. All cards in a cluster should be assigned the same rank.

5.2.5 Result

The result of the meeting was 4 piles of cards, sorted in two different ways. Two of the piles were sorted according to development cost and the other two according to market value. In concordance with Björn Regnell, a hands on way of calculating their final rank/score was defined.

• RankX(r) is the rank for requirement r made by participant X. • N is the total number of prioritized requirements. • Participant 1 and 2 are "Developers". • Participant 3 and 4 are "Marketing people".

A requirement's cost-rank, Rc, can be calculated as follows: Rc = (N - Rank1(r)) + (N - Rank2(r)) A requirement's value-rank, Rv, can be calculated as follows: Rv = (N - Rank3(r)) + (N - Rank4(r)) Finally, a list with the final score can be calculated as follows: Score = Rv - Rc This will mean that the requirement, which has the largest market value and the lowest implementation cost, will have the highest score (see Appendixes C and D). However, there is a serious problem using this technique. When sorting the requirements, no attention is paid to the dependability of the requirements. A requirement, which other requirements depend upon, may receive a low score while the depending requirements may receive a high score. In the ideal case, the requirement, which others depend upon, must receive a higher score than the requirements, which depend upon it. Also, if two requirements are dependant of each other, they must receive the same score. This must be taken in consideration when deciding which groups of requirements that are selected for implementation.

5.2.6 Follow-up

The intention of a follow-up is to get feedback on the prioritization meeting and result. Participants were asked a number of questions and their responses were written down. Most responses were discussed among the participants. Sometimes, all agreed on a comment and sometimes there were differences in opinion. The questions asked were:

• Do you have any general comments? • What did you think of the prioritization? • Was it easy or hard?


5.2 Prioritization

• Was it unnecessary? • How was the result? • Is the technique worth using? • Was the prioritization to early? • Were the requirements poorly expressed?

The participants’ responses can relate to several questions and aspects. Therefore, the responses should be seen as reactions or general comments and are found below: It was hard to classify a requirement as uncertain. After the first walkthrough, all requirements were either classified must or reject. Another walkthrough was needed to decide which of the must requirements that could be classified as uncertain. If all requirements are must-requirements, there will be no requirements to prioritize. This is a difficulty all participants encountered. The meaning of each requirement must be clear prior to the prioritization meeting. Different interpretations can make a requirement be reclassified from reject to must and vice versa. The task of formulation natural language requirements is very hard. Experience of formulating requirements is needed. It is a common problem today that requirements are expressed in a fuzzy way. Some of the requirements in this case study were very fuzzy. However, this is the developers' opinion. There is a clear difference in which point of view you look at the requirements. The participants playing the role of "marketing people" thought that some requirements were fuzzy, but they felt as if they were clearer to them than to the developers. Different stakeholders expressed the requirements on a very high level. Developers think one step further, seeing the problems and questions that will arise. The pre-meeting must go through the requirements specification (or the list of requirements) thoroughly and straighten out any question marks. Also, the requirements should be grouped and later prioritized for each group at this meeting. It is obvious in the result that grouping is needed. Requirements, which are highly related, have very different score. (Ex: requirement 25 and 26) The general thought is that it is good to conduct the prioritization early, although requirements are more likely to be fuzzy. The must-requirements and the prioritized requirements must be merged after a successful prioritization. Just because a requirement is a must-requirement, it does not mean that the requirement must be implemented first. If other requirements, which have some similarities with the must-requirement, exist, these requirements may need to be grouped and implemented together. Once again, grouping of requirements would ease. There were too many requirements to sort. It was hard to keep the overall perspective when having to go through so many requirements. "I guess it will go here" was a common thought after comparing. The participants estimated that about 15 requirements is the maximum number of requirements possible to overview. A smaller amount would have made it easier.



The judging of a requirements value or cost was hard, but the physical work was easy and fun. Although, if the prioritization would take place once again with identical data, the outcome probably would have been different. It would be interesting to see the differences between two identical prioritizations conducted with a week's interval. This would show which requirements that were correctly prioritized and also which requirements that were badly prioritized. One really positive comment was that the prioritization with respect to both market value and development cost would be more valuable than the "usual" developers-only prioritization. It may be hard to have the extra time necessary to prepare a prioritization meeting of this type, but the participants are positive that time would be saved in the long run. There are no numbers that show the gain in time and it is very hard to estimate. The result of the prioritization is good. The mix of market value and development cost is very interesting, since this shows what is really important, or if a technical cost will be backed up by a high market value.

5.3 Logbook prototype

This Section describes the prototype, which was developed during this thesis.

5.3.1 Logbook

The question "what is a logbook?" might not strike as a difficult question, but there are many different thoughts and ideas regarding the definition of a logbook. In this case, the idea of a logbook function in I-talk is that it shall serve as a manual event log for buildings and organizations. The type of entries in this event log should concern details about a building. But thoughts on what the logbook shall contain are diverging. However one fact is agreed on, the entries are natural language text.

5.3.2 Background

The market can be divided in several parts, but a simple way of seeing it is to have two groups, the users of I-talk and potential users of I-talk. The potential I-talk users are expressing a big need/demand for a logbook function. They have seen this functionality in other products and are primarily interested in only this function. However, if the logbook is not a part of I-talk, they will not invest in it although they find other I-talk services useful. The users of I-talk see the logbook as a useful functionality, but it is not as vital to them as it is to the potential users.

5.3.3 Objectives

The academic goal of the prototype was to try out some of the theoretic ideas mentioned in this report. The main area of focus was the requirements engineering, dealing with eliciting and prioritizing requirements. The functional goal, on the other hand, was to develop a working usability testable prototype, upon which future versions of the same functionality could be built.


5.3 Logbook prototype

5.3.4 Functionality

At the start of this thesis, it was decided that the prototype which was supposed to be developed, should implement a basic logbook function in the web based business platform I-talk. After having gathered requirements on the logbook functionality from different sources, more details regarding the prototype were established. In the logbook prototype, it must be possible to:

• View entries that are already stored. • Create and store new entries.

Without this basic functionality, the logbook prototype will not be usability testable, nor be of any value to TAC.

5.3.5 Development

Section 2.5 explains the difference between a throw-away prototype and an evolutionary prototype. Although the academic approach would prefer a throw-away implementation of a logbook, TAC sees more value in taking the first steps towards a fully functional logbook. Despite these diverging wishes, the logbook prototype should be seen as a first increment in the development of an I-talk logbook. The main problem with developing the logbook prototype is that an understanding of the flow in the system must be developed. Some documents describing the system must be read and I-talk developers must be consulted. However, there are some services in I-talk which have smaller parts that are very similar to parts of the logbook functionality. The first task is to find the services which have these similarities.

Database

I-talk uses a large Oracle database to store values and information. Since learning to handle Oracle is very time demanding, I-talk developers configured the database and arranged so that information could be stored and read from the database. Also, some test information was stored in the database so that the view entries part of the database could be developed. The database table created had five columns, meaning that it can store five different pieces of information for each entry. The columns were:

• Entry date • Entry text • Entry category • Entry author • Entry privacy



View entries

For the logbook to be of any use, users must be able to see what has been entered in it. The natural way to present the entries is to list them. The information which can be of any interest is the date of the entry, the entry itself, which category it belongs to and the person who made the entry. This makes a list with four columns. Developing this from nothing might not be very hard, but reusing and modifying existing code makes it more pleasant. The list meters function in I-talk is quite similar to what the view entries function should produce. A few changes and some additions to the existing code produced a fully functioning view entries function. Figure 5.1 below shows the similarities between the list meters webpage and the developed view entries webpage.

Figure 5.1 – The list meters webpage (left) compared to the view entries webpage (right).

With one part of the logbook functionality developed, the more demanding task of allowing entries to be created and stored was undertaken.

Create entry

The whole logbook idea is build on the assumption that someone makes short notes, entries, in it. It can for instance be a repairman or a TAC technician. Since education and computer skills of the people making the entries can vary quite a lot, the interface for creating an entry must be very simple and self explaining. But what should it look like? If all columns in the database are to be used, five different fields are needed. One field for each database column is needed. The date field does not have to be very complex. Nor does the author field containing the name of the person making the entry. Category should be selected from a predefined set of categories. A larger field with room for descriptive text should be the main field of the interface. A user can type in as much as he or she wants, but restrictions might be needed to keep the logbook free from larger reports.


5.4 Usability of the prototype

Developing this function was not quite as easy as the view entries function. As expected, this part of the prototype took a bit more time to get right. Figure 5.2 shows what the finished create entry webpage looks like.

Figure 5.2 - The create entry webpage.

Source code for the view entries webpage and the create entry webpage referenced above are found in Appendix E.

5.3.6 Feedback

People familiar with I-talk who have been presented to the logbook have welcomed it with open arms. They have build expectations for the final version and have started to see the full potential of its existence. As stated above, one main goal of the logbook was to be usability testable. A usability test was conducted and the results are found in Section 5.4. In addition to the usability test, other stakeholders have expressed their thoughts regarding the logbook. These thoughts are mostly concerned with how the logbook is supposed to be used and how it should be presented. The thoughts are also presented in Section 5.4.


The prototype developed during this thesis serve as the basis for the usability evaluation. As stated and described in the previous Section, prototype evaluation, the usable functionality of the prototype is fairly primitive. Still, some of the measurable factors of usability, stated in Section 2.3, can be estimated.

5.4.1 Planning

Although the planning of a usability test should be the most time consuming activity involved in usability testing, there was little planning prior to the usability test. A decision was made on what to include in the logbook prototype and a time plan for the prototype's completion was established.



5.4.2 Users

The number of users actually using I-talk and who could be involved in the usability test, was limited. The functionality of the prototype was already decided, but it included some usable functions which could be tested on users. However, users may have different views on I-talk and on the logbook. A representative from Marketing and sales was asked to comment on the functionality and look of the prototype, to cover other users’ needs.

5.4.3 End-user test

The implemented logbook was presented to an end-user at KFA, Kärnfastigheter, in Helsingborg. The user was presented to the initial logbook view and was asked to describe his thoughts regarding ease of learning, efficiency, memorability and general satisfaction.

Ease of learning

Due to the limited functionality, the user did not express any difficulty regarding the understanding of how to use the logbook. The low number of, according to the user, "self-explaining" buttons, should not be possible to misunderstand.

Efficiency of use

The user felt that the logbook effectively could support his idea of logbook functionality. However, the user suggested an alternative presentation method when viewing logbook contents. Instead of the paging, where ten entries are showed at a time, a significantly longer scrollable list was to prefer. This would ease in finding older entries. Although this reflection should be taken in consideration, this could be an effect of the lack of a search function, which will exist in a final logbook.

Memorability

As with the ease of learning, the limited number of functions in the prototype will not pose any problems in regards to the ability to remember how to use it. In the final logbook, there shall also be a search function, but the usability of this function cannot be evaluated until the graphical representation has been developed.

Satisfaction

The overall satisfaction of the user was good. The reaction to all the dialogs was positive, but there was one comment in the create logbook entry dialog. The possibility to make an entry private was disliked. The user did not appreciate the thought of the existence of entries which he could not see.

5.4.4 Usability thoughts

In parallel to the usability test conducted, other stakeholders have commented on the logbook prototype. Since these comments are of usability nature, meaning that they relate to appearance and understanding, they are described here as additional thoughts. Some of the thoughts are related to the view entries part of the logbook prototype (Figure 5.1). Many small user interface modifications can be made to decrease the amount of information directly presented to the user.



If an entry contains a large amount of text, it could be presented as a short clickable header instead. This will save the user from having to skim through non-relevant information if he or she is searching for another entry. To support the user’s ability to search, the possibility to sort the entries viewed by clicking on a column’s header should exist. This would enable the user to see the entries sorted according to the name of the person who made the entry.


Conclusions and Future Work This chapter describes the conclusions and future work resulting from this thesis.

6.1 Conclusions

The conclusion to be drawn from the work made during this master thesis is that TAC can benefit from proper requirements engineering. This report can be used to raise the knowledge of requirements engineering and what can be achieved with it. Parts of scientific publications regarding requirements engineering have been summarized and presented here. The techniques mentioned have been selected to fit I-talk and the nature of it as a product. This report also documents the analysis of TAC’s current processes. Problems, requirements management and thoughts concerning the processes can be used to improve the processes. Also, a requirements engineering process called PREP-IT has been proposed. PREP-IT deals with the issues found during the analysis of the processes used at TAC today. An evaluation of this process shows that it could be used at TAC to improve requirements engineering thinking. A small part of this thesis was to conduct a case study. This study was supposed to evaluate some of the proposed techniques and produce a prototype of a logbook function for I-talk. The prototype has been developed and I-talk stakeholders have since the start of this thesis shown an increasing interest in the logbook functionality. The final version of this logbook will be developed with the information gathered as a part of this thesis. Also, the participators of the technique evaluations reacted positive, realizing that using them would facilitate work. As mentioned in this report, the work with process improvement never ends. TAC must improve their requirements management, but they are on the right track; CASE tools are evaluated and processes are defined. Hopefully, this report can prove as valuable input to their work with requirements engineering.

6.2 Future work

The next step for TAC is to introduce the Product Planning Process in full scale, but as noticed and appointed in this thesis, requirements engineering must improve. It is logical to use the ideas proposed in this thesis, at least for work relating to I-talk. Also, the introduction of CaliberRM will improve requirements engineering work. It is vital to have support in form of a CASE tool when managing larger amounts of requirements. Using new or alternative techniques in the requirements work as with the prioritization method presented in Section 5.2 can give new insight in the development of products. This is an interesting area well suited for further studies.


Chapter 6: Conclusions


References

[Ares Casal et al, 1998] Ares Casal, J.M., Dieste Tubio, O., Garcia Vazquez, R., Lopez Fernandez, M., Rodriguez Yanez, S. (1998), “Formalising the Software Evaluation Process”, Computer Science (1998), IEEE Computer Society.

[Bleek et al, 2002] Bleek, W-G., Jeenicke, M., Klichewski, R. (2002), ”Developing Web-based Applications through e-Prototyping”, Proceedings of the 26th Annual International Computer Software and Applications Conference (COMPSAC’02)

[CaliberRM, 2003] Borland®, CaliberRM website, visited 2003-01-20, <http://www.borland.com/caliber/>

[Carlshamre & Regnell, 2000] Carlshamre, P. and Regnell, B. (2000), "Requirements Lifecycle Management and Release Planning in Market-Driven Requirements Engineering Processes", Accepted for publication at REP2000, IEEE

[Danino, 2001] Danino, N. (2001), ”Heuristic Evaluation – a Step By Step Guide”, Sitepoint website, visited 2003-03-05, <http://www.sitepoint.com/article/250>

[Delphi, 2002] Delphi – TAC internal web, visited 2002-12-11, Not publicly available, <http://delphi.tac-global.com>

[DOORS, 2003] Telelogic®, DOORS website, visited 2003-02-13, <http://www.telelogic.se/products/doorsers/doors/index.cfm>

[Fenkam et al, 2002] Fenkam, P., Gall, H., Jazayeri, M. (2002), ”Visual Requirements Validation: Case Study in a Corba-supported environment”, Proceedings of the IEEE Joint International Conference on Requirements Engineering (2002) :81-88

[Haväng, 2002] Haväng, C-P. (2002), “I-talk – Fast lane development”, Delphi – TAC internal web, Not publicly available.

[IT FlightPlan, 2003] IT FlightPlan website, visited 2003-01-20, <http://www.itflightplan.com/process/prod/Definition_of_Requirement.htm>


References

[Karlsson et al, 2002] Karlsson, L., Dahlstedt, Å.G., Natt och Dag, J., Regnell, B., Persson, A. (2002), ”Challenges in Market-Driven Requirements Engineering – an Industrial Interview Study”, Proceedings of REFSQ’02 (2002).

[Karlsson, 1996] Karlsson, J. (1996), “Software Requirements Prioritizing”, Proceedings of ICRE ’96 (IEEE)

[Karlsson, 1998] Karlsson, J. (1998), “Framgångsrik Kravhantering – vid utveckling av programvarusystem, Utgåva 2”, Nr 3, Sveriges Verkstadsindustrier.

[Karlström, 2002] Karlström, D. (2002), Increasing Involvement in Software Process Improvement, KFS Lund.

[Kotonya & Sommerville, 1996] Kotonya, G. and Sommerville, I. (1996), ”Requirements engineering with viewpoints”, Software Engineering Journal (1996) January.

[Kotonya & Sommerville, 1998] Kotonya, G. and Sommerville, I. (1998), Requirements Engineering – Processes and Techniques, John Wiley & Sons.

[Lauesen, 2000] Lauesen, S. (2000), Software Requirements – Styles and Techniques, 2nd Edition, Addison-Wesley.

[Maiden & Rugg, 1996] Maiden, N.A.M. and Rugg, G. (1996), “ACRE: selecting methods for requirements acquisition”, Software Engineering Journal (1996) May:183-192

[McMurtrey et al, 2000] McMurtrey, M-E., Teng, J., Grover, V., Kher, H. (2000), “Current utilization of CASE technology: lessons from the field”, Industrial Management & Data Systems 100/1:22-30

[Nielsen, 2003] Nielsen, J. (2003), “How to Conduct a Heuristic Evaluation”, useit.com website, visited 2003-03-05, <http://www.useit.com/papers/heuristic/heuristic_evaluation.html>

[Nilsson, 2002] Nilsson, H. (2002), “Product Planning Process”, Delphi – TAC internal web, Not publicly available.


References

[Overmyer, 2000] Overmyer, S. P. (2000), “What’s Different about Requirements Engineering for Web Sites?”, Requirements Engineering (2000) 5:62-65

[Regnell et al, 2001] Regnell, B., Höst, M., Natt och Dag, J., Beremark, P. and Hjelm, T. (2001), ”An Industrial Case Study on Distributed Prioritization in Market-Driven Requirements Engineering for Packaged Software”, Requirements Engineering (2001) 6:51-62

[RequisitePro, 2003] Rational©, RequisitePro website, visited 2003-02-13, <http://www.rational.com/products/reqpro/index.jsp>

[Ricks & Arnoldy, 2002] Ricks, K. and Arnoldy, B. (2002), “How to Conduct Your Own Usability Study”, STC Region 7 Conference November 2002

[Sommerville, 2001] Sommerville, I. (2001), Software Engineering, 6th Edition, Addison-Wesley.

[Tec-Ed, 2003] Tec-Ed, Inc. website, “Heuristic (Expert) Evaluation”, visited 2003-03-05, <http://www.teced.com/ue-he.html>

[Usability, 2003] Usability.gov website, visited 2003-02-18, <http://usability.gov/>


References


Abbreviation List Abbreviations used in the report are explained here.

CASE Computer Aided Software Engineering

CMM Capability Maturity Model

JSP Java Server Pages

KFA Kärnfastigheter

MR&D Management Research and Development

PM Project Manager

PPP Product Planning Process

PPT Product Planning Team

PREP-IT Parallel Requirements Engineering Process for I-Talk

R&D Research and Development

REPEAT Requirements Engineering ProcEss At Telelogic

ROI Return Of Investment

RPC Regional Product Council

RPU Remote Processing Unit

SDP Software Development Plan

TPM Technical Product Manager

UML Unified Modelling Language


Abbreviation List


Appendix A

Original logbook requirements

This Appendix contains the requirements collected concerning the logbook. The requirements are gathered from three different sources. These sources are briefly explained before each Section. This document was handed out on the pre-meeting of the prioritization.


Appendix A



Requirements for TAC I-talk Logbook *************************************************************************** KFA Here, we must separate the terms log and show. The wish to show only partial log information can be easily achieved if events are logged/entries are made and then some events/entries are not shown in the presentational interface. The logbook database can contain more information than is presented to users, hiding information not wanted by the user. Basic functionality: -Each building shall have a logbook of its own, meaning that entries are logged separately for each building. -The possibility to make an entry, which shall be logged for all buildings, e.g. a general entry, shall exist. (Ex: A tax raise shall be logged for all buildings.) -User access rights shall be checked before reading, changing or making entries. Logbook contents: -Changes in area usage shall be logged and shown. -Adjustments of media systems (ventilation, heat, electricity) shall be logged. -Only larger adjustments of media systems shall be shown. (Ex: The change of a single valve, which has no significant impact, shall not be shown) -Management changes (Swedish: Förvaltarbyten) shall be logged and shown. -The logbook shall be able to show log entries for a specific period of time. -Log entries that are of high importance shall always be shown, even if the time period does not include it. (Ex: Entries in say August can be a result of an important change in February, thus the entry from February shall be shown.) -Is must be possible to make a future entry, indicating an upcoming event/change. (Ex: If there are indications that something is wrong, an entry indicating that technicians will arrive next week to fix the problem will show that the problem has been addressed.) -Meter changes shall be logged and shown. -Log entries shall have the option of being media bound. (Ex: Entries dealing with heating, entries dealing with ventilation and so on.) User interface: -A logbook entry shall be self-explaining natural language. -It shall be possible to copy contents from the logbook. -It shall be possible to paste text as a new entry in the logbook. -The logbook shall have a search function. -It shall be possible to access the logbook from within other services. (Ex: When viewing diagrams showing usage of some media type for a specific period of time, it shall be possible to view the logbook covering the same time period.) Logbook search function: -It shall be possible to search for entries of a specific media type. -It shall be possible to search for any text found in an entry. (Ex: The search for "down" shall find an entry containing "The ventilation system broke down today".) -It shall be possible to search for a specific author. (Ex: If Steve has made an entry, the search for Steve, as author, shall show this entry.) Expansion: -The possibility to see imported entries form external systems is wanted. (Ex: Energy systems, Real estate systems (Janus, Repab, Energireda)) ***************************************************************************


Appendix A

Jan & Stina Today, service calls result in a note (a predefined form) with numbers, codes and other technical information. This type of reporting is not customer friendly. If the technician instead makes an entry in a logbook in self-explaining natural language, the customer will get better overview of his/her building and will thus be more satisfied. Basic functionality: -Entries shall be logged separately for each building. -There shall be predefined categories. -An entry must have a specified category assigned to it. -It shall be possible to input entries in the logbook when viewing a building. Quality: -Manual input shall be easy and self-explaining. -The logbook shall focus on usability. (Make it simple) I-talk specific: -It shall be possible to edit the logbook via the administrator menus in I-talk. -It shall be possible to show logbook contents in a small version of the service on the front page of I-talk. Logbook search function: -It shall be possible to search entries of a specific category. (Ex: Search for "down" in category "ventilation" will show all entries containing "down" in the "Ventilation" category. However, entries matching the "down" search, but have been assigned a different category, will not be shown.) -It shall be possible to search multiple categories at once. (Ex: Search for "down" in categories "Ventilation" AND "Electricity". Expansion: -It shall be possible to add entries via WAP and/or SMS. -It shall be possible to manually input entries through an external application. ***************************************************************************Anti & Niko At TAC Finland there is a product in use named E-Net, which is a “light version” of I-talk and focuses more on the management technician users. E-Net is built with a logbook as the main feature. The logbook is used for reporting information about a building. The logbook is building specific, meaning that two buildings have two separate logbooks. All logbook entries are made manually and contain self-explaining natural language. Every entry has the option of being public or private. A public entry is shown to the customer and a private is not. TAC experts are the ones making entries in the logbook. However, there is a possibility for the customers to make their own entries, but this feature has not been used, although it is a requested functionality. When the development of E-Net 2 starts, only one feature has been added to the logbook. It will be possible to select a category for the entries made in the logbook. Although, to prevent from making it to complex, the maximum number of categories has been set to five (5). The E-Net developers follow one rule of thumb and that rule is "Keep it simple". Basic functionality: -There shall be a maximum of 5 categories for logbook entries. -There shall be no category usage restrictions when making new manual entries. (Ex: When a user adds an entry, he/she can freely select a category.) -The logbook shall be building specific, meaning that there shall be one logbook for each building.



-It shall be possible to make entries private, meaning that they will not be shown to certain users. (Ex: If a TAC expert makes an entry which will not interest the customer (maybe it is intended for other TAC experts), he/she should be able to "hide" that entry so that only experts can view it.) -The logbook shall always show the latest entries when first opened. Usage: -All entries in the logbook shall be made manually. (This will improve customer relations since they receive a more personal attendance.) Expansion: -It shall be possible to select a validity date for an entry, meaning that an entry will be shown only a specified period of time and will be automatically removed when that time has passed. -There shall be one global logbook in coexistence with the building logbooks. -The global logbook shall contain entries applying to all buildings. (Ex: Tax changes.) -There shall be a settings page where every user can customize the logbook to fit their needs. (Ex: Default show, hide all entries concerning ventilation, etc.) I-talk improvement: -User and user access rights management must be made simple. -It shall be possible to see which users have what rights. *************************************************************************** Common Access rights must be dealt with. Must control who gets to add/edit/view entries made in the logbook. Alternatives: -All users can add/edit/view entries. -Administrators can add/edit/view entries and other users can add/view entries. -All users can edit their own entries. Why have a logbook? -The logbook shall be used as a lightweight reporting tool. -The logbook shall show the history of a building. Questions: -Can logbook contents be printed? -Can logbook contents be exported? *************************************************************************** Use cases -Are there other users to consider? -What should it be possible to edit? -Should it be possible to “delete” entries? -What should the Administrator menu give access to? (For TAC Experts) -Should some users be able to do more? (Ex: Should expert users be able to make common entries?)


Appendix A


Appendix B

Preliminary requirements specification

This Appendix contains the preliminary requirements specification used at the prioritization meeting.


Appendix B



Requirements for TAC I-talk Logbook Basic functionality:

LB01 Each building shall have a logbook of its own, meaning that entries are logged separately for each building.

Source Common LB02 The possibility to make an entry, which shall be logged for all

buildings, e.g. a general entry, shall exist. (Ex: A tax raise shall be logged for all buildings.)

Source KFA LB03 User access rights shall be checked before reading, changing or

making entries. Source TAC Finland LB04 When making a manual entry, a name of the person making the

entry shall be entered. Source TAC Finland LB05 When making a manual entry, a date specifying when the entry

was made shall be entered. Source TAC Finland LB06 There shall be a maximum of 5 categories for logbook entries. Source TAC Finland LB07 There shall be no category usage restrictions when making new

manual entries. (Ex: When a user adds an entry, he/she can freely select a category.)

Source TAC Finland LB08 It shall be possible to make entries private, meaning that they will

not be shown to certain users. (Ex: If a TAC expert makes an entry which will not interest the customer (maybe it is intended for other TAC experts), he/she should be able to "hide" that entry so that only experts can view it.)

Source TAC Finland LB09 The logbook shall always show the latest entries when first opened. Source TAC Finland LB10 An entry must have a specified category assigned to it. Source TAC Finland LB11 It shall be possible to input entries in the logbook when viewing a

building. Source Marketing LB12 Is must be possible to make a future entry, indicating an upcoming

event/change. (Ex: If there are indications that something is wrong, an entry indicating that technicians will arrive next week to fix the problem will show that the problem has been addressed.)

Source KFA

Must / Uncertain / Reject













Appendix B

LB13 The logbook shall be able to show log entries for a specific period

of time. Source KFA LB14 Log entries that are of high importance shall always be shown,

even if the time period does not include it. (Ex: Entries in say August can be a result of an important change in February, thus the entry from February shall be shown.)

Source KFA LB15 It shall be possible to edit the logbook via the administrator menus

in I-talk. Source Marketing LB16 It shall be possible to show logbook contents in a small version of

the service on the front page of I-talk. Source Marketing LB17 Normal users can add/edit/view all public entries. Source - LB18 Expert users can add/edit/view all entries. Source -

Logbook contents:

LB19 Changes in area usage shall be logged and shown. Source KFA LB20 Adjustments of media systems (ventilation, heat, electricity) shall

be logged. Source KFA LB21 Only larger adjustments of media systems shall be shown. (Ex: The

change of a single valve, which has no significant impact, shall not be shown)

Source KFA LB22 Management changes (Swedish: Förvaltarbyten) shall be logged

and shown. Source KFA LB23 Physical meter changes shall be logged and shown. Source KFA

User interface:

LB24 A logbook entry shall be self-explaining natural language. Source TAC Finland LB25 It shall be possible to copy contents from the logbook. Source KFA
















LB26 It shall be possible to paste text as a new entry in the logbook. Source KFA LB27 It shall be possible to access the logbook from within other

services. (Ex: When viewing diagrams showing usage of some media type for a specific period of time, it shall be possible to view the logbook covering the same time period.)

Source KFA

Logbook search function:

LB28 The logbook shall have a search function. Source Marketing LB29 It shall be possible to search for any text found in an entry. (Ex:

The search for "down" shall find an entry containing "The ventilation system broke down today".)

Source Marketing LB30 It shall be possible to search for a specific author. (Ex: If Steve has

made an entry, the search for Steve, as author, shall show this entry.)

Source Marketing LB31 It shall be possible to search entries of a specific category. (Ex:

Search for "down" in category "ventilation" will show all entries containing "down" in the "Ventilation" category. However, entries matching the "down" search, but which have been assigned different categories, will not be shown.)

Source TAC Finland LB32 It shall be possible to search multiple categories at once. (Ex:

Search for "down" in categories "Ventilation" AND "Electricity".) Source Marketing

Expansion:

LB33 The possibility to see imported entries form external systems is wanted. (Ex: Energy systems, Real estate systems (Janus, Repab, Energireda))

Source KFA LB34 It shall be possible to add entries via WAP and/or SMS. Source Marketing LB35 It shall be possible to manually input entries through an external

application. Source Marketing LB36 It shall be possible to select a validity date for an entry, meaning

that an entry will be shown only a specified period of time and will be automatically removed when that time has passed.

Source TAC Finland













Appendix B

LB37 There shall be a settings page where every user can customize the

logbook to fit their needs. (Ex: Default show, hide all entries concerning ventilation, etc.)

Source TAC Finland

Quality: LB38 Manual input shall be easy and self-explaining. Source Marketing LB39 The logbook shall focus on usability. (Make it simple) Source Marketing LB40 All entries in the logbook shall be made manually. (This will

improve customer relations since they receive a more personal attendance.)

Source TAC Finland Instructions: Read through the requirements list and check one of the three possible classifications for each requirement. The must classification means that the requirement is absolute essential and will be implemented no matter what priority it will receive. The reject classification means that the requirement will not be implemented because it is impossible/stupid/not in line with the product. If there is an uncertainty regarding a requirements classification, it should be classified as uncertain. The goal is to keep the must requirements at a minimum. There is a risk that a “good” requirement is rejected, but this should not keep you from classifying requirements as rejected. All requirements that have been classified as uncertain by one or more of the meeting participants will be selected for the prioritisation practice. Card Sort The prioritisation will be conducted according to the card sort method. Every participant will receive a pile of cards. Each card describes one requirement. The general idea is to sort these cards according to their relative importance. The sorting method to use is insertion sort: For every new card X, compare it with the first card in the sorted pile of cards and move backwards. Let Y denote the card in the pile with which you should compare X. For every comparison you should ask yourself “Is X > Y?”. If X is not, compare with the next card in the pile until X > Y and insert the card X before that Y. What does ‘>’ mean? Since the meeting have participants with different job descriptions, the meaning of ‘>’ will be somewhat different. We will try to use two meanings. Marketing people will have X > Y meaning that X has more customer value than Y. Developers will have X > Y meaning that X is more expensive to develop than Y. Finally, all participants will together sort a new pile of cards according to their rank from the previous sort. The developers’ cards will be ranked from the back starting with 1 and the marketing peoples’ cards will be ranked from the top starting with 1. The total sum of a requirements rank in the previous sort will serve as the comparison value in this final sort. This will, in ideal cases, end in a card pile with the requirement, which is cheapest to develop and which has the highest market value, at the top.






Appendix C

Prioritization result Table

This Appendix contains a Table of the prioritization result.


Appendix C


Prioritization result Table

Develo

per

1D

evelo

per

2M

ark

et

pers

on

1M

ark

et

pers

on

2Req#Rank

Rc

Req#Rank

Rc

Req#Rank

Rv

Req#Rank

Rv

Req#

Rc

Rv

Score

Req#

Score

27

18

27

21

220

52

11

14

239

19

-20

73

67

23

27

19

67

322

73

22

78

44

36

91

88

17

88

18

98

11

14

813

12

817

26

923

14

920

59

17

99

124

917

89

14

32

18

10

13

10

18

710

20

610

421

10

20

510

13

26

13

18

12

11

817

11

25

611

12

13

11

718

11

23

31

819

12

12

11

14

12

21

612

13

12

12

18

712

20

19

-125

12

13

10

15

13

13

12

13

14

11

13

223

13

27

34

727

11

14

619

14

14

12

14

16

914

16

914

31

18

-13

89

16

916

16

16

916

17

816

421

16

25

29

426

917

16

917

421

17

23

217

619

17

30

21

-911

818

15

10

18

521

18

223

18

520

18

31

43

12

13

719

22

319

12

17

19

817

19

10

15

19

20

32

12

16

420

12

13

20

817

20

718

20

24

120

30

19

-11

12

-121

13

12

21

917

21

24

121

23

221

29

3-2

628

-522

14

11

22

10

17

22

916

22

25

022

28

16

-12

17

-923

21

423

11

17

23

619

23

916

23

21

35

14

37

-10

25

25

025

23

625

18

725

14

11

25

618

12

20

-11

26

24

126

22

626

19

626

15

10

26

716

922

-12

27

19

627

24

627

15

10

27

12

13

27

12

23

11

14

-13

28

421

28

15

12

28

21

428

124

28

33

28

-52

-20

33

322

33

224

33

25

033

21

433

46

4-4

234

-25

34

124

34

124

34

520

34

22

334

48

23

-25

21

-26

36

223

36

621

36

22

336

19

636

44

9-3

536

-35

37

520

37

322

37

10

15

37

817

37

42

32

-10

33

-42

Req

# =

A r

equir

emen

ts n

um

ber

(LB

02 h

ar R

eq#

2)

Ran

k =

The

rank

for

a sp

ecific

req

uir

emen

tRv

= A

req

uir

emen

ts m

arke

t va

lue

(hig

h m

arke

t va

lue

is g

ood)

Rc

= A

req

uir

emen

ts d

evel

opm

ent

cost

(lo

w c

ost

is g

ood)

Sco

re =

A r

equir

emen

ts s

core

in r

espec

t to

bot

h m

arke

t va

lue

and d

evel

opm

ent

cost

(hig

h s

core

is

goo

d)

So

rted

resu

ltS

um

mari

zati

on


Appendix C


Appendix D

Prioritization result document

This Appendix contains a formatted document of the prioritization result. All requirements are sorted according to the calculated prioritization score.


Appendix D



Requirements prioritization result Must Requirements: LB01 Each building shall have a logbook of its own, meaning that entries are logged

separately for each building. Source Common LB03 User access rights shall be checked before reading, changing or making entries. Source TAC Finland LB04 When making a manual entry, a name of the person making the entry shall be

entered. Source TAC Finland LB05 When making a manual entry, a date specifying when the entry was made shall be

entered. Source TAC Finland LB15 It shall be possible to edit the logbook via the administrator menus in I-talk. Source Marketing LB38 Manual input shall be easy and self-explaining. Source Marketing LB39 The logbook shall focus on usability. (Make it simple) Source Marketing Prioritized Requirements: LB07 There shall be no category usage restrictions when making new manual entries.

(Ex: When a user adds an entry, he/she can freely select a category.) Source TAC Finland LB09 The logbook shall always show the latest entries when first opened. Source TAC Finland LB23 Physical meter changes shall be logged and shown. Source KFA LB10 An entry must have a specified category assigned to it. Source TAC Finland LB18 Expert users can add/edit/view all entries. Source - LB19 Changes in area usage shall be logged and shown. Source KFA LB25 It shall be possible to copy contents from the logbook. Source KFA LB11 It shall be possible to input entries in the logbook when viewing a building. Source Marketing


Appendix D

LB27 It shall be possible to access the logbook from within other services. (Ex: When viewing diagrams showing usage of some media type for a specific period of time, it shall be possible to view the logbook covering the same time period.)

Source KFA LB13 The logbook shall be able to show log entries for a specific period of time. Source KFA LB08 It shall be possible to make entries private, meaning that they will not be shown to

certain users. (Ex: If a TAC expert makes an entry which will not interest the customer (maybe it is intended for other TAC experts), he/she should be able to "hide" that entry so that only experts can view it.)

Source TAC Finland LB26 It shall be possible to paste text as a new entry in the logbook. Source KFA LB16 It shall be possible to show logbook contents in a small version of the service on

the front page of I-talk. Source Marketing LB20 Adjustments of media systems (ventilation, heat, electricity) shall be logged. Source KFA LB12 Is must be possible to make a future entry, indicating an upcoming event/change.

(Ex: If there are indications that something is wrong, an entry indicating that technicians will arrive next week to fix the problem will show that the problem has been addressed.)

Source KFA LB22 Management changes (Swedish: Förvaltarbyten) shall be logged and shown. Source KFA LB28 The logbook shall have a search function. Source Marketing LB29 It shall be possible to search for any text found in an entry. (Ex: The search for

"down" shall find an entry containing "The ventilation system broke down today".) Source Marketing LB30 It shall be possible to search for a specific author. (Ex: If Steve has made an

entry, the search for Steve, as author, shall show this entry.) Source Marketing LB31 It shall be possible to search entries of a specific category. (Ex: Search for "down"

in category "ventilation" will show all entries containing "down" in the "Ventilation" category. However, entries matching the "down" search, but which have been assigned different categories, will not be shown.)

Source TAC Finland LB32 It shall be possible to search multiple categories at once. (Ex: Search for "down" in

categories "Ventilation" AND "Electricity".) Source Marketing LB37 There shall be a settings page where every user can customize the logbook to fit

their needs. (Ex: Default show, hide all entries concerning ventilation, etc.) Source TAC Finland



LB17 Normal users can add/edit/view all public entries. Source - LB14 Log entries that are of high importance shall always be shown, even if the time

period does not include it. (Ex: Entries in say August can be a result of an important change in February, thus the entry from February shall be shown.)

Source KFA LB21 Only larger adjustments of media systems shall be shown. (Ex: The change of a

single valve, which has no significant impact, shall not be shown) Source KFA LB02 The possibility to make an entry, which shall be logged for all buildings, e.g. a

general entry, shall exist. (Ex: A tax raise shall be logged for all buildings.) Source KFA LB34 It shall be possible to add entries via WAP and/or SMS. Source Marketing LB36 It shall be possible to select a validity date for an entry, meaning that an entry will

be shown only a specified period of time and will be automatically removed when that time has passed.

Source TAC Finland LB33 The possibility to see imported entries form external systems is wanted. (Ex:

Energy systems, Real estate systems (Janus, Repab, Energireda)) Source KFA Rejected Requirements:

LB06 There shall be a maximum of 5 categories for logbook entries. Source TAC Finland LB24 A logbook entry shall be self-explaining natural language. Source TAC Finland LB35 It shall be possible to manually input entries through an external application. Source Marketing LB40 All entries in the logbook shall be made manually. (This will improve customer

relations since they receive a more personal attendance.) Source TAC Finland

Prototype decision What should be in the first increment of the prototype? What is the goal of the prototype? What is the measurement of success for the prototype? (speed, reliability, functionality)


Appendix D


Appendix E

Prototype source

This Appendix contains some of the prototype java server pages developed.


Appendix E

Prototype source

logbookmenu.jsp

 <%@ page import= "se.tac.italk.servlet.*" %> <% String listCommand = ItalkURLs.ITALK_SERVLET + "?command=" + ItalkCommands.NAVIGATE_TO_LIST_LOGBOOK; String searchCommand = ItalkURLs.ITALK_SERVLET + "?command=" + ItalkCommands.NAVIGATE_TO_QUERY_LOGBOOK; String createCommand = ItalkURLs.ITALK_SERVLET + "?command=" + ItalkCommands.NAVIGATE_TO_CREATE_LOGBOOK_ENTRY; buttons = new String[][]{ {dictionary.getText(0, user.getLanguageId(), "List"), listCommand}, {dictionary.getText(0, user.getLanguageId(), "Search"), "", "disabled"}, {dictionary.getText(0, user.getLanguageId(), "Create"), createCommand} }; %> 

listlogbook.jsp

 <%@ page import= "se.tac.italk.business.*" %> <%@ page import= "se.sigma.ei.util.*" %> <%@ page import= "se.tac.italk.authorization.UserSession" %> <%@ page import= "se.tac.italk.servlet.*" %> <jsp:useBean id="protoBean" class="se.tac.italk.business.PrototypeTmp" scope="request" /> <%@ include file="header.jsp"%> <html> <%@ include file="scripts.jsp"%> <head> <title> <%strPageTitle = dictionary.getText(0,user.getLanguageId(),"Create logbook entry");%> <%=strPageTitle%> </title> </head> <body> <%@ include file="logbookmenu.jsp"%> <%@ include file="administration_header.jsp"%> <form method="get" action="<%=ItalkURLs.ITALK_SERVLET%>"> <table border="0" cellspacing="0"> <tr> <th> <%= dictionary.getText(0, user.getLanguageId(), "Date") %>: <%= MANDATORY_INDICATOR %> </th> <td> <input size="11" type="text" name="entrydate" value="<%= Util.nullValue(DateOperator.dateToString(protoBean.getEntryDate(),user.getDateFormat())," ") %>" />


Appendix E

<%= "("+user.getDateFormat()+")" %> </td> </tr> <tr> <th> <%= dictionary.getText(0, user.getLanguageId(), "Author") %>: <%= MANDATORY_INDICATOR %> </th> <td> <input size="25" type="text" name="username" value="<%= Util.nullValue(protoBean.getUserName(),"") %>" /> </td> <td align="right"> <th align="right"> <%= dictionary.getText(0, user.getLanguageId(), "Category") %>: <%= MANDATORY_INDICATOR %> </th> <td align="right"> <% if(5<10){ %> <select name="entrycategory" style="width: 150px"> <% } else { %> <select name="entrycategory" size="5" style="width: 150px"> <% } %> <% for(int i=0; i < 5; i++){ if (protoBean.getEntryCategory().equals(i+"")) {%> <option value="<%=i%>" selected="true"> <%="Category "+i%> </option> <% } else {%> <option value="<%=i%>"> <%="Category "+i%> </option> <% } %> <% } %> </select> </td> </td> </tr> <tr> <th valign="top"> <%= dictionary.getText(0, user.getLanguageId(), "Description") %>: </th> <td colspan="4"> <textarea cols="65" rows="10" name="entrytext"><%= Util.nullValue(protoBean.getEntryText(),"") %></textarea> </td> </tr> <tr> <th> <%= dictionary.getText(0, user.getLanguageId(), "Private") %>: </th> <td> <% if (protoBean.getEntryType().intValue() == 1) { %> <input type="checkbox" name="entrytype" value="1" checked="true" />

Prototype source

<% } else { %> <input type="checkbox" name="entrytype" value="1" /> <% } %> </td> </tr> <tr> <td colspan="5" align="right"> <% String[][] newbuttons = { {dictionary.getText(0, user.getLanguageId(), "Save"), "javascript:document.forms[0].submit()"} }; buttons = newbuttons;%> <%@ include file="dynamicbuttons.jsp"%> <input type="hidden" name="command" value="<%= ItalkCommands.CREATE_LOGBOOK_ENTRY_IN_STORAGE %>"/> </td> </tr> </table> </form> <%@ include file="status.jsp"%> </body> </html> 

createlogbookentry.jsp

 <%@ page import= "se.tac.italk.business.*" %> <%@ page import= "se.sigma.ei.util.*" %> <%@ page import= "se.tac.italk.authorization.UserSession" %> <%@ page import= "se.tac.italk.servlet.*" %> <jsp:useBean id="protoBean" class="se.tac.italk.business.PrototypeTmp" scope="request" /> <%@ include file="header.jsp"%> <html> <%@ include file="scripts.jsp"%> <head> <title> <%strPageTitle = dictionary.getText(0,user.getLanguageId(),"Create logbook entry");%> <%=strPageTitle%> </title> </head> <body> <%@ include file="logbookmenu.jsp"%> <%@ include file="administration_header.jsp"%> <form method="get" action="<%=ItalkURLs.ITALK_SERVLET%>"> <table border="0" cellspacing="0"> <tr> <th> <%= dictionary.getText(0, user.getLanguageId(), "Date") %>: <%= MANDATORY_INDICATOR %> </th> <td> <input size="11" type="text" name="entrydate"


Appendix E

value="<%= Util.nullValue(DateOperator.dateToString(protoBean.getEntryDate(),user.getDateFormat())," ") %>" /> <%= "("+user.getDateFormat()+")" %> </td> </tr> <tr> <th> <%= dictionary.getText(0, user.getLanguageId(), "Author") %>: <%= MANDATORY_INDICATOR %> </th> <td> <input size="25" type="text" name="username" value="<%= Util.nullValue(protoBean.getUserName(),"") %>" /> </td> <td align="right"> <th align="right"> <%= dictionary.getText(0, user.getLanguageId(), "Category") %>: <%= MANDATORY_INDICATOR %> </th> <td align="right"> <% if(5<10){ %> <select name="entrycategory" style="width: 150px"> <% } else { %> <select name="entrycategory" size="5" style="width: 150px"> <% } %> <% for(int i=0; i < 5; i++){ if (protoBean.getEntryCategory().equals(i+"")) {%> <option value="<%=i%>" selected="true"> <%="Category "+i%> </option> <% } else {%> <option value="<%=i%>"> <%="Category "+i%> </option> <% } %> <% } %> </select> </td> </td> </tr> <tr> <th valign="top"> <%= dictionary.getText(0, user.getLanguageId(), "Description") %>: </th> <td colspan="4"> <textarea cols="65" rows="10" name="entrytext"><%= Util.nullValue(protoBean.getEntryText(),"") %></textarea> </td> </tr> <tr> <th> <%= dictionary.getText(0, user.getLanguageId(), "Private") %>: </th> <td>

Prototype source

<% if (protoBean.getEntryType().intValue() == 1) { %> <input type="checkbox" name="entrytype" value="1" checked="true" /> <% } else { %> <input type="checkbox" name="entrytype" value="1" /> <% } %> </td> </tr> <tr> <td colspan="5" align="right"> <% String[][] newbuttons = { {dictionary.getText(0, user.getLanguageId(), "Save"), "javascript:document.forms[0].submit()"} }; buttons = newbuttons;%> <%@ include file="dynamicbuttons.jsp"%> <input type="hidden" name="command" value="<%= ItalkCommands.CREATE_LOGBOOK_ENTRY_IN_STORAGE %>"/> </td> </tr> </table> </form> <%@ include file="status.jsp"%> </body> </html>

requirements engineering for building it - an industrial...

Documents