chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxweb viewrequirements...

26
Requirements Elicitation In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering. The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping. Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements. Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements. Guidelines In 1997, Sommerville and Sawyer suggested a set of guidelines for requirements elicitation, to address concerns such as those identified by Christel and Kang: 1. Assess the business and technical feasibility for the proposed system 2. Identify the people who will help specify requirements and understand their organizational bias 3. Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system or product will be placed 4. Identify "domain constraints" (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built 5. Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings) 6. Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the

Upload: trankhanh

Post on 25-Jun-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

Requirements Elicitation

In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering.

The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping.

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.

Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.

Guidelines

In 1997, Sommerville and Sawyer suggested a set of guidelines for requirements elicitation, to address concerns such as those identified by Christel and Kang:

1. Assess the business and technical feasibility for the proposed system 2. Identify the people who will help specify requirements and understand their organizational bias 3. Define the technical environment (e.g., computing architecture, operating system,

telecommunications needs) into which the system or product will be placed 4. Identify "domain constraints" (i.e., characteristics of the business environment specific to the

application domain) that limit the functionality or performance of the system or product to be built 5. Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings) 6. Solicit participation from many people so that requirements are defined from different points of view;

be sure to identify the rationale for each requirement that is recorded 7. Identify ambiguous requirements as candidates for prototyping 8. Create usage scenarios or use cases to help customers/users better identify key requirements

In 2004, Goldsmith suggested a "problem pyramid" of "six steps which must be performed in sequence":

1. Identify the real problem, opportunity or challenge 2. Identify the current measure(s) which show that the problem is real 3. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it 4. Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the

problem directly 5. Define the business "whats" that must be delivered to meet the goal measure(s) 6. Specify a product design how to satisfy the real business requirements

However Goldsmith notes that identifying the real problem "is exceedingly difficult".

Page 2: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

