REQUIREMENT ENGINEERING PROCESS

Requirement engineering is a process that involves all the activities required to create and maintain a system requirement document. Requirement engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution, validating the specification and managing the requirements as they are transformed into an operational system. The software engineering process involves the following activities: 1. 2. 3. 4. 5. 6. Feasibility study. Requirements elicitation. Requirement analysis. Documentation or requirement specification. Review of user needs. Management of user s needs.

1. Feasibility study: For every new system, the requirements engineering process should start with a feasibility study. The feasibility study takes into consideration. a. An outline description of the system. b. How the system will be used within an organization. A feasibility study should be in a report format that tells whether or not it is worth carrying on with the requirement engineering and system development process. A feasibility study is a short descriptive study. The aim of the feasibility study is to answer number of questions: y y y Does the overall objectives of the organization are covered contributed by the system. Can the implementation of the system be done using current technology and within the given cost and schedule constraints. Can the system be integrated with the other system which already exists?

Carrying out feasibility involves the following phases: i. Information assessment ii. Information collection iii. Report writing.

i.

Information assessment

The information assessment phase identifies the information which is required to answer the three questions set out above. Once the information has been identified, you should question information sources to discover the answers to these questions. Some instances of possible questions that may be put are as follows: a. How would the organization cope if this system was not implemented? b. What direct contribution will the system make to the business objectives? c. Does the system require technology which has not previously been used in the organization? d. What must be supported by the system and what need not be supported? ii. Information collection: Information may be collected from various sources which may include the managers of department where the system will be used, software engineers who are familiar with the type of system that is proposed, technology experts, and end-users of the system as. They should be interviewed during the feasibility study to collect the required information. Report writing: Once the information is gathered, the feasibility study report is prepared. This should make a recommendation about whether or not the system development should continue. It may propose changes to the scope, budget and schedule of the system and recommends further high-level requirements for the system.

iii.

2. Requirements elicitation: We will look it interviewing, brainstorming, mind mapping, facilitated application specification technique (FAST), Join Application Design (JAD), and use case scenario is viable methods for eliciting M it ware requirements. These, ire some suggested activities and through that are common to all: y Actual users need to be involved in the requirements gathering process rather than surrogates. y All stakeholders should be identified; a representative from each type of stakeholder should be involved in requirements gathering. y Ambiguous requirements should be identified as candidates for prototyping. y Customers and sponsors are not always the users of the delivered application, but they are the entities that pay for the requirements gathering works, as well as for the final system. y Domain constraints that could limit the functionality or performance of the system or software under development should be identified. y Each stakeholder will have a natural bias, including one toward his or her organization.

y y

y y y

Focus groups are not part of the methodology, as they are not composed of decision making individuals. If only software is underdevelopment, the technical environment (e.g., computing architecture, operating system, telecommunication needs) into which the product will be placed must be defined. If the entire system (hardware and software) is under development system requirement must exist before software requirements elicitation should take place. Inputs to the requirements elicitation methods process include a vision statement, high level business objectives for the project, statement of need, feasibility statement, statement of scope, and the project plan. Outputs from the requirements elicitation methods process include a list of prioritized: requirements organized by function, domain constraints, a set of use case scenarios, aid prototypes, if applicable. The rationale for each requirement should be recorded. Use case scenarios and mind mapping may be used alone, or as sub techniques interviewing, brainstorming, FAST, or JAD methods. With the appropriate people present, elicitation methods result in decisions.

After the initial feasibility studies, the next stage of the requirements engineering process is requirements elicitation. Requirement elicitation is an especially critical part of the process. Elicitation can succeed only through an effective customer developer partnership. So, the process of acquiring information/Knowledge about a specific problem domain through various techniques to build the requirements model is called requirements elicitation. In this activity, technical software development staff works with customers and system en users to find out about the application domain, what services the system should provide, the required performance of the system, hardware constraints and so on. Therefore, requirements elicitation requires the collaboration of several groups of participants who have different background. On one hand, customers and users have a solid background in their domain and have a general idea of what the software should do. However they may have little knowledge of software development process. On the other hand developers have experience in developing software but may have little knowledge of everyday requirement of the users. The general techniques that are used in requirement elicitation process are as follows: 1. 2. 3. 4. 5. 6. 7. Interviews Brainstorming Facilitated Application Specification Technique (FAST). Task analysis. Quality function deployment. Form analysis. Delphi technique.

