Requirements analysis by CoFFEE

The Background

Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.

Conceptually, requirements analysis includes three types of activity:

• Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
• Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
• Recording requirements: Requirements may be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

Stakeholder interviews are a common method used in requirement analysis. These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.

Our Idea

The task of requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. Our idea is to use CoFFEE during this process in order to alleviate these psychological skills and push more emphasis on the discussion in order to meet the business needs.

The CoFFEE Session

The discussion within CoFFEE is organized in a session, which is divided in steps. The activities that can be accomplished within each step are defined combining one or more CoFEEE tools. In addition, groups of users can be made to let them conduct parallel independent activities. The accomplishment of a step is managed by a supervisor and has the effect of freezing the associated activities. In the controlled experiment presented in this paper, two meaningful and well known tools have been used: the chat and the threaded discussion [13]. In particular, the chat tool allows the users to discuss in a group by using the so called synchronous conferencing and offering an interface based on the well know internet relay chat system.
The threaded discussion tool enhances the chat tool enabling the users to structure a discussion flow in threads. Notice that the threaded tool can be configured so that it uses the categories that are separated thread chats with a topic. A user can submit a contribution after he has selected the appropriate categories and other users can provide multiline contributes attached to some category or attached to previous contributions.
Furthermore, the threaded tool can be configured in order to tag the user contribution type (e.g., suggest, agreement, or revision). The contribution types can be customized as necessary. A session example of a threaded discussion within the CoFFEE system is shown in Figure 1.

In our experiment we have created a session composed of two identical steps. Each step is composed of a threaded chat (see the middle of Figure 1) and a chat tool (see the right hand side of Figure 1). The threaded chat has been configured to provide a discussion point for each entry within the structured description of the negotiated software functional requirement, namely as follows:

• Use case name
• Participant actors
• Flow of events
• Entry condition
• Exit Condition
• Quality Requirements

Further details on the adopted structured description can be found in [6]. In the first step the users (playing the role of developers) had to interview the client to get clarification on the negotiated software requirement. In the second step a facilitator (elected among the developers) was in charge of formalizing the negotiated requirement according to adopted template. The remaining users had to supervise the formalization of the negotiated requirement.

The CoFFEE session is composed of two steps. For each step we have two tools; the threaded chat (on the left) and the linear chat (on the right). At the beginning the teacher make several groups where each group has four students. One of the student will figure as the commette and during the discussion the linear chat will be used to debate and interview the committee. Instead, the threaded chat has six categories as follows:

The Experiment

The context of the experiment was constituted of Bachelor students in Computer Science at the University of Basilicata. The total number of involved subjects was forty eight voluntary students. Thirty two subjects have been attending a software engineering course and acted as developers, while the remaining twelve subjects have been attending an Operating System course and acted as clients. It is worth noting that the prerequisite for participating as developers was experience in software engineering. In fact, all the developers were grouped in development teams and allocated on software projects aiming at developing software systems with a distributed architecture (typically three tier) using mainly Java and web technologies and a relational DBMS. During the laboratory activity they were explicitly asked to conduct scheduled and unplanned meetings to disseminate and share project information within the team. On the other hand, the clients have never attended a software engineering course. In such a way, they were only able to provide details on the problem domain and on their needs, rather than on how the system should be implemented. All subjects gave informed consent and were compensated for their participation to the experiment.
The subjects were randomly grouped in twelve software development teams. The teams were composed of three developers and one client. The experiment has been performed in a controlled setting within a Computer Science Laboratory of the University of Basilicata.
The experiment has been organized in two laboratory sessions, which were accomplished in two different days. The former was a training session where details on the traditional face-to-face meeting, CoFFEE, and Second Life were presented. Subjects have also used them on tasks not directly related with the experimentation (e.g., OpenSource advantages and disadvantages).
In the second session the subjects were asked to perform a task regarding the negotiation of a functional requirement of a system on which they were familiar with. The following is the task they were asked to perform: Negotiating the software requirement “create a new client within an E-Commerce Platform (ECP)” and construct its structured description.

Conclusions

Soon...

Future works

Soon...

References

[1] B. Bruegge and A. Dutoit, “Object-Oriented Software Engineering Using UML, Patterns, and Java”, Prentice Hall, 2004. [2] R. De Chiara, A. Di Matteo, I. Manno, and V. Scarano, “CoFFEE: Cooperative Face2Face educational environment”, Proceeding of International Conference on Collaborative Computing: Networking, Applications and Worksharing, 2007, IEEE CS Press, pp. 243–252