5. Conclusion

12 Commandments of Requirements Gathering

Requirements Gathering is an art and there is no defined fixed technique which can be applied. Every scenario where the user lands up to gather requirement is different than the others primarily because the operation style of each company is different from other.

Keeping the above constraint in mind the user can select from any of the techniques mentioned out here to define the customers requirement.

Wishing the readers a fruitful requirements gathering exercise.

PS: Let me know your feedbacks on areas requiring elaboration.

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

3. Sample Template

System Requirements Specification Template

Taken from Volere. Please refer http://www.volere.co.uk for further details.

The elements of SRS are outlined below:

Project Drivers

1. The purpose of the project
   i.User problem or background of the project effort
   ii.Goals of the project
2. Client, customer and other stakeholders
   i.Client – the person who authorizes the development, and/or is paying for it
   ii.Customer – the person (s) who will buy the product
   iii.Other stakeholders
3. Users of the product
   i.Hands on users – people who operate the product
   ii.Priorities assigned to users
   iii.User participation – an estimate of needed involvement in the project
   

Project Constraints

1. Mandated Constraint
   i.Solution Design Constraints
   ii.Implementation Environment of the current system
   iii.Partner or collaborative applications to be used by the product
   iv.Off-the-shelf software used within the product
   v.Anticipated workplace environment
   vi.Project duration budget
   vii.Financial budget for the project
2. Naming Conventions and Definitions
3. Relevant Facts and Assumptions
   i.Factors that have an effect on the product but are not mandated requirements constraints
   ii.Assumption the team is making about the project
   

Functional Requirements

1. Scope of the work
   i.Context of the work
   ii.Work partitioning or business use case list
2. The scope of the product
   i.Product Boundary
   ii.Product Use Case list
3. Functional and Data Requirements
   i.Functional requirements
   ii.Data requirements
   

Non-Functional Requirements

1. Look and feel requirements
   i.Interface appearance
   ii.Style of the product
2. Usability and Humanity Requirements
   i.Ease of use
   ii.Personalization and Internationalization requirements
   iii.Ease of learning
   iv.Understandability requirements
   v.Accessibility requirements
3. Performance Requirements
   i.Speed and latency requirements
   ii.Safety critical requirements
   iii.Precision requirements
   iv.Reliability and availability requirements
   v.Robustness requirements
   vi.Capacity requirements
   vii.Scalability or extensibility requirements
4. Operational requirements
   i.Expected physical environment
   ii.Expected technological environment
   iii.Partner applications
   iv.Productization requirements
5. Maintainability and Support requirements
   i.Maintenance requirements
   ii.Special conditions for maintenance
   iii.Supportability
   iv.Adaptability requirements
6. Security requirements
   i.Access requirements
   ii.Integrity requirements
   iii.Privacy requirements
   iv.Audit requirements
   v.Immunity requirements
7. Cultural and Political requirements
8. Legal requirements
   i.Compliance and Standards requirements
   

Project Issues

1. Open Issues
2. Off-the-shelf solutions
   i.Ready made products that can be bought
   ii.Ready made components suitable for this product
   iii.Other products that can be copied
3. New Problems
   i.New problems caused by installing the product in the current environment
   ii.Affects on the installed system
   iii.Adverse effects on existing users
   iv.Limitations of the anticipated implementation environment
   v.Other problems
4. Tasks
   i.Steps to be taken to deliver the product
   ii.Development phases
5. Cutover
   i.Special requirements to have the existing data and procedures work in conjunction with the new product
   ii.Data to be modified/translated for the new product
6. Risks
7. Costs
8. User documentation and training
9. Waiting room
10. Ideas for solutions
    

2. Rules of The Game

Planning the Requirements Gathering

Planning is a key to drive an effective Requirement Gathering exercise. In most cases people going for requirement gathering exercise don’t spend enough time in doing their homework which gets reflected in an ambiguous Requirements Specification document getting generated.

Some of the key elements which needs to focused as part of planning are listed below:

• Prepare a preliminary agenda for our Requirement Gathering window at onsite
• Clearly budget time for various activities which needs to be performed in preparing the requirement document
• Always budget time for validation and review
• If possible then book the calendar of business users
• Share the agenda with customer project manager and get into dialogue with him prior to travelling
• Get into discussion with him to get the feedback on your agenda and make the necessary modifications based on his input
• Keep sharing the requirement document with your offshore project manager on regular basis so that he can plan from project management related activities
• Keep a set of various requirement documents handy with you at onsite and use one of them based on the best fit
  

