4. Tips and Techniques

Use Cases Way of Documentation

• Use Case Requirements Modeling is one of the first steps in an Object Oriented approach to systems development. Independent of the subsequent analysis and design methodology used, Use Cases provide a superior method for communicating the business functionality to be developed.
• Traditional thinking maintains requirements describe the "what" is required, whereas subsequent development steps translate from the "what" to the "how".
• Use Cases describe requirements for a developer’s translation; from a function but not usage point of view. They lack the ability to portray the business needs from a behavioral or user perspective.
• Behavioral modeling techniques and tools are now available and sufficiently mature that can bridge this gap between function and behavior. One such behavioral approach models requirements in terms of states and transitions between states. Use Case requirements can now be extended with behavioral modeling to add context and organization. A sort of middleware between the What and the How.

Use Case Scenario Components

• Primary Actor - role providing a stimulus
• Description - brief overview from requirements
• Pre conditions - entry state
• Post conditions - exit state
• Activities - description of transaction in time sequence
• Exceptions - any deviation from the expected transaction flow
  

What Use Cases Lack?

• Sequence and flow of operations. Although Use Case diagrams can illustrate some of the relationships between individual Use Cases, they do not convey sequence and flow of related operational usage. In a large model detailing to this level of behavior becomes increasingly difficult. Besides requirements traceability this is one of the biggest benefits of behavioral modeling. It gives the engineer an opportunity to describe requirements from a usage standpoint.
• Frequency and arrival rate information of individual Use Cases. Such information can be used for performance engineering of a system and help define load test scenarios. This type of information is easily portrayed in a state transition model, not so easily captured with Use Cases. Once sequence and flow is effectively modeled annotating frequency information can enhance the graphical representation. This information can be valuable for performance and load testing
• Use cases often describe only best case (successful completion of operation) and limited exception information. Visualizing and modeling many exception conditions can be a large task. This is more easily undertaken using state machine techniques.
• How the system's) are used, or could be used. An improved process can be realized if the actual requirements are separated from the discrete descriptions of individual use cases. Following paths through a behavioral model has proven to be a very effective approach to understanding how requirements might be used with in a "System" framework. This modeling gives the engineers a chance to further nail-down requirements and how they behave.

Document Analysis

• Review of existing documents
  Business plans
  Market studies
  Contracts
  Requests for proposals (RFP)
  Statements of work (SOW)
  Existing guidelines
  Analyses of existing systems and procedures
• Provides clue about existing “as-is” system
• Look for user addition to forms
• Look for unused form elements
  

Questionnaire

Questionnaire Approach

• Selecting participants - Using samples of the population
• Designing the questionnaire - Careful question selection
• Administering the questionnaire - Working to get good response rate
• Questionnaire follow-up - Send results to participants

Good Questionnaire design

• Begin with non-threatening and interesting questions
• Group items into logically coherent sections
• Do not put important items at the very end of the questionnaire
• Do not crowd a page with too many items
• Avoid abbreviations
• Avoid biased or suggestive items or terms
• Number questions to avoid confusion
• Pretest the questionnaire to identify confusing questions
• Provide anonymity to respondents
  

Role Playing

One of the great ways of changing the way you see the world is to see it from someone else's point of view. This technique allows you to change your perspective by getting you to role play a different person and see how they would approach the problem. Different people use different bits of information and knowledge to approach the same problem and it's extremely helpful to view a task from different angles.

The objective of a role paying exercise is to

• How would they think?
• What objects and items would they be using?
• Where would they be doing it?
• How would they see the problem?
• What action would they take?
• How would they explain the problem?
• How would they solve the problem?
  

Prototyping

Prototyping is a technique for building a quick and rough version of a desired system or parts of that system. The prototype illustrates the capabilities of the system to users and designers. It serves as a communications mechanism to allow reviewers to understand interactions with the system.

Prototypes are useful for the following reasons

• The customer may be more likely to view the prototype and react to it than to read the SRS and react to it. Thus, the prototype provides quick feedback.
• The prototype displays unanticipated aspects of the systems behavior. Thus, it produces not only answers but also new questions. This helps reach closure on the SRS.
• An SRS based on a prototype tends to undergo less change during development, thus shortening development time.

A prototype should be used as a way to elicit software requirements. Some characteristics such as screen or report formats can be extracted directly from the prototype. Other requirements can be inferred by running experiments with the prototype.

Prototyping Tips

