1. Identify the Problem
(Common techniques used to find the problems behind the problem are brainstorming, fishbone diagrams and Pareto diagrams.)

1. Ask the group: What are the problems (aka business opportunities)?
2. Write down each problem and see if everyone agrees.
3. Then ask the group again: What is the problem, really?
4. Continue to ask “why?” to find out what the problem “really” is.

2. Formulate Problem Statements
1. For each problem you have identified, complete the following:

The problem of [describe the problem]

affects [the stakeholders affected by the problem].

The impact of which is [what is the impact of the problem].

A successful solution would [list some key benefits of a successful solution].

3. Identify the Stakeholders and Users
Requirements have many sources. They may come from anyone with an interest in the outcome of the project. Customers, partners, end users and domain experts are some sources of requirements. Management, project team members, business policies and regulatory agencies can be others.

1. Interview decision-makers, potential users and other interested parties. The following questions are helpful:
a. Who are the users of the system?
b. Who is the economic buyer for the system?
c. Who else will be affected by the outputs that the system produces?
d. Who will evaluate and bless the system when it is delivered and deployed?
e. Are there any other internal or external users of the system whose needs must be addressed?
f. Who will maintain the new system?
g. Is there anyone else?
h. Okay, is there anyone else?

2. Document initial profiles of potential (or actual) users of the system and their environment in the Vision document. (These will map to the roles of the human actors of the system being developed.)

4. Define System Boundaries
(The system boundary defines the border between the solution and the real world that surrounds the solution.)

1. Name the system actors and define each actor’s role.
2. Define the information—in the form of inputs and outputs—that is passed back and forth from the system to the users that live outside of the system.
3. Define the interfaces between the system and the external world.

5. Define Features of the System
1. Create a list of features you want in the system based on the benefits listed in your problem statements.
2. Describe each feature briefly.
3. Assign each feature a priority (Clarify the scale that priority is based on. Release version? Resource availability?)

6. Identify System Constraints
(The information gathered here will be the initial input to the design constraints defined in the Supplemental Specifications.)

There are a variety of sources of constraints to be considered. Much of this information may be documented in the business rules. Following is a list of potential sources and questions to ask:
1. Political: Are there internal or external political issues that affect potential solutions? Interdepartmental?
2. Economic: Which financial or budgetary constraints are applicable? Are there costs of goods sold, or product pricing considerations? Are there any licensing issues?
3. Environmental: Are there environmental or regulatory constraints? Legal? Other standards we are restricted by?
4. Technical: Are we restricted in our choice of technologies? Are we constrained to work within existing platforms or technologies? Are we prohibited from any new technologies?
5. Feasibility: Is the schedule defined? Are we restricted to existing resources? Can we use outside labor? Can we expand resources? Temporary? Permanent?
6. System: Is the solution to be built on our existing systems? Must we maintain compatibility with existing solutions? Which operating systems and environments must be supported?

7. Review the Effort
1. Ask the group:
a. Have we fully explored what the “problem behind the problem” is?
b. Is the problem statement correctly formulated?
c. Is the list of stakeholders complete and correct?
d. Does everyone agree on the definition of the system boundaries?
e. If system boundaries have been expressed using actors, have all actors been defined and correctly described?
f. Have we sufficiently explored constraints to be put on the system?
g. Have we covered all kinds of constraints – for example political, economic and environmental?
h. Have all key features of the system been identified and defined?
i. Will the features solve the problems that have been identified?
j. Are the features consistent with the constraints that have been identified?

2. Review any issues generated from this discussion and assign any action items for issue resolution.

Techniques for eliciting requirements include interviews, brainstorming, conceptual prototyping, questionnaires, and competitive analysis. The result of requirements elicitation is a list of requests or needs that are described textually and graphically, and that have been given priority relative to one another.