8. User scenario and use case based requirements elicitation.

1. Interviews : Once a problem statement is received from a customer, and then comes the stage, where the meeting with a customer is arranged. Interviews are one of the most popular techniques for understanding the problem domains, and this technique is quite successful. During the meeting or an interview the requirement engineer and customer interaction with each other. Requirement engineer can simple ask the users about their expectation form the system. Requirements engineer must be open minded and should not approach the interview with pre conceived notions about what is required. There are following steps in interviewing. a. Creating the questions: Interviewing begins with the question, or set of question, that will lead to the more knowledge about true requirements (what is really needed, not what is or only through to be needed). There should be some indicators from the original for request for service, the concept exploration documents, and the software project management plan (SPMP) that can be used to create a template of interview questions. b. Select the interviewer: Selected stakeholders will provide the human source for interviews, providing the most relevant and precise information than any other source. Most likely, it will be impossible to interview every stakeholder and representatives must be chosen. They should have known how, accessibility and the potential to credibly and reliable answer your questions. There several groups to consider in the hierarchy of interviewees: Entry level personal because they have not had the opportunity to gain much experience, they will not be able to contribute a great deal. However, they are worry of an interview because of their fresh perspective and the possibility of an unexpected pearl of information. Mid-level stakeholders-based on experience, these stakeholder know the intraction of the operational and/or technical side of the domain and can provide detailed insight. The project lead should always be interviewed. Managers or other special customers CEO s and VPs who are knowledgeable of the domain and the impact of project success are definitely a stakeholder group to be interviewed. The executive sponsor should always be interviewed, if at all possible. Academics- if there are such stakeholders, they can open your eyes to a different perspective.

Typical users of the system this group is perhaps the most important because they will spend more time interacting with the system that anyone else. They may be revolutionary thinkers, which are good, but they may also be biased toward existing system. rising stars if they exist in the organization for which the software is under development, these soon to be leaders in their field may provide cutting edge thinking and information. c. Plan contacts: If time permits, do some research on the source you wish to contact and the perspective the individual has on the project what is his stake as a stakeholder? Everyone is busy, so plan to limit the interview to what he wants to get out of the software consideration of perspective of other stakeholders will occur during brainstorming, FAST; or JAD sessions. The first contact is often by telephone or email. Some guidelines are: y Most people will be able to participate in a more relaxed interview on a Tuesday, Wednesday, or Thursday. They are likely to be less distracted by other work and in a better mood to talk. When calling, remember to use a pleasant tone of voice. Identify yourself clearly. State the purpose of your call or email. State how this stakeholder was chosen to be on the interview list. Confirm that he is the right person to answer questions and that the question may be considered official. Give an estimated length of time for the interview. If available and needed, offer some compensation for travel and time given. Establish a time and place for the meeting, or a time for subsequent communication. Describe the exchange of information and the feedback mechanism.

y y y y y y y y y

d. Conduct the interview: Interviews can be conducted over the phone, in person, or over the internet (video conference, chat, email). However, the best way to perform interviews remains in the direct face to face human encounter. The most important factor for getting information in the interview is in get the right climate, one of comfort and confidence, between you and the interview. 1. Establish the climate. Once an atmosphere of trust and rapport has been established, it is possible to ask some very general and searching questions. The following actions will help in establishing that climate: y Ask for permission to take notes during the interview. y Exhibit a genuine human interest in the person s stake in the software.

y y y y y y y

Listen the best motivator for an interview is your complete attention. Start with smaller stuff and go to more sensitive issues. Be direct and honest. Be modest-nobody wants to talk to a know-it-all . Keep to the subject matter, unless you can tap on a shared experience that will contribute to understanding requirements needs. Ask to see the environment in which the product will be used. Offer future help or part of project report make clear the exchange of information is a two way street.

