Requirement engineering and management

- Jay

October 15, 2008

Convergys Confidential and Proprietary

Fact - 1

2 Convergys Confidential and Proprietary

Fact -2

3 Convergys Confidential and Proprietary

Fact - 3

4 Convergys Confidential and Proprietary

Fact - 4

5 Convergys Confidential and Proprietary

Where is the exact problem ?

6 Convergys Confidential and Proprietary

How it differs?

Which one you choose?

7 Convergys Confidential and Proprietary

Importance of requirements

8 Convergys Confidential and Proprietary

Where Requirement management fits?

9 Convergys Confidential and Proprietary

What it costs?

10 Convergys Confidential and Proprietary

Requirement - Definition
Defining a good requirement As requirements are the foundation of any development project, teams need to understand the attributes of a good requirement. The best requirements are: Correct Complete Clear Consistent Verifiable (technically and legally possible) (express a whole idea or statement) (unambiguous and not confusing) (not in conflict with other requirements) (it can be determined that the system meets the requirement) Traceable (uniquely identified and tracked) Feasible (can be accomplished within cost and schedule) Modular (can be changed without excessive impact) Design-independent (does not pose a specific solution on design) Each requirement must first form a complete sentence, containing a subject and a predicate. These sentences must consistently use the verb shall, will or must to show the requirement's mandatory nature, and should or may to show that the requirement is optional.

11 Convergys Confidential and Proprietary

Requirement engineering
Requirements engineering is a sub-discipline of software engineering that focuses on discovering, analyzing, specifying and managing the system requirements. A systematic approach to - Eliciting, organizing, and documenting the requirements of the system, and - Establishing and maintaining agreement between the customer and the project team on the changing requirements of the system. Appropriate mechanism for understanding what the customer wants, analyzing needs, negotiating a reasonable solution, validating the specification and managing changes in requirements. Requirement management: Requirements are real capabilities which the system must provide. It makes sense therefore to find out what the requirements are, write them down and organize them, and manage them in the event that they change. Stated another way we'll define requirements management as a systematic approach to eliciting, organizing, and documenting the requirements of a system.

12 Convergys Confidential and Proprietary

Why requirement engineering?

To capture the specific requirements that must be achieved to build high-quality software.
If we dont engineer the requirements:
In most systems, Its highly likely that youll build a very elegant software solution that solves a wrong problem. The result is:
Wasted time and money Personal frustration Unhappy Users

13 Convergys Confidential and Proprietary

Who does requirement engineering?

Depending on project complexity a team of: Software engineer System analyst Business analyst Requirements specifier Requirements Reviewer Other Stakeholders

14 Convergys Confidential and Proprietary

The framework

15 Convergys Confidential and Proprietary

The real connected environment

16 Convergys Confidential and Proprietary

RE - Process

17 Convergys Confidential and Proprietary

Requirements elicitation
Requirements Elicitation is a process during which product requirements are elicited from a variety of sources. Possible sources of information for this task are the customer, end user, any other stakeholder, books, existing applications, domain knowledge, organizational standards or constraints and any other rules or regulations. Various techniques can be used for eliciting requirements

18 Convergys Confidential and Proprietary

Requirement elicitation - Techniques

-

Interviews Surveys Data mining Questionnaires Market analysis Focus groups Future workshops Soft system methodology Co-operative requirements capture Scenario based requirements elicitation Multiple Viewpoint Requirements Capture Observation and Social Analysis Designer as Apprentice

19 Convergys Confidential and Proprietary

Interviews
Interviewing is a technique where requirements engineers and different stakeholders communicate directly with each other. Interviews are usually conducted in a question-answer format with the intention of eliciting the required information for system development. There are two types of interviews: -Structured -Unstructured Structured: In the structured interview, the requirements engineer prepares a list of specific questions and collects responses for them from the customer. Unstructured: An unstructured interview is a discussion between the requirements engineer and stakeholders about the problem concepts and concerns of users. Here the requirements engineer makes note of certain topics to be discussed *Needs experience *Both the interviewer and interviewee must have proper background knowledge and excellent communication skills.

20 Convergys Confidential and Proprietary

Surveys, Questionnaire and Data mining

