Framework for Describing the Concept of Requirements Awareness in Software Development

Andrew Swerdlow

University of Victoria

Dept. Computer Science

Victoria, BC, Canada

swerdlow@uvic.ca

ABSTRACT

This paper discusses the topic of requirements workspace awareness in software development.  We explore the important factors of requirements awareness and how they affect the development of software.  The primary goal of this paper is to propose a framework for describing the concept of awareness as it pertains to requirements.

General Terms

requirements awareness, requirements management, software process improvement.

Keywords

Management, Documentation, Performance, Design, Human Factors, Standardization.

1.         INTRODUCTION

This paper discusses the topic of requirements workspace for awareness in software development.  We explore the important factors of requirements awareness and how they affect the development of software.  The primary goal of this paper is to propose a framework for describing the concept of awareness as it pertains to requirements.

There has been little attention given to understanding the concept of awareness in software development and even less in providing research about awareness of requirements.   We believe that requirements are the foundation of any software project, and there is great benefit to engaging in proper requirements management activities.   Unfortunately, in practice, requirements management can sometimes be neglected.  It is our intent to show that requirements are indeed central to all software development, and managing those requirements as they evolve is an important and useful exercise.  We will show how requirements are important by describing the relationships between changing requirements and the development environment.  The effects of changing requirements can impact projects on many levels. It is important that relevant stakeholders are aware of the changes.  It is ourintent to describe how awareness of requirements can play an important part of the software development life cycle.

This paper will be laid out in the following manner.  The remainder of this section will identify our research question.  Section 2 will provide a survey of the relevant literature. Section 3 will describe our proposed framework.  Section 4 will focus on discussing the framework.  Section 5 will be a discussion on future work.  We offer our conclusions in section 6.

1.1         Research Questions 

The goal of this paper is to identify and define ways of describing the concept of awareness of requirements in software development environments.  We base our efforts by asking several research questions.

        Q1. What stakeholders are affected by changes to requirements?

        We pose this question because we are interested in examining the roles of individuals involved with software projects and how changes in requirements impact them.  Insight into who is affected by what information is an important component in understanding the flow of requirements information within an environment.

        Q2.  What sources of information are related to changing requirements? And what information do stakeholders need to be aware of? 

        This question is concerned with understanding how objects in the environment change when requirements change.  When a decision to change requirements has happened, the change information needs to be communicated to relevant roles. After that, requirements need to be solidified within the environment by manipulating information objects.  It is our goal to understand how information objects are manipulated, by which roles, and their effect on the environment. 

        Q3. How do relevant stakeholders become aware of the changes to requirements? 

        This research question is important to help us understand the flow of information within the software development environment.  Discussing this question will allow us to characterize the format and properties of change information. We would also like to understand the workflow of requirements information distribution.

2.         Literature Review

We have performed an exhaustive literature review of the topic of awareness in software development.  We have identified the relevant research and will review it in this section.

Over the last decade there have been several attempts to create tool support for awareness in software development. Examples of the tools are described in the following literature [7, 3, 12, 8].  However, there has yet to be any specific tool proliferation in the industry for providing awareness support.  This is likely because the tools are cumbersome to use or do not accurately provide awareness information. A summary of some of the tools can be found in [12].  We speculate that the reason that no tool has met with great success is that their designers do not have a complete understanding of the concept of awareness, although some researchers such as Schmidt have provided high level overviews in [10, 11], providing an enumeration of the open problems with awareness.  For the most part there is still a great deal of confusion and controversy about what awareness means in software development environments [10]. This could lead to an incomplete implementation of tools for supporting awareness. It is likely that they do not have a clear understanding because there is no accepted standard for defining awareness in software development. However, there has been some research trying to describe the important elements of presenting awareness information such as [6, 1, 9, 2].  Ju et al describe in their paper [6] a tool called WorkSpaceNavigator. It is used to provide awareness within a physical work environment.  One of the challenges they describe is delivering the appropriate detail of information to the user of the tool.  They also discuss how to only provide relevant information to users.    Sarma et al in [9] describe a method of pushing the flow of information out to developers.  Cadiz et al give a good summary [2] of how awareness information can be presented in an asynchronous fashion. There have also been useful studies that try to understand how current projects get their awareness information using general purpose tools such as [5]. 