2. Ask questions: Keep them simple. Questions should be short and contain only one part. Two or three questions rolled into one can lead to compound requirements statements that are difficult to interpret and test. y Are there any problems this system could create? y Are there reasons for wanting to solve this problem that might not be obvious? y At what level of granularity would you like to see it? y Describe the environment in which the system will operate. y In what way will the system change the way you are doing things now? y In what ways will the system help you to be more efficient? y Is either data or functionality shared by other departments or business areas in the organization? y Is there any place rise the solution could be obtained? y What current problems should this system solve? y What data, needed by you, exists in other system? 1. If the interview stalls: Perhaps the interview does not have, nor can have access to, the information you need. Once this is established, thank the person for his or her time and leave a good impression of your visit by leaving a contact number in case that person finds something for you. On the other hand, the interview may not feel like giving you the information. In this case, perhaps emphasizing his or her expertise and its positive impact on the system may get the interview past this hurdle. At times, the interview may need to be redirected by asking precise questions and giving examples of the type of answers needed or analysis required. 2. Close the meeting: Remember to re motivate the person, because you never know could need her help again or when she may volunteer future information. Here are some suggestions:

y y y y y y y y y

Ask if there are questions the interview has for you. Ask if there are other questions that should have been brought up. Leave a future objective, in the form of a future question or point of interest for you. Offer to share the requirement documents and Software Requirements Specifications (SRS). Leave a way to be contacted if more information is forthcoming. Ask if you can contact the interview if you think of another question. Ask if there is someone else that should be interviewed. Ask if there is hard copy or electronic material to be taken and studies. Ask meta-questions about the effectiveness of the process did the questions seem relevant?

Determine where to go from here. Do the following: y y y Contact the source to thank him or her for participating. Document the interview findings. Prepare input for the next step of the process brainstorming, FAST, JAD, or perhaps, go directly to the requirements specification. Interview may be open ended or structured. In open-ended interview, there is no pre-set agenda. Context free questions may be asked to understand the problem and to have an overview of the situation. For example, requirement engineer may ask the following questions: y y y y Who has requested for such software? Who will use the software? Is there any opposition to this project? Who will explain the manual system?

In structural interview, agenda of fairly open question is prepared. Sometimes a proper questionnaire is designed for the interview. Interview may be started with simple questions to set people at ease. After making atmosphere calm, specific questions may be asked to understand the requirements. The customer may be allowed to voice his or her perceptions about a possible solution. 2. Brainstorming: Brainstorming used in many business applications is a group technique to promote creative thinking and can be used during requirements elicitation process to generate new ideas. The group discussions may lead to new idea quickly and help to promote creative thinking. Brainstorming has become very popular and is being used by most of the companies. It promotes creative thinking, generates new ideas and provides platform to share views, getting expectations and difficulties of implementation. All participants are free to say whatever comes to their mind irrespective of their relevance. They are also not criticized for the ideas. The more

requirements that can be identified in the beginning, the better it is for the software development team. It is always easier to select from a long list of ideas or to create a new idea by combining lots of existing ideas. The leader of the session therefore should try to extract maximum ideas from the participants. Every idea will be documented in such a way that everyone can see it. White boards, overhead transparencies or a computer projection system can be used to make it visible to very participant. After a session, a detailed report will be prepared and facilitator will preview the report. Finally a document will be prepared which will have list of requirements and their priority, if possible. Various modern authors have characterized the brainstorming process as: y A part of problem solving that involves the creation of new ideas by suspending judgment. y A technique that maximize the ability to generate new ideas. y A time dedicated to generating a large number of ideas regardless of their initial worth. y Designed to obtain the maximum number of ideas relating to a specific area of interest; y The creation of an optimal state of mind for generating new ideas; y The free association of different ideas to form new ideas and concepts; y Where a group of people can put social inhibitions and rules aside generating new ideas and solutions. Roles for a brainstorming session: There are three roles for participants in a brain storming sessions: leader, scribe and team member. Leader: The leader is also called the facilitator, or moderator. Trained to be a good listener, the leader is responsible for making the brainstorming process an easy one, and the session itself run smoothly. He or she will encourage the participants, ensure proper individual and group behavior and assist the scribe in capturing ideas. Scribble: The scribe will record every idea in such a way that everyone in the room can scribble it. Flip charts and markers white boards, or overhead transparencies work for this and does the projection of a computer screen. Participant: In software development there are usually several stakeholders representing varying point of view. Brainstorming sessions are a wonderful venue for them to learn as empathize with each other s

