School of Engineering,
Blekinge Institute of Technology Box 520
Master Thesis in Software Engineering Thesis no: MSE-2004-08 June 2004
Requirements Engineering Skills Development
- A Survey
Madock Chiwenda
This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in partial fulfilment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies.
Author:
Madock Chiwenda
Address: P. O. Box 78033, Dar es Salaam, Tanzania, East Africa E-mail: madochiwenda@yahoo.com
University Advisor:
Dr. Mikael Svahnberg
Department of Computer Science and Software Engnineering Contact Information:
School of Engineering,
Blekinge Institute of Technology
: www.tek.bth.se : +46 457 38 50 00 Internet
Phone
Abstract
Software projects are among the failure prone projects in engineering and software requirements problems have been attributed to be one of main reasons to software project failures. There are many techniques and methodology developed for practitioners to use in working with software requirements, which makes it impossible for one to master them during formal education. In addition, many of the practitioners are coming from different disciplines. Thus they are required to learn in practice. Previous studies have shown informal learning (i.e. not planned or run by institutions or organizations) to be more effective and more used in workplace learning situations. The study investigates how the requirements engineering skills are and can be learned in workplace especially informally. By comparing the results obtained by the literature study and empirical study the recommendations are given on how one can recognise, utilise, and encourage the informal learning activities to develop requirements engineering skills.
The study does not rule out the need to have the formal education and training in requirements engineering but identify it as an important prerequisite and/or complement. It provides insight on how informal learning practices are utilised by practitioners who are rather experienced in requirements engineering and how they could try to recognise and/or utilise other learning opportunities presented by previous literature. It furthermore offers general recommendations of how to utilise the informal learning for developing requirements engineering skills and other related disciplines.
Keywords: software requirements, requirements engineering, skill developments, informal learning
Acknowledgements
Firstly and foremost, I would like to extend my gratitude to my thesis advisor, for his keen advise, support and encouragements. Secondly, to my respondents of the survey (interviewees) for dedicating their important time to prepare and participate in the survey wholeheartedly. Lastly but not least, to all fellow students of MSc.
Software Engineering and the rest of university staff, program whose advise, comments and support have made this thesis work bearable and successful.
To family and friends for their prayers and support
Table of Contents
CHAPTER 1: Introduction. . . .1
1.1. Background and Motivation . . . 1
1.2. The Research . . . 2
1.3. Report Structure . . . 3
1.4. Reading Guidelines . . . 3
1.5. Summary . . . 4
CHAPTER 2: Requirements Engineering. . . .5
2.1. Requirements. . . 5
2.2. Requirement Engineering . . . 6
2.3. Requirement Engineering Process . . . 6
2.4. System Stakeholders . . . 8
2.5. Requirements Engineer and Actors in Requirements Engineering Process . . . 9
2.6. Requirements Engineering Skills . . . 9
2.7. Summary . . . 12
CHAPTER 3: Requirements Engineering in Different Disciplines . . . .13
3.1. Introduction . . . 13
3.2. Software Engineering . . . 13
3.3. Systems Engineering . . . 14
3.4. Project Management . . . 14
3.5. Product Development . . . 15
3.6. Software Acquisition. . . 16
3.7. Summary . . . 17
CHAPTER 4: Skill Development . . . .18
4.1. What is a Skill? . . . 18
4.2. Learning . . . 19
4.3. Informal Learning Methods . . . 20
4.4. Skill Categories and their Learning Methods . . . 23
4.5. Summary . . . 24
CHAPTER 5: Requirements Engineering Skill Development . . . .25
5.1. Introduction . . . 25
5.2. Learning Methods for Requirements Engineering Skills . . . 25
5.3. Learning Methods for Requirements Engineering Actors . . . 27
5.4. Summary . . . 29
CHAPTER 6: Study Method . . . .30
6.1. Choice of Method . . . 30
6.2. Participants . . . 30
6.3. Survey Instruments . . . 31
6.4. Procedure. . . 31
6.5. Reliability and Validity . . . 31
6.6. Summary . . . 32
CHAPTER 7: Study Results and Analysis . . . .33
7.1. Introduction . . . 33
7.2. Additional Skills . . . 33
7.3. Interview Results Summary . . . 33
7.4. The Results Analysis. . . 34
7.5. Summary . . . 37
CHAPTER 8: Discussions and Conclusions . . . .38
8.1. Answering the Research Questions. . . 38
8.2. Comparing the Results of the Study with the Hypotheses . . . 38
8.3. Implications and Recommendations of the Study Results . . . 39
8.4. Lessons Learned . . . 41
8.5. Questions Raised . . . 41
8.6. Suggested Study Improvements . . . 41
8.7. Suggested Future Work. . . 42
8.8. General Conclusion . . . 42
8.9. Summary . . . 42
APPENDIX A: The Questionnaire . . . 43
APPENDIX B: Interview Transcripts . . . 45
B.1. Transcript of Interview 1 (Company A) . . . 45
B.2. Transcript of Interview 2 (Company B) . . . 46
B.3. Transcript of Interview 3 (Company C) . . . 49
B.4. Transcript of Interview 4 (Company C) . . . 50
B.5. Transcript of Interview 5 (Company C) . . . 51
References . . . .53
List of Tables
Table 5.1. Learning Methods for Requirements Engineering Skills ...27
Table 5.2. Learning Methods for Requirements Engineering Actors...29
Table 7.1. Learning Methods Transcript Summary ...34
Table 7.2. Suitability of Learning Methods to Skills for All Respondents ...35
Table 7.3. Suitability of Learning Methods to Skills for Project Manager ...36
1
Introduction Chapter 2
This chapter introduces the reader this master thesis to give an overview into the whole report and important issues to consider before reading the thesis in detail.
1.1. Background and Motivation
Software is becoming increasingly indispensable component most of systems, human beings interact with in their daily lives. From government and business systems and personal systems and gadgets like mobile phones and even life-supporting devices like heart pacemakers.
However, of all engineering disciplines, software industry seems to be more failure prone compared to other mature engineering disciplines like construction. It was found in the research that The Standish Group’s Chaos report (1995) estimated that the US software projects:
Only 16.2% completes on time and on budget
31.1% were cancelled before reaching their end
More than half are completed with almost 200% of initially planned budget
This is contributed by the immaturity of the field itself and the fast pace at which it is evolving.
With less than half a century since its initial emergence, it is one of the youngest. Thus, the methodologies and techniques within the professions are still evolving fast. In addition to that, the fast changing nature of business today also results into changing needs on software projects adding confusion to already chaotic situation on what is to be achieved.
Many studies in software engineering have concentrated on developing methodologies and techniques, which people can use to avoid common pitfalls encountered in software projects.
Some have investigated how students can learn effectively to become good practitioners (Cowling, 2003; Cowling, 2002; Johansson, 1995 and Johansson, 1993).
Nevertheless, there is few empirical investigations on how people can acquire the skills in the workplace which were multidisciplinary. Several of these were performed by Cheetham and Chivers (1998, 2000, 2001) and Center for Workforce Development (1998).
Some mature field like medicine, management and education, other fields of engineering have already performed and continue to perform research on how acquire the essential skills within their professions. These effort contribute into formulating better training and orientation programs for the new comers into the respective field. The similar studies within software engineering have not been conducted.
Many people performing requirements engineering tasks lack formal training support (Wiegers, 2000). Being in a constantly changing field, software practitioners are also compelled to continue learning and adopting methodologies and techniques not taught in school. With little evidence of coverage of how the skills are acquired at workplace, it invites for more effort being directed into that area.
The Research
By understanding how the skills are best learned in workplace then it is possible for others to utilize the results of the study to:
Improve the methodology to suit the learning process so that it could be best be learned and thus be effectively utilized.
Organize better the learning environment so that trainer and trainee interact in a manner that can optimize the leaning process.
Structure learning programs to include the activities, which will give learners the best opportunity to learn.
Since workplace learning is a bit wide, with formal on-the-job training and informal learning, for the purpose of this study it is not feasible to the informal learning cover both aspects in detail.
This study has been directed towards informal learning in the workplace as outlined in more details in later chapter.
Research have shown that requirement related deficiencies to be among most prevalent factors behind the software failure. The Standish Group’s Chaos report (op. cit.) identified “Incomplete Requirements” being the main cause that the projects were cancelled and “clear requirements”
being the most important technical success factor (related to software engineering practices).
In this respect it makes sense to study how professional acquire and can acquire the skills related to the most important success factor on software development projects: requirements.
Requirements engineering (discussed in details in next chapter) has emerged as a discipline within software engineering to handle the requirements from the customer and other stakeholders to the development team during the software development. It takes a generalizing approach towards the software requirements phase instead of concentrating into individual methodologies and techniques like object orientation, evolutionary development, soft systems, structured system analysis, participatory design, user centred design and formal methods (Macaulay, 1996).
1.2. The Research
1.2.1. Research Goals and Objectives
The study aimed to investigate how practitioners from different disciplines who work with software requirements acquire the requirement engineering skills at workplace. Thus, its goals are directed into finding ways or methods through which the requirements engineers use to acquire the skills they need to use in their work.
In order to achieve the targeted aims the following objectives were set to be done:
Survey of the literature of requirement engineering concepts and associated skills
Survey of the literature on organizational roles, which require the requirement engineering skills in their activities
Survey the literature to collect general skill learning methods
Investigate the methods to be used by organizations to develop the essential requirements engineering skills
Investigate the suitability of methods to a particular organizational role which is involved in requirements engineering process
Report Structure 1.2.2. Research Questions
Research have tried to answer the following questions:
What methods are suitable for a specific skill or set of skills?
What methods are suitable to which organizational role?
1.2.3. Expected Outcomes
The study recommends suitable learning methods suitable for:
Requirement engineering skills development
Different organizational roles using requirement engineering skills 1.3. Report Structure
The research documented in this report is structured in the following layout:
1.3.1. Literature Survey
Chapter 2, “Requirements Engineering”: The thesis starts with a literature survey of the generic requirements engineering concepts and practices. These include requirements, requirements engineering, requirements engineering process and the skills required to perform requirements engineering activities.
Chapter 3, “Requirements Engineering in Different Disciplines”: This discusses selected scenarios of requirements practices and investigates the requirements engineering skills required by the key actors in those scenarios.
Chapter 4, “Skill Development”: This covers basic concepts of skills and learning. It investigates different forms of learning, and categorises the skills and their respective suitable learning methods.
Chapter 5, “Requirements Engineering Skill Development”: This discusses the importance of requirements studying requirements engineering skills and derives the sets suitable learning methods for the requirements engineering skills and actors.
1.3.2. The Empirical Study
Chapter 6, “Study Method”: This chapter gives details on how the empirical study was conducted and some decisions made which determine the direction of the research. The tools used in the survey are also presented and discussed.
Chapter 7, “Study Results and Analysis”: In this chapter, the results obtained from the study are documented and analysed.
1.3.3. Discussions
Chapter 8, “Discussions and Conclusions”: In this chapter the results of the empirical study are compared to the hypothesis and discussed and reflected. Recommendations are also drawn.
Moreover, in this chapter the conclusions of the whole study are presented and possible future research work, arising from the study are discussed.
1.4. Reading Guidelines 1.4.1. Audience
Effort has been spent to make the report understandable to widest audience possible. However, the intended audience of this report consists of people who have worked with software development projects especially tasks associated with software requirements in the development.
Summary
1.4.2. Instructions
In order to make it easier for both the reader and the author, the following word shall be read as follows:
He, should be read as he/she
His, should be read as his/hers 1.5. Summary
This chapter has attempted to introduce the reader of this thesis to the background and issues of focus in this report. These includes background, motivation of the study. These include lack of studies on how skills are acquired at workplace and requirements engineering being an important factor of success and failure of the software related project. Next chapter will be introducing generic requirements engineering as part of the literature survey.
2
Requirements Engineering Chapter 3
In Chapter 1 the overview of the whole study was introduced. In this chapter the literature study starts to introduce basic concepts in requirement engineering. These include requirements, requirements engineering and requirement engineering process. Emphasis has been placed on presenting the generic view of the concepts without tying into specific techniques and methodologies. At the end of this chapter the essential skills in requirements engineering are discussed.
2.1. Requirements
2.1.1. What are Requirements?
There are several definitions found in the literature which are rather similar. A short and generalised definition of requirements can be found from Sawyer and Kotonya (2001: 10) as a property that must be exhibited by the system order to solve some real world problem. This will be regarded as a selected definition for the use of this study.
It is ideally preferred to express the requirement in terms of “what” the system should do rather than “how” the system should do; Thus, requirements are intended to express the statement of the problem and not the solution. In practice it is hard to achieve since the system is usually installed in place of existing systems or reuse the existing components e.g. database, which may constrain the way the system, is developed, thus these implementation details might be considered as requirements (Kotonya and Sommerville, 1998: 11).
Furthermore, according to Wiegers (1999: 17) of good requirements are required to hahve the following characteristics: complete; correct; feasible; necessary; prioritised; unambiguous and verifiable.
2.1.2. Levels of Requirements
When software is developed for an organization the requirements may be expressed in different forms for different uses. Thus, they can be conceptually be divided into three distinct levels or stages depending on their uses as classified by Wiegers (1999: 7):
Business requirements: these stipulate the objectives of the organization or customer that requires the product. Business requirements for a project are captured in document containing project vision and scope.
User requirements: these stipulate the tasks user will be able to perform with the product. They are usually described using scenarios and use cases.
Functional requirements: These define software functionality to be built in the software to enable users carry out their tasks, as means of satisfying business requirements. They describe external behaviour of the software. Functional requirements together with non-functional requirements and other constraints are documented in software requirement specification.
However, these represent conceptual division, in practice the levels may all be placed in a single document or may appear in documents having different titles.). Kotonya and Sommerville (1998: 19) also Sommerville and Sawyer (1997: 49) recommend a requirements document
Requirement Engineering
structure in which contain business case (which is also known as business requirements), user requirements and functional requirements.
2.2. Requirement Engineering
Kotonya and Sommerville (1998: 8) define requirement engineering to include activities used to discover, document and maintain a set of requirements for computer-based system. From engineering perspective, it implies the use of systematic and repeatable techniques to ensure completeness, consistency and relevance of the requirements. Engineering is the use of systematic, disciplined, quantifiable approach to structures, machines, systems or processes (IEEE, 1990: 30).
Requirements engineering seems to be rather a new terminology (compared to other software engineering areas) which collects different views of the software requirements, from business, user, system/software development. It also takes a generic approach towards requirements phase as expressed differently in different methodologies like: structured system analysis; object- oriented analysis; formal methods, soft systems and participatory design (Macaulay, 1996).
2.2.1. Importance of Requirement Engineering
Requirement engineering is the first activity in software development (Pressman, 2001: 28).
Being in the early stages of software development is critical to the rest of the steps, which come afterwards. Problems introduced in the requirement phase propagate into later steps increasing the cost of correcting the mistakes when they are discovered later in the system life cycle.
Correcting requirement mistakes involves correcting design, implementation and testing artefacts as well. Fixing requirement error is estimated to cost 100 times more than fixing a simple programming error (Kotonya and Sommerville, 1998: 9). Furthermore, Wiegers (1999: 15) estimates correcting a requirement error in operational software to cost 60 to 200 more compared to fixing the errors in requirement phase.
The effects of incorrect requirements according to Kotonya and Sommerville (1998: 9) may result into:
System delivered later than expected and costing more than it was expected
User dissatisfaction and possibly system under-utilization or rejection due to system not meeting the actual user needs
Disruptive and erratic operation due to use of the system in unforeseen conditions
High system maintenance and evolution costs as many changes will be demanded to make the delivered system meet the user needs.
Thus, effort spent on requirements engineering activities at the beginning of the project to get the right requirements is justifiable by the savings of the modifications costs avoided later in the development of the product.
2.3. Requirement Engineering Process
Kotonya and Sommerville define this as set of activities, structured to derive, validate and maintain a requirement document. (1998: 9). Although it is impossible to prescribe an ideal requirement engineering process, it is possible to describe an abstract process, which represent a generic structured set of requirement engineering activities. Kotonya and Sommerville (op. cit.) present the process as made of the following generic activities: elicitation; analysis and negotiation; documentation; validation and management.
Requirement Engineering Process 2.3.1. Requirements Elicitation
This involves discovery or acquisition of system requirements by consultations with stakeholders, from documents, domain knowledge and market studies. Elicitation techniques as described by Sawyer and Kotonya (2001: 19) includes:
Interviews: involves the questioning of stakeholders by the analyst to build understanding of the requirements. Interviews may have predefined questions (open-ended) or without predefined questions (closed-ended) or a mixture of the two. Kotonya and Sommerville (1998: 63) explain interviews to be useful for general requirements, which stakeholders can easily communicate in conversation. However, interview is not very useful in capturing domain knowledge as user usually expresses ideas in specialised terms or the user becomes so much used to concepts that he is unaware of need to explain to another person in detail. Furthermore, user may be unwilling to convey organizational knowledge to an outsider (interviewer) as it is related to political and social factors.
Scenarios: describes a single type of interaction of end-user with the system thus useful in discovering facilities that maybe required during the interaction. These are useful in adding details to outline requirements. It may be presented in textual description or using diagrams.
Prototypes: this is implementation of limited features of the program. This may be done on paper, people simulating the system response or a running program using fourth generation languages. The techniques are used in clarifying unclear requirements.
Facilitated meetings: this helps stakeholders to collectively think of a problem, which would be difficult to understand individually. This activity results into more consistent requirements from different stakeholders. However, the elicitation process might be jeopardised by group loyalty or subordinates loyalty to the seniors when they are in the same team.
Observation: studying people in their normal work routine to understand the support they may require from the computer based system. This is useful to study aspects, which have become so natural to the performer that it can hardly be explained. However, the technique requires time to perform and may require a formally trained observer. In addition to that, it may influence the user to act in manners different to the typical working pattern. Alternatively the requirement engineer may become an apprentice to the end user for a short period (Macaulay, 1996: 116).
2.3.2. Requirements Analysis and Negotiation:
This is detailed scrutinizing of the requirements to determine their completeness, conflicts, and compatibility. Eventually different stakeholders reach agreements through negotiations. Activities in this areas include:
Checklist: to analyse if requirements have the desired characteristics highlighted earlier in this chapter (section 2.1.1).
Interaction matrix: to investigate overlaps and conflicts between requirements.
Requirement prioritisation: to arrange requirements in order of importance thus decide on core requirements for the system.
Risk analysis: suggest potential problems which might be encountered during system implementation, their probabilities to arise and investigate possible ways to mitigate the risks.
Requirement negotiation: different stakeholders discuss their differing priorities and reach consensus on which requirements are to be implemented.
System Stakeholders
2.3.3. Requirement Documentation:
This involves recording the agreed requirements usually in a format understandable by all system stakeholders such as natural language and diagrams (models). Documentation format and content vary depending on the nature of product, audience, usage and budget (Kotonya and Sommerville, 1998: 15). However, Kotonya and Sommerville (ibid.) and IEEE (1998a) have proposed a general structure and guidelines for the requirements document.
Wiegers (1999: 18) suggests that the requirement document as a whole is desired to be complete, consistent, modifiable and traceable, in addition to characteristics of good requirements mentioned in section 2.1.1.
2.3.4. Requirement Validation
This involves checking for consistency and completeness of requirements, before they are used as a basis of system development the requirements (Kotonya and Sommerville 1998: 33).
Techniques to validate requirements include:
Requirements review: this is a formal meeting to identify problems in the requirements
Prototyping: uses prototypes developed in elicitation and analysis phase to demonstrate the requirements in to enable stakeholders easily identify problems in requirements, which are poorly understood.
Requirements testing: A good requirement should be testable, i.e. be able to check that it has been properly implemented using a finite number of test cases. Proposing preliminary requirements test cases is useful in revealing requirements ambiguity and inconsistencies.
Draft user manual: drafting user manual is a translation of requirements into the language that end-user can understand. Thus, it is useful in revealing usability problems with requirements (Sommerville and Sawyer, 1997: 206).
2.3.5. Requirement Management
The previously described activities are iterative and results into changes in the requirements as errors and omissions are discovered, customer develops better understanding of the real needs and even business priorities changing during the project execution. Thus, the activities have to be supported by “requirement management” process, which runs in parallel with the above activities.
Requirement management is process of managing changes to system requirements. This involves change control, which includes assessment of changes to be accepted, and their impact to the other requirements and other development activities. The accepted changes are documented.
Wiegers categorizes the requirements engineering activities into two broad categories:
Requirements development, which includes elicitation, analysis, specification (documenta- tion) and verification (validation)
Requirements management 2.4. System Stakeholders
These are organizations and people affected by the systems or that have influence on system requirements. These include managers, end-users, engineers who will develop and maintain the system, customers of services and product from the system and regulating authorities which regulations the system or its product must comply with. It is important to identify these parties and identify their requirements and ensure that the system provided will be acceptable.
Requirements Engineer and Actors in Requirements Engineering Process 2.5. Requirements Engineer and Actors in Requirements Engineering Process
Requirements engineering can be considered as a bridge between end users, customer, developers, and quality assurance team, as it involves all system stakeholders coming into agreement on capabilities and conditions of what the system to be developed. The process might be handled by different people in different situation or might be divided into steps each steps being handled by people with different job titles. These may include but not limited to, software engineer, systems engineer, project manager, developer, IT manager, business analyst, systems analyst, computer analyst and external consultants (Wiegers, 2003).
For the sake of generality the discussion will utilise “requirements engineer” to represents the role played in the requirement engineering process rather than job title. This role represents a person who plays the central active role in requirement elicitation, analysis, negotiation, documentation, validation and management.
However, this role might be shared among different people in different scenarios as discussed further in Chapter 3. Thus, when the responsibilities of the requirements engineering process are performed by several people within the organisation, then these can be considered as “actors” in the requirements engineering process (Kotonya and Sommerville, 1998). The “actor” is also equivalent to the term “organizational role” mentioned in the second research question mentioned in section 1.2.2. These three terms are thus be used interchangeably in the rest of this report to refer to people who participate in the requirements engineering activities.
2.6. Requirements Engineering Skills
There are several skill sets for requirement engineer, presented in the literature with slightly different organizations (Macaulay, 1996: 8, Wiegers, 2003). After comparing and analysing the skill set given in different the following skills have been compiled for the use of this study:
interviewing; observation; group work; facilitation; negotiation; analytical; modelling and presentation.
2.6.1. Interviewing
Requirements engineer need to communicate with different stakeholders individually in order to understand their interaction with existing system as well as their priorities and needs for the future system. This includes questioning and listening skills. Requirement engineer should be able to ask the right question the individual(s) to obtain information related to user role, problems and functions. One should also have ability to listen to their responses and try to understand what they are saying and what they are hesitant to say (Wiegers, 2003). Thus, interviewing includes questioning and listening skills. This is a common requirement elicitation method used to understand general requirements (Kotonya and Sommerville, 1998: 63).
2.6.2. Observation
This involves watching users at work to understand of work environments and difficulties related to daily activities. For some people who have worked with a certain activities many times that the whole process has become natural to them. It can hardly be expressed in words or described. Observation is thus the best way of understanding these hard-to-express activities in order to be in position to propose possible facilities which the computer based system could help.
2.6.3. Group Work
Since the requirements involve agreement of all stakeholders, it is effective to work in a team to define common requirements. Requirements Engineer will need ability to work with others
Requirements Engineering Skills
stakeholders as a member of the team. Working in group requires members to have effective communication of ideas and constructive conflict resolution (Johnson, 1989).
2.6.4. Facilitation
In order for group members to be able to focus better in content of the output from the group activity there is need of having a person who will oversee the progress of the whole process, i.e.
the person who will concentrate on the process and not the content. This involves being active, initially, in deciding roles and tasks of group members, communication channel and group norms, overseeing the general progress and eventually winding up the output of the whole process. In general facilitation involves leading the group with less active role to enable members to achieve their common goal.
2.6.5. Negotiation
Requirements come from different sources and stakeholders. Thus, it is inevitable that the stakeholders will have conflicting view and priorities on the system to be developed. In order for the requirements engineer to be able to specify the requirements in a consistent way negotiation skills will be required to derive a set of requirement, which all stakeholders can live with. This may involve discussing the conflicting views and associated priorities, each parties giving up some requirements in order to agree on a common set of requirements to be implemented. Thus, negotiation involves discussing conflicts in requirements and finding compromise which all stakeholders can accept.
2.6.6. Analytical
Requirement engineer is expected to evaluate critically requirements of system, its components and components interrelationship (i.e. being able to work at different levels of abstractions). He is expected to locate problems when they exists in the requirement statements like errors, omissions and other deficiencies opposite to the characteristics of good requirements highlighted previously. He is also expected to guide stakeholder in prioritising requirements.
2.6.7. Modelling
In addition to textual descriptions requirements are usually well understood when supplemented with suitable diagrams. Types of diagrams are usually closely linked to a specific methodology like object oriented analysis, formal methods, and structured analysis and design.
Diagrams models different aspects of the systems like business, process, data, and objects.
Requirements engineer is expected to be able to use these different modelling techniques to suit customer problem and organization standards.
2.6.8. Presentation
Requirements have to be written down in a manner understandable by all stakeholders so that they may agree on capabilities of the system to be built. This might involve presenting the requirements in different format to different people. For instance, customer will be interested in business requirements in overview while developers will be interested to see the detailed specification and be able to trace to the underlying user and business requirements whenever necessary (traceability). So the requirement engineer needs to have writing skills to present requirements in understandable manner and tailor their presentation to different type of audience.
2.6.9. Skills Left Out
The following skills, found in the literature, have been left out, in the selected list of skills for requirements:
Requirements Engineering Skills Creativity: Wiegers (2003) and Robertson (2002), propose that requirements engineers should be able to propose new requirements, which users have not expressed or imagined before.
Problem solving: Macaulay (1996: 8) suggests this skill in order to support the search fro the alternative solution.
However, the discussions have centred into proposing a solution rather than finding user requirements. This in conflict with idea that requirements should state what is needed and not how it should be done. Requirements engineer can be suggested requirements by the due to his previous requirements experience with other systems. However, this is best conceived as requirements reuse (Kotonya and Sommerville, 1998: 72) or the process of requirement discovery for the omissions in requirements expressed by user, instead of creativity. Requirements engineering may be facilitating the creative stakeholders customer, end users and developers to define the new system. This will avert the danger the requirement engineer loosing focus in finding the customer need and becoming occupied in being creative.
Although it is generally agreed in the literature that requirements it is not feasible to avoid talking about solution specific details during the requirements phase. This is only done with the existing constraints like regulatory standards and existing system components (op. cit.) and not new requirements. Talking about new solution should be left for architecture and design as much as possible and requirements phase should concentrate on finding needs and expectations of customers whether expressed or implied. It is agreed that the development phases are not easily separable during project execution; However, conceptually separating type of activity into phases enables better separation of responsibilities and planning.
2.6.10. Other Related Aspects
Although the focus of the study is to investigate the essential skills for requirement engineering, other aspects which have not been investigated in detail but would be beneficial to mention here are:
2.6.10.1. Related Knowledge and Experiences
Macaulay (1996: 9) summarises results from a study in which the requirement engineer is described to require knowledge and experience in the following: case tools; modelling techniques and languages; requirements management tools; human-computer interaction concepts, tools and techniques; project management and product planning and marketing
2.6.10.2. Related Technical Knowledge
Requirements engineer needs to understand the related technical activities in order to be able to develop realistic and feasible requirements. These include architecture and design, coding, testing and quality assurance activities.
2.6.10.3. Application Domain Knowledge
The system to be developed usually is based on theoretical knowledge of some specific discipline or business specialization. These disciplines and specialisations are called application domains. In order for requirements to be written these must be understood. Thus, the requirements engineer accumulates knowledge called “domain knowledge”, which can be reused for during the course of the development of the system and its evolution. This can also be reused while developing other systems within the same “problem domain”. The more domain knowledge the engineer acquires, the more possibility of discovering forgotten requirements, which would have been discovered later in the development phase, saving modification costs (Wiegers, 2003).
Summary
2.7. Summary
In this chapter, the basic concepts of requirements engineering are explored. In the next chapter, the discussion goes into details of how the requirements engineering tasks are performed in as described in different disciplines.
3
Requirements Engineering in
Different Disciplines Chapter 4
After studying the requirements engineering concepts in Chapter 2, in this chapter discussion focus on how requirements engineering activities and skills are described and used by different disciplines.
3.1. Introduction
Although the focus of the report is requirements engineering from software engineering perspective, requirements engineering activities are usually mixed up with a lot of other organizational processes that it becomes imperative to investigate their relationship in order to understand requirements engineering reality while practiced within an organization. In this way the discussion lays the foundation for answering the second reseact question as mentioned in section 1.2.2. The study have selected to investigate typical software development project on the following scenarios:
Mass-market product: in which the project is defined mainly by the marketing personnel and then the project is set up to undertake the development tasks. In this type of project people who participate includes marketing personnel (product development), project manager, system and/or software engineer.
Outsourced project: in which the information technology personnel defines the product required and then the software development project is set up for an external contractor to carry it out or the ready made product to be used is acquired to satisfy the requirements.
In this regard, the discussions in this chapters will centre on this chapter the interactions of Requirement Engineering with other parent and associated fields is investigated. The discussions has been centred on the following disciplines/practices software engineering, systems engineering, project management, software acquisition product development.
This chapter discussion is based on these disciplines. However, it does not imply that other professions or disciplines, not discussed here, are related less to requirement engineering. It they were selected as representative to be covered within the available time of master thesis. In addition to that, the report has adopted a general approach towards those disciplines avoiding going into all possible scenarios within each disciplines.
3.2. Software Engineering
3.2.1. Requirement Engineering within Software Engineering
Software engineering is the use of systematic, disciplined, quantifiable approach to software development, operation and maintenance (IEEE, 1990: 67). Thus, it is concerned with transforming a problem into a working solution and maintenance of the software until the product is retired.
Most basic model for software development process is represented by waterfall model as requirements, design, implementation, test, and operations. Although in reality it is not easy to be strictly divided, most of modern process models like EVO, Cleanroom and even Agile, have been derived from this conceptual model by reorganizing these basic steps. In this respect we will discuss the basing on the model as unification approach towards all the divergent models.
Systems Engineering
This is a software-centric approach to development of software system where software is considered as the most important component of the transformation of the business process.
However, this approach is not suitable when software is a small component of the system to be developed like in telecommunication or industry automation where hardware may cost many times more than software.
Much of the previous chapter was covering the requirements engineering activities and processes from software engineering perspective. In this respect, there is no need to discussing more them again in this section.
3.2.2. Requirement Engineering Skills in Software Engineering
Being at the core of the Requirement Engineering process software engineer is required to have all of the skills in requirements engineering as discussed in section 2.6. In short they can be summarised as interviewing, observation, group work, facilitation, negotiation, analytical, modelling and presentation.
3.3. Systems Engineering
3.3.1. Requirement Engineering within Systems Engineering
Software does not function in isolation within the organization but are integrated with hardware, people, database(s), documentation and procedures. All these are essential components of a computer-based system. When software is considered as component, the approach is termed as “system-centric” and is suitable when the software when software construction takes relative small or less significant part of the whole project.
Systems engineering focuses on analysing, designing and organizing those components, which may be in form of product, service or technology for the purpose of information transformation or control. (Pressman, 2001: 245). In system engineering, requirement engineering can be practiced by in 2 phases/levels:
To determine requirements of the whole system (system requirements engineering): these are expressed in fairly high-level using a natural language
To determine requirements of subsystems (software requirements engineering): software requirements are decomposed from high-level into more details
There is no clear separation of requirement engineering activities and processes in the literature between system engineering and software engineering, except that systems engineering takes a more multidisciplinary approach to systems development (Macaulay 1996).
3.3.2. Requirement Engineering Skills in Systems Engineering
There are no clear differences of skills between software engineering and systems engineering.
Thus, the skill set is basically the same as discussed in the section 3.2.2.
3.4. Project Management
3.4.1. Requirements Engineering with Project Management
Project management is defined as the use of knowledge, skills, tools and techniques to project activities to meet project requirements (PMI, 1996: 6). In the project, user requirements are documented as product description. This contains characteristics of the product, which the project is undertaken to create. It also incorporates the relationship to the business need, customer request, market demand, legal requirements, or technological advancement, which give rise to the
Product Development project (PMI, 1996: 49). These have been recognised as business requirements by Wiegers as discussed in the previous chapter.
Although the project manager is not expected to be an expert of all activities done in the project but rather a facilitator of the technical experts in the team to achieve the project requirements (which include product requirements). He will thus be an active participant in requirement engineering activities like requirements definition, negotiation and change management, since they are among main determinants of project success as they directly affect the project scope.
However, the project management literature does not say explicitly that the project manager will need to perform the requirement development and management activities. Nicholas briefly suggests that project manager should have ability to translate business requirements into project and system requirements (Nicholas, 2001: 487). This does not imply that he will have to perform the translation himself. Thus, it may be safely assumed he should make sure that target has been achieved in the project through facilitation
Thus, it can be concluded that the project manager the project management literature does not place project manager as primary developer/maintained of requirements. He is expected to facilitate these activities in the same way he facilitates the rest of project activities (Nicholas, 2001: 478), with exception of negotiations. However, this does not prevent project manager to assuming requirements engineer role which is not part of project manager responsibility.
3.4.2. Requirements Engineering Skills in Project Management
Supervising the refinement and achievement of the requirements of the product delivered project manager requires
Group work: to participate as a team member in developing and managing defining requirements Facilitation: to coordinate efforts to refine the requirements and management of change of requirements within the project
Negotiation: to balance the differing priorities of stakeholders from the projects
Presentation: writing requirements in project documents like contracts in a format understood by all stakeholders
3.5. Product Development
3.5.1. Requirements Engineering with Product Development
Product Development is branch of marketing discipline concerned with strategies in making the product ready for to be offered to the target customer base. Thus, it is concerned with business aspects of market-driven products as the product evolves from idea to launch
In market-driven products the initial requirements are “invented” in form of ideas coming from marketing personnel, looking for feasibility of a possible marketable solution or developers asking whether there is market for technology they are capable of implementing. Ideas are screened and then market research is performed based on interviews and questionnaires.
Alternatively facilitated focus groups are for more lengthy user involvements (Macaulay, 1996:
117).
Quality function deployment (QFD) (Macaulay, 1996: 98,) is also used in software product development in order to translate customer requirements into requirements (technical) specifications this enables analysis of customer priorities, competition, and sales projections of the product for mass market. The requirements are validated by use of prototypes and beta
Software Acquisition
releases. When products have been released to the market actual users exist. Thus, additional requirements (ideas) can be elicited from the users in form of feedback.
The user requirements are documented using “use cases scenarios” which describe the typical usage of the product by the end user. These are high level descriptions of the interactions thus do not include implementation details (Johnson, 2002). Alternatively “personas” are used to express user requirements in terms of characteristics of different classes of typical product users and how they interact with the product. The user class is presented by a selected name (ibid.). The user requirements placed in “market requirement document”, MRD (Johnson, 2001). The principles for writing the market requirements document like necessity, feasibility, and completeness are similar to those presented in requirement engineering literature described in earlier in this report.
3.5.2. Requirements Engineering Skills in Product Development Interviewing: to conduct market research and surveys
Observation: to observe general market trends, focus groups activities and competitors’ products Group work: to collaborate with top management, to define business requirements, customers representatives and project staff to define user requirements, and developers experts in defining specifications
Facilitation: to conduct focus group meetings
Analysis: to analyse the requirements collected before being documented to remove undesirable characteristics like ambiguities and to relate to factors like customer priorities, competition, and sales
Presentation: to document the market requirements in understandable format 3.6. Software Acquisition
3.6.1. Requirements Engineering with Software Acquisition
Software acquisition is the process of obtaining the software product. Software acquisition is favoured in order to take advantage of skills not available internally. The following software acquisition discussion assumes an Information Technology (IT) department, which is supporting other functional departments within an organization, without performing software development activities within the organization. IEEE recommends in software acquisition process to contain a planning phase in which one of the steps includes determination of the software requirements, which are used Request for Proposal, Invitation to Tender, and in contract (IEEE, 1998: 11).
Software Engineering Institute, SEI, in its Software Acquisition Capability Maturity Model, SA-CMM (SEI, 2002) has “Requirements Development and Management” as one of the key process areas. This has been placed at the first step (level 2) of the process improvement model.
Thus, it is among the first steps to be taken when one wants to improve the software acquisition process within the organization.
There are several types of requirements, which are of importance to software acquisition process as a whole but the “technical requirements” which include functional, performance, security and quality requirements are relevant to requirement engineering practice. These are recommended to be developed and managed using activities like elicitation, analysis and validation, which are found in requirement engineering literature.
SW-CMM (SEI, 2002) recommends that satisfactory requirements criteria to be used to grade requirements are similar to characteristics of good requirements proposed by those Wiegers (1999: 16) discussed in the previous chapter. IEEE recommends the for software acquisition to in the same format as documentation of other software developments projects (IEEE, 1998: 11).
Summary Nelson et al (1996) recommends the “need analysis” (i.e. requirements engineering activities) to be performed by information system team within the organization as they better understands the organization. Thus, it will be cheaply performed in-house.
In this respect, people involved in software acquisition are expected to be involved in requirement engineering activities. IT managers and officers, responsible to write technical requirements to be included, will need to use the requirement engineering techniques in order describe the product to be acquired in a proper way.
3.6.2. Requirements Engineering Skills for IT personnel
The skills of IT personnel essential to requirements engineering activities are
Interviewing: questioning and listening to the end user and management about their work to understand their work and application domain. However, most of “interviews” will be performed in informally while looking for solutions of the problems encountered by end users and management in day-to-day activities.
Observation: to collect requirements through daily working experience during end-user support to understand the working condition. Observing co-workers is more suitable for understanding reality in working conditions and noticing observing weaknesses of the current information systems compared to external observer who might influence the observed subject.
Group work: to participate in collaborative sessions with end users, and management to develop requirements of the new systems
Negotiation: to mediate between organizational priorities and external contractors/suppliers priorities.
Analysis: to translate business needs into technical requirements for different systems, existing and those to be acquired. to be able to identify problems in requirements statements like ambiguity and feasibility
Presentation: to write and exhibit system requirements in a format understandable to management and end users
3.7. Summary
In this chapter some selected disciplines, which utilises requirements engineering skills have been analysed. The skill sets have been drawn from the associated discussions respectively. The disciplines discussed include software engineering, systems engineering, project management, product development (marketing) and IT (software acquisition). Next chapter (Chapter 4) discussion is focused on concepts skills and learning as a way to lay foundation on how requirements skills could be developed.
4
Skill Development Chapter 5
In this chapter basic concepts associated to skills and learning are explored. These includes skills, learning, formal and informal learning, and informal learning methods. At the end the skills are categorised and analysed on the best learning methods for each category
4.1. What is a Skill?
American Heritage Dictionary defines it as proficiency or dexterity that is gained or developed through training or experience. Princeton’s WordNet (1996) defines it as an ability to deliver a solution in some problem domain.
According to Barnett (1994), skill is associated with a situation of some complexity, a deliberate performance to address the situation, not just a matter of luck and eventually evaluation of performance to see if needs to be addressed have been met.
Lovell (1980 cited by O’Donnell and Garavan, 1997: 132) considers all skills to have some characteristics in common: they are learned; involves organizing and coordinating activities associated to specific object or event and involve ordering or coordination of processes or activities into a short-lived sequence.
Thus, we can conclude that skill is associated with:
Specific task to be accomplished or problem to be solved
Knowledge to be used
Consistency of the process and result (i.e. procedural activity)
Furthermore, according to O’Donnell and Garavan (1997: 131), skills are either innate or acquired. Acquired skills are learned.
4.1.1. Skill vs. Knowledge
From survey of the literature, knowledge is much wider and harder to generalise than skill. It includes experience, values, contextual information, expert insight, which provides a basis of incorporating new experiences and information (Davenport and Prusak, 1998: 7). In general skill seems to be a subset of knowledge that is closely related to a specific task.
According to Cheetham and Chivers (2001: 264-265), there are several conflicting ways in which scholars have attempted to classify the professional knowledge. However, Cheetham and Chivers (ibid.) divides professional knowledge into these two broad categories:
Propositional Knowledge: knowledge that can be articulated and codified, for instance in theories, concepts, generalised practical principles, procedures and rules;
Practical Knowledge: knowledge of how to do things, i.e. linked to skills.
The first type of knowledge is generally studied in its generalised sense as Knowledge management. This may not be necessarily practical, as it has been defined above and may be hard to measure. However, the second category of knowledge is related to the activities and thus it is possible to assess in terms of the output of the activities performed as discussed in section 4.1.
The second type of knowledge is the focus of this study, since this study is related to a single identified discipline with an identified collection of techniques, which have activities, which output can be assessed.