It is our intent to bring together many of these ideas in to one framework for describing awareness.  We also believe that many of the methods for describing awareness suffer from cognitive bloat.  That is, they try to do too much, which inevitably becomes counter productive.  Schmidt mentions in [10] that “awareness is only meaningful if it refers to a person’s awareness of something”. So for our framework we only focus on describing the concept of awareness as it pertains to software requirements.  This domain restriction will allow us to explore the concept in-depth with out having to confuse the situation by examining a vast set of variables.  We also chose awareness of requirements because we assume that all aspects of software development can be related back to requirements.   Requirements are the starting point for software projects.  Our framework will describe workspace awareness at the earliest possible point, the inception of the project.  Many other systems for describing or supporting awareness in software development environments focus on the implementation phase of the project. Those systems usually pull information from artifacts such code repositories [12, 9].  The problem with that approach is that they are missing out on important information found at the early stages in the software development life cycle, where awareness information is arguably most important.

In Faulk’s paper [4], he mentions that many of the errors related to requirements are caused by issues such as lack of understanding between stakeholders, inadequate communication and ineffective management of changing requirements.  All of those issues could be attributed to lack of awareness within the workspace of requirements.  It is our hope that other researchers will employ the techniques we used in creating our framework to replicate systems for understanding awareness in other domains.

3.         Framework

In this section we will define a structure for organizing and developing our concept of requirements awareness.  Our framework will have three major dimensions: Roles, Information and Presentation.  We will explain these dimensions by breaking them down into sub-dimensions.  We will also give examples of how specific elements of our framework relate to describing requirements awareness in software development environments.  Describing each of these dimensions will allow us to offer answers to our research questions.   

3.1         Roles

In this section we will try to provide some answers to Q1 by defining a dimension to our framework that describes stakeholder roles.  We will define what roles are and how to define their properties.  This section will also discuss the relationships between roles and requirements.   

Properties of Roles.  Roles in software development environment are stakeholders with specific properties.  All individual members of a software project must be a member of at least 1 role, which means all stakeholders have at least one role. The role describes what their function within the environment is. Every member of a project has some function, or they would not be part of the project. Each stakeholder assumes their role in a unique manner. That is, the stakeholders customize their roles. Roles are organized into groups of stakeholders and commonly follow a hierarchy within the environment. An example is a programmer could be a subordinate of a team Lead, and a team Lead might be a subordinate of a Project manager.  It is common that stakeholders assume multiple roles. An example is the programmer that is a client group and a team lead.  Another example it some times a stakeholder can be a client and a requirements engineer.  There are many combinations of roles.

Role Relationships.    All requirements are related to roles.  Stakeholders assuming roles create, modify and delete requirements.   Some of the factors impacting changes to requirements are described by Kontonya and Sommerville in [14], they include: errors, evolving knowledge, technical problems, changing priorities, environmental changes and organizational changes.  Roles are also affected by changing requirements.  This sub-dimension describes how roles are affected by change information and the coupling of roles to requirements by a variance association; this means when requirements change roles, can be affected. An example is, assume there is a programmer whose role is responsible for implementing a function defined by a specific requirement.  If that requirement changes then the programmer role will be affected.  They might have to change the implementation of the requirement.  Another example is suppose, a requirements has been deleted from the project.  The change information needs to be delivered to all the effected roles.  Once a role has been informed of the deletion they can then modify any relevant development information such as the SRS.  Multiple roles can be coupled to the same requirements.  This is common to have a team of stakeholders working on one specific requirement.  An example is, suppose the client decides that they need to add a new requirement to the project.  The addition of this new requirement is substantial and will require many programmer hours to implement.  So, information about the new requirement needs to be distributed to many different roles such as the Project manager, Team leads and the programmers.  Roles are also associated with information objects such as source code and documents.  Roles are responsible for manipulating information objects that are associated with them.  Information objects will be described in detail in the next section. 

3.2         Information Objects 

In this section we will answer Q2 by defining the information dimension of our framework.  Changes to the environment are reflected in the information objects.  Information objects relating to the development environment are coupled to requirements by a variance association.  This means that there is a logical relationship between information objects and the requirements they refer to.  Information objects are also related to roles through a transitive association between Roles, Requirements and Information objects.  That is, a role can be associated to an information object by a requirement.   There are three different types of Information objects that are related to tasks. A task is some action taken by roles that change the environment.  All tasks begin with conceptual information, that information is communicated and then the task is implemented.  See figure 1 for a visualization of the classifications of information objects.

Figure 1: visualization of the classifications of information objects.