Requirements Phase vis-a-vis other Phases of SDLC

Requirement Gathering Process

Feasibility Study

Objective

• Feasibility study decides whether or not the proposed system is worthwhile
• Focused study that checks
• If the system contributes to organisational objectives
• If the system can be engineered using current technology and within budget
• If the system can be integrated with other existing systems

Process

• Based on information assessment (what is required), information collection and report writing
• Questions for people in the organisation
• What if the system wasn’t implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed system?

Output

• The FS report should recommend whether or not the system development should continue.
• It may propose changes to the scope, budget, schedule and also suggest requirement changes

Identifying Requirements

• What the system needs to do
• What does the user need
  
  “These must be accurate in order to construct an accurate system”

What are System Requirements?

• Define the services of the system
• Define the constraints on it’s operation

System Requirements are categorized as

• Functional Requirements
• Non-Functional Requirements
  

Functional Requirements

Example: A banking system

System Requirements

• Deposits
• Withdrawals
• Check Balance
• Provide overdrafts
• Etc..

User Requirements

• Logins
• Daily Reports
• Monitor accounts
• Etc…
  

Non-Functional Requirements

• Security
• User friendliness
• Reliability
• Maintainability
• Portability

Watch out for non-functional requirement, they can always be the surprise package

Requirements Elicitation & Analysis

Objective

• Requirement Discovery
• Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints
• May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders
  

Issues in Requirement Elicitation Process

• Based on information assessment (what is required), information collection and report writing
• Stakeholders don’t know what they really want
• Stakeholders express requirements in their own terms
• Different stakeholders may have conflicting requirements
• Organisational and political factors may influence the system requirements
• The requirements change during the analysis process. New stakeholders may emerge and the business environment change

Requirements Elicitation Process

Requirements Elicitation Process Activities

• Viewpoint Oriented Elicitation
• Domain understanding
• Requirements collection
• Classification
• Conflict resolution
• Prioritisation
• Requirements checking

Techniques for Requirements Elicitation & Analysis

• Viewpoint Oriented Elicitation

- Stakeholders represent different ways of looking at a problem or problem viewpoints

- This multi-perspective analysis is important as there is no single correct way to analyse system requirements

• Scenario Based Elicitation

- Scenarios are descriptions of how a system is used in practice

- They are helpful in requirements elicitation as people can relate to these more easily than an abstract statement of what they require from a system

- Scenarios are particularly useful for adding detail to an outline requirements description

Scenario Description

• System state at the beginning of the scenario
• Normal flow of events in the scenario
• What can go wrong and how this is handled
• Other concurrent activities
• System state on completion of the scenario
  

Scenario based Techniques

• Use Cases
• Event Scenarios
• Event scenarios may be used to describe how a system responds to the occurrence of some particular event
• Used in the Viewpoint Oriented Requirement Definition method

Ethnography Elicitation

• Stakeholders represent different ways of looking at a problem or problem viewpoints
• An analyst spends time observing and analysing how people actually work
• People do not have to explain their work
• Social and organisational factors of importance may be observed
• Identifies implicit system requirements
• Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models

Ethnography Description

• Requirements that are derived from the way that people actually work rather than the way in which process definitions suggest that they ought to work

- e.g. air-traffic controllers switch off flight path conflict alarms

• Requirements that are derived from cooperation and awareness of other people’s activities

- e.g. predict no. of aircraft entering their sector by getting information from neighboring controllers and plan accordingly

• Not suitable for using alone, has to be combined with some other technique
  

Tip: There is no standard method for Requirement Analysis

Conflict Resolution

It is inevitable that when intelligent and experienced people come together that there will be disagreement. While consensus is desired, there are times when schedules mandate a quick decision

Tips on Conflict Resolution:

• Focus on defeating the problem

Not each other

• Avoid voting, trading, or averaging, if possible
• Seek the facts

And respect cogent argument

• Accept conflict as helpful
• Don't allow it to generate threats

Or defensive reactions

• Avoid self-oriented behavior

That excludes the needs, views or positions of others

Requirements Prioritization

On projects producing large complex software intensive systems, it is not unusual to have hundreds and even thousands of individual requirements. And it is also not unusual for the customer organization acquiring such systems to have valid reasons to want each and every one of its requirements implemented.

