|
Requirement Engineering
part 3
4. Requirment Mangement
In Software Development new requirements emerge and existing requirements change during all the stages of SDLC (Software Development Life Cycle). It has been observed that in most of the software projects more than 50% of system’s requirement change or modify before the system is deployed. This astonishing figure of 50% can cause serious problems during system development and it may also have negative impact on the quality of software system. On the basis of these facts, system developers and Managers want to minimize these negative impacts to maintain the quality of software system. To minimize these negative impacts, a process is needed for documenting the changes and controlling the effects of changes. The name of needed process is “Requirement Management”. Requirement Management is a process where changes in requirements are documented and controlled. Requirement management involves many sub activities. The first activity involved in process of requirement management is categorizing the requirements.
1) Stable and Volatile Requirements: A change in Requirement may occur during requirement elicitation, requirement analysis and negotiation, requirement validation and even after the system is deployed. It is a common perception that changes in requirements are due to poor requirement engineering practices but this perception is not valid. Changes in requirements are inevitable and they can’t be avoided. As a matter of fact, these changes guide us toward better productivity of system. In requirement engineering, handling the changes in requirement is very vital because against a single requirement there may exist many changes and managing all those changes manually may become difficult. Hence for better change management, the very first task is to categorize the requirements. A requirement can be either stable or volatile. A stable requirement is concerned with the essence of a system and its application domain. Stable requirements change slowly then volatile requirements. On the other hand, volatile requirements are specific to instantiation of system in specific environment and for a specific customer. The requirements are classified to identify the most volatile requirements and then for predicting possible changes. The advantage of this approach is that it provides information to system developers and that information helps them to design the system so that these requirements are implemented by independent and isolated components. When the change will be proposed in any volatile requirement, the influence of the change will only be at the specific component and rest of the system will not be affected by the change. 2) Requirement Identification and storage: For managing the multiple requirements, it is very important to uniquely identify every requirement. Apparently this may seem simple and very obvious but in reality a large number of requirements document do not uniquely identify the system’s requirements. As a result, effective requirement management is not possible. For identification and storage of requirement many approaches are in use. Most common of those approaches are relational databases and object oriented databases. Among these the recommended approach is object oriented database. The relational database requires operations on several different tables and for very large numbers of requirements, this type of database may take a longer time. Object oriented databases are better approach for requirement identification and storage because they allow different types of information to be maintained in different objects. Moreover managing links between different objects is very straight forward in object oriented databases. 3) Change Management: Change management is concerned with the processes and standards which are used to manage changes to system requirements. Benefit of using change management is to ensure that similar information is collected for each proposed change and to ensure that overall judgments are made about the benefits obtained by the changes. Moreover change management is also used for making estimates regarding costs. If formal change management is missing then it is almost impossible to ensure that proposed changes to the requirements support the fundamental business goals or not. Many CASE (Computer Aided Software Engineering) tools are available in market, which are designed to support change management but general problem with these available tools is that they all have their own model for change management and organization must conform to that specific model before adopting that tool. 4) Traceability: Most important part of the requirement change management process is the assessment of the impact of a change on the rest of the system. In traceability, the impact of change (in terms of cost, performance and etc) is observed. Traceability is vital for Quality Assurance because in change management, it is possible that positive impact in one module of the system is having negative impact in other modules of the system. In requirement management, traceability is mostly done with the help of traceability table. The traceability table helps us to see the dependences. It shows that which requirement is depending on other requirements. By identifying the dependences, we can observe the impact of change only on dependent components instead of observing whole system. Requirement management is very vital as it helps us to keep a track of changes in requirements and to maintain the Quality of the system. Changes registered in Change management phase are sent back to requirement analysis and negotiation stage and the whole process of requirement engineering is repeated for every change in requirement. The process of requirement management comes in to act whenever any new requirement emerges or any existing requirement is changed. The time span of Requirement Management is longer than all other requirement engineering activities as it encloses all the SDLC stages. 5. Requirement Elicitation Techniques
As requirements elicitation is a process in which intensive interaction between stakeholders and the analysts is required, so for making the interaction between stakeholders and analysts easy and for improving the quality of extracted requirements, it is important to distinguish different elicitation methods according to the four means of communication:
- conversational - observational - .analytic - synthetic Each category presents a specific interaction model between analysts and stakeholders. Understanding the method category helps engineers understand different elicitation methods and guides them to select appropriate method(s) for requirements elicitation. Now we will discuss each of these categories individually. For the ease of our readers, we have divided this article in 2 parts. In first part, we will discuss Conversational and Observational Methods while in second part, we discuss the Analytic and Synthetic Methods. 1) Conversational Methods: The conversational method provides a means of verbal communication between stakeholders and Analysts. As conversation is a natural way of communication and an effective mean of expressing needs and ideas that’s why the conversational methods are used massively to understand the problems and to elicit generic product requirements. The Conversational Methods are also known as verbal methods. Examples of conversational methods are following: Interviews: A typical conversational method is interviews. It is most commonly used method in requirements elicitation. An Interview is generally conducted by an experienced analyst, who has some generic knowledge about the application domain as well. In an interview, Analyst discusses the desired product with different stakeholders and develops an understanding of their requirements. Generally Interviews are divided in two groups. - Structured Interview- Pre-defined Agenda and Questions - Open-ended Interview- No Pre-defined Agenda, all questions and inquiries are on real time Workshop and focus groups: Workshops and focus groups are also good examples of conversational methods. In a workshop or focus group, Stakeholder are gather together for a short time period but this period is intensely focused to create or review high-level features of the desired products. Brainstorming: Brainstorming is another conversation method. It has some similarities with workshops and focus groups as in Brainstorming stakeholders are gather together for a short time period but in this short time period they develop a large and broad list of ideas. In this meeting “out -of-the-box” thinking approach is encouraged. The brainstorming involves both idea generation and idea reduction. 2) Observational Methods: The observational method provides means to develop a better understanding about domain of Application. Observation methods work by observing human activities at environment where system is expected to be deployed. In addition to state able requirements, some requirements are apparent to stakeholders, but stakeholders find it very hard to verbalize. This Type of requirements is also known as tacit requirements. The observation methods come into play where Verbal communication becomes helpless for collecting tacit requirements. Therefore, observing how people carry out their routine work forms a means of acquisition of information which are hard to verbalize. The observational methods appear to be well suited when stakeholders find it difficult to state their needs and when analysts are looking for a better understanding of the context in which the desired product is expected to be used. Examples of observational Method are following: - Social analysis, Observation, Ethnographic study: An observer spends some time in a society or culture for making detailed observation of all their practices. This practice gives the initial understanding of system, work flow and organizational culture. - Protocol analysis: In protocol analysis a stakeholder is observed when he is engaged in some task, and concurrently speaks out loud and explains his thought. With the protocol analysis it is easy to identify Interaction problems in existing systems and it gives better and closer understanding of Work context and work flow. 3) Analytic Methods:
Conversational or Observational methods are used to directly extracted requirements from people’s behavior and their verbalized thought. But still there is a lot of knowledge that is not directly expressed, for example expert’s knowledge, information about regulation and legacy products are some examples of such sources. All the stated sources provide engineers rich information in relation to the product. Analytic methods provide ways to explore the existing documentation or knowledge and acquire requirements from a series of deductions. In both (Conversational and Observation) methods, requirement elicitation is done by studying some individuals but a variety of documentation may prove out to be handy for extracting the requirements of the desired product. The documentation may includes problem analysis, organizational charts, standards, user manuals of existing systems, survey report of competitive systems in market, and so on. By studying these documents, engineers capture the information about the application domain, the workflow, the product features, and map it to the requirements specification. Moreover they identify and reuse requirements from the specification of the legacy or similar products. It is always worth inquiring for reports and recorded information relevant to the desired product. Type of requirement elicitation techniques of Analytic method are following: - Requirement reuse: In this technique, glossaries and specification of legacy systems or systems within the same product family is used to identify requirements of the desired system. It has been observed that many requirements in a new system are more or less same as they were in a legacy system’s requirement. So it is not a bad idea to reuse the details of requirements of an earlier system in a new system. - Documentation studies: In this technique different available documents (e.g. Organizational policies, standards, legislation, Market information, Specification of legacy systems) are read and studied to find the content that can prove out to be relevant useful for the requirements elicitation tasks. - Laddering: This technique can be divided in 3 parts (creation, reviewing and modification). In this technique hierarchical content of expert’s knowledge is created, reviewed and modified. This hierarchical content is often in the form of ladders (i.e. tree diagrams). - Repertory grid: Stakeholder is asked for attributes applicable to a set of entities and values for cells in entity -attribute matrix. In general, the analytic methods are not vital to requirements elicitation, since requirements are captured indirectly from other sources, rather than end users and customers. However, they form complementary ones to improve the efficiency and effectiveness of requirements elicitation, especially when the information from legacy or related products is reusable. 4) Synthetic Methods: So far, we have discussed Conversational, Observational and Analytic methods. It is apparent that No single method is sufficient enough to develop all the requirement of a system. All these methods are good and very handy in some certain context and circumstances. It is often a good idea to combine different elicitation methods for developing requirement. The combination helps the engineer uncover the basic aspects and gain a generic knowledge of the application domain. Instead of combining different of individual methods, the synthetic method forms a coherent whole by systematically combining conversation, observation, and analysis into single methods. Analysts and stakeholder representatives communicate and coordinate in different ways to reach a common understanding of the desired product. Synthetic methods are known as collaborative methods as they are collaboration of multiple requirement elicitation methods. Requirement elicitation techniques of Synthetic methods are following: - Scenarios, passive storyboards: It is an interaction session. In this session a sequence of actions and events described for executing some generic task which the system is intended to accomplish. With the help of this technique, clear requirement related to procedure and data flow can be achieved. With this technique initial set of requirement can be prepared in lesser cost. - Prototyping, Interactive storyboards: In this technique, a concrete but partial system is discussed with stakeholders. This concrete but partial system is expected to be delivered at the end of project. The purpose of showing this system to stakeholders is to elicit and validate functional requirement. - JAD/RAD sessions: It stands for Joint Application Development/Rapid Application Development and emphasizes user involvement through group sessions with unbiased facilitator. - Contextual inquiry: this technique is a combination of open-ended interview, workplace observation, and prototyping. This method used for interactive systems design where user interface design is critical. All four requirement elicitation methods are commonly used but the selection of requirement elicitation method entirely depends on the needs and organizational structure.
|
|
|
来自： hildaway > 《references》
