# User Needs

## Line-by-line Instructions

### Agreed Goals

This should be a summary of product goals agreed to by both users and developers. You might have a draft of this at the beginning of the project if you were given a problem statement by the customer. More likely, you would arrive at this statement after you have completed requirements gathering. In either case, you might revise this statement as you learn the details of the problem and work through your solution. You should not have to revise it often, because details are best tracked in the use cases and feature specifications.

### What is the system's business environment?

A "business environment" is the overall business setting in which the system will be used. Describe who will use the system, the organization where those users work, who they work with, and which business processes the system affects.

### What is the system's physical environment?

Describe where the server will be located. And, describe where users will be located. Briefly note the physical characteristics of these environments affect the system's performance or usability.

### What is the system's technology environment (./hardware and software.md)?

Describe the hardware and software that the system depends on, or interoperates with. Note compatability features that users expect.

### Stakeholders / Actors

Start by listing different types of stakeholders and users. Use the greater-than notation to indicate subtypes of stakeholders and users. Then, come back to describe each class of stakeholder / user in detail. Use the sample text to prompt you to think of details and key needs of each class of stakeholder. As you go, make a note of key needs of that all stakeholders have in common. Review your interview and brainstorming notes and user stories to get more ideas.

### Notes from Interviews and Brainstorming

Link to interview notes, notes from brainstorming meetings, or other sources of information on user needs.

### User Stories

Write a few user stories to sketch out how users could use the system. User stories should be very short, simple, and concrete.

### Performance and Capacity Needs

If potential customers or users have stated performance or capacity needs, capture that here. These will be reconciled with other user needs and development team priorities when the SRS is written.