points of view. The good news is that differing personalizes and vantage points will result in more creativity and a broaded outlook. Rules of leaders y y y y y y y y Allow ideas to be expressed verbally (preferred) or in a written note. Allow silence when appropriate. Collect as many ideas as possible from all participants, with no criticisms or judgments made while ideas are being generated. Communicate the ground rules of the session. Don t allow criticism, discussion, or debate. Don t allow serious or derisive commentary. Encourage wild or exaggerated ideas. Establish the purpose or topic.

Rules for scribes: y y y y y Don t describe an idea in detail-just capture its essence. If necessary, ask for a brief clarification. Use the speaker s own words. Write down each idea as stated, inn short words or phrases. Write ideas so that all participants can see them.

Rule for participants: y y y y y y y y Hitchhike, piggyback, or build, on the ideas of others. Allow you to be in the moment become absorbed by the process and think freely. Assume different personalities. Be creative in contributions. Be open to new, original ideas. Be patient with silence. Be willing to take risks. Build and expand on the ideas of others.

Suggestions for a brainstorming session In addition to roles and rules for a brainstorming session, experience has shown that a number of subtle techniques will add to the chances for success: y y Allow the group to determine the actual length of short breaks, as the freedom to start and stop when they are ready is a relaxing ingredient. Refreshments are helpful. At the opening of the brainstorming session, have a brief warm up on an unrelated but fun topic. This will help set the mood and increase the comfort level of those who have not

y y y

attended such sessions before. When the main session begins, the creative juices will be flowing and an unrestrictive mood will prevail. Be sensitive to the fact that many employees fear making mistakes in their jobs- far of their managers, of losing their job, of demotion, of loss of status- and they are being asked to submit wild ideas that may not work. Creating a safe environment for them is a crucial part of allowing their creativity to surface. If properly set up, the brainstorming session is ideal because all participants have agreed not to judge. Crazy ideas are actually encouraged. Consider the concept of mind mapping to augment brainstorming, as discussed in the next section of this chapter. Don t trust first impressions that may make ideas seem unappealing; consider seeds of ideas. If the flow of ideas seems to be drying up, ask small groups to congregate around different flip charts and discuss the ideas on them. Another technique is to ask each person to write some ideas on a piece of paper and exchange it with someone else to discuss and build upon. List alternatives; stuck thinking doesn t mean stopped thinking.

Preparation for brainstorming As with projects, brainstorming sessions that are planned and prepped will have a much greater chance for success. The following are must do s : y y Identify and invite the participants, the scribe, and the session leader; distribute information about the location, time, place, expected length of session and RSVP-by-date. Identify the specific software system or subsystem to be developed and publicist appropriate documentation (e.g., concept exploration summaries, interview summaries, project plan objectives) to all group members. Define brainstorming and brainstorming session rules and roles for your organization and distribute them to the participants. Ensure the room is properly equipped with comfortable chairs, appropriate shaped or arranged tables, flip charts, white boards, post-its, projected computer monitors, refreshment, and manipulate toys (clay, crayons, kaleidoscope, etc.)

y y

3. Facilitated Application Specification Technique (FAST) This technique was developed specifically for collecting requirements and is similar to brainstorming. The objective of this technique is to bridge the expectation gap a difference between what developers thinks they are supposed to build and what customer think they are going to get. In order to reduce expectation gap, a team oriented appropriate is developed for requirement gathering and is called Facilitated Application Specification Technique (FAST). Similar to brainstorming technique, meeting is conducted at some neutral site which is attended both by developers and customers. The meeting is controlled by a facilitator and an informal agenda is published. Before starting of session, list of objects (interacting with the system, produced by the system and used by the system), functions and constraints is made. This list is presented in the session for discussion. Participants before starting a session also agree not to