Implementation Information Objects.  Some information objects are part of the software implementation phase.  They usually represent the deliverable of some task. We will describe some of the common objects such as Change Management systems which are repositories for project source code.  They store their information as Modification Records (MR).  The MR is a reflection of a change to the environment.  When requirements change the change is reflected in the state of the repository.  An example of the variance association is when a requirement has been added to a project, the code base in the change management repository should be updated to reflect that addition. So the variance association is the relationship between the record in the change management system and the requirement. Requirements can be associated to multiple MR’s and MR can be associated to multiple requirements.  An example is, suppose the clients have decided to remove a specific requirement form the project.  The deletion of that requirement is related to any MR that reflects the removal of the requirements from the project.  Conversely a programmer could be making modifications that effect multiple requirements, once they commit their changes there is a relationship between the MR and the effected requirements. Defect Tracking systems are also information objects.   The primary function of the defect tracking system is to identify inconsistency between the program code and the requirements.  Issues stored in a defect tracking system are associated to the requirements affected by the inconsistency.  An example is, assume that testers are assessing a new software build for the clients; they notice that the program is not producing the right output for a certain situation.  The tester then loges a bug ticket with the default tracking system.  The ticket indicated that the software does not meet a specific requirement, if it did it would not be a bug.  So there is a relationship between the defect ticket and some requirement.  Defect tickets can also relate to multiple requirements.  An example is a bug in a software program’s GUI might impact a usability requirement, performance requirement and a reliability requirement. Project Documentation such as prototypes, RFP’s, and manuals all describe project requirements.  There are many other forms of project documentation not mentioned, but any documentation related to the project development can be coupled with requirements.  Some examples are, a user manual demonstrates how to use some of the functionality of a software system.  If the requirements have been changed and some functionality has been added, the user guide needs to be updated.  There is a relationship between the added requirement and the modified section of the user guide.  Another example is if a requirement has been eliminative from the project due to budgetary concerns, then the SRS should be updated to reflect that change.  The deleted requirement is connected to the modified section of the SRS. 

Communication Information Objects. Creating software is usually a complex task that requires a high level of communication between stakeholders.  The communication is commonly how tasks move from a conceptual stage to implementation.  It should be noted that some communication objects are also implementation objects and vice versa. For instance, assume a client decides that they want some new functionality added to their software project, so they send an email to the requirements engineers describing the new feature. In the email the client makes a small prototype describing the new functionality.  The email is the means of communication between the client and the requirements engineers, but it is also an implementation of prototype.   Communication objects can be the hardest source of information to capture due to its commonly ad-hock, decentralized, non-archival manner.  For example it is difficult to capture an impromptu discussion by the coffee machine.  However, communication objects are a rich source of requirements information, and show how conceptual information becomes formal elements of the development environment. Such as email discussion threads where clients negotiate with developers on what requirements can be implement.  It is common that information relating to the change in requirements is reflected in email or audio conversations.  Some projects post email archives on the web to insure that others are aware of changes to requirements recorded in emails.

Conceptual Information Objects. Software development requires the formulation of ideas to implement the projects’ requirements.  These abstract ideas are fundamental in realizing project requirements.   Conceptualizing tasks are commonly done as group activities; however, that is not always the case.  At the beginning of a task conceptual information is communicated through the development environment that information is the foundation of the task implementation. It should also be noted that not all tasks that are conceptualized are implemented.  Conceptual information objects have a direct association to the project requirements.  Indeed they are usually the foundation for implementing change to requirements. Generating ideas is a conceptual task that can results in information objects which relate to project requirements.  In [13] McGrath describes generating ideas to be a highly creative task requiring the cognitive efforts of collaborative groups.  An example is a client group participating in a brainstorming session. The results of the session are that several new requirements have been discovered.  The clients need to add these requirements to the RFP.  There would than be an explicit relationship between the deliverable of the interaction and the requirements. Also brainstorming commonly relates to specific requirements, if those requirements change then it might be necessary to reassess the results of the brainstorming session.  For example, suppose that some programmers are brainstorming how to implement a specific set of requirements, then some of the requirements they were supposed to implement were deleted.  This means that the result of their initial brainstorm session needs to be modified to accommodate the change to requirements.  Planning tasks related to software development is a conceptual activity that relates to how tasks should be carried out. These tasks will likely manifest changes to requirements.  An example is the developers will plan how they will implement certain requirements specified by the client.  The action plan developed by the developers is connected to requirements it concerns.  If the requirements change then the plan will likely need to change as well.  Problem solving in the software life cycle is an important conceptual activity. McGrath describes problems solving to be an intellective task requiring a high level of collaborative efforts [13].    Implementing solutions to problems is done so that software will adhere to the requirements. An example of how problem solving activities are associated with requirements is as follows: suppose a requirements engineer notices that there are two requirements that are conflicting and they cannot both be implemented.  So, they decide to ask the client which requirement they can modify so that the SRS is correct.  The client decides to remove 1 of the requirements.  The problem information is directly linked to the requirements conflict. We will examine some of the classifications of group tasks proposed by McGrath in [13].  Decision making tasks in the software development environment provide conceptual information about strategies for how the group goes about choosing their activities [13]. Rationale for decisions are usually constrained by requirements. An example is the clients make a decision to remove some requirements because keeping the budget down is the highest priority requirement. So, they ask the Requirements engineers to remove the requirement. The change in requirements resulted in a decision to change the implementation.  Another example is suppose some requirements have been added by the client.  The developers now need to make decisions on how they will accommodate the new requirements.   So the change to the requirements has effect the decision processes of the developers. 