• Work with the real users. The best people to get involved in prototyping are the ones who will actually use the application when it is done. These are the people who have the most to gain from a successful implementation; these are the people who know their own needs best.
• Get your stakeholders to work with the prototype. Just as if you want to take a car for a test drive before you buy it, your users should be able to take an application for a test drive before it is developed. Furthermore, by working with the prototype hands-on, they can quickly determine whether the system will meet their needs.
• Understand the underlying business. You need to understand the underlying business before you can develop a prototype that will support it. In other words, you need to base your UI prototype on your requirements. The more you know about the business, the more likely it is you can build a prototype that supports it.
• You should only prototype features that you can actually build. Christmas wish lists are for kids. If you cannot possibly deliver the functionality, do not prototype it.
• Get an interface expert to help you design it. User interface experts understand how to develop easy-to-use interfaces, whereas you probably do not. A general rule of thumb is, if you have never taken a course in human factors, you probably should not be leading a UI prototyping effort.
• Explain what a prototype is. The biggest complaint developers have about UI prototyping is their users say “That’s great. Install it this afternoon.” This happens because users do not realize more work is left to do on the system. The reason this happens is simple: From your user's point-of-view, a fully functional application is a bunch of screens and reports tied together by a menu. Unfortunately, this is exactly what a prototype looks like. To avoid this problem, point out that your prototype is like a Styrofoam model that architects build to describe the design of a house. Nobody would expect to live in a Styrofoam model, so why would anyone expect to use a system prototype to get his job done?
• Consistency is critical. Inconsistent user interfaces lead to less usable software, more programming, and greater support and training costs.
• Avoid implementation decisions as long as possible. Be careful about how you name these user interface items in your requirements documents. Strive to keep the names generic, so you do not imply too much about the implementation technology.
  

Interview

The interview is the primary technique for information gathering during the systems analysis phases of a development project. It is a skill which must be mastered by every analyst. The interviewing skills of the analyst determine what information is gathered, and the quality and depth of that information. Interviewing, observation, and research are the primary tools of the analyst.

Goal of Interview

• Gather information on the company
• Gather information on the function
• Gather information on processes or activities
• Uncover problems
• Conduct a needs determination
• Verification of previously gathered facts
• Gather opinions or viewpoints
• Provide information
• Obtain leads for further interviews

An interview can be conducted at various times within the process for

• Initial introduction
• Familiarization or background
• Fact gathering
• Verification of information gathered elsewhere
• Confirmation of information gathered from the interviewee
• Follow-up, amplification, and clarification
  

Interviewing Tips

• Define the purpose and boundary of the interview so that discussion can happen in a controlled manner
• Be prepared by doing your homework on subject of discussion and be ready with your queries
• Schedule meeting with clear time limits
• Send some warm up material before the start of discussion
• Keep your discussion focused based on the role they play e.g. a clerk and a manger will view system differently
• No emails or ringing phones. Getting time out of business user is very difficult, try to leverage as much as possible
• Discussion should be carried out with people who have extensive hands on experience on the subject
• Use pen and paper as much as possible to draw models, sketches to confirm your understanding
• Don’t divert from the subject. Business users have this habit of getting swayed quiet often
• Keep your language as non-technical as possible (e.g. For a business user a database can mean MS Word document)
• Be a good listener while conducting the interview sessions
• Take down notes while the discussion is happening
• Illustrate the relevance of interview by highlighting something significant which you have learnt
• Thank the interviewee for his time and co-operation
  

Do’s & Don'ts of Interviewing

The rules of interviewing are similar to the rules which govern most human interactions and to the rules which govern most investigative and problem-solving processes. In effect they can be called the rules of the game.

• Do not assume anything.
• Do not form pre-judgments.
• Do ask questions which start with who, what, where, when, why, and how, where possible.
• Do ask both open and closed questions.
• Do verify understanding through probing and confirming questions.
• Do avoid confrontation.
• Do act in a friendly but professional manner.
• Do not interrupt.
• Do listen actively.
• Do take notes, but do not be obtrusive about it.
• Do let the interviewee do most of the talking
• Do establish rapport early and maintain it.
• Do maintain control over the subject matter.
• Do not go off on tangents.
• Do establish a time frame for the interview and stick to it.
• Do conclude positively.
• Do allow for follow-up or clarification interviews later on.
• Do be polite and courteous
  

Brainstorming

“Brainstorming involves both idea generation and idea reduction. The goal of the former is to identify as many ideas as possible, while the latter ranks the ideas into those considered most useful by the group. Brainstorming is a powerful technique because the most creative or effective ideas often result from combining seemingly unrelated ideas. Also, this technique encourages original thinking and unusual ideas”