debate. After discussion some of the entries from the list are eliminated and new entries are also added to the list. This process is continued till a consensus is reached. The general rules for FAST will seem familiar, as they are similar to those brainstorming: y y y y y y y 1. 2. 3. 4. Conduct the meeting at a neutral site, attended by developers and customers. Establish rules for preparation and participation. Publish an informal agenda. Invite a facilitator to control the meeting. Prepare definition mechanism-worksheets, flip charts, wall stickiest, and so on. Participants should agree not to critique or debate. Share a goal: Identify the problem. Propose element of the solution. Negotiate different approaches. Specify a preliminary set of solution requirements.

Preparation for a FAST session might include: y Making a list of objects that are: 1. Part of the environment that surround the system; 2. Produced by the system; 3. Used by the system. Making a list of services (processes or functions) that manipulate or interact with the objects. Making a list of constraints and performance criteria.

y y

Activities during a FAST session typically include: y y y y Presentation of prepared lists of objects, services, constrains, and performance for discussion (as separate entries so they can be moved, combined, etc.). Consensus on the list, where redundant entries are eliminated, and new ideas are added. Consensus on the list, gained from the participants by the facilitator. Work by teams on mini-specifications, or discrete portions of the known software requirements: 1. Discuss mini-specifications. 2. Identity externally observable data objects; 3. Evaluate the flow and content of information; 4. Define and elaborate software functionality; 5. Understand the software behavior ; 6. Establish interface characteristics; 7. Uncover design constraints. y Maintenance of a parking lot list of issues to be resolved later

y y

Creation of validation criteria Assignments for the next step of drafting the SRS.

4.

Task analysis: In the technique of task analysis, the problem domain is decomposed into hierarchy of tasks and subtasks. The customer approaches a requirement engineer and express his desire of what should a software should contribute to the organization, how the software should work, what services the system should provide and so on. After acquiring all the information from the customer, the requirement engineer, and then breakdown all the requirements in a series of tasks and subtasks in a hierarchical order. For example, the task of ordering food from a Restaurant may include the following subtasks: y Look up the menu y Decide which dishes to eat y Give a call to the restaurant, y Place an order. y Receive an order. y Pay money.

In the above set example the hierarchy of task is maintained as we cannot receive an order before placing it. All the order techniques used for elicitating requirements can also be used to identify tasks/subtasks. Task analysis is an effective technique for elicitating requirements entered with Human computer Interaction (HCL). 5. Quality Function Deployment This is a technique of Quality Management that helps to incorporate the voice of the consumer. The voice is then translated into technical requirements. These technical requirements are documented and result in the software requirements and specification document. These requirements are further translated into design requirements. Customer specification is the prime concern of this technique and thus it emphases and understanding of what is valuable to the customer and then deploys these values throughout the software engineering process. In this technique three types of requirements are identified. 1. Normal requirement In this the objectives and goals of the proposed software are discussed with the customer. If this category of requirement is present, then the customer is satisfied. For example, requirement associates with software that prepares students results that include: entry of marks, calculation of marks, conversion of marks into percentage categorization of scores according to percentage etc. 2. Expected requirements

These are those requirements that are implicit to the software product and may be so obvious that the customer do not feel the need to state them explicitly. In the absence of such requirements customer will be dissatisfied with the software product. Example of such requirements may be: protection from unauthorized access warning system for wrong entry of data. 3. Exciting requirements Some features do beyond the customer s expectations and prove to be very satisfying when present in a software product. Examples of such a requirement may be; an additional copy of important files is maintained and may be accessed by system administrator, sophisticated virus protection system. The QFD method begins with these steps, which clarify the relationship with requirements elicitation: 1. Identify the communities affected by the proposed system, e.g., customer, users and developers. Also identify any initial constraints identified by the customer that affect requirements development. 2. Create high-level requirement from customer input, considering different viewpoints. Requirements are expressions of what the system will do, which has both perceptible and of value to customers. Because the needs or wishes and mostly thought of in customer language, developers often must help in adjusting them to be testable and measurable. 3. Assign a value, indicating a degree of importance rating, to each requirement. The customer determines if the requirement is: very important (5 points) requirements (4 points), not important, but nice to have (3 points), not important (2 points), or unimportant (1 point). Some goals of QED are parallel to the goal for requirements elicitation: y y Both endeavors educate management on the importance of the elicitation phase and the benefit of promoting community action during this phase. Both strive to capture the voice of the customer, allowing subsequent decisions to be traced back to customer needs; the user community s views can be captured through the use of mock us and prototype, as well as brainstorm FAST and JAD. Both promote group work to achieve the common goal of producing quality requirements and sharing ownership in them.

