|
6. Requirements Elicitation and AnalysisGetting the requirements right on a software project is of paramount importance. If the final product does not do what the customer wants it to do, then it is likely to be rejected and the project will be a failure. From a quality perspective, the level of quality a system has can be linked to how successfully it does its required task. It may perform a task with 99.9999% reliability, and have a perfect user interface. If it is not doing what is required, then the quality can be defined as being poor. This section describes how requirements can be properly captured from the customer into specifications. It also investigates the use of Quality Function Deployment (QFD) to aid in this process. In a perfect world, requirements would not change. At the beginning of a project they would be set in stone. This is not the reality, and customers often request new features, or different ways of doing things. This brings up the second major problem relating to requirements elicitation, which is the management of change. Futrell et al. (2002) describes the six requirement engineering steps:
This review will concentrate on elicitation and management, as these impact most heavily on the resultant quality of the system. 6.1. Requirement elicitation methods6.1.1. Interviews Interviews take place between the stakeholders and either a developer or a specialist in elicitation. A wide range of interviewees should be selected to gather as many requirements as possible. The questions asked should focus on what the stakeholder wants to get out of the software. Interviews are seen as a good starting point, but it is not recommended to rely on them solely for requirements elicitation. 6.1.2. Brainstorming sessions Futrell et al. (2002, pg. 523) describes brainstorming as “a group technique that may be used during the requirements-gathering process to promote creative thinking. It facilitates defining the problem to be solved by the life cycle activities to follow”. Brainstorming for requirements is useful as it generates a large amount of them, even if they are not true or possible to implement. Each generated requirement is recorded and explored, to see if it is actually important. Requirements that are not deemed essential are postponed for a later release or are dropped entirely. Brainstorming can save time by documenting requirements that may be required at a later stage. It also generates requirements that even the stakeholders may not come up with. 6.1.3. Facilitated Application Specific Techniques (FAST) Fast is similar to brainstorming and contains the following tasks:
6.1.4. Joint Application Design (JAD) JAD is a process, similar to brainstorming, which captures requirements at a high level, but specific abstraction. JAD sessions are very popular in the industry and typically last three days. In this time, participants generate ideas that are captured by facilitators. These ideas are fleshed out with the use of tools. Data Flow Diagrams (DFDs) and Entity Relationship Diagrams (ERDs) are two common graphical methods for exploring the generated ideas. While JAD sessions are a good way to get a detailed list of requirements that have been thought out, Futrell et al. (2002) points out three disadvantages:
6.1.5. User scenarios / use case development sessions These describe what a system will do. Actors interact with events to show what the system will perform in a particular case. Actors can be users, databases, or other systems. Events might include calculating the balance of an actors account, or interfacing with a different system. By going through each possible case the system will be in (often graphically, with use case diagrams), a good knowledge of the customers business will emerge. Those who use the system (the actors) need to be a part of this process, so a focus is placed on them and their needs. 6.2. Requirements managementOnce the initial requirements have been agreed upon, other requirements are likely to be uncovered as the project progresses. How these are dealt with is important. If they are ignored by the developer, then the quality of the final system is likely to be severely reduced. If every single requirement suggested is tacked on to the system, quality is also likely to suffer, with additions and modifications done improperly. Configuration management can be used to manage requirements. Baselines are established and any modifications to those requirements must be signed off. Prototyping is a great method to use for a situation where requirements are unclear and are likely to be uncovered as the project progresses. A mock up of a system is created on a small scale to demonstrate the basic functionality. Users can interact with this prototype to determine what is required. At the completion of the prototype, it is discarded and development begins from scratch. This time however, the system requirements will have been clarified significantly. 6.3. Requirements and Quality Function DeploymentQuality Function Deployment (QFD) is used to define the requirements of a product (any product, and increasingly services) based around the end users needs. This customer focus is QFD’s strength, and with the use of the relational matrix, solid customer requirements can be extracted. Figure 4 (taken from Tan et al., 1998) demonstrates this relational matrix (also known as the house of quality). This was constructed based on a survey of internet users on how web pages should be designed. A questionnaire was given out, with participants determining what they see as being important quality issues relating to web pages. The results of the questionnaire were then sorted into primary, secondary and tertiary requirements. Following this, the requirements were translated into technical details, listed on the vertical. These technical details are not solutions, but are in a format that a solution can be readily developed from. A cross-functional team, utilising brainstorming is commonly used for this stage. The central matrix shows the relationship between the customer requirements and the technical details. The ‘roof’ of the house of quality gives the co-relationships between the technical details. Finally, a ranking is computed from both types of relationships using weightings. This final ranking is an indicator of what technical detail is the most important issue to concentrate on and get right. It can be used to prioritise the implementation of components of a system, or to choose which parts get left in or thrown out.
Figure 4. The House of Quality Relational Matrix Futrell et al. (2002) identifies the main goals of QFD as being to:
The main drawback from this approach seems to be the reliance on accurate data from the questionnaire. Therefore, it is important to design the questionnaire properly, to correctly represent what the customer is thinking.
|