Surveys and questionnaires List of questions regarding the problem domain or concerns is prepared and distributed to the customers. Responses are collected and analyzed to study the customer needs. In order to get valuable responses, *It is important to properly design the questionnaire and distribute it to the appropriate sample population Data Mining
-

Used to analyze and extract useful patterns from the data collected.

Mining the data about customers such as the responses to a product survey or customers reaction to a new technology, can draw important conclusion about their needs. These techniques are useful if the proposed product is targeted towards a large number of customers. In such cases, information gathered from a few customers will not be sufficient. Surveys and Questionnaires can be used to obtain information from a large number of customers. Data mining techniques can be used to analyze the data obtained from those surveys to identify different classes of customers and *Certain patterns or relationships in their needs. However, it is always difficult to get a good and representative number of responses to surveys. In addition to this, the list of questions prepared should be relevant and should be distributed to the right sample population.

21 Convergys Confidential and Proprietary

Market analysis
The process of analyzing the product market for its current and future trends is called market analysis. Market analysis is a good technique to elicit requirements for a system. Gathering information about the competitor products would help to identify the features that are not present in current products Market analysis is a good technique to analyze similar products in the market. It can reveal how technologies may change in the near future. It can also predict changes in customers demands. Using these details, organizations can make decisions about selecting certain features or technologies for their products. *However, in order to obtain good results from the analysis, the market expert must be well experienced and should have the skill to collect the required information.

22 Convergys Confidential and Proprietary

Focus groups
-Focus groups are group session approaches, where requirements engineers observe and study users needs. Groups of users are allowed to discuss in a free environment certain problem concepts under the supervision of the requirements engineer.
-

The requirements engineer acts as the facilitator and his role is passive. When the users discuss with each other, the requirements engineer can learn about what they think about the product and what they actually want from the product
-

-Since the users are allowed to discuss in a free environment, problems that occur due to a lack of communication can be reduced. It is easier to participate in a free discussion than in a structured interview. -In addition to this, when different customers discuss certain topic, it is easy to identify requirements conflicts and to resolve them. * However, the requirements engineer must have good listening and problem solving skills. Also when several different customers discuss together, it is important to maintain proper coordination between them.
23 Convergys Confidential and Proprietary

Future workshops
-Future workshops are group session approaches similar to focus groups. -In a future workshop session, the current problem situation is discussed, future visions of the systems are generated and possible solutions to realize those visions are discussed -During the process, any changes in the technologies or product features that may occur in the future can be foreseen. -Using these details, the organization can not only make better selections for its current product, but also develop plans for its future products.

24 Convergys Confidential and Proprietary

Soft system methodology

-SSM is a system development framework that allows for system analysis from both the organizational and technical perspective. -Unlike traditional system development processes, which focus only on solving the technical requirements, SSM tries to analyze the problem situation and proposes necessary organizational changes to improve the organizational structure and processes. SSM has several distinctive stages. 1.Problem Situation Unstructured 2.Problem Situation Expressed 3.Building Root Definitions of relevant systems 4.Conceptual modeling 5.Comparison with the real world 6.Implementing the feasible and desirable changes It also supports communication between the management and technical personnel. In addition to this, systems are analyzed from different viewpoints by defining several root definitions. This would identify conflicts in customer requirements or in different viewpoints.

25 Convergys Confidential and Proprietary

Cooperative Requirements Capture (CRC)

-Cooperative requirements capture is another group session approach for requirements engineering. The idea is to include not only the users and designers but also those who have a stake in the product. -In this approach all the stakeholders together explore the user environment and develop a shared vision of the future system. -During the group session, participants discuss the current user activities and envision any possible changes that might occur in future. -The advantage of using the CRC approach for requirements engineering is that it involves all the stakeholders in the decision making process. -Due to this, the needs of different stakeholders can be easily understood. Since all the stakeholders explore and develop a shared understanding of the current and future visions of the product, it is possible to identify requirement changes and conflicts early in the development process. -In addition to this, it supports communication between the participants.
26 Convergys Confidential and Proprietary

Scenario Based Requirements Elicitation

-User requirements are collected using a set of interaction scenarios. -A scenario is a particular instance of the systems use describing the interactions between the system and users of the systems. -Having understood the problem concept, different scenarios can be identified by consulting the system users. Scenarios can be documented using a format that is suitable for the organization. -Regardless of the format, each scenario must include information about the pre-condition, post-condition, normal and any exceptions in the flow of event and any other parallel activities -It is easier for the customer to describe how he or she performs certain sequences of activities than answering a list of questions or simply stating the needs. In addition to this, individual scenarios are easier to understand and design rather than a whole system.