Advantages of using QFD during requirements elicitation include y y y y Cross-functional communication and teamwork result in a more usable product. Prioritized requirements allow high priority items to be undertaken easy, and enhance resources allocation throughout the development cycle. QFD documentation preserves knowledge and promotes reuse, ultimately shortening development time. Customer focused activities lead to increased satisfaction with the product.

6. Form analysis: Form plays an important role in any organist ion and contains lot of meaningful information about data objects of the domain as show in the employee registration form in figure. Employee Registration Form Employee Name Address Position Year of Joining Salary Figure: A Sample Form

Forms are important source of information for modeling the static view or data aspect of the system. For example in the form shown in figure, a number of concepts like Employee Name , Salary , Address can be found and can be used to model entities relationships or attributes in the ER model. 7. Delphi technique: In a Delphi technique session, participants are made to write the requirements. These requirements then exchanged among participants who give their comments to get a revised set of requirements. This process is repeated till a final consumer is reached. 8. User scenario and use case based requirement elicitation: This is a technique for capturing requirements from user s point of view. This technique is based on notion of scenario. According to Loucopoules (95) a scenario is a story that illustrates how a perceived system will satisfy a user s need. Use case scenario, use case and use case diagram are often taken as one but in fact they are different. Use case scenarios are unstructured descriptions of the user requirements. It is a narrative text which describes the sequence of events from user s perspective. Use case diagram are graphical representation to show the system at different levels of abstraction. Use cases are identified and this information is used to draw Use case diagram. These diagrams are supported by activity diagram to show workflow view of activities. Use case model thus developed plays a major role in understanding the requirements of business and has following benefits. y Easily understandable by managers, developers, users etc. y Supports validation and implementation testing. y Supports traceability. y Easily converted into object models.

Describes the existing system developments accurately.

Guidelines for creating use cases: As use cases are developed during requirements elicitation sessions, a few guideline may be helpful: y y y y y y y Allow each use case to tell a story about how the user interacts with the system under development to satisfy a discrete goal (the conceptual dialog). Assign project champions who are actual users for each user class to serve at the primary interface between users and developers. Avoid design strategies at this point, including user interface design. Avoid duplication across use cases. Avoid creating too many use cases too quickly. Don t record data definitions in use cases (data attributes belong in class diagram logical data models and the project data dictionary). Record the following about each use case: 1. A unique ID. 2. A concise name. 3. History the originator, creation data, updater, last update data 4. The actor(s) 5. A brief description 6. Pre-and post-conditions

Benefits of use case The use case model can be a key tool in understanding the requirements of the business, as well as a way of ensuring that everyone who uses the system or works with it can agree on how the model will look. The following list identifies some of the benefits: y Having consistent names for the different use cases facilitates communication and avoids errors caused by different people, or groups of people, thinning they are referring to the same thing when they really mean something different. Use case diagrams can provide a documented model that accurately describes the existing business, as well as the system under development. Use case models are understandable to managers, users and developers, with no need for specialized training. Use cases and scenarios can provide validation as well as implementation testing. Use cases can be used to produce business rules. Use cases define the process by which the customer interacts with the group. Use cases may be easily transformed into object models. Use cases provide traceability for functions. Use cases provide the basic information needed for creating prototypes.

y y y y y y y y

y y

Use cases reduce the occurrence to the orphan funton one that sounds good but is not a direct contributor to the system goals. Use cases show the courses of events that can be performed.