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.