The reasons why all these requirements cannot be implemented are:

• Differences in importance. Not all requirements are equally important, and the many different stakeholders in the system typically will not agree as to which requirements are most important.
• Limited project resources. All projects have limited resources in terms of budget, staff, and schedule. It is usually impossible to implement all of the requirements, at least not during the system’s current release. Thus, non-trivial systems are typically implemented using an incremental development cycle in which the requirements are incrementally developed and implemented.
• Long schedule. Such large incrementally-developed systems require many months or often multiple years to develop, during which the requirements are subject to significant iteration as the business environment changes, business needs change, and new requirements are identified.
• Small RE budget. Requirements engineering rarely receives more than 2-4% of the project budget, although several studies show that projects are more successful when 3-4 times as much of the budget and schedule is invested in getting the requirements right. Thus although requirements activities and tasks are typically time-boxed, the boxes allocated to requirements engineering are typically much too small and work must be properly prioritized.

Requirements Prioritization Dimensions

Requirements can be prioritized along many different, related and even opposing
dimensions. And these dimensions can be valued differently by different stakeholders.

For example, requirements can be prioritized by:

• Personal preference – Different stakeholders can prefer certain requirements over others
• Business Value – Some requirements will be critical, whereas others will be less important though still mandatory
• Harm avoidance – The opposite of prioritizing requirements in terms of their business value when implemented is to prioritize requirements in terms of the harm that can or will occur if the requirements is not implemented
• Risk – Prioritize requirements by risks associated with their implementation
• Cost – Given limited budgets, cost can be an important and overriding factor when prioritizing requirements
• Difficulty – Related to prioritizing requirements by risk and cost is prioritizing requirements by their estimated difficulty to implement
• Time to market – Some requirements take more time to get implemented with limited
  resource
• Requirements stability – Stable requirement on priority, hold-off unstable ones
• Dependencies among requirements – Dependency of lower tier with higher tier
• Implementation dependencies – Requirements pertaining to foundation component may get a higher priority
• Different kinds of requirements – Functional and Non-functional requirement will require different approach for prioritization
• Legal mandate – Requirements may be given high priority if mandated by law
• Frequency of use – Functional requirement may be given high priority based on frequency of usage
• Reuse – Requirement which is highly reusable within the product line
  

Requirement Prioritization Techniques

Various techniques can be used to determine, negotiate and develop a consensus regarding the priorities of the requirements:

• Business Case Analysis / Return On Investment (ROI) estimation
• Pair-wise comparisons
• Prioritization working groups
• Scale of 1-to-10 rankings
• Voting schemes (e.g., give each stakeholder a specific number of votes to distribute amongst the requirements or classes of requirements being prioritized)
• Weightings (e.g., weight the votes of different stakeholders)
• Value-Based Software Engineering [Boehm 2003]
• WIN-WIN [Boehm 2001]
• Quality Function Deployment (QFD)
  

The best approaches to use also depend on many factors such as the number of requirements to be prioritized and the formality of the requirements engineering process.

Requirements Validation

Objective

• Concerned with showing that the requirements define the system that the customer really wants
• Requirements error costs are high so validation is very important

- Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error


Types of Requirement Checking

• Concerned with showing that the requirements define the system that the customer really wants
• Validity. Does the system provide the functions which best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism. Can the requirements be implemented given available budget and technology
• Verifiability. Can the requirements be checked?
  

Requirements Validation Techniques

• Requirements reviews

- Systematic manual analysis of the requirements

- Regular reviews while the requirements definition is being formulated

- Both client and contractor staff should be involved in reviews

- Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage

• Prototyping

- Using an executable model of the system to check requirements.

• Test-case generation

- Developing tests for requirements to check testability

• Automated consistency analysis

- Checking the consistency of a structured requirements description

Requirements Management

• Requirements management is the process of managing changing requirements during the requirements engineering process and system development
• Requirements are inevitably incomplete and inconsistent
• New requirements emerge during the process as business needs change and a better understanding of the system is developed
• Different viewpoints have different requirements and these are often contradictory
  

Why Requirement Changes

• The priority of requirements from different viewpoints changes during the development process
• System customers may specify requirements from a business perspective that conflict with end-user requirements
• The business and technical environment of the system changes during its development
  

Requirements Management Planning

During the requirements engineering process, you have to plan:

• Requirements identification - How requirements are individually identified
• Change management process - The process followed when analysing a requirements change
• Traceability policies - The amount of information about requirements relationships that is maintained
• CASE tool support - The tool support required to help manage requirements change

Requirements Traceability

Requirement tracing means providing explicit information that identifies all the lower level requirements that drive from a higher level of requirement, and all the design or code elements that implement each specific requirements.

To implement requirement traceability every requirement at each level must be clearly identified and tagged. The tags must of course be unique.
The requirement tags supplied in the highest level of requirements documents don’t play a role in the development process until a lower level requirements or design document is written.

1. What's the Game all about

Definition: A statement about what the proposed system will do that all stakeholders agree must be made true in order for the customer’s problem to be adequately solved.

Startling Statistics

The significance of requirement can be best realized by looking at the failed endeavors which happened in software cycle.

• 2 million people working on 300,000 software projects in the US
• 1/3 to 2/3 of the projects will exceed their schedule and budget
• 1/2 will be canceled for being out of control

Why? Some major reasons:

The reasons of an IT project failure can be because of multiple reasons which can happen at any stage of the project. Some of the key reasons for failure can be because of issues related to Requirements Gathering, Application Design, Poor Development, Limited or not testing. Other than this the contributors can be because of improper planning – ranging from scheduling to risk management. Since the focus of the current paper is primarily restricted to requirements gathering we are going to concentrate on the failure causes related to Requirements Gathering.

Customer Issues

• The project team does not have the skills to conduct a successful project
• The project team is constrained by unrealistic top-down decisions
• Team members not signed on - low morale
• Improper Change Management Planning from the management
• Lack of buy-in within the customer organization

Vendor Issues

• Misunderstood business rules - major structure changes
• No defined set of requirements - feature creep and gold plating
• Skills issues from the vendor’s team
  

How much of this is requirements related?

According to the Standish Group’s latest Extreme Chaos Report of 2000 the findings are:

• Two thirds of all projects studied were either failures or what they call “challenged”
• Only half of the desired features made it into the finished product
• Cost overruns happened on nearly half of all projects, although the good news here is that cost containment has been substantially reduced over the 189% reported in their 1994 study
• Time overruns occurred 82% of the time, or on nearly every single project. Equally disturbing is that the trend has been worsening, since time overruns occurred only 63% of the time in their 2000 study.
  

What can a good requirement specification do for you?

A good requirement specification is like a food recipe, if all key ingredients are properly specified, process all defined then the output will be of a real good taste. However, a word of caution – food is always subjective to individual’s taste bud. Just like people have their own liking for spices, hotness etc, it’s practically impossible to create a recipe which can suit to user’s taste bud. Similarly while doing requirements gathering it is impossible to keep all stakeholders requirements in the scope. The best way it can be addressed is by making a recipe which can handle most of their requirements.

Some of the advantages of having clear requirements are:

• They can help reduce defects.
• It costs 5 to 10 times more fix a defect during or after implementation versus correcting it in the planning stage.
• “If you didn’t have 5 hours to fix it the first time, where are you going to find 50 hours to fix it later.”
• Provide tighter estimates and reduce schedule slippage.
• Decrease budget overruns.
• Increase project team member morale.
• Increase stakeholder morale.
• Increase Profits $$

What are some common software requirements?

People express requirements often is very high level terms which in most cases turns out to be the objective of a given IT initiative. The high level objective needs to be properly analyzed before recommending an appropriate solution.

Some of the standard ways through which people express their high level requirements are:

• Business rules - “Inventory shipments come on the 25th”
• Budget - “We only have $1,000 for this project”
• Interface - “We need a web enabled sales entry system”
• Reports or outputs - “Stock check; monthly or weekly summaries on ...”
• Performance - “There might be 5000 concurrent users …”
• Project Completion Date - “Oh, I need that next week …”
• Security - “Everyone must have their own login and can see..”
• Hardware - “We don’t want to buy additional hardware…14’’ screens will have to do.”
• Software - “Everything must coded in Java and XML…”
• Error - Embedded system for the fire sprinklers; financial.
• User level - “Mary has been dying to learn Windows...”
• System maintenance - “Jack, our stock guy, he can…”
• System location - “The server is located in Dallas and we connect using this here modem. Just wiggle the cord...”
• No subcontracting - “Due to confidentiality, we ask…”