In general it is likely that changes to the requirements of a project will force stakeholders to reevaluate there conceptualization of their tasks.  This reassessment might prompt a change in their approach to implementing tasks. So it is important recognize the relationship between tasks and requirements, so as to minimize time wasted on confusion.

3.3         Presentation of Change Information 

This dimension of our framework is interested in describing how changes in requirements are presented to stakeholders.  By examining this dimension we hope to answer Q3.  Changes to requirements involve adding, deleting and modifying requirements.  Once a decision to make a change to the environment has occurred, it is usually the responsibility of some specified role to propagate the change information throughout the environment. The information needs to be delivered to the impacted roles. The roles then need to identify which information objects are affected by the change to the requirements.  They then need to make changes to the affected information objects.  Finally, they need to propagate any changes they made to other affected roles.  

Format of Change information. There are several factors involved in the presentation of information to roles in the environment.  Distribution of information can be presented to stakeholders on-demand or automatically.  An example is developers can have change information presented to them automatically in real time perhaps by email or audio, or the information can be stored in a repository which they can access on-demand. Some change information is high priority so it needs to be delivered in real-time, such are a major change to a requirement that needs to be implemented in a short period of time.   Other information might have less priority and could be accessed at the stakeholders leisure. The intended Audience can be specific or general. That is, the information can be presented to individuals on a point-to-point basis or can be broadcast to many stakeholders.  Some examples of mediums that allow broadcasting of information are email mailing lists, streaming audio/video, and websites.  The Form of the information refers to the media of the information. An example is change in the requirements that can be delivered to the roles in hypertext, text, graphics, email, video etc. 

Role Notification. Who is affected by changes in requirements is important to the presentation of change information.  It is vital that when requirements change there is evidence of who will be affected by the change. This will allow change information to be delivered to the affected roles.  An example is the clients decide to add a new feature to a project and the feature is based on a prototype they developed.  Once the decision to change the requirements has happened the relevant developers are notified by email with the change and are presented with the prototype as a visualization of the necessary changes they need to make. 

4.         Discussion

In this section we will discuss how our framework can be used.  Specifically, we will discuss how the frame work allows us to model an ideal environment where awareness of requirements is supported through an Awareness System.  We will also discuss how to use our framework to compare tools that provide awareness.  This will give tool designers insight into developing cognitive support for workspace awareness.  

4.1         Requirements Awareness System

To provide support for awareness of requirements in software development will require a well defined system where all objects in the environment are classified according to some criteria.  In our environment we have Roles, Information Objects and Requirements.  In the previous section we provided definitions of these classifications.  Next we must define an Awareness Mechanism.  An awareness mechanism is an instrument that detects changes to the requirements in our environment.  When the awareness mechanism detects changes, it alerts specific roles that are affected by the changes.  The awareness mechanism knows which roles are affected by the changes because there is a mapping between requirements and roles that are affected by changing those requirements.  We will call this mapping Traceability Links. The traceability links define variance association as described in the previous sections of this paper.   There is also traceability links between the requirements and the information objects associated with the requirements.  Once the awareness mechanism has detected a change to the requirements it will deliver the Awareness Information to the affected roles.  Awareness information can be presented in many different ways. Some of the characteristics of the information were described in the previous section.   Once the roles have received the awareness information they can then update the affected information objects.  Roles also provide feedback into the awareness system by modifying requirements.  See figure 2 for a visualization of the Awareness System.

Figure 2:  A visualization of the Awareness System

4.2     Comparison

Another important aspect of our framework is that it will allow us to compare tools that provide awareness support.  This is important because when selecting tools to use for supporting software development activities you would want to insure that the tools you have selected will be adequate for your intended purpose.  By evaluating them based on the framework it should be easier to identify which tools will best support your environment. 