Stakeholder Analysis (Understanding Stakeholders' Needs)

Stakeholder analysis in conflict resolution, project management, and business administration, is the process of identifying the individuals or groups that are likely to affect or be affected by a proposed action, and sorting them according to their impact on the action and the impact the action will have on them. This information is used to assess how the interests of those stakeholders should be addressed in a project plan, policy, program, or other action. Stakeholder analysis is a key part of stakeholder management.

Stakeholder analysis is a term that refers to the action of analyzing the attitudes of stakeholders towards something (most frequently a project). It is frequently used during the preparation phase of a project to assess the attitudes of the stakeholders regarding the potential changes. Stakeholder analysis can be done once or on a regular basis to track changes in stakeholder attitudes over time.

A stakeholder is any person or organization, who can be positively or negatively impacted by, or cause an impact on the actions of a company, government, or organization. Types of stakeholders are:

1. Primary stakeholders: are those ultimately affected, either positively or negatively by an organization's actions.

2. Secondary stakeholders: are the ‘intermediaries’, that is, persons or organizations who are indirectly affected by an organization's actions.

3. Key stakeholders: (who can also belong to the first two groups) have significant influence upon or importance within an organization.

Therefore, stakeholder analysis has the goal of developing cooperation between the stakeholder and the project team and, ultimately, assuring successful outcomes for the project. Stakeholder analysis is performed when there is a need to clarify the consequences of envisaged changes, or at the start of new projects and in connection with organizational changes generally. It is important to identify all stakeholders for the purpose of identifying their success criteria and turning these into quality goals. (Rodi et al., 2012)

Methods of Stakeholder Mapping

The following list identifies some of the best known and most commonly used methods for stakeholder mapping:

1. (Mitchell, Agle et al. 1997) proposed a classification of stakeholders based on power to influence, the legitimacy of each stakeholder’s relationship with the organization, and the urgency of the stakeholder’s claim on the organization. The results of this classification may assess the fundamental question of "which groups are stakeholders deserving or requiring manager’s attention, and which are not?" This is salience - "the degree to which managers give priority to competing stakeholder claims" (Mitchell, Agle et al., 1997:854)

2. (Fletcher, Guthrie et al. 2003) defined a process for mapping stakeholder expectations based on value hierarchies and Key Performance Areas (KPA),

3. (Cameron, Crawley et al. 2010) defined a process for ranking stakeholders based on needs and the relative importance of stakeholders to others in the network.

4. (Savage, Nix et al. 1991) offer a way to classify stakeholders according to potential for threat and potential for cooperation.

Page 3: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

5. (Turner, Kristoffer and Thurloway, 2002) have developed a process of identification, assessment of awareness, support, influence leading to strategies for communication and assessing stakeholder satisfaction, and who is aware or ignorant and whether their attitude is supportive or opposing.

Mapping techniques include the following sub-set of results from a Web search of analysis techniques being used by aid agencies, governments or consultant groups:

1. Influence-interest grid (Imperial College London) 2. Power-impact grid (Office of Government Commerce UK 2003) 3. Mendelow's Power-interest grid (Aubrey L. Mendelow, Kent State University, Ohio 1991)

Low Highinterest interest

Low A BpowerHigh C Dpower

4. Three-dimensional grouping of power, interest and attitude (Murray-Webster and Simon 2005) 5. The Stakeholder Circle (Bourne 2007)

The first step in building any stakeholder map is to develop a categorized list of the members of the stakeholder community. Once the list is reasonably complete it is then possible to assign priorities in some way, and then to translate the ‘highest priority’ stakeholders into a table or a picture. The potential list of stakeholders for any project will always exceed both the time available for analysis and the capability of the mapping tool to sensibly display the results, the challenge is to focus on the ‘right stakeholders’ who are currently important and to use the tool to visualize this critical sub-set of the total community.

The most common presentation styles use a matrix to represent two dimensions of interest with frequently a third dimension shown by the color or size of the symbol representing the individual stakeholders.

Some of the commonly used ‘dimensions’ include:

1. Power (high, medium, low) 2. Support (positive, neutral, negative) 3. Influence (high or low) 4. Need (strong, medium, weak)

Other Forms of Stakeholder Analysis

A more recent form of Stakeholder Analysis can be seen in Triple Task Method. An approach which seeks to blend three disciplines: psychoanalytic theory, systems analysis and action research.

Benefits

Stakeholder analysis helps with the identification of the following:

1. Stakeholders' interests 2. Mechanisms to influence other stakeholders 3. Potential risks 4. Key people to be informed about the project during the execution phase

Page 4: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

5. Negative stakeholders as well as their adverse effects on the project

Interview

An interview is a conversation between two or more people where questions are asked by the interviewer to elicit facts or statements from the interviewee. Interviews are a standard part of journalism and media reporting, but are also employed in many other situations, including qualitative research.

Interview as a Method for Qualitative Research

Interviewing, when considered as a method for conducting qualitative research, is a technique used to understand the experiences of others.[1] Interviewing differs from other methods of data collection in that it is often more exploratory in nature, and allows for more flexibility. Interviewing stems from the desire to know more about the people around us and to better understand how the people around us view the world we live in: “At the heart of interviewing research is an interest in other individuals’ stories because they are of worth.

Technique

When choosing to interview as a method for conducting qualitative research, it is important to be tactful and sensitive in your approach. Interviewer and researcher, Irving Seidman, devotes an entire chapter of his book, Interviewing as Qualitative Research, to the import of proper interviewing technique and interviewer etiquette. Some of the fundamentals of his technique are summarized below:

1. Listening: According to Seidman, this is both the hardest as well as the most important skill in interviewing. Furthermore, interviewers must be prepared to listen on three different levels: they must listen to what the participant is actually saying, they must listen to the “inner voice” or subtext of what the participant is communicating, and they must also listen to the process and flow of the interview so as to remain aware of how tired or bored the participant is as well as logistics such as how much time has already passed and how many questions still remain. The listening skills required in an interview require more focus and attention to detail than what is typical in normal conversation. Therefore it is often helpful for interviewers to take notes while the participant responds to questions or to tape-record the interviews themselves to as to be able to more accurately transcribe them later.

2. Ask questions (to follow up and to clarify): While an interviewer generally enters each interview with a predetermined, standardized set of questions, it is important that they also ask follow-up questions throughout the process. Such questions might encourage a participant to elaborate upon something poignant that they’ve shared and are important in acquiring a more comprehensive understanding of the subject matter. Additionally, it is important that an interviewer ask clarifying questions when they are confused. If the narrative, details, or chronology of a participant’s responses become unclear, it is often appropriate for the interviewer to ask them to re-explain these aspects of their story so as to keep their transcriptions accurate.

3. Be respectful of boundaries: Seidman explains this tactic as “Explore, don’t probe,” It is essential that while the participant is being interviewed they are being encouraged to explore their experiences in a manner that is sensitive and respectful. They should not be “probed” in such a way that makes them feel uncomfortable or like a specimen in lab. If too much time is spent dwelling on minute details or if too many follow-up questions are asked, it is possible that the participant will become defensive or

Page 5: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

unwilling to share. Thus, it is the interviewer’s job to strike a balance between ambiguity and specificity in their question asking.

4. Be wary of leading questions: Leading questions are questions which suggest or imply an answer. While they are often asked innocently they run the risk of altering the validity of the responses obtained as they discourage participants from using their own language to express their sentiments. Thus it is preferable that interviewers ask open-ended questions instead. For example, instead of asking “Did the experience make you feel sad?” - Which is leading in nature - it would be better to ask “How did the experience make you feel” - as this suggests no expectation.

5. Don’t interrupt: Participants should feel comfortable and respected throughout the entire interview - thus interviewers should avoid interrupting participants whenever possible. While participants may digress in their responses and while the interviewer may lose interest in what they are saying at one point or another it is critical that they be tactful in their efforts to keep the participant on track and to return to the subject matter in question.

6. Make the participant feel comfortable: Interviewing proposes an unusual dynamic in that it often requires the participant to divulge personal or emotional information in the presence of a complete stranger. Thus, many interviewers find it helpful to ask the participant to address them as if they were “someone else,” such as a close friend or family member. This is often an effective method for tuning into the aforementioned “inner voice” of the participant and breaking down the more presentational barriers of the guarded “outer voice” which often prevails.

Types of Interviews

1. Informal, conversational interview: No predetermined questions are asked, in order to remain as open and adaptable as possible to the interviewee’s nature and priorities; during the interview the interviewer “goes with the flow”.

2. General interview guide approach: Intended to ensure that the same general areas of information are collected from each interviewee; this provides more focus than the conversational approach, but still allows a degree of freedom and adaptability in getting the information from the interviewee.

3. Standardized, open-ended interview: The same open-ended questions are asked to all interviewees; this approach facilitates faster interviews that can be more easily analyzed and compared.

4. Closed, fixed-response interview: All interviewees are asked the same questions and asked to choose answers from among the same set of alternatives. This format is useful for those not practiced in interviewing.

Questionnaire

A questionnaire is a research instrument consisting of a series of questions and other prompts for the purpose of gathering information from respondents. Although they are often designed for statistical analysis of the responses, this is not always the case. The questionnaire was invented by Sir Francis Galton.

Questionnaires have advantages over some other types of surveys in that they are cheap, do not require as much effort from the questioner as verbal or telephone surveys, and often have standardized answers that make it simple to compile data. However, such standardized answers may frustrate users. Questionnaires are also sharply limited by the fact that respondents must be able to read the questions and respond to them. Thus, for some demographic groups conducting a survey by questionnaire may not be practical.

As a type of survey, questionnaires also have many of the same problems relating to question construction and wording that exist in other types of opinion polls.

Page 6: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

Basic Rules for Questionnaire Item Construction

1. Use statements which are interpreted in the same way by members of different subpopulations of the population of interest.

2. Use statements where persons that have different opinions or traits will give different answers. 3. Think of having an "open" answer category after a list of possible answers. 4. Use only one aspect of the construct you are interested in per item. 5. Use positive statements and avoid negatives or double negatives. 6. Do not make assumptions about the respondent. 7. Use clear and comprehensible wording, easily understandable for all educational levels 8. Use correct spelling, grammar and punctuation. 9. Avoid items that contain more than one question per item (e.g. Do you like strawberries

and potatoes?).

Questionnaire Administration Modes

Main modes of questionnaire administration are:

1. Face-to-face questionnaire administration, where an interviewer presents the items orally. 2. Paper-and-pencil questionnaire administration, where the items are presented on paper. 3. Computerized questionnaire administration, where the items are presented on the computer. 4. Adaptive computerized questionnaire administration, where a selection of items is presented on the

computer, and based on the answers on those items, the computer selects following items optimized for the candidate’s estimated ability or trait.

Workshops

Requirements Elicitation Workshops are one of several techniques used to define and develop requirements. Workshops are ideal when disparate stakeholder groups are involved with the project. Sessions are led by a skilled facilitator and attended by representatives and subject matter experts from each stakeholder group who meet to discuss and agree on a set of project requirements.

1. Define Project Scope And Objectives a. Identify and meet with sponsor, decision makers and customers to gain insight into

critical business needs, desired outcomes and constraints. b. Identify pre-existing commitments that may impact project outcomes.

2. Analyze Potential Requirement Sources a. Review legacy system documentation, data models, policies and regulations. b. Review historical data that may provide knowledge into the projects desired state.

3. Identify And Engage Stakeholders a. Identify and obtain commitment from stakeholders; seek managerial approval as necessary. b. Communicate goals, expected outcomes, time commitment and required actions. c. Identify and consider underlying concerns.

4. Prepare For Workshop Sessions a. Preparation includes workshop agenda, sign-in sheet, interview questionnaire and job-aids for

capturing requirements. b. Distribute relevant materials to group as read-ahead.

5. Conduct Workshop Sessions a. Introduce requirements gathering technique.

Page 7: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

b. Discuss objectives, scope, constraints and risks. c. Use job-aids to capture information related to system, user roles, data, and interfaces.

Brainstorming

Brainstorming is a group or individual creativity technique by which efforts are made to find a conclusion for a specific problem by gathering a list of ideas spontaneously contributed by its member(s). The term was popularized by Alex Faickney Osborn in the 1953 book Applied Imagination. Osborn claimed that brainstorming was more effective than individuals working alone in generating ideas, although more recent research has questioned this conclusion. Today, the term is used as a catch all for all group ideation sessions.

Types of Brainstorming

1. Nominal Group Technique

Main article: nominal group technique

Participants are asked to write their ideas anonymously. Then the facilitator collects the ideas and the group votes on each idea. The vote can be as simple as a show of hands in favor of a given idea. This process is called distillation.

After distillation, the top ranked ideas may be sent back to the group or to subgroups for further brainstorming. For example, one group may work on the color required in a product. Another group may work on the size, and so forth. Each group will come back to the whole group for ranking the listed ideas. Sometimes ideas that were previously dropped may be brought forward again once the group has re-evaluated the ideas.

It is important that the facilitator be trained in this process before attempting to facilitate this technique. The group should be primed and encouraged to embrace the process. Like all team efforts, it may take a few practice sessions to train the team in the method before tackling the important ideas.

2. Group Passing Technique

Each person in a circular group writes down one idea, and then passes the piece of paper to the next person, who adds some thoughts. This continues until everybody gets his or her original piece of paper back. By this time, it is likely that the group will have extensively elaborated on each idea.

The group may also create an "idea book" and post a distribution list or routing slip to the front of the book. On the first page is a description of the problem. The first person to receive the book lists his or her ideas and then routes the book to the next person on the distribution list. The second person can log new ideas or add to the ideas of the previous person. This continues until the distribution list is exhausted. A follow-up "read out" meeting is then held to discuss the ideas logged in the book. This technique takes longer, but it allows individuals time to think deeply about the problem.

3. Team Idea Mapping Method

This method of brainstorming works by the method of association. It may improve collaboration and increase the quantity of ideas, and is designed so that all attendees participate and no ideas are rejected.

The process begins with a well-defined topic. Each participant brainstorms individually, then all the ideas are merged onto one large idea map. During this consolidation phase, participants may discover a common

Page 8: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

understanding of the issues as they share the meanings behind their ideas. During this sharing, new ideas may arise by the association, and they are added to the map as well. Once all the ideas are captured, the group can prioritize and/or take action.

4. Electronic Brainstorming

This is a computerized version of the manual brainstorming technique typically supported by an electronic meeting system (EMS) but simpler forms can also be done via email and may be browser based, or use peer-to-peer software.

With an electronic meeting system, participants share a list of ideas over a network. Ideas are entered independently. Contributions become immediately visible to all and are typically anonymized to encourage openness and reduce personal prejudice. Modern EMS also support asynchronous brainstorming sessions over extended periods of time as well as typical follow-up activities in the creative problem solving process such as categorization of ideas, elimination of duplicates, assessment and discussion of prioritized or controversial ideas.

Proponents such as Gallupe et al. argue that electronic brainstorming eliminates many of the problems of standard brainstorming, including production blocking (i.e. group members must take turns to express their ideas) and evaluation apprehension (i.e. fear of being judged by others). This positive effect increases with larger groups. A perceived advantage of this format is that all ideas can be archived electronically in their original form, and then retrieved later for further thought and discussion. Electronic brainstorming also enables much larger groups to brainstorm on a topic than would normally be productive in a traditional brainstorming session.

When exposed to others’ ideas, attention is focused by the group member on these ideas and this attention has been proposed to cognitively stimulate the brainstormer Therefore, the individual members of the brainstorming group perform better during the session because people see everyone else’s ideas on the computer screen (via chat room or e-mail), explaining the positive effects of EBS. Additionally, during an EBS session, participants have control over their activity and can attend to the ideas of others while also creating their own, continually exposing participants to a flow of ideas. EBS techniques have been shown to produce more ideas and help individuals focus their attention on the ideas of others better than a brainwriting technique (participants write individual written notes in silence and then subsequently communicate them with the group) The production of more ideas has been linked to the fact that paying attention to others’ ideas leads to non-redundancy, as one will try to avoid to replicate or repeat another participant’s comment or idea.

The fact that individuals are not physically visible has also been shown to be an important component to the superiority of EBS over other methods, such as brainwriting. Due to the fact that participants are not typically in a room with the group, social cues such as facial expression and verbal language are not available, and therefore, attention is paid to the task at hand and the ideas rather than the people involved.

Some web-based brainstorming techniques allow contributors to post their comments anonymously through the use of avatars. This technique also allows users to log on over an extended time period, typically one or two weeks, to allow participants some "soak time" before posting their ideas and feedback. This technique has been used particularly in the field of new product development, but can be applied in any number of areas requiring collection and evaluation of ideas.

Page 9: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

Some limitations of EBS include the fact that it can flood people with too many ideas at one time that they have to attend to, and people may also compare their performance to others by analyzing how many ideas each individual produces (social matching).

5. Directed Brainstorming

Directed brainstorming is a variation of electronic brainstorming (described above). It can be done manually or with computers. Directed brainstorming works when the solution space (that is, the set of criteria for evaluating a good idea) is known prior to the session. If known, those criteria can be used to constrain the Ideation process intentionally.

In directed brainstorming, each participant is given one sheet of paper (or electronic form) and told the brainstorming question. They are asked to produce one response and stop, then all of the papers (or forms) are randomly swapped among the participants. The participants are asked to look at the idea they received and to create a new idea that improves on that idea based on the initial criteria. The forms are then swapped again and respondents are asked to improve upon the ideas, and the process is repeated for three or more rounds.

In the laboratory, directed brainstorming has been found to almost triple the productivity of groups over electronic brainstorming.

6. Guided Brainstorming

A guided brainstorming session is time set aside to brainstorm either individually or as a collective group about a particular subject under the constraints of perspective and time. This type of brainstorming removes all cause for conflict and constrains conversations while stimulating critical and creative thinking in an engaging, balanced environment. Innovative ideas consistently emerge.

Participants are asked to adopt different mindsets for pre-defined period of time while contributing their ideas to a central mind map drawn by a pre-appointed scribe. Having examined a multi-perspective point of view, participants seemingly see the simple solutions that collectively create greater growth. Action is assigned individually.

Following a guided brainstorming session participants emerge with ideas ranked for further brainstorming, research and questions remaining unanswered and a prioritized, assigned, actionable list that leaves everyone with a clear understanding of what needs to happen next and the ability to visualize the combined future focus and greater goals of the group.

7. Individual Brainstorming

"Individual brainstorming" is the use of brainstorming in solitary. It typically includes such techniques as free writing, free speaking, word association, and drawing a mind map, which is a visual note taking technique in which people diagram their thoughts. Individual brainstorming is a useful method in creative writing and has been shown to be superior to traditional group brainstorming.

Research has shown individual brainstorming to be more effective in idea-generation than group brainstorming.

8. Question Brainstorming

This process involves brainstorming the questions, rather than trying to come up with immediate answers and short term solutions. Theoretically, this technique should not inhibit participation as there is no need to

Page 10: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

provide solutions. The answers to the questions form the framework for constructing future action plans. Once the list of questions is set, it may be necessary to prioritize them to reach to the best solution in an orderly way.

"Questorming" is another term for this mode of inquiry.

Software Prototyping

Software prototyping refers to the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

A prototype typically simulates only a few aspects of, and may be completely different from, the final product.

Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development and debate since its proposal in the early 1970s.

Steps Of The Prototyping Process

The process of prototyping involves the following steps

1. Identify basic requirements: Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.

2. Develop Initial Prototype: The initial prototype is developed that includes only user interfaces. (See Horizontal Prototype, below)

3. Review: The customers, including end-users, examine the prototype and provide feedback on additions or changes.

4. Revise and Enhance the Prototype: Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps #3 and #4 may be needed.

Types of Prototyping

Software prototyping has many variants. However, all the methods are in some way based on two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.

1. Throwaway prototyping

Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved,

Page 11: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.

The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.

Strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.

…it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models.

Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a GUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality.

Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of storyboards, animatics or drawings. These are non-functional implementations but show how the system will look.

SUMMARY:-In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are:

Write preliminary requirements Design the prototype User experiences/uses the prototype, specifies new requirements Repeat if necessary Write the final requirements Develop the real products

2. Evolutionary prototyping

Evolutionary Prototyping (also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built.

When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.

Page 12: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

"…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."

This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase.

For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changes…we often try to define a system using our most familiar frame of reference---where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.[9]

Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.

"It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version…The user may decide that a 'flawed' system is better than no system at all."

In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.

To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.[

3. Incremental prototyping

The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.

4. Extreme prototyping

Extreme Prototyping as a development process is used especially for developing web applications. Basically, it breaks down web development into three phases, each one based on the preceding one. The first phase is a static prototype that consists mainly of HTML pages. In the second phase, the screens are programmed and fully functional using a simulated services layer. In the third phase, the services are implemented. The process is called Extreme Prototyping to draw attention to the second phase of the process, where a fully functional UI is developed with very little regard to the services other than their contract.

Documenting Stakeholders' Needs

This involves doing research to determine:

1. The key stakeholders associated with the project 2. The needs of the key stakeholders

At the conclusion of this process an agreement about the real requirements of the project has to be reached.

Identification Of The Stakeholders

Page 13: chettinadtech.ac.inchettinadtech.ac.in/...11/...47-2633-punithacse.docxWeb viewRequirements Elicitation. In requirements engineering, requirements elicitation is the practice of collecting

If all of the relevant stakeholders are not identified at the beginning, the success of the project/phase can be placed in jeopardy.

You must identify who the project is being done for, who will be affected, what they want or expect and their actual needs.

Care needs to be taken in this identification process. Someone who is initially considered irrelevant to the project can suddenly become important to it. The quiet, little person in the corner can often end up being the most important stakeholder!

Some Definitions:

1. The sponsor pays the bills or authorises the expenditure 2. The end-users use the product of the project 3. The champion paves the way and must be keep informed and interested

Prioritizing Stakeholders

You must determine the primary or key stakeholders for the project. They can be interested in the outcomes of the project or, alternatively might cause problems along the way.

Key decision makers will attract priority in having their needs and expectations met and it is important to be aware of unstated agendas within this group.

Analyzing the Needs Of Stakeholders And Clients

The client's needs, and those of the key stakeholders, should be fully understood.

Sometimes stakeholders will have conflicting needs that must be resolved before the project can proceed.

One of the purposes of the stakeholder analysis is to separate "needs" from "wants". Ask the question "what will make this project successful for you".

Documentation:

Clear and accurate documentation is critical to the process.

It is important that the needs are documented in the terminology of the key stakeholders so that no ambiguity can exist and a meaningful agreement can be achieved. In the analysis, the client's needs should be reviewed, constraints should be identified, the determined needs should be realistic, the findings should be documented and, most importantly, approval from the key stakeholders should be obtained in writing.

The project manager must identify and resolve the needs of key stakeholders and make sure that needs are managed throughout the project.

Often new stakeholders appear during the project. Keep an eye out for them.