27 Convergys Confidential and Proprietary

Multiple Viewpoint Requirements Capture

-

Helps to collect system requirements from different viewpoints.

Different stakeholders will have different requirements that the system needs to fulfill. Each stakeholder has his/her own viewpoint on the services that the system should provide and the way in which it should be provided.
-

In this approach, different viewpoints of the system are identified and the requirements for each viewpoint are collected separately
-

This technique enables to study the system from different viewpoints.

Requirements gathered from each viewpoint can be analyzed to identify requirements conflicts. Through proper negotiations, most appropriate requirements can be selected. On the other hand, it is a very good technique to develop a generic product that satisfies the needs of different customers.
-

28 Convergys Confidential and Proprietary

Observation and Social Analysis

-Occasionally, it is difficult to elicit requirements just by talking to the users or asking questions. Users are often experts in performing jobs rather than describing how they do them. In such cases, observing and recording the users working in their real environment for a considerable amount of time can provide a lot of information about their requirements. These techniques includes Ethnographic studies - where an ethnographer observes and records a group of users working in their real work place
-

When there is a lack of domain knowledge in the organization, Observations and Social Analysis are good techniques to elicit system requirements.
-

Example If the system being developed is completely new, developers may not have adequate domain knowledge required for product development. Sometimes users are not capable of explaining how they perform certain tasks and what they want from the product. In such cases, this is a very good technique for requirements capturing.
29 Convergys Confidential and Proprietary

Designer as apprentice

This is a technique where the designers learn from the user about their work. Here user is the master and designer is the apprentice who learns by watching and listening to the user. The idea behind this technique is to provide the designer with some practical knowledge about the end users working environment and his/her requirements on the proposed system Getting some practical knowledge about the users work practice helps designers to better understand their needs. It also promotes communication between the user and designer. However, to get good results, the designers should have excellent learning skills.

30 Convergys Confidential and Proprietary

Requirement analysis
A feasibility study and cost-benefit analysis of the product development process may be conducted and the scope of the system is determined. Customer requirements are analyzed and requirements conflicts if any are resolved. Requirements analysis ensures that the system is going to provide the services that the customers require. It also helps the designer to understand the customer requirements.

For product line development, the requirements analysis stage involves: Identification of commonalities and variabilities in the domain Identification of potential members and their features and modeling them to get a better understanding of the family.

Once the common and variable requirements are identified, potential products and their features are selected. Using these details, the feasibility of developing those products as a family is analyzed. Aspects to choose product members and their features, Company strategies Customers priority Market advantage Contribution to the domain and The competition Market Analysis is a good technique that can provide some useful information regarding the current And future market trends and information about other products in the market. Based on the results of this analysis, products and their features can be selected. Once the products and features are selected, they must be modeled. Modeling enhances the understandability and simplifies the design. Depending on the product line approach used suitable modeling techniques can be used.
31 Convergys Confidential and Proprietary

Requirement analysis - Techniques

-

Structured system analysis (SSA) Object oriented analysis (OOA) Joint application design (JAD) Quality function deployment (QFD) Participatory design

SSA: - Function-oriented requirements analysis - Data-flow diagrams can be used to represent the flow of data between various tasks in the domain whereas entity-relationship diagrams can be used to represent various domain entities and their relationships. - Data dictionaries and entity-relationship models. OOA: - Use case diagrams are suitable for modeling requirements from the users perspective and high-level class diagrams can be used to model requirements from the designers perspective. Unified Modeling Language (UML) is a widely used object-oriented modeling language - Flow of messages between the objects and the evaluation of changes in their states due to events or any other stimuli
32 Convergys Confidential and Proprietary

Requirement analysis - Techniques

JAD: -

JAD is a group session requirements analysis and design approach developed by IBM. JAD is a group session approach that involves users in the system design. All the stakeholders can participate in the decision-making process. Activities such as defining high-level requirements and bounding system scope can be extended to identify product line requirements and characterize individual products in the family. JAD defines six different roles of participants who should participate in a session: a session leader or facilitator, a system analyst, a specialist, a user representative, an information system representative and the executive sponsor.

