RAA3 Requirement Engineering: Does Users involvement matter?

Reference: Sari, K., Marjo, K., Laura, L., & Tero, K. (2005). The Role of User Involvement in Requirements Quality and Project Success. IEEE International Conference on Requirements Engineering, 2005.

Objectives: A requirement can be described as a statement which specifies what a particular product should be able to accomplish. Establishing requirements requires the gathering of information to ensure that a product help users achieve their goals. Research has shown that user involvement in requirement engineering can improve the quality of requirements. The term “user involvement” means direct contact between the design team and users through user feedback, product testing, ect. In this paper the authors seek “to investigate the role of user involvement in defining user requirements in typical development projects.” (Sari, Marjo, Laura, & Tero, 2005)

Methods: A survey was conducted, which involved 18 individuals who worked in software related development projects in 13 companies. Participants had to answer questions based on the most recent projects they participated in during the requirements engineering stage. Questions came from four sections: background information, the requirements quality issues from the user-centered design point of view, the success of the project, and requirements engineering practices. The researchers then validated the results of the survey by interviewing 8 of those participants.

Main Findings: From experience the authors argue that developers tend to view users as “one big faceless mass” (Sari et al, 2005) when users are not involved in product development. Based on the results, they argue that developers become more aware of their limited knowledge of users issues when users are involved. The project-success assessments and average requirement quality was also higher in projects where requirements were based on real information from users or customers. In addition, when users are involved less money is spent and more time is saved on requirements engineering. Finally the results revealed that requirements were defined carelessly or too abstract when users were not involved. 

Analysis: Based on these results, projects which involved users in product development were considered to be more successful than those projects where users were not involved. In their research, (Chatzoglou & Macaulay, 1996) showed that fewer iterations were needed when users were the main source of information. I believe that user involvement in a development project can tremendously increase requirement quality, because users usually know what they want. And even in cases where users are not sure what they desire, a prototype of a product will give them enough information to know what they don’t want in a product.

The authors argued that the programmers in some projects did not care for user involvement because they had to consider too many wishes and features requested by those users.I believe that it is perfectly fine for users to voice their expectation of a product, but it should be left to the design team and programmers to decide how those functions and features should be implemented.

Though this research produced valuable information on the effectiveness of user involvement, the sample was fairly small, which may not give a true impression of typical project development in all companies. Taking this into consideration, a larger study should be done with this consideration although I believe it would only confirm these results.

Although user involvement does give some value insight to programmers in terms of requirements, it may not help them understand the context in which the product will be used. Then again this would require some ethnographic research will may prove too expensive and time consuming for the project at hand. I believe that for typical development projects user involvement will give designers enough information to establish high quality user requirements.

Requirements, what is it and why do we need it?

In simple terms the requirements for a product implies what that product should be able to accomplish for the user. The requirements are a very essential part of product design because they give direction for the design activity. Before the requirements can be established we need an understanding about the user, their work and context of their work. From that information we can then produce a set of requirements for the product at hand.  Sharp et al gave a simplistic view of this process: “first gather some data, then analyze and interpret it, then extract some requirements from it”. (Sharp, Rogers, & Preece 2007)

During the design process requirements are constantly refined due to a better understanding of the needs of users.  This is important because as more information is gathered the designer gets a clearing understanding of users’ needs which was probably not communicated at first. Another reason to refine requirements is the fact that it is a lot more difficult and expensive to fix errors late in the development cycle or when the product is already sent to market. Getting a correct understanding of product requirements avoids these problems.

Types of requirements

We basically have two types of requirements: functional requirements and non functional requirements. “Functional requirements say what the product show do while non functional requirements say what constraints there are on the system and its development.” (Sharp, Rogers, & Preece 2007) Understanding the functional requirements of a product is exceptionally important since a failure to do so will result in absolute failure of the product.

 Context Inquiry

Context inquiry is a very important part of establishing requirements because it helps uncover requirements based on context of use. It contains four main principles: context, partnership, interpretation and focus.

(Sharp, Rogers, & Preece 2007)

• The context principle emphasizes the importance of going to the workplace and seeing what happens.
• The partnership principle states that the developer and the user should collaborate in understanding the work.
• The interpretation principle says that the observations must be interpreted in order to be used in design, and this interpretation should also be developed in cooperation between the user and the developer.
• The focus principle focuses on keeping the data gathering focused on your goals. 

Task description

Another aspect of establishing requirements is task description, which can come in three flavors: scenarios, use cases and essential use cases.

• A scenario describes activities or tasks in a story format, and usually place emphasis on the context and user goals.
• Like scenarios use cases also focus on user goals, but emphasizes on a user-system interaction rather than the user’s activities.
• Essential use cases are sort of in the middle of scenarios and use cases. Essential uses cases consist of a name that expresses the overall user intention, a stepped description of user actions, and a stepped description of system responsibility.