5.         Future Work

For our future work we plan to continue building on our framework.  We hope to do some case studies that will allow observing awareness of requirements in applied situations.  By seeing the effects of awareness, or in some cases lack of awareness, we hope to enhance the framework we described in this paper. 

We will also apply the framework to comparing requirements tools. It is our goal to identify what level of awareness various tools will support.  We will do this with the hope of identifying an existing tool set that provides the highest level of requirements awareness.  Next we will use our framework to go one step further and provide a specification of a tool that will provide awareness of requirements.

Some of the challenges of developing a useful requirements awareness system are: difficulties automating decision processes for creating associations between roles, information objects, and requirements.   To provide a high level of accuracy in the associating will likely require human intervention which can be costly and time consuming. Another less technical issue is the process of managing requirements centrally and keeping them up to date.  This is important because there has to be a well defined mapping between requirements, roles and information objects for an awareness system to work.

     There are also technical issues on archiving communications and linking them to requirements. Some of the most challenging aspects of archiving communications involve capturing informal communications.  This, by their nature, is unpredictable and random.

6.         Conclusion

In this paper we described the concept of requirements awareness. We focused on discussing ways to explain the important elements of requirements awareness. We then went on to argue the potential benefits of establishing such a framework.  Defining factors involved with awareness allows us to achieve a better understanding of how changes to requirements affect our development environment.  If we better understand awareness we have the potential to mitigate the negative effects of evolving requirements.  It also allows for the achievement of better shared understanding between stakeholders in software development environments. 

We hope that this framework is the beginning of identifying strategies for providing workspace awareness support for software development environments.  

7.     REFERENCES

[1]     Cadiz,  JJ.,  Venolia,  G.D.,  Jancke,  G.,  Gupta,  A., “Designing  and  Deploying  an  Information  Awareness Interface”. Proceedings of CSCW 2002, 314-323, 2001.

[2]     Cadiz, J.J., Fussell, S.R., Kraut, R.E., Lerch, F.J., Scherlis, W.L., “The awareness monitor: A coordination tool for asynchronous, distributed work teams”, 2000. Available at: http://research.microsoft.com/~jjcadiz/

[3]     Cubranic, D., Murphy, G,. “Hipikat Recommending pertinent software development artifacts”. In ICSE 2003 [13], pages 408–418, 2003.

[4]     Faulk, S,R., “Software Requirements: A Tutorial”. Technical Report NRLMR554695-7775,Naval Research Laboratory, Washington DC, 1995..

[5]     Gutwin, C., Penner, R., and Schneider, K. Group Awareness in Distributed Software Development. In Proc. of 2004 ACM Conference on Computer-Supported Cooperative Work. ACM Press, 72-81, 2004.

[6]     Ju, W., A. Ionescu, L. Neeley, T. Winograd. “Where the Wild Things Work: Capturing Shared Physical Design Workspaces”. Proceedings of CSCW 2004.

[7]     Kobylinski, R., Creighton, O. Dutoit, A.H. and Bruegge, B. “Building Awareness in Global Software Engineering Projects: Using Issues as Context” in International Workshop on Global Software Development (co-located with ICSE '02), Orlando, FL, May 21, 2002.

[8]     Mockus, A., Herbsleb, J., “Expertise Browser: A Quantitative Approach to Identifying Expertise”. Proceedings of the 2002 International Conference on Software Engineering, 2002.

[9]     Sarma, A., Noroozi, Z., van der Hoek, A., “Palantír: Raising Awareness among Configuration Management Workspaces”. Proc. ICSE 2003 (Portland, OR, May), 444-454, 2003.

[10]  Schmidt, K. “Some notes on mutual awareness”. Copenhagen, Denmark: COTCOS, CTI,DTU. 1998.

[11]  Schmidt, k., “The Problem with `Awareness': Introductory Remarks on `Awareness in CSCW'”, Computer Supported Cooperative Work (CSCW), Volume 11, Issue 3 - 4, Pages 285 – 298, Sep 2002.

[12]  Storey, M., Cubranic, D., Germán, D., “On the use of visualization to support awareness of human activities in software development: a survey and a framework.” SOFTVIS 2005: 193-2029, 2005.

[13]  McGrath, J.E., and Hollingshead, A.B. “Groups Interacting with Technology”, Newbury Park, CA, Sage, 1994

[14]  Kontonya, G., and Sommerville, I., “Requirements Engineering: Processes and Techniques”. John Wiley and Sons, New York, 1998.