33 Convergys Confidential and Proprietary

Requirement analysis - Techniques

QFD: QFD is an approach developed in Japan to produce quality products in the automotive industry in 1986.

It focuses on translating customer requirements into technical requirements throughout the product development process. The entire QFD process focuses on a house of quality, which maps customer requirements to the proposed product features. Each development phase can use its own house of quality. QFD for the planning phase is used for requirements analysis. Participants are asked to rate each requirement according to their relevance to a particular feature. In addition to this, correlation between various technical features, customers importance of each requirement and market evaluation of the competitive features are also considered. Based on the subjective analysis of the above factors, the final product features are selected. Thus the QFD approach helps to develop quality features that are important to customers QFD is a good approach to select product features and to make high-level design decisions. It encourages the organization to consider factors such as customers priority and competition for requirements analysis.

34 Convergys Confidential and Proprietary

Requirement analysis - Techniques

Participatory design: The Participatory Design approach allows designers and users to work together. Several techniques including Future Workshops, Cooperative Prototyping, Design mock-ups and Future Games are used in Participatory Design Since this approach involves users in the system design, problems that may occur due to a lack of communication can be avoided. All the users can participate in the decision making process. Designers can learn more about users needs by actually doing their work. Users can work with the designer to learn about the design and to verify that the design is going to meet all their needs.
35 Convergys Confidential and Proprietary

Requirement specification
SRS: Each product in the family must be specified separately and there should be proper traceability mechanisms between the family and individual product requirements. A SRS document is developed for each family member as well as for the entire family. While writing the family SRS, all the common and variable requirements must be documented. XML XML can be used to specify product line requirements. Since XML allows hierarchical representation of data, common and variable requirements can easily be represented.
36 Convergys Confidential and Proprietary

Requirement validation
Requirements Validation is concerned with checking the requirements for omissions, correctness, precision conflicts and ambiguities and for ensuring that the requirements follow quality standard Requirement reviews Domain experts Requirements engineers Customers and Stakeholders. Prototyping System prototypes can de developed to demonstrate the system behavior before the final product is being developed. Users have an opportunity to really see how the final system is going to behave and they can provide any feedback regarding possible misunderstandings or any other changes in the requirements. Types: Throwaway prototyping (discarded) Evolutionary prototyping (adapted)

37 Convergys Confidential and Proprietary

Requirement validation
-Requirement testing

Requirements can also be verified by defining test cases for each requirement. Test cases must be defined for both the common and variable requirements. Once the member products and their features are selected, test cases can be defined for each requirement so that products can be tested against each requirement at the end. During the process, it is possible to identify any defect or problems in the requirements.

38 Convergys Confidential and Proprietary

Requirement validation review - Checklist

Sample checklist:

Clarity Completeness Compliance Consistency Correctness Data usage Functionality Interface Level of detail Maintainability Performance Reliability Testability Traceability

39 Convergys Confidential and Proprietary

Requirement management techniques

Understand the following about requirements: -Scope creep can happen , So Beware ! -Instability typically results from problems with scope and understanding -Traceability failures result in broken links, increased instability and POOR QUALITY of product Introduce a method or tool for configuration management Introduce a method or tool for traceability Implement requirements with fields that will be appropriately altered throughout the SDLC - Models - Metrics

40 Convergys Confidential and Proprietary

Requirement management techniques

41 Convergys Confidential and Proprietary

Requirement management techniques

42 Convergys Confidential and Proprietary

Requirement management metrics

Number of requirements. Status of each requirement. Number of requirement changes. Kind of change. Reason for change. Cost of change. Change Requested by Whom. Functionality of the requirement. Functionality of the software. The preceding 9 metrics will be gathered on an ongoing basis. It therefore will be possible to determine the current value of any of the measurements at any point in time.

Requirement by type Requirement by status Requirement by time Requirement by changes

43 Convergys Confidential and Proprietary

Conclusion and Summary

Requirement management should be given as much weight as requirements development Effective requirements management includes: - General understanding of requirements trouble spots - Configuration management - Traceability - Implementation of key requirement fields This will provide an environment where requirements become a guiding light that helps keep the project on track

44 Convergys Confidential and Proprietary

45 Convergys Confidential and Proprietary