• Idea generation & idea reduction
• Typically via group meetings
• Generation Best practices
  Minimize criticism and debate
  Editing occurs at end of meeting or later
  Aim for quantity
  Mutate or combine ideas
• Reduction best practices
  Voting with a threshold (N votes/person)
  Blending ideas
  uApplying criteria
  Scoring with a weighting formula
  

Brainstorming Tips

Some key rules which needs to be adhered while conducting a brainstorming session

• Write a clear and focused objective. If the focus statement is too ambiguous, too general, people won’t know where to start. Print the statement as large as possible and stick it to a place from where everyone can see it
• Select participants for the team. The team leader will be the person who will write the focus statement and initiate the session. Two or three people should be familiar with the project. Also invite people who will be part of end user. Pick smart and imaginative people. Don’t exceed more than 7 people.
• The session location should ideally be away from office without interruption and noises. Get markers, large sheets, tapes, board pins, toys etc.
• There are no dumb ideas. Period. It's a brainstorming session, not a serious matter that requires only serious solutions. Remember, this is one of the more fun tools of the quality, so keep the entire team involved
• Don't criticize other people's ideas. This isn't a debate, discussion or forum for one person to display superiority over another
• Build on other people's ideas. Often an idea suggested by one person can trigger a bigger and/or better idea by another person. Or a variation of an idea on the board could be the next 'velcro' idea. It is this building of ideas that leads to out of the box thinking and fantastic ideas.
• Reverse the thought of 'quality over quantity.' Here we want quantity; the more creative ideas the better. As a facilitator, you can even make it a challenge to come up with as many ideas as possible and compare this team's performance to the last brainstorming session you conducted.
  

Requirements Workshop Tips

“Requirements workshops are a powerful technique for eliciting requirements because they can be designed to encourage consensus concerning the requirements of a particular capability. They are best facilitated by an outside expert and are typically short (one or a few days). Other advantages are often achieved -- participant commitment to the work products and project success, teamwork, resolution of political issues, and reaching consensus on a host of topics. ”

Benefits of Requirements Workshops

• Workshop costs are often lower than are those for multiple interviews.
• They help to give structure to the requirements capture and analysis process.
• They are dynamic, interactive, and cooperative.
• They involve users and cut across organizational boundaries.
• They help to identify and prioritize needs and resolve contentious issues.
• When properly run, they help to manage user's expectations and attitude toward change
  

Requirements Workshop Checklist

Checklist should consist of following items

• General information (Title, Place and Time)
  The workshop name and title should be short and novel like “workshop on order entry”. The duration of workshop should be half or one day. Don’t make it for an hour as it will become ‘conversation’
• Purpose
  The purpose is important to inform the workshop participants correctly up front, so that they have no wrong expectations, or at least make the chance on that a little smaller.
• Scope
  The purpose will place the workshop within the context of the project, the scope tells us all about the actual content, e.g. "order entry for 24 hour delivery". The scope should determine the field that will be covered, including a good definition of it's borders. "How a new information system will have to support our order entry activities for 24 hour deliveries. Current activities may be subject to change.
• Subjects
  To create a good list of subjects to cover, some homework has to be done. A good preparation would be joining stakeholders in their work for a short time. In addition to this, you should talk with someone with knowledge about the scope.
• Controversy
  Avoid getting into internal political dynamics of customer and their related subject areas
• Strategy
  Given the controversies and the list of subjects you put on the form in the previous steps, you should determine how to handle things, how to approach the subjects strategically. If people don't want to be concerned with the project in the first place, they can frustrate the process of conducting the workshop. If they are out to sabotage and are not into the win-win mood, you will not get them. Not during the workshop. You can handle them later on. Be pragmatic, you also need an end result, so don't let them block your workshop.
• Result
  What will be there when the workshop is over? The requirements of the end result can be written down as a story, as a formal specification in some cryptic scientific notation, or some cool graphics.
• Participants
  To close your preparation, you can specify the participants of the workshop. Who are they, what is their position within the organization, and, most important, why are they invited for the workshop; what role do they play in the discussions; leader, chairman, scribe...
  

Conducting Requirements Workshop

Two important pieces of advise come from D'Herbemont and Cesar [1998]. First: focus on your allies. If you have to get some points across, and people are against it, the natural reaction is to win them over by paying a lot of energy to them. Instead, you should support the people who agree on the matter in convincing the disbelievers.

"To get the right information out of the people that are in front of you, the simplest way is to ASK"

Some strategies which you can use:

• Be Stupid
  Don't be a smart ass. Even if you already know all of it, let the participants be the stars. They are the experts.
• Ask what you know
  Start for example with asking something you already know. Tell something you know is not correct. Try to get the attention and see who corrects what. Most of the time it gives you some glimpse of stakes.
• Repeat
  If some one tells you what, just repeat what he said, but using different words. In this way, you can get similarity in words used.
• Ask 5 times
  Ask five times why. That will give you the highest level of reason. Ask 5 times how, and it will bring you to the lowest level of operation.
  

Storyboard Tips

“A storyboard is a technique used to rehearse typical customer scenarios before the application is built. It could consist of hand-drawn overheads used in a presentation to the team building the requirement document, including the customers. The storyboard conveys a rough idea of the application's behavior, the application's interaction with the customer, and visible components. ”

What are Storyboards

• Sequences of images which demonstrate the relationship between events and actions within a system
• Use cases and storyboards together describe the way a system is used for a specific task
• Convey function, navigation (flow) and structure (form)
  -Function and flow during Analysis
  -Function, flow, and form during Information Design
• Supported by descriptive text annotations and use cases (use case descriptions and optionally scenarios)

Storyboard Rules

• Determine the audience and goals
• Define the setting and characters
• Determine key events and actions
• Structure storyboards into a narrative
• Create final presentation style and medium
• Review in a team and iterate
  

Techniques for Building Trust

• Assess Commitment
  Some stakeholders do not like to make decisions or agree to decisions in meetings. One-on-one meetings provide a safer venue to discuss real needs behind the stated—and unstated—needs.
• Address Individual Concerns
  Some individuals are more inclined to reveal their true concerns about the project and the other project stakeholders in one-on-one interviews, rather than in large groups. When elicitation is limited to facilitated sessions, these concerns go largely unaddressed.
• Address Negative Behavior
  Sometimes stakeholders either dominate meetings or demonstrate various types of behavior that negatively impact the group. By meeting individually, analysts and project managers can focus on the behavior and, together with the individual, determine ways to reduce its impact.
• Recognize Individual Achievement
  There are individuals who are not comfortable with public recognition. With these stakeholders, individual accomplishments are better recognized in private.
• Discuss the Project Objectives Openly
  If reducing headcount is a business objective and the project in question may contribute to meeting that objective, the project manager or analyst needs to communicate the possibility to the stakeholders if asked. Trust will not be built by avoiding the conversation or asking the stakeholders to discuss it with their bosses. Such a conversation can lead to one about the advantages to the employee of actively participating to help the organization meet its goals.
• Communicate Bad News
  If the project is behind schedule, needs more resources or lack of stakeholder participation is slowing the project, it is important for project managers and analysts to address these issues with the sponsor and other appropriate team members.
• Encourage Laughter
  There is a strong relationship between laughter and trust. Having fun in meetings and laughing appropriately (not hurtfully) even under pressure builds a sense of team solidarity and a desire to work together towards the desired project outcome.
• Define Clear Roles & Responsibilities
  When not defined, not only do tasks overlap, but they more commonly fall through the cracks, which invariably leads to finger-pointing, blame, and lowered morale. Clear definition helps prevent territorial squabbling and decreases the chance of misunderstanding and subsequent project delays.
  

Critical Success Factor for Requirement Gathering

• Choose the right member of your team
  Get a team who can meet the customer and communicate effectively with a non-technical audience. They also need to be good in articulating the document which can be effectively consumed by both customer and the development team
• Meet with the customer – early and often
  Since a business case drives the project, it is imperative to get them involved from the inception of the project. While e-mail is a great way of communication, the old fashioned way of human contact works like magic in gathering functional requirement
• Ask questions
  Interviewing and conversational techniques can be the difference between success and failure when it comes to extracting information and requirements from the customer. Timing becomes a critical factor in posing the questions which can make customer about current and proposed business process
• Clarify what the system will not do
  It’s of utmost importance to find out what the system won’t do equally as what the system will do. It’s equally important to identify what will be done by system and what will be done by users. Clearly document out of scope items from your document
• Avoid technical jargons
  Functional requirement meetings should focus only on the business process the system is going to manage. Discussion on implementation detail s should be taken only with the technical team.
• Document and reconfirm
  Clear, concise and thorough function requirement is key to success. The documentation should be used a bible for everyone related with the project
• Revisit the requirement often
  Project requirements are the building blocks for the remaining phases of the SDLC. Requirement is often considered as the yardstick for success or failure and as a development team it should be visited time and again